salt(7)

NAME

   salt - Salt Documentation

INSTALLATION

   This  section contains instructions to install Salt. If you are setting
   up your environment for the first  time,  you  should  install  a  Salt
   master  on a dedicated management server or VM, and then install a Salt
   minion on each system that you want to manage using Salt. For  now  you
   don't  need  to  worry  about  your  architecture,  you  can easily add
   components and modify  your  configuration  later  without  needing  to
   reinstall anything.

   The general installation process is as follows:

   1. Install a Salt master using the instructions for your platform or by
      running the Salt bootstrap script. If you use the bootstrap  script,
      be sure to include the -M option to install the Salt master.

   2. Make sure that your Salt minions can find the Salt master.

   3. Install the Salt minion on each system that you want to manage.

   4. Accept the Salt minion keys after the Salt minion connects.

   After  this,  you  should  be  able to run a simple command and receive
   returns from all connected Salt minions.

      salt '*' test.ping

   Quick Install
   On most distributions, you can set up  a  Salt  Minion  with  the  Salt
   bootstrap.

   Platform-specific Installation Instructions
   These guides go into detail how to install Salt on a given platform.

   Arch Linux
   Installation
   Salt  (stable)  is  currently  available  via  the  Arch Linux Official
   repositories.  There are currently -git packages available in the  Arch
   User repositories (AUR) as well.

   Stable Release
   Install  Salt stable releases from the Arch Linux Official repositories
   as follows:

      pacman -S salt-zmq

   To install Salt stable  releases  using  the  RAET  protocol,  use  the
   following:

      pacman -S salt-raet

   NOTE:
      transports

      Unlike  other linux distributions, please be aware that Arch Linux's
      package manager pacman defaults to RAET as the  Salt  transport.  If
      you  want  to  use ZeroMQ instead, make sure to enter the associated
      number for the salt-zmq repository when prompted.

   Tracking develop
   To install the bleeding edge version of Salt (may include  bugs!),  use
   the -git package. Installing the -git package as follows:

      wget https://aur.archlinux.org/packages/sa/salt-git/salt-git.tar.gz
      tar xf salt-git.tar.gz
      cd salt-git/
      makepkg -is

   NOTE:
      yaourt

      If  a tool such as Yaourt is used, the dependencies will be gathered
      and built automatically.

      The command to install salt using the yaourt tool is:

          yaourt salt-git

   Post-installation tasks
   systemd

   Activate the Salt Master and/or Minion via systemctl as follows:

      systemctl enable salt-master.service
      systemctl enable salt-minion.service

   Start the Master

   Once you've completed all of these steps you're  ready  to  start  your
   Salt Master. You should be able to start your Salt Master now using the
   command seen here:

      systemctl start salt-master

   Now go to the Configuring Salt page.

   Debian GNU/Linux / Raspbian
   Debian GNU/Linux distribution and some  derivatives  such  as  Raspbian
   already  have  included  Salt  packages to their repositories. However,
   current stable release codenamed "Jessie" contains  old  outdated  Salt
   release.  It  is  recommended to use SaltStack repository for Debian as
   described below.

   Installation  from  official  Debian  and  Raspbian   repositories   is
   described here.

   Installation from the Official SaltStack Repository
   Packages  for  Debian 8 (Jessie) and Debian 7 (Wheezy) are available in
   the Official SaltStack repository.

   Instructions are at https://repo.saltstack.com/#debian.

   NOTE:
      Regular security support for Debian 7 ended on April 25th 2016. As a
      result,  2016.3.1  and  2015.8.10 will be the last Salt releases for
      which Debian 7 packages are created.

   Installation from the Debian / Raspbian Official Repository
   Stretch (Testing) and Sid (Unstable) distributions are already  contain
   mostly  up-to-date  Salt  packages  built  by Debian Salt Team. You can
   install Salt components directly from Debian.

   On Jessie (Stable) there is an  option  to  install  Salt  minion  from
   Stretch    with   python-tornado   dependency   from   jessie-backports
   repositories.

   To install fresh release of Salt minion on Jessie:

   1. Add jessie-backports and stretch repositories:

      Debian:

         echo 'deb http://httpredir.debian.org/debian jessie-backports main' >> /etc/apt/sources.list
         echo 'deb http://httpredir.debian.org/debian stretch main' >> /etc/apt/sources.list

      Raspbian:

         echo 'deb http://archive.raspbian.org/raspbian/ stretch main' >> /etc/apt/sources.list

   2. Make Jessie a default release:

         echo 'APT::Default-Release "jessie";' > /etc/apt/apt.conf.d/10apt

   3. Install Salt dependencies:

      Debian:

         apt-get update
         apt-get install python-zmq python-tornado/jessie-backports salt-common/stretch

      Raspbian:

         apt-get update
         apt-get install python-zmq python-tornado/stretch salt-common/stretch

   4. Install Salt minion package from Stretch:

         apt-get install salt-minion/stretch

   Install Packages
   Install the Salt master, minion or other packages from  the  repository
   with  the  apt-get  command.  These  examples  each install one of Salt
   components, but more than one package name may be given at a time:

   * apt-get install salt-api

   * apt-get install salt-cloud

   * apt-get install salt-master

   * apt-get install salt-minion

   * apt-get install salt-ssh

   * apt-get install salt-syndic

   Post-installation tasks
   Now, go to the Configuring Salt page.

   Fedora
   Beginning with version 0.9.4, Salt has been available  in  the  primary
   Fedora  repositories  and  EPEL.  It  is  installable using yum or dnf,
   depending on your version of Fedora.

   NOTE:
      Released versions of Salt starting with 2015.5.2 through 2016.3.2 do
      not have Fedora packages available though EPEL. To install a version
      of Salt within this release array, please use SaltStack's  Bootstrap
      Script and use the git method of installing Salt using the version's
      associated release tag.

      Release 2016.3.3 and onward will have  packaged  versions  available
      via EPEL.

   WARNING:  Fedora  19  comes  with  systemd 204.  Systemd has known bugs
   fixed in later revisions that prevent  the  salt-master  from  starting
   reliably or opening the network connections that it needs to.  It's not
   likely  that  a  salt-master  will  start  or  run  reliably   on   any
   distribution  that  uses  systemd  version  204  or  earlier.   Running
   salt-minions should be OK.

   Installation
   Salt can be installed using yum and is available in the standard Fedora
   repositories.

   Stable Release
   Salt  is  packaged  separately  for  the  minion  and the master. It is
   necessary only to install the appropriate  package  for  the  role  the
   machine  will  play.  Typically,  there will be one master and multiple
   minions.

      yum install salt-master
      yum install salt-minion

   Installing from updates-testing
   When a new Salt release is packaged, it  is  first  admitted  into  the
   updates-testing repository, before being moved to the stable repo.

   To install from updates-testing, use the enablerepo argument for yum:

      yum --enablerepo=updates-testing install salt-master
      yum --enablerepo=updates-testing install salt-minion

   Installation Using pip
   Since Salt is on PyPI, it can be installed using pip, though most users
   prefer to install using a package manager.

   Installing from pip has a few additional requirements:

   * Install the group 'Development Tools', dnf groupinstall  'Development
     Tools'

   * Install  the  'zeromq-devel'  package  if it fails on linking against
     that afterwards as well.

   A pip  install  does  not  make  the  init  scripts  or  the  /etc/salt
   directory, and you will need to provide your own systemd service unit.

   Installation from pip:

      pip install salt

   WARNING:
      If  installing  from pip (or from source using setup.py install), be
      advised that the yum-utils package is  needed  for  Salt  to  manage
      packages.   Also,   if  the  Python  dependencies  are  not  already
      installed, then you will need additional  libraries/tools  installed
      to build some of them.  More information on this can be found here.

   Post-installation tasks
   Master

   To have the Master start automatically at boot time:

      systemctl enable salt-master.service

   To start the Master:

      systemctl start salt-master.service

   Minion

   To have the Minion start automatically at boot time:

      systemctl enable salt-minion.service

   To start the Minion:

      systemctl start salt-minion.service

   Now go to the Configuring Salt page.

   FreeBSD
   Installation
   Salt  is  available  in binary package form from both the FreeBSD pkgng
   repository or directly from SaltStack. The instructions  below  outline
   installation via both methods:

   FreeBSD repo
   The  FreeBSD  pkgng  repository  is  preconfigured  on systems 10.x and
   above. No configuration is needed to pull from these repositories.

      pkg install py27-salt

   These packages are usually available within  a  few  days  of  upstream
   release.

   SaltStack repo
   SaltStack  also  hosts  internal  binary  builds  of  the Salt package,
   available from https://repo.saltstack.com/freebsd/. To make use of this
   repository, add the following file to your system:

   /usr/local/etc/pkg/repos/saltstack.conf:

      saltstack: {
        url: "https://repo.saltstack.com/freebsd/${ABI}/",
        enabled: yes
      }

   You should now be able to install Salt from this new repository:

      pkg install py27-salt

   These  packages  are  usually  available earlier than upstream FreeBSD.
   Also available are release candidates  and  development  releases.  Use
   these pre-release packages with caution.

   Post-installation tasks
   Master

   Copy the sample configuration file:

      cp /usr/local/etc/salt/master.sample /usr/local/etc/salt/master

   rc.conf

   Activate the Salt Master in /etc/rc.conf:

      sysrc salt_master_enable="YES"

   Start the Master

   Start the Salt Master as follows:

      service salt_master start

   Minion

   Copy the sample configuration file:

      cp /usr/local/etc/salt/minion.sample /usr/local/etc/salt/minion

   rc.conf

   Activate the Salt Minion in /etc/rc.conf:

      sysrc salt_minion_enable="YES"

   Start the Minion

   Start the Salt Minion as follows:

      service salt_minion start

   Now go to the Configuring Salt page.

   Gentoo
   Salt can be easily installed on Gentoo via Portage:

      emerge app-admin/salt

   Post-installation tasks
   Now go to the Configuring Salt page.

   OpenBSD
   Salt was added to the OpenBSD ports tree on Aug 10th 2013.  It has been
   tested on OpenBSD 5.5 onwards.

   Salt is dependent on the following  additional  ports.  These  will  be
   installed as dependencies of the sysutils/salt port:

      devel/py-futures
      devel/py-progressbar
      net/py-msgpack
      net/py-zmq
      security/py-crypto
      security/py-M2Crypto
      textproc/py-MarkupSafe
      textproc/py-yaml
      www/py-jinja2
      www/py-requests
      www/py-tornado

   Installation
   To install Salt from the OpenBSD pkg repo, use the command:

      pkg_add salt

   Post-installation tasks
   Master

   To have the Master start automatically at boot time:

      rcctl enable salt_master

   To start the Master:

      rcctl start salt_master

   Minion

   To have the Minion start automatically at boot time:

      rcctl enable salt_minion

   To start the Minion:

      rcctl start salt_minion

   Now go to the Configuring Salt page.

   OS X
   Installation from the Official SaltStack Repository
   Latest stable build from the selected branch:

   The  output  of  md5  <salt  pkg>  should  match  the  contents  of the
   corresponding md5 file.

   Earlier builds from supported branches

   Archived builds from unsupported branches

   Installation from Homebrew
      brew install saltstack

   It should be noted that Homebrew  explicitly  discourages  the  use  of
   sudo:
      Homebrew  is  designed to work without using sudo. You can decide to
      use it but we strongly recommend not to do so. If you have used sudo
      and  run  into a bug then it is likely to be the cause. Please don't
      file a bug report unless you can  reproduce  it  after  reinstalling
      Homebrew from scratch without using sudo

   Installation from MacPorts
      sudo port install salt

   Installation from Pip
   When only using the OS X system's pip, install this way:

      sudo pip install salt

   Salt-Master Customizations
   NOTE:
      Salt  master  on  OS  X is not tested or supported by SaltStack. See
      SaltStack Platform Support for more information.

   To run salt-master on OS X, sudo add this configuration option  to  the
   /etc/salt/master file:

      max_open_files: 8192

   On  versions  previous to OS X 10.10 (Yosemite), increase the root user
   maxfiles limit:

      sudo launchctl limit maxfiles 4096 8192

   NOTE:
      On OS  X  10.10  (Yosemite)  and  higher,  maxfiles  should  not  be
      adjusted.  The  default  limits  are  sufficient in all but the most
      extreme scenarios.  Overriding these values with the  setting  below
      will cause system instability!

   Now the salt-master should run without errors:

      sudo salt-master --log-level=all

   Post-installation tasks
   Now go to the Configuring Salt page.

   RHEL / CentOS / Scientific Linux / Amazon Linux / Oracle Linux
   Salt  should  work  properly with all mainstream derivatives of Red Hat
   Enterprise Linux, including CentOS, Scientific Linux, Oracle Linux, and
   Amazon Linux.  Report any bugs or issues on the issue tracker.

   Installation from the Official SaltStack Repository
   Packages  for  Redhat,  CentOS,  and  Amazon Linux are available in the
   SaltStack Repository.

   * Red Hat / CentOS

   * Amazon Linux

   NOTE:
      As of 2015.8.0, EPEL repository is no longer required for installing
      on   RHEL   systems.   SaltStack   repository  provides  all  needed
      dependencies.

   WARNING:
      If installing on Red Hat  Enterprise  Linux  7  with  disabled  (not
      subscribed  on)  'RHEL  Server  Releases'  or  'RHEL Server Optional
      Channel' repositories, append CentOS 7 GPG key URL to SaltStack  yum
      repository configuration to install required base packages:

          [saltstack-repo]
          name=SaltStack repo for Red Hat Enterprise Linux $releasever
          baseurl=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest
          enabled=1
          gpgcheck=1
          gpgkey=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/SALTSTACK-GPG-KEY.pub
                 https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/base/RPM-GPG-KEY-CentOS-7

   NOTE:
      systemd  and  systemd-python  are  required  by  Salt,  but  are not
      installed by the Red  Hat  7  @base  installation  or  by  the  Salt
      installation.  These  dependencies might need to be installed before
      Salt.

   Installation from the Community-Maintained Repository
   Beginning with version 0.9.4, Salt has  been  available  in  EPEL.  For
   RHEL/CentOS  5,  Fedora  COPR  is  a  single  community repository that
   provides Salt packages due to the removal from EPEL5.

   NOTE:
      Packages in these repositories are built by community,  and  it  can
      take a little while until the latest stable SaltStack release become
      available.

   RHEL/CentOS 6 and 7, Scientific Linux, etc.
   WARNING:
      Salt 2015.8 is currently not available in EPEL  due  to  unsatisfied
      dependencies:  python-crypto  2.6.1  or  higher,  and python-tornado
      version 4.2.1 or higher. These packages are not currently  available
      in EPEL for Red Hat Enterprise Linux 6 and 7.

   Enabling EPEL
   If  the  EPEL  repository  is  not  installed  on  your system, you can
   download the RPM for RHEL/CentOS 6 or for RHEL/CentOS 7 and install  it
   using the following command:

      rpm -Uvh epel-release-X-Y.rpm

   Replace epel-release-X-Y.rpm with the appropriate filename.

   Installing Stable Release
   Salt  is  packaged  separately  for  the  minion  and the master. It is
   necessary to install only the appropriate  package  for  the  role  the
   machine  will  play.   Typically, there will be one master and multiple
   minions.

      * yum install salt-master

      * yum install salt-minion

      * yum install salt-ssh

      * yum install salt-syndic

      * yum install salt-cloud

   Installing from epel-testing
   When a new Salt release is packaged, it  is  first  admitted  into  the
   epel-testing   repository,  before  being  moved  to  the  stable  EPEL
   repository.

   To install from epel-testing, use the enablerepo argument for yum:

      yum --enablerepo=epel-testing install salt-minion

   Installation Using pip
   Since Salt is on PyPI, it can be installed using pip, though most users
   prefer  to  install  using  RPM  packages  (which can be installed from
   EPEL).

   Installing from pip has a few additional requirements:

   * Install the group 'Development Tools', yum groupinstall  'Development
     Tools'

   * Install  the  'zeromq-devel'  package  if it fails on linking against
     that afterwards as well.

   A pip  install  does  not  make  the  init  scripts  or  the  /etc/salt
   directory, and you will need to provide your own systemd service unit.

   Installation from pip:

      pip install salt

   WARNING:
      If  installing  from pip (or from source using setup.py install), be
      advised that the yum-utils package is  needed  for  Salt  to  manage
      packages.   Also,   if  the  Python  dependencies  are  not  already
      installed, then you will need additional  libraries/tools  installed
      to build some of them.  More information on this can be found here.

   ZeroMQ 4
   We  recommend using ZeroMQ 4 where available. SaltStack provides ZeroMQ
   4.0.5 and pyzmq 14.5.0  in  the  SaltStack  Repository  as  well  as  a
   separate zeromq4 COPR repository.

   If  this  repository is added before Salt is installed, then installing
   either salt-master or salt-minion will  automatically  pull  in  ZeroMQ
   4.0.5,   and   additional   steps  to  upgrade  ZeroMQ  and  pyzmq  are
   unnecessary.

   WARNING:
      RHEL/CentOS 5 Users Using COPR repos on RHEL/CentOS 5 requires  that
      the  python-hashlib package be installed. Not having it present will
      result in checksum errors because YUM will not be  able  to  process
      the SHA256 checksums used by COPR.

   NOTE:
      For  RHEL/CentOS  5  installations,  if  using the SaltStack repo or
      Fedora COPR to install Salt (as described above),  then  it  is  not
      necessary  to  enable  the  zeromq4 COPR, because those repositories
      already include ZeroMQ 4.

   Package Management
   Salt's interface to yum makes heavy use of the repoquery utility,  from
   the  yum-utils  package. This package will be installed as a dependency
   if salt is installed via EPEL. However,  if  salt  has  been  installed
   using  pip,  or  a  host  is  being  managed using salt-ssh, then as of
   version 2014.7.0 yum-utils will be installed automatically  to  satisfy
   this dependency.

   Post-installation tasks
   Master
   To have the Master start automatically at boot time:

   RHEL/CentOS 5 and 6

      chkconfig salt-master on

   RHEL/CentOS 7

      systemctl enable salt-master.service

   To start the Master:

   RHEL/CentOS 5 and 6

      service salt-master start

   RHEL/CentOS 7

      systemctl start salt-master.service

   Minion
   To have the Minion start automatically at boot time:

   RHEL/CentOS 5 and 6

      chkconfig salt-minion on

   RHEL/CentOS 7

      systemctl enable salt-minion.service

   To start the Minion:

   RHEL/CentOS 5 and 6

      service salt-minion start

   RHEL/CentOS 7

      systemctl start salt-minion.service

   Now go to the Configuring Salt page.

   Solaris
   Salt  was  added to the OpenCSW package repository in September of 2012
   by Romeo Theriault <[email protected]> at version 0.10.2  of  Salt.  It
   has  mainly  been  tested on Solaris 10 (sparc), though it is built for
   and  has  been  tested  minimally  on  Solaris  10  (x86),  Solaris   9
   (sparc/x86) and 11 (sparc/x86).  (Please let me know if you're using it
   on these platforms!) Most of the testing has also just focused  on  the
   minion,  though  it has verified that the master starts up successfully
   on Solaris 10.

   Comments and patches for better support  on  these  platforms  is  very
   welcome.

   As of version 0.10.4, Solaris is well supported under salt, with all of
   the following working well:

   1. remote execution

   2. grain detection

   3. service control with SMF

   4. 'pkg' states with 'pkgadd' and 'pkgutil' modules

   5. cron modules/states

   6. user and group modules/states

   7. shadow password management modules/states

   Salt is dependent on the  following  additional  packages.  These  will
   automatically be installed as dependencies of the py_salt package:

   * py_yaml

   * py_pyzmq

   * py_jinja2

   * py_msgpack_python

   * py_m2crypto

   * py_crypto

   * python

   Installation
   To  install  Salt from the OpenCSW package repository you first need to
   install pkgutil assuming you don't already have it installed:

   On Solaris 10:

      pkgadd -d http://get.opencsw.org/now

   On Solaris 9:

      wget http://mirror.opencsw.org/opencsw/pkgutil.pkg
      pkgadd -d pkgutil.pkg all

   Once pkgutil  is  installed  you'll  need  to  edit  it's  config  file
   /etc/opt/csw/pkgutil.conf to point it at the unstable catalog:

      - #mirror=http://mirror.opencsw.org/opencsw/testing
      + mirror=http://mirror.opencsw.org/opencsw/unstable

   OK, time to install salt.

      # Update the catalog
      root> /opt/csw/bin/pkgutil -U
      # Install salt
      root> /opt/csw/bin/pkgutil -i -y py_salt

   Minion Configuration
   Now  that  salt  is  installed you can find it's configuration files in
   /etc/opt/csw/salt/.

   You'll want to edit the minion config file to set the name of your salt
   master server:

      - #master: salt
      + master: your-salt-server

   If  you  would  like to use pkgutil as the default package provider for
   your Solaris minions, you can do so using the providers option  in  the
   minion config file.

   You can now start the salt minion like so:

   On Solaris 10:

      svcadm enable salt-minion

   On Solaris 9:

      /etc/init.d/salt-minion start

   You  should now be able to log onto the salt master and check to see if
   the salt-minion key is awaiting acceptance:

      salt-key -l un

   Accept the key:

      salt-key -a <your-salt-minion>

   Run a simple test against the minion:

      salt '<your-salt-minion>' test.ping

   Troubleshooting
   Logs are in /var/log/salt

   Ubuntu
   Installation from the Official SaltStack Repository
   Packages for Ubuntu 16 (Xenial), Ubuntu  14  (Trusty),  and  Ubuntu  12
   (Precise) are available in the SaltStack repository.

   Instructions are at https://repo.saltstack.com/#ubuntu.

   Installation from the Community-Maintained Repository
   Packages  for  Ubuntu  are  also published in the saltstack PPA. If you
   have the add-apt-repository utility, you can  add  the  repository  and
   import the key in one step:

      sudo add-apt-repository ppa:saltstack/salt

   In  addition  to  the main repository, there are secondary repositories
   for each individual major release. These repositories receive  security
   and  point  releases  but  will  not  upgrade  to  any subsequent major
   release.  There are currently several available repos: salt16,  salt17,
   salt2014-1,  salt2014-7,  salt2015-5.  For  example  to follow 2015.5.x
   releases:

      sudo add-apt-repository ppa:saltstack/salt2015-5

      add-apt-repository: command not found?

             The add-apt-repository  command  is  not  always  present  on
             Ubuntu   systems.    This   can   be   fixed   by  installing
             python-software-properties:

          sudo apt-get install python-software-properties

      The following may be required as well:

          sudo apt-get install software-properties-common

      Note that since Ubuntu 12.10 (Raring  Ringtail),  add-apt-repository
      is  found  in the software-properties-common package, and is part of
      the base install. Thus, add-apt-repository should be able to be used
      out-of-the-box to add the PPA.

   Alternately,  manually  add  the repository and import the PPA key with
   these commands:

      echo deb http://ppa.launchpad.net/saltstack/salt/ubuntu `lsb_release -sc` main | sudo tee /etc/apt/sources.list.d/saltstack.list
      wget -q -O- "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x4759FA960E27C0A6" | sudo apt-key add -

   After adding the repository, update the package management database:

      sudo apt-get update

   Install Packages
   Install the Salt master, minion or other packages from  the  repository
   with  the  apt-get  command.  These  examples  each install one of Salt
   components, but more than one package name may be given at a time:

   * apt-get install salt-api

   * apt-get install salt-cloud

   * apt-get install salt-master

   * apt-get install salt-minion

   * apt-get install salt-ssh

   * apt-get install salt-syndic

   Post-installation tasks
   Now go to the Configuring Salt page.

   Windows
   Salt has full support for running the Salt minion on Windows. You  must
   connect  Windows Salt minions to a Salt master on a supported operating
   system to control your Salt Minions.

   Many of the standard Salt modules have been ported to work  on  Windows
   and many of the Salt States currently work on Windows as well.

   Installation from the Official SaltStack Repository
   Latest stable build from the selected branch:

   The output of md5sum <salt minion exe> should match the contents of the
   corresponding md5 file.

   Earlier builds from supported branches

   Archived builds from unsupported branches

   NOTE:
      The installation executable  installs  dependencies  that  the  Salt
      minion requires.

   The  64bit  installer  has  been  tested on Windows 7 64bit and Windows
   Server 2008R2 64bit. The 32bit installer has  been  tested  on  Windows
   2008  Server  32bit.   Please  file  a bug report on our GitHub repo if
   issues for other platforms are found.

   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.

   The  installer asks for two additional bits of information to configure
   the minion; the master hostname and the minion name. The installer will
   update the minion config with these options.

   The final page allows you to select which services to start.

   The  salt-minion service will appear in the Windows Service Manager and
   can be started and stopped there or with the command  line  program  sc
   like any other Windows service.

      sc start salt-minion
      net start salt-minion

   If the minion won't start, try installing the Microsoft Visual C++ 2008
   x64 SP1 redistributable. Allow all Windows updates to  run  salt-minion
   smoothly.

   Installation Prerequisites
   Most  Salt  functionality should work just fine right out of the box. A
   few Salt modules rely on PowerShell. The minimum version of  PowerShell
   required  for  Salt  is  version 3. If you intend to work with DSC then
   Powershell version 5 is the minimum.

   Silent Installer Options
   The installer can be run silently by providing the  /S  option  at  the
   command  line.  The  installer  also  accepts the following options for
   configuring the Salt Minion silently:

   * /master= A string value to set the IP address or  host  name  of  the
     master. Default value is 'salt'

   * /minion-name=  A  string  value  to  set  the minion name. Default is
     'hostname'

   * /start-minion= Either a 1  or  0.  '1'  will  start  the  salt-minion
     service,  '0'  will  not.  Default  is  to  start  the  service after
     installation.

   NOTE:
      /start-service has been deprecated but will continue to function  as
      expected for the time being.

   Here are some examples of using the silent installer:

      # Will install the minion and start the service

      *-Setup-*.exe /S /master=yoursaltmaster /minion-name=yourminionname

      # Will install the minion but will NOT start the salt-minion service

      *-Setup-*.exe /S /master=yoursaltmaster /minion-name=yourminionname /start-minion=0

   Running the Salt Minion on Windows as an Unprivileged User
   Notes:

   * These instructions were tested with Windows Server 2008 R2

   * They  are  generalizable  to  any  version of Windows that supports a
     salt-minion

   Create the Unprivileged User that the Salt Minion will Run As
   1.  Click Start > Control Panel > User Accounts.

   2.  Click Add or remove user accounts.

   3.  Click Create new account.

   4.  Enter salt-user (or a name of your preference) in the  New  account
       name field.

   5.  Select the Standard user radio button.

   6.  Click the Create Account button.

   7.  Click on the newly created user account.

   8.  Click the Create a password link.

   9.  In  the  New  password  and  Confirm new password fields, provide a
       password (e.g "SuperSecretMinionPassword4Me!").

   10. In the Type a password hint field, provide appropriate  text  (e.g.
       "My Salt Password").

   11. Click the Create password button.

   12. Close the Change an Account window.

   Add the New User to the Access Control List for the Salt Folder
   1. In  a  File  Explorer  window,  browse  to  the  path  where Salt is
      installed (the default path is C:\Salt).

   2. Right-click on the Salt folder and select Properties.

   3. Click on the Security tab.

   4. Click the Edit button.

   5. Click the Add button.

   6. Type the name of your designated Salt user and click the OK button.

   7. Check the box to Allow the Modify permission.

   8. Click the OK button.

   9. Click the OK button to close the Salt Properties window.

   Update the Windows Service User for the salt-minion Service
   1.  Click Start > Administrative Tools > Services.

   2.  In  the  Services  list,  right-click  on  salt-minion  and  select
       Properties.

   3.  Click the Log On tab.

   4.  Click the This account radio button.

   5.  Provide the account credentials created in section A.

   6.  Click the OK button.

   7.  Click the OK button to the prompt confirming that the user has been
       granted the Log On As A Service right.

   8.  Click the OK button to the prompt confirming  that  The  new  logon
       name will not take effect until you stop and restart the service.

   9.  Right-Click on salt-minion and select Stop.

   10. Right-Click on salt-minion and select Start.

   Building and Developing on Windows
   This  document will explain how to set up a development environment for
   Salt on Windows. The development environment allows you  to  work  with
   the  source  code  to  customize or fix bugs. It will also allow you to
   build your own installation.

   There are several scripts to automate creating a Windows  installer  as
   well  as  setting  up  an  environment  that facilitates developing and
   troubleshooting  Salt  code.  They  are  located  in  the   pkg\windows
   directory in the Salt repo (here).

   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                    
                

   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.

   Prerequisite Software
   The only prerequisite is Git for Windows.

   Create a Build Environment
   1. Working Directory
   Create a Salt-Dev directory on the root of C:. This will be our working
   directory. Navigate to Salt-Dev and clone the Salt repo from GitHub.

   Open a command line and type:

      cd \
      md Salt-Dev
      cd Salt-Dev
      git clone https://github.com/saltstack/salt

   Go into the salt directory and checkout the version  of  salt  to  work
   with (2016.3 or higher).

      cd salt
      git checkout 2016.3

   2. Setup the Python Environment
   Navigate  to  the  pkg\windows  directory and execute the build_env.ps1
   PowerShell script.

      cd pkg\windows
      powershell -file build_env.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
      selecting Run with PowerShell

   This will download and install Python with all the dependencies  needed
   to develop and build Salt.

   NOTE:
      If  you  get  an  error  or  the script fails to run you may need to
      change the execution policy. Open a powershell window and  type  the
      following command:

      Set-ExecutionPolicy RemoteSigned

   3. Salt in Editable Mode
   Editable  mode  allows  you  to  more easily modify and test the source
   code. For more information see the Pip documentation.

   Navigate to the root of the salt directory and install Salt in editable
   mode with pip

      cd \Salt-Dev\salt
      pip install -e .

   NOTE:
      The . is important

   NOTE:
      If  pip is not recognized, you may need to restart your shell to get
      the updated path

   4. Setup Salt Configuration
   Salt requires a minion configuration file and a few other  directories.
   The  default  config  file is named minion located in C:\salt\conf. The
   easiest  way  to  set  this  up  is  to  copy  the  contents   of   the
   salt\pkg\windows	uildenv directory to C:\salt.

      cd \
      md salt
      xcopy /s /e \Salt-Dev\salt\pkg\windows	uildenv\* \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:

      master: <ip or name of your master>
      id: <name of your minion>

   Create a Windows Installer
   To create a Windows installer, follow steps 1 and 2 from Create a Build
   Environment above. Then proceed to 3 below:

   3. Install Salt
   To create the installer for Window we install Salt using Python instead
   of pip.  Navigate to the root salt directory and install Salt.

      cd \Salt-Dev\salt
      python setup.py install

   4. Create the Windows Installer
   Navigate  to  the  pkg\windows directory and run the build_pkg.bat with
   the build version (2016.3) script.

      cd pkg\windows
      build_pkg.bat 2016.3

   NOTE:
      If no version is passed, the build_pkg.bat will  guess  the  version
      number using git.

   Creating a Windows Installer: Alternate Method (Easier)
   Clone  the  Salt  repo  from  GitHub into the directory of your choice.
   We're going to use Salt-Dev.

      cd \
      md Salt-Dev
      cd Salt-Dev
      git clone https://github.com/saltstack/salt

   Go into the salt directory and checkout the version of Salt you want to
   build.

      cd salt
      git checkout 2016.3

   Then  navigate  to  pkg\windows  and  run the build.bat script with the
   version you're building.

      cd pkg\windows
      build.bat 2016.3

   This will install everything needed to build a  Windows  installer  for
   Salt. The binary will be in the salt\pkg\windows\installer directory.

   Testing the Salt minion
   1. Create the directory C:\salt (if it doesn't exist already)

   2.

      Copy the example conf and var directories from
             pkg\windows	uildenv into C:\salt

   3. Edit C:\salt\conf\minion

             master: ipaddress or hostname of your salt-master

   4. Start the salt-minion

             cd C:\Python27\Scripts
             python salt-minion -l debug

   5. On the salt-master accept the new minion's key

             sudo salt-key -A

         This  accepts  all  unaccepted  keys.  If  you're concerned about
         security just accept the key for this specific minion.

   6. Test that your minion is responding
         On the salt-master run:

             sudo salt '*' test.ping

   You should get the following response: {'your minion hostname': True}

   Packages Management Under Windows 2003
   Windows Server 2003 and Windows XP have both reached  End  of  Support.
   Though  Salt  is not officially supported on operating systems that are
   EoL, some functionality may continue to work.

   On Windows Server 2003, you need to  install  optional  component  "WMI
   Windows  Installer  Provider" to get a full list of installed packages.
   If you  don't  have  this,  salt-minion  can't  report  some  installed
   software.

   SUSE
   Installation from the Official SaltStack Repository
   Packages  for  SUSE  12 SP1, SUSE 12, SUSE 11, openSUSE 13 and openSUSE
   Leap 42.1 are available in the SaltStack Repository.

   Instructions are at https://repo.saltstack.com/#suse.

   Installation from the SUSE Repository
   Since openSUSE  13.2,  Salt  2014.1.11  is  available  in  the  primary
   repositories.   With  the  release  of  SUSE manager 3 a new repository
   setup    has    been    created.     The    new    repo     will     by
   systemsmanagement:saltstack,  which  is  the  source  for  newer stable
   packages. For backward compatibility a linkpackage will be  created  to
   the  old  devel:language:python repo.  All development of suse packages
   will be done in systemsmanagement:saltstack:testing.  This will  ensure
   that  salt will be in mainline suse repo's, a stable release repo and a
   testing repo for further enhancements.

   Installation
   Salt can be installed using zypper and is  available  in  the  standard
   openSUSE/SLES repositories.

   Stable Release
   Salt  is  packaged  separately  for  the  minion  and the master. It is
   necessary only to install the appropriate  package  for  the  role  the
   machine  will  play.  Typically,  there will be one master and multiple
   minions.

      zypper install salt-master
      zypper install salt-minion

   Post-installation tasks openSUSE
   Master

   To have the Master start automatically at boot time:

      systemctl enable salt-master.service

   To start the Master:

      systemctl start salt-master.service

   Minion

   To have the Minion start automatically at boot time:

      systemctl enable salt-minion.service

   To start the Minion:

      systemctl start salt-minion.service

   Post-installation tasks SLES
   Master

   To have the Master start automatically at boot time:

      chkconfig salt-master on

   To start the Master:

      rcsalt-master start

   Minion

   To have the Minion start automatically at boot time:

      chkconfig salt-minion on

   To start the Minion:

      rcsalt-minion start

   Unstable Release
   openSUSE
   For openSUSE Tumbleweed run the following as root:

      zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/saltstack/openSUSE_Tumbleweed/systemsmanagement:saltstack.repo
      zypper refresh
      zypper install salt salt-minion salt-master

   For openSUSE 42.1 Leap run the following as root:

      zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/saltstack/openSUSE_Leap_42.1/systemsmanagement:saltstack.repo
      zypper refresh
      zypper install salt salt-minion salt-master

   For openSUSE 13.2 run the following as root:

      zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/saltstack/openSUSE_13.2/systemsmanagement:saltstack.repo
      zypper refresh
      zypper install salt salt-minion salt-master

   SUSE Linux Enterprise
   For SLE 12 run the following as root:

      zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/saltstack/SLE_12/systemsmanagement:saltstack.repo
      zypper refresh
      zypper install salt salt-minion salt-master

   For SLE 11 SP4 run the following as root:

      zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/saltstack/SLE_11_SP4/systemsmanagement:saltstack.repo
      zypper refresh
      zypper install salt salt-minion salt-master

   Now go to the Configuring Salt page.

   Initial Configuration
   Configuring Salt
   Salt configuration is very simple. The default  configuration  for  the
   master  will  work  for most installations and the only requirement for
   setting up a minion is to set the location of the master in the  minion
   configuration file.

   The  configuration  files  will be installed to /etc/salt and are named
   after    the    respective    components,     /etc/salt/master,     and
   /etc/salt/minion.

   Master Configuration
   By  default  the  Salt  master  listens  on  ports 4505 and 4506 on all
   interfaces (0.0.0.0). To bind Salt  to  a  specific  IP,  redefine  the
   "interface"  directive  in  the  master  configuration  file, typically
   /etc/salt/master, as follows:

      - #interface: 0.0.0.0
      + interface: 10.0.0.1

   After updating the configuration file, restart the  Salt  master.   See
   the  master  configuration  reference  for  more  details  about  other
   configurable options.

   Minion Configuration
   Although there are many Salt Minion configuration options,  configuring
   a  Salt  Minion  is  very  simple. By default a Salt Minion will try to
   connect to the DNS name "salt"; if the Minion is able to  resolve  that
   name correctly, no configuration is needed.

   If  the  DNS  name  "salt"  does  not  resolve  to point to the correct
   location of the Master, redefine the "master" directive in  the  minion
   configuration file, typically /etc/salt/minion, as follows:

      - #master: salt
      + master: 10.0.0.1

   After  updating  the  configuration file, restart the Salt minion.  See
   the  minion  configuration  reference  for  more  details  about  other
   configurable options.

   Running Salt
   1. Start  the  master in the foreground (to daemonize the process, pass
      the -d flag):

         salt-master

   2. Start the minion in the foreground (to daemonize the  process,  pass
      the -d flag):

         salt-minion

      Having trouble?

             The  simplest  way  to troubleshoot Salt is to run the master
             and minion in the foreground with log level set to debug:

          salt-master --log-level=debug

      For information on salt's logging  system  please  see  the  logging
      document.

      Run as an unprivileged (non-root) user

             To  run  Salt  as another user, set the user parameter in the
             master config file.

             Additionally, ownership, and permissions need to be set  such
             that  the  desired  user  can  read  from  and  write  to the
             following  directories  (and  their   subdirectories,   where
             applicable):

      * /etc/salt

      * /var/cache/salt

      * /var/log/salt

      * /var/run/salt

      More  information about running salt as a non-privileged user can be
      found here.

   There is also a full troubleshooting guide available.

   Key Identity
   Salt provides commands to validate the identity of your Salt master and
   Salt  minions  before the initial key exchange. Validating key identity
   helps avoid inadvertently connecting to  the  wrong  Salt  master,  and
   helps  prevent  a  potential  MiTM attack when establishing the initial
   connection.

   Master Key Fingerprint
   Print the master key fingerprint by running the  following  command  on
   the Salt master:

      salt-key -F master

   Copy  the  master.pub fingerprint from the Local Keys section, and then
   set this value as the master_finger in the minion  configuration  file.
   Save the configuration file and then restart the Salt minion.

   Minion Key Fingerprint
   Run  the  following  command on each Salt minion to view the minion key
   fingerprint:

      salt-call --local key.finger

   Compare this value to the value that is  displayed  when  you  run  the
   salt-key --finger <MINION_ID> command on the Salt master.

   Key Management
   Salt  uses  AES encryption for all communication between the Master and
   the Minion. This ensures that the commands sent to the  Minions  cannot
   be  tampered  with, and that communication between Master and Minion is
   authenticated through trusted, accepted keys.

   Before commands can be sent to a Minion, its key must  be  accepted  on
   the Master. Run the salt-key command to list the keys known to the Salt
   Master:

      [root@master ~]# salt-key -L
      Unaccepted Keys:
      alpha
      bravo
      charlie
      delta
      Accepted Keys:

   This example shows that the Salt Master is aware of four  Minions,  but
   none  of  the  keys has been accepted. To accept the keys and allow the
   Minions to be controlled by the Master, again use the salt-key command:

      [root@master ~]# salt-key -A
      [root@master ~]# salt-key -L
      Unaccepted Keys:
      Accepted Keys:
      alpha
      bravo
      charlie
      delta

   The salt-key command allows for signing keys individually or  in  bulk.
   The  example  above,  using -A bulk-accepts all pending keys. To accept
   keys individually use the lowercase of the same option, -a keyname.

   SEE ALSO:
      salt-key manpage

   Sending Commands
   Communication between the Master  and  a  Minion  may  be  verified  by
   running the test.ping command:

      [root@master ~]# salt alpha test.ping
      alpha:
          True

   Communication  between  the  Master  and all Minions may be tested in a
   similar way:

      [root@master ~]# salt '*' test.ping
      alpha:
          True
      bravo:
          True
      charlie:
          True
      delta:
          True

   Each of the Minions should send a True response as shown above.

   What's Next?
   Understanding targeting is important. From there, depending on the  way
   you  wish  to  use  Salt, you should also proceed to learn about Remote
   Execution and Configuration Management.

   Additional Installation Guides
   Salt Bootstrap
   The Salt Bootstrap script allows for a user to install the Salt  Minion
   or Master on a variety of system distributions and versions. This shell
   script known as bootstrap-salt.sh runs through a series  of  checks  to
   determine  the  operating system type and version. It then installs the
   Salt binaries using the appropriate methods. The Salt Bootstrap  script
   installs  the  minimum  number  of  packages required to run Salt. This
   means that in the event you run the bootstrap to install  via  package,
   Git  will  not be installed.  Installing the minimum number of packages
   helps ensure the script stays as lightweight as possible, assuming  the
   user  will  install any other required packages after the Salt binaries
   are present on the system. The script source is  available  on  GitHub:
   https://github.com/saltstack/salt-bootstrap

   Supported Operating Systems
   NOTE:
      In  the  event you do not see your distribution or version available
      please review the develop  branch  on  GitHub  as  it  main  contain
      updates    that   are   not   present   in   the   stable   release:
      https://github.com/saltstack/salt-bootstrap/tree/develop

   Debian and derivatives
   * Debian GNU/Linux 7/8

   * Linux Mint Debian Edition 1 (based on Debian 8)

   * Kali Linux 1.0 (based on Debian 7)

   Red Hat family
   * Amazon Linux 2012.09/2013.03/2013.09/2014.03/2014.09

   * CentOS 5/6/7

   * Fedora 17/18/20/21/22

   * Oracle Linux 5/6/7

   * Red Hat Enterprise Linux 5/6/7

   * Scientific Linux 5/6/7

   SUSE family
   * openSUSE 12/13

   * openSUSE Leap 42

   * openSUSE Tumbleweed 2015

   * SUSE Linux Enterprise Server 11 SP1/11 SP2/11 SP3/12

   Ubuntu and derivatives
   * Elementary OS 0.2 (based on Ubuntu 12.04)

   * Linaro 12.04

   * Linux Mint 13/14/16/17

   * Trisquel GNU/Linux 6 (based on Ubuntu 12.04)

   * Ubuntu 10.x/11.x/12.x/13.x/14.x/15.x/16.x

   Other Linux distro
   * Arch Linux

   * Gentoo

   UNIX systems
   BSD:

   * OpenBSD (pip installation)

   * FreeBSD 9/10/11

   SunOS:

   * SmartOS

   Example Usage
   If you're looking for the one-liner to install Salt, please  scroll  to
   the  bottom  and  use  the  instructions for Installing via an Insecure
   One-Liner

   NOTE:
      In every two-step example, you would be well-served to  examine  the
      downloaded  file  and  examine  it  to  ensure that it does what you
      expect.

   The Salt Bootstrap script has a wide variety of  options  that  can  be
   passed  as  well  as  several  ways  of  obtaining the bootstrap script
   itself.

   NOTE:
      These examples below show how to bootstrap Salt directly from GitHub
      or  other  Git repository.  Run the script without any parameters to
      get latest stable Salt  packages  for  your  system  from  SaltStack
      corporate  repository.  See  first example in the Install using wget
      section.

   Install using curl
   Using curl to install latest development version from GitHub:

      curl -o bootstrap-salt.sh -L https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh git develop

   If you want to install a specific release version  (based  on  the  Git
   tags):

      curl -o bootstrap-salt.sh -L https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh git v2015.8.8

   To install a specific branch from a Git fork:

      curl -o bootstrap-salt.sh -L https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh -g https://github.com/myuser/salt.git git mybranch

   If all you want is to install a salt-master using latest Git:

      curl -o bootstrap-salt.sh -L https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh -M -N git develop

   If your host has Internet access only via HTTP proxy:

      PROXY='http://user:[email protected]:3128'
      curl -o bootstrap-salt.sh -L -x "$PROXY" https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh -G -H "$PROXY" git

   Install using wget
   Using wget to install your distribution's stable packages:

      wget -O bootstrap-salt.sh https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh

   Downloading the script from develop branch:

      wget -O bootstrap-salt.sh https://bootstrap.saltstack.com/develop
      sudo sh bootstrap-salt.sh

   Installing a specific version from git using wget:

      wget -O bootstrap-salt.sh https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh -P git v2015.8.8

   NOTE:
      On the above example we added -P which will allow PIP packages to be
      installed if required but it's not a necessary flag  for  Git  based
      bootstraps.

   Install using Python
   If you already have Python installed, python 2.6, then it's as easy as:

      python -m urllib "https://bootstrap.saltstack.com" > bootstrap-salt.sh
      sudo sh bootstrap-salt.sh git develop

   All Python versions should support the following in-line code:

      python -c 'import urllib; print urllib.urlopen("https://bootstrap.saltstack.com").read()' > bootstrap-salt.sh
      sudo sh bootstrap-salt.sh git develop

   Install using fetch
   On  a  FreeBSD  base  system you usually don't have either of the above
   binaries available. You do have fetch available though:

      fetch -o bootstrap-salt.sh https://bootstrap.saltstack.com
      sudo sh bootstrap-salt.sh

   If you have any SSL issues install ca_root_nssp:

      pkg install ca_root_nssp

   And either copy the certificates to the  place  where  fetch  can  find
   them:

      cp /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem

   Or link them to the right place:

      ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem

   Installing via an Insecure One-Liner
   The following examples illustrate how to install Salt via a one-liner.

   NOTE:
      Warning! These methods do not involve a verification step and assume
      that the delivered file is trustworthy.

   Any of the example above which use two-lines can be made to  run  in  a
   single-line configuration with minor modifications.

   For example, using curl to install your distribution's stable packages:

      curl -L https://bootstrap.saltstack.com | sudo sh

   Using wget to install your distribution's stable packages:

      wget -O - https://bootstrap.saltstack.com | sudo sh

   Installing the latest develop branch of Salt:

      curl -L https://bootstrap.saltstack.com | sudo sh -s -- git develop

   Command Line Options
   Here's a summary of the command line options:

      $ sh bootstrap-salt.sh -h

        Usage :  bootstrap-salt.sh [options] <install-type> <install-type-args>

        Installation types:
          - stable (default)
          - stable [version] (ubuntu specific)
          - daily  (ubuntu specific)
          - testing (redhat specific)
          - git

        Examples:
          - bootstrap-salt.sh
          - bootstrap-salt.sh stable
          - bootstrap-salt.sh stable 2014.7
          - bootstrap-salt.sh daily
          - bootstrap-salt.sh testing
          - bootstrap-salt.sh git
          - bootstrap-salt.sh git develop
          - bootstrap-salt.sh git v0.17.0
          - bootstrap-salt.sh git 8c3fadf15ec183e5ce8c63739850d543617e4357

        Options:
        -h  Display this message
        -v  Display script version
        -n  No colours.
        -D  Show debug output.
        -c  Temporary configuration directory
        -g  Salt repository URL. (default: git://github.com/saltstack/salt.git)
        -G  Instead of cloning from git://github.com/saltstack/salt.git, clone from https://github.com/saltstack/salt.git (Usually necessary on systems which have the regular git protocol port blocked, where https usually is not)
        -k  Temporary directory holding the minion keys which will pre-seed
            the master.
        -s  Sleep time used when waiting for daemons to start, restart and when checking
            for the services running. Default: 3
        -M  Also install salt-master
        -S  Also install salt-syndic
        -N  Do not install salt-minion
        -X  Do not start daemons after installation
        -C  Only run the configuration function. This option automatically
            bypasses any installation.
        -P  Allow pip based installations. On some distributions the required salt
            packages or its dependencies are not available as a package for that
            distribution. Using this flag allows the script to use pip as a last
            resort method. NOTE: This only works for functions which actually
            implement pip based installations.
        -F  Allow copied files to overwrite existing(config, init.d, etc)
        -U  If set, fully upgrade the system prior to bootstrapping salt
        -K  If set, keep the temporary files in the temporary directories specified
            with -c and -k.
        -I  If set, allow insecure connections while downloading any files. For
            example, pass '--no-check-certificate' to 'wget' or '--insecure' to 'curl'
        -A  Pass the salt-master DNS name or IP. This will be stored under
            ${BS_SALT_ETC_DIR}/minion.d/99-master-address.conf
        -i  Pass the salt-minion id. This will be stored under
            ${BS_SALT_ETC_DIR}/minion_id
        -L  Install the Apache Libcloud package if possible(required for salt-cloud)
        -p  Extra-package to install while installing salt dependencies. One package
            per -p flag. You're responsible for providing the proper package name.
        -d  Disable check_service functions. Setting this flag disables the
            'install_<distro>_check_services' checks. You can also do this by
            touching /tmp/disable_salt_checks on the target host. Defaults ${BS_FALSE}
        -H  Use the specified http proxy for the installation
        -Z  Enable external software source for newer ZeroMQ(Only available for RHEL/CentOS/Fedora/Ubuntu based distributions)
        -b  Assume that dependencies are already installed and software sources are set up.
            If git is selected, git tree is still checked out as dependency step.

   Opening the Firewall up for Salt
   The  Salt  master  communicates with the minions using an AES-encrypted
   ZeroMQ connection. These communications are done over  TCP  ports  4505
   and 4506, which need to be accessible on the master only. This document
   outlines  suggested  firewall  rules  for   allowing   these   incoming
   connections to the master.

   NOTE:
      No  firewall  configuration  needs to be done on Salt minions. These
      changes refer to the master only.

   Fedora 18 and beyond / RHEL 7 / CentOS 7
   Starting with  Fedora  18  FirewallD  is  the  tool  that  is  used  to
   dynamically  manage  the  firewall  rules on a host. It has support for
   IPv4/6  settings  and  the  separation   of   runtime   and   permanent
   configurations.  To interact with FirewallD use the command line client
   firewall-cmd.

   firewall-cmd example:

      firewall-cmd --permanent --zone=<zone> --add-port=4505-4506/tcp

   Please choose the desired zone according to your setup. Don't forget to
   reload after you made your changes.

      firewall-cmd --reload

   RHEL 6 / CentOS 6
   The lokkit command packaged with some Linux distributions makes opening
   iptables firewall ports very simple  via  the  command  line.  Just  be
   careful  to not lock out access to the server by neglecting to open the
   ssh port.

   lokkit example:

      lokkit -p 22:tcp -p 4505:tcp -p 4506:tcp

   The system-config-firewall-tui command provides a text-based  interface
   to modifying the firewall.

   system-config-firewall-tui:

      system-config-firewall-tui

   openSUSE
   Salt           installs           firewall           rules           in
   /etc/sysconfig/SuSEfirewall2.d/services/salt.  Enable with:

      SuSEfirewall2 open
      SuSEfirewall2 start

   If you have an older package of Salt where the above configuration file
   is  not  included,  the  SuSEfirewall2  command  makes opening iptables
   firewall ports very simple via the command line.

   SuSEfirewall example:

      SuSEfirewall2 open EXT TCP 4505
      SuSEfirewall2 open EXT TCP 4506

   The firewall  module  in  YaST2  provides  a  text-based  interface  to
   modifying the firewall.

   YaST2:

      yast2 firewall

   iptables
   Different  Linux  distributions  store  their  iptables  (also known as
   netfilter) rules in different  places,  which  makes  it  difficult  to
   standardize  firewall  documentation.  Included  are  some  of the more
   common locations, but your mileage may vary.

   Fedora / RHEL / CentOS:

      /etc/sysconfig/iptables

   Arch Linux:

      /etc/iptables/iptables.rules

   Debian

   Follow these instructions: https://wiki.debian.org/iptables

   Once you've found your firewall rules, you'll need to add the two lines
   below to allow traffic on tcp/4505 and tcp/4506:

      -A INPUT -m state --state new -m tcp -p tcp --dport 4505 -j ACCEPT
      -A INPUT -m state --state new -m tcp -p tcp --dport 4506 -j ACCEPT

   Ubuntu

   Salt   installs  firewall  rules  in  /etc/ufw/applications.d/salt.ufw.
   Enable with:

      ufw allow salt

   pf.conf
   The BSD-family of  operating  systems  uses  packet  filter  (pf).  The
   following  example  describes the additions to pf.conf needed to access
   the Salt master.

      pass in on $int_if proto tcp from any to $int_if port 4505
      pass in on $int_if proto tcp from any to $int_if port 4506

   Once these additions have been made to the pf.conf the rules will  need
   to be reloaded. This can be done using the pfctl command.

      pfctl -vf /etc/pf.conf

   Whitelist communication to Master
   There are situations where you want to selectively allow Minion traffic
   from specific hosts or  networks  into  your  Salt  Master.  The  first
   scenario  which  comes  to  mind is to prevent unwanted traffic to your
   Master out of security concerns, but  another  scenario  is  to  handle
   Minion  upgrades  when there are backwards incompatible changes between
   the installed Salt versions in your environment.

   Here is an example Linux iptables ruleset to be set on the Master:

      # Allow Minions from these networks
      -I INPUT -s 10.1.2.0/24 -p tcp -m multiport --dports 4505,4506 -j ACCEPT
      -I INPUT -s 10.1.3.0/24 -p tcp -m multiport --dports 4505,4506 -j ACCEPT
      # Allow Salt to communicate with Master on the loopback interface
      -A INPUT -i lo -p tcp -m multiport --dports 4505,4506 -j ACCEPT
      # Reject everything else
      -A INPUT -p tcp -m multiport --dports 4505,4506 -j REJECT

   NOTE:
      The important thing to note here is that the salt command  needs  to
      communicate  with the listening network socket of 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.

   Preseed Minion with Accepted Key
   In  some situations, it is not convenient to wait for a minion to start
   before accepting its key on the master. For instance, you may want  the
   minion  to  bootstrap  itself  as soon as it comes online. You may also
   want to to let your developers provision new  development  machines  on
   the fly.

   SEE ALSO:
      Many ways to preseed minion keys

      Salt  has  other  ways  to  generate  and  pre-accept minion keys in
      addition to the manual steps outlined below.

      salt-cloud performs these same steps automatically  when  new  cloud
      VMs are created (unless instructed not to).

      salt-api  exposes  an  HTTP  call to Salt's REST API to generate and
      download the new minion keys as a tarball.

   There is a general four step process to do this:

   1. Generate the keys on the master:

      root@saltmaster# salt-key --gen-keys=[key_name]

   Pick a name for the key, such as the minion's id.

   2. Add the public key to the accepted minion folder:

      root@saltmaster# cp key_name.pub /etc/salt/pki/master/minions/[minion_id]

   It is necessary that the public key file has  the  same  name  as  your
   minion id.  This is how Salt matches minions with their keys. Also note
   that the pki folder could be in a different location, depending on your
   OS or if specified in the master config file.

   3. Distribute the minion keys.

   There  is  no  single  method  to  get the keypair to your minion.  The
   difficulty is finding a distribution method which is secure. For Amazon
   EC2 only, an AWS best practice is to use IAM Roles to pass credentials.
   (See                             blog                             post,
   http://blogs.aws.amazon.com/security/post/Tx610S2MLVZWEA/Using-IAM-roles-to-distribute-non-AWS-credentials-to-your-EC2-instances
   )

      Security Warning

             Since the minion key  is  already  accepted  on  the  master,
             distributing the private key poses a potential security risk.
             A malicious party will have access to your entire state  tree
             and  other  sensitive data if they gain access to a preseeded
             minion key.

   4. Preseed the Minion with the keys

   You will want to place the minion keys before starting the  salt-minion
   daemon:

      /etc/salt/pki/minion/minion.pem
      /etc/salt/pki/minion/minion.pub

   Once  in  place,  you  should  be  able  to  start  salt-minion and run
   salt-call state.apply or any other salt commands  that  require  master
   authentication.

   The MacOS X (Maverick) Developer Step By Step Guide To Salt Installation
   This  document  provides  a  step-by-step  guide  to  installing a Salt
   cluster consisting of  one master, and one minion running on a local VM
   hosted on Mac OS X.

   NOTE:
      This  guide is aimed at developers who wish to run Salt in a virtual
      machine.  The official (Linux) walkthrough can be found here.

   The 5 Cent Salt Intro
   Since you're here you've probably already  heard  about  Salt,  so  you
   already  know  Salt  lets  you  configure and run commands on hordes of
   servers easily.  Here's a brief overview of a Salt cluster:

   * Salt works by having a "master" server sending  commands  to  one  or
     multiple  "minion"  servers  [1].  The  master server is the "command
     center".  It  is  going  to  be  the  place  where  you  store   your
     configuration  files,  aka: "which server is the db, which is the web
     server, and what libraries and software they should have  installed".
     The  minions receive orders from the master.  Minions are the servers
     actually performing work for your business.

   * Salt has two types of configuration files:

     1.  the  "salt  communication  channels"  or  "meta"    or   "config"
     configuration files (not official names): one for the master (usually
     is /etc/salt/master , on the master  server),  and  one  for  minions
     (default  is /etc/salt/minion or /etc/salt/minion.conf, on the minion
     servers). Those files are used to  determine  things  like  the  Salt
     Master IP, port, Salt folder locations, etc.. If these are configured
     incorrectly, your minions will probably be unable to  receive  orders
     from  the  master, or the master will not know which software a given
     minion should install.

     2. the "business" or "service" configuration files (once  again,  not
     an  official name): these are configuration files, ending with ".sls"
     extension, that describe which software should run on  which  server,
     along  with particular configuration properties for the software that
     is being installed. These files should be created  in  the  /srv/salt
     folder  by  default,  but  their  location  can  be changed using ...
     /etc/salt/master configuration file!

   NOTE:
      This tutorial contains a third important configuration file, not  to
      be  confused with the previous two: the virtual machine provisioning
      configuration file. This in itself is not specifically tied to Salt,
      but  it  also contains some Salt configuration. More on that in step
      3. Also note  that  all  configuration  files  are  YAML  files.  So
      indentation matters.

   [1]  Salt  also works with "masterless" configuration where a minion is
        autonomous  (in  which  case  salt  can  be  seen   as   a   local
        configuration  tool),  or  in "multiple master" configuration. See
        the documentation for more on that.

   Before Digging In, The Architecture Of The Salt Cluster
   Salt Master
   The "Salt master" server is going to be the Mac OS  machine,  directly.
   Commands  will  be  run  from  a  terminal app, so Salt will need to be
   installed on the Mac.  This is going to be more convenient  for  toying
   around with configuration files.

   Salt Minion
   We'll  only have one "Salt minion" server. It is going to be running on
   a Virtual Machine running on the Mac, using VirtualBox. It will run  an
   Ubuntu distribution.

   Step 1 - Configuring The Salt Master On Your Mac
   official documentation

   Because  Salt has a lot of dependencies that are not built in Mac OS X,
   we will use Homebrew to install Salt. Homebrew is a package manager for
   Mac,  it's  great,  use  it  (for this tutorial at least!). Some people
   spend a lot of time  installing  libs  by  hand  to  better  understand
   dependencies,  and  then  realize  how useful a package manager is once
   they're configuring a brand new machine and have  to  do  it  all  over
   again. It also lets you uninstall things easily.

   NOTE:
      Brew is a Ruby program (Ruby is installed by default with your Mac).
      Brew downloads, compiles, and links software. The linking  phase  is
      when  compiled software is deployed on your machine. It may conflict
      with manually  installed  software,  especially  in  the  /usr/local
      directory.  It's  ok,  remove  the  manually  installed version then
      refresh the link by typing brew link 'packageName'. Brew has a  brew
      doctor command that can help you troubleshoot. It's a great command,
      use it often. Brew requires xcode command line tools. When  you  run
      brew  the  first  time  it  asks  you to install them if they're not
      already on your system. Brew  installs  software  in  /usr/local/bin
      (system  bins  are in /usr/bin). In order to use those bins you need
      your $PATH to search there first. Brew tells you if your $PATH needs
      to be fixed.

   TIP:
      Use  the keyboard shortcut cmd + shift + period in the "open" Mac OS
      X dialog box to display hidden files and folders, such as .profile.

   Install Homebrew
   Install Homebrew here http://brew.sh/ Or just type

      ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

   Now type the following commands in your terminal (you may want to  type
   brew doctor after each to make sure everything's fine):

      brew install python
      brew install swig
      brew install zmq

   NOTE:
      zmq  is  ZeroMQ.  It's a fantastic library used for server to server
      network communication and is at the core of Salt efficiency.

   Install Salt
   You should now have everything ready to launch this command:

      pip install salt

   NOTE:
      There should be no need for sudo pip install  salt.  Brew  installed
      Python for your user, so you should have all the access. In case you
      would  like  to  check,  type  which  python  to  ensure  that  it's
      /usr/local/bin/python,    and    which    pip    which   should   be
      /usr/local/bin/pip.

   Now type python in a terminal then, import salt.  There  should  be  no
   errors. Now exit the Python terminal using exit().

   Create The Master Configuration
   If  the  default  /etc/salt/master  configuration file was not created,
   copy-paste                it                 from                 here:
   http://docs.saltstack.com/ref/configuration/examples.html#configuration-examples-master

   NOTE:
      /etc/salt/master is a file, not a folder.

   Salt  Master  configuration  changes.  The  Salt  master  needs  a  few
   customization to be able to run on Mac OS X:

      sudo launchctl limit maxfiles 4096 8192

   In  the  /etc/salt/master  file, change max_open_files to 8192 (or just
   add the line: max_open_files: 8192 (no quote)  if  it  doesn't  already
   exists).

   You should now be able to launch the Salt master:

      sudo salt-master --log-level=all

   There should be no errors when running the above command.

   NOTE:
      This  command  is  supposed  to  be a daemon, but for toying around,
      we'll keep it running on a terminal to monitor the activity.

   Now that the master is set, let's configure a minion on a VM.

   The Salt minion is going to run on a Virtual Machine. There are  a  lot
   of software options that let you run virtual machines on a mac, But for
   this tutorial we're going to use VirtualBox. In addition to virtualBox,
   we   will  use  Vagrant,  which  allows  you  to  create  the  base  VM
   configuration.

   Vagrant lets you build ready to use VM  images,  starting  from  an  OS
   image  and  customizing it using "provisioners". In our case, we'll use
   it to:

   * Download the base Ubuntu image

   * Install  salt  on  that  Ubuntu  image  (Salt  is  going  to  be  the
     "provisioner" for the VM).

   * Launch the VM

   * SSH into the VM to debug

   * Stop the VM once you're done.

   Install VirtualBox
   Go  get  it  here:  https://www.virtualBox.org/wiki/Downloads (click on
   VirtualBox for OS X hosts => x86/amd64)

   Install Vagrant
   Go get it here: http://downloads.vagrantup.com/ and choose  the  latest
   version (1.3.5 at time of writing), then the .dmg file. Double-click to
   install it.  Make sure the vagrant command is found  when  run  in  the
   terminal. Type vagrant. It should display a list of commands.

   Create The Minion VM Folder
   Create  a  folder  in  which  you  will store your minion's VM. In this
   tutorial, it's going to be a minion folder in the $home directory.

      cd $home
      mkdir minion

   Initialize Vagrant
   From the minion folder, type

      vagrant init

   This command creates a default  Vagrantfile  configuration  file.  This
   configuration file will be used to pass configuration parameters to the
   Salt provisioner in Step 3.

   Import Precise64 Ubuntu Box
      vagrant box add precise64 http://files.vagrantup.com/precise64.box

   NOTE:
      This box is added at the global Vagrant level. You only need  to  do
      it once as each VM will use this same file.

   Modify the Vagrantfile
   Modify  ./minion/Vagrantfile  to  use  th  precise64  box.  Change  the
   config.vm.box line to:

      config.vm.box = "precise64"

   Uncomment the line creating a host-only IP. This  is  the  ip  of  your
   minion  (you  can  change it to something else if that IP is already in
   use):

      config.vm.network :private_network, ip: "192.168.33.10"

   At this point you should have a VM that can run, although  there  won't
   be much in it. Let's check that.

   Checking The VM
   From the $home/minion folder type:

      vagrant up

   A  log  showing the VM booting should be present. Once it's done you'll
   be back to the terminal:

      ping 192.168.33.10

   The VM should respond to your ping request.

   Now log into the VM in ssh using Vagrant again:

      vagrant ssh

   You should  see  the  shell  prompt  change  to  something  similar  to
   vagrant@precise64:~$  meaning  you're  inside the VM. From there, enter
   the following:

      ping 10.0.2.2

   NOTE:
      That ip is the ip of your VM host (the Mac OS X OS). The number is a
      VirtualBox default and is displayed in the log after the Vagrant ssh
      command. We'll use that IP to tell the minion where the Salt  master
      is.  Once you're done, end the ssh session by typing exit.

   It's now time to connect the VM to the salt master

   Creating The Minion Configuration File
   Create  the  /etc/salt/minion  file.  In  that  file, put the following
   lines, giving the ID for this minion, and the IP of the master:

      master: 10.0.2.2
      id: 'minion1'
      file_client: remote

   Minions authenticate with the master using  keys.  Keys  are  generated
   automatically  if  you  don't provide one and can accept them later on.
   However, this requires accepting the minion key every time  the  minion
   is  destroyed  or created (which could be quite often). A better way is
   to create those keys in advance, feed them to the minion, and authorize
   them once.

   Preseed minion keys
   From the minion folder on your Mac run:

      sudo salt-key --gen-keys=minion1

   This  should  create  two  files:  minion1.pem, and minion1.pub.  Since
   those files have been created using sudo, but will be used by  vagrant,
   you need to change ownership:

      sudo chown youruser:yourgroup minion1.pem
      sudo chown youruser:yourgroup minion1.pub

   Then copy the .pub file into the list of accepted minions:

      sudo cp minion1.pub /etc/salt/pki/master/minions/minion1

   Modify Vagrantfile to Use Salt Provisioner
   Let's now modify the Vagrantfile used to provision the Salt VM. Add the
   following section in the Vagrantfile (note: it should be  at  the  same
   indentation level as the other properties):

      # salt-vagrant config
      config.vm.provision :salt do |salt|
          salt.run_highstate = true
          salt.minion_config = "/etc/salt/minion"
          salt.minion_key = "./minion1.pem"
          salt.minion_pub = "./minion1.pub"
      end

   Now destroy the vm and recreate it from the /minion folder:

      vagrant destroy
      vagrant up

   If everything is fine you should see the following message:

      "Bootstrapping Salt... (this may take a while)
      Salt successfully configured and installed!"

   Checking Master-Minion Communication
   To make sure the master and minion are talking to each other, enter the
   following:

      sudo salt '*' test.ping

   You should see your minion answering the ping. It's now time to do some
   configuration.

   In  this  step  we'll  use  the  Salt  master to instruct our minion to
   install Nginx.

   Checking the system's original state
   First, make sure that an HTTP server is not installed  on  our  minion.
   When opening a browser directed at http://192.168.33.10/ You should get
   an error saying the site cannot be reached.

   Initialize the top.sls file
   System   configuration    is    done    in    /srv/salt/top.sls    (and
   subfiles/folders), and then applied by running the state.apply function
   to have the Salt master order its minions to update their  instructions
   and run the associated commands.

   First Create an empty file on your Salt master (Mac OS X machine):

      touch /srv/salt/top.sls

   When  the file is empty, or if no configuration is found for our minion
   an error is reported:

      sudo salt 'minion1' state.apply

   This should return an error stating: No Top file or external nodes data
   matches found.

   Create The Nginx Configuration
   Now  is  finally  the  time  to  enter  the  real  meat of our server's
   configuration.  For this tutorial our minion will be treated as  a  web
   server that needs to have Nginx installed.

   Insert the following lines into /srv/salt/top.sls (which should current
   be empty).

      base:
        'minion1':
          - bin.nginx

   Now create /srv/salt/bin/nginx.sls containing the following:

      nginx:
        pkg.installed:
          - name: nginx
        service.running:
          - enable: True
          - reload: True

   Check Minion State
   Finally, run the state.apply function again:

      sudo salt 'minion1' state.apply

   You should see a log showing that the Nginx package has been  installed
   and the service configured. To prove it, open your browser and navigate
   to http://192.168.33.10/, you should see  the  standard  Nginx  welcome
   page.

   Congratulations!

   Where To Go From Here
   A  full  description of configuration management within Salt (sls files
   among       other       things)        is        available        here:
   http://docs.saltstack.com/en/latest/index.html#configuration-management

   running salt as normal user tutorial
   Before  continuing  make  sure  you have a working Salt installation by
   following the installation and the configuration instructions.

      Stuck?

             There are many ways to  get  help  from  the  Salt  community
             including our mailing list and our IRC channel #salt.

   Running Salt functions as non root user
   If  you don't want to run salt cloud as root or even install it you can
   configure it to have a virtual root in your working directory.

   The salt system uses the salt.syspath module to find the variables

   If you run the salt-build, it will generated in:

      ./build/lib.linux-x86_64-2.7/salt/_syspaths.py

   To generate it, run the command:

      python setup.py build

   Copy the generated module into your salt directory

      cp ./build/lib.linux-x86_64-2.7/salt/_syspaths.py salt/_syspaths.py

   Edit it to include needed variables and your new paths

      # you need to edit this
      ROOT_DIR = *your current dir* + '/salt/root'

      # you need to edit this
      INSTALL_DIR = *location of source code*

      CONFIG_DIR =  ROOT_DIR + '/etc/salt'
      CACHE_DIR = ROOT_DIR + '/var/cache/salt'
      SOCK_DIR = ROOT_DIR + '/var/run/salt'
      SRV_ROOT_DIR= ROOT_DIR + '/srv'
      BASE_FILE_ROOTS_DIR = ROOT_DIR + '/srv/salt'
      BASE_PILLAR_ROOTS_DIR = ROOT_DIR + '/srv/pillar'
      BASE_MASTER_ROOTS_DIR = ROOT_DIR + '/srv/salt-master'
      LOGS_DIR = ROOT_DIR + '/var/log/salt'
      PIDFILE_DIR = ROOT_DIR + '/var/run'
      CLOUD_DIR = INSTALL_DIR + '/cloud'
      BOOTSTRAP = CLOUD_DIR + '/deploy/bootstrap-salt.sh'

   Create the directory structure

      mkdir -p root/etc/salt root/var/cache/run root/run/salt root/srv
      root/srv/salt root/srv/pillar root/srv/salt-master root/var/log/salt root/var/run

   Populate the configuration files:

      cp -r conf/* root/etc/salt/

   Edit  your  root/etc/salt/master  configuration   that   is   used   by
   salt-cloud:

      user: *your user name*

   Run like this:

      PYTHONPATH=`pwd` scripts/salt-cloud

   Standalone Minion
   Since  the  Salt minion contains such extensive functionality it can be
   useful to run it standalone. A standalone minion can be used  to  do  a
   number of things:

   * Use salt-call commands on a system without connectivity to a master

   * Masterless States, run states entirely from files local to the minion

   NOTE:
      When  running  Salt  in  masterless mode, do not run the salt-minion
      daemon.  Otherwise, it will attempt to connect to a master and fail.
      The  salt-call  command  stands  on  its  own  and does not need the
      salt-minion daemon.

   Minion Configuration
   Throughout this  document  there  are  several  references  to  setting
   different  options  to  configure a masterless Minion. Salt Minions are
   easy to configure via a configuration file that is located, by default,
   in  /etc/salt/minion.   Note,  however,  that  on  FreeBSD systems, the
   minion configuration file is located in /usr/local/etc/salt/minion.

   You  can  learn  more  about  minion  configuration  options   in   the
   Configuring the Salt Minion docs.

   Telling Salt Call to Run Masterless
   The  salt-call  command  is  used  to run module functions locally on a
   minion  instead  of  executing  them  from  the  master.  Normally  the
   salt-call  command  checks  into the master to retrieve file server and
   pillar  data,  but  when  running  standalone  salt-call  needs  to  be
   instructed  to  not  check  the  master  for this data. To instruct the
   minion to not look for a master when running salt-call the  file_client
   configuration  option  needs  to be set.  By default the file_client is
   set to remote so that the minion knows that file server and pillar data
   are to be gathered from the master. When setting the file_client option
   to local the minion is configured to not  gather  this  data  from  the
   master.

      file_client: local

   Now  the  salt-call  command will not look for a master and will assume
   that the local system has all of the file and pillar resources.

   Running States Masterless
   The state system can be easily run without  a  Salt  master,  with  all
   needed  files  local to the minion. To do this the minion configuration
   file needs to be set up to know how to  return  file_roots  information
   like  the  master. The file_roots setting defaults to /srv/salt for the
   base environment just like on the master:

      file_roots:
        base:
          - /srv/salt

   Now set up the Salt State Tree, top file, and SLS modules in  the  same
   way  that  they  would be set up on a master. Now, with the file_client
   option set to local and an available state tree then calls to functions
   in  the  state module will use the information in the file_roots on the
   minion instead of checking in with the master.

   Remember that when creating a state tree  on  a  minion  there  are  no
   syntax  or  path  changes needed, SLS modules written to be used from a
   master do not need to be modified in any way to work with a minion.

   This makes it easy to "script" deployments  with  Salt  states  without
   having  to  set  up  a  master,  and allows for these SLS modules to be
   easily moved into a Salt master as the deployment grows.

   The declared state can now be executed with:

      salt-call state.apply

   Or the salt-call command can be executed with the  --local  flag,  this
   makes it unnecessary to change the configuration file:

      salt-call state.apply --local

   External Pillars
   External pillars are supported when running in masterless mode.

   Salt Masterless Quickstart
   Running  a  masterless  salt-minion  lets  you use Salt's configuration
   management for a single machine without calling out to a Salt master on
   another machine.

   Since  the  Salt minion contains such extensive functionality it can be
   useful to run it standalone. A standalone minion can be used  to  do  a
   number of things:

   * Stand up a master server via States (Salting a Salt Master)

   * Use salt-call commands on a system without connectivity to a master

   * Masterless States, run states entirely from files local to the minion

   It  is  also  useful  for testing out state trees before deploying to a
   production setup.

   Bootstrap Salt Minion
   The salt-bootstrap script makes bootstrapping a server with Salt simple
   for any OS with a Bourne shell:

      curl -L https://bootstrap.saltstack.com -o bootstrap_salt.sh
      sudo sh bootstrap_salt.sh

   See  the  salt-bootstrap documentation for other one liners. When using
   Vagrant to test out salt, the Vagrant salt provisioner  will  provision
   the VM for you.

   Telling Salt to Run Masterless
   To  instruct  the  minion  to  not  look  for a master, the file_client
   configuration option needs to be set in the minion configuration  file.
   By  default the file_client is set to remote so that the minion gathers
   file server and pillar data from the salt  master.   When  setting  the
   file_client option to local the minion is configured to not gather this
   data from the master.

      file_client: local

   Now the salt minion will not look for a master and will assume that the
   local system has all of the file and pillar resources.

   Configuration   which   resided   in  the  master  configuration  (e.g.
   /etc/salt/master) should be moved to the minion configuration since the
   minion does not read the master configuration.

   NOTE:
      When  running  Salt  in  masterless mode, do not run the salt-minion
      daemon.  Otherwise, it will attempt to connect to a master and fail.
      The  salt-call  command  stands  on  its  own  and does not need the
      salt-minion daemon.

   Create State Tree
   Following the successful installation of a salt-minion, the  next  step
   is  to  create a state tree, which is where the SLS files that comprise
   the possible states of the minion are stored.

   The following example walks through the steps  necessary  to  create  a
   state  tree  that  ensures  that  the  server  has the Apache webserver
   installed.

   NOTE:
      For a complete explanation on Salt States, see the tutorial.

   1. Create the top.sls file:

   /srv/salt/top.sls:

      base:
        '*':
          - webserver

   2. Create the webserver state tree:

   /srv/salt/webserver.sls:

      apache:               # ID declaration
        pkg:                # state declaration
          - installed       # function declaration

   NOTE:
      The apache package has different names on different  platforms,  for
      instance  on Debian/Ubuntu it is apache2, on Fedora/RHEL it is httpd
      and on Arch it is apache

   The only thing left is to provision our minion using salt-call.

   Salt-call
   The salt-call command is used to run remote execution functions locally
   on  a  minion  instead  of executing them from the master. Normally the
   salt-call command checks into the master to retrieve  file  server  and
   pillar  data,  but  when  running  standalone  salt-call  needs  to  be
   instructed to not check the master for this data:

      salt-call --local state.apply

   The --local flag tells the salt-minion to look for the  state  tree  in
   the   local   file  system  and  not  to  contact  a  Salt  Master  for
   instructions.

   To provide verbose output, use -l debug:

      salt-call --local state.apply -l debug

   The minion first examines the top.sls file and determines that it is  a
   part  of  the group matched by * glob and that the webserver SLS should
   be applied.

   It then examines the webserver.sls file and  finds  the  apache  state,
   which installs the Apache package.

   The  minion  should  now have Apache installed, and the next step is to
   begin learning how to write more complex states.

   Dependencies
   Salt should run on any Unix-like platform so long as  the  dependencies
   are met.

   * Python 2.6 >= 2.6 <3.0

   * msgpack-python - High-performance message interchange format

   * YAML - Python YAML bindings

   * Jinja2 - parsing Salt States (configurable in the master settings)

   * MarkupSafe  -  Implements  a  XML/HTML/XHTML  Markup  safe string for
     Python

   * apache-libcloud - Python lib for interacting with many of the popular
     cloud service providers using a unified API

   * Requests - HTTP library

   * Tornado - Web framework and asynchronous networking library

   * futures - Backport of the concurrent.futures package from Python 3.2

   Depending  on  the  chosen Salt transport, ZeroMQ or RAET, dependencies
   vary:

   * ZeroMQ:

     * ZeroMQ >= 3.2.0

     * pyzmq >= 2.2.0 - ZeroMQ Python bindings

     * PyCrypto - The Python cryptography toolkit

   * RAET:

     * libnacl - Python bindings to libsodium

     * ioflo - The flo programming interface raet and salt-raet  is  built
       on

     * RAET - The worlds most awesome UDP protocol

   Salt  defaults  to  the ZeroMQ transport, and the choice can be made at
   install time, for example:

      python setup.py --salt-transport=raet install

   This way, only the required dependencies are pulled by the setup script
   if need be.

   If  installing  using  pip,  the --salt-transport install option can be
   provided like:

      pip install --install-option="--salt-transport=raet" salt

   NOTE:
      Salt does not bundle dependencies that are typically distributed  as
      part  of the base OS. If you have unmet dependencies and are using a
      custom or minimal installation,  you  might  need  to  install  some
      additional packages from your OS vendor.

   Optional Dependencies
   * mako - an optional parser for Salt States (configurable in the master
     settings)

   * gcc - dynamic Cython module compiling

   Upgrading Salt
   When upgrading Salt, the master(s) should  always  be  upgraded  first.
   Backward  compatibility for minions running newer versions of salt than
   their masters is not guaranteed.

   Whenever possible, backward compatibility between new masters  and  old
   minions  will  be  preserved.   Generally,  the  only exception to this
   policy is in case of a security vulnerability.

   SEE ALSO:
      Installing Salt for development and contributing to the project.

   Building Packages using Salt Pack
   Salt-pack is an open-source package  builder  for  most  commonly  used
   Linux platforms, for example: Redhat/CentOS and Debian/Ubuntu families,
   utilizing SaltStack states and execution modules to build  Salt  and  a
   specified   set   of  dependencies,  from  which  a  platform  specific
   repository can be built.

   https://github.com/saltstack/salt-pack

CONFIGURING SALT

   This section explains how to configure user access, view and store  job
   results,  secure  and  troubleshoot,  and  how  to  perform  many other
   administrative tasks.

   Configuring the Salt Master
   The Salt system is amazingly simple and  easy  to  configure,  the  two
   components  of  the  Salt  system  each have a respective configuration
   file. The salt-master is configured via the master configuration  file,
   and the salt-minion is configured via the minion configuration file.

   SEE ALSO:
      Example master configuration file.

   The   configuration   file   for   the   salt-master   is   located  at
   /etc/salt/master by default.  A notable exception is FreeBSD, where the
   configuration  file  is  located at /usr/local/etc/salt.  The available
   options are as follows:

   Primary Master Configuration
   interface
   Default: 0.0.0.0 (all interfaces)

   The local interface to bind to.

      interface: 192.168.0.1

   ipv6
   Default: False

   Whether the master should listen for IPv6 connections. If this  is  set
   to  True,  the  interface  option  must  be  adjusted too (for example:
   interface: '::')

      ipv6: True

   publish_port
   Default: 4505

   The network port to set up the publication interface.

      publish_port: 4505

   master_id
   Default: None

   The id to be passed in the publish job to minions.  This  is  used  for
   MultiSyndics to return the job to the requesting master.

   NOTE:
      This must be the same string as the syndic is configured with.

      master_id: MasterOfMaster

   user
   Default: root

   The user to run the Salt processes

      user: root

   max_open_files
   Default: 100000

   Each minion connecting to the master uses AT LEAST one file descriptor,
   the master subscription connection. If enough minions connect you might
   start seeing on the console(and then salt-master crashes):

      Too many open files (tcp_listener.cpp:335)
      Aborted (core dumped)

      max_open_files: 100000

   By  default  this  value  will be the one of ulimit -Hn, i.e., the hard
   limit for max open files.

   To set a different value than the default one, uncomment, and configure
   this  setting.  Remember that this value CANNOT be higher than the hard
   limit. Raising the hard limit depends on the OS and/or distribution,  a
   good way to find the limit is to search the internet for something like
   this:

      raise max open files hard limit debian

   worker_threads
   Default: 5

   The number of threads to start for receiving commands and replies  from
   minions.   If  minions  are  stalling  on replies because you have many
   minions, raise the worker_threads value.

   Worker threads should not be put below 3 when using  the  peer  system,
   but can drop down to 1 worker otherwise.

   NOTE:
      When  the  master  daemon  starts,  it  is expected behaviour to see
      multiple salt-master processes, even if 'worker_threads' is  set  to
      '1'.  At  a  minimum,  a controlling process will start along with a
      Publisher, an EventPublisher, and a number of MWorker processes will
      be  started.  The  number  of  MWorker  processes is tuneable by the
      'worker_threads' configuration value while the others are not.

      worker_threads: 5

   ret_port
   Default: 4506

   The port used by the return server, this is the server used by Salt  to
   receive execution returns and command executions.

      ret_port: 4506

   pidfile
   Default: /var/run/salt-master.pid

   Specify the location of the master pidfile.

      pidfile: /var/run/salt-master.pid

   root_dir
   Default: /

   The system root directory to operate from, change this to make Salt run
   from an alternative root.

      root_dir: /

   NOTE:
      This directory is  prepended  to  the  following  options:  pki_dir,
      cachedir,   sock_dir,   log_file,   autosign_file,  autoreject_file,
      pidfile.

   conf_file
   Default: /etc/salt/master

   The path to the master's configuration file.

      conf_file: /etc/salt/master

   pki_dir
   Default: /etc/salt/pki/master

   The directory to store the pki authentication keys.

      pki_dir: /etc/salt/pki/master

   extension_modules
   Changed in version 2016.3.0: The default location  for  this  directory
   has  been  moved.  Prior  to this version, the location was a directory
   named   extmods   in   the   Salt   cachedir   (on   most    platforms,
   /var/cache/salt/extmods).  It  has  been moved into the master cachedir
   (on most platforms, /var/cache/salt/master/extmods).

   Directory for custom modules. This directory can contain subdirectories
   for  each  of  Salt's  module  types  such  as  runners, output, wheel,
   modules, states, returners, engines, etc.  This  path  is  appended  to
   root_dir.

      extension_modules: /root/salt_extmods

   module_dirs
   Default: []

   Like  extension_modules,  but a list of extra directories to search for
   Salt modules.

      module_dirs:
        - /var/cache/salt/minion/extmods

   cachedir
   Default: /var/cache/salt/master

   The location used to store  cache  information,  particularly  the  job
   information for executed salt commands.

   This  directory  may  contain  sensitive  data  and should be protected
   accordingly.

      cachedir: /var/cache/salt/master

   verify_env
   Default: True

   Verify and set permissions on configuration directories at startup.

      verify_env: True

   keep_jobs
   Default: 24

   Set the number of hours to keep old job information. Note that  setting
   this option to 0 disables the cache cleaner.

      keep_jobs: 24

   gather_job_timeout
   New in version 2014.7.0.

   Default: 10

   The number of seconds to wait when the client is requesting information
   about running jobs.

      gather_job_timeout: 10

   timeout
   Default: 5

   Set the default timeout for the salt command and api.

   loop_interval
   Default: 60

   The  loop_interval  option  controls  the  seconds  for  the   master's
   maintenance  process  check  cycle.  This  process  updates file server
   backends, cleans the job cache and executes the scheduler.

   output
   Default: nested

   Set the default outputter used by the salt command.

   output_file
   Default: None

   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.

      output_file: /path/output/file

   color
   Default: True

   By  default  output is colored, to disable colored output set the color
   value to False.

      color: False

   cli_summary
   Default: False

   When set to True, displays a summary of the number of minions targeted,
   the  number of minions returned, and the number of minions that did not
   return.

      cli_summary: False

   sock_dir
   Default: /var/run/salt/master

   Set the location to use for creating Unix sockets  for  master  process
   communication.

      sock_dir: /var/run/salt/master

   enable_gpu_grains
   Default: True

   Enable  GPU hardware data for your master. Be aware that the master can
   take a while to start  up  when  lspci  and/or  dmidecode  is  used  to
   populate the grains for the master.

   job_cache
   Default: True

   The  master  maintains  a  temporary  job  cache. While this is a great
   addition, it can be a burden on the master for larger deployments (over
   5000  minions).   Disabling the job cache will make previously executed
   jobs unavailable to the jobs system and is not  generally  recommended.
   Normally  it  is wise to make sure the master has access to a faster IO
   system or a tmpfs is mounted to the jobs dir.

      job_cache: True

   NOTE:
      Setting the job_cache to False will not cache  minion  returns,  but
      the JID directory for each job is still created. The creation of the
      JID directories is necessary because Salt uses those directories  to
      check  for  JID collisions. By setting this option to False, the job
      cache directory, which is /var/cache/salt/master/jobs/  by  default,
      will be smaller, but the JID directories will still be present.

      Note  that the keep_jobs option can be set to a lower value, such as
      1, to limit the number of hours jobs are stored in  the  job  cache.
      (The default is 24 hours.)

      Please  see  the  Managing  the  Job  Cache  documentation  for more
      information.

   minion_data_cache
   Default: True

   The minion data cache is a  cache  of  information  about  the  minions
   stored  on  the  master,  this  information is primarily the pillar and
   grains data. The data is cached in the Master cachedir under  the  name
   of  the  minion  and  used to predetermine what minions are expected to
   reply from executions.

      minion_data_cache: True

   ext_job_cache
   Default: ''

   Used to specify a default returner for all minions. When this option is
   set,  the  specified  returner  needs to be properly configured and the
   minions will always default to sending returns to this  returner.  This
   will also disable the local job cache on the master.

      ext_job_cache: redis

   event_return
   New in version 2015.5.0.

   Default: ''

   Specify  the  returner(s)  to use to log events. Each returner may have
   installation  and  configuration  requirements.  Read  the   returner's
   documentation.

   NOTE:
      Not  all returners support event returns. Verify that a returner has
      an event_return() function before configuring  this  option  with  a
      returner.

      event_return:
        - syslog
        - splunk

   event_return_queue
   New in version 2015.5.0.

   Default: 0

   On  busy  systems, enabling event_returns can cause a considerable load
   on the storage system for returners. Events can be queued on the master
   and stored in a batched fashion using a single transaction for multiple
   events.  By default, events are not queued.

      event_return_queue: 0

   event_return_whitelist
   New in version 2015.5.0.

   Default: []

   Only return events matching tags in a whitelist.

   Changed in version 2016.11.0: Supports glob matching patterns.

      event_return_whitelist:
        - salt/master/a_tag
        - salt/run/*/ret

   event_return_blacklist
   New in version 2015.5.0.

   Default: []

   Store all event returns _except_ the tags in a blacklist.

   Changed in version 2016.11.0: Supports glob matching patterns.

      event_return_blacklist:
        - salt/master/not_this_tag
        - salt/wheel/*/ret

   max_event_size
   New in version 2014.7.0.

   Default: 1048576

   Passing very large events can cause the minion to consume large amounts
   of  memory. This value tunes the maximum size of a message allowed onto
   the master event bus. The value is expressed in bytes.

      max_event_size: 1048576

   master_job_cache
   New in version 2014.7.0.

   Default: local_cache

   Specify the returner to use for the job cache. The job cache will  only
   be  interacted with from the salt master and therefore does not need to
   be accessible from the minions.

      master_job_cache: redis

   enforce_mine_cache
   Default: False

   By-default when disabling the minion_data_cache mine will stop  working
   since it is based on cached data, by enabling this option we explicitly
   enabling only the cache for the mine system.

      enforce_mine_cache: False

   max_minions
   Default: 0

   The maximum number of minion connections allowed  by  the  master.  Use
   this  to  accommodate  the  number  of  minions  per master if you have
   different types of hardware serving your  minions.  The  default  of  0
   means  unlimited  connections.  Please note that this can slow down the
   authentication process a bit in large setups.

      max_minions: 100

   con_cache
   Default: False

   If max_minions  is  used  in  large  installations,  the  master  might
   experience  high-load  situations because of having to check the number
   of connected minions for every authentication. This cache provides  the
   minion-ids  of  all  connected  minions  to  all  MWorker-processes and
   greatly improves the performance of max_minions.

      con_cache: True

   presence_events
   Default: False

   Causes the master to periodically look for actively connected  minions.
   Presence events are fired on the event bus on a regular interval with a
   list of connected minions, as  well  as  events  with  lists  of  newly
   connected or disconnected minions. This is a master-only operation that
   does not send executions to minions. Note, this does not detect minions
   that connect to a master via localhost.

      presence_events: False

   transport
   Default: zeromq

   Changes  the  underlying  transport  layer.  ZeroMQ  is the recommended
   transport while additional  transport  layers  are  under  development.
   Supported   values   are   zeromq,   raet   (experimental),   and   tcp
   (experimental). This setting has a significant  impact  on  performance
   and  should  not  be  changed  unless  you  know  what  you  are doing!
   Transports are explained in Salt Transports.

      transport: zeromq

   transport_opts
   Default: {}

   (experimental) Starts multiple transports  and  overrides  options  for
   each  transport  with  the  provided  dictionary  This  setting  has  a
   significant impact on performance and should not be changed unless  you
   know  what  you are doing! Transports are explained in Salt Transports.
   The following example shows how to start a TCP  transport  alongside  a
   ZMQ transport.

      transport_opts:
        tcp:
          publish_port: 4605
          ret_port: 4606
        zeromq: []

   Salt-SSH Configuration
   roster_file
   Default: /etc/salt/roster

   Pass in an alternative location for the salt-ssh roster file.

      roster_file: /root/roster

   ssh_log_file
   New in version 2016.3.5.

   Default: /var/log/salt/ssh

   Specify the log file of the salt-ssh command.

      ssh_log_file: /var/log/salt/ssh

   ssh_minion_opts
   Default: None

   Pass in minion option overrides that will be inserted into the SHIM for
   salt-ssh calls. The local minion config is not used for  salt-ssh.  Can
   be overridden on a per-minion basis in the roster (minion_opts)

      ssh_minion_opts:
        gpg_keydir: /root/gpg

   ssh_use_home_key
   Default: False

   Set  this  to  True  to  default  to  using  ~/.ssh/id_rsa for salt-ssh
   authentication with minions

      ssh_use_home_key: False

   thin_extra_mods
   Default: None

   List of additional modules, needed to be included into the  Salt  Thin.
   Pass  a list of importable Python modules that are typically located in
   the site-packages Python directory so they will be also always included
   into the Salt Thin, once generated.

   Master Security Settings
   open_mode
   Default: False

   Open mode is a dangerous security feature. One problem encountered with
   pki authentication systems is that  keys  can  become  "mixed  up"  and
   authentication  begins  to fail. Open mode turns off authentication and
   tells the master to accept all authentication. This will clean  up  the
   pki  keys  received from the minions. Open mode should not be turned on
   for general use. Open mode should only be used for a  short  period  of
   time to clean up pki keys. To turn on open mode set this value to True.

      open_mode: False

   auto_accept
   Default: False

   Enable auto_accept. This setting will automatically accept all incoming
   public keys from minions.

      auto_accept: False

   autosign_timeout
   New in version 2014.7.0.

   Default: 120

   Time in minutes that a incoming public key with a matching  name  found
   in  pki_dir/minion_autosign/keyid  is  automatically  accepted. Expired
   autosign keys are removed when the master  checks  the  minion_autosign
   directory.  This  method  to  auto  accept minions can be safer than an
   autosign_file because the keyid record can expire  and  is  limited  to
   being an exact name match.  This should still be considered a less than
   secure option, due to  the  fact  that  trust  is  based  on  just  the
   requesting minion id.

   autosign_file
   Default: not defined

   If  the  autosign_file  is  specified  incoming  keys  specified in the
   autosign_file will be automatically accepted. Matches will be  searched
   for  first  by string comparison, then by globbing, then by full-string
   regex matching.  This should still be considered  a  less  than  secure
   option,  due  to  the  fact  that trust is based on just the requesting
   minion id.

   autoreject_file
   New in version 2014.1.0.

   Default: not defined

   Works like autosign_file, but instead allows you to specify minion  IDs
   for  which  keys  will  automatically  be  rejected. Will override both
   membership in the autosign_file and the auto_accept setting.

   publisher_acl
   Default: {}

   Enable user accounts on the master to execute specific  modules.  These
   modules  can  be expressed as regular expressions. Note that client_acl
   option is deprecated by publisher_acl option and  will  be  removed  in
   future releases.

      publisher_acl:
        fred:
          - test.ping
          - pkg.*

   publisher_acl_blacklist
   Default: {}

   Blacklist users or modules

   This  example  would  blacklist all non sudo users, including root from
   running any commands. It would also blacklist  any  use  of  the  "cmd"
   module.   Note   that  client_acl_blacklist  option  is  deprecated  by
   publisher_acl_blacklist option and will be removed in future releases.

   This is completely disabled by default.

      publisher_acl_blacklist:
        users:
          - root
          - '^(?!sudo_).*$'   #  all non sudo users
        modules:
          - cmd

   external_auth
   Default: {}

   The external auth system uses the Salt auth modules to authenticate and
   validate users to access areas of the Salt system.

      external_auth:
        pam:
          fred:
            - test.*

   token_expire
   Default: 43200

   Time (in seconds) for a newly generated token to live.

   Default: 12 hours

      token_expire: 43200

   token_expire_user_override
   Default: False

   Allow  eauth  users  to  specify  the  expiry  time  of the tokens they
   generate.

   A boolean applies to all users or a  dictionary  of  whitelisted  eauth
   backends and usernames may be given:

      token_expire_user_override:
        pam:
          - fred
          - tom
        ldap:
          - gary

   file_recv
   Default: False

   Allow minions to push files to the master. This is disabled by default,
   for security purposes.

      file_recv: False

   file_recv_max_size
   New in version 2014.7.0.

   Default: 100

   Set a hard-limit on the size of the files that can  be  pushed  to  the
   master.  It will be interpreted as megabytes.

      file_recv_max_size: 100

   master_sign_pubkey
   Default: False

   Sign  the  master  auth-replies  with  a cryptographic signature of the
   master's public key. Please see the tutorial how to use these  settings
   in the Multimaster-PKI with Failover Tutorial

      master_sign_pubkey: True

   master_sign_key_name
   Default: master_sign

   The customizable name of the signing-key-pair without suffix.

      master_sign_key_name: <filename_without_suffix>

   master_pubkey_signature
   Default: master_pubkey_signature

   The  name  of  the  file  in  the master's pki-directory that holds the
   pre-calculated signature of the master's public-key.

      master_pubkey_signature: <filename>

   master_use_pubkey_signature
   Default: False

   Instead  of  computing  the  signature  for  each  auth-reply,  use   a
   pre-calculated  signature. The master_pubkey_signature must also be set
   for this.

      master_use_pubkey_signature: True

   rotate_aes_key
   Default: True

   Rotate the salt-masters AES-key when a minion-public  is  deleted  with
   salt-key.  This is a very important security-setting. Disabling it will
   enable deleted minions to still listen in on the messages published  by
   the  salt-master.   Do  not  disable this unless it is absolutely clear
   what this does.

      rotate_aes_key: True

   ssl
   New in version 2016.11.0.

   Default: None

   TLS/SSL  connection  options.  This  could  be  set  to  a   dictionary
   containing  arguments  corresponding  to python ssl.wrap_socket method.
   For details see Tornado and Python documentation.

   Note: to set enum arguments values like cert_reqs and  ssl_version  use
   constant   names   without   ssl   module   prefix:   CERT_REQUIRED  or
   PROTOCOL_SSLv23.

      ssl:
          keyfile: <path_to_keyfile>
          certfile: <path_to_certfile>
          ssl_version: PROTOCOL_TLSv1_2

   Master Module Management
   runner_dirs
   Default: []

   Set additional directories to search for runner modules.

      runner_dirs:
        - /var/lib/salt/runners

   cython_enable
   Default: False

   Set to true to enable Cython modules (.pyx files) to be compiled on the
   fly on the Salt master.

      cython_enable: False

   Master State System Settings
   state_top
   Default: top.sls

   The state system uses a "top" file to tell the minions what environment
   to use and what modules to use. The state_top file is defined  relative
   to the root of the base environment.

      state_top: top.sls

   master_tops
   Default: {}

   The master_tops option replaces the external_nodes option by creating a
   pluggable  system  for  the  generation  of  external  top  data.   The
   external_nodes option is deprecated by the master_tops option.  To gain
   the  capabilities  of  the  classic  external_nodes  system,  use   the
   following configuration:

      master_tops:
        ext_nodes: <Shell command which returns yaml>

   external_nodes
   Default: None

   The  external_nodes  option  allows  Salt  to  gather  data  that would
   normally be placed in a top file from and external node controller. The
   external_nodes  option is the executable that will return the ENC data.
   Remember that Salt will look for  external  nodes  AND  top  files  and
   combine the results if both are enabled and available!

      external_nodes: cobbler-ext-nodes

   renderer
   Default: yaml_jinja

   The renderer to use on the minions to render the state data.

      renderer: yaml_jinja

   jinja_trim_blocks
   New in version 2014.1.0.

   Default: False

   If  this  is  set  to  True,  the  first newline after a Jinja block is
   removed (block, not variable tag!). Defaults to False  and  corresponds
   to the Jinja environment init variable trim_blocks.

      jinja_trim_blocks: False

   jinja_lstrip_blocks
   New in version 2014.1.0.

   Default: False

   If  this  is set to True, leading spaces and tabs are stripped from the
   start of a line to a block. Defaults to False and  corresponds  to  the
   Jinja environment init variable lstrip_blocks.

      jinja_lstrip_blocks: False

   failhard
   Default: False

   Set  the  global failhard flag. This informs all states to stop running
   states at the moment a single state fails.

      failhard: False

   state_verbose
   Default: True

   Controls the verbosity of state runs. By default, the  results  of  all
   states are returned, but setting this value to False will cause salt to
   only display output for states that failed or states that have changes.

      state_verbose: False

   state_output
   Default: full

   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.  If set to 'mixed',  the
   output  will  be terse unless a state failed, in which case that output
   will be full.  If set to 'changes', the output will be full unless  the
   state didn't change.

      state_output: full

   state_aggregate
   Default: 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.

      state_aggregate:
        - pkg

      state_aggregate: True

   state_events
   Default: False

   Send  progress  events  as  each  function  in  a  state  run completes
   execution by setting  to  True.  Progress  events  are  in  the  format
   salt/job/<JID>/prog/<MID>/<RUN NUM>.

      state_events: True

   yaml_utf8
   Default: False

   Enable  extra  routines  for  YAML  renderer used states containing UTF
   characters.

      yaml_utf8: False

   test
   Default: False

   Set all state calls to only test if they are  going  to  actually  make
   changes or just post what changes are going to be made.

      test: False

   runner_returns
   Default: False

   If  set  to  True,  runner  jobs will be saved to job cache (defined by
   master_job_cache).

      runner_returns: True

   Master File Server Settings
   fileserver_backend
   Default: ['roots']

   Salt supports a modular fileserver backend system, this  system  allows
   the  salt  master to link directly to third party systems to gather and
   manage the  files  available  to  minions.  Multiple  backends  can  be
   configured  and will be searched for the requested file in the order in
   which they are defined here.  The  default  setting  only  enables  the
   standard  backend  roots,  which  is  configured  using  the file_roots
   option.

   Example:

      fileserver_backend:
        - roots
        - git

   NOTE:
      For masterless Salt, this parameter must be specified in the  minion
      config file.

   fileserver_followsymlinks
   New in version 2014.1.0.

   Default: True

   By   default,   the  file_server  follows  symlinks  when  walking  the
   filesystem tree.  Currently this only  applies  to  the  default  roots
   fileserver_backend.

      fileserver_followsymlinks: True

   fileserver_ignoresymlinks
   New in version 2014.1.0.

   Default: False

   If  you  do  not  want  symlinks  to  be  treated as the files they are
   pointing to, set fileserver_ignoresymlinks to True. By default this  is
   set  to  False.  When  set  to True, any detected symlink while listing
   files on the Master will not be returned to the Minion.

      fileserver_ignoresymlinks: False

   fileserver_limit_traversal
   New in version 2014.1.0.

   Default: False

   By default,  the  Salt  fileserver  recurses  fully  into  all  defined
   environments  to  attempt to find files. To limit this behavior so that
   the fileserver only traverses directories with SLS  files  and  special
   Salt directories like _modules, set fileserver_limit_traversal to True.
   This might be useful for installations where a file  root  has  a  very
   large number of files and performance is impacted.

      fileserver_limit_traversal: False

   fileserver_list_cache_time
   New in version 2014.1.0.

   Changed  in  version 2016.11.0: The default was changed from 30 seconds
   to 20.

   Default: 20

   Salt caches the list of files/symlinks/directories for each  fileserver
   backend  and  environment  as  they  are  requested, to guard against a
   performance  bottleneck  at  scale  when  many  minions  all  ask   the
   fileserver which files are available simultaneously. This configuration
   parameter allows for the max age of that cache to be altered.

   Set this value to 0 to disable use of this cache altogether,  but  keep
   in  mind that this may increase the CPU load on the master when running
   a highstate on a large number of minions.

   NOTE:
      Rather  than  altering  this  configuration  parameter,  it  may  be
      advisable  to  use  the  fileserver.clear_list_cache runner to clear
      these caches.

      fileserver_list_cache_time: 5

   hash_type
   Default: sha256

   The hash_type is the hash to use when discovering the hash of a file on
   the  master  server.  The  default  is  sha256,  but md5, sha1, sha224,
   sha384, and sha512 are also supported.

      hash_type: sha256

   file_buffer_size
   Default: 1048576

   The buffer size in the file server in bytes.

      file_buffer_size: 1048576

   file_ignore_regex
   Default: ''

   A regular expression (or a list of expressions) that  will  be  matched
   against  the  file  path  before  syncing the modules and states to the
   minions.  This includes files affected by the file.recurse state.   For
   example, if you manage your custom modules and states in subversion and
   don't want all the '.svn' folders and content synced to  your  minions,
   you could set this to '/.svn($|/)'. By default nothing is ignored.

      file_ignore_regex:
        - '/\.svn($|/)'
        - '/\.git($|/)'

   file_ignore_glob
   Default ''

   A  file  glob  (or list of file globs) that will be matched against the
   file path before syncing the modules and states to the minions. This is
   similar  to  file_ignore_regex  above,  but  works  on globs instead of
   regex. By default nothing is ignored.

      file_ignore_glob:
        - '\*.pyc'
        - '\*/somefolder/\*.bak'
        - '\*.swp'

   NOTE:
      Vim's  .swp  files  are  a  common  cause  of  Unicode   errors   in
      file.recurse  states  which  use  templating. Unless there is a good
      reason to distribute them via the fileserver, it is good practice to
      include '\*.swp' in the file_ignore_glob.

   roots: Master's Local File Server
   file_roots
   Default:

      base:
        - /srv/salt

   Salt  runs a lightweight file server written in ZeroMQ to deliver files
   to minions. This file server is built into the master daemon  and  does
   not require a dedicated port.

   The  file  server  works  on  environments  passed  to the master. 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

   NOTE:
      For  masterless Salt, this parameter must be specified in the minion
      config file.

   git: Git Remote File Server Backend
   gitfs_remotes
   Default: []

   When using the git fileserver backend at least one git remote needs  to
   be  defined.  The user running the salt master will need read access to
   the repo.

   The repos will be searched in order to find the  file  requested  by  a
   client and the first repo to have the file will return it. Branches and
   tags are translated into salt environments.

      gitfs_remotes:
        - git://github.com/saltstack/salt-states.git
        - file:///var/git/saltmaster

   NOTE:
      file:// repos will be treated  as  a  remote  and  copied  into  the
      master's gitfs cache, so only the local refs for those repos will be
      exposed as fileserver environments.

   As of 2014.7.0, it is possible to have per-repo versions of several  of
   the gitfs configuration parameters. For more information, see the GitFS
   Walkthrough.

   gitfs_provider
   New in version 2014.7.0.

   Optional parameter used to specify the provider to be used  for  gitfs.
   More information can be found in the GitFS Walkthrough.

   Must  be one of the following: pygit2, gitpython, or dulwich. If unset,
   then each will be tried in that same order, and the first  one  with  a
   compatible version installed will be the provider that is used.

      gitfs_provider: dulwich

   gitfs_ssl_verify
   Changed in version 2016.11.0.

   Default: True

   Specifies  whether  or  not  to  ignore  SSL  certificate  errors  when
   contacting the remote repository. The False setting is useful if you're
   using  a git repo that uses a self-signed certificate. However, keep in
   mind that setting this to anything other True is a considered insecure,
   and using an SSH-based transport (if available) may be a better option.

   In  the  2016.11.0 release, the default config value changed from False
   to True.

      gitfs_ssl_verify: True

   gitfs_mountpoint
   New in version 2014.7.0.

   Default: ''

   Specifies a path on the salt fileserver which will be prepended to  all
   files  served  by  gitfs.  This  option can be used in conjunction with
   gitfs_root. It can also be configured on a per-remote basis,  see  here
   for more info.

      gitfs_mountpoint: salt://foo/bar

   NOTE:
      The  salt://  protocol  designation can be left off (in other words,
      foo/bar and salt://foo/bar are equivalent). Assuming a  file  baz.sh
      in  the  root  of  a gitfs remote, and the above example mountpoint,
      this file would be served up via salt://foo/bar/baz.sh.

   gitfs_root
   Default: ''

   Relative path to a subdirectory within the repository from  which  Salt
   should begin to serve files. This is useful when there are files in the
   repository that should not be available to the Salt fileserver. Can  be
   used  in  conjunction  with gitfs_mountpoint. If used, then from Salt's
   perspective the directories above the one specified will be ignored and
   the relative path will (for the purposes of gitfs) be considered as the
   root of the repo.

      gitfs_root: somefolder/otherfolder

   Changed in version 2014.7.0:  Ability  to  specify  gitfs  roots  on  a
   per-remote basis was added. See here for more info.

   gitfs_base
   Default: master

   Defines which branch/tag should be used as the base environment.

      gitfs_base: salt

   Changed  in  version  2014.7.0:  Ability  to  specify  the  base  on  a
   per-remote basis was added. See here for more info.

   gitfs_saltenv
   New in version 2016.11.0.

   Default: []

   Global  settings  for  per-saltenv  configuration  parameters.   Though
   per-saltenv  configuration  parameters  are  typically  one-off changes
   specific to a single gitfs remote, and thus more often configured on  a
   per-remote  basis,  this  parameter  can be used to specify per-saltenv
   changes which should apply to  all  remotes.  For  example,  the  below
   configuration  will  map  the develop branch to the dev saltenv for all
   gitfs remotes.

      gitfs_saltenv:
        - dev:
          - ref: develop

   gitfs_env_whitelist
   New in version 2014.7.0.

   Default: []

   Used to restrict which environments are made available.  Can  speed  up
   state  runs  if  the repos in gitfs_remotes contain many branches/tags.
   More information can be found in the GitFS Walkthrough.

      gitfs_env_whitelist:
        - base
        - v1.*
        - 'mybranch\d+'

   gitfs_env_blacklist
   New in version 2014.7.0.

   Default: []

   Used to restrict which environments are made available.  Can  speed  up
   state  runs  if  the repos in gitfs_remotes contain many branches/tags.
   More information can be found in the GitFS Walkthrough.

      gitfs_env_blacklist:
        - base
        - v1.*
        - 'mybranch\d+'

   gitfs_global_lock
   New in version 2015.8.9.

   Default: True

   When set to False, if there is an update lock for a  gitfs  remote  and
   the  pid written to it is not running on the master, the lock file will
   be automatically cleared and a new lock will be obtained. When  set  to
   True,  Salt  will  simply  log  a  warning when there is an update lock
   present.

   On  single-master  deployments,  disabling   this   option   can   help
   automatically    deal    with    instances   where   the   master   was
   shutdown/restarted during the middle  of  a  gitfs  update,  leaving  a
   update lock in place.

   However, on multi-master deployments with the gitfs cachedir shared via
   GlusterFS,  nfs,  or  another  network  filesystem,  it   is   strongly
   recommended  not  to  disable  this  option as doing so will cause lock
   files to be removed if they were created by a different master.

      # Disable global lock
      gitfs_global_lock: False

   GitFS Authentication Options
   These parameters only currently apply to  the  pygit2  gitfs  provider.
   Examples of how to use these can be found in the GitFS Walkthrough.

   gitfs_user
   New in version 2014.7.0.

   Default: ''

   Along with gitfs_password, is used to authenticate to HTTPS remotes.

      gitfs_user: git

   gitfs_password
   New in version 2014.7.0.

   Default: ''

   Along  with gitfs_user, is used to authenticate to HTTPS remotes.  This
   parameter  is  not  required   if   the   repository   does   not   use
   authentication.

      gitfs_password: mypassword

   gitfs_insecure_auth
   New in version 2014.7.0.

   Default: False

   By  default,  Salt will not authenticate to an HTTP (non-HTTPS) remote.
   This parameter enables authentication over HTTP. Enable  this  at  your
   own risk.

      gitfs_insecure_auth: True

   gitfs_pubkey
   New in version 2014.7.0.

   Default: ''

   Along  with gitfs_privkey (and optionally gitfs_passphrase), is used to
   authenticate  to  SSH  remotes.  This  parameter  (or  its   per-remote
   counterpart) is required for SSH remotes.

      gitfs_pubkey: /path/to/key.pub

   gitfs_privkey
   New in version 2014.7.0.

   Default: ''

   Along  with  gitfs_pubkey (and optionally gitfs_passphrase), is used to
   authenticate  to  SSH  remotes.  This  parameter  (or  its   per-remote
   counterpart) is required for SSH remotes.

      gitfs_privkey: /path/to/key

   gitfs_passphrase
   New in version 2014.7.0.

   Default: ''

   This  parameter  is optional, required only when the SSH key being used
   to authenticate is protected by a passphrase.

      gitfs_passphrase: mypassphrase

   hg: Mercurial Remote File Server Backend
   hgfs_remotes
   New in version 0.17.0.

   Default: []

   When using the hg fileserver backend  at  least  one  mercurial  remote
   needs  to  be  defined. The user running the salt master will need read
   access to the repo.

   The repos will be searched in order to find the  file  requested  by  a
   client  and  the  first  repo to have the file will return it. Branches
   and/or bookmarks are translated into salt environments, as  defined  by
   the hgfs_branch_method parameter.

      hgfs_remotes:
        - https://[email protected]/username/reponame

   NOTE:
      As  of  2014.7.0,  it  is  possible to have per-repo versions of the
      hgfs_root,  hgfs_mountpoint,   hgfs_base,   and   hgfs_branch_method
      parameters.  For example:

          hgfs_remotes:
            - https://[email protected]/username/repo1
              - base: saltstates
            - https://[email protected]/username/repo2:
              - root: salt
              - mountpoint: salt://foo/bar/baz
            - https://[email protected]/username/repo3:
              - root: salt/states
              - branch_method: mixed

   hgfs_branch_method
   New in version 0.17.0.

   Default: branches

   Defines the objects that will be used as fileserver environments.

   * branches - Only branches and tags will be used

   * bookmarks - Only bookmarks and tags will be used

   * mixed - Branches, bookmarks, and tags will be used

      hgfs_branch_method: mixed

   NOTE:
      Starting  in  version 2014.1.0, the value of the hgfs_base parameter
      defines which branch is used as the base environment, allowing for a
      base environment to be used with an hgfs_branch_method of bookmarks.

      Prior  to  this release, the default branch will be used as the base
      environment.

   hgfs_mountpoint
   New in version 2014.7.0.

   Default: ''

   Specifies a path on the salt fileserver which will be prepended to  all
   files  served  by  hgfs.  This  option  can be used in conjunction with
   hgfs_root. It can also be configured on a per-remote  basis,  see  here
   for more info.

      hgfs_mountpoint: salt://foo/bar

   NOTE:
      The  salt://  protocol  designation can be left off (in other words,
      foo/bar and salt://foo/bar are equivalent). Assuming a  file  baz.sh
      in  the  root  of  an  hgfs remote, this file would be served up via
      salt://foo/bar/baz.sh.

   hgfs_root
   New in version 0.17.0.

   Default: ''

   Relative path to a subdirectory within the repository from  which  Salt
   should begin to serve files. This is useful when there are files in the
   repository that should not be available to the Salt fileserver. Can  be
   used  in  conjunction  with  hgfs_mountpoint. If used, then from Salt's
   perspective the directories above the one specified will be ignored and
   the  relative path will (for the purposes of hgfs) be considered as the
   root of the repo.

      hgfs_root: somefolder/otherfolder

   Changed in version  2014.7.0:  Ability  to  specify  hgfs  roots  on  a
   per-remote basis was added. See here for more info.

   hgfs_base
   New in version 2014.1.0.

   Default: default

   Defines  which  branch  should  be used as the base environment. Change
   this if  hgfs_branch_method  is  set  to  bookmarks  to  specify  which
   bookmark should be used as the base environment.

      hgfs_base: salt

   hgfs_env_whitelist
   New in version 2014.7.0.

   Default: []

   Used  to  restrict  which environments are made available. Can speed up
   state runs if your hgfs remotes contain  many  branches/bookmarks/tags.
   Full  names,  globs,  and regular expressions are supported. If using a
   regular expression, the expression must match the entire minion ID.

   If used, only branches/bookmarks/tags which match one of the  specified
   expressions will be exposed as fileserver environments.

   If  used  in  conjunction  with  hgfs_env_blacklist, then the subset of
   branches/bookmarks/tags which match the whitelist but do not match  the
   blacklist will be exposed as fileserver environments.

      hgfs_env_whitelist:
        - base
        - v1.*
        - 'mybranch\d+'

   hgfs_env_blacklist
   New in version 2014.7.0.

   Default: []

   Used  to  restrict  which environments are made available. Can speed up
   state runs if your hgfs remotes contain  many  branches/bookmarks/tags.
   Full  names,  globs,  and regular expressions are supported. If using a
   regular expression, the expression must match the entire minion ID.

   If used, branches/bookmarks/tags  which  match  one  of  the  specified
   expressions will not be exposed as fileserver environments.

   If  used  in  conjunction  with  hgfs_env_whitelist, then the subset of
   branches/bookmarks/tags which match the whitelist but do not match  the
   blacklist will be exposed as fileserver environments.

      hgfs_env_blacklist:
        - base
        - v1.*
        - 'mybranch\d+'

   svn: Subversion Remote File Server Backend
   svnfs_remotes
   New in version 0.17.0.

   Default: []

   When  using  the  svn fileserver backend at least one subversion remote
   needs to be defined. The user running the salt master  will  need  read
   access to the repo.

   The  repos  will  be  searched in order to find the file requested by a
   client and the first repo to have the file will return it.  The  trunk,
   branches,  and  tags become environments, with the trunk being the base
   environment.

      svnfs_remotes:
        - svn://foo.com/svn/myproject

   NOTE:
      As of 2014.7.0, it is possible to  have  per-repo  versions  of  the
      following configuration parameters:

      * svnfs_root

      * svnfs_mountpoint

      * svnfs_trunk

      * svnfs_branches

      * svnfs_tags

      For example:

          svnfs_remotes:
            - svn://foo.com/svn/project1
            - svn://foo.com/svn/project2:
              - root: salt
              - mountpoint: salt://foo/bar/baz
            - svn//foo.com/svn/project3:
              - root: salt/states
              - branches: branch
              - tags: tag

   svnfs_mountpoint
   New in version 2014.7.0.

   Default: ''

   Specifies  a path on the salt fileserver which will be prepended to all
   files served by hgfs. This option  can  be  used  in  conjunction  with
   svnfs_root.  It  can also be configured on a per-remote basis, see here
   for more info.

      svnfs_mountpoint: salt://foo/bar

   NOTE:
      The salt:// protocol designation can be left off  (in  other  words,
      foo/bar  and  salt://foo/bar are equivalent). Assuming a file baz.sh
      in the root of an svnfs remote, this file would  be  served  up  via
      salt://foo/bar/baz.sh.

   svnfs_root
   New in version 0.17.0.

   Default: ''

   Relative  path  to a subdirectory within the repository from which Salt
   should begin to serve files. This is useful when there are files in the
   repository  that should not be available to the Salt fileserver. Can be
   used in conjunction with svnfs_mountpoint. If used,  then  from  Salt's
   perspective the directories above the one specified will be ignored and
   the relative path will (for the purposes of svnfs) be considered as the
   root of the repo.

      svnfs_root: somefolder/otherfolder

   Changed  in  version  2014.7.0:  Ability  to  specify  svnfs roots on a
   per-remote basis was added. See here for more info.

   svnfs_trunk
   New in version 2014.7.0.

   Default: trunk

   Path relative to the root of the repository where the trunk is located.
   Can also be configured on a per-remote basis, see here for more info.

      svnfs_trunk: trunk

   svnfs_branches
   New in version 2014.7.0.

   Default: branches

   Path  relative  to  the  root  of the repository where the branches are
   located. Can also be configured on a per-remote  basis,  see  here  for
   more info.

      svnfs_branches: branches

   svnfs_tags
   New in version 2014.7.0.

   Default: tags

   Path relative to the root of the repository where the tags are located.
   Can also be configured on a per-remote basis, see here for more info.

      svnfs_tags: tags

   svnfs_env_whitelist
   New in version 2014.7.0.

   Default: []

   Used to restrict which environments are made available.  Can  speed  up
   state  runs  if  your  svnfs  remotes  contain many branches/tags. Full
   names, globs, and regular expressions are supported. If using a regular
   expression, the expression must match the entire minion ID.

   If   used,   only  branches/tags  which  match  one  of  the  specified
   expressions will be exposed as fileserver environments.

   If used in conjunction with svnfs_env_blacklist,  then  the  subset  of
   branches/tags  which match the whitelist but do not match the blacklist
   will be exposed as fileserver environments.

      svnfs_env_whitelist:
        - base
        - v1.*
        - 'mybranch\d+'

   svnfs_env_blacklist
   New in version 2014.7.0.

   Default: []

   Used to restrict which environments are made available.  Can  speed  up
   state  runs  if  your  svnfs  remotes  contain many branches/tags. Full
   names, globs, and regular expressions are supported. If using a regular
   expression, the expression must match the entire minion ID.

   If  used,  branches/tags  which  match one of the specified expressions
   will not be exposed as fileserver environments.

   If used in conjunction with svnfs_env_whitelist,  then  the  subset  of
   branches/tags  which match the whitelist but do not match the blacklist
   will be exposed as fileserver environments.

      svnfs_env_blacklist:
        - base
        - v1.*
        - 'mybranch\d+'

   minion: MinionFS Remote File Server Backend
   minionfs_env
   New in version 2014.7.0.

   Default: base

   Environment from which MinionFS files are made available.

      minionfs_env: minionfs

   minionfs_mountpoint
   New in version 2014.7.0.

   Default: ''

   Specifies a path on the salt fileserver from which minionfs  files  are
   served.

      minionfs_mountpoint: salt://foo/bar

   NOTE:
      The  salt://  protocol  designation can be left off (in other words,
      foo/bar and salt://foo/bar are equivalent).

   minionfs_whitelist
   New in version 2014.7.0.

   Default: []

   Used to restrict which minions' pushed files are exposed via  minionfs.
   If  using  a  regular  expression, the expression must match the entire
   minion ID.

   If used, only the pushed files from minions  which  match  one  of  the
   specified expressions will be exposed.

   If  used  in  conjunction  with  minionfs_blacklist, then the subset of
   hosts which match the whitelist but do not match the blacklist will  be
   exposed.

      minionfs_whitelist:
        - server01
        - dev*
        - 'mail\d+.mydomain.tld'

   minionfs_blacklist
   New in version 2014.7.0.

   Default: []

   Used  to restrict which minions' pushed files are exposed via minionfs.
   If using a regular expression, the expression  must  match  the  entire
   minion ID.

   If  used,  only  the  pushed  files from minions which match one of the
   specified expressions will not be exposed.

   If used in conjunction with  minionfs_whitelist,  then  the  subset  of
   hosts  which match the whitelist but do not match the blacklist will be
   exposed.

      minionfs_blacklist:
        - server01
        - dev*
        - 'mail\d+.mydomain.tld'

   Pillar Configuration
   pillar_roots
   Default:

      base:
        - /srv/pillar

   Set the environments and directories used to hold pillar sls data. This
   configuration is the same as file_roots:

      pillar_roots:
        base:
          - /srv/pillar
        dev:
          - /srv/pillar/dev
        prod:
          - /srv/pillar/prod

   pillar_opts
   Default: False

   The  pillar_opts  option  adds  the master configuration file data to a
   dict in the pillar called master.  This  can  be  used  to  set  simple
   configurations  in  the  master  config  file  that can then be used on
   minions.

   Note that setting this option to True means the master config file will
   be   included   in  all  minion's  pillars.  While  this  makes  global
   configuration of services and systems easy, it may not  be  desired  if
   sensitive data is stored in the master configuration.

      pillar_opts: False

   ext_pillar
   The  ext_pillar  option  allows  for  any  number  of  external  pillar
   interfaces to be called when populating pillar data. The  configuration
   is  based  on  ext_pillar functions. The available ext_pillar functions
   can be found herein:

   https://github.com/saltstack/salt/blob/develop/salt/pillar

   By default, the ext_pillar interface is not configured to run.

   Default: []

      ext_pillar:
        - hiera: /etc/hiera.yaml
        - cmd_yaml: cat /etc/salt/yaml
        - reclass:
            inventory_base_uri: /etc/reclass

   There are additional details at salt-pillars

   ext_pillar_first
   New in version 2015.5.0.

   Default: False

   This option allows for external pillar sources to be  evaluated  before
   pillar_roots.   External  pillar  data  is  evaluated  separately  from
   pillar_roots pillar data, and then both sets of pillar data are  merged
   into  a  single  pillar  dictionary, so the value of this config option
   will have an impact on which key "wins" when there is one of  the  same
   name  in both the external pillar data and pillar_roots pillar data. By
   setting this option to True, ext_pillar  keys  will  be  overridden  by
   pillar_roots,  while  leaving it as False will allow ext_pillar keys to
   override those from pillar_roots.

   NOTE:
      For a while, this config option did not  work  as  specified  above,
      because  of  a bug in Pillar compilation. This bug has been resolved
      in version 2016.3.4 and later.

      ext_pillar_first: False

   pillar_raise_on_missing
   New in version 2015.5.0.

   Default: False

   Set this option to True to force a KeyError to be  raised  whenever  an
   attempt  to  retrieve a named value from pillar fails. When this option
   is set to False, the failed attempt returns an empty string.

   Git External Pillar (git_pillar) Configuration Options
   git_pillar_provider
   New in version 2015.8.0.

   Specify the provider to be used for git_pillar. Must be  either  pygit2
   or gitpython. If unset, then both will be tried in that same order, and
   the first one with a compatible version installed will be the  provider
   that is used.

      git_pillar_provider: gitpython

   git_pillar_base
   New in version 2015.8.0.

   Default: master

   If  the  desired  branch  matches  this  value,  and the environment is
   omitted from the git_pillar configuration,  then  the  environment  for
   that  git_pillar remote will be base. For example, in the configuration
   below, the foo branch/tag would be assigned to  the  base  environment,
   while bar would be mapped to the bar environment.

      git_pillar_base: foo

      ext_pillar:
        - git:
          - foo https://mygitserver/git-pillar.git
          - bar https://mygitserver/git-pillar.git

   git_pillar_branch
   New in version 2015.8.0.

   Default: master

   If  the  branch  is  omitted from a git_pillar remote, then this branch
   will be used instead. For example,  in  the  configuration  below,  the
   first  two remotes would use the pillardata branch/tag, while the third
   would use the foo branch/tag.

      git_pillar_branch: pillardata

      ext_pillar:
        - git:
          - https://mygitserver/pillar1.git
          - https://mygitserver/pillar2.git:
            - root: pillar
          - foo https://mygitserver/pillar3.git

   git_pillar_env
   New in version 2015.8.0.

   Default: '' (unset)

   Environment to use for git_pillar remotes.  This  is  normally  derived
   from  the  branch/tag  (or from a per-remote env parameter), but if set
   this will override the process of deriving the env from the  branch/tag
   name.  For  example, in the configuration below the foo branch would be
   assigned to the base environment, while the bar branch  would  need  to
   explicitly have bar configured as it's environment to keep it from also
   being mapped to the base environment.

      git_pillar_env: base

      ext_pillar:
        - git:
          - foo https://mygitserver/git-pillar.git
          - bar https://mygitserver/git-pillar.git:
            - env: bar

   For this reason, this option is recommended to be  left  unset,  unless
   the use case calls for all (or almost all) of the git_pillar remotes to
   use the same environment irrespective of the branch/tag being used.

   git_pillar_root
   New in version 2015.8.0.

   Default: ''

   Path relative to the root of the repository where  the  git_pillar  top
   file  and SLS files are located. In the below configuration, the pillar
   top file and SLS files would be looked for  in  a  subdirectory  called
   pillar.

      git_pillar_root: pillar

      ext_pillar:
        - git:
          - master https://mygitserver/pillar1.git
          - master https://mygitserver/pillar2.git

   NOTE:
      This is a global option. If only one or two repos need to have their
      files sourced from  a  subdirectory,  then  git_pillar_root  can  be
      omitted  and  the  root can be specified on a per-remote basis, like
      so:

          ext_pillar:
            - git:
              - master https://mygitserver/pillar1.git
              - master https://mygitserver/pillar2.git:
                - root: pillar

      In this example, for the first remote the top  file  and  SLS  files
      would  be  looked  for  in  the root of the repository, while in the
      second remote the pillar data would be  retrieved  from  the  pillar
      subdirectory.

   git_pillar_ssl_verify
   New in version 2015.8.0.

   Changed in version 2016.11.0.

   Default: False

   Specifies  whether  or  not  to  ignore  SSL  certificate  errors  when
   contacting the remote repository. The False setting is useful if you're
   using  a git repo that uses a self-signed certificate. However, keep in
   mind that setting this to anything other True is a considered insecure,
   and using an SSH-based transport (if available) may be a better option.

   In  the  2016.11.0 release, the default config value changed from False
   to True.

      git_pillar_ssl_verify: True

   git_pillar_global_lock
   New in version 2015.8.9.

   Default: True

   When set to False, if there is an update/checkout lock for a git_pillar
   remote and the pid written to it is not running on the master, the lock
   file will be automatically cleared and a new  lock  will  be  obtained.
   When  set to True, Salt will simply log a warning when there is an lock
   present.

   On  single-master  deployments,  disabling   this   option   can   help
   automatically    deal    with    instances   where   the   master   was
   shutdown/restarted during the middle of a  git_pillar  update/checkout,
   leaving a lock in place.

   However,  on  multi-master  deployments  with  the  git_pillar cachedir
   shared via  GlusterFS,  nfs,  or  another  network  filesystem,  it  is
   strongly  recommended not to disable this option as doing so will cause
   lock files to be removed if they were created by a different master.

      # Disable global lock
      git_pillar_global_lock: False

   Git External Pillar Authentication Options
   These   parameters    only    currently    apply    to    the    pygit2
   git_pillar_provider.   Authentication  works  the  same  as  it does in
   gitfs,  as  outlined  in  the  GitFS  Walkthrough,  though  the  global
   configuration  options  are  named differently to reflect that they are
   for git_pillar instead of gitfs.

   git_pillar_user
   New in version 2015.8.0.

   Default: ''

   Along with  git_pillar_password,  is  used  to  authenticate  to  HTTPS
   remotes.

      git_pillar_user: git

   git_pillar_password
   New in version 2015.8.0.

   Default: ''

   Along  with  git_pillar_user, is used to authenticate to HTTPS remotes.
   This  parameter  is  not  required  if  the  repository  does  not  use
   authentication.

      git_pillar_password: mypassword

   git_pillar_insecure_auth
   New in version 2015.8.0.

   Default: False

   By  default,  Salt will not authenticate to an HTTP (non-HTTPS) remote.
   This parameter enables authentication over HTTP. Enable  this  at  your
   own risk.

      git_pillar_insecure_auth: True

   git_pillar_pubkey
   New in version 2015.8.0.

   Default: ''

   Along  with  git_pillar_privkey (and optionally git_pillar_passphrase),
   is used to authenticate to SSH remotes.

      git_pillar_pubkey: /path/to/key.pub

   git_pillar_privkey
   New in version 2015.8.0.

   Default: ''

   Along with git_pillar_pubkey (and optionally git_pillar_passphrase), is
   used to authenticate to SSH remotes.

      git_pillar_privkey: /path/to/key

   git_pillar_passphrase
   New in version 2015.8.0.

   Default: ''

   This  parameter  is optional, required only when the SSH key being used
   to authenticate is protected by a passphrase.

      git_pillar_passphrase: mypassphrase

   Pillar Merging Options
   pillar_source_merging_strategy
   New in version 2014.7.0.

   Default: smart

   The  pillar_source_merging_strategy  option  allows  you  to  configure
   merging strategy between different sources. It accepts 5 values:

   * none:

   New  in  version  2016.3.4:  It will not do any merging at all and only
   parse the pillar data from the passed  environment  and  'base'  if  no
   environment was specified.

   * recurse:

     it  will  merge  recursively  mapping  of data. For example, theses 2
     sources:

        foo: 42
        bar:
            element1: True

        bar:
            element2: True
        baz: quux

     will be merged as:

        foo: 42
        bar:
            element1: True
            element2: True
        baz: quux

   * aggregate:

     instructs aggregation  of  elements  between  sources  that  use  the
     #!yamlex renderer.

     For example, these two documents:

        #!yamlex
        foo: 42
        bar: !aggregate {
          element1: True
        }
        baz: !aggregate quux

        #!yamlex
        bar: !aggregate {
          element2: True
        }
        baz: !aggregate quux2

     will be merged as:

        foo: 42
        bar:
          element1: True
          element2: True
        baz:
          - quux
          - quux2

   * overwrite:

     Will use the behaviour of the 2014.1 branch and earlier.

     Overwrites elements according the order in which they are processed.

     First pillar processed:

        A:
          first_key: blah
          second_key: blah

     Second pillar processed:

        A:
          third_key: blah
          fourth_key: blah

     will be merged as:

        A:
          third_key: blah
          fourth_key: blah

   * smart (default):

     Guesses the best strategy based on the "renderer" setting.

   pillar_merge_lists
   New in version 2015.8.0.

   Default: False

   Recursively merge lists by aggregating them instead of replacing them.

      pillar_merge_lists: False

   Pillar Cache Options
   pillar_cache
   New in version 2015.8.8.

   Default: False

   A  master  can cache pillars locally to bypass the expense of having to
   render them for each minion on every request. This feature should  only
   be  enabled  in  cases  where  pillar  rendering  time  is  known to be
   unsatisfactory  and  any  attendant  security  concerns  about  storing
   pillars in a master cache have been addressed.

   When  enabling  this feature, be certain to read through the additional
   pillar_cache_* configuration options to fully  understand  the  tunable
   parameters and their implications.

      pillar_cache: False

   NOTE:
      Setting  pillar_cache:  True has no effect on targeting minions with
      pillar.

   pillar_cache_ttl
   New in version 2015.8.8.

   Default: 3600

   If and only if a master has  set  pillar_cache:  True,  the  cache  TTL
   controls the amount of time, in seconds, before the cache is considered
   invalid by a master and a fresh pillar is recompiled and stored.

   pillar_cache_backend
   New in version 2015.8.8.

   Default: disk

   If an only if a master has  set  pillar_cache:  True,  one  of  several
   storage providers can be utilized:

   * disk (default):

     The  default  storage  backend.  This  caches rendered pillars to the
     master cache.  Rendered pillars are serialized  and  deserialized  as
     msgpack   structures   for  speed.   Note  that  pillars  are  stored
     UNENCRYPTED.  Ensure  that  the  master  cache  has  permissions  set
     appropriately (sane defaults are provided).

   * memory [EXPERIMENTAL]:

     An  optional  backend  for  pillar  caches  which  uses a pure-Python
     in-memory data structure for maximal performance. There  are  several
     caveats,  however. First, because each master worker contains its own
     in-memory cache, there is no guarantee of cache  consistency  between
     minion  requests.  This  works  best  in  situations where the pillar
     rarely if ever changes. Secondly, and perhaps more importantly,  this
     means  that  unencrypted  pillars  will  be accessible to any process
     which can examine the memory of the salt-master!  This may  represent
     a substantial security risk.

      pillar_cache_backend: disk

   Syndic Server Settings
   A Salt syndic is a Salt master used to pass commands from a higher Salt
   master to minions below the syndic. Using the syndic is simple. If this
   is  a  master  that  will  have  syndic  servers(s)  below  it, set the
   order_masters setting to True.

   If this  is  a  master  that  will  be  running  a  syndic  daemon  for
   passthrough  the  syndic_master setting needs to be set to the location
   of the master server.

   Do not forget that, in other words, it means that it  shares  with  the
   local minion its ID and PKI directory.

   order_masters
   Default: False

   Extra  data  needs  to  be  sent  with  publications  if  the master is
   controlling a lower level master via a syndic minion. If  this  is  the
   case the order_masters value must be set to True

      order_masters: False

   syndic_master
   Changed  in version 2016.3.5,2016.11.1: Set default higher level master
   address.

   Default: masterofmasters

   If this master will be running the salt-syndic to connect to  a  higher
   level  master,  specify the higher level master with this configuration
   value.

      syndic_master: masterofmasters

   You can optionally connect a syndic to multiple higher level masters by
   setting the syndic_master value to a list:

      syndic_master:
        - masterofmasters1
        - masterofmasters2

   Each   higher   level   master   must  be  set  up  in  a  multi-master
   configuration.

   syndic_master_port
   Default: 4506

   If this master will be running the salt-syndic to connect to  a  higher
   level   master,   specify  the  higher  level  master  port  with  this
   configuration value.

      syndic_master_port: 4506

   syndic_pidfile
   Default: /var/run/salt-syndic.pid

   If this master will be running the salt-syndic to connect to  a  higher
   level master, specify the pidfile of the syndic daemon.

      syndic_pidfile: /var/run/syndic.pid

   syndic_log_file
   Default: /var/log/salt/syndic

   If  this  master will be running the salt-syndic to connect to a higher
   level master, specify the log file of the syndic daemon.

      syndic_log_file: /var/log/salt-syndic.log

   syndic_failover
   New in version 2016.3.0.

   Default: random

   The behaviour of the  multi-syndic  when  connection  to  a  master  of
   masters  failed.   Can  specify  random (default) or ordered. If set to
   random, masters will  be  iterated  in  random  order.  If  ordered  is
   specified, the configured order will be used.

      syndic_failover: random

   Peer Publish Settings
   Salt minions can send commands to other minions, but only if the minion
   is allowed to. By default "Peer  Publication"  is  disabled,  and  when
   enabled  it is enabled for specific minions and specific commands. This
   allows secure compartmentalization  of  commands  based  on  individual
   minions.

   peer
   Default: {}

   The  configuration uses regular expressions to match minions and then a
   list of regular expressions to  match  functions.  The  following  will
   allow  the minion authenticated as foo.example.com to execute functions
   from the test and pkg modules.

      peer:
        foo.example.com:
            - test.*
            - pkg.*

   This will allow all minions to execute all commands:

      peer:
        .*:
            - .*

   This is not recommended, since it would allow anyone who gets  root  on
   any single minion to instantly have root on all of the minions!

   By  adding  an  additional  layer  you  can  limit  the target hosts in
   addition to the accessible commands:

      peer:
        foo.example.com:
          'db*':
            - test.*
            - pkg.*

   peer_run
   Default: {}

   The peer_run option is used to open up runners on the master to  access
   from  the minions. The peer_run configuration matches the format of the
   peer configuration.

   The following  example  would  allow  foo.example.com  to  execute  the
   manage.up runner:

      peer_run:
        foo.example.com:
            - manage.up

   Master Logging Settings
   log_file
   Default: /var/log/salt/master

   The  master  log  can  be  sent  to a regular file, local path name, or
   network location. See also log_file.

   Examples:

      log_file: /var/log/salt/master

      log_file: file:///dev/log

      log_file: udp://loghost:10514

   log_level
   Default: warning

   The level of messages to send to the console. See also log_level.

      log_level: warning

   log_level_logfile
   Default: warning

   The  level  of  messages  to  send  to   the   log   file.   See   also
   log_level_logfile.  When  it  is not set explicitly it will inherit the
   level set by log_level option.

      log_level_logfile: warning

   log_datefmt
   Default: %H:%M:%S

   The date and time  format  used  in  console  log  messages.  See  also
   log_datefmt.

      log_datefmt: '%H:%M:%S'

   log_datefmt_logfile
   Default: %Y-%m-%d %H:%M:%S

   The  date  and  time  format  used  in  log  file  messages.  See  also
   log_datefmt_logfile.

      log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

   log_fmt_console
   Default: [%(levelname)-8s] %(message)s

   The format of the console logging messages. See also log_fmt_console.

   NOTE:
      Log colors are enabled in  log_fmt_console  rather  than  the  color
      config since the logging system is loaded before the master config.

      Console log colors are specified by these additional formatters:

      %(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s

      Since  it  is desirable to include the surrounding brackets, '[' and
      ']', in the coloring of the messages, these  color  formatters  also
      include  padding  as  well.   Color  LogRecord  attributes  are only
      available for console logging.

      log_fmt_console: '%(colorlevel)s %(colormsg)s'
      log_fmt_console: '[%(levelname)-8s] %(message)s'

   log_fmt_logfile
   Default:     %(asctime)s,%(msecs)03d     [%(name)-17s][%(levelname)-8s]
   %(message)s

   The format of the log file logging messages. See also log_fmt_logfile.

      log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'

   log_granular_levels
   Default: {}

   This  can be used to control logging levels more specifically. See also
   log_granular_levels.

   Node Groups
   Default: {}

   Node groups allow for logical  groupings  of  minion  nodes.   A  group
   consists of a group name and a compound target.

      nodegroups:
        group1: '[email protected],bar.domain.com,baz.domain.com or bl*.domain.com'
        group2: 'G@os:Debian and foo.domain.com'
        group3: 'G@os:Debian and N@group1'
        group4:
          - 'G@foo:bar'
          - 'or'
          - 'G@foo:baz'

   More information on using nodegroups can be found here.

   Range Cluster Settings
   range_server
   Default: 'range:80'

   The   range  server  (and  optional  port)  that  serves  your  cluster
   information
   https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec

      range_server: range:80

   Include Configuration
   default_include
   Default: master.d/*.conf

   The  master can include configuration from other files. Per default the
   master will automatically include all config files from master.d/*.conf
   where master.d is relative to the directory of the master configuration
   file.

   NOTE:
      Salt creates files in the master.d directory for its own use.  These
      files  are  prefixed with an underscore. A common example of this is
      the _schedule.conf file.

   include
   Default: not defined

   The master 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. Paths can make
   use of shell-style globbing. If no files are matched by a  path  passed
   to this option then the master will log a warning message.

      # Include files from a master.d directory in the same
      # directory as the master config file
      include: master.d/*

      # Include a single extra file into the configuration
      include: /etc/roles/webserver

      # Include several files and the master.d directory
      include:
        - extra_config
        - master.d/*
        - /etc/roles/webserver

   Windows Software Repo Settings
   winrepo_provider
   New in version 2015.8.0.

   Specify  the  provider to be used for winrepo. Must be either pygit2 or
   gitpython. If unset, then both will be tried in that  same  order,  and
   the  first one with a compatible version installed will be the provider
   that is used.

      winrepo_provider: gitpython

   winrepo_dir
   Changed in version 2015.8.0: Renamed from win_repo to winrepo_dir.

   Default: /srv/salt/win/repo

   Location on the master where the winrepo_remotes are  checked  out  for
   pre-2015.8.0 minions. 2015.8.0 and later minions use winrepo_remotes_ng
   instead.

      winrepo_dir: /srv/salt/win/repo

   winrepo_dir_ng
   New in version 2015.8.0: A new ng repo was added.

   Default: /srv/salt/win/repo-ng

   Location on the master where the winrepo_remotes_ng are checked out for
   2015.8.0 and later minions.

      winrepo_dir_ng: /srv/salt/win/repo-ng

   winrepo_cachefile
   Changed  in  version 2015.8.0: Renamed from win_repo_mastercachefile to
   winrepo_cachefile

   NOTE:
      2015.8.0 and later  minions  do  not  use  this  setting  since  the
      cachefile is now located on the minion.

   Default: winrepo.p

   Path relative to winrepo_dir where the winrepo cache should be created.

      winrepo_cachefile: winrepo.p

   winrepo_remotes
   Changed   in   version   2015.8.0:   Renamed   from   win_gitrepos   to
   winrepo_remotes.

   Default: ['https://github.com/saltstack/salt-winrepo.git']

   List of git repositories to checkout and include  in  the  winrepo  for
   pre-2015.8.0 minions. 2015.8.0 and later minions use winrepo_remotes_ng
   instead.

      winrepo_remotes:
        - https://github.com/saltstack/salt-winrepo.git

   To specify a specific revision of the repository, prepend a  commit  ID
   to the URL of the repository:

      winrepo_remotes:
        - '<commit_id> https://github.com/saltstack/salt-winrepo.git'

   Replace  <commit_id>  with  the  SHA1 hash of a commit ID. Specifying a
   commit ID is useful in that it allows one to revert back to a  previous
   version in the event that an error is introduced in the latest revision
   of the repo.

   winrepo_remotes_ng
   New in version 2015.8.0: A new ng repo was added.

   Default: ['https://github.com/saltstack/salt-winrepo-ng.git']

   List of git repositories to checkout and include  in  the  winrepo  for
   2015.8.0 and later minions.

      winrepo_remotes_ng:
        - https://github.com/saltstack/salt-winrepo-ng.git

   To  specify  a specific revision of the repository, prepend a commit ID
   to the URL of the repository:

      winrepo_remotes:
        - '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'

   Replace <commit_id> with the SHA1 hash of a  commit  ID.  Specifying  a
   commit  ID is useful in that it allows one to revert back to a previous
   version in the event that an error is introduced in the latest revision
   of the repo.

   winrepo_branch
   New in version 2015.8.0.

   Default: master

   If  the  branch is omitted from a winrepo remote, then this branch will
   be used instead. For example, in the configuration below, the first two
   remotes would use the winrepo branch/tag, while the third would use the
   foo branch/tag.

      winrepo_branch: winrepo

      ext_pillar:
        - git:
          - https://mygitserver/winrepo1.git
          - https://mygitserver/winrepo2.git:
          - foo https://mygitserver/winrepo3.git

   winrepo_ssl_verify
   New in version 2015.8.0.

   Changed in version 2016.11.0.

   Default: False

   Specifies  whether  or  not  to  ignore  SSL  certificate  errors  when
   contacting  the  remote  repository.  The   False  setting is useful if
   you're using a git repo that uses a self-signed  certificate.  However,
   keep  in  mind that setting this to anything other True is a considered
   insecure, and using an SSH-based transport  (if  available)  may  be  a
   better option.

   In  the  2016.11.0 release, the default config value changed from False
   to True.

      winrepo_ssl_verify: True

   Winrepo Authentication Options
   These parameters only currently apply to the  pygit2  winrepo_provider.
   Authentication  works  the same as it does in gitfs, as outlined in the
   GitFS Walkthrough, though the global configuration  options  are  named
   differently to reflect that they are for winrepo instead of gitfs.

   winrepo_user
   New in version 2015.8.0.

   Default: ''

   Along with winrepo_password, is used to authenticate to HTTPS remotes.

      winrepo_user: git

   winrepo_password
   New in version 2015.8.0.

   Default: ''

   Along with winrepo_user, is used to authenticate to HTTPS remotes. This
   parameter  is  not  required   if   the   repository   does   not   use
   authentication.

      winrepo_password: mypassword

   winrepo_insecure_auth
   New in version 2015.8.0.

   Default: False

   By  default,  Salt will not authenticate to an HTTP (non-HTTPS) remote.
   This parameter enables authentication over HTTP. Enable  this  at  your
   own risk.

      winrepo_insecure_auth: True

   winrepo_pubkey
   New in version 2015.8.0.

   Default: ''

   Along with winrepo_privkey (and optionally winrepo_passphrase), is used
   to authenticate to SSH remotes.

      winrepo_pubkey: /path/to/key.pub

   winrepo_privkey
   New in version 2015.8.0.

   Default: ''

   Along with winrepo_pubkey (and optionally winrepo_passphrase), is  used
   to authenticate to SSH remotes.

      winrepo_privkey: /path/to/key

   winrepo_passphrase
   New in version 2015.8.0.

   Default: ''

   This  parameter  is optional, required only when the SSH key being used
   to authenticate is protected by a passphrase.

      winrepo_passphrase: mypassphrase

   Configuring the Salt Minion
   The Salt system is amazingly simple and  easy  to  configure.  The  two
   components  of  the  Salt  system  each have a respective configuration
   file. The salt-master is configured via the master configuration  file,
   and the salt-minion is configured via the minion configuration file.

   SEE ALSO:
      example minion configuration file

   The Salt Minion configuration is very simple. Typically, the only value
   that needs to be set is the master value so the minion knows  where  to
   locate its master.

   By  default, the salt-minion configuration will be in /etc/salt/minion.
   A notable exception is FreeBSD, where  the  configuration  will  be  in
   /usr/local/etc/salt/minion.

   Minion Primary Configuration
   master
   Default: salt

   The hostname or ipv4 of the master.

   Default: salt

      master: salt

   The  option  can  can  also  be  set  to  a  list  of masters, enabling
   multi-master mode.

      master:
        - address1
        - address2

   Changed in version 2014.7.0: The master can be dynamically  configured.
   The  master  value  can  be  set  to  an  module function which will be
   executed and will assume that the returning value is the ip or hostname
   of  the  desired  master.  If  a  function is being specified, then the
   master_type option must be set to func, to tell  the  minion  that  the
   value is a function to be run and not a fully-qualified domain name.

      master: module.function
      master_type: func

   In  addition,  instead  of  using  multi-master mode, the minion can be
   configured to use the list of master  addresses  as  a  failover  list,
   trying  the  first  address,  then  the  second,  etc. until the minion
   successfully connects. To enable  this  behavior,  set  master_type  to
   failover:

      master:
        - address1
        - address2
      master_type: failover

   master_type
   New in version 2014.7.0.

   Default: str

   The type of the master variable. Can be str, failover, func or disable.

      master_type: failover

   If  this  option  is  set  to failover, master must be a list of master
   addresses. The minion will then try each master in the order  specified
   in the list until it successfully connects.  master_alive_interval must
   also be set, this determines how  often  the  minion  will  verify  the
   presence of the master.

      master_type: func

   If  the master needs to be dynamically assigned by executing a function
   instead of reading in the static master value, set this to  func.  This
   can  be  used  to  manage the minion's master setting from an execution
   module. By simply changing the algorithm in the module to return a  new
   master  ip/fqdn,  restart  the  minion  and  it will connect to the new
   master.

   As of version 2016.11.0 this option can  be  set  to  disable  and  the
   minion  will  never  attempt  to talk to the master. This is useful for
   running a masterless minion daemon.

      master_type: disable

   max_event_size
   New in version 2014.7.0.

   Default: 1048576

   Passing very large events can cause the minion to consume large amounts
   of  memory. This value tunes the maximum size of a message allowed onto
   the minion event bus. The value is expressed in bytes.

      max_event_size: 1048576

   master_failback
   New in version 2016.3.0.

   Default: False

   If the minion is in multi-master mode and the :conf_minion`master_type`
   configuration  option  is  set  to failover, this setting can be set to
   True to force the minion to fail back to the first master in  the  list
   if the first master is back online.

      master_failback: False

   master_failback_interval
   New in version 2016.3.0.

   Default: 0

   If  the  minion  is in multi-master mode, the :conf_minion`master_type`
   configuration is set to failover, and  the  master_failback  option  is
   enabled, the master failback interval can be set to ping the top master
   with this interval, in seconds.

      master_failback_interval: 0

   master_alive_interval
   Default: 0

   Configures how often, in seconds,  the  minion  will  verify  that  the
   current  master  is  alive  and  responding.   The  minion  will try to
   establish a connection to the next master in the list if it  finds  the
   existing one is dead.

      master_alive_interval: 30

   master_shuffle
   New in version 2014.7.0.

   Default: False

   If  master  is  a  list  of  addresses and :conf_minion`master_type` is
   failover, shuffle them before  trying  to  connect  to  distribute  the
   minions  over  all available masters. This uses Python's random.shuffle
   method.

      master_shuffle: True

   random_master
   Default: False

   If master is a list of addresses, shuffle them before trying to connect
   to  distribute  the  minions  over  all  available  masters.  This uses
   Python's random.randint method.

      random_master: True

   retry_dns
   Default: 30

   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

   master_port
   Default: 4506

   The port of the master ret server, this  needs  to  coincide  with  the
   ret_port option on the Salt master.

      master_port: 4506

   user
   Default: root

   The user to run the Salt processes

      user: root

   sudo_user
   Default: ''

   The  user  to  run  salt remote execution commands as via sudo. If this
   option is enabled then sudo will be used  to  change  the  active  user
   executing  the  remote  command.  If  enabled  the user will need to be
   allowed access via the sudoers file for the user that the  salt  minion
   is  configured  to  run  as. The most common option would be to use the
   root user. If this option is set the user option should also be set  to
   a  non-root  user. If migrating from a root minion to a non root minion
   the minion cache should be cleared and the minion  pki  directory  will
   need to be changed to the ownership of the new user.

      sudo_user: root

   pidfile
   Default: /var/run/salt-minion.pid

   The location of the daemon's process ID file

      pidfile: /var/run/salt-minion.pid

   root_dir
   Default: /

   This   directory  is  prepended  to  the  following  options:  pki_dir,
   cachedir, log_file, sock_dir, and pidfile.

      root_dir: /

   conf_file
   Default: /etc/salt/minion

   The path to the minion's configuration file.

      conf_file: /etc/salt/minion

   pki_dir
   Default: /etc/salt/pki/minion

   The directory used to store the minion's public and private keys.

      pki_dir: /etc/salt/pki/minion

   id
   Default: the system's hostname

   SEE ALSO:
      Salt Walkthrough

      The Setting up a Salt Minion section contains  detailed  information
      on how the hostname is determined.

   Explicitly  declare  the  id  for  this  minion to use. Since Salt uses
   detached ids it is possible to run multiple minions on the same machine
   but with different ids.

      id: foo.bar.com

   minion_id_caching
   New in version 0.17.2.

   Default: True

   Caches the minion id to a file when the minion's
   :minion_conf:`id`
    is  not statically defined in the minion config. This setting prevents
   potential problems when automatic minion id resolution  changes,  which
   can  cause  the  minion to lose connection with the master. To turn off
   minion id caching, set this config to False.

   For more information, please see Issue #7558 and Pull Request #8488.

      minion_id_caching: True

   append_domain
   Default: None

   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: foo.org

   cachedir
   Default: /var/cache/salt/minion

   The location for minion cache data.

   This directory may contain  sensitive  data  and  should  be  protected
   accordingly.

      cachedir: /var/cache/salt/minion

   append_minionid_config_dirs
   Default:  []  (the  empty  list)  for regular minions, ['cachedir'] for
   proxy minions.

   Append  minion_id  to  these  configuration  directories.   Helps  with
   multiple  proxies  and  minions  running  on  the same machine. Allowed
   elements in the list: pki_dir, cachedir,  extension_modules.   Normally
   not  needed  unless  running several proxies and/or minions on the same
   machine.

      append_minionid_config_dirs:
        - pki_dir
        - cachedir

   verify_env
   Default: True

   Verify and set permissions on configuration directories at startup.

      verify_env: True

   NOTE:
      When set to True the verify_env option requires WRITE access to  the
      configuration  directory (/etc/salt/). In certain situations such as
      mounting /etc/salt/ as read-only for templating this will  create  a
      stack trace when state.apply is called.

   cache_jobs
   Default: False

   The minion can locally cache the return data from jobs sent to it, this
   can be a good way to keep track of the minion  side  of  the  jobs  the
   minion has executed. By default this feature is disabled, to enable set
   cache_jobs to True.

      cache_jobs: False

   minion_pillar_cache
   Default: False

   The   minion   can   locally   cache   rendered   pillar   data   under
   cachedir/pillar.  This  allows  a  temporarily  disconnected  minion to
   access previously cached pillar data by  invoking  salt-call  with  the
   --local  and --pillar_root=:conf_minion:cachedir/pillar options. Before
   enabling this setting consider that the  rendered  pillar  may  contain
   security  sensitive data.  Appropriate access restrictions should be in
   place. By default the saved pillar data will be readable  only  by  the
   user  account  running  salt.  By  default this feature is disabled, to
   enable set minion_pillar_cache to True.

      minion_pillar_cache: False

   grains
   Default: (empty)

   SEE ALSO:
      static-custom-grains

   Statically assigns grains to the minion.

      grains:
        roles:
          - webserver
          - memcache
        deployment: datacenter4
        cabinet: 13
        cab_u: 14-15

   grains_cache
   Default: False

   The minion can locally cache grain data instead of refreshing the  data
   each time the grain is referenced. By default this feature is disabled,
   to enable set grains_cache to True.

      grains_cache: False

   grains_deep_merge
   New in version 2016.3.0.

   Default: False

   The grains can be merged, instead of  overridden,  using  this  option.
   This   allows  custom  grains  to  defined  different  subvalues  of  a
   dictionary grain. By default this feature is disabled,  to  enable  set
   grains_deep_merge to True.

      grains_deep_merge: False

   For example, with these custom grains functions:

      def custom1_k1():
          return {'custom1': {'k1': 'v1'}}

      def custom1_k2():
          return {'custom1': {'k2': 'v2'}}

   Without grains_deep_merge, the result would be:

      custom1:
        k1: v1

   With grains_deep_merge, the result will be:

      custom1:
        k1: v1
        k2: v2

   mine_enabled
   New in version 2015.8.10.

   Default: True

   Determines  whether  or  not  the salt minion should run scheduled mine
   updates.  If this is set to False then the mine  update  function  will
   not get added to the scheduler for the minion.

      mine_enabled: True

   mine_return_job
   New in version 2015.8.10.

   Default: False

   Determines  whether or not scheduled mine updates should be accompanied
   by a job return for the job cache.

      mine_return_job: False

   mine_functions
   Default: Empty

   Designate which functions should be executed at mine_interval intervals
   on  each  minion.   See  this  documentation  on the Salt Mine for more
   information.  Note these can be defined in the pillar for a  minion  as
   well.
      example minion configuration file

      mine_functions:
        test.ping: []
        network.ip_addrs:
          interface: eth0
          cidr: '10.0.0.0/8'

   sock_dir
   Default: /var/run/salt/minion

   The directory where Unix sockets will be kept.

      sock_dir: /var/run/salt/minion

   backup_mode
   Default: ''

   Backup files replaced by file.managed and file.recurse under cachedir.

      backup_mode: minion

   acceptance_wait_time
   Default: 10

   The  number of seconds to wait until attempting to re-authenticate with
   the master.

      acceptance_wait_time: 10

   acceptance_wait_time_max
   Default: 0

   The  maximum  number  of  seconds   to   wait   until   attempting   to
   re-authenticate  with  the  master.  If  set, the wait will increase by
   acceptance_wait_time seconds each iteration.

      acceptance_wait_time_max: 0

   random_reauth_delay
   Default: 10

   When the master key changes, the minion will try to re-auth  itself  to
   receive  the  new  master  key. In larger environments this can cause a
   syn-flood on the master because all minions try to re-auth immediately.
   To prevent this and have a minion wait for a random amount of time, use
   this optional parameter. The wait-time  will  be  a  random  number  of
   seconds between 0 and the defined value.

      random_reauth_delay: 60

   master_tries
   New in version 2016.3.0.

   Default: 1

   The  number  of  attempts  to connect to a master before giving up. Set
   this to -1 for unlimited attempts. This allows for  a  master  to  have
   downtime and the minion to reconnect to it later when it comes back up.
   In 'failover' mode, which is set in the master_type configuration, this
   value  is the number of attempts for each set of masters. In this mode,
   it will cycle through the list of masters for each attempt.

   master_tries is different than auth_tries because  auth_tries  attempts
   to  retry  auth  attempts with a single master. auth_tries is under the
   assumption  that  you  can  connect  to  the  master   but   not   gain
   authorization  from  it.   master_tries will still cycle through all of
   the masters in a  given  try,  so  it  is  appropriate  if  you  expect
   occasional downtime from the master(s).

      master_tries: 1

   auth_tries
   New in version 2014.7.0.

   Default: 7

   The  number  of  attempts to authenticate to a master before giving up.
   Or, more technically, the number  of  consecutive  SaltReqTimeoutErrors
   that are acceptable when trying to authenticate to the master.

      auth_tries: 7

   auth_timeout
   New in version 2014.7.0.

   Default: 60

   When  waiting for a master to accept the minion's public key, salt will
   continuously attempt to reconnect until successful. This is the timeout
   value,  in  seconds,  for  each  individual attempt. After this timeout
   expires, the minion will wait for acceptance_wait_time  seconds  before
   trying  again.   Unless your master is under unusually heavy load, this
   should be left at the default.

      auth_timeout: 60

   auth_safemode
   New in version 2014.7.0.

   Default: False

   If  authentication  fails   due   to   SaltReqTimeoutError   during   a
   ping_interval,  this setting, when set to True, will cause a sub-minion
   process to restart.

      auth_safemode: False

   recon_default
   Default: 1000

   The interval in milliseconds that the socket should wait before  trying
   to reconnect to the master (1000ms = 1 second).

      recon_default: 1000

   recon_max
   Default: 10000

   The  maximum  time a socket should wait. Each interval the time to wait
   is calculated by doubling the previous time. If recon_max  is  reached,
   it starts again at the recon_default.

   Short example:

          * reconnect 1: the socket will wait 'recon_default' milliseconds

          * reconnect 2: 'recon_default' * 2

          * reconnect 3: ('recon_default' * 2) * 2

          * reconnect 4: value from previous interval * 2

          * reconnect 5: value from previous interval * 2

          * reconnect  x:  if  value  >=  recon_max,  it starts again with
            recon_default

      recon_max: 10000

   recon_randomize
   Default: True

   Generate a random wait time on minion start. The wait time  will  be  a
   random  value  between  recon_default  and  recon_default  + recon_max.
   Having all minions reconnect with the same recon_default and  recon_max
   value  kind  of  defeats  the  purpose  of  being  able to change these
   settings. If all minions have the same values and the  setup  is  quite
   large (several thousand minions), they will still flood the master. The
   desired behavior is to  have  time-frame  within  all  minions  try  to
   reconnect.

      recon_randomize: True

   loop_interval
   Default: 1

   The loop_interval sets how long in seconds the minion will wait between
   evaluating the scheduler and running cleanup tasks. This defaults to  1
   second on the minion scheduler.

      loop_interval: 1

   pub_ret
   Default: True

   Some  installations  choose  to  start  all job returns in a cache or a
   returner and forgo sending the  results  back  to  a  master.  In  this
   workflow,  jobs  are most often executed with --async from the Salt CLI
   and then results are evaluated by examining job caches on  the  minions
   or  any  configured  returners.   WARNING:  Setting  this to False will
   disable returns back to the master.

      pub_ret: True

   return_retry_timer
   Default: 5

   The default timeout for a minion return attempt.

      return_retry_timer: 5

   return_retry_timer_max
   Default: 10

   The maximum timeout for a minion return attempt. If non-zero the minion
   return  retry  timeout  will be a random int between return_retry_timer
   and return_retry_timer_max

      return_retry_timer_max: 10

   cache_sreqs
   Default: True

   The connection to the master ret_port is kept open. When set to  False,
   the minion creates a new connection for every return to the master.

      cache_sreqs: True

   ipc_mode
   Default: ipc

   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

   tcp_pub_port
   Default: 4510

   Publish port used when ipc_mode is set to tcp.

      tcp_pub_port: 4510

   tcp_pull_port
   Default: 4511

   Pull port used when ipc_mode is set to tcp.

      tcp_pull_port: 4511

   transport
   Default: zeromq

   Changes the underlying  transport  layer.  ZeroMQ  is  the  recommended
   transport  while  additional  transport  layers  are under development.
   Supported   values   are   zeromq,   raet   (experimental),   and   tcp
   (experimental).  This  setting  has a significant impact on performance
   and should  not  be  changed  unless  you  know  what  you  are  doing!
   Transports are explained in Salt Transports.

      transport: zeromq

   syndic_finger
   Default: ''

   The key fingerprint of the higher-level master for the syndic to verify
   it is talking to the intended master.

      syndic_finger: 'ab:30:65:2a:d6:9e:20:4f:d8:b2:f3:a7:d4:65:50:10'

   proxy_host
   Default: ''

   The hostname used for HTTP proxy access.

      proxy_host: proxy.my-domain

   proxy_port
   Default: 0

   The port number used for HTTP proxy access.

      proxy_port: 31337

   proxy_username
   Default: ''

   The username used for HTTP proxy access.

      proxy_username: charon

   proxy_password
   Default: ''

   The password used for HTTP proxy access.

      proxy_password: obolus

   Minion Module Management
   disable_modules
   Default: [] (all modules are enabled by default)

   The event may occur in which the administrator desires  that  a  minion
   should not be able to execute a certain module. The sys module is built
   into the minion and cannot be disabled.

   This setting can also tune the minion. Because all modules  are  loaded
   into  system  memory,  disabling modules will lover the minion's memory
   footprint.

   Modules should be specified according to their file name on the  system
   and  not  by  their  virtual name. For example, to disable cmd, use the
   string cmdmod which corresponds to salt.modules.cmdmod.

      disable_modules:
        - test
        - solr

   disable_returners
   Default: [] (all returners are enabled by default)

   If certain returners should be disabled, this is the place

      disable_returners:
        - mongo_return

   whitelist_modules
   Default: [] (Module whitelisting is disabled.  Adding anything  to  the
   config  option  will  cause  only  the  listed  modules  to be enabled.
   Modules not in the list will not be loaded.)

   This option is the reverse of disable_modules.

   Note that this is a very large hammer and it can be quite difficult  to
   keep  the  minion  working  the way you think it should since Salt uses
   many modules internally  itself.   At  a  bare  minimum  you  need  the
   following enabled or else the minion won't start.

      whitelist_modules:
        - cmdmod
        - test
        - config

   module_dirs
   Default: []

   A list of extra directories to search for Salt modules

      module_dirs:
        - /var/lib/salt/modules

   returner_dirs
   Default: []

   A list of extra directories to search for Salt returners

      returner_dirs:
        - /var/lib/salt/returners

   states_dirs
   Default: []

   A list of extra directories to search for Salt states

      states_dirs:
        - /var/lib/salt/states

   grains_dirs
   Default: []

   A list of extra directories to search for Salt grains

      grains_dirs:
        - /var/lib/salt/grains

   render_dirs
   Default: []

   A list of extra directories to search for Salt renderers

      render_dirs:
        - /var/lib/salt/renderers

   cython_enable
   Default: False

   Set  this  value  to  true to enable auto-loading and compiling of .pyx
   modules, This setting requires that gcc and cython are installed on the
   minion.

      cython_enable: False

   enable_zip_modules
   New in version 2015.8.0.

   Default: False

   Set  this  value to true to enable loading of zip archives as extension
   modules.   This  allows  for  packing   module   code   with   specific
   dependencies  to  avoid  conflicts  and/or  having  to install specific
   modules' dependencies in system libraries.

      enable_zip_modules: False

   providers
   Default: (empty)

   A module provider can be statically overwritten  or  extended  for  the
   minion  via  the  providers  option.  This can be done on an individual
   basis in an SLS file, or globally  here  in  the  minion  config,  like
   below.

      providers:
        service: systemd

   State Management Settings
   renderer
   Default: yaml_jinja

   The default renderer used for local state executions

      renderer: yaml_jinja

   state_verbose
   Default: True

   Controls  the  verbosity  of state runs. By default, the results of all
   states are returned, but setting this value to False will cause salt to
   only display output for states that failed or states that have changes.

      state_verbose: True

   state_output
   Default: full

   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

   autoload_dynamic_modules
   Default: True

   autoload_dynamic_modules turns on automatic loading of modules found in
   the environments on the master. This is turned on by default.  To  turn
   off auto-loading modules when states run, set this value to False.

      autoload_dynamic_modules: True

   Default: 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

   environment
   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: dev

   state_top_saltenv
   This option has no default value. Set it  to  an  environment  name  to
   ensure  that  only  the  top  file  from that environment is considered
   during a highstate.

   NOTE:
      Using this value does not change the merging strategy. For instance,
      if  top_file_merging_strategy is set to merge, and state_top_saltenv
      is set to foo, then any sections for environments other than foo  in
      the  top  file  for  the  foo  environment  will  be  ignored.  With
      state_top_saltenv set to base, all states from all  environments  in
      the  base  top  file  will be applied, while all other top files are
      ignored. The only way to set state_top_saltenv  to  something  other
      than  base  and  not have the other environments in the targeted top
      file  ignored,  would  be  to   set   top_file_merging_strategy   to
      merge_all.

      state_top_saltenv: dev

   top_file_merging_strategy
   Changed in version 2016.11.0: A merge_all strategy has been added.

   Default: merge

   When  no  specific  fileserver  environment  (a.k.a.  saltenv) has been
   specified for a highstate, all environments' top files  are  inspected.
   This  config  option  determines how the SLS targets in those top files
   are handled.

   When set to merge, the base environment's top file is evaluated  first,
   followed  by  the  other  environments'  top  files.  The  first target
   expression (e.g. '*') for a given environment is  kept,  and  when  the
   same target expression is used in a different top file evaluated later,
   it is ignored.  Because base is evaluated first, it  is  authoritative.
   For  example,  if  there is a target for '*' for the foo environment in
   both the base and foo environment's top  files,  the  one  in  the  foo
   environment  would be ignored. The environments will be evaluated in no
   specific order (aside from base coming first). For greater control over
   the order in which the environments are evaluated, use env_order.

   When  set  to  same, then for each environment, only that environment's
   top file is processed, with the others being ignored. For example, only
   the   dev  environment's  top  file  will  be  processed  for  the  dev
   environment,  and  any  SLS  targets  defined  for  dev  in  the   base
   environment's (or any other environment's) top file will be ignored. If
   an environment does not have a top file, then the  top  file  from  the
   default_top config parameter will be used as a fallback.

   When  set  to merge_all, then all states in all environments in all top
   files will be applied. The order in which individual SLS files will  be
   executed  will  depend  on  the  order  in  which  the  top  files were
   evaluated, and the environments will be evaluated in no specific order.
   For  greater  control  over  the  order  in  which the environments are
   evaluated, use env_order.

      top_file_merging_strategy: same

   env_order
   Default: []

   When top_file_merging_strategy is set to merge, and no  environment  is
   specified  for  a highstate, this config option allows for the order in
   which top files are evaluated to be explicitly defined.

      env_order:
        - base
        - dev
        - qa

   default_top
   Default: base

   When top_file_merging_strategy is set to same, and  no  environment  is
   specified  for  a  highstate  (i.e.   environment  is  not  set for the
   minion), this config option specifies a fallback environment  in  which
   to look for a top file if an environment lacks one.

      default_top: dev

   snapper_states
   Default: False

   The  snapper_states  value  is  used to enable taking snapper snapshots
   before and after salt state runs. This allows  for  state  runs  to  be
   rolled back.

   For  snapper  states to function properly snapper needs to be installed
   and enabled.

      snapper_states: True

   snapper_states_config
   Default: root

   Snapper can execute based on a snapper configuration. The configuration
   needs to be set up before snapper can use it. The default configuration
   is root, this default makes snapper  run  on  SUSE  systems  using  the
   default configuration set up at install time.

      snapper_states_config: root

   File Directory Settings
   file_client
   Default: remote

   The  client defaults to looking on the master server for files, but can
   be directed to look on the minion by setting this parameter to local.

      file_client: remote

   use_master_when_local
   Default: False

   When using a local file_client, this parameter is  used  to  allow  the
   client to connect to a master for remote execution.

      use_master_when_local: False

   file_roots
   Default:

      base:
        - /srv/salt

   When  using  a  local  file_client, this parameter is used to setup the
   fileserver's environments. This parameter operates identically  to  the
   master config parameter of the same name.

      file_roots:
        base:
          - /srv/salt
        dev:
          - /srv/salt/dev/services
          - /srv/salt/dev/states
        prod:
          - /srv/salt/prod/services
          - /srv/salt/prod/states

   fileserver_followsymlinks
   New in version 2014.1.0.

   Default: True

   By   default,   the  file_server  follows  symlinks  when  walking  the
   filesystem tree.  Currently this only  applies  to  the  default  roots
   fileserver_backend.

      fileserver_followsymlinks: True

   fileserver_ignoresymlinks
   New in version 2014.1.0.

   Default: False

   If  you  do  not  want  symlinks  to  be  treated as the files they are
   pointing to, set fileserver_ignoresymlinks to True. By default this  is
   set  to  False.  When  set  to True, any detected symlink while listing
   files on the Master will not be returned to the Minion.

      fileserver_ignoresymlinks: False

   fileserver_limit_traversal
   New in version 2014.1.0.

   Default: False

   By default,  the  Salt  fileserver  recurses  fully  into  all  defined
   environments  to  attempt to find files. To limit this behavior so that
   the fileserver only traverses directories with SLS  files  and  special
   Salt directories like _modules, set fileserver_limit_traversal to True.
   This might be useful for installations where a file  root  has  a  very
   large number of files and performance is impacted.

      fileserver_limit_traversal: False

   hash_type
   Default: sha256

   The hash_type is the hash to use when discovering the hash of a file on
   the local fileserver. The default is sha256,  but  md5,  sha1,  sha224,
   sha384, and sha512 are also supported.

      hash_type: sha256

   Pillar Settings
   pillar_roots
   Default:

      base:
        - /srv/pillar

   When  using  a  local  file_client, this parameter is used to setup the
   pillar environments.

      pillar_roots:
        base:
          - /srv/pillar
        dev:
          - /srv/pillar/dev
        prod:
          - /srv/pillar/prod

   pillarenv
   Default: None

   Isolates the pillar environment on the minion side. This functions  the
   same as the environment setting, but for pillar instead of states.

      pillarenv: None

   pillar_raise_on_missing
   New in version 2015.5.0.

   Default: False

   Set  this  option  to True to force a KeyError to be raised whenever an
   attempt to retrieve a named value from pillar fails. When  this  option
   is set to False, the failed attempt returns an empty string.

   file_recv_max_size
   New in version 2014.7.0.

   Default: 100

   Set  a  hard-limit  on  the size of the files that can be pushed to the
   master.  It will be interpreted as megabytes.

      file_recv_max_size: 100

   Security Settings
   open_mode
   Default: False

   Open mode can be used to clean out the PKI key received from  the  Salt
   master,  turn on open mode, restart the minion, then turn off open mode
   and restart the minion to clean the keys.

      open_mode: False

   master_finger
   Default: ''

   Fingerprint of the master public key to validate the identity  of  your
   Salt master before the initial key exchange. The master fingerprint can
   be found by running "salt-key -F master" on the Salt master.

      master_finger: 'ba:30:65:2a:d6:9e:20:4f:d8:b2:f3:a7:d4:65:11:13'

   verify_master_pubkey_sign
   Default: False

   Enables verification of the  master-public-signature  returned  by  the
   master  in  auth-replies.  Please  see the tutorial on how to configure
   this properly Multimaster-PKI with Failover Tutorial

   New in version 2014.7.0.

      verify_master_pubkey_sign: True

   If this is set to True, master_sign_pubkey must be also set to True  in
   the master configuration file.

   master_sign_key_name
   Default: master_sign

   The  filename  without the .pub suffix of the public key that should be
   used for verifying the signature from the  master.  The  file  must  be
   located in the minion's pki directory.

   New in version 2014.7.0.

      master_sign_key_name: <filename_without_suffix>

   always_verify_signature
   Default: False

   If verify_master_pubkey_sign is enabled, the signature is only verified
   if the public-key of the master changes. If the signature should always
   be verified, this can be set to True.

   New in version 2014.7.0.

      always_verify_signature: True

   cmd_blacklist_glob
   Default: []

   If  cmd_blacklist_glob  is  enabled  then any shell command called over
   remote execution or via salt-call will  be  checked  against  the  glob
   matches  found  in  the  cmd_blacklist_glob  list and any matched shell
   command will be blocked.

   NOTE:
      This blacklist is only applied to direct executions made by the salt
      and salt-call commands. This does NOT blacklist commands called from
      states or shell commands executed from other modules.

   New in version 2016.11.0.

      cmd_blacklist_glob:
        - 'rm * '
        - 'cat /etc/* '

   cmd_whitelist_glob
   Default: []

   If cmd_whitelist_glob is enabled then any  shell  command  called  over
   remote  execution  or  via  salt-call  will be checked against the glob
   matches found in the cmd_whitelist_glob list and any shell command  NOT
   found  in  the  list will be blocked. If cmd_whitelist_glob is NOT SET,
   then all shell commands are permitted.

   NOTE:
      This whitelist is only applied to direct executions made by the salt
      and  salt-call commands. This does NOT restrict commands called from
      states or shell commands executed from other modules.

   New in version 2016.11.0.

      cmd_whitelist_glob:
        - 'ls * '
        - 'cat /etc/fstab'

   ssl
   New in version 2016.11.0.

   Default: None

   TLS/SSL  connection  options.  This  could  be  set  to  a   dictionary
   containing  arguments  corresponding  to python ssl.wrap_socket method.
   For details see Tornado and Python documentation.

   Note: to set enum arguments values like cert_reqs and  ssl_version  use
   constant   names   without   ssl   module   prefix:   CERT_REQUIRED  or
   PROTOCOL_SSLv23.

      ssl:
          keyfile: <path_to_keyfile>
          certfile: <path_to_certfile>
          ssl_version: PROTOCOL_TLSv1_2

   Thread Settings
   Default: True

   If multiprocessing is enabled when a minion receives  a  publication  a
   new   process   is   spawned  and  the  command  is  executed  therein.
   Conversely, if multiprocessing is disabled the new publication will  be
   run executed in a thread.

      multiprocessing: True

   Minion Logging Settings
   log_file
   Default: /var/log/salt/minion

   The  minion  log  can  be  sent  to a regular file, local path name, or
   network location.  See also log_file.

   Examples:

      log_file: /var/log/salt/minion

      log_file: file:///dev/log

      log_file: udp://loghost:10514

   log_level
   Default: warning

   The level of messages to send to the console. See also log_level.

      log_level: warning

   log_level_logfile
   Default: info

   The  level  of  messages  to  send  to   the   log   file.   See   also
   log_level_logfile.  When  it  is not set explicitly it will inherit the
   level set by log_level option.

      log_level_logfile: warning

   log_datefmt
   Default: %H:%M:%S

   The date and time  format  used  in  console  log  messages.  See  also
   log_datefmt.

      log_datefmt: '%H:%M:%S'

   log_datefmt_logfile
   Default: %Y-%m-%d %H:%M:%S

   The  date  and  time  format  used  in  log  file  messages.  See  also
   log_datefmt_logfile.

      log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

   log_fmt_console
   Default: [%(levelname)-8s] %(message)s

   The format of the console logging messages. See also log_fmt_console.

   NOTE:
      Log colors are enabled in  log_fmt_console  rather  than  the  color
      config since the logging system is loaded before the minion config.

      Console log colors are specified by these additional formatters:

      %(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s

      Since  it  is desirable to include the surrounding brackets, '[' and
      ']', in the coloring of the messages, these  color  formatters  also
      include  padding  as  well.   Color  LogRecord  attributes  are only
      available for console logging.

      log_fmt_console: '%(colorlevel)s %(colormsg)s'
      log_fmt_console: '[%(levelname)-8s] %(message)s'

   log_fmt_logfile
   Default:     %(asctime)s,%(msecs)03d     [%(name)-17s][%(levelname)-8s]
   %(message)s

   The format of the log file logging messages. See also log_fmt_logfile.

      log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'

   log_granular_levels
   Default: {}

   This  can be used to control logging levels more specifically. See also
   log_granular_levels.

   zmq_monitor
   Default: False

   To diagnose issues  with  minions  disconnecting  or  missing  returns,
   ZeroMQ  supports  the  use of monitor sockets to log connection events.
   This feature requires ZeroMQ 4.0 or higher.

   To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True'  and  log
   at a debug level or higher.

   A sample log event is as follows:

      [DEBUG   ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512,
      'value': 27, 'description': 'EVENT_DISCONNECTED'}

   All  events  logged  will include the string ZeroMQ event. A connection
   event should be logged as the minion starts up and  initially  connects
   to the master. If not, check for debug log level and that the necessary
   version of ZeroMQ is installed.

   failhard
   Default: False

   Set the global failhard flag. This informs all states to  stop  running
   states at the moment a single state fails

      failhard: False

   Include Configuration
   default_include
   Default: minion.d/*.conf

   The  minion can include configuration from other files. Per default the
   minion will automatically include all config files from minion.d/*.conf
   where minion.d is relative to the directory of the minion configuration
   file.

   NOTE:
      Salt creates files in the minion.d directory for its own use.  These
      files  are  prefixed with an underscore. A common example of this is
      the _schedule.conf file.

   include
   Default: not defined

   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. 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 files from a minion.d directory in the same
      # directory as the minion config file
      include: minion.d/*.conf

      # Include a single extra file into the configuration
      include: /etc/roles/webserver

      # Include several files and the minion.d directory
      include:
        - extra_config
        - minion.d/*
        - /etc/roles/webserver

   Frozen Build Update Settings
   These  options  control  how  salt.modules.saltutil.update() works with
   esky    frozen    apps.    For     more     information     look     at
   https://github.com/cloudmatrix/esky/.

   update_url
   Default: False (Update feature is disabled)

   The  url  to  use when looking for application updates. Esky depends on
   directory listings to search for new versions. A webserver  running  on
   your Master is a good starting point for most setups.

      update_url: 'http://salt.example.com/minion-updates'

   update_restart_services
   Default: [] (service restarting on update is disabled)

   A list of services to restart when the minion software is updated. This
   would typically just be a list containing the  minion's  service  name,
   but you may have other services that need to go with it.

      update_restart_services: ['salt-minion']

   winrepo_cache_expire_min
   New in version 2016.11.0.

   Default: 0

   If  set to a nonzero integer, then passing refresh=True to functions in
   the windows pkg module will not refresh the windows  repo  metadata  if
   the  age of the metadata is less than this value. The exception to this
   is pkg.refresh_db, which will always refresh the  metadata,  regardless
   of age.

      winrepo_cache_expire_min: 1800

   winrepo_cache_expire_max
   New in version 2016.11.0.

   Default: 21600

   If the windows repo metadata is older than this value, and the metadata
   is needed by a function in the windows pkg module, the metadata will be
   refreshed.

      winrepo_cache_expire_max: 86400

   Standalone Minion Windows Software Repo Settings
   IMPORTANT:
      To  use  these  config  options,  the  minion  must  be  running  in
      masterless mode (set file_client to local).

   winrepo_dir
   Changed in version 2015.8.0:  Renamed  from  win_repo  to  winrepo_dir.
   Also, this option did not have a default value until this version.

   Default: C:\salt\srv\salt\win\repo

   Location on the minion where the winrepo_remotes are checked out.

      winrepo_dir: 'D:\winrepo'

   winrepo_cachefile
   Changed   in  version  2015.8.0:  Renamed  from  win_repo_cachefile  to
   winrepo_cachefile. Also, this option did not have a default value until
   this version.

   Default: winrepo.p

   Path relative to winrepo_dir where the winrepo cache should be created.

      winrepo_cachefile: winrepo.p

   winrepo_remotes
   Changed   in   version   2015.8.0:   Renamed   from   win_gitrepos   to
   winrepo_remotes. Also, this option did not have a default  value  until
   this version.

   New in version 2015.8.0.

   Default: ['https://github.com/saltstack/salt-winrepo.git']

   List of git repositories to checkout and include in the winrepo

      winrepo_remotes:
        - https://github.com/saltstack/salt-winrepo.git

   To  specify  a specific revision of the repository, prepend a commit ID
   to the URL of the the repository:

      winrepo_remotes:
        - '<commit_id> https://github.com/saltstack/salt-winrepo.git'

   Replace <commit_id> with the SHA1 hash of a  commit  ID.  Specifying  a
   commit  ID is useful in that it allows one to revert back to a previous
   version in the event that an error is introduced in the latest revision
   of the repo.

   Configuration file examples
   * Example master configuration file

   * Example minion configuration file

   Example master configuration file
      ##### Primary configuration settings #####
      ##########################################
      # This configuration file is used to manage the behavior of the Salt Master.
      # Values that are commented out but have an empty line after the comment are
      # defaults that do not need to be set in the config. If there is no blank line
      # after the comment then the value is presented as an example and is not the
      # default.

      # Per default, the master will automatically include all config files
      # from master.d/*.conf (master.d is a directory in the same directory
      # as the main master config file).
      #default_include: master.d/*.conf

      # The address of the interface to bind to:
      #interface: 0.0.0.0

      # Whether the master should listen for IPv6 connections. If this is set to True,
      # the interface option must be adjusted, too. (For example: "interface: '::'")
      #ipv6: False

      # The tcp port used by the publisher:
      #publish_port: 4505

      # The user under which the salt master will run. Salt will update all
      # permissions to allow the specified user to run the master. The exception is
      # the job cache, which must be deleted if this user is changed. If the
      # modified files cause conflicts, set verify_env to False.
      #user: root

      # The port used by the communication interface. The ret (return) port is the
      # interface used for the file server, authentication, job returns, etc.
      #ret_port: 4506

      # Specify the location of the daemon process ID file:
      #pidfile: /var/run/salt-master.pid

      # The root directory prepended to these options: pki_dir, cachedir,
      # sock_dir, log_file, autosign_file, autoreject_file, extension_modules,
      # key_logfile, pidfile:
      #root_dir: /

      # The path to the master's configuration file.
      #conf_file: /etc/salt/master

      # Directory used to store public key data:
      #pki_dir: /etc/salt/pki/master

      # Key cache. Increases master speed for large numbers of accepted
      # keys. Available options: 'sched'. (Updates on a fixed schedule.)
      # Note that enabling this feature means that minions will not be
      # available to target for up to the length of the maintanence loop
      # which by default is 60s.
      #key_cache: ''

      # Directory to store job and cache data:
      # This directory may contain sensitive data and should be protected accordingly.
      #
      #cachedir: /var/cache/salt/master

      # Directory for custom modules. This directory can contain subdirectories for
      # each of Salt's module types such as "runners", "output", "wheel", "modules",
      # "states", "returners", etc.
      #extension_modules: <no default>

      # Directory for custom modules. This directory can contain subdirectories for
      # each of Salt's module types such as "runners", "output", "wheel", "modules",
      # "states", "returners", "engines", etc.
      # Like 'extension_modules' but can take an array of paths
      #module_dirs: <no default>
      #   - /var/cache/salt/minion/extmods

      # Verify and set permissions on configuration directories at startup:
      #verify_env: True

      # Set the number of hours to keep old job information in the job cache:
      #keep_jobs: 24

      # The number of seconds to wait when the client is requesting information
      # about running jobs.
      #gather_job_timeout: 10

      # Set the default timeout for the salt command and api. The default is 5
      # seconds.
      #timeout: 5

      # The loop_interval option controls the seconds for the master's maintenance
      # process check cycle. This process updates file server backends, cleans the
      # job cache and executes the scheduler.
      #loop_interval: 60

      # Set the default outputter used by the salt command. The default is "nested".
      #output: nested

      # 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.
      #output_file: None

      # Return minions that timeout when running commands like test.ping
      #show_timeout: True

      # By default, output is colored. To disable colored output, set the color value
      # to False.
      #color: True

      # Do not strip off the colored output from nested results and state outputs
      # (true by default).
      # strip_colors: False

      # To display a summary of the number of minions targeted, the number of
      # minions returned, and the number of minions that did not return, set the
      # cli_summary value to True. (False by default.)
      #
      #cli_summary: False

      # Set the directory used to hold unix sockets:
      #sock_dir: /var/run/salt/master

      # The master can take a while to start up when lspci and/or dmidecode is used
      # to populate the grains for the master. Enable if you want to see GPU hardware
      # data for your master.
      # enable_gpu_grains: False

      # The master maintains a job cache. While this is a great addition, it can be
      # a burden on the master for larger deployments (over 5000 minions).
      # Disabling the job cache will make previously executed jobs unavailable to
      # the jobs system and is not generally recommended.
      #job_cache: True

      # Cache minion grains and pillar data in the cachedir.
      #minion_data_cache: True

      # Store all returns in the given returner.
      # Setting this option requires that any returner-specific configuration also
      # be set. See various returners in salt/returners for details on required
      # configuration values. (See also, event_return_queue below.)
      #
      #event_return: mysql

      # On busy systems, enabling event_returns can cause a considerable load on
      # the storage system for returners. Events can be queued on the master and
      # stored in a batched fashion using a single transaction for multiple events.
      # By default, events are not queued.
      #event_return_queue: 0

      # Only return events matching tags in a whitelist, supports glob matches.
      #event_return_whitelist:
      #  - salt/master/a_tag
      #  - salt/run/*/ret

      # Store all event returns **except** the tags in a blacklist, supports globs.
      #event_return_blacklist:
      #  - salt/master/not_this_tag
      #  - salt/wheel/*/ret

      # Passing very large events can cause the minion to consume large amounts of
      # memory. This value tunes the maximum size of a message allowed onto the
      # master event bus. The value is expressed in bytes.
      #max_event_size: 1048576

      # 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.
      # ping_on_rotate: False

      # By default, the master deletes its cache of minion data when the key for that
      # minion is removed. To preserve the cache after key deletion, set
      # 'preserve_minion_cache' to True.
      #
      # WARNING: This may have security implications if compromised minions auth with
      # a previous deleted minion ID.
      #preserve_minion_cache: False

      # If max_minions is used in large installations, the master might experience
      # high-load situations because of having to check the number of connected
      # minions for every authentication. This cache provides the minion-ids of
      # all connected minions to all MWorker-processes and greatly improves the
      # performance of max_minions.
      # con_cache: False

      # The master 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 master 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 master 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

      #####  Large-scale tuning settings   #####
      ##########################################
      # Max open files
      #
      # Each minion connecting to the master uses AT LEAST one file descriptor, the
      # master subscription connection. If enough minions connect you might start
      # seeing on the console (and then salt-master crashes):
      #   Too many open files (tcp_listener.cpp:335)
      #   Aborted (core dumped)
      #
      # By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
      # max open files.
      #
      # If you wish to set a different value than the default one, uncomment and
      # configure this setting. Remember that this value CANNOT be higher than the
      # hard limit. Raising the hard limit depends on your OS and/or distribution,
      # a good way to find the limit is to search the internet. For example:
      #   raise max open files hard limit debian
      #
      #max_open_files: 100000

      # The number of worker threads to start. These threads are used to manage
      # return calls made from minions to the master. If the master seems to be
      # running slowly, increase the number of threads. This setting can not be
      # set lower than 3.
      #worker_threads: 5

      # Set the ZeroMQ high water marks
      # http://api.zeromq.org/3-2:zmq-setsockopt

      # The publisher interface ZeroMQPubServerChannel
      #pub_hwm: 1000

      # These two ZMQ HWM settings, salt_event_pub_hwm and event_publisher_pub_hwm
      # are significant for masters with thousands of minions.  When these are
      # insufficiently high it will manifest in random responses missing in the CLI
      # and even missing from the job cache.  Masters that have fast CPUs and many
      # cores with appropriate worker_threads will not need these set as high.

      # On deployment with 8,000 minions, 2.4GHz CPUs, 24 cores, 32GiB memory has
      # these settings:
      #
      #   salt_event_pub_hwm: 128000
      #   event_publisher_pub_hwm: 64000

      # ZMQ high-water-mark for SaltEvent pub socket
      #salt_event_pub_hwm: 20000

      # ZMQ high-water-mark for EventPublisher pub socket
      #event_publisher_pub_hwm: 10000

      # The master may allocate memory per-event and not
      # reclaim it.
      # To set a high-water mark for memory allocation, use
      # ipc_write_buffer to set a high-water mark for message
      # buffering.
      # Value: In bytes. Set to 'dynamic' to have Salt select
      # a value for you. Default is disabled.
      # ipc_write_buffer: 'dynamic'

      #####        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 auto_accept, this setting will automatically accept all incoming
      # public keys from the minions. Note that this is insecure.
      #auto_accept: False

      # Time in minutes that an incoming public key with a matching name found in
      # pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys
      # are removed when the master checks the minion_autosign directory.
      # 0 equals no timeout
      # autosign_timeout: 120

      # If the autosign_file is specified, incoming keys specified in the
      # autosign_file will be automatically accepted. This is insecure.  Regular
      # expressions as well as globing lines are supported.
      #autosign_file: /etc/salt/autosign.conf

      # Works like autosign_file, but instead allows you to specify minion IDs for
      # which keys will automatically be rejected. Will override both membership in
      # the autosign_file and the auto_accept setting.
      #autoreject_file: /etc/salt/autoreject.conf

      # 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. If an autosign_file
      # is specified, enabling permissive_pki_access will allow group access to that
      # specific file.
      #permissive_pki_access: False

      # Allow users on the master access to execute specific commands on minions.
      # This setting should be treated with care since it opens up execution
      # capabilities to non root users. By default this capability is completely
      # disabled.
      #publisher_acl:
      #  larry:
      #    - test.ping
      #    - network.*
      #
      # Blacklist any of the following users or modules
      #
      # This example would blacklist all non sudo users, including root from
      # running any commands. It would also blacklist any use of the "cmd"
      # module. This is completely disabled by default.
      #
      #
      # Check the list of configured users in client ACL against users on the
      # system and throw errors if they do not exist.
      #client_acl_verify: True
      #
      #publisher_acl_blacklist:
      #  users:
      #    - root
      #    - '^(?!sudo_).*$'   #  all non sudo users
      #  modules:
      #    - cmd
      #
      # WARNING: client_acl and client_acl_blacklist options are deprecated and will
      # be removed in the future releases. Use publisher_acl and
      # publisher_acl_blacklist instead.

      # Enforce publisher_acl & publisher_acl_blacklist when users have sudo
      # access to the salt command.
      #
      #sudo_acl: False

      # The external auth system uses the Salt auth modules to authenticate and
      # validate users to access areas of the Salt system.
      #external_auth:
      #  pam:
      #    fred:
      #      - test.*
      #
      # Time (in seconds) for a newly generated token to live. Default: 12 hours
      #token_expire: 43200
      #
      # Allow eauth users to specify the expiry time of the tokens they generate.
      # A boolean applies to all users or a dictionary of whitelisted eauth backends
      # and usernames may be given.
      # token_expire_user_override:
      #   pam:
      #     - fred
      #     - tom
      #   ldap:
      #     - gary
      #
      #token_expire_user_override: False

      # Allow minions to push files to the master. This is disabled by default, for
      # security purposes.
      #file_recv: False

      # Set a hard-limit on the size of the files that can be pushed to the master.
      # It will be interpreted as megabytes. Default: 100
      #file_recv_max_size: 100

      # Signature verification on messages published from the master.
      # This causes the master to cryptographically sign all messages published to its event
      # bus, and minions then verify that signature before acting on the message.
      #
      # This is False by default.
      #
      # Note that to facilitate interoperability with masters and minions that are different
      # versions, if sign_pub_messages is True but a message is received by a minion with
      # no signature, it will still be accepted, and a warning message will be logged.
      # Conversely, if sign_pub_messages is False, but a minion receives a signed
      # message it will be accepted, the signature will not be checked, and a warning message
      # will be logged. This behavior went away in Salt 2014.1.0 and these two situations
      # will cause minion to throw an exception and drop the message.
      # sign_pub_messages: 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.
      # Default is None.
      #ssl:
      #    keyfile: <path_to_keyfile>
      #    certfile: <path_to_certfile>
      #    ssl_version: PROTOCOL_TLSv1_2

      #####     Salt-SSH Configuration     #####
      ##########################################

      # Pass in an alternative location for the salt-ssh roster file
      #roster_file: /etc/salt/roster

      # The log file of the salt-ssh command:
      #ssh_log_file: /var/log/salt/ssh

      # Pass in minion option overrides that will be inserted into the SHIM for
      # salt-ssh calls. The local minion config is not used for salt-ssh. Can be
      # overridden on a per-minion basis in the roster (`minion_opts`)
      #ssh_minion_opts:
      #  gpg_keydir: /root/gpg

      # Set this to True to default to using ~/.ssh/id_rsa for salt-ssh
      # authentication with minions
      #ssh_use_home_key: False

      #####    Master Module Management    #####
      ##########################################
      # Manage how master side modules are loaded.

      # Add any additional locations to look for master runners:
      #runner_dirs: []

      # Enable Cython for master side modules:
      #cython_enable: False

      #####      State System settings     #####
      ##########################################
      # The state system uses a "top" file to tell the minions what environment to
      # use and what modules to use. The state_top file is defined relative to the
      # root of the base environment as defined in "File Server settings" below.
      #state_top: top.sls

      # The master_tops option replaces the external_nodes option by creating
      # a plugable system for the generation of external top data. The external_nodes
      # option is deprecated by the master_tops option.
      #
      # To gain the capabilities of the classic external_nodes system, use the
      # following configuration:
      # master_tops:
      #   ext_nodes: <Shell command which returns yaml>
      #
      #master_tops: {}

      # The external_nodes option allows Salt to gather data that would normally be
      # placed in a top file. The external_nodes option is the executable that will
      # return the ENC data. Remember that Salt will look for external nodes AND top
      # files and combine the results if both are enabled!
      #external_nodes: None

      # The renderer to use on the minions to render the state data
      #renderer: yaml_jinja

      # The Jinja renderer can strip extra carriage returns and whitespace
      # See http://jinja.pocoo.org/docs/api/#high-level-api
      #
      # If this is set to True the first newline after a Jinja block is removed
      # (block, not variable tag!). Defaults to False, corresponds to the Jinja
      # environment init variable "trim_blocks".
      #jinja_trim_blocks: False
      #
      # If this is set to True leading spaces and tabs are stripped from the start
      # of a line to a block. Defaults to False, corresponds to the Jinja
      # environment init variable "lstrip_blocks".
      #jinja_lstrip_blocks: False

      # The failhard option tells the minions to stop immediately after the first
      # failure detected in the state execution, defaults to False
      #failhard: 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.  If set to 'mixed', the output
      # will be terse unless a state failed, in which case that output will be full.
      # If set to 'changes', the output will be full unless the state didn't change.
      #state_output: full

      # 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.
      #
      # state_aggregate:
      #   - pkg
      #
      #state_aggregate: False

      # Send progress events as each function in a state run completes execution
      # by setting to 'True'. Progress events are in the format
      # 'salt/job/<JID>/prog/<MID>/<RUN NUM>'.
      #state_events: False

      #####      File Server settings      #####
      ##########################################
      # Salt runs a lightweight file server written in zeromq to deliver files to
      # minions. This file server is built into the master daemon and does not
      # require a dedicated port.

      # The file server works on environments passed to the master, 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
      #
      #file_roots:
      #  base:
      #    - /srv/salt
      #

      # 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
      # requested environment, set this value to 'same'.
      #top_file_merging_strategy: merge

      # To specify the order in which environments are merged, set the ordering
      # in the env_order option. Given a conflict, the last matching value will
      # win.
      #env_order: ['base', 'dev', 'prod']

      # If top_file_merging_strategy is set to 'same' and an environment does not
      # contain a top file, the top file in the environment specified by default_top
      # will be used instead.
      #default_top: base

      # The hash_type is the hash to use when discovering the hash of a file on
      # the master server. The default is md5 but sha1, sha224, sha256, sha384
      # and sha512 are also supported.
      #
      # WARNING: While md5 is also supported, do not use it due to the high chance
      # of possible collisions and thus security breach.
      #
      # Prior to changing this value, the master should be stopped and all Salt
      # caches should be cleared.
      #hash_type: sha256

      # The buffer size in the file server can be adjusted here:
      #file_buffer_size: 1048576

      # A regular expression (or a list of expressions) that will be matched
      # against the file path before syncing the modules and states to the minions.
      # This includes files affected by the file.recurse state.
      # For example, if you manage your custom modules and states in subversion
      # and don't want all the '.svn' folders and content synced to your minions,
      # you could set this to '/\.svn($|/)'. By default nothing is ignored.
      #file_ignore_regex:
      #  - '/\.svn($|/)'
      #  - '/\.git($|/)'

      # A file glob (or list of file globs) that will be matched against the file
      # path before syncing the modules and states to the minions. This is similar
      # to file_ignore_regex above, but works on globs instead of regex. By default
      # nothing is ignored.
      # file_ignore_glob:
      #  - '*.pyc'
      #  - '*/somefolder/*.bak'
      #  - '*.swp'

      # File Server Backend
      #
      # Salt supports a modular fileserver backend system, this system allows
      # the salt master to link directly to third party systems to gather and
      # manage the files available to minions. Multiple backends can be
      # configured and will be searched for the requested file in the order in which
      # they are defined here. The default setting only enables the standard backend
      # "roots" which uses the "file_roots" option.
      #fileserver_backend:
      #  - roots
      #
      # To use multiple backends list them in the order they are searched:
      #fileserver_backend:
      #  - git
      #  - roots
      #
      # Uncomment the line below if you do not want the file_server to follow
      # symlinks when walking the filesystem tree. This is set to True
      # by default. Currently this only applies to the default roots
      # fileserver_backend.
      #fileserver_followsymlinks: False
      #
      # Uncomment the line below if you do not want symlinks to be
      # treated as the files they are pointing to. By default this is set to
      # False. By uncommenting the line below, any detected symlink while listing
      # files on the Master will not be returned to the Minion.
      #fileserver_ignoresymlinks: True
      #
      # By default, the Salt fileserver recurses fully into all defined environments
      # to attempt to find files. To limit this behavior so that the fileserver only
      # traverses directories with SLS files and special Salt directories like _modules,
      # enable the option below. This might be useful for installations where a file root
      # has a very large number of files and performance is impacted. Default is False.
      # fileserver_limit_traversal: False
      #
      # The fileserver can fire events off every time the fileserver is updated,
      # these are disabled by default, but can be easily turned on by setting this
      # flag to True
      #fileserver_events: False

      # Git File Server Backend Configuration
      #
      # Optional parameter used to specify the provider to be used for gitfs. Must
      # be one of the following: pygit2, gitpython, or dulwich. If unset, then each
      # will be tried in that same order, and the first one with a compatible
      # version installed will be the provider that is used.
      #gitfs_provider: pygit2

      # Along with gitfs_password, is used to authenticate to HTTPS remotes.
      # gitfs_user: ''

      # Along with gitfs_user, is used to authenticate to HTTPS remotes.
      # This parameter is not required if the repository does not use authentication.
      #gitfs_password: ''

      # By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
      # This parameter enables authentication over HTTP. Enable this at your own risk.
      #gitfs_insecure_auth: False

      # Along with gitfs_privkey (and optionally gitfs_passphrase), is used to
      # authenticate to SSH remotes. This parameter (or its per-remote counterpart)
      # is required for SSH remotes.
      #gitfs_pubkey: ''

      # Along with gitfs_pubkey (and optionally gitfs_passphrase), is used to
      # authenticate to SSH remotes. This parameter (or its per-remote counterpart)
      # is required for SSH remotes.
      #gitfs_privkey: ''

      # This parameter is optional, required only when the SSH key being used to
      # authenticate is protected by a passphrase.
      #gitfs_passphrase: ''

      # When using the git fileserver backend at least one git remote needs to be
      # defined. The user running the salt master will need read access to the repo.
      #
      # The repos will be searched in order to find the file requested by a client
      # and the first repo to have the file will return it.
      # When using the git backend branches and tags are translated into salt
      # environments.
      # Note: file:// repos will be treated as a remote, so refs you want used must
      # exist in that repo as *local* refs.
      #gitfs_remotes:
      #  - git://github.com/saltstack/salt-states.git
      #  - file:///var/git/saltmaster
      #
      # The gitfs_ssl_verify option specifies whether to ignore ssl certificate
      # errors when contacting the gitfs backend. You might want to set this to
      # false if you're using a git backend that uses a self-signed certificate but
      # keep in mind that setting this flag to anything other than the default of True
      # is a security concern, you may want to try using the ssh transport.
      #gitfs_ssl_verify: True
      #
      # The gitfs_root option gives the ability to serve files from a subdirectory
      # within the repository. The path is defined relative to the root of the
      # repository and defaults to the repository root.
      #gitfs_root: somefolder/otherfolder
      #
      #
      #####         Pillar settings        #####
      ##########################################
      # Salt Pillars allow for the building of global data that can be made selectively
      # available to different minions based on minion grain filtering. The Salt
      # Pillar is laid out in the same fashion as the file server, with environments,
      # a top file and sls files. However, pillar data does not need to be in the
      # highstate format, and is generally just key/value pairs.
      #pillar_roots:
      #  base:
      #    - /srv/pillar
      #
      #ext_pillar:
      #  - hiera: /etc/hiera.yaml
      #  - cmd_yaml: cat /etc/salt/yaml

      # The ext_pillar_first option allows for external pillar sources to populate
      # before file system pillar. This allows for targeting file system pillar from
      # ext_pillar.
      #ext_pillar_first: False

      # The pillar_gitfs_ssl_verify option specifies whether to ignore ssl certificate
      # errors when contacting the pillar gitfs backend. You might want to set this to
      # false if you're using a git backend that uses a self-signed certificate but
      # keep in mind that setting this flag to anything other than the default of True
      # is a security concern, you may want to try using the ssh transport.
      #pillar_gitfs_ssl_verify: True

      # The pillar_opts option adds the master configuration file data to a dict in
      # the pillar called "master". This is used to set simple configurations in the
      # master config file that can then be used on minions.
      #pillar_opts: False

      # The pillar_safe_render_error option prevents the master from passing pillar
      # render errors to the minion. This is set on by default because the error could
      # contain templating data which would give that minion information it shouldn't
      # have, like a password! When set true the error message will only show:
      #   Rendering SLS 'my.sls' failed. Please see master log for details.
      #pillar_safe_render_error: True

      # The pillar_source_merging_strategy option allows you to configure merging strategy
      # between different sources. It accepts five values: none, recurse, aggregate, overwrite,
      # or smart. None will not do any merging at all. Recurse will merge recursively mapping of data.
      # Aggregate instructs aggregation of elements between sources that use the #!yamlex renderer. Overwrite
      # will overwrite elements according the order in which they are processed. This is
      # behavior of the 2014.1 branch and earlier. Smart guesses the best strategy based
      # on the "renderer" setting and is the default value.
      #pillar_source_merging_strategy: smart

      # Recursively merge lists by aggregating them instead of replacing them.
      #pillar_merge_lists: False

      # Set this option to 'True' to force a 'KeyError' to be raised whenever an
      # attempt to retrieve a named value from pillar fails. When this option is set
      # to 'False', the failed attempt returns an empty string. Default is 'False'.
      #pillar_raise_on_missing: False

      # Git External Pillar (git_pillar) Configuration Options
      #
      # Specify the provider to be used for git_pillar. Must be either pygit2 or
      # gitpython. If unset, then both will be tried in that same order, and the
      # first one with a compatible version installed will be the provider that
      # is used.
      #git_pillar_provider: pygit2

      # If the desired branch matches this value, and the environment is omitted
      # from the git_pillar configuration, then the environment for that git_pillar
      # remote will be base.
      #git_pillar_base: master

      # If the branch is omitted from a git_pillar remote, then this branch will
      # be used instead
      #git_pillar_branch: master

      # Environment to use for git_pillar remotes. This is normally derived from
      # the branch/tag (or from a per-remote env parameter), but if set this will
      # override the process of deriving the env from the branch/tag name.
      #git_pillar_env: ''

      # Path relative to the root of the repository where the git_pillar top file
      # and SLS files are located.
      #git_pillar_root: ''

      # Specifies whether or not to ignore SSL certificate errors when contacting
      # the remote repository.
      #git_pillar_ssl_verify: False

      # When set to False, if there is an update/checkout lock for a git_pillar
      # remote and the pid written to it is not running on the master, the lock
      # file will be automatically cleared and a new lock will be obtained.
      #git_pillar_global_lock: True

      # Git External Pillar Authentication Options
      #
      # Along with git_pillar_password, is used to authenticate to HTTPS remotes.
      #git_pillar_user: ''

      # Along with git_pillar_user, is used to authenticate to HTTPS remotes.
      # This parameter is not required if the repository does not use authentication.
      #git_pillar_password: ''

      # By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
      # This parameter enables authentication over HTTP.
      #git_pillar_insecure_auth: False

      # Along with git_pillar_privkey (and optionally git_pillar_passphrase),
      # is used to authenticate to SSH remotes.
      #git_pillar_pubkey: ''

      # Along with git_pillar_pubkey (and optionally git_pillar_passphrase),
      # is used to authenticate to SSH remotes.
      #git_pillar_privkey: ''

      # This parameter is optional, required only when the SSH key being used
      # to authenticate is protected by a passphrase.
      #git_pillar_passphrase: ''

      # A master can cache pillars locally to bypass the expense of having to render them
      # for each minion on every request. This feature should only be enabled in cases
      # where pillar rendering time is known to be unsatisfactory and any attendant security
      # concerns about storing pillars in a master cache have been addressed.
      #
      # When enabling this feature, be certain to read through the additional ``pillar_cache_*``
      # configuration options to fully understand the tunable parameters and their implications.
      #
      # Note: setting ``pillar_cache: True`` has no effect on targeting Minions with Pillars.
      # See https://docs.saltstack.com/en/latest/topics/targeting/pillar.html
      #pillar_cache: False

      # If and only if a master has set ``pillar_cache: True``, the cache TTL controls the amount
      # of time, in seconds, before the cache is considered invalid by a master and a fresh
      # pillar is recompiled and stored.
      #pillar_cache_ttl: 3600

      # If and only if a master has set `pillar_cache: True`, one of several storage providers
      # can be utililzed.
      #
      # `disk`: The default storage backend. This caches rendered pillars to the master cache.
      #         Rendered pillars are serialized and deserialized as msgpack structures for speed.
      #         Note that pillars are stored UNENCRYPTED. Ensure that the master cache
      #         has permissions set appropriately. (Same defaults are provided.)
      #
      # memory: [EXPERIMENTAL] An optional backend for pillar caches which uses a pure-Python
      #         in-memory data structure for maximal performance. There are several caveats,
      #         however. First, because each master worker contains its own in-memory cache,
      #         there is no guarantee of cache consistency between minion requests. This
      #         works best in situations where the pillar rarely if ever changes. Secondly,
      #         and perhaps more importantly, this means that unencrypted pillars will
      #         be accessible to any process which can examine the memory of the ``salt-master``!
      #         This may represent a substantial security risk.
      #
      #pillar_cache_backend: disk

      #####          Syndic settings       #####
      ##########################################
      # The Salt syndic is used to pass commands through a master from a higher
      # master. Using the syndic is simple. If this is a master that will have
      # syndic servers(s) below it, then set the "order_masters" setting to True.
      #
      # If this is a master that will be running a syndic daemon for passthrough, then
      # the "syndic_master" setting needs to be set to the location of the master server
      # to receive commands from.

      # Set the order_masters setting to True if this master will command lower
      # masters' syndic interfaces.
      #order_masters: False

      # If this master will be running a salt syndic daemon, syndic_master tells
      # this master where to receive commands from.
      #syndic_master: masterofmasters

      # This is the 'ret_port' of the MasterOfMaster:
      #syndic_master_port: 4506

      # PID file of the syndic daemon:
      #syndic_pidfile: /var/run/salt-syndic.pid

      # The log file of the salt-syndic daemon:
      #syndic_log_file: /var/log/salt/syndic

      # The behaviour of the multi-syndic when connection to a master of masters failed.
      # Can specify ``random`` (default) or ``ordered``. If set to ``random``, masters
      # will be iterated in random order. If ``ordered`` is specified, the configured
      # order will be used.
      #syndic_failover: random

      #####      Peer Publish settings     #####
      ##########################################
      # Salt minions can send commands to other minions, but only if the minion is
      # allowed to. By default "Peer Publication" is disabled, and when enabled it
      # is enabled for specific minions and specific commands. This allows secure
      # compartmentalization of commands based on individual minions.

      # The configuration uses regular expressions to match minions and then a list
      # of regular expressions to match functions. The following will allow the
      # minion authenticated as foo.example.com to execute functions from the test
      # and pkg modules.
      #peer:
      #  foo.example.com:
      #    - test.*
      #    - pkg.*
      #
      # This will allow all minions to execute all commands:
      #peer:
      #  .*:
      #    - .*
      #
      # This is not recommended, since it would allow anyone who gets root on any
      # single minion to instantly have root on all of the minions!

      # Minions can also be allowed to execute runners from the salt master.
      # Since executing a runner from the minion could be considered a security risk,
      # it needs to be enabled. This setting functions just like the peer setting
      # except that it opens up runners instead of module functions.
      #
      # All peer runner support is turned off by default and must be enabled before
      # using. This will enable all peer runners for all minions:
      #peer_run:
      #  .*:
      #    - .*
      #
      # To enable just the manage.up runner for the minion foo.example.com:
      #peer_run:
      #  foo.example.com:
      #    - manage.up
      #
      #
      #####         Mine settings     #####
      #####################################
      # Restrict mine.get access from minions. By default any minion has a full access
      # to get all mine data from master cache. In acl definion below, only pcre matches
      # are allowed.
      # mine_get:
      #   .*:
      #     - .*
      #
      # The example below enables minion foo.example.com to get 'network.interfaces' mine
      # data only, minions web* to get all network.* and disk.* mine data and all other
      # minions won't get any mine data.
      # mine_get:
      #   foo.example.com:
      #     - network.interfaces
      #   web.*:
      #     - network.*
      #     - disk.*

      #####         Logging settings       #####
      ##########################################
      # The location of the master log file
      # The master log can be sent to a regular file, local path name, or network
      # location. Remote logging works best when configured to use rsyslogd(8) (e.g.:
      # ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI
      # format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
      #log_file: /var/log/salt/master
      #log_file: file:///dev/log
      #log_file: udp://loghost:10514

      #log_file: /var/log/salt/master
      #key_logfile: /var/log/salt/key

      # The level of messages to send to the console.
      # One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
      #
      # The following log levels are considered INSECURE and may log sensitive data:
      # ['garbage', 'trace', 'debug']
      #
      #log_level: warning

      # The level of messages to send to the log file.
      # One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
      # If using 'log_granular_levels' this must be set to the highest desired level.
      #log_level_logfile: warning

      # The date and time format used in log messages. Allowed date/time formatting
      # can be seen here: 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 here: http://docs.python.org/library/logging.html#logrecord-attributes
      #
      # Console log colors are specified by these additional formatters:
      #
      # %(colorlevel)s
      # %(colorname)s
      # %(colorprocess)s
      # %(colormsg)s
      #
      # Since it is desirable to include the surrounding brackets, '[' and ']', in
      # the coloring of the messages, these color formatters also include padding as
      # well.  Color LogRecord attributes are only available for console logging.
      #
      #log_fmt_console: '%(colorlevel)s %(colormsg)s'
      #log_fmt_console: '[%(levelname)-8s] %(message)s'
      #
      #log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'

      # This can be used to control logging levels more specificically.  This
      # example sets the main salt library at the 'warning' level, but sets
      # 'salt.modules' to log at the 'debug' level:
      #   log_granular_levels:
      #     'salt': 'warning'
      #     'salt.modules': 'debug'
      #
      #log_granular_levels: {}

      #####         Node Groups           ######
      ##########################################
      # Node groups allow for logical groupings of minion nodes. A group consists of
      # a group name and a compound target. Nodgroups can reference other nodegroups
      # with 'N@' classifier. Ensure that you do not have circular references.
      #
      #nodegroups:
      #  group1: '[email protected],bar.domain.com,baz.domain.com or bl*.domain.com'
      #  group2: 'G@os:Debian and foo.domain.com'
      #  group3: 'G@os:Debian and N@group1'
      #  group4:
      #    - 'G@foo:bar'
      #    - 'or'
      #    - 'G@foo:baz'

      #####     Range Cluster settings     #####
      ##########################################
      # The range server (and optional port) that serves your cluster information
      # https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec
      #
      #range_server: range:80

      #####  Windows Software Repo settings #####
      ###########################################
      # Location of the repo on the master:
      #winrepo_dir_ng: '/srv/salt/win/repo-ng'
      #
      # List of git repositories to include with the local repo:
      #winrepo_remotes_ng:
      #  - 'https://github.com/saltstack/salt-winrepo-ng.git'

      #####  Windows Software Repo settings - Pre 2015.8 #####
      ########################################################
      # Legacy repo settings for pre-2015.8 Windows minions.
      #
      # Location of the repo on the master:
      #winrepo_dir: '/srv/salt/win/repo'
      #
      # Location of the master's repo cache file:
      #winrepo_mastercachefile: '/srv/salt/win/repo/winrepo.p'
      #
      # List of git repositories to include with the local repo:
      #winrepo_remotes:
      #  - 'https://github.com/saltstack/salt-winrepo.git'

      #####      Returner settings          ######
      ############################################
      # Which returner(s) will be used for minion's result:
      #return: mysql

      ######    Miscellaneous  settings     ######
      ############################################
      # Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
      #event_match_type: startswith

      # Save runner returns to the job cache
      #runner_returns: True

      # Permanently include any available Python 3rd party modules into Salt Thin
      # when they are generated for Salt-SSH or other purposes.
      # The modules should be named by the names they are actually imported inside the Python.
      # The value of the parameters can be either one module or a comma separated list of them.
      #thin_extra_mods: foo,bar

   Example minion configuration file
      ##### Primary configuration settings #####
      ##########################################
      # This configuration file is used to manage the behavior of the Salt Minion.
      # With the exception of the location of the Salt Master Server, values that are
      # commented out but have an empty line after the comment are defaults that need
      # not be set in the config. If there is no blank line after the comment, the
      # value is presented as an example and is not the default.

      # 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.
      #master: salt

      # Set http proxy information for the minion when doing requests
      #proxy_host:
      #proxy_port:
      #proxy_username:
      #proxy_password:

      # If multiple masters are specified in the 'master' setting, the default behavior
      # is to always try to connect to them in the order they are listed. If random_master is
      # set to True, the order will be randomized instead. This can be helpful in distributing
      # the load of many minions executing salt-call requests, for example, from a cron job.
      # If only one master is listed, this setting is ignored and a warning will be logged.
      # NOTE: If master_type is set to failover, use master_shuffle instead.
      #random_master: False

      # Use if master_type is set to failover.
      #master_shuffle: False

      # Minions can connect to multiple masters simultaneously (all masters
      # are "hot"), or can be configured to failover if a master becomes
      # unavailable.  Multiple hot masters are configured by setting this
      # value to "str".  Failover masters can be requested by setting
      # to "failover".  MAKE SURE TO SET master_alive_interval if you are
      # using failover.
      # Setting master_type to 'disable' let's you have a running minion (with engines and
      # beacons) without a master connection
      # master_type: str

      # Poll interval in seconds for checking if the master is still there.  Only
      # respected if master_type above is "failover". To disable the interval entirely,
      # set the value to -1. (This may be necessary on machines which have high numbers
      # of TCP connections, such as load balancers.)
      # master_alive_interval: 30

      # If the minion is in multi-master mode and the master_type configuration option
      # is set to "failover", this setting can be set to "True" to force the minion
      # to fail back to the first master in the list if the first master is back online.
      #master_failback: False

      # If the minion is in multi-master mode, the "master_type" configuration is set to
      # "failover", and the "master_failback" option is enabled, the master failback
      # interval can be set to ping the top master with this interval, in seconds.
      #master_failback_interval: 0

      # Set whether the minion should connect to the master via IPv6:
      #ipv6: False

      # 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

      # The user to run salt remote execution commands as via sudo. If this option is
      # enabled then sudo will be used to change the active user executing the remote
      # command. If enabled the user will need to be allowed access via the sudoers
      # file for the user that the salt minion is configured to run as. The most
      # common option would be to use the root user. If this option is set the user
      # option should also be set to a non-root user. If migrating from a root minion
      # to a non root minion the minion cache should be cleared and the minion pki
      # directory will need to be changed to the ownership of the new user.
      #sudo_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: /

      # The path to the minion's configuration file.
      #conf_file: /etc/salt/minion

      # The directory to store the pki information in
      #pki_dir: /etc/salt/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:

      # Cache the minion id to a file when the minion's id is not statically defined
      # in the minion config. Defaults to "True". This setting prevents potential
      # problems when automatic minion id resolution changes, which can cause the
      # minion to lose connection with the master. To turn off minion id caching,
      # set this config to ``False``.
      #minion_id_caching: True

      # 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.
      # This data may contain sensitive data and should be protected accordingly.
      #cachedir: /var/cache/salt/minion

      # Append minion_id to these directories.  Helps with
      # multiple proxies and minions running on the same machine.
      # Allowed elements in the list: pki_dir, cachedir, extension_modules
      # Normally not needed unless running several proxies and/or minions on the same machine
      # Defaults to ['cachedir'] for proxies, [] (empty list) for regular minions
      #append_minionid_config_dirs:

      # 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

      # Set the default outputter used by the salt-call command. The default is
      # "nested".
      #output: nested
      #
      # By default output is colored. To disable colored output, set the color value
      # to False.
      #color: True

      # Do not strip off the colored output from nested results and state outputs
      # (true by default).
      # strip_colors: False

      # 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 nonzero, the time between reconnection attempts will increase by
      # acceptance_wait_time seconds per iteration, up to this maximum. If this is
      # set to zero, the time between reconnection attempts will stay constant.
      #acceptance_wait_time_max: 0

      # If the master rejects the minion's public key, retry instead of exiting.
      # Rejected keys will be handled the same as waiting on acceptance.
      #rejected_retry: False

      # When the master key changes, the minion will try to re-auth itself to receive
      # the new master key. In larger environments this can cause a SYN flood on the
      # master because all minions try to re-auth immediately. To prevent this and
      # have a minion wait for a random amount of time, use this optional parameter.
      # The wait-time will be a random number of seconds between 0 and the defined value.
      #random_reauth_delay: 60

      # When waiting for a master to accept the minion's public key, salt will
      # continuously attempt to reconnect until successful. This is the timeout value,
      # in seconds, for each individual attempt. After this timeout expires, the minion
      # will wait for acceptance_wait_time seconds before trying again. Unless your master
      # is under unusually heavy load, this should be left at the default.
      #auth_timeout: 60

      # Number of consecutive SaltReqTimeoutError that are acceptable when trying to
      # authenticate.
      #auth_tries: 7

      # The number of attempts to connect to a master before giving up.
      # Set this to -1 for unlimited attempts. This allows for a master to have
      # downtime and the minion to reconnect to it later when it comes back up.
      # In 'failover' mode, it is the number of attempts for each set of masters.
      # In this mode, it will cycle through the list of masters for each attempt.
      #
      # This is different than auth_tries because auth_tries attempts to
      # retry auth attempts with a single master. auth_tries is under the
      # assumption that you can connect to the master but not gain
      # authorization from it. master_tries will still cycle through all
      # the masters in a given try, so it is appropriate if you expect
      # occasional downtime from the master(s).
      #master_tries: 1

      # If authentication fails due to SaltReqTimeoutError during a ping_interval,
      # cause sub minion process to restart.
      #auth_safemode: False

      # Ping Master to ensure connection is alive (minutes).
      #ping_interval: 0

      # To auto recover minions if master changes IP address (DDNS)
      #    auth_tries: 10
      #    auth_safemode: False
      #    ping_interval: 90
      #
      # Minions won't know master is missing until a ping fails. After the ping fail,
      # the minion will attempt authentication and likely fails out and cause a restart.
      # When the minion restarts it will resolve the masters IP and attempt to reconnect.

      # If you don't have any problems with syn-floods, don't bother with the
      # three recon_* settings described below, just leave the defaults!
      #
      # The ZeroMQ pull-socket that binds to the masters publishing interface tries
      # to reconnect immediately, if the socket is disconnected (for example if
      # the master processes are restarted). In large setups this will have all
      # minions reconnect immediately which might flood the master (the ZeroMQ-default
      # is usually a 100ms delay). To prevent this, these three recon_* settings
      # can be used.
      # recon_default: the interval in milliseconds that the socket should wait before
      #                trying to reconnect to the master (1000ms = 1 second)
      #
      # recon_max: the maximum time a socket should wait. each interval the time to wait
      #            is calculated by doubling the previous time. if recon_max is reached,
      #            it starts again at recon_default. Short example:
      #
      #            reconnect 1: the socket will wait 'recon_default' milliseconds
      #            reconnect 2: 'recon_default' * 2
      #            reconnect 3: ('recon_default' * 2) * 2
      #            reconnect 4: value from previous interval * 2
      #            reconnect 5: value from previous interval * 2
      #            reconnect x: if value >= recon_max, it starts again with recon_default
      #
      # recon_randomize: generate a random wait time on minion start. The wait time will
      #                  be a random value between recon_default and recon_default +
      #                  recon_max. Having all minions reconnect with the same recon_default
      #                  and recon_max value kind of defeats the purpose of being able to
      #                  change these settings. If all minions have the same values and your
      #                  setup is quite large (several thousand minions), they will still
      #                  flood the master. The desired behavior is to have timeframe within
      #                  all minions try to reconnect.
      #
      # Example on how to use these settings. The goal: have all minions reconnect within a
      # 60 second timeframe on a disconnect.
      # recon_default: 1000
      # recon_max: 59000
      # recon_randomize: True
      #
      # Each minion will have a randomized reconnect value between 'recon_default'
      # and 'recon_default + recon_max', which in this example means between 1000ms
      # 60000ms (or between 1 and 60 seconds). The generated random-value will be
      # doubled after each attempt to reconnect. Lets say the generated random
      # value is 11 seconds (or 11000ms).
      # reconnect 1: wait 11 seconds
      # reconnect 2: wait 22 seconds
      # reconnect 3: wait 33 seconds
      # reconnect 4: wait 44 seconds
      # reconnect 5: wait 55 seconds
      # reconnect 6: wait time is bigger than 60 seconds (recon_default + recon_max)
      # reconnect 7: wait 11 seconds
      # reconnect 8: wait 22 seconds
      # reconnect 9: wait 33 seconds
      # reconnect x: etc.
      #
      # In a setup with ~6000 thousand hosts these settings would average the reconnects
      # to about 100 per second and all hosts would be reconnected within 60 seconds.
      # recon_default: 100
      # recon_max: 5000
      # recon_randomize: False
      #
      #
      # The loop_interval sets how long in seconds the minion will wait between
      # evaluating the scheduler and running cleanup tasks.  This defaults to 1
      # second on the minion scheduler.
      #loop_interval: 1

      # Some installations choose to start all job returns in a cache or a returner
      # and forgo sending the results back to a master. In this workflow, jobs
      # are most often executed with --async from the Salt CLI and then results
      # are evaluated by examining job caches on the minions or any configured returners.
      # WARNING: Setting this to False will **disable** returns back to the master.
      #pub_ret: True

      # The grains can be merged, instead of overridden, using this option.
      # This allows custom grains to defined different subvalues of a dictionary
      # grain. By default this feature is disabled, to enable set grains_deep_merge
      # to ``True``.
      #grains_deep_merge: False

      # 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.
      #
      # If the value is set to zero, this check is disabled.
      #grains_refresh_every: 1

      # Cache grains on the minion. Default is False.
      #grains_cache: False

      # Cache rendered pillar data on the minion. Default is False.
      # This may cause 'cachedir'/pillar to contain sensitive data that should be
      # protected accordingly.
      #minion_pillar_cache: False

      # Grains cache expiration, in seconds. If the cache file is older than this
      # number of seconds then the grains cache will be dumped and fully re-populated
      # with fresh data. Defaults to 5 minutes. Will have no effect if 'grains_cache'
      # is not enabled.
      # grains_cache_expiration: 300

      # Determines whether or not the salt minion should run scheduled mine updates.
      # Defaults to "True". Set to "False" to disable the scheduled mine updates
      # (this essentially just does not add the mine update function to the minion's
      # scheduler).
      #mine_enabled: True

      # Determines whether or not scheduled mine updates should be accompanied by a job
      # return for the job cache. Defaults to "False". Set to "True" to include job
      # returns in the job cache for mine updates.
      #mine_return_job: False

      # Example functions that can be run via the mine facility
      # NO mine functions are established by default.
      # Note these can be defined in the minion's pillar as well.
      #mine_functions:
      #  test.ping: []
      #  network.ip_addrs:
      #    interface: eth0
      #    cidr: '10.0.0.0/8'

      # 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

      # Passing very large events can cause the minion to consume large amounts of
      # memory. This value tunes the maximum size of a message allowed onto the
      # minion event bus. The value is expressed in bytes.
      #max_event_size: 1048576

      # To detect failed master(s) and fire events on connect/disconnect, set
      # master_alive_interval to the number of seconds to poll the masters for
      # connection events.
      #
      #master_alive_interval: 30

      # 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

      # The syndic minion can verify that it is talking to the correct master via the
      # key fingerprint of the higher-level master with the "syndic_finger" config.
      #syndic_finger: ''
      #
      #
      #
      #####   Minion module management     #####
      ##########################################
      # Disable specific modules. This allows the admin to limit the level of
      # access the master has to the minion.  The default here is the empty list,
      # below is an example of how this needs to be formatted in the config file
      #disable_modules:
      #  - cmdmod
      #  - test
      #disable_returners: []

      # This is the reverse of disable_modules.  The default, like disable_modules, is the empty list,
      # but if this option is set to *anything* then *only* those modules will load.
      # Note that this is a very large hammer and it can be quite difficult to keep the minion working
      # the way you think it should since Salt uses many modules internally itself.  At a bare minimum
      # you need the following enabled or else the minion won't start.
      #whitelist_modules:
      #  - cmdmod
      #  - test
      #  - config

      # 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: []
      #utils_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
      #
      # Specify a max size (in bytes) for modules on import. This feature is currently
      # only supported on *nix operating systems and requires psutil.
      # modules_max_memory: -1

      #####    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
      #
      # Reload the modules prior to a highstate run.
      #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
      #
      # Isolates the pillar environment on the minion side. This functions the same
      # as the environment setting, but for pillar instead of states.
      #pillarenv: None
      #
      # Set this option to 'True' to force a 'KeyError' to be raised whenever an
      # attempt to retrieve a named value from pillar fails. When this option is set
      # to 'False', the failed attempt returns an empty string. Default is 'False'.
      #pillar_raise_on_missing: False
      #
      # 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: ''

      # 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.
      #
      # state_aggregate:
      #   - pkg
      #
      #state_aggregate: False

      #####     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". Setting a local file_client runs the
      # minion in masterless mode.
      #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
      #
      #file_roots:
      #  base:
      #    - /srv/salt

      # Uncomment the line below if you do not want the file_server to follow
      # symlinks when walking the filesystem tree. This is set to True
      # by default. Currently this only applies to the default roots
      # fileserver_backend.
      #fileserver_followsymlinks: False
      #
      # Uncomment the line below if you do not want symlinks to be
      # treated as the files they are pointing to. By default this is set to
      # False. By uncommenting the line below, any detected symlink while listing
      # files on the Master will not be returned to the Minion.
      #fileserver_ignoresymlinks: True
      #
      # By default, the Salt fileserver recurses fully into all defined environments
      # to attempt to find files. To limit this behavior so that the fileserver only
      # traverses directories with SLS files and special Salt directories like _modules,
      # enable the option below. This might be useful for installations where a file root
      # has a very large number of files and performance is negatively impacted. Default
      # is False.
      #fileserver_limit_traversal: False

      # The hash_type is the hash to use when discovering the hash of a file on
      # the local fileserver. The default is md5, but sha1, sha224, sha256, sha384
      # and sha512 are also supported.
      #
      # WARNING: While md5 and sha1 are also supported, do not use it due to the high chance
      # of possible collisions and thus security breach.
      #
      # WARNING: While md5 is also supported, do not use it due to the high chance
      # of possible collisions and thus security breach.
      #
      # Warning: Prior to changing this value, the minion should be stopped and all
      # Salt caches should be cleared.
      #hash_type: sha256

      # 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

      # Set a hard-limit on the size of the files that can be pushed to the master.
      # It will be interpreted as megabytes. Default: 100
      #file_recv_max_size: 100
      #
      #
      ######        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

      # 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

      # The state_output_profile setting changes whether profile information
      # will be shown for each state run.
      #state_output_profile: True

      # Fingerprint of the master public key to validate the identity of your Salt master
      # before the initial key exchange. The master fingerprint can be found by running
      # "salt-key -f master.pub" on the Salt master.
      #master_finger: ''

      # 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.
      # Default is None.
      #ssl:
      #    keyfile: <path_to_keyfile>
      #    certfile: <path_to_certfile>
      #    ssl_version: PROTOCOL_TLSv1_2

      ######         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
      # The minion log can be sent to a regular file, local path name, or network
      # location. Remote logging works best when configured to use rsyslogd(8) (e.g.:
      # ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI
      # format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
      #log_file: /var/log/salt/minion
      #log_file: file:///dev/log
      #log_file: udp://loghost:10514
      #
      #log_file: /var/log/salt/minion
      #key_logfile: /var/log/salt/key

      # The level of messages to send to the console.
      # One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
      #
      # The following log levels are considered INSECURE and may log sensitive data:
      # ['garbage', 'trace', 'debug']
      #
      # Default: 'warning'
      #log_level: warning

      # The level of messages to send to the log file.
      # One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
      # If using 'log_granular_levels' this must be set to the highest desired level.
      # Default: 'warning'
      #log_level_logfile:

      # The date and time format used in log messages. Allowed date/time formatting
      # can be seen here: 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 here: http://docs.python.org/library/logging.html#logrecord-attributes
      #
      # Console log colors are specified by these additional formatters:
      #
      # %(colorlevel)s
      # %(colorname)s
      # %(colorprocess)s
      # %(colormsg)s
      #
      # Since it is desirable to include the surrounding brackets, '[' and ']', in
      # the coloring of the messages, these color formatters also include padding as
      # well.  Color LogRecord attributes are only available for console logging.
      #
      #log_fmt_console: '%(colorlevel)s %(colormsg)s'
      #log_fmt_console: '[%(levelname)-8s] %(message)s'
      #
      #log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'

      # This can be used to control logging levels more specificically.  This
      # example sets the main salt library at the 'warning' level, but sets
      # 'salt.modules' to log at the 'debug' level:
      #   log_granular_levels:
      #     'salt': 'warning'
      #     'salt.modules': 'debug'
      #
      #log_granular_levels: {}

      # To diagnose issues with minions disconnecting or missing returns, ZeroMQ
      # supports the use of monitor sockets to log connection events. This
      # feature requires ZeroMQ 4.0 or higher.
      #
      # To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True' and log at a
      # debug level or higher.
      #
      # A sample log event is as follows:
      #
      # [DEBUG   ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512,
      # 'value': 27, 'description': 'EVENT_DISCONNECTED'}
      #
      # All events logged will include the string 'ZeroMQ event'. A connection event
      # should be logged as the minion starts up and initially connects to the
      # master. If not, check for debug log level and that the necessary version of
      # ZeroMQ is installed.
      #
      #zmq_monitor: False

      ######      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'

      ######      Returner  settings        ######
      ############################################
      # Which returner(s) will be used for minion's result:
      #return: mysql

      ######    Miscellaneous  settings     ######
      ############################################
      # Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
      #event_match_type: startswith

   Minion Blackout Configuration
   New in version 2016.3.0.

   Salt  supports minion blackouts. When a minion is in blackout mode, all
   remote execution commands are disabled. This allows production  minions
   to  be put "on hold", eliminating the risk of an untimely configuration
   change.

   Minion  blackouts  are   configured   via   a   special   pillar   key,
   minion_blackout.   If  this  key  is  set to True, then the minion will
   reject all incoming commands, except for saltutil.refresh_pillar.  (The
   exception is important, so minions can be brought out of blackout mode)

   Salt  also  supports an explicit whitelist of additional functions that
   will be allowed during blackout. This is configured  with  the  special
   pillar key minion_blackout_whitelist, which is formed as a list:

      minion_blackout_whitelist:
        - test.ping
        - pillar.get

   Access Control System
   New in version 0.10.4.

   Salt  maintains  a standard system used to open granular control to non
   administrative users to  execute  Salt  commands.  The  access  control
   system  has been applied to all systems used to configure access to non
   administrative control interfaces in Salt.

   These interfaces include, the peer system, the external auth system and
   the publisher acl system.

   The access control system mandated a standard configuration syntax used
   in  all  of  the  three  aforementioned  systems.   While   this   adds
   functionality  to  the  configuration in 0.10.4, it does not negate the
   old configuration.

   Now specific functions can  be  opened  up  to  specific  minions  from
   specific users in the case of external auth and publisher ACLs, and for
   specific minions in the case of the peer system.

   Publisher ACL system
   The salt publisher ACL system is a means to allow  system  users  other
   than  root  to  have  access to execute select salt commands on minions
   from the master.

   The publisher ACL system is configured in the master configuration file
   via  the  publisher_acl  configuration  option. Under the publisher_acl
   configuration option the users open to send commands are specified  and
   then  a  list of regular expressions which specify the minion functions
   which will be made available to specified user. This  configuration  is
   much like the peer configuration:

      publisher_acl:
        # Allow thatch to execute anything.
        thatch:
          - .*
        # Allow fred to use test and pkg, but only on "web*" minions.
        fred:
          - web*:
            - test.*
            - pkg.*

   WARNING: client_acl and client_acl_blacklist options are deprecated and
   will  be  removed  in  the  future  releases.  Use  publisher_acl   and
   publisher_acl_blacklist instead.

   Permission Issues
   Directories  required for publisher_acl must be modified to be readable
   by the users specified:

      chmod 755 /var/cache/salt /var/cache/salt/master /var/cache/salt/master/jobs /var/run/salt /var/run/salt/master

   NOTE:
      In addition to the changes above you will also need  to  modify  the
      permissions  of  /var/log/salt  and  the  existing  log  file  to be
      writable by the user(s) which will be running the commands.  If  you
      do  not  wish  to do this then you must disable logging or Salt will
      generate errors as it cannot write to the logs as the system users.

   If you are upgrading from earlier versions of salt you must also remove
   any existing user keys and re-start the Salt master:

      rm /var/cache/salt/.*key
      service salt-master restart

   Whitelist and Blacklist
   Salt's  authentication  systems can be configured by specifying what is
   allowed using a whitelist, or by specifying what is disallowed using  a
   blacklist.  If  you  specify a whitelist, only specified operations are
   allowed. If you specify a blacklist, all operations are allowed  except
   those that are blacklisted.

   See publisher_acl and publisher_acl_blacklist.

   External Authentication System
   Salt's  External  Authentication System (eAuth) allows for Salt to pass
   through command authorization to any  external  authentication  system,
   such as PAM or LDAP.

   NOTE:
      eAuth  using the PAM external auth system requires salt-master to be
      run  as  root  as  this  system   needs   root   access   to   check
      authentication.

   External Authentication System Configuration
   The  external  authentication  system  allows  for specific users to be
   granted access to  execute  specific  functions  on  specific  minions.
   Access  is  configured  in  the  master configuration file and uses the
   access control system:

      external_auth:
        pam:
          thatch:
            - 'web*':
              - test.*
              - network.*
          steve:
            - .*

   The above configuration allows the user thatch to execute functions  in
   the test and network modules on the minions that match the web* target.
   User steve is given unrestricted access to minion commands.

   Salt respects the current PAM configuration  in  place,  and  uses  the
   'login' service to authenticate.

   NOTE:
      The PAM module does not allow authenticating as root.

   NOTE:
      state.sls  and state.highstate will return "Failed to authenticate!"
      if the request timeout is reached.  Use  -t  flag  to  increase  the
      timeout

   To  allow  access  to  wheel  modules or runner modules the following @
   syntax must be used:

      external_auth:
        pam:
          thatch:
            - '@wheel'   # to allow access to all wheel modules
            - '@runner'  # to allow access to all runner modules
            - '@jobs'    # to allow access to the jobs runner and/or wheel module

   NOTE:
      The runner/wheel markup is different, since there are no minions  to
      scope the acl to.

   NOTE:
      Globs  will  not  match  wheel  or  runners! They must be explicitly
      allowed with @wheel or @runner.

   WARNING:
      All users that have external authentication privileges  are  allowed
      to  run  saltutil.findjob.  Be  aware  that this could inadvertently
      expose some data such as minion IDs.

   Matching syntax
   The structure of the external_auth dictionary can  take  the  following
   shapes.  Function  matches  are regular expressions; minion matches are
   compound targets.

   By user:

      external_auth:
        <eauth backend>:
          <user or group%>:
            - <regex to match function>

   By user, by minion:

      external_auth:
        <eauth backend>:
          <user or group%>:
            <minion compound target>:
              - <regex to match function>

   Groups
   To apply permissions to a group of users in an external  authentication
   system, append a % to the ID:

      external_auth:
        pam:
          admins%:
            - '*':
              - 'pkg.*'

   Limiting by function arguments
   Positional  arguments  or  keyword  arguments  to functions can also be
   whitelisted.

   New in version 2016.3.0.

      external_auth:
        pam:
          my_user:
            - '*':
              - 'my_mod.*':
                  args:
                  - 'a.*'
                  - 'b.*'
                  kwargs:
                    'kwa': 'kwa.*'
                    'kwb': 'kwb'

   The rules:

   1. The arguments values are matched as regexp.

   2. If  arguments  restrictions  are  specified  the  only  matched  are
      allowed.

   3. If an argument isn't specified any value is allowed.

   4. To  skip  an  arg  use "everything" regexp .*. I.e. if arg0 and arg2
      should be limited but arg1 and other arguments could have any  value
      use:

         args:
           - 'value0'
           - '.*'
           - 'value2'

   Usage
   The   external   authentication  system  can  then  be  used  from  the
   command-line by any user on the same system as the master with  the  -a
   option:

      $ salt -a pam web\* test.ping

   The  system  will  ask  the  user  for  the credentials required by the
   authentication system and then publish the command.

   Tokens
   With external authentication alone, the authentication credentials will
   be  required  with every call to Salt. This can be alleviated with Salt
   tokens.

   Tokens are short term authorizations and can be easily created by  just
   adding a -T option when authenticating:

      $ salt -T -a pam web\* test.ping

   Now  a  token  will  be  created that has an expiration of 12 hours (by
   default).  This token is stored in  a  file  named  salt_token  in  the
   active user's home directory.

   Once   the   token   is   created,  it  is  sent  with  all  subsequent
   communications.  User authentication does not need to be entered  again
   until the token expires.

   Token expiration time can be set in the Salt master config file.

   LDAP and Active Directory
   NOTE:
      LDAP usage requires that you have installed python-ldap.

   Salt  supports  both user and group authentication for LDAP (and Active
   Directory accessed via its LDAP interface)

   OpenLDAP and similar systems
   LDAP configuration happens in the Salt master configuration file.

   Server configuration values and their defaults:

      # Server to auth against
      auth.ldap.server: localhost

      # Port to connect via
      auth.ldap.port: 389

      # Use TLS when connecting
      auth.ldap.tls: False

      # LDAP scope level, almost always 2
      auth.ldap.scope: 2

      # Server specified in URI format
      auth.ldap.uri: ''    # Overrides .ldap.server, .ldap.port, .ldap.tls above

      # Verify server's TLS certificate
      auth.ldap.no_verify: False

      # Bind to LDAP anonymously to determine group membership
      # Active Directory does not allow anonymous binds without special configuration
      auth.ldap.anonymous: False

      # FOR TESTING ONLY, this is a VERY insecure setting.
      # If this is True, the LDAP bind password will be ignored and
      # access will be determined by group membership alone with
      # the group memberships being retrieved via anonymous bind
      auth.ldap.auth_by_group_membership_only: False

      # Require authenticating user to be part of this Organizational Unit
      # This can be blank if your LDAP schema does not use this kind of OU
      auth.ldap.groupou: 'Groups'

      # Object Class for groups.  An LDAP search will be done to find all groups of this
      # class to which the authenticating user belongs.
      auth.ldap.groupclass: 'posixGroup'

      # Unique ID attribute name for the user
      auth.ldap.accountattributename: 'memberUid'

      # These are only for Active Directory
      auth.ldap.activedirectory: False
      auth.ldap.persontype: 'person'

      auth.ldap.minion_stripdomains: []

   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  and  groups,  it
   re-authenticates as the user running the Salt commands.

   If  you  are already aware of the structure of your DNs and permissions
   in your LDAP store are set such that users can look up their own  group
   memberships,  then the first and second users can be the same.  To tell
   Salt this is the case, omit the auth.ldap.bindpw  parameter.   You  can
   template the binddn like this:

      auth.ldap.basedn: dc=saltstack,dc=com
      auth.ldap.binddn: uid={{ username }},cn=users,cn=accounts,dc=saltstack,dc=com

   Salt will use the password entered on the salt command line in place of
   the bindpw.

   To use two separate users, specify the LDAP lookup user in  the  binddn
   directive, and include a bindpw like so

      auth.ldap.binddn: uid=ldaplookup,cn=sysaccounts,cn=etc,dc=saltstack,dc=com
      auth.ldap.bindpw: mypassword

   As  mentioned before, Salt uses a filter to find the DN associated with
   a user. Salt substitutes the {{ username }} value for the username when
   querying LDAP

      auth.ldap.filter: uid={{ username }}

   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 posixGroup, and the account's 'name'  attribute,  memberUid  by
   default.

      auth.ldap.groupou: Groups

   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 can
   match the minion IDs.

      auth.ldap.minion_stripdomains: ['.external.bigcorp.com', '.internal.bigcorp.com']

   Active Directory
   Active Directory handles group membership  differently,  and  does  not
   utilize  the  groupou  configuration  variable.  AD needs the following
   options in the master config:

      auth.ldap.activedirectory: True
      auth.ldap.filter: sAMAccountName={{username}}
      auth.ldap.accountattributename: sAMAccountName
      auth.ldap.groupclass: group
      auth.ldap.persontype: person

   To determine group membership in AD, the username and password that  is
   entered  when  LDAP  is requested as the eAuth mechanism on the command
   line is used to bind to AD's LDAP interface. If  this  fails,  then  it
   doesn't  matter  what  groups  the user belongs to, he or she is denied
   access. Next, the distinguishedName of the user is looked up  with  the
   following LDAP search:

      (&(<value of auth.ldap.accountattributename>={{username}})
        (objectClass=<value of auth.ldap.persontype>)
      )

   This  should  return  a distinguishedName that we can use to filter for
   group membership.  Then the following LDAP query is executed:

      (&(member=<distinguishedName from search above>)
        (objectClass=<value of auth.ldap.groupclass>)
      )

      external_auth:
        ldap:
          test_ldap_user:
              - '*':
                  - test.ping

   To configure a LDAP group, append a % to the ID:

      external_auth:
        ldap:
          test_ldap_group%:
            - '*':
              - test.echo

   In addition, if there are a set of computers in the  directory  service
   that should be part of the eAuth definition, they can be specified like
   this:

      external_auth:
        ldap:
          test_ldap_group%:
            - ldap('DC=corp,DC=example,DC=com'):
              - test.echo

   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.

   Peer Communication
   Salt 0.9.0 introduced  the  capability  for  Salt  minions  to  publish
   commands.  The intent of this feature is not for Salt minions to act as
   independent brokers one with another, but to allow Salt minions to pass
   commands to each other.

   In  Salt  0.10.0  the  ability  to  execute runners from the master was
   added. This allows for  the  master  to  return  collective  data  from
   runners back to the minions via the peer interface.

   The  peer  interface  is  configured  through two options in the master
   configuration file. For minions to send commands from  the  master  the
   peer  configuration  is  used.  To allow for minions to execute runners
   from the master the peer_run configuration is used.

   Since this presents a viable security risk by allowing  minions  access
   to  the  master  publisher the capability is turned off by default. The
   minions can be allowed access to the master publisher on a  per  minion
   basis  based  on  regular expressions. Minions with specific ids can be
   allowed access to certain Salt modules and functions.

   Peer Configuration
   The configuration is done under the peer setting  in  the  Salt  master
   configuration file, here are a number of configuration possibilities.

   The  simplest  approach is to enable all communication for all minions,
   this is only recommended for very secure environments.

      peer:
        .*:
          - .*

   This configuration will allow minions with IDs  ending  in  example.com
   access to the test, ps, and pkg module functions.

      peer:
        .*example.com:
          - test.*
          - ps.*
          - pkg.*

   The  configuration  logic is simple, a regular expression is passed for
   matching minion ids, and then a list  of  expressions  matching  minion
   functions  is  associated  with  the  named  minion. For instance, this
   configuration will also allow minions ending with foo.org access to the
   publisher.

      peer:
        .*example.com:
          - test.*
          - ps.*
          - pkg.*
        .*foo.org:
          - test.*
          - ps.*
          - pkg.*

   NOTE:
      Functions are matched using regular expressions.

   Peer Runner Communication
   Configuration  to  allow  minions to execute runners from the master is
   done via the peer_run option on the master. The peer_run  configuration
   follows  the same logic as the peer option. The only difference is that
   access is granted to runner modules.

   To open up access to all minions to all runners:

      peer_run:
        .*:
          - .*

   This configuration will allow minions with IDs  ending  in  example.com
   access to the manage and jobs runner functions.

      peer_run:
        .*example.com:
          - manage.*
          - jobs.*

   NOTE:
      Functions are matched using regular expressions.

   Using Peer Communication
   The  publish  module  was  created  to  manage  peer communication. The
   publish module comes  with  a  number  of  functions  to  execute  peer
   communication in different ways. Currently there are three functions in
   the publish module. These examples will  show  how  to  test  the  peer
   system via the salt-call command.

   To execute test.ping on all minions:

      # salt-call publish.publish \* test.ping

   To execute the manage.up runner:

      # salt-call publish.runner manage.up

   To match minions using other matchers, use expr_form:

      # salt-call publish.publish 'webserv* and not G@os:Ubuntu' test.ping expr_form='compound'

   NOTE:
      The  expr_form  argument will be renamed to tgt_type in the Nitrogen
      release of Salt.

   When to Use Each Authentication System
   publisher_acl is useful for allowing local system  users  to  run  Salt
   commands  without giving them root access. If you can log into the Salt
   master directly, then publisher_acl allows you to use Salt without root
   privileges. If the local system is configured to authenticate against a
   remote system, like LDAP or Active Directory, then  publisher_acl  will
   interact with the remote system transparently.

   external_auth  is  useful  for  salt-api or for making your own scripts
   that use Salt's Python API. It can be used at  the  CLI  (with  the  -a
   flag)  but it is more cumbersome as there are more steps involved.  The
   only time it is useful at the CLI is  when  the  local  system  is  not
   configured  to  authenticate  against an external service but you still
   want Salt to authenticate against an external service.

   Examples
   The  access  controls  are   manifested   using   matchers   in   these
   configurations:

      publisher_acl:
        fred:
          - web\*:
            - pkg.list_pkgs
            - test.*
            - apache.*

   In  the  above  example,  fred is able to send commands only to minions
   which match the specified glob target. This can be expanded to  include
   other  functions  for  other  minions  based  on  standard targets (all
   matchers are supported except the compound one).

      external_auth:
        pam:
          dave:
            - test.ping
            - mongo\*:
              - network.*
            - log\*:
              - network.*
              - pkg.*
            - 'G@os:RedHat':
              - kmod.*
          steve:
            - .*

   The above allows for all minions to be hit by test.ping  by  dave,  and
   adds  a  few  functions that dave can execute on other minions. It also
   allows steve unrestricted access to salt commands.

   NOTE:
      Functions are matched using regular expressions.

   Job Management
   New in version 0.9.7.

   Since Salt executes jobs running on many systems, Salt needs to be able
   to manage jobs running on many systems.

   The Minion proc System
   Salt  Minions  maintain a proc directory in the Salt cachedir. The proc
   directory maintains files named after the executed job ID. These  files
   contain  the  information  about the current running jobs on the minion
   and allow for jobs to be  looked  up.  This  is  located  in  the  proc
   directory  under the cachedir, with a default configuration it is under
   /var/cache/salt/proc.

   Functions in the saltutil Module
   Salt 0.9.7 introduced a few new functions to the  saltutil  module  for
   managing jobs. These functions are:

   1. running  Returns  the data of all running jobs that are found in the
      proc directory.

   2. find_job Returns specific data about a certain job based on job id.

   3. signal_job Allows for a given jid to be sent a signal.

   4. term_job Sends a termination signal (SIGTERM,  15)  to  the  process
      controlling the specified job.

   5. kill_job Sends a kill signal (SIGKILL, 9) to the process controlling
      the specified job.

   These functions make up the core of the back end used to manage jobs at
   the minion level.

   The jobs Runner
   A  convenience  runner front end and reporting system has been added as
   well.  The jobs runner contains functions to make viewing  data  easier
   and cleaner.

   The jobs runner contains a number of functions...

   active
   The  active  function  runs saltutil.running on all minions and formats
   the return data about all running  jobs  in  a  much  more  usable  and
   compact  format.   The active function will also compare jobs that have
   returned and jobs that are still running, making it easier to see  what
   systems  have  completed  a job and what systems are still being waited
   on.

      # salt-run jobs.active

   lookup_jid
   When jobs are executed the return data is sent back to the  master  and
   cached.   By  default  it  is  cached  for  24  hours,  but this can be
   configured via the keep_jobs option in the master configuration.  Using
   the  lookup_jid  runner  will  display  the  same  return data that the
   initial job invocation with the salt command would display.

      # salt-run jobs.lookup_jid <job id number>

   list_jobs
   Before finding a historic job, it may be required to find the  job  id.
   list_jobs  will  parse the cached execution data and display all of the
   job data for jobs that have already, or partially returned.

      # salt-run jobs.list_jobs

   Scheduling Jobs
   Salt's scheduling system allows incremental executions  on  minions  or
   the  master. The schedule system exposes the execution of any execution
   function on minions or any runner on the master.

   Scheduling can be enabled by multiple methods:

   * schedule option in either the master or minion config  files.   These
     require the master or minion application to be restarted in order for
     the schedule to be implemented.

   * Minion pillar  data.   Schedule  is  implemented  by  refreshing  the
     minion's pillar data, for example by using saltutil.refresh_pillar.

   * The schedule state or schedule module

   NOTE:
      The  scheduler  executes  different  functions  on  the  master  and
      minions. When running on the master the functions  reference  runner
      functions,   when  running  on  the  minion  the  functions  specify
      execution functions.

   A scheduled run has no output on the minion unless the config is set to
   info level or higher. Refer to minion-logging-settings.

   States  are  executed  on  the  minion, as all states are. You can pass
   positional arguments and provide a YAML dict of named arguments.

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          args:
            - httpd
          kwargs:
            test: True

   This will schedule the command: state.sls httpd  test=True  every  3600
   seconds (every hour).

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          args:
            - httpd
          kwargs:
            test: True
          splay: 15

   This  will  schedule  the command: state.sls httpd test=True every 3600
   seconds (every hour) splaying the time between 0 and 15 seconds.

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          args:
            - httpd
          kwargs:
            test: True
          splay:
            start: 10
            end: 15

   This will schedule the command: state.sls httpd  test=True  every  3600
   seconds (every hour) splaying the time between 10 and 15 seconds.

   Schedule by Date and Time
   New in version 2014.7.0.

   Frequency of jobs can also be specified using date strings supported by
   the Python dateutil library. This requires the Python dateutil  library
   to be installed.

      schedule:
        job1:
          function: state.sls
          args:
            - httpd
          kwargs:
            test: True
          when: 5:00pm

   This  will  schedule  the command: state.sls httpd test=True at 5:00 PM
   minion localtime.

      schedule:
        job1:
          function: state.sls
          args:
            - httpd
          kwargs:
            test: True
          when:
            - Monday 5:00pm
            - Tuesday 3:00pm
            - Wednesday 5:00pm
            - Thursday 3:00pm
            - Friday 5:00pm

   This will schedule the command: state.sls httpd test=True at 5:00 PM on
   Monday, Wednesday and Friday, and 3:00 PM on Tuesday and Thursday.

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          args:
            - httpd
          kwargs:
            test: True
          range:
            start: 8:00am
            end: 5:00pm

   This  will  schedule  the command: state.sls httpd test=True every 3600
   seconds (every hour) between the hours of 8:00  AM  and  5:00  PM.  The
   range  parameter  must  be a dictionary with the date strings using the
   dateutil format.

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          args:
            - httpd
          kwargs:
            test: True
          range:
            invert: True
            start: 8:00am
            end: 5:00pm

   Using the invert option for  range,  this  will  schedule  the  command
   state.sls  httpd  test=True  every  3600 seconds (every hour) until the
   current time is between the hours of 8:00 AM and  5:00  PM.  The  range
   parameter must be a dictionary with the date strings using the dateutil
   format.

      schedule:
        job1:
          function: pkg.install
          kwargs:
            pkgs: [{'bar': '>1.2.3'}]
            refresh: true
          once: '2016-01-07T14:30:00'

   This will schedule the function pkg.install to be executed once at  the
   specified  time.  The schedule entry job1 will not be removed after the
   job completes, therefore use  schedule.delete  to  manually  remove  it
   afterwards.

   The  default  date  format  is  ISO  8601 but can be overridden by also
   specifying the once_fmt option, like this:

      schedule:
        job1:
          function: test.ping
          once: 2015-04-22T20:21:00
          once_fmt: '%Y-%m-%dT%H:%M:%S'

   Maximum Parallel Jobs Running
   New in version 2014.7.0.

   The scheduler also supports ensuring that there  are  no  more  than  N
   copies  of  a particular routine running. Use this for jobs that may be
   long-running and could step on  each  other  or  pile  up  in  case  of
   infrastructure outage.

   The default for maxrunning is 1.

      schedule:
        long_running_job:
          function: big_file_transfer
          jid_include: True
          maxrunning: 1

   Cron-like Schedule
   New in version 2014.7.0.

      schedule:
        job1:
          function: state.sls
          cron: '*/15 * * * *'
          args:
            - httpd
          kwargs:
            test: True

   The  scheduler  also supports scheduling jobs using a cron like format.
   This requires the Python croniter library.

   Job Data Return
   New in version 2015.5.0.

   By default, data about jobs runs from the Salt scheduler is returned to
   the  master. Setting the return_job parameter to False will prevent the
   data from being sent back to the Salt master.

      schedule:
        job1:
          function: scheduled_job_function
          return_job: False

   Job Metadata
   New in version 2015.5.0.

   It can be useful to include specific data to differentiate a  job  from
   other  jobs.  Using  the  metadata  parameter  special  values  can  be
   associated with a scheduled job. These  values  are  not  used  in  the
   execution of the job, but can be used to search for specific jobs later
   if combined with the return_job parameter. The metadata parameter  must
   be specified as a dictionary, othewise it will be ignored.

      schedule:
        job1:
          function: scheduled_job_function
          metadata:
            foo: bar

   Run on Start
   New in version 2015.5.0.

   By  default,  any job scheduled based on the startup time of the minion
   will run the scheduled job when the minion starts up. Sometimes this is
   not  the  desired  situation.  Using  the run_on_start parameter set to
   False will cause the scheduler to skip this first run  and  wait  until
   the next scheduled run:

      schedule:
        job1:
          function: state.sls
          seconds: 3600
          run_on_start: False
          args:
            - httpd
          kwargs:
            test: True

   Until and After
   New in version 2015.8.0.

      schedule:
        job1:
          function: state.sls
          seconds: 15
          until: '12/31/2015 11:59pm'
          args:
            - httpd
          kwargs:
            test: True

   Using  the  until argument, the Salt scheduler allows you to specify an
   end time for a scheduled job. If this argument is specified, jobs  will
   not run once the specified time has passed. Time should be specified in
   a format supported by the dateutil library.  This requires  the  Python
   dateutil library to be installed.

   New in version 2015.8.0.

      schedule:
        job1:
          function: state.sls
          seconds: 15
          after: '12/31/2015 11:59pm'
          args:
            - httpd
          kwargs:
            test: True

   Using  the  after argument, the Salt scheduler allows you to specify an
   start time for a scheduled job.  If this argument  is  specified,  jobs
   will  not  run  until  the  specified  time  has passed. Time should be
   specified in a format supported by the dateutil library.  This requires
   the Python dateutil library to be installed.

   Scheduling States
      schedule:
        log-loadavg:
          function: cmd.run
          seconds: 3660
          args:
            - 'logger -t salt < /proc/loadavg'
          kwargs:
            stateful: False
            shell: /bin/sh

   Scheduling Highstates
   To  set  up a highstate to run on a minion every 60 minutes set this in
   the minion config or pillar:

      schedule:
        highstate:
          function: state.highstate
          minutes: 60

   Time intervals can be specified as seconds, minutes, hours, or days.

   Scheduling Runners
   Runner executions can also be specified on the master within the master
   configuration file:

      schedule:
        run_my_orch:
          function: state.orchestrate
          hours: 6
          splay: 600
          args:
            - orchestration.my_orch

   The  above  configuration  is  analogous to running salt-run state.orch
   orchestration.my_orch every 6 hours.

   Scheduler With Returner
   The scheduler is also useful for tasks like gathering  monitoring  data
   about  a  minion, this schedule option will gather status data and send
   it to a MySQL returner database:

      schedule:
        uptime:
          function: status.uptime
          seconds: 60
          returner: mysql
        meminfo:
          function: status.meminfo
          minutes: 5
          returner: mysql

   Since  specifying  the  returner  repeatedly  can  be   tiresome,   the
   schedule_returner  option  is  available  to  specify  one or a list of
   global returners to be used by the minions when scheduling.

   Managing the Job Cache
   The Salt Master maintains a job cache of all job executions  which  can
   be  queried  via  the jobs runner. This job cache is called the Default
   Job Cache.

   Default Job Cache
   A number of options are available when configuring the job  cache.  The
   default caching system uses local storage on the Salt Master and can be
   found in the job cache directory (on Linux systems  this  is  typically
   /var/cache/salt/master/jobs).  The  default  caching system is suitable
   for most deployments as it  does  not  typically  require  any  further
   configuration or management.

   The  default job cache is a temporary cache and jobs will be stored for
   24 hours. If the default cache needs to  store  jobs  for  a  different
   period  the  time  can  be  easily  adjusted  by changing the keep_jobs
   parameter in the Salt Master configuration file. The value passed in is
   measured via hours:

      keep_jobs: 24

   Reducing the Size of the Default Job Cache
   The  Default  Job Cache can sometimes be a burden on larger deployments
   (over 5000 minions). Disabling  the  job  cache  will  make  previously
   executed  jobs  unavailable  to  the  jobs  system and is not generally
   recommended. Normally it is wise to make sure the master has access  to
   a faster IO system or a tmpfs is mounted to the jobs dir.

   However,  you  can  disable the job_cache by setting it to False in the
   Salt Master configuration file. Setting this value to False means  that
   the  Salt  Master  will  no  longer  cache  minion  returns,  but a JID
   directory and jid file for each job will still  be  created.  This  JID
   directory is necessary for checking for and preventing JID collisions.

   The    default    location    for    the    job   cache   is   in   the
   /var/cache/salt/master/jobs/ directory.

   Setting the job_cache` to False in addition to  setting  the  keep_jobs
   option  to a smaller value, such as 1, in the Salt Master configuration
   file will reduce the size of the Default Job Cache, and thus the burden
   on the Salt Master.

   NOTE:
      Changing  the  keep_jobs option sets the number of hours to keep old
      job information and defaults to 24 hours. Do not set this value to 0
      when  trying  to make the cache cleaner run more frequently, as this
      means the cache cleaner will never run.

   Additional Job Cache Options
   Many deployments may wish to use an external  database  to  maintain  a
   long  term  register  of  executed  jobs.  Salt  comes  with  two  main
   mechanisms to do this, the master job cache and the external job cache.

   See Storing Job Results in an External System.

   Storing Job Results in an External System
   After a job executes, job results are returned to the  Salt  Master  by
   each Salt Minion. These results are stored in the Default Job Cache.

   In  addition  to  the  Default  Job Cache, Salt provides two additional
   mechanisms to send job  results  to  other  systems  (databases,  local
   syslog, and others):

   * External Job Cache

   * Master Job Cache

   The  major difference between these two mechanism is from where results
   are returned (from the Salt Master or Salt Minion).

   External Job Cache - Minion-Side Returner
   When an External Job Cache is  configured,  data  is  returned  to  the
   Default  Job  Cache on the Salt Master like usual, and then results are
   also sent to an External Job Cache using a Salt returner module running
   on the Salt Minion.  [image]

   * Advantages:  Data  is  stored  without placing additional load on the
     Salt Master.

   * Disadvantages: Each Salt Minion connects to the external  job  cache,
     which  can  result  in  a large number of connections.  Also requires
     additional configuration to get returner module settings on all  Salt
     Minions.

   Master Job Cache - Master-Side Returner
   New in version 2014.7.0.

   Instead  of  configuring an External Job Cache on each Salt Minion, you
   can configure the Master Job Cache to send job results  from  the  Salt
   Master  instead.  In  this configuration, Salt Minions send data to the
   Default Job Cache as usual, and then the Salt Master sends the data  to
   the  external  system  using a Salt returner module running on the Salt
   Master.  [image]

   * Advantages: A single connection is required to the  external  system.
     This is preferred for databases and similar systems.

   * Disadvantages: Places additional load on your Salt Master.

   Configure an External or Master Job Cache
   Step 1: Understand Salt Returners
   Before  you  configure  a job cache, it is essential to understand Salt
   returner modules ("returners"). Returners are  pluggable  Salt  Modules
   that  take  the  data  returned by jobs, and then perform any necessary
   steps to send the data to an external system. For example,  a  returner
   might  establish  a  connection,  authenticate,  and  then  format  and
   transfer data.

   The Salt Returner system provides the core functionality  used  by  the
   External  and Master Job Cache systems, and the same returners are used
   by both systems.

   Salt currently provides many different returners that let  you  connect
   to  a wide variety of systems. A complete list is available at all Salt
   returners.  Each returner is configured differently, so make  sure  you
   read and follow the instructions linked from that page.

   For example, the MySQL returner requires:

   * A  database  created using provided schema (structure is available at
     MySQL returner)

   * A user created with with privileges to the database

   * Optional SSL configuration

   A simpler returner, such as Slack or HipChat, requires:

   * An API key/version

   * The target channel/room

   * The username that should be used to send the message

   Step 2: Configure the Returner
   After you understand the configuration and  have  the  external  system
   ready,  add  the  returner  configuration  settings  to the Salt Minion
   configuration file for the External Job Cache, or to  the  Salt  Master
   configuration file for the Master Job Cache.

   For example, MySQL requires:

      mysql.host: 'salt'
      mysql.user: 'salt'
      mysql.pass: 'salt'
      mysql.db: 'salt'
      mysql.port: 3306

   Slack requires:

      slack.channel: 'channel'
      slack.api_key: 'key'
      slack.from_name: 'name'

   After  you  have  configured  the  returner  and  added settings to the
   configuration file, you can enable the External or Master Job Cache.

   Step 3: Enable the External or Master Job Cache
   Configuration is a single line  that  specifies  an  already-configured
   returner to use to send all job data to an external system.

   External Job Cache
   To  enable  a returner as the External Job Cache (Minion-side), add the
   following line to the Salt Master configuration file:

      ext_job_cache: <returner>

   For example:

      ext_job_cache: mysql

   NOTE:
      When configuring an External Job Cache (Minion-side),  the  returner
      settings  are  added  to  the  Minion  configuration  file,  but the
      External Job Cache setting is configured in the Master configuration
      file.

   Master Job Cache
   To  enable  a  returner  as  a  Master Job Cache (Master-side), add the
   following line to the Salt Master configuration file:

      master_job_cache: <returner>

   For example:

      master_job_cache: mysql

   Verify that the returner  configuration  settings  are  in  the  Master
   configuration  file,  and  be  sure  to restart the salt-master service
   after you make configuration changes. (service salt-master restart).

   Logging
   The salt project tries to get the logging to work for you and  help  us
   solve any issues you might find along the way.

   If  you want to get some more information on the nitty-gritty of salt's
   logging system, please head over to the logging  development  document,
   if  all  you're after is salt's logging configurations, please continue
   reading.

   Log Levels
   The log levels are ordered numerically such that setting the log  level
   to  a  specific  level will record all log statements at that level and
   higher.  For example, setting log_level: error will log  statements  at
   error, critical, and quiet levels, although nothing should be logged at
   quiet level.

   Most of the logging levels are defined by default in  Python's  logging
   library  and  can  be found in the official Python documentation.  Salt
   uses some more levels in addition to the standard levels.   All  levels
   available in salt are shown in the table below.

   NOTE:
      Python  dependencies  used  by  salt  may  define and use additional
      logging  levels.   For  example,  the  Python  2  version   of   the
      multiprocessing  standard Python library uses the levels subwarning,
      25 and subdebug, 5.

              
              Level     Numeric value  Description         
              
              quiet     1000           Nothing  should  be 
                                       logged    at   this 
                                       level               
              
              critical  50             Critical errors     
              
              error     40             Errors              
              
              warning   30             Warnings            
              
              info      20             Normal          log 
                                       information         
              
              profile   15             Profiling           
                                       information on salt 
                                       performance         
              
              debug     10             Information  useful 
                                       for debugging  both 
                                       salt                
                                       implementations and 
                                       salt code           
              
              trace     5              More  detailed code 
                                       debugging           
                                       information         
              
              garbage   1              Even more debugging 
                                       information         
              
              all       0              Everything          
              

   Available Configuration Settings
   log_file
   The log records can be sent to a regular  file,  local  path  name,  or
   network  location.   Remote  logging  works best when configured to use
   rsyslogd(8) (e.g.: file:///dev/log), with  rsyslogd(8)  configured  for
   network    logging.     The    format    for   remote   addresses   is:
   <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>.
   Where log-facility is the symbolic name of a syslog facility as defined
   in the SysLogHandler documentation . It defaults to LOG_USER.

   Default: Dependent of the  binary  being  executed,  for  example,  for
   salt-master, /var/log/salt/master.

   Examples:

      log_file: /var/log/salt/master

      log_file: /var/log/salt/minion

      log_file: file:///dev/log

      log_file: file:///dev/log/LOG_DAEMON

      log_file: udp://loghost:10514

   log_level
   Default: warning

   The  level  of  log record messages to send to the console. One of all,
   garbage, trace, debug, profile, info, warning, error, critical, quiet.

      log_level: warning

   NOTE:
      Add log_level:  quiet  in  salt  configuration  file  to  completely
      disable  logging.  In  case  of  running  salt  in  command line use
      --log-level=quiet instead.

   log_level_logfile
   Default: info

   The level of messages to send to the log file.  One  of  all,  garbage,
   trace, debug, profile, info, warning, error, critical, quiet.

      log_level_logfile: warning

   log_datefmt
   Default: %H:%M:%S

   The  date  and  time  format  used  in  console  log  messages. Allowed
   date/time formatting can be seen on time.strftime.

      log_datefmt: '%H:%M:%S'

   log_datefmt_logfile
   Default: %Y-%m-%d %H:%M:%S

   The date and time format used in log file messages.  Allowed  date/time
   formatting can be seen on time.strftime.

      log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

   log_fmt_console
   Default: [%(levelname)-8s] %(message)s

   The format of the console logging messages. All standard python logging
   LogRecord attributes can be used.   Salt  also  provides  these  custom
   LogRecord attributes to colorize console log output:

      '%(colorlevel)s'   # log level name colorized by level
      '%(colorname)s'    # colorized module name
      '%(colorprocess)s' # colorized process number
      '%(colormsg)s'     # log message colorized by level

   NOTE:
      The  %(colorlevel)s,  %(colorname)s,  and  %(colorprocess) LogRecord
      attributes also include padding and enclosing brackets, [ and  ]  to
      match the default values of their collateral non-colorized LogRecord
      attributes.

      log_fmt_console: '[%(levelname)-8s] %(message)s'

   log_fmt_logfile
   Default:     %(asctime)s,%(msecs)03d     [%(name)-17s][%(levelname)-8s]
   %(message)s

   The  format  of  the  log  file  logging  messages. All standard python
   logging LogRecord attributes can be used.   Salt  also  provides  these
   custom LogRecord attributes that include padding and enclosing brackets
   [ and ]:

      '%(bracketlevel)s'   # equivalent to [%(levelname)-8s]
      '%(bracketname)s'    # equivalent to [%(name)-17s]
      '%(bracketprocess)s' # equivalent to [%(process)5s]

      log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'

   log_granular_levels
   Default: {}

   This can be used to control  logging  levels  more  specifically.   The
   example  sets  the  main  salt library at the 'warning' level, but sets
   salt.modules to log at the debug level:

      log_granular_levels:
        'salt': 'warning'
        'salt.modules': 'debug'

   External Logging Handlers
   Besides the internal logging handlers used  by  salt,  there  are  some
   external which can be used, see the external logging handlers document.

   Salt File Server
   Salt comes with a simple file server suitable for distributing files to
   the Salt minions. The file server is a stateless ZeroMQ server that  is
   built into the Salt master.

   The  main intent of the Salt file server is to present files for use in
   the Salt state system. With this said, the Salt file server can be used
   for any general file transfer from the master to the minions.

   File Server Backends
   In  Salt  0.12.0,  the  modular fileserver was introduced. This feature
   added the ability for the  Salt  Master  to  integrate  different  file
   server backends. File server backends allow the Salt file server to act
   as a transparent bridge to external resources. A good example  of  this
   is  the  git backend, which allows Salt to serve files sourced from one
   or more git repositories, but there are several others as  well.  Click
   here for a full list of Salt's fileserver backends.

   Enabling a Fileserver Backend
   Fileserver backends can be enabled with the fileserver_backend option.

      fileserver_backend:
        - git

   See the documentation for each backend to find the correct value to add
   to fileserver_backend in order to enable them.

   Using Multiple Backends
   If fileserver_backend is not defined in the Master  config  file,  Salt
   will  use the roots backend, but the fileserver_backend option supports
   multiple backends. When more than one backend is in use, the files from
   the  enabled backends are merged into a single virtual filesystem. When
   a file is requested, the backends will be searched in  order  for  that
   file,  and the first backend to match will be the one which returns the
   file.

      fileserver_backend:
        - roots
        - git

   With this configuration, the environments  and  files  defined  in  the
   file_roots  parameter  will  be  searched first, and if the file is not
   found then the  git  repositories  defined  in  gitfs_remotes  will  be
   searched.

   Defining Environments
   Just  as  the order of the values in fileserver_backend matters, so too
   does the  order  in  which  different  sources  are  defined  within  a
   fileserver   environment.  For  example,  given  the  below  file_roots
   configuration, if both /srv/salt/dev/foo.txt and /srv/salt/prod/foo.txt
   exist   on   the   Master,   then   salt://foo.txt   would   point   to
   /srv/salt/dev/foo.txt in the dev environment, but  it  would  point  to
   /srv/salt/prod/foo.txt in the base environment.

      file_roots:
        base:
          - /srv/salt/prod
        qa:
          - /srv/salt/qa
          - /srv/salt/prod
        dev:
          - /srv/salt/dev
          - /srv/salt/qa
          - /srv/salt/prod

   Similarly,  when  using  the  git backend, if both repositories defined
   below have a hotfix23 branch/tag, and both of  them  also  contain  the
   file  bar.txt  in  the  root of the repository at that branch/tag, then
   salt://bar.txt in the hotfix23 environment would  be  served  from  the
   first repository.

      gitfs_remotes:
        - https://mydomain.tld/repos/first.git
        - https://mydomain.tld/repos/second.git

   NOTE:
      Environments  map  differently  based on the fileserver backend. For
      instance, the mappings are  explicitly  defined  in  roots  backend,
      while  in  the  VCS  backends  (git,  hg,  svn) the environments are
      created from branches/tags/bookmarks/etc. For  the  minion  backend,
      the files are all in a single environment, which is specified by the
      minionfs_env option.

      See  the  documentation  for  each  backend  for  a  more   detailed
      explanation of how environments are mapped.

   Dynamic Module Distribution
   New in version 0.9.5.

   Custom  Salt  execution, state, and other modules can be distributed to
   Salt minions using the Salt file server.

   Under the root of any environment defined via the file_roots option  on
   the  master  server directories corresponding to the type of module can
   be used.

   The directories are prepended with an underscore:

   * _beacons

   * _engines

   * _grains

   * _modules

   * _output

   * _proxy

   * _renderers

   * _returners

   * _states

   * _utils

   The contents of these directories need to be synced over to the minions
   after  Python  modules have been created in them. There are a number of
   ways to sync the modules.

   Sync Via States
   The minion configuration contains  an  option  autoload_dynamic_modules
   which  defaults to True. This option makes the state system refresh all
   dynamic modules when states are  run.  To  disable  this  behavior  set
   autoload_dynamic_modules to False in the minion config.

   When  dynamic modules are autoloaded via states, modules only pertinent
   to the environments matched in the master's top file are downloaded.

   This is important to remember, because modules can be  manually  loaded
   from any specific environment that environment specific modules will be
   loaded when a state run is executed.

   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  module  function
   saltutil.sync_all will sync all module types over to a minion. For more
   information see: salt.modules.saltutil

   Requesting Files from Specific Environments
   The  Salt  fileserver  supports multiple environments, allowing for SLS
   files and other files to be isolated for better organization.

   For the default backend (called roots), environments are defined  using
   the  roots  option.  Other backends (such as gitfs) define environments
   in their own ways. For a list of  available  fileserver  backends,  see
   here.

   Querystring Syntax
   Any  salt://  file  URL  can specify its fileserver environment using a
   querystring syntax, like so:

      salt://path/to/file?saltenv=foo

   In Reactor configurations, this method must be used to pull files  from
   an environment other than base.

   In States
   Minions  can  be instructed which environment to use both globally, and
   for a single state, and multiple methods for each are available:

   Globally
   A minion can be pinned to an environment using the  environment  option
   in the minion config file.

   Additionally,  the  environment  can  be  set  for a single call to the
   following functions:

   * state.apply

   * state.highstate

   * state.sls

   * state.top

   NOTE:
      When the saltenv parameter is used  to  trigger  a  highstate  using
      either   state.apply  or  state.highstate,  only  states  from  that
      environment will be applied.

   On a Per-State Basis
   Within an individual state,  there  are  two  ways  of  specifying  the
   environment.  The first is to add a saltenv argument to the state. This
   example will pull the file from the config environment:

      /etc/foo/bar.conf:
        file.managed:
          - source: salt://foo/bar.conf
          - user: foo
          - mode: 600
          - saltenv: config

   Another way of doing the same thing is to use  the  querystring  syntax
   described above:

      /etc/foo/bar.conf:
        file.managed:
          - source: salt://foo/bar.conf?saltenv=config
          - user: foo
          - mode: 600

   NOTE:
      Specifying the environment using either of the above methods is only
      necessary in cases where a  state  from  one  environment  needs  to
      access  files  from  another environment. If the SLS file containing
      this state was in the config environment, then it would look in that
      environment by default.

   File Server Configuration
   The  Salt  file  server  is  a  high performance file server written in
   ZeroMQ. It manages large files quickly and with  little  overhead,  and
   has  been  optimized  to  handle  small files in an extremely efficient
   manner.

   The Salt file server is an environment aware file  server.  This  means
   that  files  can be allocated within many root directories and accessed
   by specifying both the file path and the  environment  to  search.  The
   individual  environments  can  span  across multiple directory roots to
   create overlays and to allow for files to be organized in many flexible
   ways.

   Environments
   The  Salt  file server defaults to the mandatory base environment. This
   environment MUST be defined and is  used  to  download  files  when  no
   environment is specified.

   Environments  allow  for  files and sls data to be logically separated,
   but environments are not isolated from  each  other.  This  allows  for
   logical  isolation of environments by the engineer using Salt, but also
   allows for information to be used in multiple environments.

   Directory Overlay
   The environment setting is a list of directories to publish files from.
   These  directories are searched in order to find the specified file and
   the first file found is returned.

   This means that directory data is prioritized based  on  the  order  in
   which they are listed. In the case of this file_roots configuration:

      file_roots:
        base:
          - /srv/salt/base
          - /srv/salt/failover

   If  a  file's  URI is salt://httpd/httpd.conf, it will first search for
   the file at /srv/salt/base/httpd/httpd.conf. If the file is found there
   it   will   be   returned.  If  the  file  is  not  found  there,  then
   /srv/salt/failover/httpd/httpd.conf will be used for the source.

   This allows for directories to be overlaid and prioritized based on the
   order they are defined in the configuration.

   It  is  also  possible  to  have  file_roots  which  supports  multiple
   environments:

      file_roots:
        base:
          - /srv/salt/base
        dev:
          - /srv/salt/dev
          - /srv/salt/base
        prod:
          - /srv/salt/prod
          - /srv/salt/base

   This example ensures that each environment will  check  the  associated
   environment  directory  for  files first. If a file is not found in the
   appropriate directory, the  system  will  default  to  using  the  base
   directory.

   Local File Server
   New in version 0.9.8.

   The  file  server  can  be  rerouted  to  run  from the minion. This is
   primarily to enable running Salt states without a Salt master.  To  use
   the  local  file  server  interface,  copy  the file server data to the
   minion and set the file_roots option on the  minion  to  point  to  the
   directories  copied from the master.  Once the minion file_roots option
   has been set, change the file_client option to local to make sure  that
   the local file server interface is used.

   The cp Module
   The cp module is the home of minion side file server operations. The cp
   module is used by the Salt state system, salt-cp, and can  be  used  to
   distribute files presented by the Salt file server.

   Escaping Special Characters
   The  salt://  url  format  can  potentially contain a query string, for
   example   salt://dir/file.txt?saltenv=base.   You   can   prevent   the
   fileclient/fileserver  from  interpreting  ?  as the initial token of a
   query string by referencing the file with salt://| rather than salt://.

      /etc/marathon/conf/?checkpoint:
        file.managed:
          - source: salt://|hw/config/?checkpoint
          - makedirs: True

   Environments
   Since the file server is made to work with the Salt  state  system,  it
   supports  environments.  The  environments  are  defined  in the master
   config file and when referencing an environment the file specified will
   be based on the root directory of the environment.

   get_file
   The  cp.get_file  function can be used on the minion to download a file
   from the master, the syntax looks like this:

      # salt '*' cp.get_file salt://vimrc /etc/vimrc

   This will instruct all Salt minions to download the vimrc file and copy
   it to /etc/vimrc

   Template  rendering  can  be enabled on both the source and destination
   file names like so:

      # salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja

   This example would instruct all Salt minions to download the vimrc from
   a  directory  with  the  same  name  as  their  OS grain and copy it to
   /etc/vimrc

   For  larger  files,  the  cp.get_file   module   also   supports   gzip
   compression.   Because  gzip is CPU-intensive, this should only be used
   in  scenarios  where  the  compression  ratio  is   very   high   (e.g.
   pretty-printed JSON or YAML files).

   To  use  compression,  use  the  gzip  named argument. Valid values are
   integers from 1 to 9, where 1 is the lightest  compression  and  9  the
   heaviest.  In  other  words,  1  uses  the least CPU on the master (and
   minion), while 9 uses the most.

      # salt '*' cp.get_file salt://vimrc /etc/vimrc gzip=5

   Finally,  note  that  by  default  cp.get_file  does  not  create   new
   destination  directories if they do not exist.  To change this, use the
   makedirs argument:

      # salt '*' cp.get_file salt://vimrc /etc/vim/vimrc makedirs=True

   In this example, /etc/vim/ would be created if it didn't already exist.

   get_dir
   The cp.get_dir function can be used on the minion to download an entire
   directory from the master.  The syntax is very similar to get_file:

      # salt '*' cp.get_dir salt://etc/apache2 /etc

   cp.get_dir  supports  template rendering and gzip compression arguments
   just like get_file:

      # salt '*' cp.get_dir salt://etc/{{pillar.webserver}} /etc gzip=5 template=jinja

   File Server Client Instance
   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 Module
   The salt/fileclient.py module is used to set up the communication  from
   the  minion  to  the  master. When creating a client instance using the
   fileclient module, the minion configuration needs to be passed in. When
   using  the  fileclient  module from within a minion module the built in
   __opts__ data can be passed:

      import salt.minion
      import salt.fileclient

      def get_file(path, dest, saltenv='base'):
          '''
          Used to get a single file from the Salt master

          CLI Example:
          salt '*' cp.get_file salt://vimrc /etc/vimrc
          '''
          # Get the fileclient object
          client = salt.fileclient.get_file_client(__opts__)
          # Call get_file
          return client.get_file(path, dest, False, saltenv)

   Creating a fileclient instance outside of a  minion  module  where  the
   __opts__ data is not available, it needs to be generated:

      import salt.fileclient
      import salt.config

      def get_file(path, dest, saltenv='base'):
          '''
          Used to get a single file from the Salt master
          '''
          # Get the configuration data
          opts = salt.config.minion_config('/etc/salt/minion')
          # Get the fileclient object
          client = salt.fileclient.get_file_client(opts)
          # Call get_file
          return client.get_file(path, dest, False, saltenv)

   Git Fileserver Backend Walkthrough
   NOTE:
      This  walkthrough  assumes  basic  knowledge  of  Salt. To get up to
      speed, check out the Salt Walkthrough.

   The gitfs backend allows Salt to serve files from git repositories.  It
   can  be  enabled  by  adding  git  to  the fileserver_backend list, and
   configuring one or more repositories in gitfs_remotes.

   Branches and tags become Salt fileserver environments.

   NOTE:
      Branching and tagging can result in a lot of potentially-conflicting
      top   files,   for   this   reason   it   may   be   useful  to  set
      top_file_merging_strategy to same in the minions'  config  files  if
      the top files are being managed in a GitFS repo.

   Installing Dependencies
   Beginning  with version 2014.7.0, both pygit2 and Dulwich are supported
   as alternatives to GitPython. The desired provider  can  be  configured
   using the gitfs_provider parameter in the master config file.

   If  gitfs_provider is not configured, then Salt will prefer pygit2 if a
   suitable version is available, followed by GitPython and Dulwich.

   NOTE:
      It is recommended to always run the most recent version of  any  the
      below  dependencies.  Certain features of gitfs may not be available
      without the most recent version of the chosen library.

   pygit2
   The minimum supported version of pygit2  is  0.20.3.  Availability  for
   this  version  of pygit2 is still limited, though the SaltStack team is
   working to get compatible versions available for as many  platforms  as
   possible.

   For  the Fedora/EPEL versions which have a new enough version packaged,
   the following command would be used to install pygit2:

      # yum install python-pygit2

   Provided a valid version is packaged for Debian/Ubuntu  (which  is  not
   currently  the  case),  the  package  name  would  be the same, and the
   following command would be used to install it:

      # apt-get install python-pygit2

   If pygit2 is not packaged for the  platform  on  which  the  Master  is
   running, the pygit2 website has installation instructions here. Keep in
   mind however that following these instructions will install libgit2 and
   pygit2  without  system  packages.  Additionally, keep in mind that SSH
   authentication in pygit2  requires  libssh2  (not  libssh)  development
   libraries  to  be present before libgit2 is built. On some Debian-based
   distros pkg-config is also required to link libgit2 with libssh2.

   Additionally, version 0.21.0  of  pygit2  introduced  a  dependency  on
   python-cffi,  which  in  turn  depends  on  newer  releases  of libffi.
   Upgrading libffi is not advisable as several other applications  depend
   on  it, so on older LTS linux releases pygit2 0.20.3 and libgit2 0.20.0
   is the recommended combination.  While these are not  packaged  in  the
   official  repositories  for  Debian  and  Ubuntu, SaltStack is actively
   working on adding packages for these to our repositories. The  progress
   of this effort can be tracked here.

   WARNING:
      pygit2     is    actively    developed    and    frequently    makes
      non-backwards-compatible API changes, even in minor releases. It  is
      not uncommon for pygit2 upgrades to result in errors in Salt. Please
      take care when upgrading pygit2, and  pay  close  attention  to  the
      changelog,  keeping  an  eye  out  for  API  changes.  Errors can be
      reported on the SaltStack issue tracker.

   GitPython
   GitPython 0.3.0 or newer is required to use GitPython  for  gitfs.  For
   RHEL-based  Linux  distros,  a compatible version is available in EPEL,
   and can be easily installed on the master using yum:

      # yum install GitPython

   Ubuntu 14.04 LTS and Debian Wheezy (7.x) also have a compatible version
   packaged:

      # apt-get install python-git

   If your master is running an older version (such as Ubuntu 12.04 LTS or
   Debian Squeeze), then you will need to install GitPython  using  either
   pip  or  easy_install (it is recommended to use pip). Version 0.3.2.RC1
   is now marked as the stable release in PyPI, so it should be  a  simple
   matter  of running pip install GitPython (or easy_install GitPython) as
   root.

   WARNING:
      Keep in mind that if GitPython has been previously installed on  the
      master  using pip (even if it was subsequently uninstalled), then it
      may    still    exist    in    the    build     cache     (typically
      /tmp/pip-build-root/GitPython)  if  the  cache  is not cleared after
      installation. The package in  the  build  cache  will  override  any
      requirement specifiers, so if you try upgrading to version 0.3.2.RC1
      by running pip install 'GitPython==0.3.2.RC1' then  it  will  ignore
      this  and  simply  install  the  version  from  the cache directory.
      Therefore, it may be necessary to  delete  the  GitPython  directory
      from  the  build cache in order to ensure that the specified version
      is installed.

   WARNING:
      GitPython 2.0.9 and newer is not  compatible  with  Python  2.6.  If
      installing GitPython using pip on a machine running Python 2.6, make
      sure that a version earlier than 2.0.9 is  installed.  This  can  be
      done  on  the  CLI by running pip install 'GitPython<2.0.9', or in a
      pip.installed state using the following SLS:

          GitPython:
            pip.installed:
              - name: 'GitPython < 2.0.9'

   Dulwich
   Dulwich 0.9.4 or newer is required to use Dulwich as backend for gitfs.

   Dulwich is available in EPEL, and can be easily installed on the master
   using yum:

      # yum install python-dulwich

   For APT-based distros such as Ubuntu and Debian:

      # apt-get install python-dulwich

   IMPORTANT:
      If  switching  to  Dulwich  from GitPython/pygit2, or switching from
      GitPython/pygit2 to Dulwich, it is  necessary  to  clear  the  gitfs
      cache  to avoid unpredictable behavior. This is probably a good idea
      whenever switching to a new gitfs_provider, but it is less important
      when switching between GitPython and pygit2.

      Beginning in version 2015.5.0, the gitfs cache can be easily cleared
      using the fileserver.clear_cache runner.

          salt-run fileserver.clear_cache backend=git

      If the Master is running an earlier version, then the cache  can  be
      cleared by removing the gitfs and file_lists/gitfs directories (both
      paths   relative   to   the   master   cache   directory,    usually
      /var/cache/salt/master).

          rm -rf /var/cache/salt/master{,/file_lists}/gitfs

   Simple Configuration
   To  use  the gitfs backend, only two configuration changes are required
   on the master:

   1. Include git in the fileserver_backend  list  in  the  master  config
      file:

         fileserver_backend:
           - git

   2. Specify  one  or  more  git://, https://, file://, or ssh:// URLs in
      gitfs_remotes to configure which repositories to  cache  and  search
      for requested files:

         gitfs_remotes:
           - https://github.com/saltstack-formulas/salt-formula.git

      SSH remotes can also be configured using scp-like syntax:

         gitfs_remotes:
           - [email protected]:user/repo.git
           - ssh://[email protected]/path/to/repo.git

      Information on how to authenticate to SSH remotes can be found here.

      NOTE:
         Dulwich  does  not recognize ssh:// URLs, git+ssh:// must be used
         instead. Salt version 2015.5.0 and later will  automatically  add
         the  git+  to  the  beginning  of these URLs before fetching, but
         earlier Salt versions will  fail  to  fetch  unless  the  URL  is
         specified using git+ssh://.

   3. Restart the master to load the new configuration.

   NOTE:
      In  a master/minion setup, files from a gitfs remote are cached once
      by the master, so minions do not  need  direct  access  to  the  git
      repository.

   Multiple Remotes
   The  gitfs_remotes  option  accepts  an  ordered list of git remotes to
   cache and search, in listed order, for requested files.

   A simple scenario illustrates this cascading lookup behavior:

   If the gitfs_remotes option specifies three remotes:

      gitfs_remotes:
        - git://github.com/example/first.git
        - https://github.com/example/second.git
        - file:///root/third

   And each repository contains some files:

      first.git:
          top.sls
          edit/vim.sls
          edit/vimrc
          nginx/init.sls

      second.git:
          edit/dev_vimrc
          haproxy/init.sls

      third:
          haproxy/haproxy.conf
          edit/dev_vimrc

   Salt will attempt to lookup the requested file from each  gitfs  remote
   repository in the order in which they are defined in the configuration.
   The git://github.com/example/first.git remote will be  searched  first.
   If  the  requested  file  is  found,  then  it is served and no further
   searching is executed. For example:

   * A request for the file salt://haproxy/init.sls will  be  served  from
     the https://github.com/example/second.git git repo.

   * A  request  for  the  file salt://haproxy/haproxy.conf will be served
     from the file:///root/third repo.

   NOTE:
      This example is purposefully contrived to illustrate the behavior of
      the  gitfs backend. This example should not be read as a recommended
      way to lay out files and git repos.

      The file:// prefix denotes a git repository in  a  local  directory.
      However, it will still use the given file:// URL as a remote, rather
      than copying the git repo to the salt cache.  This  means  that  any
      refs  you  want accessible must exist as local refs in the specified
      repo.

   WARNING:
      Salt versions prior to 2014.1.0 are not  tolerant  of  changing  the
      order  of remotes or modifying the URI of existing remotes. In those
      versions, when modifying remotes it is a good  idea  to  remove  the
      gitfs    cache   directory   (/var/cache/salt/master/gitfs)   before
      restarting the salt-master service.

   Per-remote Configuration Parameters
   New in version 2014.7.0.

   The following master config parameters are global (that is, they  apply
   to all configured gitfs remotes):

   * gitfs_base

   * gitfs_root

   * gitfs_mountpoint (new in 2014.7.0)

   * gitfs_user (pygit2 only, new in 2014.7.0)

   * gitfs_password (pygit2 only, new in 2014.7.0)

   * gitfs_insecure_auth (pygit2 only, new in 2014.7.0)

   * gitfs_pubkey (pygit2 only, new in 2014.7.0)

   * gitfs_privkey (pygit2 only, new in 2014.7.0)

   * gitfs_passphrase (pygit2 only, new in 2014.7.0)

   These  parameters  can  now  be  overridden on a per-remote basis. This
   allows for a tremendous amount of customization.  Here's  some  example
   usage:

      gitfs_provider: pygit2
      gitfs_base: develop

      gitfs_remotes:
        - https://foo.com/foo.git
        - https://foo.com/bar.git:
          - root: salt
          - mountpoint: salt://bar
          - base: salt-base
        - https://foo.com/bar.git:
          - name: second_bar_repo
          - root: other/salt
          - mountpoint: salt://other/bar
          - base: salt-base
        - http://foo.com/baz.git:
          - root: salt/states
          - user: joe
          - password: mysupersecretpassword
          - insecure_auth: True

   IMPORTANT:
      There  are  two  important  distinctions  which  should be noted for
      per-remote configuration:

      1. The URL of a remote which has per-remote  configuration  must  be
         suffixed with a colon.

      2. Per-remote  configuration  parameters  are  named like the global
         versions,  with  the  gitfs_  removed  from  the  beginning.  The
         exception  being  the  name  parameter which is only available to
         per-remote configurations.

   In the example configuration above, the following is true:

   1. The first and fourth gitfs remotes will use the  develop  branch/tag
      as  the  base  environment,  while the second and third will use the
      salt-base branch/tag as the base environment.

   2. The first remote will serve all files in the repository. The  second
      remote  will  only  serve  files  from  the  salt directory (and its
      subdirectories). The third remote will only server  files  from  the
      other/salt  directory  (and  its  subdirectories),  while the fourth
      remote 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 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 need to be declared for duplicate gitfs remotes.

   5. The   fourth   remote   overrides   the   default  behavior  of  not
      authenticating to insecure (non-HTTPS) remotes.

   Per-Saltenv Configuration Parameters
   New in version 2016.11.0.

   For more granular control, Salt allows the following three things to be
   overridden for individual saltenvs within a given repo:

   * The mountpoint

   * The root

   * The branch/tag to be used for a given saltenv

   Here is an example:

      gitfs_root: salt

      gitfs_saltenv:
        - dev:
          - mountpoint: salt://gitfs-dev
          - ref: develop

      gitfs_remotes:
        - https://foo.com/bar.git:
          - saltenv:
            - staging:
              - ref: qa
              - mountpoint: salt://bar-staging
            - dev:
              - ref: development
        - https://foo.com/baz.git:
          - saltenv:
            - staging:
              - mountpoint: salt://baz-staging

   Given the above configuration, the following is true:

   1. For  all  gitfs  remotes,  files for the dev saltenv will be located
      under salt://gitfs-dev.

   2. For the dev saltenv, files from the first  remote  will  be  sourced
      from the development branch, while files from the second remote will
      be sourced from the develop branch.

   3. For the staging saltenv, files from the first remote will be located
      under salt://bar-staging, while files from the second remote will be
      located under salt://baz-staging.

   4. For all gitfs remotes, and in all saltenvs,  files  will  be  served
      from the salt directory (and its subdirectories).

   Configuration Order of Precedence
   The  order  of  precedence  for gitfs configuration is as follows (each
   level overrides all levels below it):

   1. Per-saltenv configuration (defined under a per-remote saltenv param)

         gitfs_remotes:
           - https://foo.com/bar.git:
             - saltenv:
               - dev:
                 - mountpoint: salt://bar

   2. Global per-saltenv configuration (defined in gitfs_saltenv)

         gitfs_saltenv:
           - saltenv:
             - dev:
               - mountpoint: salt://bar

   3. Per-remote configuration parameter

         gitfs_remotes:
           - https://foo.com/bar.git:
             - mountpoint: salt://bar

   4. Global configuration parameter

         gitfs_mountpoint: salt://bar

   Serving from a Subdirectory
   The gitfs_root parameter allows files to be served from a  subdirectory
   within  the repository. This allows for only part of a repository to be
   exposed to the Salt fileserver.

   Assume the below layout:

      .gitignore
      README.txt
      foo/
      foo/bar/
      foo/bar/one.txt
      foo/bar/two.txt
      foo/bar/three.txt
      foo/baz/
      foo/baz/top.sls
      foo/baz/edit/vim.sls
      foo/baz/edit/vimrc
      foo/baz/nginx/init.sls

   The below configuration would  serve  only  the  files  under  foo/baz,
   ignoring the other files in the repository:

      gitfs_remotes:
        - git://mydomain.com/stuff.git

      gitfs_root: foo/baz

   The root can also be configured on a per-remote basis.

   Mountpoints
   New in version 2014.7.0.

   The  gitfs_mountpoint  parameter will prepend the specified path to the
   files served from gitfs. This allows an existing repository to be used,
   rather  than needing to reorganize a repository or design it around the
   layout of the Salt fileserver.

   Before the addition of this feature, if a  file  being  served  up  via
   gitfs  was  deeply  nested  within  the  root  directory  (for example,
   salt://webapps/foo/files/foo.conf, it would be necessary to ensure that
   the file was properly located in the remote repository, and that all of
   the the parent directories were present (for example,  the  directories
   webapps/foo/files/ would need to exist at the root of the repository).

   The  below  example  would allow for a file foo.conf at the root of the
   repository  to  be  served   up   from   the   Salt   fileserver   path
   salt://webapps/foo/files/foo.conf.

      gitfs_remotes:
        - https://mydomain.com/stuff.git

      gitfs_mountpoint: salt://webapps/foo/files

   Mountpoints can also be configured on a per-remote basis.

   Using gitfs Alongside Other Backends
   Sometimes  it may make sense to use multiple backends; for instance, if
   sls files are stored in git but larger files are stored directly on the
   master.

   The  cascading lookup logic used for multiple remotes is also used with
   multiple backends. If the fileserver_backend option  contains  multiple
   backends:

      fileserver_backend:
        - roots
        - git

   Then the roots backend (the default backend of files in /srv/salt) will
   be searched first for the requested file; then, if it is not  found  on
   the master, each configured git remote will be searched.

   Branches, Environments, and Top Files
   When  using  the  gitfs  backend,  branches, and tags will be mapped to
   environments using the branch/tag name as an identifier.

   There is one exception to this rule: the master  branch  is  implicitly
   mapped to the base environment.

   So,  for a typical base, qa, dev setup, the following branches could be
   used:

      master
      qa
      dev

   top.sls files from different  branches  will  be  merged  into  one  at
   runtime.   Since  this  can  lead to overly complex configurations, the
   recommended setup is to have a separate repository, containing only the
   top.sls file with just one single master branch.

   To  map  a  branch  other  than master as the base environment, use the
   gitfs_base parameter.

      gitfs_base: salt-base

   The base can also be configured on a per-remote basis.

   Environment Whitelist/Blacklist
   New in version 2014.7.0.

   The gitfs_env_whitelist and gitfs_env_blacklist  parameters  allow  for
   greater  control  over  which  branches/tags  are exposed as fileserver
   environments.  Exact  matches,  globs,  and  regular  expressions   are
   supported,  and  are  evaluated  in  that  order.  If  using  a regular
   expression, ^ and $ must be omitted, and the expression must match  the
   entire branch/tag.

      gitfs_env_whitelist:
        - base
        - v1.*
        - 'mybranch\d+'

   NOTE:
      v1.*,  in  this  example,  will  match  as both a glob and a regular
      expression (though it will have been matched as a glob, since  globs
      are evaluated before regular expressions).

   The  behavior of the blacklist/whitelist will differ depending on which
   combination of the two options is used:

   * If only gitfs_env_whitelist is used, then  only  branches/tags  which
     match the whitelist will be available as environments

   * If  only  gitfs_env_blacklist  is  used, then the branches/tags which
     match the blacklist will not be available as environments

   * If both are used, then the branches/tags which match  the  whitelist,
     but do not match the blacklist, will be available as environments.

   Authentication
   pygit2
   New in version 2014.7.0.

   Both  HTTPS  and SSH authentication are supported as of version 0.20.3,
   which is the earliest version of pygit2 supported by Salt for gitfs.

   NOTE:
      The examples below make use of per-remote configuration  parameters,
      a  feature  new  to  Salt 2014.7.0. More information on these can be
      found here.

   HTTPS
   For HTTPS repositories which require authentication, the  username  and
   password can be provided like so:

      gitfs_remotes:
        - https://domain.tld/myrepo.git:
          - user: git
          - password: mypassword

   If  the repository is served over HTTP instead of HTTPS, then Salt will
   by  default  refuse  to  authenticate  to  it.  This  behavior  can  be
   overridden by adding an insecure_auth parameter:

      gitfs_remotes:
        - http://domain.tld/insecure_repo.git:
          - user: git
          - password: mypassword
          - insecure_auth: True

   SSH
   SSH   repositories   can   be  configured  using  the  ssh://  protocol
   designation,  or  using  scp-like  syntax.  So,   the   following   two
   configurations are equivalent:

   * ssh://[email protected]/user/repo.git

   * [email protected]:user/repo.git

   Both  gitfs_pubkey and gitfs_privkey (or their per-remote counterparts)
   must be configured in order to authenticate to SSH-based repos. If  the
   private  key is protected with a passphrase, it can be configured using
   gitfs_passphrase (or simply passphrase if being configured per-remote).
   For example:

      gitfs_remotes:
        - [email protected]:user/repo.git:
          - pubkey: /root/.ssh/id_rsa.pub
          - privkey: /root/.ssh/id_rsa
          - passphrase: myawesomepassphrase

   Finally, the SSH host key must be added to the known_hosts file.

   GitPython
   With  GitPython,  only passphrase-less SSH public key authentication is
   supported. The auth parameters (pubkey, privkey,  etc.)  shown  in  the
   pygit2 authentication examples above do not work with GitPython.

      gitfs_remotes:
        - ssh://[email protected]/example/salt-states.git

   Since  GitPython  wraps the git CLI, the private key must be located in
   ~/.ssh/id_rsa for the user under  which  the  Master  is  running,  and
   should  have permissions of 0600. Also, in the absence of a user in the
   repo URL, GitPython will (just as SSH does) attempt  to  login  as  the
   current  user  (in  other  words,  the  user  under which the Master is
   running, usually root).

   If a key needs to be used, then ~/.ssh/config can be configured to  use
   the  desired key. Information on how to do this can be found by viewing
   the manpage for ssh_config. Here's an example entry which can be  added
   to the ~/.ssh/config to use an alternate key for gitfs:

      Host github.com
          IdentityFile /root/.ssh/id_rsa_gitfs

   The Host parameter should be a hostname (or hostname glob) that matches
   the domain name of the git repository.

   It is also necessary to add the SSH host key to the  known_hosts  file.
   The exception to this would be if strict host key checking is disabled,
   which can be done by adding StrictHostKeyChecking no to  the  entry  in
   ~/.ssh/config

      Host github.com
          IdentityFile /root/.ssh/id_rsa_gitfs
          StrictHostKeyChecking no

   However,   this   is   generally  regarded  as  insecure,  and  is  not
   recommended.

   Adding the SSH Host Key to the known_hosts File
   To  use  SSH  authentication,  it  is  necessary  to  have  the  remote
   repository's SSH host key in the ~/.ssh/known_hosts file. If the master
   is also a  minion,  this  can  be  done  using  the  ssh.set_known_host
   function:

      # salt mymaster ssh.set_known_host user=root hostname=github.com
      mymaster:
          ----------
          new:
              ----------
              enc:
                  ssh-rsa
              fingerprint:
                  16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
              hostname:
                  |1|OiefWWqOD4kwO3BhoIGa0loR5AA=|BIXVtmcTbPER+68HvXmceodDcfI=
              key:
                  AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
          old:
              None
          status:
              updated

   If  not,  then  the  easiest  way  to  add the key is to su to the user
   (usually root) under which the salt-master runs and attempt to login to
   the server via SSH:

      $ su -
      Password:
      # ssh github.com
      The authenticity of host 'github.com (192.30.252.128)' can't be established.
      RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
      Are you sure you want to continue connecting (yes/no)? yes
      Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts.
      Permission denied (publickey).

   It  doesn't  matter  if the login was successful, as answering yes will
   write the fingerprint to the known_hosts file.

   Verifying the Fingerprint
   To verify that the correct fingerprint was added, it is a good idea  to
   look it up. One way to do this is to use nmap:

      $ nmap -p 22 github.com --script ssh-hostkey

      Starting Nmap 5.51 ( http://nmap.org ) at 2014-08-18 17:47 CDT
      Nmap scan report for github.com (192.30.252.129)
      Host is up (0.17s latency).
      Not shown: 996 filtered ports
      PORT     STATE SERVICE
      22/tcp   open  ssh
      | ssh-hostkey: 1024 ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA)
      |_2048 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA)
      80/tcp   open  http
      443/tcp  open  https
      9418/tcp open  git

      Nmap done: 1 IP address (1 host up) scanned in 28.78 seconds

   Another  way  is  to  check  one's  own  known_hosts  file,  using this
   one-liner:

      $ ssh-keygen -l -f /dev/stdin <<<`ssh-keyscan github.com 2>/dev/null` | awk '{print $2}'
      16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48

   WARNING:
      AWS tracks usage of nmap and may flag it as abuse. On AWS hosts, the
      ssh-keygen method is recommended for host key verification.

   NOTE:
      As   of   OpenSSH  6.8  the  SSH  fingerprint  is  now  shown  as  a
      base64-encoded SHA256 checksum of the host key. So, instead  of  the
      fingerprint                       looking                       like
      16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48, it would look  like
      SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.

   Refreshing gitfs Upon Push
   By  default,  Salt  updates  the  remote  fileserver  backends every 60
   seconds.  However, if it is desirable to refresh quicker than that, the
   Reactor  System  can  be  used  to  signal  the  master  to  update the
   fileserver on each push, provided that the git server is  also  a  Salt
   minion. There are three steps to this process:

   1. On  the  master,  create  a file /srv/reactor/update_fileserver.sls,
      with the following contents:

         update_fileserver:
           runner.fileserver.update

   2. Add the following reactor configuration to the master config file:

         reactor:
           - 'salt/fileserver/gitfs/update':
             - /srv/reactor/update_fileserver.sls

   3. On the git server, add a post-receive hook

      a. If the user executing git push is the same as  the  minion  user,
         use the following hook:

             #!/usr/bin/env sh
             salt-call event.fire_master update salt/fileserver/gitfs/update

      b. To  enable other git users to run the hook after a push, use sudo
         in the hook script:

             #!/usr/bin/env sh
             sudo -u root salt-call event.fire_master update salt/fileserver/gitfs/update

   4. If using sudo in the git hook (above), the policy must be changed to
      permit all users to fire the event.  Add the following policy to the
      sudoers file on the git server.

         Cmnd_Alias SALT_GIT_HOOK = /bin/salt-call event.fire_master update salt/fileserver/gitfs/update
         Defaults!SALT_GIT_HOOK !requiretty
         ALL ALL=(root) NOPASSWD: SALT_GIT_HOOK

   The update argument right after event.fire_master in this  example  can
   really  be  anything,  as  it  represents  the data being passed in the
   event, and the passed data is ignored by this reactor.

   Similarly, the tag name salt/fileserver/gitfs/update can be replaced by
   anything, so long as the usage is consistent.

   The root user name in the hook script and sudo policy should be changed
   to match the user under which the minion is running.

   Using Git as an External Pillar Source
   The git external pillar (a.k.a. git_pillar) has been rewritten for  the
   2015.8.0  release. This rewrite brings with it pygit2 support (allowing
   for access to authenticated repositories), as  well  as  more  granular
   support for per-remote configuration.

   To  make  use  of  the  new  features,  changes  to  the git ext_pillar
   configuration must be made. The new configuration  schema  is  detailed
   here.

   For Salt releases before 2015.8.0, click here for documentation.

   Why aren't my custom modules/states/etc. syncing to my Minions?
   In  versions  0.16.3  and older, when using the git fileserver backend,
   certain versions of GitPython may generate errors when fetching,  which
   Salt  fails  to  catch.  While  not  fatal  to the fetch process, these
   interrupt the fileserver update that takes place  before  custom  types
   are  synced,  and thus interrupt the sync itself. Try disabling the git
   fileserver backend in the master config,  restarting  the  master,  and
   attempting the sync again.

   This issue is worked around in Salt 0.16.4 and newer.

   MinionFS Backend Walkthrough
   New in version 2014.1.0.

   NOTE:
      This walkthrough assumes basic knowledge of Salt and cp.push. To get
      up to speed, check out the walkthrough.

   Sometimes it is desirable to deploy a file located on one minion to one
   or  more  other  minions.  This  is  supported  in  Salt,  and  can  be
   accomplished in two parts:

   1. Minion support for pushing files to the master (using cp.push)

   2. The minionfs fileserver backend

   This walkthrough will show how to use both of these features.

   Enabling File Push
   To set the master to accept files pushed from  minions,  the  file_recv
   option  in  the  master config file must be set to True (the default is
   False).

      file_recv: True

   NOTE:
      This change requires a restart of the salt-master service.

   Pushing Files
   Once this has been done, files can be pushed to the  master  using  the
   cp.push function:

      salt 'minion-id' cp.push /path/to/the/file

   This  command will store the file in a subdirectory named minions under
   the  master's  cachedir.  On  most   masters,   this   path   will   be
   /var/cache/salt/master/minions.  Within  this  directory  will  be  one
   directory for each minion which has pushed a file to  the  master,  and
   underneath  that  the  full  path  to  the  file on the minion. So, for
   example,  if  a  minion  with   an   ID   of   dev1   pushed   a   file
   /var/log/myapp.log    to   the   master,   it   would   be   saved   to
   /var/cache/salt/master/minions/dev1/var/log/myapp.log.

   Serving Pushed Files Using MinionFS
   While it is certainly possible to add /var/cache/salt/master/minions to
   the master's file_roots and serve these files, it may only be desirable
   to   expose    files    pushed    from    certain    minions.    Adding
   /var/cache/salt/master/minions/<minion-id>  for  each minion that needs
   to be exposed can be cumbersome and prone to errors.

   Enter minionfs. This fileserver backend will make  files  pushed  using
   cp.push  available  to  the  Salt  fileserver,  and  provides  an  easy
   mechanism to restrict which minions' pushed files are made available.

   Simple Configuration
   To use the minionfs backend, add minion to the list of backends in  the
   fileserver_backend configuration option on the master:

      file_recv: True

      fileserver_backend:
        - roots
        - minion

   NOTE:
      As  described  earlier, file_recv: True is also needed to enable the
      master to receive files pushed from minions. As always,  changes  to
      the  master  configuration  require  a  restart  of  the salt-master
      service.

   Files  made  available  via  minionfs  are  by   default   located   at
   salt://<minion-id>/path/to/file.  Think back to the earlier example, in
   which dev1  pushed  a  file  /var/log/myapp.log  to  the  master.  With
   minionfs   enabled,   this   file  would  be  addressable  in  Salt  at
   salt://dev1/var/log/myapp.log.

   If many minions have pushed to the master, this  will  result  in  many
   directories  in the root of the Salt fileserver. For this reason, it is
   recommended to use the minionfs_mountpoint config  option  to  organize
   these files underneath a subdirectory:

      minionfs_mountpoint: salt://minionfs

   Using the above mountpoint, the file in the example would be located at
   salt://minionfs/dev1/var/log/myapp.log.

   Restricting Certain Minions' Files from Being Available Via MinionFS
   A whitelist and blacklist can be used to  restrict  the  minions  whose
   pushed  files  are  available  via minionfs. These lists can be managed
   using the minionfs_whitelist  and  minionfs_blacklist  config  options.
   Click  the  links for both of them for a detailed explanation of how to
   use them.

   A more complex configuration example, which uses both a  whitelist  and
   blacklist, can be found below:

      file_recv: True

      fileserver_backend:
        - roots
        - minion

      minionfs_mountpoint: salt://minionfs

      minionfs_whitelist:
        - host04
        - web*
        - 'mail\d+\.domain\.tld'

      minionfs_whitelist:
        - web21

   Potential Concerns
   * There  is  no  access control in place to restrict which minions have
     access to files served up by minionfs. All minions will  have  access
     to these files.

   * Unless   the   minionfs_whitelist  and/or  minionfs_blacklist  config
     options are used, all minions which push files  to  the  master  will
     have their files made available via minionfs.

   Salt Package Manager
   The  Salt Package Manager, or SPM, enables Salt formulas to be packaged
   to simplify distribution  to  Salt  masters.  The  design  of  SPM  was
   influenced  by other existing packaging systems including RPM, Yum, and
   Pacman.  [image]

   NOTE:
      The previous diagram shows each SPM component as a different system,
      but  this  is  not required. You can build packages and host the SPM
      repo on a single Salt master if you'd like.

   Packaging System

   The packaging system  is  used  to  package  the  state,  pillar,  file
   templates,  and  other  files  used by your formula into a single file.
   After a formula package is created, it  is  copied  to  the  Repository
   System where it is made available to Salt masters.

   See Building SPM Packages

   Repo System

   The  Repo  system  stores  the SPM package and metadata files and makes
   them available to Salt masters via http(s),  ftp,  or  file  URLs.  SPM
   repositories  can  be  hosted  on  a  Salt Master, a Salt Minion, or on
   another system.

   See Distributing SPM Packages

   Salt Master

   SPM provides Salt master settings that let you configure the URL of one
   or  more  SPM repos. You can then quickly install packages that contain
   entire formulas to your Salt masters using SPM.

   See Installing SPM Packages

   Contents

   Building SPM Packages
   The first step when using Salt Package Manager is to build packages for
   each  of  of  the formulas that you want to distribute. Packages can be
   built on any system where you can install Salt.

   Package Build Overview
   To build a package, all state, pillar, jinja, and file  templates  used
   by  your formula are assembled into a folder on the build system. These
   files can be cloned from a Git repository, such as those found  at  the
   saltstack-formulas  organization  on  GitHub, or copied directly to the
   folder.

   The following diagram demonstrates a  typical  formula  layout  on  the
   build system: [image]

   In  this  example,  all  formula  files  are  placed in a myapp-formula
   folder.  This is the folder that is targeted by the spm  build  command
   when this package is built.

   Within  this  folder, pillar data is placed in a pillar.example file at
   the root, and all state, jinja, and template files are placed within  a
   subfolder  that  is  named  after the application being packaged. State
   files are typically contained within a subfolder, similar to how  state
   files  are  organized  in  the state tree. Any non-pillar files in your
   package that are not contained in a subfolder are placed at the root of
   the spm state tree.

   Additionally,  a  FORMULA file is created and placed in the root of the
   folder. This file contains package metadata that is used by SPM.

   Package Installation Overview
   When building packages, it is useful to know where files are  installed
   on   the   Salt   master.   During   installation,   all  files  except
   pillar.example and FORMULA are copied directly to the spm state tree on
   the Salt master (located at \srv\spm\salt).

   If  a  pillar.example  file  is  present  in the root, it is renamed to
   <formula name>.sls.orig and placed in the pillar_path.  [image]

   NOTE:
      Even though the pillar data file is copied to the pillar  root,  you
      still  need to manually assign this pillar data to systems using the
      pillar top file. This file can also be duplicated and renamed so the
      .orig version is left intact in case you need to restore it later.

   Building an SPM Formula Package
   1. Assemble formula files in a folder on the build system.

   2. Create  a  FORMULA  file  and  place  it  in the root of the package
      folder.

   3. Run spm build <folder name>. The package is built and placed in  the
      /srv/spm_build folder.

         spm build /path/to/salt-packages-source/myapp-formula

   4. Copy the .spm file to a folder on the repository system.

   Types of Packages
   SPM  supports different types of packages. The function of each package
   is denoted by its name. For instance, packages which  end  in  -formula
   are  considered  to  be  Salt States (the most common type of formula).
   Packages which end in -conf contain configuration which is to be placed
   in the /etc/salt/ directory. Packages which do not contain one of these
   names are treated as if they have a -formula name.

   formula
   By  default,  most  files  from  this  type  of  package  live  in  the
   /srv/spm/salt/  directory.  The  exception  is the pillar.example file,
   which will be renamed to <package_name>.sls and placed  in  the  pillar
   directory (/srv/spm/pillar/ by default).

   reactor
   By   default,   files   from   this   type   of  package  live  in  the
   /srv/spm/reactor/ directory.

   conf
   The files in this type of package are  configuration  files  for  Salt,
   which  normally  live  in the /etc/salt/ directory. Configuration files
   for packages other than Salt can and should  be  handled  with  a  Salt
   State (using a formula type of package).

   Technical Information
   Packages  are  built  using  BZ2-compressed  tarballs.  By default, the
   package database is stored using the sqlite3 driver (see Loader Modules
   below).

   Support   for   these  are  built  into  Python,  and  so  no  external
   dependencies are needed.

   All other files belonging to SPM use YAML, for portability and ease  of
   use and maintainability.

   SPM-Specific Loader Modules
   SPM  was  designed  to  behave like traditional package managers, which
   apply files to the filesystem and store package  metadata  in  a  local
   database.  However,  because modern infrastructures often extend beyond
   those use cases, certain parts of SPM have been broken out  into  their
   own set of modules.

   Package Database
   By  default,  the  package database is stored using the sqlite3 module.
   This module was chosen because support for SQLite3 is built into Python
   itself.

   Please  see  the  SPM Development Guide for information on creating new
   modules for package database management.

   Package Files
   By default, package files are installed using the  local  module.  This
   module  applies  files to the local filesystem, on the machine that the
   package is installed on.

   Please see the SPM Development Guide for information  on  creating  new
   modules for package file management.

   Distributing SPM Packages
   SPM  packages  can be distributed to Salt masters over HTTP(S), FTP, or
   through the file system. The SPM repo can be hosted on any system where
   you  can  install  Salt.  Salt  is  installed  so  you  can run the spm
   create_repo command when you update or add a package to the  repo.  SPM
   repos do not require the salt-master, salt-minion, or any other process
   running on the system.

   NOTE:
      If you are hosting the SPM repo on a system where you can not or  do
      not want to install Salt, you can run the spm create_repo command on
      the build system and  then  copy  the  packages  and  the  generated
      SPM-METADATA  file  to  the  repo.  You  can  also install SPM files
      directly on a Salt master, bypassing the repository completely.

   Setting up a Package Repository
   After packages are built, the generated SPM files  are  placed  in  the
   srv/spm_build folder.

   Where  you  place the built SPM files on your repository server depends
   on how you plan to make them available to your Salt masters.

   You can share the srv/spm_build folder on  the  network,  or  copy  the
   files to your FTP or Web server.

   Adding a Package to the repository
   New  packages  are  added  by  simply  copying the SPM file to the repo
   folder, and then generating repo metadata.

   Generate Repo Metadata
   Each time you update or add an SPM package to your repository, issue an
   spm create_repo command:

      spm create_repo /srv/spm_build

   SPM  generates  the repository metadata for all of the packages in that
   directory and places it in an SPM-METADATA file  at  the  folder  root.
   This command is used even if repository metadata already exists in that
   directory.

   Installing SPM Packages
   SPM packages  are  installed  to  your  Salt  master,  where  they  are
   available  to  Salt  minions  using  all  of  Salt's package management
   functions.

   Configuring Remote Repositories
   Before SPM can use a repository, two things need to happen. First,  the
   Salt   master   needs  to  know  where  the  repository  is  through  a
   configuration process. Then  it  needs  to  pull  down  the  repository
   metadata.

   Repository Configuration Files
   Repositories   are   configured   by   adding   each  of  them  to  the
   /etc/salt/spm.repos.d/spm.repo file on  each  Salt  master.  This  file
   contains the name of the repository, and the link to the repository:

      my_repo:
        url: https://spm.example.com/

   The URL can use http, https, ftp, or file.

      my_repo:
        url: file:///srv/spm_build

   Updating Local Repository Metadata
   After  the  repository  is  configured  on  the Salt master, repository
   metadata is downloaded using the spm update_repo command:

      spm update_repo

   NOTE:
      A file for each repo is placed in /var/cache/salt/spm  on  the  Salt
      master  after  you  run  the  update_repo  command.  If  you  add  a
      repository and it does not seem to be showing up, check this path to
      verify that the repository was found.

   Update File Roots
   SPM  packages  are  installed  to  the srv/spm/salt folder on your Salt
   master.  This path needs to be added to the file  roots  on  your  Salt
   master manually.

      file_roots:
        base:
          1. /srv/salt
          2. /srv/spm/salt

   Restart the salt-master service after updating the file_roots setting.

   Installing Packages
   To install a package, use the spm install command:

      spm install apache

   WARNING:
      Currently,  SPM  does not check to see if files are already in place
      before installing them. That  means  that  existing  files  will  be
      overwritten without warning.

   Installing directly from an SPM file
   You  can also install SPM packages using a local SPM file using the spm
   local install command:

      spm local install /srv/spm/apache-201506-1.spm

   An SPM repository is not required when using spm local install.

   Pillars
   If an installed package includes Pillar data, be  sure  to  target  the
   installed pillar to the necessary systems using the pillar Top file.

   Removing Packages
   Packages  may  be removed after they are installed using the spm remove
   command.

      spm remove apache

   If  files  have  been  modified,  they  will  not  be  removed.   Empty
   directories will also be removed.

   SPM Configuration
   There  are  a  number  of options that are specific to SPM. They may be
   configured in the master  configuration  file,  or  in  SPM's  own  spm
   configuration  file  (normally located at /etc/salt/spm). If configured
   in both places, the spm file takes precedence. In general, these values
   will not need to be changed from the defaults.

   spm_logfile
   Default: /var/log/salt/spm

   Where SPM logs messages.

   spm_repos_config
   Default: /etc/salt/spm.repos

   SPM  repositories  are  configured  with  this  file.  There  is also a
   directory which corresponds to it, which ends in .d. For  instance,  if
   the   filename   is   /etc/salt/spm.repos,   the   directory   will  be
   /etc/salt/spm.repos.d/.

   spm_cache_dir
   Default: /var/cache/salt/spm

   When SPM updates package repository metadata  and  downloads  packaged,
   they  will  be placed in this directory. The package database, normally
   called packages.db, also lives in this directory.

   spm_db
   Default: /var/cache/salt/spm/packages.db

   The location and name of the package database. This database stores the
   names  of  all  of  the SPM packages installed on the system, the files
   that belong to them, and the metadata for those files.

   spm_build_dir
   Default: /srv/spm_build

   When packages are built, they will be placed in this directory.

   spm_build_exclude
   Default: ['.git']

   When SPM builds a package, it normally adds all files  in  the  formula
   directory  to the package. Files listed here will be excluded from that
   package. This option requires a list to be specified.

      spm_build_exclude:
        - .git
        - .svn

   Types of Packages
   SPM supports different types of formula packages. The function of  each
   package  is  denoted  by  its name. For instance, packages which end in
   -formula are considered to be Salt States  (the  most  common  type  of
   formula). Packages which end in -conf contain configuration which is to
   be placed in the /etc/salt/ directory. Packages which  do  not  contain
   one of these names are treated as if they have a -formula name.

   formula
   By  default,  most  files  from  this  type  of  package  live  in  the
   /srv/spm/salt/ directory. The exception  is  the  pillar.example  file,
   which  will  be  renamed to <package_name>.sls and placed in the pillar
   directory (/srv/spm/pillar/ by default).

   reactor
   By  default,  files  from  this   type   of   package   live   in   the
   /srv/spm/reactor/ directory.

   conf
   The  files  in  this  type of package are configuration files for Salt,
   which normally live in the /etc/salt/  directory.  Configuration  files
   for  packages  other  than  Salt  can and should be handled with a Salt
   State (using a formula type of package).

   FORMULA File
   In addition to the formula itself, a  FORMULA  file  must  exist  which
   describes the package. An example of this file is:

      name: apache
      os: RedHat, Debian, Ubuntu, SUSE, FreeBSD
      os_family: RedHat, Debian, SUSE, FreeBSD
      version: 201506
      release: 2
      summary: Formula for installing Apache
      description: Formula for installing Apache

   Required Fields
   This file must contain at least the following fields:

   name
   The  name of the package, as it will appear in the package filename, in
   the repository metadata, and the package database. Even if  the  source
   formula has -formula in its name, this name should probably not include
   that. For instance, when packaging the apache-formula, the name  should
   be set to apache.

   os
   The  value  of the os grain that this formula supports. This is used to
   help users know which operating systems can support this package.

   os_family
   The value of the os_family grain that this formula  supports.  This  is
   used  to  help  users  know which operating system families can support
   this package.

   version
   The version of the package. While it is up  to  the  organization  that
   manages this package, it is suggested that this version is specified in
   a YYYYMM format.  For instance, if this version was  released  in  June
   2015,  the  package  version should be 201506. If multiple releases are
   made in a month, the release field should be used.

   minimum_version
   Minimum recommended version of Salt to use this formula. Not  currently
   enforced.

   release
   This  field  refers  primarily  to  a release of a version, but also to
   multiple versions within a month. In general, if  a  version  has  been
   made  public,  and  immediate updates need to be made to it, this field
   should also be updated.

   summary
   A one-line description of the package.

   description
   A more detailed description of the package which can contain more  than
   one line.

   Optional Fields
   The following fields may also be present.

   top_level_dir
   This field is optional, but highly recommended. If it is not specified,
   the package name will be used.

   Formula repositories typically do not store .sls files in the  root  of
   the  repository;  instead  they  are  stored  in  a  subdirectory.  For
   instance, an apache-formula repository would contain a directory called
   apache, which would contain an init.sls, plus a number of other related
   files. In this instance, the top_level_dir should be set to apache.

   Files outside the  top_level_dir,  such  as  README.rst,  FORMULA,  and
   LICENSE  will  not  be installed. The exceptions to this rule are files
   that  are  already  treated  specially,  such  as  pillar.example   and
   _modules/.

   dependencies
   A  comma-separated  list  of packages that must be installed along with
   this package. When this package  is  installed,  SPM  will  attempt  to
   discover  and  install these packages as well. If it is unable to, then
   it will refuse to install this package.

   This is useful for creating packages which tie together other packages.
   For  instance,  a  package called wordpress-mariadb-apache would depend
   upon wordpress, mariadb, and apache.

   optional
   A comma-separated list of packages which are related to  this  package,
   but  are  neither  required  nor  necessarily recommended. This list is
   displayed in an informational message when the package is installed  to
   SPM.

   recommended
   A  comma-separated list of optional packages that are recommended to be
   installed with the package. This list is displayed in an  informational
   message when the package is installed to SPM.

   Building a Package
   Once a FORMULA file has been created, it is placed into the root of the
   formula that is to be turned into a package. The spm build  command  is
   used to turn that formula into a package:

      spm build /path/to/saltstack-formulas/apache-formula

   The  resulting  file  will be placed in the build directory. By default
   this directory is located at /srv/spm/.

   Loader Modules
   When an execution module is placed  in  <file_roots>/_modules/  on  the
   master,  it  will  automatically  be synced to minions, the next time a
   sync operation takes place. Other modules are also propagated this way:
   state modules can be placed in _states/, and so on.

   When  SPM  detects  a  file  in a package which resides in one of these
   directories, that directory will be placed in <file_roots>  instead  of
   in the formula directory with the rest of the files.

   Removing Packages
   Packages  may  be  removed once they are installed using the spm remove
   command.

      spm remove apache

   If  files  have  been  modified,  they  will  not  be  removed.   Empty
   directories will also be removed.

   Technical Information
   Packages  are  built  using  BZ2-compressed  tarballs.  By default, the
   package database is stored using the sqlite3 driver (see Loader Modules
   below).

   Support   for   these  are  built  into  Python,  and  so  no  external
   dependencies are needed.

   All other files belonging to SPM use YAML, for portability and ease  of
   use and maintainability.

   SPM-Specific Loader Modules
   SPM  was  designed  to  behave like traditional package managers, which
   apply files to the filesystem and store package  metadata  in  a  local
   database.  However,  because modern infrastructures often extend beyond
   those use cases, certain parts of SPM have been broken out  into  their
   own set of modules.

   Package Database
   By  default,  the  package database is stored using the sqlite3 module.
   This module was chosen because support for SQLite3 is built into Python
   itself.

   Please  see  the  SPM Development Guide for information on creating new
   modules for package database management.

   Package Files
   By default, package files are installed using the  local  module.  This
   module  applies  files to the local filesystem, on the machine that the
   package is installed on.

   Please see the SPM Development Guide for information  on  creating  new
   modules for package file management.

   Types of Packages
   SPM  supports different types of formula packages. The function of each
   package is denoted by its name. For instance,  packages  which  end  in
   -formula  are  considered  to  be  Salt States (the most common type of
   formula). Packages which end in -conf contain configuration which is to
   be  placed  in  the /etc/salt/ directory. Packages which do not contain
   one of these names are treated as if they have a -formula name.

   formula
   By  default,  most  files  from  this  type  of  package  live  in  the
   /srv/spm/salt/  directory.  The  exception  is the pillar.example file,
   which will be renamed to <package_name>.sls and placed  in  the  pillar
   directory (/srv/spm/pillar/ by default).

   reactor
   By   default,   files   from   this   type   of  package  live  in  the
   /srv/spm/reactor/ directory.

   conf
   The files in this type of package are  configuration  files  for  Salt,
   which  normally  live  in the /etc/salt/ directory. Configuration files
   for packages other than Salt can and should  be  handled  with  a  Salt
   State (using a formula type of package).

   SPM Development Guide
   This document discusses developing additional code for SPM.

   SPM-Specific Loader Modules
   SPM  was  designed  to  behave like traditional package managers, which
   apply files to the filesystem and store package  metadata  in  a  local
   database.  However,  because modern infrastructures often extend beyond
   those use cases, certain parts of SPM have been broken out  into  their
   own set of modules.

   Each function that accepts arguments has a set of required and optional
   arguments. Take note that SPM will pass all arguments in, and therefore
   each  function  must accept each of those arguments. However, arguments
   that are marked as required are crucial to  SPM's  core  functionality,
   while  arguments  that are marked as optional are provided as a benefit
   to the module, if it needs to use them.

   Package Database
   By default, the package database is stored using  the  sqlite3  module.
   This module was chosen because support for SQLite3 is built into Python
   itself.

   Modules  for  managing  the  package  database  are   stored   in   the
   salt/spm/pkgdb/  directory. A number of functions must exist to support
   database management.

   init()
   Get a database connection,  and  initialize  the  package  database  if
   necessary.

   This  function  accepts  no  arguments.  If  a  database  is used which
   supports a connection object, then that connection object is  returned.
   For  instance,  the  sqlite3 module returns a connect() object from the
   sqlite3 library:

      conn = sqlite3.connect(__opts__['spm_db'], isolation_level=None)
      ...
      return conn

   SPM itself will not use this connection object; it will  be  passed  in
   as-is  to the other functions in the module. Therefore, when you set up
   this object, make sure to  do  so  in  a  way  that  is  easily  usable
   throughout the module.

   info()
   Return  information  for  a  package.  This  generally  consists of the
   information that is stored in the FORMULA file in the package.

   The arguments that are passed in, in order, are package (required)  and
   conn (optional).

   package  is the name of the package, as specified in the FORMULA.  conn
   is the connection object returned from init().

   list_files()
   Return a list of files for an  installed  package.  Only  the  filename
   should be returned, and no other information.

   The  arguments that are passed in, in order, are package (required) and
   conn (optional).

   package is the name of the package, as specified in the FORMULA.   conn
   is the connection object returned from init().

   register_pkg()
   Register  a  package in the package database. Nothing is expected to be
   returned from this function.

   The arguments that are  passed  in,  in  order,  are  name  (required),
   formula_def (required), and conn (optional).

   name  is  the  name  of  the  package,  as  specified  in  the FORMULA.
   formula_def is the contents of the FORMULA file, as a dict. conn is the
   connection object returned from init().

   register_file()
   Register  a  file  in  the  package database. Nothing is expected to be
   returned from this function.

   The  arguments  that  are  passed  in  are  name   (required),   member
   (required), path (required), digest (optional), and conn (optional).

   name is the name of the package.

   member  is  a  tarfile  object  for  the  package file. It is included,
   because it contains most of the information for the file.

   path is the location of the file on the local filesystem.

   digest is the SHA1 checksum of the file.

   conn is the connection object returned from init().

   unregister_pkg()
   Unregister a package from  the  package  database.  This  usually  only
   involves  removing  the  package's record from the database. Nothing is
   expected to be returned from this function.

   The arguments that are passed in, in order,  are  name  (required)  and
   conn (optional).

   name  is  the name of the package, as specified in the FORMULA. conn is
   the connection object returned from init().

   unregister_file()
   Unregister a package from  the  package  database.  This  usually  only
   involves  removing  the  package's record from the database. Nothing is
   expected to be returned from this function.

   The arguments that are passed in, in order, are  name  (required),  pkg
   (optional) and conn (optional).

   name is the path of the file, as it was installed on the filesystem.

   pkg is the name of the package that the file belongs to.

   conn is the connection object returned from init().

   db_exists()
   Check  to  see whether the package database already exists. This is the
   path to the package database file. This function will  return  True  or
   False.

   The  only  argument  that  is  expected  is  db_,  which is the package
   database file.

   Package Files
   By default, package files are installed using the  local  module.  This
   module  applies  files to the local filesystem, on the machine that the
   package is installed on.

   Modules  for  managing  the  package  database  are   stored   in   the
   salt/spm/pkgfiles/  directory.  A  number  of  functions  must exist to
   support file management.

   init()
   Initialize the installation location for the  package  files.  Normally
   these  will be directory paths, but other external destinations such as
   databases can be used. For this reason, this  function  will  return  a
   connection  object,  which  can  be  a database object. However, in the
   default local module, this object is a dict containing the paths.  This
   object will be passed into all other functions.

   Three   directories   are  used  for  the  destinations:  formula_path,
   pillar_path, and reactor_path.

   formula_path is the  location  of  most  of  the  files  that  will  be
   installed.   The  default  is  specific to the operating system, but is
   normally /srv/salt/.

   pillar_path is the  location  that  the  pillar.example  file  will  be
   installed  to.  The default is specific to the operating system, but is
   normally /srv/pillar/.

   reactor_path is the location that reactor files will be  installed  to.
   The  default  is  specific  to  the  operating  system, but is normally
   /srv/reactor/.

   check_existing()
   Check the filesystem for existing files. All files for the package will
   be  checked,  and if any are existing, then this function will normally
   state that SPM will refuse to install the package.

   This function returns a list of the files that exist on the system.

   The arguments that are passed into this function are, in order: package
   (required),  pkg_files  (required), formula_def (formula_def), and conn
   (optional).

   package is the name of the package that is to be installed.

   pkg_files is a list of the files to be checked.

   formula_def is a copy of the information that is stored in the  FORMULA
   file.

   conn is the file connection object.

   install_file()
   Install  a single file to the destination (normally on the filesystem).
   Nothing is expected to be returned from this function.

   This function returns the final location that the  file  was  installed
   to.

   The arguments that are passed into this function are, in order, package
   (required),  formula_tar  (required),  member  (required),  formula_def
   (required), and conn (optional).

   package is the name of the package that is to be installed.

   formula_tar is the tarfile object for the package. This is passed in so
   that the function can call formula_tar.extract() for the file.

   member is the tarfile object which represents the individual file. This
   may    be   modified   as   necessary,   before   being   passed   into
   formula_tar.extract().

   formula_def is a copy of the information from the FORMULA file.

   conn is the file connection object.

   remove_file()
   Remove a single file from file system. Normally  this  will  be  little
   more  than an os.remove(). Nothing is expected to be returned from this
   function.

   The arguments that are passed into this function are,  in  order,  path
   (required) and conn (optional).

   path is the absolute path to the file to be removed.

   conn is the file connection object.

   hash_file()
   Returns the hexdigest hash value of a file.

   The  arguments  that  are passed into this function are, in order, path
   (required), hashobj (required), and conn (optional).

   path is the absolute path to the file.

   hashobj is a reference to hashlib.sha1(), which is  used  to  pull  the
   hexdigest() for the file.

   conn is the file connection object.

   This function will not generally be more complex than:

      def hash_file(path, hashobj, conn=None):
          with salt.utils.fopen(path, 'r') as f:
              hashobj.update(f.read())
              return hashobj.hexdigest()

   path_exists()
   Check to see whether the file already exists on the filesystem. Returns
   True or False.

   This function expects a path argument, which is the  absolute  path  to
   the file to be checked.

   path_isdir()
   Check to see whether the path specified is a directory. Returns True or
   False.

   This function expects a path argument, which is the absolute path to be
   checked.

   Storing Data in Other Databases
   The  SDB  interface is designed to store and retrieve data that, unlike
   pillars and grains, is not  necessarily  minion-specific.  The  initial
   design  goal  was to allow passwords to be stored in a secure database,
   such as one managed by the keyring package, rather than  as  plain-text
   files.  However, as a generic database interface, it could conceptually
   be used for a number of other purposes.

   SDB was added to Salt in version 2014.7.0.

   SDB Configuration
   In order to use the SDB interface, a configuration profile must be  set
   up in either the master or minion configuration file. The configuration
   stanza includes the name/ID that the profile will be referred to as,  a
   driver  setting, and any other arguments that are necessary for the SDB
   module that will be used. For instance,  a  profile  called  mykeyring,
   which uses the system service in the keyring module would look like:

      mykeyring:
        driver: keyring
        service: system

   It is recommended to keep the name of the profile simple, as it is used
   in the SDB URI as well.

   SDB URIs
   SDB is designed to make small database queries (hence  the  name,  SDB)
   using  a  compact  URL. This allows users to reference a database value
   quickly inside a number of Salt configuration areas, without a  lot  of
   overhead. The basic format of an SDB URI is:

      sdb://<profile>/<args>

   The  profile  refers to the configuration profile defined in either the
   master or the minion configuration file. The args are specific  to  the
   module  referred  to  in  the  profile, but will typically only need to
   refer to the key of a key/value  pair  inside  the  database.  This  is
   because  the  profile  itself should define as many other parameters as
   possible.

   For example, a profile might be set up to reference credentials  for  a
   specific OpenStack account. The profile might look like:

      kevinopenstack:
        driver: keyring
        service: salt.cloud.openstack.kevin

   And the URI used to reference the password might look like:

      sdb://kevinopenstack/password

   Getting, Setting and Deleting SDB Values
   Once  an SDB driver is configured, you can use the sdb execution module
   to get, set and delete values from it. There are two functions that may
   appear in most SDB modules: get, set and delete.

   Getting  a value requires only the SDB URI to be specified. To retrieve
   a value from the kevinopenstack profile above, you would use:

      salt-call sdb.get sdb://kevinopenstack/password

   Some drivers use slightly more complex URIs. For  instance,  the  vault
   driver requires the full path to where the key is stored, followed by a
   question mark, followed by the key to be retrieved.  If you were  using
   a profile called myvault, you would use a URI that looks like:

      salt-call sdb.get 'sdb://myvault/secret/salt?saltstack'

   Setting  a  value  uses  the  same URI as would be used to retrieve it,
   followed by the value as another argument. For the above  myvault  URI,
   you would set a new value using a command like:

      salt-call sdb.set 'sdb://myvault/secret/salt?saltstack' 'super awesome'

   Deleting  values  (if  supported by the driver) is done pretty much the
   same way as getting them. Provided  that  you  have  a  profile  called
   mykvstore that uses a driver allowing to delete values you would delete
   a value as shown bellow:

      salt-call sdb.delete 'sdb://mykvstore/foobar'

   The sdb.get, sdb.set and sdb.delete functions are also available in the
   runner system:

      salt-run sdb.get 'sdb://myvault/secret/salt?saltstack'
      salt-run sdb.set 'sdb://myvault/secret/salt?saltstack' 'super awesome'
      salt-run sdb.delete 'sdb://mykvstore/foobar'

   Using SDB URIs in Files
   SDB  URIs  can  be used in both configuration files, and files that are
   processed  by  the  renderer  system  (jinja,   mako,   etc.).   In   a
   configuration   file   (such   as  /etc/salt/master,  /etc/salt/minion,
   /etc/salt/cloud, etc.), make an entry as usual, and set  the  value  to
   the SDB URI. For instance:

      mykey: sdb://myetcd/mykey

   To  retrieve this value using a module, the module in question must use
   the config.get function to retrieve configuration  values.  This  would
   look something like:

      mykey = __salt__['config.get']('mykey')

   Templating  renderers  use  a similar construct. To get the mykey value
   from above in Jinja, you would use:

      {{ salt['config.get']('mykey') }}

   When retrieving data from configuration files using config.get, the SDB
   URI need only appear in the configuration file itself.

   If  you  would like to retrieve a key directly from SDB, you would call
   the sdb.get function directly, using the  SDB  URI.  For  instance,  in
   Jinja:

      {{ salt['sdb.get']('sdb://myetcd/mykey') }}

   When  writing  Salt  modules,  it  is  not  recommended to call sdb.get
   directly, as it requires the user to provide values  in  SDB,  using  a
   specific URI. Use config.get instead.

   Writing SDB Modules
   There  is  currently  one  function  that  MUST exist in any SDB module
   (get()), one  that  SHOULD  exist  (set_())  and  one  that  MAY  exist
   (delete()).  If  using a (set_()) function, a __func_alias__ dictionary
   MUST be declared in the module as well:

      __func_alias__ = {
          'set_': 'set',
      }

   This is because set is  a  Python  built-in,  and  therefore  functions
   should  not  be  created  which  are  called  set(). The __func_alias__
   functionality is provided via  Salt's  loader  interfaces,  and  allows
   legally-named  functions  to  be  referred  to  using  names that would
   otherwise be unwise to use.

   The get() function is required, as it will be called via  functions  in
   other  areas of the code which make use of the sdb:// URI. For example,
   the config.get function  in  the  config  execution  module  uses  this
   function.

   The  set_()  function  may  be  provided,  but is not required, as some
   sources may be read-only, or may be otherwise unwise to  access  via  a
   URI (for instance, because of SQL injection attacks).

   The  delete() function may be provided as well, but is not required, as
   many sources may be read-only or restrict such operations.

   A simple example of an SDB  module  is  salt/sdb/keyring_db.py,  as  it
   provides  basic  examples  of  most,  if  not  all,  of  the  types  of
   functionality that are available not only for SDB modules, but for Salt
   modules in general.

   Running the Salt Master/Minion as an Unprivileged User
   While  the  default  setup runs the master and minion as the root user,
   some may consider it an extra measure of security to run the master  as
   a  non-root  user.  Keep  in  mind  that  doing  so does not change the
   master's capability to access minions as the user they are running  as.
   Due  to  this many feel that running the master as a non-root user does
   not grant any real security advantage  which  is  why  the  master  has
   remained as root by default.

   NOTE:
      Some  of  Salt's operations cannot execute correctly when the master
      is not running as root, specifically the pam external  auth  system,
      as this system needs root access to check authentication.

   As  of  Salt 0.9.10 it is possible to run Salt as a non-root user. This
   can be done by setting the user parameter in the  master  configuration
   file. and restarting the salt-master service.

   The  minion has it's own user parameter as well, but running the minion
   as an unprivileged user will keep it from making changes to things like
   users, installed packages, etc. unless access controls (sudo, etc.) are
   setup on the minion to permit the non-root  user  to  make  the  needed
   changes.

   In  order  to  allow  Salt  to  successfully  run  as  a non-root user,
   ownership, and permissions need to be set such that  the  desired  user
   can  read  from  and  write  to  the  following  directories (and their
   subdirectories, where applicable):

   * /etc/salt

   * /var/cache/salt

   * /var/log/salt

   * /var/run/salt

   Ownership can be easily changed with chown, like so:

      # chown -R user /etc/salt /var/cache/salt /var/log/salt /var/run/salt

   WARNING:
      Running either the master or  minion  with  the  root_dir  parameter
      specified  will  affect  these  paths,  as will setting options like
      pki_dir, cachedir, log_file, and other options that normally live in
      the above directories.

   Using cron with Salt
   The  Salt  Minion  can  initiate  its own highstate using the salt-call
   command.

      $ salt-call state.apply

   This will cause the minion to check in with the master and ensure it is
   in the correct "state".

   Use cron to initiate a highstate
   If you would like the Salt Minion to regularly check in with the master
   you can use cron to run the salt-call command:

      0 0 * * * salt-call state.apply

   The above cron entry will run a highstate every day at midnight.

   NOTE:
      When executing Salt using cron, keep in mind that the  default  PATH
      for  cron  may not include the path for any scripts or commands used
      by Salt, and it may be necessary to set the PATH accordingly in  the
      crontab:

          PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin

          0 0 * * * salt-call state.apply

   Hardening Salt
   This  topic  contains  tips  you can use to secure and harden your Salt
   environment. How you best  secure  and  harden  your  Salt  environment
   depends  heavily on how you use Salt, where you use Salt, how your team
   is structured, where you get  data  from,  and  what  kinds  of  access
   (internal and external) you require.

   General hardening tips
   * Restrict who can directly log into your Salt master system.

   * Use  SSH  keys  secured  with a passphrase to gain access to the Salt
     master system.

   * Track and secure SSH keys and any other  login  credentials  you  and
     your team need to gain access to the Salt master system.

   * Use  a  hardened bastion server or a VPN to restrict direct access to
     the Salt master from the internet.

   * Don't expose the Salt master any more than what is required.

   * Harden the system as you would with any high-priority target.

   * Keep the system patched and up-to-date.

   * Use tight firewall rules.

   Salt hardening tips
   * Subscribe to salt-users or salt-announce so you know  when  new  Salt
     releases  are available. Keep your systems up-to-date with the latest
     patches.

   * Use Salt's Client ACL system to avoid having to give out root  access
     in order to run Salt commands.

   * Use  Salt's  Client  ACL  system to restrict which users can run what
     commands.

   * Use external Pillar to pull data into Salt from external  sources  so
     that  non-sysadmins (other teams, junior admins, developers, etc) can
     provide configuration data without needing access to the Salt master.

   * Make heavy use of  SLS  files  that  are  version-controlled  and  go
     through a peer-review/code-review process before they're deployed and
     run in production.  This  is  good  advice  even  for  "one-off"  CLI
     commands because it helps mitigate typos and mistakes.

   * Use salt-api, SSL, and restrict authentication with the external auth
     system if you need to expose your Salt master to external services.

   * Make use of Salt's event system  and  reactor  to  allow  minions  to
     signal the Salt master without requiring direct access.

   * Run the salt-master daemon as non-root.

   * Disable   which   modules   are   loaded   onto   minions   with  the
     disable_modules setting. (for example, disable the cmd module  if  it
     makes sense in your environment.)

   * Look  through  the  fully-commented  sample  master and minion config
     files. There are many options for securing an installation.

   * Run masterless-mode minions on particularly sensitive minions.  There
     is  also salt-ssh or the modules.sudo if you need to further restrict
     a minion.

   Security disclosure policy
   email  [email protected]

   gpg key ID
          4EA0793D

   gpg key fingerprint
          8ABE 4EFC F0F4 B24B FF2A  AF90 D570 F2D3 4EA0 793D

   gpg public key:

      -----BEGIN PGP PUBLIC KEY BLOCK-----
      Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

      mQINBFO15mMBEADa3CfQwk5ED9wAQ8fFDku277CegG3U1hVGdcxqKNvucblwoKCb
      hRK6u9ihgaO9V9duV2glwgjytiBI/z6lyWqdaD37YXG/gTL+9Md+qdSDeaOa/9eg
      7y+g4P+FvU9HWUlujRVlofUn5Dj/IZgUywbxwEybutuzvvFVTzsn+DFVwTH34Qoh
      QIuNzQCSEz3Lhh8zq9LqkNy91ZZQO1ZIUrypafspH6GBHHcE8msBFgYiNBnVcUFH
      u0r4j1Rav+621EtD5GZsOt05+NJI8pkaC/dDKjURcuiV6bhmeSpNzLaXUhwx6f29
      Vhag5JhVGGNQxlRTxNEM86HEFp+4zJQ8m/wRDrGX5IAHsdESdhP+ljDVlAAX/ttP
      /Ucl2fgpTnDKVHOA00E515Q87ZHv6awJ3GL1veqi8zfsLaag7rw1TuuHyGLOPkDt
      t5PAjsS9R3KI7pGnhqI6bTOi591odUdgzUhZChWUUX1VStiIDi2jCvyoOOLMOGS5
      AEYXuWYP7KgujZCDRaTNqRDdgPd93Mh9JI8UmkzXDUgijdzVpzPjYgFaWtyK8lsc
      Fizqe3/Yzf9RCVX/lmRbiEH+ql/zSxcWlBQd17PKaL+TisQFXcmQzccYgAxFbj2r
      QHp5ABEu9YjFme2Jzun7Mv9V4qo3JF5dmnUk31yupZeAOGZkirIsaWC3hwARAQAB
      tDBTYWx0U3RhY2sgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAc2FsdHN0YWNrLmNv
      bT6JAj4EEwECACgFAlO15mMCGwMFCQeGH4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4B
      AheAAAoJENVw8tNOoHk9z/MP/2vzY27fmVxU5X8joiiturjlgEqQw41IYEmWv1Bw
      4WVXYCHP1yu/1MC1uuvOmOd5BlI8YO2C2oyW7d1B0NorguPtz55b7jabCElekVCh
      h/H4ZVThiwqgPpthRv/2npXjIm7SLSs/kuaXo6Qy2JpszwDVFw+xCRVL0tH9KJxz
      HuNBeVq7abWD5fzIWkmGM9hicG/R2D0RIlco1Q0VNKy8klG+pOFOW886KnwkSPc7
      JUYp1oUlHsSlhTmkLEG54cyVzrTP/XuZuyMTdtyTc3mfgW0adneAL6MARtC5UB/h
      q+v9dqMf4iD3wY6ctu8KWE8Vo5MUEsNNO9EA2dUR88LwFZ3ZnnXdQkizgR/Aa515
      dm17vlNkSoomYCo84eN7GOTfxWcq+iXYSWcKWT4X+h/ra+LmNndQWQBRebVUtbKE
      ZDwKmiQz/5LY5EhlWcuU4lVmMSFpWXt5FR/PtzgTdZAo9QKkBjcv97LYbXvsPI69
      El1BLAg+m+1UpE1L7zJT1il6PqVyEFAWBxW46wXCCkGssFsvz2yRp0PDX8A6u4yq
      rTkt09uYht1is61joLDJ/kq3+6k8gJWkDOW+2NMrmf+/qcdYCMYXmrtOpg/wF27W
      GMNAkbdyzgeX/MbUBCGCMdzhevRuivOI5bu4vT5s3KdshG+yhzV45bapKRd5VN+1
      mZRquQINBFO15mMBEAC5UuLii9ZLz6qHfIJp35IOW9U8SOf7QFhzXR7NZ3DmJsd3
      f6Nb/habQFIHjm3K9wbpj+FvaW2oWRlFVvYdzjUq6c82GUUjW1dnqgUvFwdmM835
      1n0YQ2TonmyaF882RvsRZrbJ65uvy7SQxlouXaAYOdqwLsPxBEOyOnMPSktW5V2U
      IWyxsNP3sADchWIGq9p5D3Y/loyIMsS1dj+TjoQZOKSj7CuRT98+8yhGAY8YBEXu
      9r3I9o6mDkuPpAljuMc8r09Im6az2egtK/szKt4Hy1bpSSBZU4W/XR7XwQNywmb3
      wxjmYT6Od3Mwj0jtzc3gQiH8hcEy3+BO+NNmyzFVyIwOLziwjmEcw62S57wYKUVn
      HD2nglMsQa8Ve0e6ABBMEY7zGEGStva59rfgeh0jUMJiccGiUDTMs0tdkC6knYKb
      u/fdRqNYFoNuDcSeLEw4DdCuP01l2W4yY+fiK6hAcL25amjzc+yYo9eaaqTn6RAT
      bzdhHQZdpAMxY+vNT0+NhP1Zo5gYBMR65Zp/VhFsf67ijb03FUtdw9N8dHwiR2m8
      vVA8kO/gCD6wS2p9RdXqrJ9JhnHYWjiVuXR+f755ZAndyQfRtowMdQIoiXuJEXYw
      6XN+/BX81gJaynJYc0uw0MnxWQX+A5m8HqEsbIFUXBYXPgbwXTm7c4IHGgXXdwAR
      AQABiQIlBBgBAgAPBQJTteZjAhsMBQkHhh+AAAoJENVw8tNOoHk91rcQAIhxLv4g
      duF/J1Cyf6Wixz4rqslBQ7DgNztdIUMjCThg3eB6pvIzY5d3DNROmwU5JvGP1rEw
      hNiJhgBDFaB0J/y28uSci+orhKDTHb/cn30IxfuAuqrv9dujvmlgM7JUswOtLZhs
      5FYGa6v1RORRWhUx2PQsF6ORg22QAaagc7OlaO3BXBoiE/FWsnEQCUsc7GnnPqi7
      um45OJl/pJntsBUKvivEU20fj7j1UpjmeWz56NcjXoKtEvGh99gM5W2nSMLE3aPw
      vcKhS4yRyLjOe19NfYbtID8m8oshUDji0XjQ1z5NdGcf2V1YNGHU5xyK6zwyGxgV
      xZqaWnbhDTu1UnYBna8BiUobkuqclb4T9k2WjbrUSmTwKixokCOirFDZvqISkgmN
      r6/g3w2TRi11/LtbUciF0FN2pd7rj5mWrOBPEFYJmrB6SQeswWNhr5RIsXrQd/Ho
      zvNm0HnUNEe6w5YBfA6sXQy8B0Zs6pcgLogkFB15TuHIIIpxIsVRv5z8SlEnB7HQ
      Io9hZT58yjhekJuzVQB9loU0C/W0lzci/pXTt6fd9puYQe1DG37pSifRG6kfHxrR
      if6nRyrfdTlawqbqdkoqFDmEybAM9/hv3BqriGahGGH/hgplNQbYoXfNwYMYaHuB
      aSkJvrOQW8bpuAzgVyd7TyNFv+t1kLlfaRYJ
      =wBTJ

      -----END PGP PUBLIC KEY BLOCK-----
   The SaltStack Security Team is available at [email protected]  for
   security-related bug reports or questions.

   We  request  the  disclosure  of any security-related bugs or issues be
   reported non-publicly until such time as the issue can be resolved  and
   a  security-fix  release  can be prepared. At that time we will release
   the fix and make a public announcement with  upgrade  instructions  and
   download locations.

   Security response procedure
   SaltStack  takes security and the trust of our customers and users very
   seriously. Our disclosure policy is intended to resolve security issues
   as quickly and safely as is possible.

   1. A  security  report  sent to [email protected] is assigned to a
      team member. This person is the primary contact  for  questions  and
      will coordinate the fix, release, and announcement.

   2. The  reported  issue is reproduced and confirmed. A list of affected
      projects and releases is made.

   3. Fixes are implemented for all affected projects  and  releases  that
      are  actively  supported.  Back-ports of the fix are made to any old
      releases that are actively supported.

   4. Packagers are notified via the salt-packagers mailing list  that  an
      issue  was  reported  and  resolved,  and  that  an  announcement is
      incoming.

   5. A new release is created and pushed to  all  affected  repositories.
      The  release documentation provides a full description of the issue,
      plus any upgrade instructions or other relevant details.

   6. An announcement is made to the salt-users and salt-announce  mailing
      lists.  The  announcement  contains a description of the issue and a
      link to the full release documentation and download locations.

   Receiving security announcements
   The  fastest  place  to  receive  security  announcements  is  via  the
   salt-announce mailing list. This list is low-traffic.

   Salt Transport
   One  of  fundamental features of Salt is remote execution. Salt has two
   basic "channels" for communicating with minions. Each channel  requires
   a  client  (minion) and a server (master) implementation to work within
   Salt. These pairs of channels  will  work  together  to  implement  the
   specific message passing required by the channel interface.

   Pub Channel
   The  pub  channel,  or  publish  channel,  is  how a master sends a job
   (payload) to a minion. This is a  basic  pub/sub  paradigm,  which  has
   specific  targeting  semantics.  All data which goes across the publish
   system should be encrypted such that only members of the  Salt  cluster
   can decrypt the publishes.

   Req Channel
   The  req  channel  is  how  the  minions  send data to the master. This
   interface is primarily  used  for  fetching  files  and  returning  job
   returns. The req channels have two basic interfaces when talking to the
   master. send is  the  basic  method  that  guarantees  the  message  is
   encrypted at least so that only minions attached to the same master can
   read it-- but no guarantee of  minion-master  confidentiality,  whereas
   the    crypted_transfer_decode_dictentry    method    does    guarantee
   minion-master confidentiality.

   Zeromq Transport
   NOTE:
      Zeromq is the current default transport within Salt

   Zeromq is a messaging library with bindings into many languages. Zeromq
   implements  a  socket  interface  for  message  passing,  with specific
   semantics for the socket type.

   Pub Channel
   The pub channel is  implemented  using  zeromq's  pub/sub  sockets.  By
   default  we  don't use zeromq's filtering, which means that all publish
   jobs are sent to all minions and filtered minion side. Zeromq does have
   publisher   side   filtering   which  can  be  enabled  in  salt  using
   zmq_filtering.

   Req Channel
   The req channel is implemented using zeromq's  req/rep  sockets.  These
   sockets  enforce  a  send/recv  pattern, which forces salt to serialize
   messages through these socket  pairs.  This  means  that  although  the
   interface is asynchronous on the minion we cannot send a second message
   until we have received the reply of the first message.

   TCP Transport
   The tcp transport is an implementation of Salt's channels using raw tcp
   sockets.   Since  this  isn't  using a pre-defined messaging library we
   will describe the  wire  protocol,  message  semantics,  etc.  in  this
   document.

   The  tcp  transport is enabled by changing the transport setting to tcp
   on each Salt minion and Salt master.

      transport: tcp

   Wire Protocol
   This implementation over  TCP  focuses  on  flexibility  over  absolute
   efficiency.   This means we are okay to spend a couple of bytes of wire
   space for flexibility in the future. That being said, the wire  framing
   is quite efficient and looks like:

      msgpack({'head': SOMEHEADER, 'body': SOMEBODY})

   Since  msgpack is an iterably parsed serialization, we can simply write
   the serialized payload to the wire. Within that  payload  we  have  two
   items  "head"  and  "body".   Head contains header information (such as
   "message id"). The  Body  contains  the  actual  message  that  we  are
   sending.  With this flexible wire protocol we can implement any message
   semantics that we'd like-- including multiplexed message passing  on  a
   single socket.

   Crypto
   The   current  implementation  uses  the  same  crypto  as  the  zeromq
   transport.

   Pub Channel
   For the pub channel we send messages without "message  ids"  which  the
   remote end interprets as a one-way send.

   NOTE:
      As  of  today  we  send  all  publishes  to  all minions and rely on
      minion-side filtering.

   Req Channel
   For the req channel we send messages with a "message id". This "message
   id" allows us to multiplex messages across the socket.

   The RAET Transport
   NOTE:
      The  RAET  transport  is in very early development, it is functional
      but no promises are yet made as to its reliability or security.   As
      for  reliability  and security, the encryption used has been audited
      and our tests show that raet is reliable.  With  this  said  we  are
      still  conducting  more security audits and pushing the reliability.
      This document outlines the encryption used in RAET

   New in version 2014.7.0.

   The Reliable Asynchronous Event Transport, or RAET, is  an  alternative
   transport  medium developed specifically with Salt in mind. It has been
   developed to allow queuing to happen up on the  application  layer  and
   comes  with  socket layer encryption. It also abstracts a great deal of
   control over the socket layer and makes it easy to bubble up errors and
   exceptions.

   RAET  also  offers very powerful message routing capabilities, allowing
   for messages to be routed between processes on a single machine all the
   way  up  to  processes  on  multiple  machines.  Messages  can  also be
   restricted, allowing processes to be sent messages  of  specific  types
   from specific sources allowing for trust to be established.

   Using RAET in Salt
   Using  RAET  in  Salt  is  easy,  the  main difference is that the core
   dependencies change, instead of needing pycrypto, M2Crypto, ZeroMQ, and
   PYZMQ,  the  packages libsodium, libnacl, ioflo, and raet are required.
   Encryption is handled very cleanly by libnacl, while the  queueing  and
   flow   control   is   handled   by  ioflo.  Distribution  packages  are
   forthcoming, but libsodium can be easily installed from source, or many
   distributions  do ship packages for it.  The libnacl and ioflo packages
   can be easily installed from pypi, distribution  packages  are  in  the
   works.

   Once  the  new  deps are installed the 2014.7 release or higher of Salt
   needs to be installed.

   Once installed, modify the  configuration  files  for  the  minion  and
   master to set the transport to raet:

   /etc/salt/master:

      transport: raet

   /etc/salt/minion:

      transport: raet

   Now start salt as it would normally be started, the minion will connect
   to the master and share long term keys,  which  can  then  in  turn  be
   managed via salt-key. Remote execution and salt states will function in
   the same way as with Salt over ZeroMQ.

   Limitations
   The 2014.7 release of RAET is not complete! The Syndic and Multi Master
   have  not been completed yet and these are slated for completion in the
   2015.5.0 release.

   Also, Salt-Raet allows for more control over the client but these hooks
   have  not  been  implemented  yet, thereforre the client still uses the
   same system as the ZeroMQ client. This means that the extra reliability
   that RAET exposes has not yet been implemented in the CLI client.

   Why?
   Customer and User Request
   Why make an alternative transport for Salt? There are many reasons, but
   the  primary  motivation  came  from  customer  requests,  many   large
   companies came with requests to run Salt over an alternative transport,
   the reasoning was varied, from performance and scaling improvements  to
   licensing  concerns.  These  customers have partnered with SaltStack to
   make RAET a reality.

   More Capabilities
   RAET has been designed to allow  salt  to  have  greater  communication
   capabilities.  It  has  been  designed  to  allow  for development into
   features which out ZeroMQ topologies can't match.

   Many of the proposed features are still under development and  will  be
   announced  as  they  enter  proof of concept phases, but these features
   include salt-fuse - a filesystem over salt, salt-vt -  a  parallel  api
   driven shell over the salt transport and many others.

   RAET Reliability
   RAET   is   reliable,  hence  the  name  (Reliable  Asynchronous  Event
   Transport).

   The concern posed by some over RAET reliability is based  on  the  fact
   that  RAET  uses  UDP  instead  of  TCP  and UDP does not have built in
   reliability.

   RAET itself implements the  needed  reliability  layers  that  are  not
   natively  present  in  UDP,  this  allows  RAET to dynamically optimize
   packet delivery in a way that keeps it both reliable and asynchronous.

   RAET and ZeroMQ
   When using RAET, ZeroMQ is not required. RAET is a complete  networking
   replacement.  It is noteworthy that RAET is not a ZeroMQ replacement in
   a general sense, the ZeroMQ constructs are not reproduced in RAET,  but
   they  are  instead implemented in such a way that is specific to Salt's
   needs.

   RAET is  primarily  an  async  communication  layer  over  truly  async
   connections,  defaulting to UDP. ZeroMQ is over TCP and abstracts async
   constructs within the socket layer.

   Salt is not dropping ZeroMQ support and has no immediate  plans  to  do
   so.

   Encryption
   RAET  uses  Dan  Bernstein's  NACL  encryption  libraries  and  CurveCP
   handshake.  The libnacl python binding  binds  to  both  libsodium  and
   tweetnacl  to  execute  the  underlying cryptography. This allows us to
   completely rely on an externally developed cryptography system.

   Programming Intro
   Intro to RAET Programming
   NOTE:
      This page is still under construction

   The first thing to cover is that RAET does not present a socket api, it
   presents,  and queueing api, all messages in RAET are made available to
   via queues. This is the single most differentiating factor with RAET vs
   other  networking  libraries,  instead  of  making a socket, a stack is
   created.  Instead of calling send() or recv(), messages are  placed  on
   the  stack  to  be  sent  and  messages that are received appear on the
   stack.

   Different kinds of stacks are  also  available,  currently  two  stacks
   exist,  the  UDP  stack,  and  the  UXD stack. The UDP stack is used to
   communicate over udp sockets, and the UXD stack is used to  communicate
   over Unix Domain Sockets.

   The UDP stack runs a context for communicating over networks, while the
   UXD stack has contexts for communicating between processes.

   UDP Stack Messages
   To create a UDP stack in RAET, simply  create  the  stack,  manage  the
   queues, and process messages:

      from salt.transport.road.raet import stacking
      from salt.transport.road.raet import estating

      udp_stack = stacking.StackUdp(ha=('127.0.0.1', 7870))
      r_estate = estating.Estate(stack=stack, name='foo', ha=('192.168.42.42', 7870))
      msg = {'hello': 'world'}
      udp_stack.transmit(msg, udp_stack.estates[r_estate.name])
      udp_stack.serviceAll()

   Master Tops System
   In  0.10.4  the external_nodes system was upgraded to allow for modular
   subsystems to be used to generate the top file data for a highstate run
   on the master.

   The old external_nodes option has been removed.  The master tops system
   contains a number of subsystems that are loaded  via  the  Salt  loader
   interfaces like modules, states, returners, runners, etc.

   Using the new master_tops option is simple:

      master_tops:
        ext_nodes: cobbler-external-nodes

   for Cobbler or:

      master_tops:
        reclass:
          inventory_base_uri: /etc/reclass
          classes_uri: roles

   for Reclass.

      master_tops:
        varstack: /path/to/the/config/file/varstack.yaml

   for Varstack.

   It's  also possible to create custom master_tops modules. These modules
   must  go  in  a  subdirectory  called  tops  in  the  extension_modules
   directory.   The  extension_modules directory is not defined by default
   (the default /srv/salt/_modules will NOT work as of this release)

   Custom tops modules are written like any other  execution  module,  see
   the  source  for the two modules above for examples of fully functional
   ones. Below is a degenerate example:

   /etc/salt/master:

      extension_modules: /srv/salt/modules
      master_tops:
        customtop: True

   /srv/salt/modules/tops/customtop.py:

      import logging
      import sys
      # Define the module's virtual name
      __virtualname__ = 'customtop'

      log = logging.getLogger(__name__)

      def __virtual__():
          return __virtualname__

      def top(**kwargs):
          log.debug('Calling top in customtop')
          return {'base': ['test']}

   salt minion state.show_top should then display something like:

      $ salt minion state.show_top

      minion
          ----------
          base:
            - test

   Returners
   By default the return values of the commands sent to the  Salt  minions
   are  returned  to  the Salt master, however anything at all can be done
   with the results data.

   By using a Salt returner, results data can be  redirected  to  external
   data-stores for analysis and archival.

   Returners  pull  their  configuration  values  from  the  Salt minions.
   Returners are only configured once, which is generally at load time.

   The returner interface allows the return data to be sent to any  system
   that  can  receive  data.  This means that return data can be sent to a
   Redis server, a MongoDB server, a MySQL server, or any system.

   SEE ALSO:
      Full list of builtin returners

   Using Returners
   All Salt commands will return the command  data  back  to  the  master.
   Specifying  returners  will  ensure that the data is _also_ sent to the
   specified returner interfaces.

   Specifying what returners to use is done when the command is invoked:

      salt '*' test.ping --return redis_return

   This command will ensure that the redis_return returner is used.

   It is also possible to specify multiple returners:

      salt '*' test.ping --return mongo_return,redis_return,cassandra_return

   In this scenario all three returners will be called and the  data  from
   the test.ping command will be sent out to the three named returners.

   Writing a Returner
   A  returner  is  a  Python  module  containing  at  minimum  a returner
   function.  Other optional functions can be included to add support  for
   master_job_cache, external_job_cache, and Event Returners.

   returner
          The  returner  function  must  accept  a  single  argument.  The
          argument contains return data from the called  minion  function.
          If  the  minion  function  test.ping is called, the value of the
          argument will be a dictionary. Run the following command from  a
          Salt master to get a sample of the dictionary:

      salt-call --local --metadata test.ping --out=pprint

      import redis
      import json

      def returner(ret):
          '''
          Return information to a redis server
          '''
          # Get a redis connection
          serv = redis.Redis(
                      host='redis-serv.example.com',
                      port=6379,
                      db='0')
          serv.sadd("%(id)s:jobs" % ret, ret['jid'])
          serv.set("%(jid)s:%(id)s" % ret, json.dumps(ret['return']))
          serv.sadd('jobs', ret['jid'])
          serv.sadd(ret['jid'], ret['id'])

   The  above example of a returner set to send the data to a Redis server
   serializes the data as JSON and sets it in redis.

   Master Job Cache Support
   master_job_cache,  external_job_cache,  and  Event  Returners.   Salt's
   master_job_cache allows returners to be used as a pluggable replacement
   for the default_job_cache. In order to do so, a returner must implement
   the following functions:

   NOTE:
      The  code  samples  contained  in  this  section were taken from the
      cassandra_cql returner.

   prep_jid
          Ensures that job ids (jid) don't collide, unless  passed_jid  is
          provided.

          nochache  is  an  optional boolean that indicates if return data
          should be cached. passed_jid is  a  caller  provided  jid  which
          should be returned unconditionally.

      def prep_jid(nocache, passed_jid=None):  # pylint: disable=unused-argument
          '''
          Do any work necessary to prepare a JID, including sending a custom id
          '''
          return passed_jid if passed_jid is not None else salt.utils.jid.gen_jid()

   save_load
          Save  job  information.   The  jid  is generated by prep_jid and
          should be considered a unique identifier for the job.  The  jid,
          for  example,  could  be  used  as  the  primary/unique key in a
          database. The load is what is returned to a  Salt  master  by  a
          minion.  The  following  code  example stores the load as a JSON
          string in the salt.jids table.

      def save_load(jid, load):
          '''
          Save the load to the specified jid id
          '''
          query = '''INSERT INTO salt.jids (
                       jid, load
                     ) VALUES (
                       '{0}', '{1}'
                     );'''.format(jid, json.dumps(load))

          # cassandra_cql.cql_query may raise a CommandExecutionError
          try:
              __salt__['cassandra_cql.cql_query'](query)
          except CommandExecutionError:
              log.critical('Could not save load in jids table.')
              raise
          except Exception as e:
              log.critical('''Unexpected error while inserting into
               jids: {0}'''.format(str(e)))
              raise

   get_load
          must accept a job id (jid) and return the  job  load  stored  by
          save_load, or an empty dictionary when not found.

      def get_load(jid):
          '''
          Return the load data that marks a specified jid
          '''
          query = '''SELECT load FROM salt.jids WHERE jid = '{0}';'''.format(jid)

          ret = {}

          # cassandra_cql.cql_query may raise a CommandExecutionError
          try:
              data = __salt__['cassandra_cql.cql_query'](query)
              if data:
                  load = data[0].get('load')
                  if load:
                      ret = json.loads(load)
          except CommandExecutionError:
              log.critical('Could not get load from jids table.')
              raise
          except Exception as e:
              log.critical('''Unexpected error while getting load from
               jids: {0}'''.format(str(e)))
              raise

          return ret

   External Job Cache Support
   Salt's  external_job_cache  extends  the master_job_cache. External Job
   Cache support requires the following functions in addition to  what  is
   required for Master Job Cache support:

   get_jid
          Return  a  dictionary containing the information (load) returned
          by each minion when the specified job id was executed.

   Sample:

      {
          "local": {
              "master_minion": {
                  "fun_args": [],
                  "jid": "20150330121011408195",
                  "return": true,
                  "retcode": 0,
                  "success": true,
                  "cmd": "_return",
                  "_stamp": "2015-03-30T12:10:12.708663",
                  "fun": "test.ping",
                  "id": "master_minion"
              }
          }
      }

   get_fun
          Return a dictionary of minions that called a given Salt function
          as their last function call.

   Sample:

      {
          "local": {
              "minion1": "test.ping",
              "minion3": "test.ping",
              "minion2": "test.ping"
          }
      }

   get_jids
          Return a list of all job ids.

   Sample:

      {
          "local": [
              "20150330121011408195",
              "20150330195922139916"
          ]
      }

   get_minions
          Returns a list of minions

   Sample:

      {
           "local": [
               "minion3",
               "minion2",
               "minion1",
               "master_minion"
           ]
      }

   Please  refer  to  one  or  more of the existing returners (i.e. mysql,
   cassandra_cql) if you need further clarification.

   Event Support
   An event_return function must be added to the returner module to  allow
   events  to  be  logged from a master via the returner. A list of events
   are passed to the function by the master.

   The following example was  taken  from  the  MySQL  returner.  In  this
   example, each event is inserted into the salt_events table keyed on the
   event tag. The tag contains the jid and therefore is guaranteed  to  be
   unique.

      def event_return(events):
       '''
       Return event to mysql server

       Requires that configuration be enabled via 'event_return'
       option in master config.
       '''
       with _get_serv(events, commit=True) as cur:
           for event in events:
               tag = event.get('tag', '')
               data = event.get('data', '')
               sql = '''INSERT INTO `salt_events` (`tag`, `data`, `master_id` )
                        VALUES (%s, %s, %s)'''
               cur.execute(sql, (tag, json.dumps(data), __opts__['id']))

   Custom Returners
   Place  custom returners in a _returners directory within the file_roots
   specified by the master config file.

   Custom returners are distributed when any of the following are called:

   * state.apply

   * saltutil.sync_returners

   * saltutil.sync_all

   Any custom returners which have been synced to a minion that are  named
   the  same as one of Salt's default set of returners will take the place
   of the default returner with the same name.

   Naming the Returner
   Note that a returner's  default  name  is  its  filename  (i.e.  foo.py
   becomes  returner  foo), but that its name can be overridden by using a
   __virtual__ function. A good example of this can be found in the  redis
   returner, which is named redis_return.py but is loaded as simply redis:

      try:
          import redis
          HAS_REDIS = True
      except ImportError:
          HAS_REDIS = False

      __virtualname__ = 'redis'

      def __virtual__():
          if not HAS_REDIS:
              return False
          return __virtualname__

   Testing the Returner
   The returner, prep_jid, save_load, get_load, and event_return functions
   can be tested by configuring the master_job_cache and  Event  Returners
   in the master config file and submitting a job to test.ping each minion
   from the master.

   Once you have successfully exercised the Master  Job  Cache  functions,
   test the External Job Cache functions using the ret execution module.

      salt-call ret.get_jids cassandra_cql --output=json
      salt-call ret.get_fun cassandra_cql test.ping --output=json
      salt-call ret.get_minions cassandra_cql --output=json
      salt-call ret.get_jid cassandra_cql 20150330121011408195 --output=json

   Event Returners
   For  maximum  visibility  into  the  history  of  events  across a Salt
   infrastructure, all events seen by a salt master may be logged  to  one
   or more returners.

   To  enable  event logging, set the event_return configuration option in
   the master config to the returner(s) which should be designated as  the
   handler for event returns.

   NOTE:
      Not  all  returners  support event returns. Verify a returner has an
      event_return() function before using.

   NOTE:
      On larger installations, many hundreds of events may be generated on
      a  busy  master  every  second.  Be  certain  to closely monitor the
      storage of  a  given  returner  as  Salt  can  easily  overwhelm  an
      underpowered server with thousands of returns.

   Full List of Returners
   returner modules
             
             carbon_return         Take  data  from  salt and 
                                   "return" it into a  carbon 
                                   receiver                   
             
             cassandra_cql_return  Return data to a cassandra 
                                   server                     
             
             cassandra_return      Return data to a Cassandra 
                                   ColumnFamily               
             
             couchbase_return      Simple     returner    for 
                                   Couchbase.                 
             
             couchdb_return        Simple    returner     for 
                                   CouchDB.                   
             

             django_return         A returner that will infor 
                                   a   Django   system   that 
                                   returns    are   available 
                                   using   Django's    signal 
                                   system.                    
             
             elasticsearch_return  Return    data    to    an 
                                   elasticsearch  server  for 
                                   indexing.                  
             
             etcd_return           Return  data  to  an  etcd 
                                   server or cluster          
             
             hipchat_return        Return   salt   data   via 
                                   hipchat.                   
             
             influxdb_return       Return data to an influxdb 
                                   server.                    
             
             kafka_return          Return  data  to  a  Kafka 
                                   topic                      
             
             local                 The local returner is used 
                                   to   test   the   returner 
                                   interface,  it just prints 
                                   the                        
             
             local_cache           Return data to  local  job 
                                   cache                      
             
             memcache_return       Return  data to a memcache 
                                   server                     
             
             mongo_future_return   Return data to  a  mongodb 
                                   server                     
             
             mongo_return          Return  data  to a mongodb 
                                   server                     
             
             multi_returner        Read/Write        multiple 
                                   returners                  
             
             mysql                 Return  data  to  a  mysql 
                                   server                     
             
             nagios_return         Return salt data to Nagios 
             
             odbc                  Return  data  to  an  ODBC 
                                   compliant server.          
             
             pgjsonb               Return     data    to    a 
                                   PostgreSQL   server   with 
                                   json  data  stored in Pg's 
                                   jsonb data type            
             
             postgres              Return    data    to     a 
                                   postgresql server          
             
             postgres_local_cache  Use  a  postgresql  server 
                                   for the master job cache.  
             
             pushover_returner     Return   salt   data   via 
                                   pushover                ( 
                                   http://www.pushover.net)   
             
             rawfile_json          Take data  from  salt  and 
                                   "return"  it  into  a  raw 
                                   file containing the  json, 
                                   with one line per event.   
             
             redis_return          Return  data  to  a  redis 
                                   server                     
             
             sentry_return         Salt returner that reports 
                                   execution  results back to 
                                   sentry.                    
             
             slack_returner        Return salt data via slack 
             
             sms_return            Return data by SMS.        
             
             smtp_return           Return salt data via email 
             
             splunk                Send json response data to 
                                   Splunk  via the HTTP Event 
                                   Collector                  
             
             sqlite3_return        Insert minion return  data 
                                   into a sqlite3 database    
             

             syslog_return         Return  data  to  the host 
                                   operating system's  syslog 
                                   facility                   
             
             xmpp_return           Return salt data via xmpp  
             

   salt.returners.carbon_return
   Take data from salt and "return" it into a carbon receiver

   Add the following configuration to the minion configuration file:

      carbon.host: <server ip address>
      carbon.port: 2003

   Errors when trying to convert data to numbers may be ignored by setting
   carbon.skip_on_error to True:

      carbon.skip_on_error: True

   By default, data will be sent to carbon using the  plaintext  protocol.
   To use the pickle protocol, set carbon.mode to pickle:

      carbon.mode: pickle

   You  can also specify the pattern used for the metric base path (except
   for virt modules metrics):
          carbon.metric_base_pattern:
          carbon.[minion_id].[module].[function]

   These tokens can used :
          [module]:  salt  module  [function]:  salt function [minion_id]:
          minion id

   Default is :
          carbon.metric_base_pattern: [module].[function].[minion_id]

   Carbon settings may also be configured as:

      carbon:
        host: <server IP or hostname>
        port: <carbon port>
        skip_on_error: True
        mode: (pickle|text)
        metric_base_pattern: <pattern> | [module].[function].[minion_id]

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      alternative.carbon:
        host: <server IP or hostname>
        port: <carbon port>
        skip_on_error: True
        mode: (pickle|text)

   To use the carbon  returner,  append  '--return  carbon'  to  the  salt
   command.

      salt '*' test.ping --return carbon

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return carbon --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return carbon --return_kwargs '{"skip_on_error": False}'

   salt.returners.carbon_return.event_return(events)
          Return event data to remote carbon server

          Provide a list of events to be stored in carbon

   salt.returners.carbon_return.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.carbon_return.returner(ret)
          Return data to a remote carbon  server  using  the  text  metric
          protocol

          Each metric will look like:

             [module].[function].[minion_id].[metric path [...]].[metric name]

   salt.returners.cassandra_cql_return
   Return data to a cassandra server

   New in version 2015.5.0.

   maintainer
          Corin Kochenower<[email protected]>

   maturity
          new as of 2015.2

   depends
          salt.modules.cassandra_cql

   depends
          DataStax      Python     Driver     for     Apache     Cassandra
          https://github.com/datastax/python-driver      pip       install
          cassandra-driver

   platform
          all

   configuration
          To  enable  this  returner,  the  minion  will need the DataStax
          Python      Driver      for       Apache       Cassandra       (
          https://github.com/datastax/python-driver  )  installed  and the
          following values configured in the minion or master config.  The
          list  of cluster IPs must include at least one cassandra node IP
          address. No assumption or default will be used for  the  cluster
          IPs.   The  cluster  IPs  will be tried in the order listed. The
          port, username, and password values  shown  below  will  be  the
          assumed defaults if you do not provide values.:

             cassandra:
               cluster:
                 - 192.168.50.11
                 - 192.168.50.12
                 - 192.168.50.13
               port: 9042
               username: salt
               password: salt

          Use the following cassandra database schema:

             CREATE KEYSPACE IF NOT EXISTS salt
                 WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 1};

             CREATE USER IF NOT EXISTS salt WITH PASSWORD 'salt' NOSUPERUSER;

             GRANT ALL ON KEYSPACE salt TO salt;

             USE salt;

             CREATE TABLE IF NOT EXISTS salt.salt_returns (
                 jid text,
                 minion_id text,
                 fun text,
                 alter_time timestamp,
                 full_ret text,
                 return text,
                 success boolean,
                 PRIMARY KEY (jid, minion_id, fun)
             ) WITH CLUSTERING ORDER BY (minion_id ASC, fun ASC);
             CREATE INDEX IF NOT EXISTS salt_returns_minion_id ON salt.salt_returns (minion_id);
             CREATE INDEX IF NOT EXISTS salt_returns_fun ON salt.salt_returns (fun);

             CREATE TABLE IF NOT EXISTS salt.jids (
                 jid text PRIMARY KEY,
                 load text
             );

             CREATE TABLE IF NOT EXISTS salt.minions (
                 minion_id text PRIMARY KEY,
                 last_fun text
             );
             CREATE INDEX IF NOT EXISTS minions_last_fun ON salt.minions (last_fun);

             CREATE TABLE IF NOT EXISTS salt.salt_events (
                 id timeuuid,
                 tag text,
                 alter_time timestamp,
                 data text,
                 master_id text,
                 PRIMARY KEY (id, tag)
             ) WITH CLUSTERING ORDER BY (tag ASC);
             CREATE INDEX tag ON salt.salt_events (tag);

   Required python modules: cassandra-driver

   To  use  the cassandra returner, append '--return cassandra_cql' to the
   salt command. ex:

      salt '*' test.ping --return_cql cassandra

   Note: if your Cassandra instance  has  not  been  tuned  much  you  may
   benefit from altering some timeouts in cassandra.yaml like so:

      # How long the coordinator should wait for read operations to complete
      read_request_timeout_in_ms: 5000
      # How long the coordinator should wait for seq or index scans to complete
      range_request_timeout_in_ms: 20000
      # How long the coordinator should wait for writes to complete
      write_request_timeout_in_ms: 20000
      # How long the coordinator should wait for counter writes to complete
      counter_write_request_timeout_in_ms: 10000
      # How long a coordinator should continue to retry a CAS operation
      # that contends with other proposals for the same row
      cas_contention_timeout_in_ms: 5000
      # How long the coordinator should wait for truncates to complete
      # (This can be much longer, because unless auto_snapshot is disabled
      # we need to flush first so we can snapshot before removing the data.)
      truncate_request_timeout_in_ms: 60000
      # The default timeout for other, miscellaneous operations
      request_timeout_in_ms: 20000

   As  always,  your  mileage may vary and your Cassandra cluster may have
   different needs.  SaltStack has seen situations  where  these  timeouts
   can  resolve  some  stacktraces  that  appear to come from the Datastax
   Python driver.

   salt.returners.cassandra_cql_return.event_return(events)
          Return event to one  of  potentially  many  clustered  cassandra
          nodes

          Requires that configuration be enabled via 'event_return' option
          in master config.

          Cassandra does not support an auto-increment feature due to  the
          highly inefficient nature of creating a monotonically increasing
          number across all nodes in a distributed  database.  Each  event
          will be assigned a uuid by the connecting client.

   salt.returners.cassandra_cql_return.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.cassandra_cql_return.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.cassandra_cql_return.get_jids()
          Return a list of all job ids

   salt.returners.cassandra_cql_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.cassandra_cql_return.get_minions()
          Return a list of minions

   salt.returners.cassandra_cql_return.prep_jid(nocache, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.cassandra_cql_return.returner(ret)
          Return data to one of potentially many clustered cassandra nodes

   salt.returners.cassandra_cql_return.save_load(jid, load, minions=None)
          Save the load to the specified jid id

   salt.returners.cassandra_return
   Return data to a Cassandra ColumnFamily

   Here's  an  example  Keyspace / ColumnFamily setup that works with this
   returner:

      create keyspace salt;
      use salt;
      create column family returns
        with key_validation_class='UTF8Type'
        and comparator='UTF8Type'
        and default_validation_class='UTF8Type';

   Required python modules: pycassa
      To use the cassandra returner, append '--return  cassandra'  to  the
      salt command. ex:
          salt '*' test.ping --return cassandra

   salt.returners.cassandra_return.prep_jid(nocache=False,
   passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.cassandra_return.returner(ret)
          Return data to a Cassandra ColumnFamily

   salt.returners.couchbase_return
   Simple  returner  for  Couchbase.  Optional  configuration settings are
   listed below, along with sane defaults.

      couchbase.host:   'salt'
      couchbase.port:   8091
      couchbase.bucket: 'salt'
      couchbase.ttl: 24
      couchbase.password: 'password'
      couchbase.skip_verify_views: False

   To use the couchbase returner, append '--return couchbase' to the  salt
   command. ex:

      salt '*' test.ping --return couchbase

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return couchbase --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return couchbase --return_kwargs '{"bucket": "another-salt"}'

   All of the return data will be stored in documents as follows:

   JID
   load: load obj tgt_minions: list of minions targeted nocache: should we
   not cache the return data

   JID/MINION_ID
   return: return_data full_ret: full load of job return

   salt.returners.couchbase_return.get_jid(jid)
          Return the information returned when the specified  job  id  was
          executed

   salt.returners.couchbase_return.get_jids()
          Return a list of all job ids

   salt.returners.couchbase_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.couchbase_return.prep_jid(nocache=False,
   passed_jid=None)
          Return a job id and prepare the job id  directory  This  is  the
          function  responsible for making sure jids don't collide (unless
          its passed a jid) So do what you have to do to  make  sure  that
          stays the case

   salt.returners.couchbase_return.returner(load)
          Return data to couchbase bucket

   salt.returners.couchbase_return.save_load(jid, clear_load, minion=None)
          Save the load to the specified jid

   salt.returners.couchbase_return.save_minions(jid,              minions,
   syndic_id=None)
          Save/update the minion list  for  a  given  jid.  The  syndic_id
          argument is included for API compatibility only.

   salt.returners.couchdb_return
   Simple returner for CouchDB. Optional configuration settings are listed
   below, along with sane defaults:

      couchdb.db: 'salt'
      couchdb.url: 'http://salt:5984/'

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      alternative.couchdb.db: 'salt'
      alternative.couchdb.url: 'http://salt:5984/'

   To use the couchdb  returner,  append  --return  couchdb  to  the  salt
   command. Example:

      salt '*' test.ping --return couchdb

   To   use   the   alternative   configuration,   append  --return_config
   alternative to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return couchdb --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return couchdb --return_kwargs '{"db": "another-salt"}'

   On concurrent database access
   As  this  returner  creates  a couchdb document with the salt job id as
   document id and as only one document with a given id  can  exist  in  a
   given couchdb database, it is advised for most setups that every minion
   be configured to write to it own database (the value of couchdb.db  may
   be  suffixed  with the minion id), otherwise multi-minion targeting can
   lead to losing output:

   * the first returning minion is  able  to  create  a  document  in  the
     database

   * other minions fail with {'error': 'HTTP Error 409: Conflict'}

   salt.returners.couchdb_return.ensure_views()
          This function makes sure that all the views that should exist in
          the design document do exist.

   salt.returners.couchdb_return.get_fun(fun)
          Return a dict with key being minion  and  value  being  the  job
          details of the last run of function 'fun'.

   salt.returners.couchdb_return.get_jid(jid)
          Get the document with a given JID.

   salt.returners.couchdb_return.get_jids()
          List all the jobs that we have..

   salt.returners.couchdb_return.get_minions()
          Return a list of minion identifiers from a request of the view.

   salt.returners.couchdb_return.get_valid_salt_views()
          Returns  a  dict object of views that should be part of the salt
          design document.

   salt.returners.couchdb_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.couchdb_return.returner(ret)
          Take in the return and shove it into the couchdb database.

   salt.returners.couchdb_return.set_salt_view()
          Helper  function  that  sets  the  salt  design  document.  Uses
          get_valid_salt_views and some hardcoded values.

   salt.returners.django_return
   A returner that will infor a Django system that returns  are  available
   using Django's signal system.

   https://docs.djangoproject.com/en/dev/topics/signals/

   It  is  up  to the Django developer to register necessary handlers with
   the signals provided by this returner and process returns as necessary.

   The easiest way to use signals is to import  them  from  this  returner
   directly and then use a decorator to register them.

   An   example   Django   module   that   registers   a  function  called
   'returner_callback' with this module's 'returner' function:

      import salt.returners.django_return
      from django.dispatch import receiver

      @receiver(salt.returners.django_return, sender=returner)
      def returner_callback(sender, ret):
          print('I received {0} from {1}'.format(ret, sender))

   salt.returners.django_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom ID

   salt.returners.django_return.returner(ret)
          Signal a Django server that a return is available

   salt.returners.django_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.elasticsearch_return
   Return data to an elasticsearch server for indexing.

   maintainer
          Jurnell   Cockhren   <[email protected]>,   Arnold
          Bechtoldt <[email protected]>

   maturity
          New

   depends
          elasticsearch-py

   platform
          all

   To enable  this  returner  the  elasticsearch  python  client  must  be
   installed on the desired minions (all or some subset).

   Please  see documentation of elasticsearch execution module for a valid
   connection configuration.

   WARNING:
      The index that you wish  to  store  documents  will  be  created  by
      Elasticsearch  automatically  if  doesn't  exist  yet.  It is highly
      recommended to create predefined index  templates  with  appropriate
      mapping(s)  that  will be used by Elasticsearch upon index creation.
      Otherwise you will have problems as described in #20826.

   To use the returner per salt call:

      salt '*' test.ping --return elasticsearch

   In order to have the returner apply to all minions:

      ext_job_cache: elasticsearch

   Minion configuration example:

      elasticsearch:
          hosts:
            - "10.10.10.10:9200"
            - "10.10.10.11:9200"
            - "10.10.10.12:9200"
          index_date: True
          number_of_shards: 5
          number_of_replicas: 1
          functions_blacklist:
            - "test.ping"

   salt.returners.elasticsearch_return.event_return(events)
          Return events to Elasticsearch

          Requires that the event_return configuration be  set  in  master
          config.

   salt.returners.elasticsearch_return.get_load(jid)
          Return the load data that marks a specified jid

          New in version 2015.8.1.

   salt.returners.elasticsearch_return.prep_jid(nocache=False,
   passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.elasticsearch_return.returner(ret)
          Process the return from Salt

   salt.returners.elasticsearch_return.save_load(jid, load, minions=None)
          Save the load to the specified jid id

          New in version 2015.8.1.

   salt.returners.etcd_return
   Return data to an etcd server or cluster

   depends

          * python-etcd

   In  order  to  return to an etcd server, a profile should be created in
   the master configuration file:

      my_etcd_config:
        etcd.host: 127.0.0.1
        etcd.port: 4001

   It is technically possible to configure etcd without using  a  profile,
   but  this  is  not  considered  to  be a best practice, especially when
   multiple etcd servers or clusters are available.

      etcd.host: 127.0.0.1
      etcd.port: 4001

   Additionally, two more options  must  be  specified  in  the  top-level
   configuration in order to use the etcd returner:

      etcd.returner: my_etcd_config
      etcd.returner_root: /salt/return

   The  etcd.returner option specifies which configuration profile to use.
   The etcd.returner_root option specifies the path inside etcd to use  as
   the root of the returner system.

   Once the etcd options are configured, the returner may be used:

   CLI Example:
      salt '*' test.ping --return etcd

   A username and password can be set:

      etcd.username: larry  # Optional; requires etcd.password to be set
      etcd.password: 123pass  # Optional; requires etcd.username to be set

   You can also set a TTL (time to live) value for the returner:

      etcd.ttl: 5

   Authentication  with username and password, and ttl, currently requires
   the master branch of python-etcd.

   You may also specify different roles for  read  and  write  operations.
   First, create the profiles as specified above. Then add:

      etcd.returner_read_profile: my_etcd_read
      etcd.returner_write_profile: my_etcd_write

   salt.returners.etcd_return.get_fun()
          Return a dict of the last function called for all minions

   salt.returners.etcd_return.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.etcd_return.get_jids()
          Return a list of all job ids

   salt.returners.etcd_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.etcd_return.get_minions()
          Return a list of minions

   salt.returners.etcd_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.etcd_return.returner(ret)
          Return data to an etcd server or cluster

   salt.returners.etcd_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.hipchat_return
   Return salt data via hipchat.

   New in version 2015.5.0.

   The following fields can be set in the minion conf file:

      hipchat.room_id (required)
      hipchat.api_key (required)
      hipchat.api_version (required)
      hipchat.api_url (optional)
      hipchat.from_name (required)
      hipchat.color (optional)
      hipchat.notify (optional)
      hipchat.profile (optional)
      hipchat.url (optional)

   NOTE:
      When  using  Hipchat's  API  v2, api_key needs to be assigned to the
      room with the "Label" set to what you would have  been  set  in  the
      hipchat.from_name  field. The v2 API disregards the from_name in the
      data sent for the room notification  and  uses  the  Label  assigned
      through the Hipchat control panel.

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location:

      hipchat.room_id
      hipchat.api_key
      hipchat.api_version
      hipchat.api_url
      hipchat.from_name

   Hipchat settings may also be configured as:

      hipchat:
        room_id: RoomName
        api_url: https://hipchat.myteam.con
        api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        api_version: v1
        from_name: [email protected]

      alternative.hipchat:
        room_id: RoomName
        api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        api_version: v1
        from_name: [email protected]

      hipchat_profile:
        hipchat.api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        hipchat.api_version: v1
        hipchat.from_name: [email protected]

      hipchat:
        profile: hipchat_profile
        room_id: RoomName

      alternative.hipchat:
        profile: hipchat_profile
        room_id: RoomName

      hipchat:
        room_id: RoomName
        api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        api_version: v1
        api_url: api.hipchat.com
        from_name: [email protected]

   To  use  the  HipChat  returner,  append '--return hipchat' to the salt
   command.

      salt '*' test.ping --return hipchat

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return hipchat --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return hipchat --return_kwargs '{"room_id": "another-room"}'

   salt.returners.hipchat_return.event_return(events)
          Return event data to hipchat

   salt.returners.hipchat_return.returner(ret)
          Send an hipchat message with the return data from a job

   salt.returners.influxdb_return
   Return data to an influxdb server.

   New in version 2015.8.0.

   To enable this returner the minion will  need  the  python  client  for
   influxdb installed and the following values configured in the minion or
   master config, these are the defaults:

      influxdb.db: 'salt'
      influxdb.user: 'salt'
      influxdb.password: 'salt'
      influxdb.host: 'localhost'
      influxdb.port: 8086

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      alternative.influxdb.db: 'salt'
      alternative.influxdb.user: 'salt'
      alternative.influxdb.password: 'salt'
      alternative.influxdb.host: 'localhost'
      alternative.influxdb.port: 6379

   To use the influxdb returner, append '--return influxdb'  to  the  salt
   command.

      salt '*' test.ping --return influxdb

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

      salt '*' test.ping --return influxdb --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return influxdb --return_kwargs '{"db": "another-salt"}'

   salt.returners.influxdb_return.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.influxdb_return.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.influxdb_return.get_jids()
          Return a list of all job ids

   salt.returners.influxdb_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.influxdb_return.get_minions()
          Return a list of minions

   salt.returners.influxdb_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.influxdb_return.returner(ret)
          Return data to a influxdb data store

   salt.returners.influxdb_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.kafka_return
   Return data to a Kafka topic

   maintainer
          Christer Edwards ([email protected])

   maturity
          0.1

   depends
          kafka-python

   platform
          all

   To  enable  this returner install kafka-python and enable the following
   settings in the minion config:

      returner.kafka.hostnames:

             * "server1"

             * "server2"

             * "server3"

      returner.kafka.topic: 'topic'

   To use the kafka returner, append '--return kafka' to the Salt command,
   eg;
      salt '*' test.ping --return kafka

   salt.returners.kafka_return.returner(ret)
          Return information to a Kafka server

   salt.returners.local
   The  local  returner  is  used  to test the returner interface, it just
   prints the return data to the console to verify that it is being passed
   properly
      To  use  the  local  returner,  append  '--return local' to the salt
      command. ex:
          salt '*' test.ping --return local

   salt.returners.local.event_return(event)
          Print event return data to the terminal to verify functionality

   salt.returners.local.returner(ret)
          Print the return data to the terminal to verify functionality

   salt.returners.local_cache
   Return data to local job cache

   salt.returners.local_cache.clean_old_jobs()
          Clean out the old jobs from the job cache

   salt.returners.local_cache.get_endtime(jid)
          Retrieve the stored endtime for a given job

          Returns False if no endtime is present

   salt.returners.local_cache.get_jid(jid)
          Return the information returned when the specified  job  id  was
          executed

   salt.returners.local_cache.get_jids()
          Return a dict mapping all job ids to job information

   salt.returners.local_cache.get_jids_filter(count, filter_find_job=True)
          Return  a  list  of  all  jobs information filtered by the given
          criteria.  :param int count: show not more  than  the  count  of
          most  recent  jobs  :param  bool  filter_find_jobs:  filter  out
          'saltutil.find_job' jobs

   salt.returners.local_cache.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.local_cache.load_reg()
          Load the register from msgpack files

   salt.returners.local_cache.prep_jid(nocache=False,     passed_jid=None,
   recurse_count=0)
          Return a job id and prepare the job id directory.

          This  is  the  function  responsible  for making sure jids don't
          collide (unless it is passed a jid).  So do what you have to  do
          to make sure that stays the case

   salt.returners.local_cache.returner(load)
          Return data to the local job cache

   salt.returners.local_cache.save_load(jid,   clear_load,   minions=None,
   recurse_count=0)
          Save the load to the specified jid

          minions argument is to provide a pre-computed  list  of  matched
          minions  for the job, for cases when this function can't compute
          that list itself (such as for salt-ssh)

   salt.returners.local_cache.save_minions(jid, minions, syndic_id=None)
          Save/update the serialized list of minions for a given job

   salt.returners.local_cache.save_reg(data)
          Save the register to msgpack files

   salt.returners.local_cache.update_endtime(jid, time)
          Update (or store) the end time for a given job

          Endtime is stored as a plain text string

   salt.returners.memcache_return
   Return data to a memcache server

   To enable this returner the minion will  need  the  python  client  for
   memcache installed and the following values configured in the minion or
   master config, these are the defaults.

      memcache.host: 'localhost'
      memcache.port: '11211'

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location.

      alternative.memcache.host: 'localhost'
      alternative.memcache.port: '11211'

   python2-memcache uses 'localhost' and '11211' as syntax on connection.

   To use the memcache returner, append '--return memcache'  to  the  salt
   command.

      salt '*' test.ping --return memcache

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return memcache --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return memcache --return_kwargs '{"host": "hostname.domain.com"}'

   salt.returners.memcache_return.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.memcache_return.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.memcache_return.get_jids()
          Return a list of all job ids

   salt.returners.memcache_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.memcache_return.get_minions()
          Return a list of minions

   salt.returners.memcache_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.memcache_return.returner(ret)
          Return data to a memcache data store

   salt.returners.memcache_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.mongo_future_return
   Return data to a mongodb server

   Required python modules: pymongo

   This  returner  will send data from the minions to a MongoDB server. To
   configure the settings for your MongoDB server, add the following lines
   to the minion config files:

      mongo.db: <database name>
      mongo.host: <server ip address>
      mongo.user: <MongoDB username>
      mongo.password: <MongoDB user password>
      mongo.port: 27017

   You  can  also ask for indexes creation on the most common used fields,
   which should greatly improve performance. Indexes are  not  created  by
   default.

      mongo.indexes: true

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location:

      alternative.mongo.db: <database name>
      alternative.mongo.host: <server ip address>
      alternative.mongo.user: <MongoDB username>
      alternative.mongo.password: <MongoDB user password>
      alternative.mongo.port: 27017

   This  mongo  returner is being developed to replace the default mongodb
   returner in the future and should not be considered API stable yet.

   To use the mongo returner, append '--return mongo' to the salt command.

      salt '*' test.ping --return mongo

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return mongo --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return mongo --return_kwargs '{"db": "another-salt"}'

   salt.returners.mongo_future_return.event_return(events)
          Return events to Mongodb server

   salt.returners.mongo_future_return.get_fun(fun)
          Return the  most  recent  jobs  that  have  executed  the  named
          function

   salt.returners.mongo_future_return.get_jid(jid)
          Return the return information associated with a jid

   salt.returners.mongo_future_return.get_jids()
          Return a list of job ids

   salt.returners.mongo_future_return.get_load(jid)
          Return the load associated with a given job id

   salt.returners.mongo_future_return.get_minions()
          Return a list of minions

   salt.returners.mongo_future_return.prep_jid(nocache=False,
   passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.mongo_future_return.returner(ret)
          Return data to a mongodb server

   salt.returners.mongo_future_return.save_load(jid, load, minions=None)
          Save the load for a given job id

   salt.returners.mongo_return
   Return data to a mongodb server

   Required python modules: pymongo

   This  returner  will send data from the minions to a MongoDB server. To
   configure the settings for your MongoDB server, add the following lines
   to the minion config files.

      mongo.db: <database name>
      mongo.host: <server ip address>
      mongo.user: <MongoDB username>
      mongo.password: <MongoDB user password>
      mongo.port: 27017

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location.

      alternative.mongo.db: <database name>
      alternative.mongo.host: <server ip address>
      alternative.mongo.user: <MongoDB username>
      alternative.mongo.password: <MongoDB user password>
      alternative.mongo.port: 27017

   To use the mongo returner, append '--return mongo' to the salt command.

      salt '*' test.ping --return mongo_return

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return mongo_return --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return mongo --return_kwargs '{"db": "another-salt"}'

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return mongo --return_kwargs '{"db": "another-salt"}'

   salt.returners.mongo_return.get_fun(fun)
          Return the  most  recent  jobs  that  have  executed  the  named
          function

   salt.returners.mongo_return.get_jid(jid)
          Return the return information associated with a jid

   salt.returners.mongo_return.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.mongo_return.returner(ret)
          Return data to a mongodb server

   salt.returners.multi_returner
   Read/Write multiple returners

   salt.returners.multi_returner.clean_old_jobs()
          Clean out the old jobs from all returners (if you have it)

   salt.returners.multi_returner.get_jid(jid)
          Merge the return data from all returners

   salt.returners.multi_returner.get_jids()
          Return all job data from all returners

   salt.returners.multi_returner.get_load(jid)
          Merge the load data from all returners

   salt.returners.multi_returner.prep_jid(nocache=False, passed_jid=None)
          Call both with prep_jid on all returners in multi_returner

          TODO: finish this, what do do when you get different jids from 2
          returners...   since  our  jids  are  time based, this make this
          problem hard, because they aren't unique, meaning that  we  have
          to  make  sure  that  no one else got the jid and if they did we
          spin to get a new one,  which  means  "locking"  the  jid  in  2
          returners is non-trivial

   salt.returners.multi_returner.returner(load)
          Write return to all returners in multi_returner

   salt.returners.multi_returner.save_load(jid, clear_load, minions=None)
          Write load to all returners in multi_returner

   salt.returners.mysql
   Return data to a mysql server

   maintainer
          Dave     Boucha     <[email protected]>,    Seth    House    <
          [email protected]>

   maturity
          mature

   depends
          python-mysqldb

   platform
          all

   To enable this returner, the minion will need  the  python  client  for
   mysql  installed  and  the following values configured in the minion or
   master config. These are the defaults:

      mysql.host: 'salt'
      mysql.user: 'salt'
      mysql.pass: 'salt'
      mysql.db: 'salt'
      mysql.port: 3306

   SSL is optional. The defaults are set to None. If you do  not  want  to
   use SSL, either exclude these options or set them to None.

      mysql.ssl_ca: None
      mysql.ssl_cert: None
      mysql.ssl_key: None

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration  with  alternative..  Any  values  not   found   in   the
   alternative  configuration will be pulled from the default location. As
   stated above, SSL configuration is optional. The following ssl  options
   are simply for illustration purposes:

      alternative.mysql.host: 'salt'
      alternative.mysql.user: 'salt'
      alternative.mysql.pass: 'salt'
      alternative.mysql.db: 'salt'
      alternative.mysql.port: 3306
      alternative.mysql.ssl_ca: '/etc/pki/mysql/certs/localhost.pem'
      alternative.mysql.ssl_cert: '/etc/pki/mysql/certs/localhost.crt'
      alternative.mysql.ssl_key: '/etc/pki/mysql/certs/localhost.key'

   Should you wish the returner data to be cleaned out every so often, set
   keep_jobs to the number of hours for the jobs to live  in  the  tables.
   Setting  it to 0 or leaving it unset will cause the data to stay in the
   tables.

   Should you wish  to  archive  jobs  in  a  different  table  for  later
   processing,  set  archive_jobs  to  True.   Salt  will create 3 archive
   tables

   * jids_archive

   * salt_returns_archive

   * salt_events_archive

   and move the contents of jids, salt_returns, and salt_events  that  are
   more than keep_jobs hours old to these tables.

   Use the following mysql database schema:

      CREATE DATABASE  `salt`
        DEFAULT CHARACTER SET utf8
        DEFAULT COLLATE utf8_general_ci;

      USE `salt`;

      --
      -- Table structure for table `jids`
      --

      DROP TABLE IF EXISTS `jids`;
      CREATE TABLE `jids` (
        `jid` varchar(255) NOT NULL,
        `load` mediumtext NOT NULL,
        UNIQUE KEY `jid` (`jid`)
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
      CREATE INDEX jid ON jids(jid) USING BTREE;

      --
      -- Table structure for table `salt_returns`
      --

      DROP TABLE IF EXISTS `salt_returns`;
      CREATE TABLE `salt_returns` (
        `fun` varchar(50) NOT NULL,
        `jid` varchar(255) NOT NULL,
        `return` mediumtext NOT NULL,
        `id` varchar(255) NOT NULL,
        `success` varchar(10) NOT NULL,
        `full_ret` mediumtext NOT NULL,
        `alter_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        KEY `id` (`id`),
        KEY `jid` (`jid`),
        KEY `fun` (`fun`)
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

      --
      -- Table structure for table `salt_events`
      --

      DROP TABLE IF EXISTS `salt_events`;
      CREATE TABLE `salt_events` (
      `id` BIGINT NOT NULL AUTO_INCREMENT,
      `tag` varchar(255) NOT NULL,
      `data` mediumtext NOT NULL,
      `alter_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
      `master_id` varchar(255) NOT NULL,
      PRIMARY KEY (`id`),
      KEY `tag` (`tag`)
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

   Required python modules: MySQLdb

   To use the mysql returner, append '--return mysql' to the salt command.

      salt '*' test.ping --return mysql

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return mysql --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return mysql --return_kwargs '{"db": "another-salt"}'

   salt.returners.mysql.clean_old_jobs()
          Called in the master's event loop every loop_interval.  Archives
          and/or deletes the events and job  details  from  the  database.
          :return:

   salt.returners.mysql.event_return(events)
          Return event to mysql server

          Requires that configuration be enabled via 'event_return' option
          in master config.

   salt.returners.mysql.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.mysql.get_jid(jid)
          Return the information returned when the specified  job  id  was
          executed

   salt.returners.mysql.get_jids()
          Return a list of all job ids

   salt.returners.mysql.get_jids_filter(count, filter_find_job=True)
          Return  a  list  of  all job ids :param int count: show not more
          than the count of most recent jobs :param bool filter_find_jobs:
          filter out 'saltutil.find_job' jobs

   salt.returners.mysql.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.mysql.get_minions()
          Return a list of minions

   salt.returners.mysql.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.mysql.returner(ret)
          Return data to a mysql server

   salt.returners.mysql.save_load(jid, load, minions=None)
          Save the load to the specified jid id

   salt.returners.nagios_return
   Return salt data to Nagios

   The following fields can be set in the minion conf file:

      nagios.url (required)
      nagios.token (required)
      nagios.service (optional)
      nagios.check_type (optional)

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      nagios.url
      nagios.token
      nagios.service

   Nagios settings may also be configured as:

        nagios:
            url: http://localhost/nrdp
            token: r4nd0mt0k3n
            service: service-check

        alternative.nagios:
            url: http://localhost/nrdp
            token: r4nd0mt0k3n
            service: another-service-check

      To use the Nagios returner, append '--return nagios' to the salt command. ex:

      .. code-block:: bash

        salt '*' test.ping --return nagios

      To use the alternative configuration, append '--return_config alternative' to the salt command. ex:

        salt '*' test.ping --return nagios --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return nagios --return_kwargs '{"service": "service-name"}'

   salt.returners.nagios_return.returner(ret)
          Send a message to Nagios with the data

   salt.returners.odbc
   Return  data  to  an  ODBC compliant server.  This driver was developed
   with Microsoft SQL Server in mind, but theoretically could be  used  to
   return  data  to  any  compliant  ODBC  database  as long as there is a
   working ODBC driver for it on your minion platform.

   maintainer

          C.

             R. Oldham ([email protected])

   maturity
          New

   depends
          unixodbc, pyodbc, freetds (for SQL Server)

   platform
          all

   To enable this returner the minion will need

   On Linux:
      unixodbc (http://www.unixodbc.org) pyodbc (pip install  pyodbc)  The
      FreeTDS  ODBC  driver  for  SQL  Server  (http://www.freetds.org) or
      another compatible ODBC driver

   On Windows:
      TBD

   unixODBC and FreeTDS need to be configured  via  /etc/odbcinst.ini  and
   /etc/odbc.ini.

   /etc/odbcinst.ini:

      [TDS]
      Description=TDS
      Driver=/usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so

   (Note  the  above  Driver  line  needs  to point to the location of the
   FreeTDS shared library.  This example is for Ubuntu 14.04.)

   /etc/odbc.ini:

      [TS]
      Description = "Salt Returner"
      Driver=TDS
      Server = <your server ip or fqdn>
      Port = 1433
      Database = salt
      Trace = No

   Also you need the following values configured in the minion  or  master
   config.  Configure as you see fit:

      returner.odbc.dsn: 'TS'
      returner.odbc.user: 'salt'
      returner.odbc.passwd: 'salt'

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location:

      alternative.returner.odbc.dsn: 'TS'
      alternative.returner.odbc.user: 'salt'
      alternative.returner.odbc.passwd: 'salt'

   Running  the  following  commands  against  Microsoft SQL Server in the
   desired database as the appropriate user  should  create  the  database
   tables correctly.  Replace with equivalent SQL for other ODBC-compliant
   servers

        --
        -- Table structure for table 'jids'
        --

        if OBJECT_ID('dbo.jids', 'U') is not null
            DROP TABLE dbo.jids

        CREATE TABLE dbo.jids (
           jid   varchar(255) PRIMARY KEY,
           load  varchar(MAX) NOT NULL
         );

        --
        -- Table structure for table 'salt_returns'
        --
        IF OBJECT_ID('dbo.salt_returns', 'U') IS NOT NULL
            DROP TABLE dbo.salt_returns;

        CREATE TABLE dbo.salt_returns (
           added     datetime not null default (getdate()),
           fun       varchar(100) NOT NULL,
           jid       varchar(255) NOT NULL,
           retval    varchar(MAX) NOT NULL,
           id        varchar(255) NOT NULL,
           success   bit default(0) NOT NULL,
           full_ret  varchar(MAX)
         );

        CREATE INDEX salt_returns_added on dbo.salt_returns(added);
        CREATE INDEX salt_returns_id on dbo.salt_returns(id);
        CREATE INDEX salt_returns_jid on dbo.salt_returns(jid);
        CREATE INDEX salt_returns_fun on dbo.salt_returns(fun);

      To use this returner, append '--return odbc' to the salt command.

      .. code-block:: bash

        salt '*' status.diskusage --return odbc

      To use the alternative configuration, append '--return_config alternative' to the salt command.

      .. versionadded:: 2015.5.0

      .. code-block:: bash

        salt '*' test.ping --return odbc --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return odbc --return_kwargs '{"dsn": "dsn-name"}'

   salt.returners.odbc.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.odbc.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.odbc.get_jids()
          Return a list of all job ids

   salt.returners.odbc.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.odbc.get_minions()
          Return a list of minions

   salt.returners.odbc.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.odbc.returner(ret)
          Return data to an odbc server

   salt.returners.odbc.save_load(jid, load, minions=None)
          Save the load to the specified jid id

   salt.returners.pgjsonb
   Return  data to a PostgreSQL server with json data stored in Pg's jsonb
   data type

   maintainer
          Dave    Boucha    <[email protected]>,    Seth     House     <
          [email protected]>, C. R. Oldham <[email protected]>

   maturity
          new

   depends
          python-psycopg2

   platform
          all

   To  enable  this  returner,  the minion will need the python client for
   PostgreSQL installed and the following values configured in the  minion
   or master config. These are the defaults:

      returner.pgjsonb.host: 'salt'
      returner.pgjsonb.user: 'salt'
      returner.pgjsonb.pass: 'salt'
      returner.pgjsonb.db: 'salt'
      returner.pgjsonb.port: 5432

   SSL  is  optional.  The defaults are set to None. If you do not want to
   use SSL, either exclude these options or set them to None.

      returner.pgjsonb.ssl_ca: None
      returner.pgjsonb.ssl_cert: None
      returner.pgjsonb.ssl_key: None

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration   with   alternative..   Any  values  not  found  in  the
   alternative configuration will be pulled from the default location.  As
   stated  above, SSL configuration is optional. The following ssl options
   are simply for illustration purposes:

      alternative.pgjsonb.host: 'salt'
      alternative.pgjsonb.user: 'salt'
      alternative.pgjsonb.pass: 'salt'
      alternative.pgjsonb.db: 'salt'
      alternative.pgjsonb.port: 5432
      alternative.pgjsonb.ssl_ca: '/etc/pki/mysql/certs/localhost.pem'
      alternative.pgjsonb.ssl_cert: '/etc/pki/mysql/certs/localhost.crt'
      alternative.pgjsonb.ssl_key: '/etc/pki/mysql/certs/localhost.key'

   Use the following Pg database schema:

      CREATE DATABASE  salt
        WITH ENCODING 'utf-8';

      --
      -- Table structure for table `jids`
      --
      DROP TABLE IF EXISTS jids;
      CREATE TABLE jids (
         jid varchar(255) NOT NULL primary key,
         load jsonb NOT NULL
      );
      CREATE INDEX idx_jids_jsonb on jids
             USING gin (load)
             WITH (fastupdate=on);

      --
      -- Table structure for table `salt_returns`
      --

      DROP TABLE IF EXISTS salt_returns;
      CREATE TABLE salt_returns (
        fun varchar(50) NOT NULL,
        jid varchar(255) NOT NULL,
        return jsonb NOT NULL,
        id varchar(255) NOT NULL,
        success varchar(10) NOT NULL,
        full_ret jsonb NOT NULL,
        alter_time TIMESTAMP WITH TIME ZONE DEFAULT NOW());

      CREATE INDEX idx_salt_returns_id ON salt_returns (id);
      CREATE INDEX idx_salt_returns_jid ON salt_returns (jid);
      CREATE INDEX idx_salt_returns_fun ON salt_returns (fun);
      CREATE INDEX idx_salt_returns_return ON salt_returns
          USING gin (return) with (fastupdate=on);
      CREATE INDEX idx_salt_returns_full_ret ON salt_returns
          USING gin (full_ret) with (fastupdate=on);

      --
      -- Table structure for table `salt_events`
      --

      DROP TABLE IF EXISTS salt_events;
      DROP SEQUENCE IF EXISTS seq_salt_events_id;
      CREATE SEQUENCE seq_salt_events_id;
      CREATE TABLE salt_events (
          id BIGINT NOT NULL UNIQUE DEFAULT nextval('seq_salt_events_id'),
          tag varchar(255) NOT NULL,
          data jsonb NOT NULL,
          alter_time TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
          master_id varchar(255) NOT NULL);

      CREATE INDEX idx_salt_events_tag on
          salt_events (tag);
      CREATE INDEX idx_salt_events_data ON salt_events
          USING gin (data) with (fastupdate=on);

   Required python modules: Psycopg2

   To use this returner, append '--return pgjsonb' to the salt command.

      salt '*' test.ping --return pgjsonb

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return pgjsonb --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return pgjsonb --return_kwargs '{"db": "another-salt"}'

   salt.returners.pgjsonb.event_return(events)
          Return event to Pg server

          Requires that configuration be enabled via 'event_return' option
          in master config.

   salt.returners.pgjsonb.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.pgjsonb.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.pgjsonb.get_jids()
          Return a list of all job ids

   salt.returners.pgjsonb.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.pgjsonb.get_minions()
          Return a list of minions

   salt.returners.pgjsonb.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.pgjsonb.returner(ret)
          Return data to a Pg server

   salt.returners.pgjsonb.save_load(jid, load, minions=None)
          Save the load to the specified jid id

   salt.returners.postgres
   Return data to a postgresql server

   NOTE:
      returners.postgres_local_cache is recommended instead of this module
      when using PostgreSQL as a  master  job  cache.  These  two  modules
      provide  different  functionality  so you should compare each to see
      which module best suits your particular needs.

   maintainer
          None

   maturity
          New

   depends
          psycopg2

   platform
          all

   To enable this returner the minion will need the psycopg2 installed and
   the following values configured in the minion or master config:

      returner.postgres.host: 'salt'
      returner.postgres.user: 'salt'
      returner.postgres.passwd: 'salt'
      returner.postgres.db: 'salt'
      returner.postgres.port: 5432

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location:

      alternative.returner.postgres.host: 'salt'
      alternative.returner.postgres.user: 'salt'
      alternative.returner.postgres.passwd: 'salt'
      alternative.returner.postgres.db: 'salt'
      alternative.returner.postgres.port: 5432

   Running  the  following commands as the postgres user should create the
   database correctly:

      psql << EOF
      CREATE ROLE salt WITH PASSWORD 'salt';
      CREATE DATABASE salt WITH OWNER salt;
      EOF

      psql -h localhost -U salt << EOF
      --
      -- Table structure for table 'jids'
      --

      DROP TABLE IF EXISTS jids;
      CREATE TABLE jids (
        jid   varchar(20) PRIMARY KEY,
        load  text NOT NULL
      );

      --
      -- Table structure for table 'salt_returns'
      --

      DROP TABLE IF EXISTS salt_returns;
      CREATE TABLE salt_returns (
        fun       varchar(50) NOT NULL,
        jid       varchar(255) NOT NULL,
        return    text NOT NULL,
        full_ret  text,
        id        varchar(255) NOT NULL,
        success   varchar(10) NOT NULL,
        alter_time   TIMESTAMP WITH TIME ZONE DEFAULT now()
      );

      CREATE INDEX idx_salt_returns_id ON salt_returns (id);
      CREATE INDEX idx_salt_returns_jid ON salt_returns (jid);
      CREATE INDEX idx_salt_returns_fun ON salt_returns (fun);
      CREATE INDEX idx_salt_returns_updated ON salt_returns (alter_time);

      --
      -- Table structure for table `salt_events`
      --

      DROP TABLE IF EXISTS salt_events;
      DROP SEQUENCE IF EXISTS seq_salt_events_id;
      CREATE SEQUENCE seq_salt_events_id;
      CREATE TABLE salt_events (
          id BIGINT NOT NULL UNIQUE DEFAULT nextval('seq_salt_events_id'),
          tag varchar(255) NOT NULL,
          data text NOT NULL,
          alter_time TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
          master_id varchar(255) NOT NULL
      );

      CREATE INDEX idx_salt_events_tag on salt_events (tag);

      EOF

   Required python modules: psycopg2

   To use the postgres returner, append '--return postgres'  to  the  salt
   command.

      salt '*' test.ping --return postgres

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return postgres --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return postgres --return_kwargs '{"db": "another-salt"}'

   salt.returners.postgres.event_return(events)
          Return event to Pg server

          Requires that configuration be enabled via 'event_return' option
          in master config.

   salt.returners.postgres.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.postgres.get_jid(jid)
          Return the information returned when the specified  job  id  was
          executed

   salt.returners.postgres.get_jids()
          Return a list of all job ids

   salt.returners.postgres.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.postgres.get_minions()
          Return a list of minions

   salt.returners.postgres.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.postgres.returner(ret)
          Return data to a postgres server

   salt.returners.postgres.save_load(jid, load, minions=None)
          Save the load to the specified jid id

   salt.returners.postgres_local_cache
   Use a postgresql server for the master job cache. This  helps  the  job
   cache to cope with scale.

   NOTE:
      returners.postgres is also available if you are not using PostgreSQL
      as  a  master  job  cache.   These  two  modules  provide  different
      functionality  so  you  should compare each to see which module best
      suits your particular needs.

   maintainer
          [email protected]

   maturity
          New

   depends
          psycopg2

   platform
          all

   To enable this returner the minion will need the psycopg2 installed and
   the following values configured in the master config:

      master_job_cache: postgres_local_cache
      master_job_cache.postgres.host: 'salt'
      master_job_cache.postgres.user: 'salt'
      master_job_cache.postgres.passwd: 'salt'
      master_job_cache.postgres.db: 'salt'
      master_job_cache.postgres.port: 5432

   Running  the  following  command as the postgres user should create the
   database correctly:

      psql << EOF
      CREATE ROLE salt WITH PASSWORD 'salt';
      CREATE DATABASE salt WITH OWNER salt;
      EOF

   In case the postgres database  is  a  remote  host,  you'll  need  this
   command also:

      ALTER ROLE salt WITH LOGIN;

   and then:

      psql -h localhost -U salt << EOF
      --
      -- Table structure for table 'jids'
      --

      DROP TABLE IF EXISTS jids;
      CREATE TABLE jids (
        jid   varchar(20) PRIMARY KEY,
        started TIMESTAMP WITH TIME ZONE DEFAULT now(),
        tgt_type text NOT NULL,
        cmd text NOT NULL,
        tgt text NOT NULL,
        kwargs text NOT NULL,
        ret text NOT NULL,
        username text NOT NULL,
        arg text NOT NULL,
        fun text NOT NULL
      );

      --
      -- Table structure for table 'salt_returns'
      --
      -- note that 'success' must not have NOT NULL constraint, since
      -- some functions don't provide it.

      DROP TABLE IF EXISTS salt_returns;
      CREATE TABLE salt_returns (
        added     TIMESTAMP WITH TIME ZONE DEFAULT now(),
        fun       text NOT NULL,
        jid       varchar(20) NOT NULL,
        return    text NOT NULL,
        id        text NOT NULL,
        success   boolean
      );
      CREATE INDEX ON salt_returns (added);
      CREATE INDEX ON salt_returns (id);
      CREATE INDEX ON salt_returns (jid);
      CREATE INDEX ON salt_returns (fun);

      DROP TABLE IF EXISTS salt_events;
      CREATE TABLE salt_events (
        id SERIAL,
        tag text NOT NULL,
        data text NOT NULL,
        alter_time TIMESTAMP WITH TIME ZONE DEFAULT now(),
        master_id text NOT NULL
      );
      CREATE INDEX ON salt_events (tag);
      CREATE INDEX ON salt_events (data);
      CREATE INDEX ON salt_events (id);
      CREATE INDEX ON salt_events (master_id);
      EOF

   Required python modules: psycopg2

   salt.returners.postgres_local_cache.clean_old_jobs()
          Clean out the old jobs from the job cache

   salt.returners.postgres_local_cache.event_return(events)
          Return event to a postgres server

          Require  that configuration be enabled via 'event_return' option
          in master config.

   salt.returners.postgres_local_cache.get_jid(jid)
          Return the information returned when the specified  job  id  was
          executed

   salt.returners.postgres_local_cache.get_jids()
          Return  a  list  of  all  job ids For master job cache this also
          formats the output and returns a string

   salt.returners.postgres_local_cache.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.postgres_local_cache.prep_jid(nocache=False,
   passed_jid=None)
          Return  a  job  id  and prepare the job id directory This is the
          function responsible for making sure jids don't collide  (unless
          its  passed  a jid). So do what you have to do to make sure that
          stays the case

   salt.returners.postgres_local_cache.returner(load)
          Return data to a postgres server

   salt.returners.postgres_local_cache.save_load(jid,          clear_load,
   minions=None)
          Save the load to the specified jid id

   salt.returners.pushover_returner
   Return salt data via pushover (http://www.pushover.net)

   New in version 2016.3.0.

   The following fields can be set in the minion conf file:

      pushover.user (required)
      pushover.token (required)
      pushover.title (optional)
      pushover.device (optional)
      pushover.priority (optional)
      pushover.expire (optional)
      pushover.retry (optional)
      pushover.profile (optional)

   Alternative   configuration   values  can  be  used  by  prefacing  the
   configuration.  Any values not found in the  alternative  configuration
   will be pulled from the default location:

      alternative.pushover.user
      alternative.pushover.token
      alternative.pushover.title
      alternative.pushover.device
      alternative.pushover.priority
      alternative.pushover.expire
      alternative.pushover.retry

   PushOver settings may also be configured as:

        pushover:
            user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            title: Salt Returner
            device: phone
            priority: -1
            expire: 3600
            retry: 5

        alternative.pushover:
            user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            title: Salt Returner
            device: phone
            priority: 1
            expire: 4800
            retry: 2

        pushover_profile:
            pushover.token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

        pushover:
            user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            profile: pushover_profile

        alternative.pushover:
            user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            profile: pushover_profile

      To use the PushOver returner, append '--return pushover' to the salt command. ex:

      .. code-block:: bash

        salt '*' test.ping --return pushover

      To use the alternative configuration, append '--return_config alternative' to the salt command. ex:

        salt '*' test.ping --return pushover --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

      salt '*' test.ping --return pushover --return_kwargs '{"title": "Salt is awesome!"}'

   salt.returners.pushover_returner.returner(ret)
          Send an PushOver message with the data

   salt.returners.rawfile_json
   Take data from salt and "return" it into  a  raw  file  containing  the
   json, with one line per event.

   Add the following to the minion or master configuration file.

      rawfile_json.filename: <path_to_output_file>

   Default is /var/log/salt/events.

   Common  use is to log all events on the master. This can generate a lot
   of noise,  so  you  may  wish  to  configure  batch  processing  and/or
   configure   the  event_return_whitelist  or  event_return_blacklist  to
   restrict the events that are written.

   salt.returners.rawfile_json.event_return(event)
          Write event return data to a file on the master.

   salt.returners.rawfile_json.returner(ret)
          Write the return data to a file on the minion.

   salt.returners.redis_return
   Return data to a redis server

   To enable this returner the minion will  need  the  python  client  for
   redis  installed  and  the following values configured in the minion or
   master config, these are the defaults:

      redis.db: '0'
      redis.host: 'salt'
      redis.port: 6379

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      alternative.redis.db: '0'
      alternative.redis.host: 'salt'
      alternative.redis.port: 6379

   To use the redis returner, append '--return redis' to the salt command.

      salt '*' test.ping --return redis

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return redis --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return redis --return_kwargs '{"db": "another-salt"}'

   salt.returners.redis_return.clean_old_jobs()
          Clean out minions's return data for old jobs.

          Normally, hset 'ret:<jid>'  are  saved  with  a  TTL,  and  will
          eventually get cleaned by redis.But for jobs with some very late
          minion return, the corresponding hset's TTL will be refreshed to
          a too late timestamp, we'll do manually cleaning here.

   salt.returners.redis_return.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.redis_return.get_jid(jid)
          Return  the  information  returned when the specified job id was
          executed

   salt.returners.redis_return.get_jids()
          Return a dict mapping all job ids to job information

   salt.returners.redis_return.get_load(jid)
          Return the load data that marks a specified jid

   salt.returners.redis_return.get_minions()
          Return a list of minions

   salt.returners.redis_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.redis_return.returner(ret)
          Return data to a redis data store

   salt.returners.redis_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.sentry_return
   Salt  returner  that  reports  execution  results  back  to sentry. The
   returner will inspect the payload to identify errors and flag  them  as
   such.

   Pillar needs something like:

      raven:
        servers:
          - http://192.168.1.1
          - https://sentry.example.com
        public_key: deadbeefdeadbeefdeadbeefdeadbeef
        secret_key: beefdeadbeefdeadbeefdeadbeefdead
        project: 1
        tags:
          - os
          - master
          - saltversion
          - cpuarch

   or using a dsn:

      raven:
        dsn: https://aaaa:[email protected]/12345
        tags:
          - os
          - master
          - saltversion
          - cpuarch

   https://pypi.python.org/pypi/raven must be installed.

   The pillar can be hidden on sentry return by setting hide_pillar: true.

   The  tags  list  (optional) specifies grains items that will be used as
   sentry tags, allowing tagging of events in the sentry ui.

   To report only errors to sentry, set report_errors_only: true.

   salt.returners.sentry_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.sentry_return.returner(ret)
          Log outcome to sentry. The returner tries to identify errors and
          report them as such. All other messages will be reported at info
          level.   Failed  states  will  be  appended as separate list for
          convenience.

   salt.returners.slack_returner
   Return salt data via slack

   New in version 2015.5.0.

   The following fields can be set in the minion conf file:

      .. code-block:: yaml
      slack.channel  (required)  slack.api_key  (required)  slack.username
      (required)  slack.as_user  (required  to  see the profile picture of
      your bot) slack.profile (optional) slack.changes(optional, only show
      changes  and  failed  states) slack.yaml_format(optional, format the
      json in yaml format)

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      slack.channel
      slack.api_key
      slack.username
      slack.as_user

   Slack settings may also be configured as:

      slack:
          channel: RoomName
          api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          username: user
          as_user: true

      alternative.slack:
          room_id: RoomName
          api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          from_name: [email protected]

      slack_profile:
          slack.api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          slack.from_name: [email protected]

      slack:
          profile: slack_profile
          channel: RoomName

      alternative.slack:
          profile: slack_profile
          channel: RoomName

   To use the Slack returner, append '--return slack' to the salt command.

      salt '*' test.ping --return slack

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

      salt '*' test.ping --return slack --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return slack --return_kwargs '{"channel": "#random"}'

   salt.returners.slack_returner.returner(ret)
          Send an slack message with the data

   salt.returners.sms_return
   Return data by SMS.

   New in version 2015.5.0.

   maintainer
          Damian Myerscough

   maturity
          new

   depends
          twilio

   platform
          all

   To enable this returner the minion will need the python twilio  library
   installed  and  the following values configured in the minion or master
   config:

      twilio.sid: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      twilio.token: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      twilio.to: '+1415XXXXXXX'
      twilio.from: '+1650XXXXXXX'

   To use the sms returner, append '--return sms' to the salt command.

      salt '*' test.ping --return sms

   salt.returners.sms_return.returner(ret)
          Return a response in an SMS message

   salt.returners.smtp_return
   Return salt data via email

   The following fields can be set in the minion  conf  file.  Fields  are
   optional unless noted otherwise.

   * from (required) The name/address of the email sender.

   *

     to (required) The names/addresses of the email recipients;
            comma-delimited.                  For                 example:
            [email protected],[email protected].

   * host (required) The SMTP server hostname or address.

   * port The SMTP server port; defaults to 25.

   *

     username  The  username  used  to  authenticate  to  the  server.  If
     specified a
            password  is also required. It is recommended but not required
            to also use TLS with this option.

   * password The password used to authenticate to the server.

   * tls Whether to secure the connection using TLS; defaults to False

   * subject The email subject line.

   *

     fields Which fields from the returned data to include in the  subject
     line
            of  the  email;  comma-delimited.  For example: id,fun. Please
            note, the subject line is not encrypted.

   *

     gpgowner A user's ~/.gpg directory. This must contain a gpg
            public key matching the address the mail is sent to.  If  left
            unset, no encryption will be used. Requires python-gnupg to be
            installed.

   * template The path to a file to be used as a template  for  the  email
     body.

   *

     renderer A Salt renderer, or render-pipe, to use to render the email
            template. Default jinja.

   Below   is   an  example  of  the  above  settings  in  a  Salt  Minion
   configuration file:

      smtp.from: [email protected]
      smtp.to: [email protected]
      smtp.host: localhost
      smtp.port: 1025

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location. For example:

      alternative.smtp.username: saltdev
      alternative.smtp.password: saltdev
      alternative.smtp.tls: True

   To use the SMTP returner, append '--return smtp' to the salt command.

      salt '*' test.ping --return smtp

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return smtp --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return smtp --return_kwargs '{"to": "[email protected]"}'

   An easy way to test the SMTP returner is to use  the  development  SMTP
   server   built   into   Python.   The   command   below  will  start  a
   single-threaded SMTP server that prints any email it  receives  to  the
   console.

      python -m smtpd -n -c DebuggingServer localhost:1025

   New in version 2016.11.0.

   It  is possible to send emails with selected Salt events by configuring
   event_return option for Salt Master. For example:

      event_return: smtp

      event_return_whitelist:
        - salt/key

      smtp.from: [email protected]
      smtp.to: [email protected]
      smtp.host: localhost
      smtp.subject: 'Salt Master {{act}}ed key from Minion ID: {{id}}'
      smtp.template: /srv/salt/templates/email.j2

   Also you need to create  additional  file  /srv/salt/templates/email.j2
   with email body template:

      act: {{act}}
      id: {{id}}
      result: {{result}}

   This  configuration enables Salt Master to send an email when accepting
   or rejecting minions keys.

   salt.returners.smtp_return.event_return(events)
          Return event data via SMTP

   salt.returners.smtp_return.prep_jid(nocache=False, passed_jid=None)
          Do any work necessary to prepare  a  JID,  including  sending  a
          custom id

   salt.returners.smtp_return.returner(ret)
          Send an email with the data

   salt.returners.splunk module
   Send json response data to Splunk via the HTTP Event Collector Requires
   the following config values to be specified in config or pillar:

      splunk_http_forwarder:
        token: <splunk_http_forwarder_token>
        indexer: <hostname/IP of Splunk indexer>
        sourcetype: <Destination sourcetype for data>
        index: <Destination index for data>

   Run a test by using salt-call test.ping --return splunk

   Written by Scott Pack (github.com/scottjpack)

   salt.returners.splunk.returner(ret)
          Send a message to Splunk via the HTTP Event Collector

   salt.returners.sqlite3
   Insert minion return data into a sqlite3 database

   maintainer
          Mickey Malone <[email protected]>

   maturity
          New

   depends
          None

   platform
          All

   Sqlite3 is a serverless database that lives in a single file.  In order
   to use this returner the database file must exist, have the appropriate
   schema defined, and be accessible to the user whom the  minion  process
   is  running  as. This returner requires the following values configured
   in the master or minion config:

      sqlite3.database: /usr/lib/salt/salt.db
      sqlite3.timeout: 5.0

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      alternative.sqlite3.database: /usr/lib/salt/salt.db
      alternative.sqlite3.timeout: 5.0

   Use the commands to create the sqlite3 database and tables:

      sqlite3 /usr/lib/salt/salt.db << EOF
      --
      -- Table structure for table 'jids'
      --

      CREATE TABLE jids (
        jid TEXT PRIMARY KEY,
        load TEXT NOT NULL
        );

      --
      -- Table structure for table 'salt_returns'
      --

      CREATE TABLE salt_returns (
        fun TEXT KEY,
        jid TEXT KEY,
        id TEXT KEY,
        fun_args TEXT,
        date TEXT NOT NULL,
        full_ret TEXT NOT NULL,
        success TEXT NOT NULL
        );
      EOF

   To use the sqlite returner,  append  '--return  sqlite3'  to  the  salt
   command.

      salt '*' test.ping --return sqlite3

   To   use   the   alternative   configuration,  append  '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return sqlite3 --return_config alternative

   To override  individual  configuration  items,  append  --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return sqlite3 --return_kwargs '{"db": "/var/lib/salt/another-salt.db"}'

   salt.returners.sqlite3_return.get_fun(fun)
          Return a dict of the last function called for all minions

   salt.returners.sqlite3_return.get_jid(jid)
          Return the information returned from a specified jid

   salt.returners.sqlite3_return.get_jids()
          Return a list of all job ids

   salt.returners.sqlite3_return.get_load(jid)
          Return the load from a specified jid

   salt.returners.sqlite3_return.get_minions()
          Return a list of minions

   salt.returners.sqlite3_return.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.sqlite3_return.returner(ret)
          Insert minion return data into the sqlite3 database

   salt.returners.sqlite3_return.save_load(jid, load, minions=None)
          Save the load to the specified jid

   salt.returners.syslog_return
   Return data to the host operating system's syslog facility

   To use the syslog  returner,  append  '--return  syslog'  to  the  salt
   command.

      salt '*' test.ping --return syslog

   The following fields can be set in the minion conf file:

      syslog.level (optional, Default: LOG_INFO)
      syslog.facility (optional, Default: LOG_USER)
      syslog.tag (optional, Default: salt-minion)
      syslog.options (list, optional, Default: [])

   Available  levels,  facilities,  and options can be found in the syslog
   docs for your python version.

   NOTE:
      The  default  tag  comes   from   sys.argv[0]   which   is   usually
      "salt-minion"   but   could  be  different  based  on  the  specific
      environment.

   Configuration example:

      syslog.level: 'LOG_ERR'
      syslog.facility: 'LOG_DAEMON'
      syslog.tag: 'mysalt'
      syslog.options:
        - LOG_PID

   Of course you can also nest the options:

      syslog:
        level: 'LOG_ERR'
        facility: 'LOG_DAEMON'
        tag: 'mysalt'
        options:
          - LOG_PID

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.  Any  values  not found in the alternative configuration
   will be pulled from the default location:

      alternative.syslog.level: 'LOG_WARN'
      alternative.syslog.facility: 'LOG_NEWS'

   To  use   the   alternative   configuration,   append   --return_config
   alternative to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return syslog --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return syslog --return_kwargs '{"level": "LOG_DEBUG"}'

   NOTE:
      Syslog server implementations may have limits on the maximum  record
      size  received by the client. This may lead to job return data being
      truncated in the syslog server's logs. For example, for  rsyslog  on
      RHEL-based systems, the default maximum record size is approximately
      2KB (which return data can easily exceed). This is  configurable  in
      rsyslog.conf   via  the  $MaxMessageSize  config  parameter.  Please
      consult your syslog implmentation's documentation to  determine  how
      to adjust this limit.

   salt.returners.syslog_return.prep_jid(nocache=False, passed_jid=None)
          Do  any  work  necessary  to  prepare a JID, including sending a
          custom id

   salt.returners.syslog_return.returner(ret)
          Return data to the local syslog

   salt.returners.xmpp_return
   Return salt data via xmpp

   depends
          sleekxmpp >= 1.3.1

   The following fields can be set in the minion conf file:

      xmpp.jid (required)
      xmpp.password (required)
      xmpp.recipient (required)
      xmpp.profile (optional)

   Alternative  configuration  values  can  be  used  by   prefacing   the
   configuration.   Any  values not found in the alternative configuration
   will be pulled from the default location:

      xmpp.jid
      xmpp.password
      xmpp.recipient
      xmpp.profile

   XMPP settings may also be configured as:

      xmpp:
          jid: [email protected]/resource
          password: password
          recipient: [email protected]

      alternative.xmpp:
          jid: [email protected]/resource
          password: password
          recipient: [email protected]

      xmpp_profile:
          xmpp.jid: [email protected]/resource
          xmpp.password: password

      xmpp:
          profile: xmpp_profile
          recipient: [email protected]

      alternative.xmpp:
          profile: xmpp_profile
          recipient: [email protected]

   To use the XMPP returner, append '--return xmpp' to the salt command.

      salt '*' test.ping --return xmpp

   To  use  the   alternative   configuration,   append   '--return_config
   alternative' to the salt command.

   New in version 2015.5.0.

      salt '*' test.ping --return xmpp --return_config alternative

   To  override  individual  configuration  items,  append --return_kwargs
   '{"key:": "value"}' to the salt command.

   New in version 2016.3.0.

      salt '*' test.ping --return xmpp --return_kwargs '{"recipient": "[email protected]"}'

   salt.returners.xmpp_return.returner(ret)
          Send an xmpp message with the data

   Renderers
   The Salt state system operates by  gathering  information  from  common
   data  types  such  as  lists,  dictionaries,  and strings that would be
   familiar to any developer.

   SLS files are translated from whatever data templating format they  are
   written in back into Python data types to be consumed by Salt.

   By default SLS files are rendered as Jinja templates and then parsed as
   YAML documents. But since the only thing the state system  cares  about
   is  raw  data,  the  SLS files can be any structured format that can be
   dreamed up.

   Currently there is support for Jinja + YAML, Mako + YAML, Wempy + YAML,
   Jinja + json, Mako + json and Wempy + json.

   Renderers  can be written to support any template type. This means that
   the Salt states could be managed  by  XML  files,  HTML  files,  Puppet
   files,  or  any  format  that  can be translated into the Pythonic data
   structure used by the state system.

   Multiple Renderers
   A default renderer is selected in  the  master  configuration  file  by
   providing a value to the renderer key.

   When evaluating an SLS, more than one renderer can be used.

   When   rendering   SLS  files,  Salt  checks  for  the  presence  of  a
   Salt-specific shebang line.

   The shebang line directly calls the name  of  the  renderer  as  it  is
   specified  within  Salt. One of the most common reasons to use multiple
   renderers is to use the Python or py renderer.

   Below, the first line is a shebang that references the py renderer.

      #!py

      def run():
          '''
          Install the python-mako package
          '''
          return {'include': ['python'],
                  'python-mako': {'pkg': ['installed']}}

   Composing Renderers
   A renderer can be composed from other renderers by connecting them in a
   series of pipes(|).

   In fact, the default Jinja + YAML renderer is implemented by connecting
   a YAML renderer to a Jinja renderer.  Such  renderer  configuration  is
   specified as: jinja | yaml.

   Other renderer combinations are possible:

      yaml   i.e, just YAML, no templating.

      mako | yaml
             pass the input to the mako renderer, whose output is then fed
             into the yaml renderer.

      jinja | mako | yaml
             This one allows you to use both  jinja  and  mako  templating
             syntax  in the input and then parse the final rendered output
             as YAML.

   The following is a contrived example SLS file using the jinja | mako  |
   yaml renderer:

      #!jinja|mako|yaml

      An_Example:
        cmd.run:
          - name: |
              echo "Using Salt ${grains['saltversion']}" \
                   "from path {{grains['saltpath']}}."
          - cwd: /

      <%doc> ${...} is Mako's notation, and so is this comment. </%doc>
      {#     Similarly, {{...}} is Jinja's notation, and so is this comment. #}

   For  backward  compatibility,  jinja  |  yaml  can  also  be written as
   yaml_jinja,  and  similarly,  the  yaml_mako,  yaml_wempy,  json_jinja,
   json_mako, and json_wempy renderers are all supported.

   Keep in mind that not all renderers can be used alone or with any other
   renderers.  For example, the template renderers shouldn't be used alone
   as  their  outputs  are  just strings, which still need to be parsed by
   another renderer to turn them into highstate data structures.

   For example, it doesn't make sense to specify yaml | jinja because  the
   output  of  the  YAML renderer is a highstate data structure (a dict in
   Python), which cannot be used as the  input  to  a  template  renderer.
   Therefore, when combining renderers, you should know what each renderer
   accepts as input and what it returns as output.

   Writing Renderers
   A custom renderer must be a  Python  module  placed  in  the  renderers
   directory and the module implement the render function.

   The  render  function  will  be  passed  the path of the SLS file as an
   argument.

   The purpose of of render function is to  parse the passed file  and  to
   return the Python data structure derived from the file.

   Custom  renderers  must  be placed in a _renderers directory within the
   file_roots specified by the master config file.

   Custom renderers are distributed when any of the following are run:

   * state.apply

   * saltutil.sync_renderers

   * saltutil.sync_all

   Any custom renderers which have been synced to a minion, that are named
   the same as one of Salt's default set of renderers, will take the place
   of the default renderer with the same name.

   Examples
   The best place to find examples of renderers  is  in  the  Salt  source
   code.

   Documentation for renderers included with Salt can be found here:

   https://github.com/saltstack/salt/blob/develop/salt/renderers

   Here is a simple YAML renderer example:

      import yaml
      def render(yaml_data, saltenv='', sls='', **kws):
          if not isinstance(yaml_data, basestring):
              yaml_data = yaml_data.read()
          data = yaml.load(yaml_data)
          return data if data else {}

   Full List of Renderers
   renderer modules
                  
                  cheetah    Cheetah Renderer for Salt  
                  
                  dson       DSON Renderer for Salt     
                  
                  genshi     Genshi Renderer for Salt   
                  
                  gpg        Renderer that will decrypt 
                             GPG ciphers                
                  
                  hjson      Hjson Renderer for Salt    
                  
                  jinja      Jinja  loading  utils   to 
                             enable   a  more  powerful 
                             backend     for      jinja 
                             templates                  
                  
                  json       JSON Renderer for Salt     
                  
                  json5      JSON5 Renderer for Salt    
                  
                  mako       Mako Renderer for Salt     
                  
                  msgpack                               
                  
                  py         Pure python state renderer 
                  
                  pydsl      A Python-based DSL         
                  
                  pyobjects  Python    renderer    that 
                             includes a Pythonic Object 
                             based interface            
                  

                  stateconf  A  flexible  renderer that 
                             takes a templating  engine 
                             and a data format          
                  
                  wempy                                 
                  
                  yaml       YAML Renderer for Salt     
                  
                  yamlex                                
                  

   salt.renderers.cheetah
   Cheetah Renderer for Salt

   salt.renderers.cheetah.render(cheetah_data,   saltenv='base',   sls='',
   method='xml', **kws)
          Render a Cheetah template.

          Return type
                 A Python data structure

   salt.renderers.dson
   DSON Renderer for Salt

   This renderer is intended for demonstration  purposes.  Information  on
   the DSON spec can be found here.

   This renderer requires Dogeon (installable via pip)

   salt.renderers.dson.render(dson_input,      saltenv='base',     sls='',
   **kwargs)
          Accepts DSON data as a string or as a file object  and  runs  it
          through the JSON parser.

          Return type
                 A Python data structure

   salt.renderers.genshi
   Genshi Renderer for Salt

   salt.renderers.genshi.render(genshi_data,    saltenv='base',    sls='',
   method='xml', **kws)
          Render a Genshi template. A method should be passed in  as  part
          of  the kwargs. If no method is passed in, xml is assumed. Valid
          methods are:

          Note that the text method will call NewTextTemplate. If  oldtext
          is desired, it must be called explicitly

          Return type
                 A Python data structure

   salt.renderers.gpg
   Renderer that will decrypt GPG ciphers

   Any  key  in  the  SLS file can be a GPG cipher, and this renderer will
   decrypt it before passing it off to Salt. This  allows  you  to  safely
   store  secrets  in  source  control,  in such a way that only your Salt
   master can decrypt them and distribute them only to  the  minions  that
   need them.

   The  typical  use-case would be to use ciphers in your pillar data, and
   keep a secret key on your master. You can put the public key in  source
   control so that developers can add new secrets quickly and easily.

   This renderer requires the gpg binary. No python libraries are required
   as of the 2015.8.0 release.

   Setup
   To set things up, first generate a keypair.  On  the  master,  run  the
   following:

      # mkdir -p /etc/salt/gpgkeys
      # chmod 0700 /etc/salt/gpgkeys
      # gpg --gen-key --homedir /etc/salt/gpgkeys

   Do  not  supply  a  password for the keypair, and use a name that makes
   sense for your application. Be sure to back up  the  gpgkeys  directory
   someplace safe!

   NOTE:
      Unfortunately,  there  are  some scenarios - for example, on virtual
      machines which don't have real hardware - where insufficient entropy
      causes  key  generation  to be extremely slow. In these cases, there
      are usually means of increasing the system entropy.  On  virtualised
      Linux  systems,  this  can  often  be  achieved  by  installing  the
      rng-tools package.

   Export the Public Key
      # gpg --homedir /etc/salt/gpgkeys --armor --export <KEY-NAME> > exported_pubkey.gpg

   Import the Public Key
   To encrypt secrets, copy the public key to your local machine and run:

      $ gpg --import exported_pubkey.gpg

   To generate a cipher from a secret:

      $ echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r <KEY-name>

   To apply the renderer on a file-by-file basis add the following line to
   the top of any pillar with gpg data in it:

      #!yaml|gpg

   Now with your renderer configured, you can include your ciphers in your
   pillar data like so:

      #!yaml|gpg

      a-secret: |
        -----BEGIN PGP MESSAGE-----
        Version: GnuPG v1

        hQEMAweRHKaPCfNeAQf9GLTN16hCfXAbPwU6BbBK0unOc7i9/etGuVc5CyU9Q6um
        QuetdvQVLFO/HkrC4lgeNQdM6D9E8PKonMlgJPyUvC8ggxhj0/IPFEKmrsnv2k6+
        cnEfmVexS7o/U1VOVjoyUeliMCJlAz/30RXaME49Cpi6No2+vKD8a4q4nZN1UZcG
        RhkhC0S22zNxOXQ38TBkmtJcqxnqT6YWKTUsjVubW3bVC+u2HGqJHu79wmwuN8tz
        m4wBkfCAd8Eyo2jEnWQcM4TcXiF01XPL4z4g1/9AAxh+Q4d8RIRP4fbw7ct4nCJv
        Gr9v2DTF7HNigIMl4ivMIn9fp+EZurJNiQskLgNbktJGAeEKYkqX5iCuB1b693hJ
        FKlwHiJt5yA8X2dDtfk8/Ph1Jx2TwGS+lGjlZaNqp3R1xuAZzXzZMLyZDe5+i3RJ
        skqmFTbOiA===Eqsm

        -----END PGP MESSAGE-----
   Encrypted CLI Pillar Data
   New in version 2016.3.0.

   Functions like state.highstate and state.sls allow for pillar  data  to
   be passed on the CLI.

      salt myminion state.highstate pillar="{'mypillar': 'foo'}"

   Starting with the 2016.3.0 release of Salt, it is now possible for this
   pillar data to be GPG-encrypted, and to use the GPG renderer to decrypt
   it.

   Replacing Newlines
   To  pass encrypted pillar data on the CLI, the ciphertext must have its
   newlines replaced with a literal backslash-n (\n), as newlines are  not
   supported  within  Salt CLI arguments. There are a number of ways to do
   this:

   With awk or Perl:

      # awk
      ciphertext=`echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r [email protected] | awk '{printf "%s\\n",$0} END {print ""}'`
      # Perl
      ciphertext=`echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r [email protected] | perl -pe 's/\n/\\n/g'`

   With Python:

      import subprocess

      secret, stderr = subprocess.Popen(
          ['gpg', '--armor', '--batch', '--trust-model', 'always', '--encrypt',
           '-r', '[email protected]'],
          stdin=subprocess.PIPE,
          stdout=subprocess.PIPE,
          stderr=subprocess.PIPE).communicate(input='supersecret')

      if secret:
          print(secret.replace('\n', r'\n'))
      else:
          raise ValueError('No ciphertext found: {0}'.format(stderr))

      ciphertext=`python /path/to/script.py`

   The ciphertext can be included in the CLI pillar data like so:

      salt myminion state.sls secretstuff pillar_enc=gpg pillar="{secret_pillar: '$ciphertext'}"

   The pillar_enc=gpg argument tells  Salt  that  there  is  GPG-encrypted
   pillar  data,  so  that  the  CLI pillar data is passed through the GPG
   renderer,  which  will  iterate  recursively  though  the  CLI   pillar
   dictionary to decrypt any encrypted values.

   Encrypting the Entire CLI Pillar Dictionary
   If  several  values  need to be encrypted, it may be more convenient to
   encrypt the entire CLI pillar dictionary. Again, this can  be  done  in
   several ways:

   With awk or Perl:

      # awk
      ciphertext=`echo -n "{'secret_a': 'CorrectHorseBatteryStaple', 'secret_b': 'GPG is fun!'}" | gpg --armor --batch --trust-model always --encrypt -r [email protected] | awk '{printf "%s\\n",$0} END {print ""}'`
      # Perl
      ciphertext=`echo -n "{'secret_a': 'CorrectHorseBatteryStaple', 'secret_b': 'GPG is fun!'}" | gpg --armor --batch --trust-model always --encrypt -r [email protected] | perl -pe 's/\n/\\n/g'`

   With Python:

      import subprocess

      pillar_data = {'secret_a': 'CorrectHorseBatteryStaple',
                     'secret_b': 'GPG is fun!'}

      secret, stderr = subprocess.Popen(
          ['gpg', '--armor', '--batch', '--trust-model', 'always', '--encrypt',
           '-r', '[email protected]'],
          stdin=subprocess.PIPE,
          stdout=subprocess.PIPE,
          stderr=subprocess.PIPE).communicate(input=repr(pillar_data))

      if secret:
          print(secret.replace('\n', r'\n'))
      else:
          raise ValueError('No ciphertext found: {0}'.format(stderr))

      ciphertext=`python /path/to/script.py`

   With  the entire pillar dictionary now encrypted, it can be included in
   the CLI pillar data like so:

      salt myminion state.sls secretstuff pillar_enc=gpg pillar="$ciphertext"

   salt.renderers.gpg.render(gpg_data, saltenv='base', sls='', argline='',
   **kwargs)
          Create  a  gpg object given a gpg_keydir, and then use it to try
          to decrypt the data to be rendered.

   salt.renderers.hjson
   Hjson Renderer for Salt http://laktak.github.io/hjson/

   salt.renderers.hjson.render(hjson_data, saltenv='base', sls='', **kws)
          Accepts HJSON as a string or  as  a  file  object  and  runs  it
          through the HJSON parser.

          Return type
                 A Python data structure

   salt.renderers.jinja
   Jinja  loading  utils  to  enable  a  more  powerful  backend for jinja
   templates

   For Jinja usage information see Understanding Jinja.

   salt.renderers.jinja.render(template_file,   saltenv='base',    sls='',
   argline='', context=None, tmplpath=None, **kws)
          Render  the template_file, passing the functions and grains into
          the Jinja rendering system.

          Return type
                 string

   class salt.utils.jinja.SerializerExtension(environment)
          Yaml and Json manipulation.

          Format filters

          Allows jsonifying or yamlifying any data structure. For example,
          this dataset:

             data = {
                 'foo': True,
                 'bar': 42,
                 'baz': [1, 2, 3],
                 'qux': 2.0
             }

             yaml = {{ data|yaml }}
             json = {{ data|json }}
             python = {{ data|python }}

          will be rendered as:

             yaml = {bar: 42, baz: [1, 2, 3], foo: true, qux: 2.0}
             json = {"baz": [1, 2, 3], "foo": true, "bar": 42, "qux": 2.0}
             python = {'bar': 42, 'baz': [1, 2, 3], 'foo': True, 'qux': 2.0}

          The  yaml  filter  takes  an  optional  flow_style  parameter to
          control the default-flow-style parameter of the YAML dumper.

             {{ data|yaml(False) }}

          will be rendered as:

             bar: 42
             baz:
               - 1
               - 2
               - 3
             foo: true
             qux: 2.0

          Load filters

          Strings and variables can be  deserialized  with  load_yaml  and
          load_json  tags  and  filters.  It allows one to manipulate data
          directly in templates, easily:

             {%- set yaml_src = "{foo: it works}"|load_yaml %}
             {%- set json_src = "{'bar': 'for real'}"|load_json %}
             Dude, {{ yaml_src.foo }} {{ json_src.bar }}!

          will be rendered as:

             Dude, it works for real!

          Load tags

          Salt implements load_yaml and load_json tags. They work like the
          import tag, except that the document is also deserialized.

          Syntaxes  are {% load_yaml as [VARIABLE] %}[YOUR DATA]{% endload
          %} and {% load_json as [VARIABLE] %}[YOUR DATA]{% endload %}

          For example:

             {% load_yaml as yaml_src %}
                 foo: it works
             {% endload %}
             {% load_json as json_src %}
                 {
                     "bar": "for real"
                 }
             {% endload %}
             Dude, {{ yaml_src.foo }} {{ json_src.bar }}!

          will be rendered as:

             Dude, it works for real!

          Import tags

          External files can be imported and made  available  as  a  Jinja
          variable.

             {% import_yaml "myfile.yml" as myfile %}
             {% import_json "defaults.json" as defaults %}
             {% import_text "completeworksofshakespeare.txt" as poems %}

          Catalog

          import_*  and load_* tags will automatically expose their target
          variable to import.  This  feature  makes  catalog  of  data  to
          handle.

          for example:

             # doc1.sls
             {% load_yaml as var1 %}
                 foo: it works
             {% endload %}
             {% load_yaml as var2 %}
                 bar: for real
             {% endload %}

             # doc2.sls
             {% from "doc1.sls" import var1, var2 as local2 %}
             {{ var1.foo }} {{ local2.bar }}

   salt.renderers.json
   JSON Renderer for Salt

   salt.renderers.json.render(json_data, saltenv='base', sls='', **kws)
          Accepts JSON as a string or as a file object and runs it through
          the JSON parser.

          Return type
                 A Python data structure

   salt.renderers.json5
   JSON5 Renderer for Salt

   New in version 2016.3.0.

   JSON5 is an unofficial extension to  JSON.  See  http://json5.org/  for
   more information.

   This renderer requires the json5 python bindings, installable via pip.

   salt.renderers.json5.render(json_data, saltenv='base', sls='', **kws)
          Accepts JSON as a string or as a file object and runs it through
          the JSON parser.

          Return type
                 A Python data structure

   salt.renderers.mako
   Mako Renderer for Salt

   salt.renderers.mako.render(template_file,    saltenv='base',    sls='',
   context=None, tmplpath=None, **kws)
          Render  the template_file, passing the functions and grains into
          the Mako rendering system.

          Return type
                 string

   salt.renderers.msgpack
   salt.renderers.msgpack.render(msgpack_data,   saltenv='base',   sls='',
   **kws)
          Accepts  a  message  pack  string or a file object, renders said
          data back to a python dict.

          Return type
                 A Python data structure

   salt.renderers.py
   Pure python state renderer

   The SLS file should contain a function called run  which  returns  high
   state data.

   In  this  module,  a  few objects are defined for you, giving access to
   Salt's execution functions, grains, pillar, etc. They are:

   * __salt__ - Execution functions (i.e.  __salt__['test.echo']('foo'))

   * __grains__ - Grains (i.e. __grains__['os'])

   * __pillar__ - Pillar data (i.e. __pillar__['foo'])

   * __opts__ - Minion configuration options

   * __env__ - The effective salt fileserver environment (i.e. base). Also
     referred  to as a "saltenv". __env__ should not be modified in a pure
     python SLS file. To use  a  different  environment,  the  environment
     should  be set when executing the state. This can be done in a couple
     different ways:

     * Using the saltenv argument on the salt CLI (i.e. salt '*' state.sls
       foo.bar.baz saltenv=env_name).

     * By  adding a saltenv argument to an individual state within the SLS
       file. In other words, adding a line like this to the  state's  data
       structure: {'saltenv': 'env_name'}

   * __sls__  -  The SLS path of the file. For example, if the root of the
     base   environment   is   /srv/salt,   and   the    SLS    file    is
     /srv/salt/foo/bar/baz.sls,   then   __sls__  in  that  file  will  be
     foo.bar.baz.

       #!py

       def run():
           config = {}

           if __grains__['os'] == 'Ubuntu':
               user = 'ubuntu'
               group = 'ubuntu'
               home = '/home/{0}'.format(user)
           else:
               user = 'root'
               group = 'root'
               home = '/root/'

           config['s3cmd'] = {
               'pkg': [
                   'installed',
                   {'name': 's3cmd'},
               ],
           }

           config[home + '/.s3cfg'] = {
               'file.managed': [
                   {'source': 'salt://s3cfg/templates/s3cfg'},
                   {'template': 'jinja'},
                   {'user': user},
                   {'group': group},
                   {'mode': 600},
                   {'context': {
                       'aws_key': __pillar__['AWS_ACCESS_KEY_ID'],
                       'aws_secret_key': __pillar__['AWS_SECRET_ACCESS_KEY'],
                       },
                   },
               ],
           }

           return config

   salt.renderers.py.render(template,       saltenv='base',        sls='',
   tmplpath=None, **kws)
          Render the python module's components

          Return type
                 string

   salt.renderers.pydsl
   A Python-based DSL

   maintainer
          Jack Kuan <[email protected]>

   maturity
          new

   platform
          all

   The  pydsl  renderer allows one to author salt formulas (.sls files) in
   pure Python using a DSL that's easy to write and easy to  read.  Here's
   an example:

      #!pydsl

      apache = state('apache')
      apache.pkg.installed()
      apache.service.running()
      state('/var/www/index.html') \
          .file('managed',
                source='salt://webserver/index.html') \
          .require(pkg='apache')

   Notice  that  any  Python  code  is  allow in the file as it's really a
   Python module, so you have the full power of Python at  your  disposal.
   In  this module, a few objects are defined for you, including the usual
   (with __ added) __salt__ dictionary, __grains__, __pillar__,  __opts__,
   __env__, and __sls__, plus a few more:
      __file__
          local file system path to the sls module.

      __pydsl__
          Salt  PyDSL  object, useful for configuring DSL behavior per sls
          rendering.

      include
          Salt PyDSL function for creating include-declaration's.

      extend
          Salt PyDSL function for creating extend-declaration's.

      state
          Salt PyDSL function for creating ID-declaration's.

   A state ID-declaration is  created  with  a  state(id)  function  call.
   Subsequent  state(id)  call  with  the same id returns the same object.
   This singleton  access  pattern  applies  to  all  declaration  objects
   created with the DSL.

      state('example')
      assert state('example') is state('example')
      assert state('example').cmd is state('example').cmd
      assert state('example').cmd.running is state('example').cmd.running

   The  id argument is optional. If omitted, an UUID will be generated and
   used as the id.

   state(id)  returns  an  object   under   which   you   can   create   a
   state-declaration  object  by  accessing  an  attribute named after any
   state module available in Salt.

      state('example').cmd
      state('example').file
      state('example').pkg
      ...

   Then,  a  function-declaration   object   can   be   created   from   a
   state-declaration object by one of the following two ways:

   1. by   calling  a  method  named  after  the  state  function  on  the
      state-declaration object.

      state('example').file.managed(...)

   2. by directly calling the attribute named for  the  state-declaration,
      and supplying the state function name as the first argument.

      state('example').file('managed', ...)

   With   either  way  of  creating  a  function-declaration  object,  any
   function-arg-declaration's can be passed as keyword  arguments  to  the
   call.  Subsequent  calls  of a function-declaration will update the arg
   declarations.

      state('example').file('managed', source='salt://webserver/index.html')
      state('example').file.managed(source='salt://webserver/index.html')

   As a shortcut, the special name argument can  also  be  passed  as  the
   first  or  second  positional argument depending on the first or second
   way of calling the  state-declaration  object.  In  the  following  two
   examples ls -la is the name argument.

      state('example').cmd.run('ls -la', cwd='/')
      state('example').cmd('run', 'ls -la', cwd='/')

   Finally,  a requisite-declaration object with its requisite-reference's
   can be created by invoking one of  the  requisite  methods  (see  State
   Requisites)    on   either   a   function-declaration   object   or   a
   state-declaration object. The return value of a requisite call is  also
   a function-declaration object, so you can chain several requisite calls
   together.

   Arguments to a requisite  call  can  be  a  list  of  state-declaration
   objects and/or a set of keyword arguments whose names are state modules
   and values are IDs of ID-declaration's or names of name-declaration's.

      apache2 = state('apache2')
      apache2.pkg.installed()
      state('libapache2-mod-wsgi').pkg.installed()

      # you can call requisites on function declaration
      apache2.service.running() \
                     .require(apache2.pkg,
                              pkg='libapache2-mod-wsgi') \
                     .watch(file='/etc/apache2/httpd.conf')

      # or you can call requisites on state declaration.
      # this actually creates an anonymous function declaration object
      # to add the requisites.
      apache2.service.require(state('libapache2-mod-wsgi').pkg,
                              pkg='apache2') \
                     .watch(file='/etc/apache2/httpd.conf')

      # we still need to set the name of the function declaration.
      apache2.service.running()

   include-declaration objects can be created with the  include  function,
   while  extend-declaration  objects  can  be  created  with  the  extend
   function, whose arguments are just function-declaration objects.

      include('edit.vim', 'http.server')
      extend(state('apache2').service.watch(file='/etc/httpd/httpd.conf')

   The include function, by default, causes the included sls  file  to  be
   rendered  as  soon as the include function is called. It returns a list
   of rendered module objects; sls  files  not  rendered  with  the  pydsl
   renderer return None's.  This behavior creates no include-declaration's
   in the resulting high state data structure.

      import types

      # including multiple sls returns a list.
      _, mod = include('a-non-pydsl-sls', 'a-pydsl-sls')

      assert _ is None
      assert isinstance(slsmods[1], types.ModuleType)

      # including a single sls returns a single object
      mod = include('a-pydsl-sls')

      # myfunc is a function that calls state(...) to create more states.
      mod.myfunc(1, 2, "three")

   Notice how you can define a reusable function in your pydsl sls  module
   and then call it via the module returned by include.

   It's  still  possible  to  do late includes by passing the delayed=True
   keyword argument to include.

      include('edit.vim', 'http.server', delayed=True)

   Above will just create a include-declaration in  the  rendered  result,
   and such call always returns None.

   Special integration with the cmd state
   Taking  advantage  of  rendering  a  Python module, PyDSL allows you to
   declare a state that calls a pre-defined Python function when the state
   is executed.

      greeting = "hello world"
      def helper(something, *args, **kws):
          print greeting                # hello world
          print something, args, kws    # test123 ['a', 'b', 'c'] {'x': 1, 'y': 2}

      state().cmd.call(helper, "test123", 'a', 'b', 'c', x=1, y=2)

   The  cmd.call  state function takes care of calling our helper function
   with the arguments we specified  in  the  states,  and  translates  the
   return  value  of  our  function into a structure expected by the state
   system.  See salt.states.cmd.call() for more information.

   Implicit ordering of states
   Salt  states  are  explicitly  ordered   via   requisite-declaration's.
   However,  with  pydsl it's possible to let the renderer track the order
   of  creation  for  function-declaration  objects,  and  implicitly  add
   require  requisites  for  your  states  to  enforce  the ordering. This
   feature is enabled by setting the ordered option on __pydsl__.

   NOTE:
      this feature is only available if your minions are using  Python  >=
      2.7.

      include('some.sls.file')

      A = state('A').cmd.run(cwd='/var/tmp')
      extend(A)

      __pydsl__.set(ordered=True)

      for i in range(10):
          i = str(i)
          state(i).cmd.run('echo '+i, cwd='/')
      state('1').cmd.run('echo one')
      state('2').cmd.run(name='echo two')

   Notice  that the ordered option needs to be set after any extend calls.
   This is to prevent pydsl from tracking the creation of a state function
   that's passed to an extend call.

   Above example should create states from 0 to 9 that will output 0, one,
   two, 3, ... 9, in that order.

   It's  important  to  know  that   pydsl   tracks   the   creations   of
   function-declaration   objects,   and   automatically  adds  a  require
   requisite to a  function-declaration  object  that  requires  the  last
   function-declaration object created before it in the sls file.

   This   means   later   calls   (perhaps   to   update   the  function's
   function-arg-declaration) to a previously created function  declaration
   will not change the order.

   Render time state execution
   When Salt processes a salt formula file, the file is rendered to salt's
   high state data representation by a renderer before the states  can  be
   executed.  In the case of the pydsl renderer, the .sls file is executed
   as a python module as it is being  rendered  which  makes  it  easy  to
   execute a state at render time.  In pydsl, executing one or more states
   at render time can be  done  by  calling  a  configured  ID-declaration
   object.

      #!pydsl

      s = state() # save for later invocation

      # configure it
      s.cmd.run('echo at render time', cwd='/')
      s.file.managed('target.txt', source='salt://source.txt')

      s() # execute the two states now

   Once an ID-declaration is called at render time it is detached from the
   sls module as if it was never defined.

   NOTE:
      If     implicit     ordering     is     enabled      (i.e.,      via
      __pydsl__.set(ordered=True))   then   the   first  invocation  of  a
      ID-declaration object must be done before a new function-declaration
      is created.

   Integration with the stateconf renderer
   The salt.renderers.stateconf renderer offers a few interesting features
   that can be leveraged by the pydsl renderer. In particular, when  using
   with   the  pydsl  renderer,  we  are  interested  in  stateconf's  sls
   namespacing feature (via dot-prefixed id declarations), as well as, the
   automatic start and goal states generation.

   Now you can use pydsl with stateconf like this:

      #!pydsl|stateconf -ps

      include('xxx', 'yyy')

      # ensure that states in xxx run BEFORE states in this file.
      extend(state('.start').stateconf.require(stateconf='xxx::goal'))

      # ensure that states in yyy run AFTER states in this file.
      extend(state('.goal').stateconf.require_in(stateconf='yyy::start'))

      __pydsl__.set(ordered=True)

      ...

   -s  enables  the  generation of a stateconf start state, and -p lets us
   pipe high state data rendered by pydsl to stateconf. This example shows
   that  by  require-ing or require_in-ing the included sls' start or goal
   states, it's possible to ensure that the included sls files can be made
   to execute before or after a state in the including sls file.

   Importing custom Python modules
   To  use  a  custom Python module inside a PyDSL state, place the module
   somewhere that it can be loaded by the Salt loader, such as _modules in
   the /srv/salt directory.

   Then,    copy    it    to   any   minions   as   necessary   by   using
   saltutil.sync_modules.

   To import into a PyDSL SLS, one must bypass  the  Python  importer  and
   insert  it  manually  by  getting a reference from Python's sys.modules
   dictionary.

   For example:

      #!pydsl|stateconf -ps

      def main():
          my_mod = sys.modules['salt.loaded.ext.module.my_mod']

   salt.renderers.pyobjects
   Python renderer that includes a Pythonic Object based interface

   maintainer
          Evan Borgstrom <[email protected]>

   Let's take a look at how you use pyobjects in a state  file.  Here's  a
   quick example that ensures the /tmp directory is in the correct state.

       #!pyobjects

       File.managed("/tmp", user='root', group='root', mode='1777')

   Nice and Pythonic!

   By  using  the  "shebang" syntax to switch to the pyobjects renderer we
   can now write our state data  using  an  object  based  interface  that
   should feel at home to python developers. You can import any module and
   do anything that you'd like (with caution, importing sqlalchemy, django
   or other large frameworks has not been tested yet). Using the pyobjects
   renderer is exactly the same as using the built-in Python renderer with
   the  exception  that  pyobjects  provides  you  with  an  object  based
   interface for generating state data.

   Creating state data
   Pyobjects takes care of creating an object for each  of  the  available
   states  on  the  minion. Each state is represented by an object that is
   the CamelCase version of its name (i.e. File, Service, User, etc),  and
   these  objects  expose  all  of  their  available state functions (i.e.
   File.managed, Service.running, etc).

   The name of the state is split based upon underscores  (_),  then  each
   part is capitalized and finally the parts are joined back together.

   Some examples:

   * postgres_user becomes PostgresUser

   * ssh_known_hosts becomes SshKnownHosts

   Context Managers and requisites
   How about something a little more complex. Here we're going to get into
   the core of how to use pyobjects to write states.

       #!pyobjects

       with Pkg.installed("nginx"):
           Service.running("nginx", enable=True)

           with Service("nginx", "watch_in"):
               File.managed("/etc/nginx/conf.d/mysite.conf",
                            owner='root', group='root', mode='0444',
                            source='salt://nginx/mysite.conf')

   The objects that are returned from each of the magic method  calls  are
   setup to be used a Python context managers (with) and when you use them
   as such all declarations made within the scope will  automatically  use
   the enclosing state as a requisite!

   The  above could have also been written use direct requisite statements
   as.

       #!pyobjects

       Pkg.installed("nginx")
       Service.running("nginx", enable=True, require=Pkg("nginx"))
       File.managed("/etc/nginx/conf.d/mysite.conf",
                    owner='root', group='root', mode='0444',
                    source='salt://nginx/mysite.conf',
                    watch_in=Service("nginx"))

   You can use the direct requisite statement for referencing states  that
   are generated outside of the current file.

       #!pyobjects

       # some-other-package is defined in some other state file
       Pkg.installed("nginx", require=Pkg("some-other-package"))

   The  last thing that direct requisites provide is the ability to select
   which of the SaltStack requisites you want to use (require, require_in,
   watch,  watch_in,  use  & use_in) when using the requisite as a context
   manager.

       #!pyobjects

       with Service("my-service", "watch_in"):
           ...

   The above example would cause all declarations inside the scope of  the
   context   manager   to   automatically   have  their  watch_in  set  to
   Service("my-service").

   Including and Extending
   To include other states use the include() function. It takes  one  name
   per state to include.

   To  extend  another  state  use  the extend() function on the name when
   creating a state.

       #!pyobjects

       include('http', 'ssh')

       Service.running(extend('apache'),
                       watch=[File('/etc/httpd/extra/httpd-vhosts.conf')])

   Importing from other state files
   Like any Python project that grows you will likely reach a point  where
   you  want  to  create  reusability in your state tree and share objects
   between state files, Map Data (described below) is a perfect example of
   this.

   To  facilitate  this  Python's  import  statement has been augmented to
   allow for a special case when working with a Salt state  tree.  If  you
   specify  a  Salt url (salt://...) as the target for importing from then
   the pyobjects renderer will take care of fetching  the  file  for  you,
   parsing  it with all of the pyobjects features available and then place
   the requested objects  in  the  global  scope  of  the  template  being
   rendered.

   This  works for all types of import statements; import X, from X import
   Y, and from X import Y as Z.

       #!pyobjects

       import salt://myfile.sls
       from salt://something/data.sls import Object
       from salt://something/data.sls import Object as Other

   See the Map Data section for a more practical use.

   Caveats:

   * Imported objects are  ALWAYS  put  into  the  global  scope  of  your
     template, regardless of where your import statement is.

   Salt object
   In the spirit of the object interface for creating state data pyobjects
   also provides a simple object interface to the __salt__ object.

   A function named salt exists in scope  for  your  sls  files  and  will
   dispatch its attributes to the __salt__ dictionary.

   The following lines are functionally equivalent:

       #!pyobjects

       ret = salt.cmd.run(bar)
       ret = __salt__['cmd.run'](bar)

   Pillar, grain, mine & config data
   Pyobjects   provides   shortcut   functions   for  calling  pillar.get,
   grains.get, mine.get & config.get on the __salt__  object.  This  helps
   maintain the readability of your state files.

   Each  type  of  data  can  be  access  by  a function of the same name:
   pillar(), grains(), mine() and config().

   The following pairs of lines are functionally equivalent:

       #!pyobjects

       value = pillar('foo:bar:baz', 'qux')
       value = __salt__['pillar.get']('foo:bar:baz', 'qux')

       value = grains('pkg:apache')
       value = __salt__['grains.get']('pkg:apache')

       value = mine('os:Fedora', 'network.interfaces', 'grain')
       value = __salt__['mine.get']('os:Fedora', 'network.interfaces', 'grain')

       value = config('foo:bar:baz', 'qux')
       value = __salt__['config.get']('foo:bar:baz', 'qux')

   Map Data
   When building complex states or  formulas  you  often  need  a  way  of
   building  up  a map of data based on grain data. The most common use of
   this is tracking the  package  and  service  name  differences  between
   distributions.

   To build map data using pyobjects we provide a class named Map that you
   use to build your own classes with inner classes for each set of values
   for the different grain matches.

       #!pyobjects

       class Samba(Map):
           merge = 'samba:lookup'

           class Debian:
               server = 'samba'
               client = 'samba-client'
               service = 'samba'

           class Ubuntu:
               __grain__ = 'os'
               service = 'smbd'

           class RedHat:
               server = 'samba'
               client = 'samba'
               service = 'smb'

   To  use  this  new data you can import it into your state file and then
   access your attributes. To access the data in the map you simply access
   the  attribute  name  on the base class that is extending Map. Assuming
   the above  Map  was  in  the  file  samba/map.sls,  you  could  do  the
   following.

       #!pyobjects

       from salt://samba/map.sls import Samba

       with Pkg.installed("samba", names=[Samba.server, Samba.client]):
           Service.running("samba", name=Samba.service)

   class salt.renderers.pyobjects.PyobjectsModule(name, attrs)
          This provides a wrapper for bare imports.

   salt.renderers.pyobjects.load_states()
          This loads our states into the salt __context__

   salt.renderers.stateconf
   maintainer
          Jack Kuan <[email protected]>

   maturity
          new

   platform
          all

   This  module provides a custom renderer that processes a salt file with
   a specified templating engine (e.g. Jinja) and a chosen  data  renderer
   (e.g.  YAML),  extracts  arguments  for  any  stateconf.set  state, and
   provides the extracted arguments (including Salt-specific args, such as
   require,  etc)  as  template  context.  The  goal  is  to  make writing
   reusable/configurable/parameterized salt files easier and cleaner.

   To use this renderer, either set it as the  default  renderer  via  the
   renderer  option  in master/minion's config, or use the shebang line in
   each individual sls file, like so: #!stateconf. Note, due  to  the  way
   this  renderer  works,  it must be specified as the first renderer in a
   render pipeline. That is, you cannot specify #!mako|yaml|stateconf, for
   example.   Instead, you specify them as renderer arguments: #!stateconf
   mako . yaml.

   Here's a list of features enabled by this renderer.

   * Prefixes any state id (declaration or reference) that starts  with  a
     dot (.)  to avoid duplicated state ids when the salt file is included
     by other salt files.

     For  example,  in  the  salt://some/file.sls,  a  state  id  such  as
     .sls_params will be turned into some.file::sls_params. Example:

        #!stateconf yaml . jinja

        .vim:
          pkg.installed

     Above will be translated into:

        some.file::vim:
          pkg.installed:
            - name: vim

     Notice  how that if a state under a dot-prefixed state id has no name
     argument then one will be added automatically by using the  state  id
     with the leading dot stripped off.

     The  leading  dot trick can be used with extending state ids as well,
     so you can include relatively and  extend  relatively.  For  example,
     when extending a state in salt://some/other_file.sls, e.g.:

        #!stateconf yaml . jinja

        include:
          - .file

        extend:
          .file::sls_params:
            stateconf.set:
              - name1: something

     Above will be pre-processed into:

        include:
          - some.file

        extend:
          some.file::sls_params:
            stateconf.set:
              - name1: something

   * Adds  a  sls_dir  context  variable  that  expands  to  the directory
     containing   the   rendering   salt   file.   So,   you   can   write
     salt://{{sls_dir}}/... to reference templates files used by your salt
     file.

   * Recognizes the special state function, stateconf.set, that configures
     a  default list of named arguments usable within the template context
     of the salt file. Example:

        #!stateconf yaml . jinja

        .sls_params:
          stateconf.set:
            - name1: value1
            - name2: value2
            - name3:
              - value1
              - value2
              - value3
            - require_in:
              - cmd: output

        # --- end of state config ---

        .output:
          cmd.run:
            - name: |
                echo 'name1={{sls_params.name1}}
                      name2={{sls_params.name2}}
                      name3[1]={{sls_params.name3[1]}}
                '

     This even works with include + extend so that you  can  override  the
     default  configured  arguments  by  including  the salt file and then
     extend the stateconf.set states that  come  from  the  included  salt
     file.  (IMPORTANT: Both the included and the extending sls files must
     use the stateconf renderer for this ``extend`` to work!)

     Notice that the end of configuration  marker  (#  ---  end  of  state
     config  --) is needed to separate the use of 'stateconf.set' form the
     rest of your salt file. The regex that matches  such  marker  can  be
     configured  via  the  stateconf_end_marker  option  in your master or
     minion config file.

     Sometimes, it is desirable to set a  default  argument  value  that's
     based on earlier arguments in the same stateconf.set. For example, it
     may be tempting to do something like this:

        #!stateconf yaml . jinja

        .apache:
          stateconf.set:
            - host: localhost
            - port: 1234
            - url: 'http://{{host}}:{{port}}/'

        # --- end of state config ---

        .test:
          cmd.run:
            - name: echo '{{apache.url}}'
            - cwd: /

     However, this won't work. It can however be worked around like so:

        #!stateconf yaml . jinja

        .apache:
          stateconf.set:
            - host: localhost
            - port: 1234
        {#  - url: 'http://{{host}}:{{port}}/' #}

        # --- end of state config ---
        # {{ apache.setdefault('url', "http://%(host)s:%(port)s/" % apache) }}

        .test:
          cmd.run:
            - name: echo '{{apache.url}}'
            - cwd: /

   * Adds support for relative include and exclude of .sls files. Example:

        #!stateconf yaml . jinja

        include:
          - .apache
          - .db.mysql
          - ..app.django

        exclude:
          - sls: .users

     If the above is written in a salt file at salt://some/where.sls  then
     it  will include salt://some/apache.sls, salt://some/db/mysql.sls and
     salt://app/django.sls, and exclude  salt://some/users.ssl.  Actually,
     it does that by rewriting the above include and exclude into:

        include:
          - some.apache
          - some.db.mysql
          - app.django

        exclude:
          - sls: some.users

   * Optionally  (enabled  by default, disable via the -G renderer option,
     e.g. in the shebang line: #!stateconf -G), generates a  stateconf.set
     goal  state (state id named as .goal by default, configurable via the
     master/minion config option, stateconf_goal_state) that requires  all
     other states in the salt file. Note, the .goal state id is subject to
     dot-prefix rename rule mentioned earlier.

     Such goal state is intended to  be  required  by  some  state  in  an
     including  salt  file.  For example, in your webapp salt file, if you
     include a sls file that is supposed to setup Tomcat, you  might  want
     to  make sure that all states in the Tomcat sls file will be executed
     before some state in the webapp sls file.

   * Optionally (enable via the -o renderer option, e.g.  in  the  shebang
     line:  #!stateconf  -o),  orders the states in a sls file by adding a
     require requisite to each state such that every  state  requires  the
     state  defined  just  before  it. The order of the states here is the
     order they are defined in the sls file. (Note: this feature  is  only
     available  if your minions are using Python >= 2.7. For Python2.6, it
     should also work if you install the ordereddict module from PyPI)

     By enabling this feature, you are basically agreeing to  author  your
     sls files in a way that gives up the explicit (or implicit?) ordering
     imposed  by  the  use  of  require,  watch,  require_in  or  watch_in
     requisites,  and  instead, you rely on the order of states you define
     in the sls files. This may or may  not  be  a  better  way  for  you.
     However,  if  there  are  many  states defined in a sls file, then it
     tends to be easier to see the order they will be executed  with  this
     feature.

     You  are  still  allowed  to  use  all  the  requisites,  with  a few
     restrictions.  You cannot require or watch a state defined after  the
     current  state.  Similarly,  in  a  state,  you  cannot require_in or
     watch_in  a  state  defined  before  it.  Breaking  any  of  the  two
     restrictions  above  will  result  in a state loop. The renderer will
     check for such incorrect uses if this feature is enabled.

     Additionally, names declarations cannot be  used  with  this  feature
     because  the way they are compiled into low states make it impossible
     to guarantee the order in which they will be executed. This  is  also
     checked  by  the  renderer. As a workaround for not being able to use
     names, you can achieve the same effect, by generate your states  with
     the template engine available within your sls file.

     Finally,  with the use of this feature, it becomes possible to easily
     make an included sls file execute all its  states  after  some  state
     (say, with id X) in the including sls file.  All you have to do is to
     make state, X, require_in the first state defined in the included sls
     file.

   When  writing sls files with this renderer, one should avoid using what
   can be defined in a name argument of a state as the  state's  id.  That
   is, avoid writing states like this:

      /path/to/some/file:
        file.managed:
          - source: salt://some/file

      cp /path/to/some/file file2:
        cmd.run:
          - cwd: /
          - require:
            - file: /path/to/some/file

   Instead,  define the state id and the name argument separately for each
   state. Also,  the  ID  should  be  something  meaningful  and  easy  to
   reference  within  a  requisite (which is a good habit anyway, and such
   extra indirection would also  makes  the  sls  file  easier  to  modify
   later). Thus, the above states should be written like this:

      add-some-file:
        file.managed:
          - name: /path/to/some/file
          - source: salt://some/file

      copy-files:
        cmd.run:
          - name: cp /path/to/some/file file2
          - cwd: /
          - require:
            - file: add-some-file

   Moreover,  when  referencing  a  state  from  a  requisite,  you should
   reference the state's id plus the state name rather than the state name
   plus  its  name  argument. (Yes, in the above example, you can actually
   require  the   file:   /path/to/some/file,   instead   of   the   file:
   add-some-file).  The  reason  is  that  this  renderer will re-write or
   rename state id's and their references for state id's prefixed with  ..
   So,  if you reference name then there's no way to reliably rewrite such
   reference.

   salt.renderers.wempy
   salt.renderers.wempy.render(template_file,   saltenv='base',    sls='',
   argline='', context=None, **kws)
          Render  the  data  passing  the  functions  and  grains into the
          rendering system

          Return type
                 string

   salt.renderers.yaml
   Understanding YAML
   The default renderer for SLS files is the  YAML  renderer.  YAML  is  a
   markup language with many powerful features. However, Salt uses a small
   subset of YAML that maps over very commonly used data structures,  like
   lists  and dictionaries. It is the job of the YAML renderer to take the
   YAML data structure and compile it into a Python data structure for use
   by Salt.

   Though YAML syntax may seem daunting and terse at first, there are only
   three very simple rules to remember when writing YAML for SLS files.

   Rule One: Indentation
   YAML uses a fixed indentation scheme to represent relationships between
   data layers. Salt requires that the indentation for each level consists
   of exactly two spaces. Do not use tabs.

   Rule Two: Colons
   Python dictionaries are, of course, simply key-value pairs. Users  from
   other  languages  may recognize this data type as hashes or associative
   arrays.

   Dictionary keys are represented in YAML  as  strings  terminated  by  a
   trailing  colon.   Values  are represented by either a string following
   the colon, separated by a space:

      my_key: my_value

   In Python, the above maps to:

      {'my_key': 'my_value'}

   Dictionaries can be nested:

      first_level_dict_key:
        second_level_dict_key: value_in_second_level_dict

   And in Python:

      {'first_level_dict_key': {'second_level_dict_key': 'value_in_second_level_dict' }

   Rule Three: Dashes
   To represent lists of items, a single dash followed by a space is used.
   Multiple  items  are  a  part  of  the same list as a function of their
   having the same level of indentation.

      - list_value_one
      - list_value_two
      - list_value_three

   Lists can be the value of a key-value pair. This  is  quite  common  in
   Salt:

      my_dictionary:
        - list_value_one
        - list_value_two
        - list_value_three

   Reference
   YAML Renderer for Salt

   For YAML usage information see Understanding YAML.

   salt.renderers.yaml.get_yaml_loader(argline)
          Return the ordered dict yaml loader

   salt.renderers.yaml.render(yaml_data,      saltenv='base',      sls='',
   argline='', **kws)
          Accepts YAML as a string or as a file object and runs it through
          the YAML parser.

          Return type
                 A Python data structure

   salt.renderers.yamlex
   YAMLEX  renderer is a replacement of the YAML renderer.  It's 100% YAML
   with a pinch of Salt magic:

   * All mappings are automatically OrderedDict

   * All strings are automatically str obj

   * data  aggregation  with  !aggregation  yaml   tag,   based   on   the
     salt.utils.aggregation module.

   * data aggregation over documents for pillar

   Instructed aggregation within the !aggregation and the !reset tags:

      #!yamlex
      foo: !aggregate first
      foo: !aggregate second
      bar: !aggregate {first: foo}
      bar: !aggregate {second: bar}
      baz: !aggregate 42
      qux: !aggregate default
      !reset qux: !aggregate my custom data

   is roughly equivalent to

      foo: [first, second]
      bar: {first: foo, second: bar}
      baz: [42]
      qux: [my custom data]

   Reference
   salt.renderers.yamlex.render(sls_data, saltenv='base', sls='', **kws)
          Accepts  YAML_EX  as  a  string  or as a file object and runs it
          through the YAML_EX parser.

          Return type
                 A Python data structure

USING SALT

   This section describes the fundamental components and concepts that you
   need to understand to use Salt.

   Grains
   Salt comes with an interface to derive information about the underlying
   system.  This is called the grains interface, because it presents  salt
   with  grains  of  information.  Grains  are collected for the operating
   system, domain name, IP address, kernel,  OS  type,  memory,  and  many
   other system properties.

   The  grains  interface is made available to Salt modules and components
   so that the right salt minion commands are automatically  available  on
   the right systems.

   Grain  data  is relatively static, though if system information changes
   (for example, if network settings are changed), or if a  new  value  is
   assigned to a custom grain, grain data is refreshed.

   NOTE:
      Grains  resolve  to  lowercase  letters.  For  example, FOO, and foo
      target the same grain.

   Listing Grains
   Available grains can be listed by using the 'grains.ls' module:

      salt '*' grains.ls

   Grains data can be listed by using the 'grains.items' module:

      salt '*' grains.items

   Grains in the Minion Config
   Grains can also be statically assigned within the minion  configuration
   file.  Just add the option grains and pass options to it:

      grains:
        roles:
          - webserver
          - memcache
        deployment: datacenter4
        cabinet: 13
        cab_u: 14-15

   Then status data specific to your servers can be retrieved via Salt, or
   used inside of the State system for matching. It also makes  targeting,
   in  the  case of the example above, simply based on specific data about
   your deployment.

   Grains in /etc/salt/grains
   If you do not want to place your custom static  grains  in  the  minion
   config  file,  you can also put them in /etc/salt/grains on the minion.
   They are configured in the same way  as  in  the  above  example,  only
   without a top-level grains: key:

      roles:
        - webserver
        - memcache
      deployment: datacenter4
      cabinet: 13
      cab_u: 14-15

   Matching Grains in the Top File
   With  correctly  configured  grains on the Minion, the top file used in
   Pillar or during Highstate can be made  very  efficient.  For  example,
   consider the following configuration:

      'node_type:webserver':
        - match: grain
        - webserver

      'node_type:postgres':
        - match: grain
        - postgres

      'node_type:redis':
        - match: grain
        - redis

      'node_type:lb':
        - match: grain
        - lb

   For  this  example  to  work,  you would need to have defined the grain
   node_type for the minions you wish to match.  This  simple  example  is
   nice,  but  too  much  of  the code is similar. To go one step further,
   Jinja templating can be used to simplify the top file.

      {% set the_node_type = salt['grains.get']('node_type', '') %}

      {% if the_node_type %}
        'node_type:{{ the_node_type }}':
          - match: grain
          - {{ the_node_type }}
      {% endif %}

   Using Jinja templating, only one match entry needs to be defined.

   NOTE:
      The example above  uses  the  grains.get  function  to  account  for
      minions which do not have the node_type grain set.

   Writing Grains
   The grains are derived by executing all of the "public" functions (i.e.
   those which do not begin with  an  underscore)  found  in  the  modules
   located in the Salt's core grains code, followed by those in any custom
   grains modules. The functions in a grains module must return  a  Python
   dict, where the dictionary keys are the names of grains, and each key's
   value is that value for that grain.

   Custom grains modules should be placed in a subdirectory named  _grains
   located  under  the file_roots specified by the master config file. The
   default path would be /srv/salt/_grains. Custom grains modules will  be
   distributed to the minions when state.highstate is run, or by executing
   the saltutil.sync_grains or saltutil.sync_all functions.

   Grains modules are easy to write, and (as noted  above)  only  need  to
   return a dictionary. For example:

      def yourfunction():
           # initialize a grains dictionary
           grains = {}
           # Some code for logic that sets grains like
           grains['yourcustomgrain'] = True
           grains['anothergrain'] = 'somevalue'
           return grains

   The  name  of the function does not matter and will not factor into the
   grains data at all; only the keys/values returned become  part  of  the
   grains.

   When to Use a Custom Grain
   Before  adding  new grains, consider what the data is and remember that
   grains should (for the most part) be static data.

   If the data is something that  is  likely  to  change,  consider  using
   Pillar  or  an  execution  module  instead.  If  it's  a  simple set of
   key/value pairs, pillar is a good match. If compiling  the  information
   requires  that system commands be run, then putting this information in
   an execution module is likely a better idea.

   Good candidates for grains  are  data  that  is  useful  for  targeting
   minions in the top file or the Salt CLI. The name and data structure of
   the grain should be  designed  to  support  many  platforms,  operating
   systems  or  applications.  Also, keep in mind that Jinja templating in
   Salt supports referencing pillar data as  well  as  invoking  functions
   from  execution  modules,  so  there's  no need to place information in
   grains to make it available to Jinja templates. For example:

      ...
      ...
      {{ salt['module.function_name']('argument_1', 'argument_2') }}
      {{ pillar['my_pillar_key'] }}
      ...
      ...

   WARNING:
      Custom grains will not be available in the top file until after  the
      first highstate. To make custom grains available on a minion's first
      highstate, it is recommended to use this example to ensure that  the
      custom grains are synced when the minion starts.

   Loading Custom Grains
   If you have multiple functions specifying grains that are called from a
   main function,  be  sure  to  prepend  grain  function  names  with  an
   underscore.  This  prevents  Salt from including the loaded grains from
   the grain functions in the final grain  data  structure.  For  example,
   consider this custom grain file:

      #!/usr/bin/env python
      def _my_custom_grain():
          my_grain = {'foo': 'bar', 'hello': 'world'}
          return my_grain

      def main():
          # initialize a grains dictionary
          grains = {}
          grains['my_grains'] = _my_custom_grain()
          return grains

   The output of this example renders like so:

      # salt-call --local grains.items
      local:
          ----------
          <Snipped for brevity>
          my_grains:
              ----------
              foo:
                  bar
              hello:
                  world

   However,  if  you  don't  prepend  the my_custom_grain function with an
   underscore, the function will be rendered twice by Salt  in  the  items
   output:  once for the my_custom_grain call itself, and again when it is
   called in the main function:

      # salt-call --local grains.items
      local:
      ----------
          <Snipped for brevity>
          foo:
              bar
          <Snipped for brevity>
          hello:
              world
          <Snipped for brevity>
          my_grains:
              ----------
              foo:
                  bar
              hello:
                  world

   Precedence
   Core grains can be overridden by custom grains. As  there  are  several
   ways  of  defining custom grains, there is an order of precedence which
   should be kept in mind when defining them. The order of  evaluation  is
   as follows:

   1. Core grains.

   2. Custom grains in /etc/salt/grains.

   3. Custom grains in /etc/salt/minion.

   4. Custom grain modules in _grains directory, synced to minions.

   Each  successive  evaluation overrides the previous ones, so any grains
   defined by custom grains modules synced to minions that have  the  same
   name  as  a core grain will override that core grain. Similarly, grains
   from /etc/salt/minion  override  both  core  grains  and  custom  grain
   modules,  and  grains  in  _grains will override any grains of the same
   name.

   Examples of Grains
   The core module in the grains package is  where  the  main  grains  are
   loaded  by the Salt minion and provides the principal example of how to
   write grains:

   https://github.com/saltstack/salt/blob/develop/salt/grains/core.py

   Syncing Grains
   Syncing grains can be done a number of  ways,  they  are  automatically
   synced  when  state.highstate is called, or (as noted above) the grains
   can be manually synced and reloaded by calling the saltutil.sync_grains
   or saltutil.sync_all functions.

   Storing Static Data in the Pillar
   Pillar  is  an  interface for Salt designed to offer global values that
   can be distributed to minions. Pillar data is managed in a similar  way
   as the Salt State Tree.

   Pillar was added to Salt in version 0.9.8

   NOTE:
      Storing sensitive data

      Unlike  state  tree,  pillar data is only available for the targeted
      minion specified by the matcher type.   This  makes  it  useful  for
      storing sensitive data specific to a particular minion.

   Declaring the Master Pillar
   The  Salt Master server maintains a pillar_roots setup that matches the
   structure of the file_roots used in the Salt file server. Like the Salt
   file  server  the  pillar_roots option in the master config is based on
   environments mapping to directories. The pillar data is then mapped  to
   minions  based  on matchers in a top file which is laid out in the same
   way as the state top file. Salt pillars can use the same matcher  types
   as the standard top file.

   The  configuration  for  the  pillar_roots in the master config file is
   identical in behavior and function as file_roots:

      pillar_roots:
        base:
          - /srv/pillar

   This example configuration declares that the base environment  will  be
   located  in the /srv/pillar directory. It must not be in a subdirectory
   of the state tree.

   The top file used matches the name of the top file used for States, and
   has the same structure:

   /srv/pillar/top.sls

      base:
        '*':
          - packages

   In the above top file, it is declared that in the base environment, the
   glob matching all minions will  have  the  pillar  data  found  in  the
   packages  pillar  available  to  it. Assuming the pillar_roots value of
   /srv/pillar taken from above, the packages pillar would be  located  at
   /srv/pillar/packages.sls.

   Any  number  of  matchers  can  be  added  to the base environment. For
   example, here is an expanded version of  the  Pillar  top  file  stated
   above:

   /srv/pillar/top.sls:

      base:
        '*':
          - packages
        'web*':
          - vim

   In  this expanded top file, minions that match web* will have access to
   the /srv/pillar/packages.sls file, as well as  the  /srv/pillar/vim.sls
   file.

   Another  example  shows how to use other standard top matching types to
   deliver specific salt pillar data to minions with different properties.

   Here is an example using  the  grains  matcher  to  target  pillars  to
   minions by their os grain:

      dev:
        'os:Debian':
          - match: grain
          - servers

   /srv/pillar/packages.sls

      {% if grains['os'] == 'RedHat' %}
      apache: httpd
      git: git
      {% elif grains['os'] == 'Debian' %}
      apache: apache2
      git: git-core
      {% endif %}

      company: Foo Industries

   IMPORTANT:
      See  Is  Targeting  using  Grain Data Secure? for important security
      information.

   The above pillar sets two key/value  pairs.  If  a  minion  is  running
   RedHat,  then  the apache key is set to httpd and the git key is set to
   the value of git. If the minion is running  Debian,  those  values  are
   changed  to  apache2  and  git-core respectively. All minions that have
   this pillar targeting to them via a top  file  will  have  the  key  of
   company with a value of Foo Industries.

   Consequently  this  data  can  be  used from within modules, renderers,
   State SLS files, and more via the shared pillar dict:

      apache:
        pkg.installed:
          - name: {{ pillar['apache'] }}

      git:
        pkg.installed:
          - name: {{ pillar['git'] }}

   Finally, the above states can utilize the values provided to  them  via
   Pillar.   All  pillar values targeted to a minion are available via the
   'pillar' dictionary. As seen in the above example,  Jinja  substitution
   can  then  be  utilized  to  access  the  keys and values in the Pillar
   dictionary.

   Note that  you  cannot  just  list  key/value-information  in  top.sls.
   Instead,  target  a  minion to a pillar file and then list the keys and
   values in the pillar. Here is an example top file that illustrates this
   point:

      base:
        '*':
           - common_pillar

   And the actual pillar file at '/srv/pillar/common_pillar.sls':

      foo: bar
      boo: baz

   Pillar namespace flattened
   The separate pillar files all share the same namespace. Given a top.sls
   of:

      base:
        '*':
          - packages
          - services

   a packages.sls file of:

      bind: bind9

   and a services.sls file of:

      bind: named

   Then a request for the bind pillar will only return  named;  the  bind9
   value  is  not  available.  It is better to structure your pillar files
   with more hierarchy. For example your package.sls file could look like:

      packages:
        bind: bind9

   Pillar Namespace Merges
   With some care, the pillar namespace can merge  content  from  multiple
   pillar  files  under  a single key, so long as conflicts are avoided as
   described above.

   For example, if the above example were modified as follows, the  values
   are merged below a single key:

      base:
        '*':
          - packages
          - services

   And a packages.sls file like:

      bind:
        package-name: bind9
        version: 9.9.5

   And a services.sls file like:

      bind:
        port: 53
        listen-on: any

   The resulting pillar will be as follows:

      $ salt-call pillar.get bind
      local:
          ----------
          listen-on:
              any
          package-name:
              bind9
          port:
              53
          version:
              9.9.5

   NOTE:
      Pillar  files  are  applied  in the order they are listed in the top
      file.  Therefore conflicting keys will be overwritten in a 'last one
      wins'  manner!   For  example, in the above scenario conflicting key
      values in services will overwrite those in packages because it's  at
      the bottom of the list.

   Including Other Pillars
   New in version 0.16.0.

   Pillar  SLS  files  may  include  other  pillar files, similar to State
   files. Two syntaxes are available for this  purpose.  The  simple  form
   simply  includes  the  additional pillar as if it were part of the same
   file:

      include:
        - users

   The full include form allows two additional options -- passing  default
   values to the templating engine for the included pillar file as well as
   an optional key under which to nest the results of the included pillar:

      include:
        - users:
            defaults:
                sudo: ['bob', 'paul']
            key: users

   With this form, the included file (users.sls) will be nested within the
   'users' key of the compiled pillar. Additionally, the 'sudo' value will
   be available as a template variable to users.sls.

   Viewing Minion Pillar
   Once the pillar is set up the data can be viewed on the minion via  the
   pillar module, the pillar module comes with functions, pillar.items and
   pillar.raw.  pillar.items will return a  freshly  reloaded  pillar  and
   pillar.raw will return the current pillar without a refresh:

      salt '*' pillar.items

   NOTE:
      Prior  to  version  0.16.2, this function is named pillar.data. This
      function name is still supported for backwards compatibility.

   Pillar get Function
   New in version 0.14.0.

   The pillar.get function works much in the same way as the get method in
   a  python  dict, but with an enhancement: nested dict components can be
   extracted using a : delimiter.

   If a structure like this is in pillar:

      foo:
        bar:
          baz: qux

   Extracting it from the raw pillar in an sls formula or file template is
   done this way:

      {{ pillar['foo']['bar']['baz'] }}

   Now,  with  the new pillar.get function the data can be safely gathered
   and a default can be set, allowing the template to  fall  back  if  the
   value is not available:

      {{ salt['pillar.get']('foo:bar:baz', 'qux') }}

   This makes handling nested structures much easier.

   NOTE:
      pillar.get() vs salt['pillar.get']()

      It  should  be  noted that within templating, the pillar variable is
      just a dictionary.  This means that calling pillar.get() inside of a
      template  will just use the default dictionary .get() function which
      does not include the extra : delimiter functionality.   It  must  be
      called  using  the  above  syntax (salt['pillar.get']('foo:bar:baz',
      'qux')) to get the salt function, instead of the default  dictionary
      behavior.

   Refreshing Pillar Data
   When  pillar  data is changed on the master the minions need to refresh
   the  data  locally.  This  is  done  with  the  saltutil.refresh_pillar
   function.

      salt '*' saltutil.refresh_pillar

   This  function triggers the minion to asynchronously refresh the pillar
   and will always return None.

   Set Pillar Data at the Command Line
   Pillar data can be set at the command line like the following example:

      salt '*' state.apply pillar='{"cheese": "spam"}'

   This will add a Pillar key of cheese with its value set to spam.

   NOTE:
      Be aware  that  when  sending  sensitive  data  via  pillar  on  the
      command-line  that  the  publication  containing  that  data will be
      received by all minions and will not be restricted to  the  targeted
      minions. This may represent a security concern in some cases.

   Master Config In Pillar
   For convenience the data stored in the master configuration file can be
   made available in all minion's pillars. This makes global configuration
   of  services  and systems very easy but may not be desired if sensitive
   data is stored in the master configuration. This option is disabled  by
   default.

   To  enable  the  master  config  from  being  added  to  the pillar set
   pillar_opts to True:

      pillar_opts: True

   Minion Config in Pillar
   Minion configuration options can be set on pillars. Any option that you
   want  to  modify,  should  be in the first level of the pillars, in the
   same way you set the options  in  the  config  file.  For  example,  to
   configure  the  MySQL  root password to be used by MySQL Salt execution
   module, set the following pillar variable:

      mysql.pass: hardtoguesspassword

   Master Provided Pillar Error
   By default if there is an error rendering a pillar, the detailed  error
   is hidden and replaced with:

      Rendering SLS 'my.sls' failed. Please see master log for details.

   The error is protected because it's possible to contain templating data
   which would give that minion information  it  shouldn't  know,  like  a
   password!

   To  have  the  master provide the detailed error that could potentially
   carry protected data set pillar_safe_render_error to False:

      pillar_safe_render_error: False

   Pillar Walkthrough
   NOTE:
      This walkthrough assumes that the reader has already  completed  the
      initial Salt walkthrough.

   Pillars are tree-like structures of data defined on the Salt Master and
   passed through to minions. They allow confidential, targeted data to be
   securely sent only to the relevant minion.

   NOTE:
      Grains  and Pillar are sometimes confused, just remember that Grains
      are data about a minion  which  is  stored  or  generated  from  the
      minion.   This is why information like the OS and CPU type are found
      in Grains.  Pillar is information about a  minion  or  many  minions
      stored or generated on the Salt Master.

   Pillar data is useful for:

   Highly Sensitive Data:
          Information  transferred  via  pillar  is  guaranteed to only be
          presented to  the  minions  that  are  targeted,  making  Pillar
          suitable    for   managing   security   information,   such   as
          cryptographic keys and passwords.

   Minion Configuration:
          Minion modules  such  as  the  execution  modules,  states,  and
          returners can often be configured via data stored in pillar.

   Variables:
          Variables  which  need  to  be  assigned  to specific minions or
          groups of minions can be defined in  pillar  and  then  accessed
          inside sls formulas and template files.

   Arbitrary Data:
          Pillar  can  contain  any  basic  data  structure  in dictionary
          format, so a key/value store can be defined making  it  easy  to
          iterate over a group of values in sls formulas.

   Pillar  is therefore one of the most important systems when using Salt.
   This walkthrough is designed to get a simple Pillar up and running in a
   few  minutes and then to dive into the capabilities of Pillar and where
   the data is available.

   Setting Up Pillar
   The pillar is already running in Salt by default. To see  the  minion's
   pillar data:

      salt '*' pillar.items

   NOTE:
      Prior  to  version  0.16.2, this function is named pillar.data. This
      function name is still supported for backwards compatibility.

   By default the contents of the master  configuration  file  are  loaded
   into pillar for all minions. This enables the master configuration file
   to be used for global configuration of minions.

   Similar to the state tree, the pillar is comprised of sls files and has
   a top file.  The default location for the pillar is in /srv/pillar.

   NOTE:
      The  pillar  location  can be configured via the pillar_roots option
      inside  the  master  configuration  file.  It  must  not  be  in   a
      subdirectory of the state tree or file_roots. If the pillar is under
      file_roots, any pillar targeting can be bypassed by minions.

   To start setting up the pillar, the /srv/pillar directory needs  to  be
   present:

      mkdir /srv/pillar

   Now create a simple top file, following the same format as the top file
   used for states:

   /srv/pillar/top.sls:

      base:
        '*':
          - data

   This top file associates the data.sls file  to  all  minions.  Now  the
   /srv/pillar/data.sls file needs to be populated:

   /srv/pillar/data.sls:

      info: some data

   To ensure that the minions have the new pillar data, issue a command to
   them asking that they fetch their pillars from the master:

      salt '*' saltutil.refresh_pillar

   Now that the minions have the new pillar, it can be retrieved:

      salt '*' pillar.items

   The key info should now appear in the returned pillar data.

   More Complex Data
   Unlike states, pillar files do  not  need  to  define  formulas.   This
   example sets up user data with a UID:

   /srv/pillar/users/init.sls:

      users:
        thatch: 1000
        shouse: 1001
        utahdave: 1002
        redbeard: 1003

   NOTE:
      The  same directory lookups that exist in states exist in pillar, so
      the file users/init.sls can be referenced  with  users  in  the  top
      file.

   The top file will need to be updated to include this sls file:

   /srv/pillar/top.sls:

      base:
        '*':
          - data
          - users

   Now  the  data will be available to the minions. To use the pillar data
   in a state, you can use Jinja:

   /srv/salt/users/init.sls

      {% for user, uid in pillar.get('users', {}).items() %}
      {{user}}:
        user.present:
          - uid: {{uid}}
      {% endfor %}

   This approach allows for users to be safely defined  in  a  pillar  and
   then the user data is applied in an sls file.

   Parameterizing States With Pillar
   Pillar  data  can  be accessed in state files to customise behavior for
   each minion. All pillar (and grain) data applicable to each  minion  is
   substituted  into  the state files through templating before being run.
   Typical uses include setting directories appropriate for the minion and
   skipping states that don't apply.

   A  simple example is to set up a mapping of package names in pillar for
   separate Linux distributions:

   /srv/pillar/pkg/init.sls:

      pkgs:
        {% if grains['os_family'] == 'RedHat' %}
        apache: httpd
        vim: vim-enhanced
        {% elif grains['os_family'] == 'Debian' %}
        apache: apache2
        vim: vim
        {% elif grains['os'] == 'Arch' %}
        apache: apache
        vim: vim
        {% endif %}

   The new pkg sls needs to be added to the top file:

   /srv/pillar/top.sls:

      base:
        '*':
          - data
          - users
          - pkg

   Now the minions will auto map  values  based  on  respective  operating
   systems inside of the pillar, so sls files can be safely parameterized:

   /srv/salt/apache/init.sls:

      apache:
        pkg.installed:
          - name: {{ pillar['pkgs']['apache'] }}

   Or, if no pillar is available a default can be set as well:

   NOTE:
      The  function  pillar.get  used in this example was added to Salt in
      version 0.14.0

   /srv/salt/apache/init.sls:

      apache:
        pkg.installed:
          - name: {{ salt['pillar.get']('pkgs:apache', 'httpd') }}

   In the above example, if the pillar value  pillar['pkgs']['apache']  is
   not set in the minion's pillar, then the default of httpd will be used.

   NOTE:
      Under the hood, pillar is just a Python dict, so Python dict methods
      such as get and items can be used.

   Pillar Makes Simple States Grow Easily
   One of the design goals of pillar is to make simple sls formulas easily
   grow  into  more  flexible formulas without refactoring or complicating
   the states.

   A simple formula:

   /srv/salt/edit/vim.sls:

      vim:
        pkg.installed: []

      /etc/vimrc:
        file.managed:
          - source: salt://edit/vimrc
          - mode: 644
          - user: root
          - group: root
          - require:
            - pkg: vim

   Can be easily transformed into a powerful, parameterized formula:

   /srv/salt/edit/vim.sls:

      vim:
        pkg.installed:
          - name: {{ pillar['pkgs']['vim'] }}

      /etc/vimrc:
        file.managed:
          - source: {{ pillar['vimrc'] }}
          - mode: 644
          - user: root
          - group: root
          - require:
            - pkg: vim

   Where the vimrc source location can now be changed via pillar:

   /srv/pillar/edit/vim.sls:

      {% if grains['id'].startswith('dev') %}
      vimrc: salt://edit/dev_vimrc
      {% elif grains['id'].startswith('qa') %}
      vimrc: salt://edit/qa_vimrc
      {% else %}
      vimrc: salt://edit/vimrc
      {% endif %}

   Ensuring that the right vimrc is sent out to the correct minions.

   Setting Pillar Data on the Command Line
   Pillar data can be set on the command  line  when  running  state.apply
   <salt.modules.state.apply_() like so:

      salt '*' state.apply pillar='{"foo": "bar"}'
      salt '*' state.apply my_sls_file pillar='{"hello": "world"}'

   Nested pillar values can also be set via the command line:

      salt '*' state.sls my_sls_file pillar='{"foo": {"bar": "baz"}}'

   NOTE:
      If  a  key  is passed on the command line that already exists on the
      minion, the key that is passed in will overwrite the entire value of
      that  key,  rather than merging only the specified value set via the
      command line.

   The example below will swap the  value  for  vim  with  telnet  in  the
   previously specified list, notice the nested pillar dict:

      salt '*' state.apply edit.vim pillar='{"pkgs": {"vim": "telnet"}}'

   This  will  attempt  to  install  telnet  on your minions, feel free to
   uninstall the package or replace telnet value with anything else.

   NOTE:
      Be aware  that  when  sending  sensitive  data  via  pillar  on  the
      command-line  that  the  publication  containing  that  data will be
      received by all minions and will not be restricted to  the  targeted
      minions. This may represent a security concern in some cases.

   More On Pillar
   Pillar data is generated on the Salt master and securely distributed to
   minions. Salt is not restricted to the pillar sls files  when  defining
   the  pillar  but  can  retrieve data from external sources. This can be
   useful when information about an infrastructure is stored in a separate
   location.

   Reference  information  on pillar and the external pillar interface can
   be found in the Salt documentation:

   Pillar

   Minion Config in Pillar
   Minion configuration options can be set on pillars. Any option that you
   want  to  modify,  should  be in the first level of the pillars, in the
   same way you set the options  in  the  config  file.  For  example,  to
   configure  the  MySQL  root password to be used by MySQL Salt execution
   module:

      mysql.pass: hardtoguesspassword

   This is very convenient when you need some dynamic configuration change
   that you want to be applied on the fly. For example, there is a chicken
   and the egg problem if you do this:

      mysql-admin-passwd:
        mysql_user.present:
          - name: root
          - password: somepasswd

      mydb:
        mysql_db.present

   The second state will fail, because you changed the root  password  and
   the  minion  didn't  notice  it. Setting mysql.pass in the pillar, will
   help to sort out the issue. But always change the root  admin  password
   in the first place.

   This  is  very  helpful  for any module that needs credentials to apply
   state changes: mysql, keystone, etc.

   Targeting Minions
   Targeting minions is specifying which minions should run a  command  or
   execute  a  state by matching against hostnames, or system information,
   or defined groups, or even combinations thereof.

   For example the command salt web1 apache.signal restart to restart  the
   Apache  httpd  server  specifies the machine web1 as the target and the
   command will only be run on that one minion.

   Similarly when using States, the following top file specifies that only
   the web1 minion should execute the contents of webserver.sls:

      base:
        'web1':
          - webserver

   The simple target specifications, glob, regex, and list will cover many
   use cases, and for some will cover all use  cases,  but  more  powerful
   options exist.

   Targeting with Grains
   The  Grains  interface  was  built  into  Salt  to  allow minions to be
   targeted by system properties.  So  minions  running  on  a  particular
   operating  system  can  be  called to execute a function, or a specific
   kernel.

   Calling via a  grain  is  done  by  passing  the  -G  option  to  salt,
   specifying  a  grain  and  a  glob expression to match the value of the
   grain. The syntax for the  target  is  the  grain  key  followed  by  a
   globexpression: "os:Arch*".

      salt -G 'os:Fedora' test.ping

   Will return True from all of the minions running Fedora.

   To  discover what grains are available and what the values are, execute
   the grains.item salt function:

      salt '*' grains.items

   more info on using targeting with grains can be found here.

   Compound Targeting
   New in version 0.9.5.

   Multiple target interfaces can be used in conjunction to determine  the
   command  targets.  These  targets  can then be combined using and or or
   statements. This is well defined with an example:

      salt -C 'G@os:Debian and webser* or E@db.*' test.ping

   In this example any minion who's id starts with webser and  is  running
   Debian, or any minion who's id starts with db will be matched.

   The  type  of  matcher  defaults to glob, but can be specified with the
   corresponding letter followed by the @ symbol. In the above  example  a
   grain  is  used  with  G@  as well as a regular expression with E@. The
   webser* target does  not  need  to  be  prefaced  with  a  target  type
   specifier because it is a glob.

   more info on using compound targeting can be found here.

   Node Group Targeting
   New in version 0.9.5.

   For  certain  cases, it can be convenient to have a predefined group of
   minions on which to execute commands. This can  be  accomplished  using
   what  are  called  nodegroups. Nodegroups allow for predefined compound
   targets to be declared in the master configuration file, as a  sort  of
   shorthand for having to type out complicated compound expressions.

      nodegroups:
        group1: '[email protected],bar.domain.com,baz.domain.com and bl*.domain.com'
        group2: 'G@os:Debian and foo.domain.com'
        group3: 'G@os:Debian and N@group1'

   There  are  many ways to target individual minions or groups of minions
   in Salt:

   Matching the minion id
   Each minion needs a unique identifier. By default when a minion  starts
   for  the  first time it chooses its FQDN as that identifier. The minion
   id can be overridden via the minion's id configuration setting.

   TIP:
      minion id and minion keys

      The minion id is used to generate the minion's  public/private  keys
      and  if  it  ever changes the master must then accept the new key as
      though the minion was a new host.

   Globbing
   The default matching that Salt utilizes is shell-style globbing  around
   the minion id. This also works for states in the top file.

   NOTE:
      You  must  wrap  salt  calls  that  use globbing in single-quotes to
      prevent the shell from expanding the globs before Salt is invoked.

   Match all minions:

      salt '*' test.ping

   Match all minions in the example.net  domain  or  any  of  the  example
   domains:

      salt '*.example.net' test.ping
      salt '*.example.*' test.ping

   Match all the webN minions in the example.net domain (web1.example.net,
   web2.example.net ... webN.example.net):

      salt 'web?.example.net' test.ping

   Match the web1 through web5 minions:

      salt 'web[1-5]' test.ping

   Match the web1 and web3 minions:

      salt 'web[1,3]' test.ping

   Match the web-x, web-y, and web-z minions:

      salt 'web-[x-z]' test.ping

   NOTE:
      For additional targeting methods please review the compound matchers
      documentation.

   Regular Expressions
   Minions can be matched using Perl-compatible regular expressions (which
   is globbing on steroids and a ton of caffeine).

   Match both web1-prod and web1-devel minions:

      salt -E 'web1-(prod|devel)' test.ping

   When using regular expressions in a State's top file, you must  specify
   the  matcher  as  the  first option. The following example executes the
   contents of webserver.sls on the above-mentioned minions.

      base:
        'web1-(prod|devel)':
        - match: pcre
        - webserver

   Lists
   At the most basic level, you can specify a flat list of minion IDs:

      salt -L 'web1,web2,web3' test.ping

   Targeting using Grains
   Grain data can be used when targeting minions.

   For example, the following matches all CentOS minions:

      salt -G 'os:CentOS' test.ping

   Match all minions with 64-bit CPUs, and return number of CPU cores  for
   each matching minion:

      salt -G 'cpuarch:x86_64' grains.item num_cpus

   Additionally,  globs  can be used in grain matches, and grains that are
   nested in a dictionary can be matched by adding a colon for each  level
   that  is  traversed.  For  example, the following will match hosts that
   have a grain called ec2_tags, which itself is a dict with a  key  named
   environment, which has a value that contains the word production:

      salt -G 'ec2_tags:environment:*production*'

   IMPORTANT:
      See  Is  Targeting  using  Grain Data Secure? for important security
      information.

   Targeting using Pillar
   Pillar data can  be  used  when  targeting  minions.  This  allows  for
   ultimate control and flexibility when targeting minions.

   NOTE:
      To start using Pillar targeting it is required to make a Pillar data
      cache on Salt Master for each Minion via  following  commands:  salt
      '*'  saltutil.refresh_pillar  or  salt  '*' saltutil.sync_all.  Also
      Pillar data cache will be populated during the highstate  run.  Once
      Pillar  data  changes,  you  must refresh the cache by running above
      commands for this targeting method to work correctly.

   Example:

      salt -I 'somekey:specialvalue' test.ping

   Like with Grains, it is possible to  use  globbing  as  well  as  match
   nested  values in Pillar, by adding colons for each level that is being
   traversed. The below example would match minions with  a  pillar  named
   foo,  which is a dict containing a key bar, with a value beginning with
   baz:

      salt -I 'foo:bar:baz*' test.ping

   Subnet/IP Address Matching
   Minions can easily be matched based on IP address, or by subnet  (using
   CIDR notation).

      salt -S 192.168.40.20 test.ping
      salt -S 10.0.0.0/24 test.ping

   Ipcidr matching can also be used in compound matches

      salt -C '[email protected]/24 and G@os:Debian' test.ping

   It is also possible to use in both pillar and state-matching

      '172.16.0.0/12':
         - match: ipcidr
         - internal

   NOTE:
      Only IPv4 matching is supported at this time.

   Compound matchers
   Compound  matchers  allow  very  granular minion targeting using any of
   Salt's matchers. The default matcher is a glob match, just as with  CLI
   and  top  file  matching.  To  match  using anything other than a glob,
   prefix the match string with the  appropriate  letter  from  the  table
   below, followed by an @ sign.


Letter  Match Type       Example                                   Alt Delimiter? 

G       Grains glob      G@os:Ubuntu                               Yes            

E       PCRE Minion ID   E@web\d+\.(dev|qa|prod)\.loc              No             

P       Grains PCRE      P@os:(RedHat|Fedora|CentOS)               Yes            

L       List of minions  [email protected],minion3.domain.com  No             
                     or bl*.domain.com                                        

I       Pillar glob      I@pdata:foobar                            Yes            

J       Pillar PCRE      J@pdata:^(foo|bar)$                       Yes            

S       Subnet/IP        [email protected]/24 or [email protected]       No             

R       Range cluster    R@%foo.bar                                No             


   Matchers can be joined using boolean and, or, and not operators.

   For example, the following string matches all  Debian  minions  with  a
   hostname  that  begins with webserv, as well as any minions that have a
   hostname which matches the regular expression web-dc1-srv.*:

      salt -C 'webserv* and G@os:Debian or E@web-dc1-srv.*' test.ping

   That same example expressed in a top file looks like the following:

      base:
        'webserv* and G@os:Debian or E@web-dc1-srv.*':
          - match: compound
          - webserver

   New in version 2015.8.0.

   Excluding a minion based on its ID is also possible:

      salt -C 'not web-dc1-srv' test.ping

   Versions prior to 2015.8.0 a leading not was not supported in  compound
   matches. Instead, something like the following was required:

      salt -C '* and not G@kernel:Darwin' test.ping

   Excluding a minion based on its ID was also possible:

      salt -C '* and not web-dc1-srv' test.ping

   Precedence Matching
   Matchers can be grouped together with parentheses to explicitly declare
   precedence amongst groups.

      salt -C '( ms-1 or G@id:ms-3 ) and G@id:ms-3' test.ping

   NOTE:
      Be certain to note that spaces are required between the  parentheses
      and  targets.  Failing  to  obey  this  rule may result in incorrect
      targeting!

   Alternate Delimiters
   New in version 2015.8.0.

   Matchers that target based on a key value pair use a  colon  (:)  as  a
   delimiter.  Matchers  with  a  Yes  in the Alt Delimiters column in the
   previous table support specifying an alternate delimiter character.

   This is done by specifying an alternate delimiter character between the
   leading  matcher  character and the @ pattern separator character. This
   avoids incorrect interpretation of the pattern in the case  that  :  is
   part of the grain or pillar data structure traversal.

      salt -C 'J|@foo|bar|^foo:bar$ or J!@gitrepo!https://github.com:example/project.git' test.ping

   Node groups
   Nodegroups  are  declared  using  a  compound target specification. The
   compound target documentation can be found here.

   The  nodegroups  master  config  file  parameter  is  used  to   define
   nodegroups.   Here's   an   example   nodegroup   configuration  within
   /etc/salt/master:

      nodegroups:
        group1: '[email protected],bar.domain.com,baz.domain.com or bl*.domain.com'
        group2: 'G@os:Debian and foo.domain.com'
        group3: 'G@os:Debian and N@group1'
        group4:
          - 'G@foo:bar'
          - 'or'
          - 'G@foo:baz'

   NOTE:
      The L within group1 is matching a list of minions, while  the  G  in
      group2  is  matching  specific  grains.  See  the  compound matchers
      documentation for more details.

   New in version 2015.8.0.

   NOTE:
      Nodegroups can reference other nodegroups as seen in group3.  Ensure
      that  you do not have circular references.  Circular references will
      be detected and cause partial expansion with a logged error message.

   New in version 2015.8.0.

   Compound nodegroups can be either string  values  or  lists  of  string
   values.   When  the  nodegroup  is  A string value will be tokenized by
   splitting on whitespace.  This  may  be  a  problem  if  whitespace  is
   necessary  as part of a pattern.  When a nodegroup is a list of strings
   then tokenization will happen for each list element as a whole.

   To match a nodegroup on the CLI, use the -N command-line option:

      salt -N group1 test.ping

   NOTE:
      The N@ classifier cannot be used in compound matches within the  CLI
      or  top  file, it is only recognized in the nodegroups master config
      file parameter.

   To match a nodegroup in your top  file,  make  sure  to  put  -  match:
   nodegroup on the line directly following the nodegroup name.

      base:
        group1:
          - match: nodegroup
          - webserver

   NOTE:
      When  adding or modifying nodegroups to a master configuration file,
      the  master  must  be  restarted  for  those  changes  to  be  fully
      recognized.

      A  limited  amount  of functionality, such as targeting with -N from
      the command-line may be available without a restart.

   Defining Nodegroups as Lists of Minion IDs
   A simple list of minion IDs would traditionally be defined like this:

      nodegroups:
        - group1: L@host1,host2,host3

   They can now also be defined as a YAML list, like this:

      nodegroups:
        - group1:
          - host1
          - host2
          - host3

   New in version 2016.11.0.

   Using Nodegroups in SLS files
   To use Nodegroups in Jinja logic for SLS files, the pillar_opts  option
   in  /etc/salt/master  must  be set to True. This will pass the master's
   configuration as Pillar data to each minion.

   NOTE:
      If the master's configuration contains any sensitive data, this will
      be passed to each minion.  Do not enable this option if you have any
      configuration data that you do not want to get on your minions.

      Also, if you make changes to your nodegroups, you might need to  run
      salt '*' saltutil.refresh_pillar after restarting the master.

   Once  pillar_opts is set to True, you can find the nodegroups under the
   "master" pillar.  To make  sure  that  only  the  correct  minions  are
   targeted,  you  should  use  each matcher for the nodegroup definition.
   For example, to check if a minion is in the 'webserver' nodegroup:

      nodegroups:
        webserver: 'G@os:Debian and L@minion1,minion2'

      {% if grains.id in salt['pillar.get']('master:nodegroups:webserver', [])
      and grains.os in salt['pillar.get']('master:nodegroups:webserver', []) %}
      ...
      {% endif %}

   NOTE:
      If you do  not  include  all  of  the  matchers  used  to  define  a
      nodegroup,  Salt  might incorrectly target minions that meet some of
      the nodegroup requirements, but not all of them.

   Batch Size
   The -b (or --batch-size) option allows commands to be executed on  only
   a  specified  number  of minions at a time. Both percentages and finite
   numbers are supported.

      salt '*' -b 10 test.ping

      salt -G 'os:RedHat' --batch-size 25% apache.signal restart

   This will only run test.ping on 10 of the targeted minions  at  a  time
   and  then  restart apache on 25% of the minions matching os:RedHat at a
   time and work through them all until the task is complete.  This  makes
   jobs  like  rolling web server restarts behind a load balancer or doing
   maintenance on BSD firewalls using carp much easier with salt.

   The batch system maintains a window of running minions,  so,  if  there
   are  a total of 150 minions targeted and the batch size is 10, then the
   command is sent to 10 minions, when one minion returns then the command
   is sent to one additional minion, so that the job is constantly running
   on 10 minions.

   New in version 2016.3.

   The --batch-wait argument can be used to specify a number of seconds to
   wait  after  a  minion  returns,  before  sending  the command to a new
   minion.

   SECO Range
   SECO range is a cluster-based metadata store developed  and  maintained
   by Yahoo!

   The Range project is hosted here:

   https://github.com/ytoolshed/range

   Learn more about range here:

   https://github.com/ytoolshed/range/wiki/

   Prerequisites
   To  utilize  range support in Salt, a range server is required. Setting
   up a range server is outside the scope of this document. Apache modules
   are included in the range distribution.

   With a working range server, cluster files must be defined. These files
   are written in YAML and define hosts contained inside a  cluster.  Full
   documentation on writing YAML range files is here:

   https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec

   Additionally,  the Python seco range libraries must be installed on the
   salt master. One can verify that they have been installed correctly via
   the following command:

      python -c 'import seco.range'

   If  no errors are returned, range is installed successfully on the salt
   master.

   Preparing Salt
   Range support must be  enabled  on  the  salt  master  by  setting  the
   hostname  and  port of the range server inside the master configuration
   file:

      range_server: my.range.server.com:80

   Following this, the master must be restarted for the change to have  an
   effect.

   Targeting with Range
   Once a cluster has been defined, it can be targeted with a salt command
   by using the -R or --range flags.

   For example, given the following range YAML file being  served  from  a
   range server:

      $ cat /etc/range/test.yaml
      CLUSTER: host1..100.test.com
      APPS:
        - frontend
        - backend
        - mysql

   One might target host1 through host100 in the test.com domain with Salt
   as follows:

      salt --range %test:CLUSTER test.ping

   The following salt command would target three hosts: frontend, backend,
   and mysql:

      salt --range %test:APPS test.ping

   The Salt Mine
   The  Salt Mine is used to collect arbitrary data from Minions and store
   it on the Master. This data is then made available to all  Minions  via
   the salt.modules.mine module.

   Mine  data  is gathered on the Minion and sent back to the Master where
   only the most recent data is maintained (if long term data is  required
   use returners or the external job cache).

   Mine vs Grains
   Mine  data  is  designed  to  be  much more up-to-date than grain data.
   Grains are refreshed on a very limited basis  and  are  largely  static
   data.  Mines  are  designed  to replace slow peer publishing calls when
   Minions need data from other Minions. Rather than having a Minion reach
   out  to  all  the  other  Minions  for  a piece of data, the Salt Mine,
   running on the Master, can  collect  it  from  all  the  Minions  every
   mine-interval,  resulting  in almost fresh data at any given time, with
   much less overhead.

   Mine Functions
   To enable the Salt Mine the mine_functions option needs to  be  applied
   to  a Minion. This option can be applied via the Minion's configuration
   file, or the Minion's Pillar. The mine_functions option  dictates  what
   functions  are being executed and allows for arguments to be passed in.
   If no arguments are passed, an empty list must be added:

      mine_functions:
        test.ping: []
        network.ip_addrs:
          interface: eth0
          cidr: '10.0.0.0/8'

   Mine Functions Aliases
   Function  aliases  can  be  used  to  provide  friendly  names,   usage
   intentions  or  to  allow  multiple  calls  of  the  same function with
   different arguments. There is a different syntax for passing positional
   and  key-value  arguments. Mixing positional and key-value arguments is
   not supported.

   New in version 2014.7.0.

      mine_functions:
        network.ip_addrs: [eth0]
        networkplus.internal_ip_addrs: []
        internal_ip_addrs:
          mine_function: network.ip_addrs
          cidr: 192.168.0.0/16
        ip_list:
          - mine_function: grains.get
          - ip_interfaces

   Mine Interval
   The Salt Mine functions are executed when the Minion starts  and  at  a
   given  interval  by  the  scheduler.  The  default interval is every 60
   minutes and can be  adjusted  for  the  Minion  via  the  mine_interval
   option:

      mine_interval: 60

   Mine in Salt-SSH
   As of the 2015.5.0 release of salt, salt-ssh supports mine.get.

   Because   the   Minions   cannot   provide   their  own  mine_functions
   configuration, we retrieve the args for specified mine functions in one
   of three places, searched in the following order:

   1. Roster data

   2. Pillar

   3. Master config

   The  mine_functions  are  formatted exactly the same as in normal salt,
   just stored in a different location. Here  is  an  example  of  a  flat
   roster containing mine_functions:

      test:
        host: 104.237.131.248
        user: root
        mine_functions:
          cmd.run: ['echo "hello!"']
          network.ip_addrs:
            interface: eth0

   NOTE:
      Because of the differences in the architecture of salt-ssh, mine.get
      calls are somewhat inefficient. Salt must make a new  salt-ssh  call
      to  each  of the Minions in question to retrieve the requested data,
      much like a publish call. However, unlike publish, it must  run  the
      requested  function  as  a  wrapper function, so we can retrieve the
      function args from the  pillar  of  the  Minion  in  question.  This
      results in a non-trivial delay in retrieving the requested data.

   Minions Targeting with Mine
   The  mine.get function supports various methods of Minions targeting to
   fetch Mine  data  from  particular  hosts,  such  as  glob  or  regular
   expression  matching  on Minion id (name), grains, pillars and compound
   matches.  See  the  salt.modules.mine  module  documentation  for   the
   reference.

   NOTE:
      Pillar  data  needs  to  be cached on Master for pillar targeting to
      work with Mine. Read the note in relevant section.

   Example
   One way to use data from Salt Mine is in a State.  The  values  can  be
   retrieved  via Jinja and used in the SLS file. The following example is
   a partial HAProxy configuration file and pulls IP  addresses  from  all
   Minions  with  the "web" grain to add them to the pool of load balanced
   servers.

   /srv/pillar/top.sls:

      base:
        'G@roles:web':
          - web

   /srv/pillar/web.sls:

      mine_functions:
        network.ip_addrs: [eth0]

   /etc/salt/minion.d/mine.conf:

      mine_interval: 5

   /srv/salt/haproxy.sls:

      haproxy_config:
        file.managed:
          - name: /etc/haproxy/config
          - source: salt://haproxy_config
          - template: jinja

   /srv/salt/haproxy_config:

      <...file contents snipped...>

      {% for server, addrs in salt['mine.get']('roles:web', 'network.ip_addrs', expr_form='grain') | dictsort() %}
      server {{ server }} {{ addrs[0] }}:80 check
      {% endfor %}

      <...file contents snipped...>

   NOTE:
      The expr_form argument will be renamed to tgt_type in  the  Nitrogen
      release of Salt.

   Runners
   Salt  runners  are  convenience applications executed with the salt-run
   command.

   Salt runners work similarly to  Salt  execution  modules  however  they
   execute on the Salt master itself instead of remote Salt minions.

   A Salt runner can be a simple client call or a complex application.

   SEE ALSO:
      The full list of runners

   Writing Salt Runners
   A  Salt  runner  is  written  in  a  similar manner to a Salt execution
   module.  Both are Python  modules  which  contain  functions  and  each
   public  function  is  a  runner  which may be executed via the salt-run
   command.

   For example, if a Python module named test.py is created in the runners
   directory  and contains a function called foo, the test runner could be
   invoked with the following command:

      # salt-run test.foo

   Runners have several options for controlling output.

   Any print statement in a runner is automatically also  fired  onto  the
   master event bus where. For example:

      def a_runner(outputter=None, display_progress=False):
          print('Hello world')
          ...

   The above would result in an event fired as follows:

      Event fired at Tue Jan 13 15:26:45 2015
      *************************
      Tag: salt/run/20150113152644070246/print
      Data:
      {'_stamp': '2015-01-13T15:26:45.078707',
       'data': 'hello',
        'outputter': 'pprint'}

   A runner may also send a progress event, which is displayed to the user
   during runner execution and is also passed across the event bus if  the
   display_progress argument to a runner is set to True.

   A  custom  runner  may  send  its  own  progress  event  by  using  the
   __jid_event_.fire_event() method as shown here:

      if display_progress:
          __jid_event__.fire_event({'message': 'A progress message'}, 'progress')

   The above would produce output  on  the  console  reading:  A  progress
   message as well as an event on the event similar to:

      Event fired at Tue Jan 13 15:21:20 2015
      *************************
      Tag: salt/run/20150113152118341421/progress
      Data:
      {'_stamp': '2015-01-13T15:21:20.390053',
       'message': "A progress message"}

   A runner could use the same approach to send an event with a customized
   tag onto the event bus by replacing the second argument (progress) with
   whatever  tag  is  desired.  However,  this  will  not  be shown on the
   command-line and will only be fired onto the event bus.

   Synchronous vs. Asynchronous
   A runner may be fired  asynchronously  which  will  immediately  return
   control.  In  this  case,  no  output  will  be  display to the user if
   salt-run is being used from the command-line. If used programmatically,
   no  results  will  be  returned.   If results are desired, they must be
   gathered either by firing events on the bus from the  runner  and  then
   watching for them or by some other means.

   NOTE:
      When running a runner in asynchronous mode, the --progress flag will
      not deliver output to the salt-run  CLI.  However,  progress  events
      will still be fired on the bus.

   In synchronous mode, which is the default, control will not be returned
   until the runner has finished executing.

   To add  custom  runners,  put  them  in  a  directory  and  add  it  to
   runner_dirs in the master configuration file.

   Examples
   Examples of runners can be found in the Salt distribution:

   https://github.com/saltstack/salt/blob/develop/salt/runners

   A  simple runner that returns a well-formatted list of the minions that
   are responding to Salt calls could look like this:

      # Import salt modules
      import salt.client

      def up():
          '''
          Print a list of all of the minions that are up
          '''
          client = salt.client.LocalClient(__opts__['conf_file'])
          minions = client.cmd('*', 'test.ping', timeout=1)
          for minion in sorted(minions):
              print minion

   Salt Engines
   New in version 2015.8.0.

   Salt Engines are long-running, external system processes that  leverage
   Salt.

   * Engines  have  access  to  Salt configuration, execution modules, and
     runners (__opts__, __salt__, and __runners__).

   * Engines are executed in a separate process that is monitored by Salt.
     If a Salt engine stops, it is restarted automatically.

   * Engines can run on the Salt master and on Salt minions.

   Salt engines enhance and replace the external processes functionality.

   Configuration
   Salt  engines are configured under an engines top-level section in your
   Salt master or Salt minion configuration. Provide a list of engines and
   parameters under this section.

      engines:
        - logstash:
            host: log.my_network.com
            port: 5959

   Salt  engines must be in the Salt path, or you can add the engines_dirs
   option in your Salt master configuration with  a  list  of  directories
   under which Salt attempts to find Salt engines.

   Writing an Engine
   An                 example                 Salt                 engine,
   https://github.com/saltstack/salt/blob/develop/salt/engines/test.py, is
   available   in  the  Salt  source.  To  develop  an  engine,  the  only
   requirement is that your module implement the start() function.

   Understanding YAML
   The default renderer for SLS files is the  YAML  renderer.  YAML  is  a
   markup language with many powerful features. However, Salt uses a small
   subset of YAML that maps over very commonly used data structures,  like
   lists  and dictionaries. It is the job of the YAML renderer to take the
   YAML data structure and compile it into a Python data structure for use
   by Salt.

   Though YAML syntax may seem daunting and terse at first, there are only
   three very simple rules to remember when writing YAML for SLS files.

   Rule One: Indentation
   YAML uses a fixed indentation scheme to represent relationships between
   data layers. Salt requires that the indentation for each level consists
   of exactly two spaces. Do not use tabs.

   Rule Two: Colons
   Python dictionaries are, of course, simply key-value pairs. Users  from
   other  languages  may recognize this data type as hashes or associative
   arrays.

   Dictionary keys are represented in YAML  as  strings  terminated  by  a
   trailing colon. Values are represented by either a string following the
   colon, separated by a space:

      my_key: my_value

   In Python, the above maps to:

      {'my_key': 'my_value'}

   Alternatively,  a  value  can  be  associated  with   a   key   through
   indentation.

      my_key:
        my_value

   NOTE:
      The  above syntax is valid YAML but is uncommon in SLS files because
      most often, the value for a key is not singular  but  instead  is  a
      list of values.

   In Python, the above maps to:

      {'my_key': 'my_value'}

   Dictionaries can be nested:

      first_level_dict_key:
        second_level_dict_key: value_in_second_level_dict

   And in Python:

      {
          'first_level_dict_key': {
              'second_level_dict_key': 'value_in_second_level_dict'
          }
      }

   Rule Three: Dashes
   To represent lists of items, a single dash followed by a space is used.
   Multiple items are a part of the same  list  as  a  function  of  their
   having the same level of indentation.

      - list_value_one
      - list_value_two
      - list_value_three

   Lists  can  be  the  value of a key-value pair. This is quite common in
   Salt:

      my_dictionary:
        - list_value_one
        - list_value_two
        - list_value_three

   In Python, the above maps to:

      {'my_dictionary': ['list_value_one', 'list_value_two', 'list_value_three']}

   Learning More
   One easy way to learn more about how YAML  gets  rendered  into  Python
   data  structures  is  to  use  an  online YAML parser to see the Python
   output.

   One  excellent  choice  for  experimenting  with   YAML   parsing   is:
   http://yaml-online-parser.appspot.com/

   Templating
   Jinja  statements  and expressions are allowed by default in SLS files.
   See Understanding Jinja.

   Understanding Jinja
   Jinja is the default templating language in SLS files.

   Jinja in States
   Jinja is evaluated before YAML, which means it is evaluated before  the
   States are run.

   The  most  basic  usage  of  Jinja  in  state  files  is  using control
   structures to wrap conditional or redundant state elements:

      {% if grains['os'] != 'FreeBSD' %}
      tcsh:
          pkg:
              - installed
      {% endif %}

      motd:
        file.managed:
          {% if grains['os'] == 'FreeBSD' %}
          - name: /etc/motd
          {% elif grains['os'] == 'Debian' %}
          - name: /etc/motd.tail
          {% endif %}
          - source: salt://motd

   In this example, the first if block will only be evaluated  on  minions
   that aren't running FreeBSD, and the second block changes the file name
   based on the os grain.

   Writing if-else blocks can lead to very redundant state files  however.
   In  this  case,  using  pillars, or using a previously defined variable
   might be easier:

      {% set motd = ['/etc/motd'] %}
      {% if grains['os'] == 'Debian' %}
        {% set motd = ['/etc/motd.tail', '/var/run/motd'] %}
      {% endif %}

      {% for motdfile in motd %}
      {{ motdfile }}:
        file.managed:
          - source: salt://motd
      {% endfor %}

   Using a variable set by the template, the for loop  will  iterate  over
   the list of MOTD files to update, adding a state block for each file.

   The  filter_by  function  can  also  be  used to set variables based on
   grains:

      {% set auditd = salt['grains.filter_by']({
      'RedHat': { 'package': 'audit' },
      'Debian': { 'package': 'auditd' },
      }) %}

   Include and Import
   Includes and imports can  be  used  to  share  common,  reusable  state
   configuration between state files and between files.

      {% from 'lib.sls' import test %}

   This  would  import  the  test template variable or macro, not the test
   state element, from the file lib.sls. In the  case  that  the  included
   file  performs  checks  again  grains,  or something else that requires
   context, passing the context into the included file is required:

      {% from 'lib.sls' import test with context %}

   Including Context During Include/Import
   By adding with context to the  include/import  directive,  the  current
   context can be passed to an included/imported template.

      {% import 'openssl/vars.sls' as ssl with context %}

   Macros
   Macros  are  helpful  for  eliminating  redundant code. Macros are most
   useful as mini-templates  to  repeat  blocks  of  strings  with  a  few
   parameterized  variables.   Be aware that stripping whitespace from the
   template block, as well  as  contained  blocks,  may  be  necessary  to
   emulate a variable return from the macro.

      # init.sls
      {% from 'lib.sls' import pythonpkg with context %}

      python-virtualenv:
        pkg.installed:
          - name: {{ pythonpkg('virtualenv') }}

      python-fabric:
        pkg.installed:
          - name: {{ pythonpkg('fabric') }}

      # lib.sls
      {% macro pythonpkg(pkg) -%}
        {%- if grains['os'] == 'FreeBSD' -%}
          py27-{{ pkg }}
        {%- elif grains['os'] == 'Debian' -%}
          python-{{ pkg }}
        {%- endif -%}
      {%- endmacro %}

   This  would  define  a  macro  that  would  return a string of the full
   package name, depending on the packaging  system's  naming  convention.
   The  whitespace  of  the  macro was eliminated, so that the macro would
   return a string without line breaks, using whitespace control.

   Template Inheritance
   Template inheritance works fine from state files and files. The  search
   path starts at the root of the state tree or pillar.

   Filters
   Saltstack extends builtin filters with these custom filters:

   strftime
          Converts  any  time  related object into a time based string. It
          requires a valid strftime directives. An exhaustive list can  be
          found in the official Python documentation.

             {% set curtime = None | strftime() %}

          Fuzzy dates require the timelib Python module is installed.

             {{ "2002/12/25"|strftime("%y") }}
             {{ "1040814000"|strftime("%Y-%m-%d") }}
             {{ datetime|strftime("%u") }}
             {{ "tomorrow"|strftime }}

   sequence
          Ensure that parsed data is a sequence.

   yaml_encode
          Serializes a single object into a YAML scalar with any necessary
          handling for escaping special characters.  This  will  work  for
          any  scalar  YAML data type: ints, floats, timestamps, booleans,
          strings, unicode.  It will not work for  multi-objects  such  as
          sequences or maps.

             {%- set bar = 7 %}
             {%- set baz = none %}
             {%- set zip = true %}
             {%- set zap = 'The word of the day is "salty"' %}

             {%- load_yaml as foo %}
             bar: {{ bar|yaml_encode }}
             baz: {{ baz|yaml_encode }}
             baz: {{ zip|yaml_encode }}
             baz: {{ zap|yaml_encode }}
             {%- endload %}

          In  the  above  case  {{  bar  }}  and  {{  foo.bar }} should be
          identical and {{ baz }} and {{ foo.baz }} should be identical.

   yaml_dquote
          Serializes a string into a properly-escaped  YAML  double-quoted
          string.   This  is  useful  when  the  contents  of a string are
          unknown and may contain quotes  or  unicode  that  needs  to  be
          preserved.   The  resulting  string will be emitted with opening
          and closing double quotes.

             {%- set bar = '"The quick brown fox . . ."' %}
             {%- set baz = 'The word of the day is "salty".' %}

             {%- load_yaml as foo %}
             bar: {{ bar|yaml_dquote }}
             baz: {{ baz|yaml_dquote }}
             {%- endload %}

          In the above case  {{  bar  }}  and  {{  foo.bar  }}  should  be
          identical  and  {{ baz }} and {{ foo.baz }} should be identical.
          If variable contents are not guaranteed to be a string  then  it
          is  better  to  use  yaml_encode  which  handles all YAML scalar
          types.

   yaml_squote
          Similar to the yaml_dquote filter but with single quotes.   Note
          that  YAML  only  allows special escapes inside double quotes so
          yaml_squote is not nearly as useful (viz. you likely want to use
          yaml_encode or yaml_dquote).

   Jinja in Files
   Jinja_
    can be used in the same way in managed files:

      # redis.sls
      /etc/redis/redis.conf:
          file.managed:
              - source: salt://redis.conf
              - template: jinja
              - context:
                  bind: 127.0.0.1

      # lib.sls
      {% set port = 6379 %}

      # redis.conf
      {% from 'lib.sls' import port with context %}
      port {{ port }}
      bind {{ bind }}

   As  an example, configuration was pulled from the file context and from
   an external template file.

   NOTE:
      Macros and variables can be shared across templates. They should not
      be  starting  with one or more underscores, and should be managed by
      one  of  the  following  tags:  macro,  set,  load_yaml,  load_json,
      import_yaml and import_json.

   Escaping Jinja
   Occasionally, it may be necessary to escape Jinja syntax. There are two
   ways to to do this in Jinja. One is escaping  individual  variables  or
   strings and the other is to escape entire blocks.

   To  escape  a  string commonly used in Jinja syntax such as {{, you can
   use the following syntax:

      {{ '{{' }}

   For larger blocks that contain Jinja syntax that needs to  be  escaped,
   you can use raw blocks:

      {% raw %}
          some text that contains jinja characters that need to be escaped
      {% endraw %}

   See the Escaping section of Jinja's documentation to learn more.

   A real-word example of needing to use raw tags to escape a larger block
   of code is when using file.managed with the contents_pillar  option  to
   manage  files that contain something like consul-template, which shares
   a syntax subset with Jinja. Raw blocks are necessary here  because  the
   Jinja  in  the pillar would be rendered before the file.managed is ever
   called, so the Jinja syntax must be escaped:

      {% raw %}
      - contents_pillar: |
          job "example-job" {
            <snipped>
            task "example" {
                driver = "docker"

                config {
                    image = "docker-registry.service.consul:5000/example-job:{{key "nomad/jobs/example-job/version"}}"
            <snipped>
      {% endraw %}

   Calling Salt Functions
   The Jinja renderer provides a shorthand  lookup  syntax  for  the  salt
   dictionary of execution function.

   New in version 2014.7.0.

      # The following two function calls are equivalent.
      {{ salt['cmd.run']('whoami') }}
      {{ salt.cmd.run('whoami') }}

   Debugging
   The  show_full_context  function  can  be  used to output all variables
   present in the current Jinja context.

   New in version 2014.7.0.

      Context is: {{ show_full_context() }}

   Custom Execution Modules
   Custom execution modules can be used to supplement or  replace  complex
   Jinja.  Many  tasks  that require complex looping and logic are trivial
   when using Python in a Salt execution module.  Salt  execution  modules
   are easy to write and distribute to Salt minions.

   Functions  in  custom  execution  modules  are  available  in  the Salt
   execution module dictionary just like the built-in execution modules:

      {{ salt['my_custom_module.my_custom_function']() }}

   * How to Convert Jinja Logic to an Execution Module

   * Writing Execution Modules

   Tutorials Index
   * Salt as a Cloud Controller

   * Using Cron with Salt

   * Automatic Updates / Frozen Deployments

   * ESXi Proxy Minion

   * Opening the Firewall up for Salt

   * Git Fileserver Backend Walkthrough

   * Halite

   * HTTP Modules

   * Using Salt at Scale

   * LXC Management with Salt

   * MinionFS Backend Walkthrough

   * Remote Execution Tutorial

   * Multi-Master-PKI Tutorial With Failover

   * Multi Master Tutorial

   * Pillar Walkthrough

   * Preseed Minion with Accepted Key

   * Packaging External Modules for Salt

   * Salt Masterless Quickstart

   * running salt as normal user tutorial

   * Salt Bootstrap

   * Standalone Minion

   * How Do I Use Salt States?

   * States tutorial, part 1 - Basic Usage

   * States tutorial, part 2 - More Complex States, Requisites

   * States tutorial, part 3 - Templating, Includes, Extends

   * States tutorial, part 4

   * How to Convert Jinja Logic to an Execution Module

   * Using Salt with Stormpath

   * Syslog-ng usage

   * The  MacOS  X  (Maverick)  Developer  Step  By  Step  Guide  To  Salt
     Installation

   * SaltStack Walk-through

   * Writing Salt Tests

   Troubleshooting
   The  intent of the troubleshooting section is to introduce solutions to
   a number of common issues encountered by users and the tools  that  are
   available to aid in developing States and Salt code.

   Troubleshooting the Salt Master
   If  your  Salt  master  is  having issues such as minions not returning
   data, slow execution times, or a variety of other issues, the following
   links  contain  details  on  troubleshooting  the  most  common  issues
   encountered:

   Troubleshooting the Salt Master
   Running in the Foreground
   A great deal of information is available via the debug logging  system,
   if  you  are  having issues with minions connecting or not starting run
   the master in the foreground:

      # salt-master -l debug

   Anyone wanting to run Salt daemons via a  process  supervisor  such  as
   monit,  runit,  or  supervisord,  should  omit  the  -d argument to the
   daemons and run them in the foreground.

   What Ports does the Master Need Open?
   For the master, TCP ports 4505 and 4506 need to be open. If you've  put
   both  your  Salt  master  and  minion  in  debug  mode and don't see an
   acknowledgment that your minion has connected, it could very well be  a
   firewall   interfering   with   the   connection.   See   our  firewall
   configuration page for help opening the firewall on various platforms.

   If you've  opened  the  correct  TCP  ports  and  still  aren't  seeing
   connections,  check  that  no  additional access control system such as
   SELinux or AppArmor is blocking Salt.

   Too many open files
   The salt-master needs at least 2 sockets per host that connects to  it,
   one   for  the  Publisher  and  one  for  response  port.  Thus,  large
   installations may, upon scaling up the number of  minions  accessing  a
   given master, encounter:

      12:45:29,289 [salt.master    ][INFO    ] Starting Salt worker process 38
      Too many open files
      sock != -1 (tcp_listener.cpp:335)

   The  solution  to this would be to check the number of files allowed to
   be opened by the user running salt-master (root by default):

      [root@salt-master ~]# ulimit -n
      1024

   If this value is not equal to at least twice  the  number  of  minions,
   then  it  will  need  to be raised. For example, in an environment with
   1800 minions, the nofile limit should be set to no less than 3600. This
   can  be  done by creating the file /etc/security/limits.d/99-salt.conf,
   with the following contents:

      root        hard    nofile        4096
      root        soft    nofile        4096

   Replace root with the user under which the master runs, if different.

   If your master does not have an /etc/security/limits.d  directory,  the
   lines can simply be appended to /etc/security/limits.conf.

   As  with  any change to resource limits, it is best to stay logged into
   your current shell and open another shell to run ulimit  -n  again  and
   verify  that  the changes were applied correctly. Additionally, if your
   master is running upstart, it may be necessary to  specify  the  nofile
   limit  in  /etc/default/salt-master  if  upstart  isn't respecting your
   resource limits:

      limit nofile 4096 4096

   NOTE:
      The above is simply an example of how to set these values,  and  you
      may  wish to increase them even further if your Salt master is doing
      more than just running Salt.

   Salt Master Stops Responding
   There are known bugs with ZeroMQ versions less than  2.1.11  which  can
   cause  the  Salt  master  to  not respond properly. If you're running a
   ZeroMQ version greater than or equal to 2.1.9, you can work around  the
   bug  by  setting the sysctls net.core.rmem_max and net.core.wmem_max to
   16777216.  Next,  set  the  third  field   in   net.ipv4.tcp_rmem   and
   net.ipv4.tcp_wmem to at least 16777216.

   You can do it manually with something like:

      # echo 16777216 > /proc/sys/net/core/rmem_max
      # echo 16777216 > /proc/sys/net/core/wmem_max
      # echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem
      # echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_wmem

   Or with the following Salt state:

      net.core.rmem_max:
        sysctl:
          - present
          - value: 16777216

      net.core.wmem_max:
        sysctl:
          - present
          - value: 16777216

      net.ipv4.tcp_rmem:
        sysctl:
          - present
          - value: 4096 87380 16777216

      net.ipv4.tcp_wmem:
        sysctl:
          - present
          - value: 4096 87380 16777216

   Live Python Debug Output
   If  the master seems to be unresponsive, a SIGUSR1 can be passed to the
   salt-master threads to display what piece of code  is  executing.  This
   debug information can be invaluable in tracking down bugs.

   To  pass a SIGUSR1 to the master, first make sure the minion is running
   in the foreground. Stop the service if it is running as a  daemon,  and
   start it in the foreground like so:

      # salt-master -l debug

   Then pass the signal to the master when it seems to be unresponsive:

      # killall -SIGUSR1 salt-master

   When  filing  an  issue  or sending questions to the mailing list for a
   problem  with  an  unresponsive  daemon,  be  sure  to   include   this
   information if possible.

   Live Salt-Master Profiling
   When  faced  with  performance  problems one can turn on master process
   profiling by sending it SIGUSR2.

      # killall -SIGUSR2 salt-master

   This will activate yappi profiler inside salt-master code,  then  after
   some  time  one  must  send  SIGUSR2  again  to stop profiling and save
   results to file. If run in foreground salt-master will report  filename
   for  the  results,  which  are usually located under /tmp on Unix-based
   OSes and c:\temp on windows.

   Results can then be analyzed with kcachegrind or similar tool.

   Commands Time Out or Do Not Return Output
   Depending on your OS (this is most common on Ubuntu due to apt-get) you
   may  sometimes  encounter  times  where  a  state.apply,  or other long
   running commands do not return output.

   By default the timeout is set to  5  seconds.  The  timeout  value  can
   easily   be  increased  by  modifying  the  timeout  line  within  your
   /etc/salt/master configuration file.

   Having keys accepted for Salt minions that no longer exist or  are  not
   reachable  also  increases  the possibility of timeouts, since the Salt
   master waits for those systems to return command results.

   Passing the -c Option to Salt Returns a Permissions Error
   Using the -c option with the Salt command  modifies  the  configuration
   directory.  When the configuration file is read it will still base data
   off of the root_dir setting. This can result in unintended behavior  if
   you  are  expecting  files  such as /etc/salt/pki to be pulled from the
   location specified with -c. Modify the root_dir setting to address this
   behavior.

   Salt Master Doesn't Return Anything While Running jobs
   When  a  command  being  run  via Salt takes a very long time to return
   (package installations, certain scripts, etc.) the master may drop  you
   back to the shell. In most situations the job is still running but Salt
   has exceeded the set timeout before returning. Querying the  job  queue
   will  provide  the  data  of  the  job but is inconvenient. This can be
   resolved by either manually using the -t option to set a longer timeout
   when  running commands (by default it is 5 seconds) or by modifying the
   master configuration file: /etc/salt/master  and  setting  the  timeout
   value  to  change  the  default  timeout  for  all  commands,  and then
   restarting the salt-master service.

   Salt Master Auth Flooding
   In large installations, care must be taken not to overwhealm the master
   with  authentication requests. Several options can be set on the master
   which mitigate the chances of an authentication flood from  causing  an
   interruption in service.

   NOTE:
      recon_default:

      The average number of seconds to wait between reconnection attempts.

      recon_max:
             The  maximum  number  of seconds to wait between reconnection
             attempts.

      recon_randomize:
             A flag to indicate whether the recon_default value should  be
             randomized.

      acceptance_wait_time:
             The   number   of  seconds  to  wait  for  a  reply  to  each
             authentication request.

      random_reauth_delay:
             The range of seconds across which the minions should  attempt
             to randomize authentication attempts.

      auth_timeout:
             The  total  time  to  wait  for the authentication process to
             complete, regardless of the number of attempts.

   Running state locally
   To debug the states, you can use call locally.

      salt-call -l trace --local state.highstate

   The top.sls file is used to map what SLS modules get loaded  onto  what
   minions via the state system.

   It  is  located  in  the file defined in the file_roots variable of the
   salt  master  configuration  file  which  is  defined   by   found   in
   CONFIG_DIR/master, normally /etc/salt/master

   The default configuration for the file_roots is:

      file_roots:
        base:
          - /srv/salt

   So the top file is defaulted to the location /srv/salt/top.sls

   Salt Master Umask
   The  salt  master  uses a cache to track jobs as they are published and
   returns come back.  The recommended umask for  a  salt-master  is  022,
   which  is  the default for most users on a system. Incorrect umasks can
   result in permission-denied errors when  the  master  tries  to  access
   files in its cache.

   Troubleshooting the Salt Minion
   In  the  event  that  your  Salt  minion is having issues, a variety of
   solutions and suggestions are available. Please refer to the  following
   links for more information:

   Troubleshooting the Salt Minion
   Running in the Foreground
   A  great deal of information is available via the debug logging system,
   if you are having issues with minions connecting or  not  starting  run
   the minion in the foreground:

      # salt-minion -l debug

   Anyone  wanting  to  run  Salt daemons via a process supervisor such as
   monit, runit, or supervisord,  should  omit  the  -d  argument  to  the
   daemons and run them in the foreground.

   What Ports does the Minion Need Open?
   No  ports  need  to  be  opened  on  the  minion,  as it makes outbound
   connections to the master. If you've put  both  your  Salt  master  and
   minion  in  debug mode and don't see an acknowledgment that your minion
   has connected, it could very well be a firewall  interfering  with  the
   connection.  See  our  firewall configuration page for help opening the
   firewall on various platforms.

   If you have netcat installed, you can check port connectivity from  the
   minion with the nc command:

      $ nc -v -z salt.master.ip.addr 4505
      Connection to salt.master.ip.addr 4505 port [tcp/unknown] succeeded!
      $ nc -v -z salt.master.ip.addr 4506
      Connection to salt.master.ip.addr 4506 port [tcp/unknown] succeeded!

   The Nmap utility can also be used to check if these ports are open:

      # nmap -sS -q -p 4505-4506 salt.master.ip.addr

      Starting Nmap 6.40 ( http://nmap.org ) at 2013-12-29 19:44 CST
      Nmap scan report for salt.master.ip.addr (10.0.0.10)
      Host is up (0.0026s latency).
      PORT     STATE  SERVICE
      4505/tcp open   unknown
      4506/tcp open   unknown
      MAC Address: 00:11:22:AA:BB:CC (Intel)

      Nmap done: 1 IP address (1 host up) scanned in 1.64 seconds

   If  you've  opened  the  correct  TCP  ports  and  still  aren't seeing
   connections, check that no additional access  control  system  such  as
   SELinux or AppArmor is blocking Salt. Tools like tcptraceroute can also
   be used to determine if an intermediate device or firewall is  blocking
   the needed TCP ports.

   Using salt-call
   The  salt-call  command  was  originally  developed  for  aiding in the
   development of new Salt modules. Since  then,  many  applications  have
   been  developed  for running any Salt module locally on a minion. These
   range from the original intent of salt-call  (development  assistance),
   to gathering more verbose output from calls like state.apply.

   When initially creating your state tree, it is generally recommended to
   invoke highstates by running state.apply directly from the minion  with
   salt-call, rather than remotely from the master. This displays far more
   information about the execution than calling it remotely. For even more
   verbosity, increase the loglevel using the -l argument:

      # salt-call -l debug state.apply

   The  main  difference  between  using  salt and using salt-call is that
   salt-call is run from  the  minion,  and  it  only  runs  the  selected
   function  on that minion. By contrast, salt is run from the master, and
   requires you to specify the minions on which to run the  command  using
   salt's targeting system.

   Live Python Debug Output
   If  the minion seems to be unresponsive, a SIGUSR1 can be passed to the
   process to  display  what  piece  of  code  is  executing.  This  debug
   information can be invaluable in tracking down bugs.

   To  pass a SIGUSR1 to the minion, first make sure the minion is running
   in the foreground. Stop the service if it is running as a  daemon,  and
   start it in the foreground like so:

      # salt-minion -l debug

   Then pass the signal to the minion when it seems to be unresponsive:

      # killall -SIGUSR1 salt-minion

   When  filing  an  issue  or sending questions to the mailing list for a
   problem  with  an  unresponsive  daemon,  be  sure  to   include   this
   information if possible.

   Multiprocessing in Execution Modules
   As  is  outlined  in  github  issue  #6300,  Salt  cannot  use python's
   multiprocessing   pipes   and   queues    from    execution    modules.
   Multiprocessing  from  the execution modules is perfectly viable, it is
   just necessary to use Salt's event system to communicate back with  the
   process.

   The  reason  for  this difficulty is that python attempts to pickle all
   objects in memory when communicating, and  it  cannot  pickle  function
   objects.  Since  the  Salt  loader  system creates and manages function
   objects this causes the pickle operation to fail.

   Salt Minion Doesn't Return Anything While Running Jobs Locally
   When a command being run via Salt takes a  very  long  time  to  return
   (package  installations, certain scripts, etc.) the minion may drop you
   back to the shell. In most situations the job is still running but Salt
   has  exceeded  the set timeout before returning. Querying the job queue
   will provide the data of the job  but  is  inconvenient.  This  can  be
   resolved by either manually using the -t option to set a longer timeout
   when running commands (by default it is 5 seconds) or by modifying  the
   minion  configuration  file:  /etc/salt/minion  and setting the timeout
   value to  change  the  default  timeout  for  all  commands,  and  then
   restarting the salt-minion service.

   NOTE:
      Modifying  the  minion  timeout  value  is not required when running
      commands from a Salt  Master.  It  is  only  required  when  running
      commands locally on the minion.

   Running in the Foreground
   A  great deal of information is available via the debug logging system,
   if you are having issues with minions connecting or  not  starting  run
   the minion and/or master in the foreground:

      salt-master -l debug
      salt-minion -l debug

   Anyone  wanting  to  run  Salt daemons via a process supervisor such as
   monit, runit, or supervisord,  should  omit  the  -d  argument  to  the
   daemons and run them in the foreground.

   What Ports do the Master and Minion Need Open?
   No ports need to be opened up on each minion. For the master, TCP ports
   4505 and 4506 need to be open. If you've put both your Salt master  and
   minion  in  debug mode and don't see an acknowledgment that your minion
   has connected, it could very well be a firewall.

   You can check port connectivity from the minion with the nc command:

      nc -v -z salt.master.ip 4505
      nc -v -z salt.master.ip 4506

   There is also a firewall configuration  document  that  might  help  as
   well.

   If you've enabled the right TCP ports on your operating system or Linux
   distribution's firewall and still aren't seeing connections, check that
   no  additional  access  control  system  such as SELinux or AppArmor is
   blocking Salt.

   Using salt-call
   The salt-call command  was  originally  developed  for  aiding  in  the
   development  of  new  Salt  modules. Since then, many applications have
   been developed for running any Salt module locally on a  minion.  These
   range from the original intent of salt-call, development assistance, to
   gathering more verbose output from calls like state.apply.

   When initially creating your state tree, it is generally recommended to
   invoke state.apply directly from the minion with salt-call, rather than
   remotely from the master. This displays far more information about  the
   execution  than  calling it remotely. For even more verbosity, increase
   the loglevel using the -l argument:

      salt-call -l debug state.apply

   The main difference between using salt  and  using  salt-call  is  that
   salt-call  is  run  from  the  minion,  and  it  only runs the selected
   function on that minion. By contrast, salt is run from the master,  and
   requires  you  to specify the minions on which to run the command using
   salt's targeting system.

   Too many open files
   The salt-master needs at least 2 sockets per host that connects to  it,
   one   for  the  Publisher  and  one  for  response  port.  Thus,  large
   installations may, upon scaling up the number of  minions  accessing  a
   given master, encounter:

      12:45:29,289 [salt.master    ][INFO    ] Starting Salt worker process 38
      Too many open files
      sock != -1 (tcp_listener.cpp:335)

   The  solution  to this would be to check the number of files allowed to
   be opened by the user running salt-master (root by default):

      [root@salt-master ~]# ulimit -n
      1024

   And modify that value to be at least equal to the number of  minions  x
   2.   This setting can be changed in limits.conf as the nofile value(s),
   and activated upon new a login of the specified user.

   So, an environment with 1800 minions, would need 1800 x 2 = 3600  as  a
   minimum.

   Salt Master Stops Responding
   There  are  known  bugs with ZeroMQ versions less than 2.1.11 which can
   cause the Salt master to not respond  properly.  If  you're  running  a
   ZeroMQ  version greater than or equal to 2.1.9, you can work around the
   bug by setting the sysctls net.core.rmem_max and  net.core.wmem_max  to
   16777216.   Next,   set   the  third  field  in  net.ipv4.tcp_rmem  and
   net.ipv4.tcp_wmem to at least 16777216.

   You can do it manually with something like:

      # echo 16777216 > /proc/sys/net/core/rmem_max
      # echo 16777216 > /proc/sys/net/core/wmem_max
      # echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem
      # echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_wmem

   Or with the following Salt state:

      net.core.rmem_max:
        sysctl:
          - present
          - value: 16777216

      net.core.wmem_max:
        sysctl:
          - present
          - value: 16777216

      net.ipv4.tcp_rmem:
        sysctl:
          - present
          - value: 4096 87380 16777216

      net.ipv4.tcp_wmem:
        sysctl:
          - present
          - value: 4096 87380 16777216

   Salt and SELinux
   Currently there are no SELinux policies for Salt.  For  the  most  part
   Salt runs without issue when SELinux is running in Enforcing mode. This
   is because when the minion executes as a daemon  the  type  context  is
   changed  to  initrc_t.   The  problem  with  SELinux  arises when using
   salt-call or running the minion  in  the  foreground,  since  the  type
   context stays unconfined_t.

   This  problem  is  generally  manifest  in the rpm install scripts when
   using the pkg module. Until a full SELinux Policy is available for Salt
   the solution to this issue is to set the execution context of salt-call
   and salt-minion to rpm_exec_t:

      # CentOS 5 and RHEL 5:
      chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-minion
      chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-call

      # CentOS 6 and RHEL 6:
      chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-minion
      chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-call

   This works well, because the rpm_exec_t context has very broad  control
   over other types.

   Red Hat Enterprise Linux 5
   Salt  requires  Python  2.6  or 2.7. Red Hat Enterprise Linux 5 and its
   variants come with Python 2.4 installed by default. When installing  on
   RHEL  5  from  the EPEL repository this is handled for you. But, if you
   run Salt from  git,  be  advised  that  its  dependencies  need  to  be
   installed  from  EPEL  and  that Salt needs to be run with the python26
   executable.

   Common YAML Gotchas
   An extensive list of YAML idiosyncrasies has been compiled:

   YAML Idiosyncrasies
   One of Salt's strengths, the use of existing serialization systems  for
   representing  SLS  data,  can  also backfire. YAML is a general purpose
   system and there are a number of things that would seem to  make  sense
   in  an sls file that cause YAML issues. It is wise to be aware of these
   issues. While reports or running into them are generally rare they  can
   still crop up at unexpected times.

   Spaces vs Tabs
   YAML uses spaces, period. Do not use tabs in your SLS files! If strange
   errors are coming up in rendering SLS files, make sure to check that no
   tabs  have  crept  in! In Vim, after enabling search highlighting with:
   :set hlsearch,  you can check with the following key sequence in normal
   mode(you can hit ESC twice to be sure): /, Ctrl-v, Tab, then hit Enter.
   Also, you can convert tabs to 2 spaces by these commands in  Vim:  :set
   tabstop=2 expandtab and then :retab.

   Indentation
   The suggested syntax for YAML files is to use 2 spaces for indentation,
   but YAML will follow whatever indentation system  that  the  individual
   file  uses.  Indentation  of  two  spaces works very well for SLS files
   given the fact that the data is uniform and not deeply nested.

   Nested Dictionaries
   When dicts  are  nested  within  other  data  structures  (particularly
   lists),  the  indentation  logic  sometimes changes.  Examples of where
   this  might  happen  include  context  and  default  options  from  the
   file.managed state:

      /etc/http/conf/http.conf:
        file:
          - managed
          - source: salt://apache/http.conf
          - user: root
          - group: root
          - mode: 644
          - template: jinja
          - context:
              custom_var: "override"
          - defaults:
              custom_var: "default value"
              other_var: 123

   Notice  that  while  the  indentation  is two spaces per level, for the
   values under the context and defaults options  there  is  a  four-space
   indent.  If only two spaces are used to indent, then those keys will be
   considered part of the same dictionary that contains the  context  key,
   and  so the data will not be loaded correctly. If using a double indent
   is not desirable, then a deeply-nested dict can be declared with  curly
   braces:

      /etc/http/conf/http.conf:
        file:
          - managed
          - source: salt://apache/http.conf
          - user: root
          - group: root
          - mode: 644
          - template: jinja
          - context: {
            custom_var: "override" }
          - defaults: {
            custom_var: "default value",
            other_var: 123 }

   Here  is  a  more  concrete  example of how YAML actually handles these
   indentations, using the Python interpreter on the command line:

      >>> import yaml
      >>> yaml.safe_load('''mystate:
      ...   file.managed:
      ...     - context:
      ...         some: var''')
      {'mystate': {'file.managed': [{'context': {'some': 'var'}}]}}
      >>> yaml.safe_load('''mystate:
      ...   file.managed:
      ...     - context:
      ...       some: var''')
      {'mystate': {'file.managed': [{'some': 'var', 'context': None}]}}

   Note that in the second example, some is added as another  key  in  the
   same  dictionary, whereas in the first example, it's the start of a new
   dictionary.  That's  the  distinction.  context  is  a  common  example
   because  it  is  a keyword arg for many functions, and should contain a
   dictionary.

   True/False, Yes/No, On/Off
   PyYAML will load these values as boolean True or False.  Un-capitalized
   versions will also be loaded as booleans (true, false, yes, no, on, and
   off). This can be especially problematic when constructing Pillar data.
   Make  sure  that  your Pillars which need to use the string versions of
   these values are enclosed in quotes.  Pillars will be parsed  twice  by
   salt,  so  you'll  need  to  wrap  your  values in multiple quotes, for
   example '"false"'.

   The '%' Sign
   The % symbol has a special meaning in YAML, it needs to be passed as  a
   string literal:

      cheese:
        ssh_auth.present:
          - user: tbortels
          - source: salt://ssh_keys/chease.pub
          - config: '%h/.ssh/authorized_keys'

   Integers are Parsed as Integers
   NOTE: This has been fixed in salt 0.10.0, as of this release passing an
   integer that is preceded by a 0 will be correctly parsed

   When passing integers into an SLS file, they are  passed  as  integers.
   This  means  that  if  a state accepts a string value and an integer is
   passed, that an integer will be sent. The solution here is to send  the
   integer as a string.

   This is best explained when setting the mode for a file:

      /etc/vimrc:
        file:
          - managed
          - source: salt://edit/vimrc
          - user: root
          - group: root
          - mode: 644

   Salt  manages  this  well,  since the mode is passed as 644, but if the
   mode is zero padded as 0644, then it is read by YAML as an integer  and
   evaluated  as  an octal value, 0644 becomes 420. Therefore, if the file
   mode is preceded by a 0 then it needs to be passed as a string:

      /etc/vimrc:
        file:
          - managed
          - source: salt://edit/vimrc
          - user: root
          - group: root
          - mode: '0644'

   YAML does not like Double Short Decs
   If I can find a way to make YAML accept  "Double  Short  Decs"  then  I
   will, since I think that double short decs would be awesome. So what is
   a "Double Short Dec"? It is when you declare a multiple short  decs  in
   one ID. Here is a standard short dec, it works great:

      vim:
        pkg.installed

   The  short  dec means that there are no arguments to pass, so it is not
   required to add any arguments, and it can save space.

   YAML though, gets upset when declaring multiple  short  decs,  for  the
   record...

   THIS DOES NOT WORK:

      vim:
        pkg.installed
        user.present

   Similarly  declaring  a  short dec in the same ID dec as a standard dec
   does not work either...

   ALSO DOES NOT WORK:

      fred:
        user.present
        ssh_auth.present:
          - name: AAAAB3NzaC...
          - user: fred
          - enc: ssh-dss
          - require:
            - user: fred

   The correct way is to define them like this:

      vim:
        pkg.installed: []
        user.present: []

      fred:
        user.present: []
        ssh_auth.present:
          - name: AAAAB3NzaC...
          - user: fred
          - enc: ssh-dss
          - require:
            - user: fred

   Alternatively,  they can be defined the "old way",   or  with  multiple
   "full decs":

      vim:
        pkg:
          - installed
        user:
          - present

      fred:
        user:
          - present
        ssh_auth:
          - present
          - name: AAAAB3NzaC...
          - user: fred
          - enc: ssh-dss
          - require:
            - user: fred

   YAML support only plain ASCII
   According to YAML specification, only ASCII characters can be used.

   Within  double-quotes,  special  characters  may  be  represented  with
   C-style escape sequences starting with a backslash ( \ ).

   Examples:

      - micro: "\u00b5"
      - copyright: "\u00A9"
      - A: "\x41"
      - alpha: "\u0251"
      - Alef: "\u05d0"

   List of usable Unicode characters  will help you  to  identify  correct
   numbers.

   Python can also be used to discover the Unicode number for a character:

      repr(u"Text with wrong characters i need to figure out")

   This shell command can find wrong characters in your SLS files:

      find . -name '*.sls'  -exec  grep --color='auto' -P -n '[^\x00-\x7F]' \{} \;

   Alternatively  you  can  toggle  the  yaml_utf8  setting in your master
   configuration file. This is still an experimental setting but it should
   manage  the  right  encoding  conversion  in  salt  after  yaml  states
   compilations.

   Underscores stripped in Integer Definitions
   If a definition only includes numbers and underscores, it is parsed  by
   YAML  as  an  integer  and all underscores are stripped.  To ensure the
   object becomes a string, it  should  be  surrounded  by  quotes.   More
   information here.

   Here's an example:

      >>> import yaml
      >>> yaml.safe_load('2013_05_10')
      20130510
      >>> yaml.safe_load('"2013_05_10"')
      '2013_05_10'

   Automatic datetime conversion
   If  there  is  a  value in a YAML file formatted 2014-01-20 14:23:23 or
   similar, YAML will automatically convert  this  to  a  Python  datetime
   object.   These  objects are not msgpack serializable, and so may break
   core salt functionality.  If values such as these are needed in a  salt
   YAML file (specifically a configuration file), they should be formatted
   with surrounding strings to force YAML to serialize them as strings:

      >>> import yaml
      >>> yaml.safe_load('2014-01-20 14:23:23')
      datetime.datetime(2014, 1, 20, 14, 23, 23)
      >>> yaml.safe_load('"2014-01-20 14:23:23"')
      '2014-01-20 14:23:23'

   Additionally, numbers formatted like XXXX-XX-XX will also be  converted
   (or  YAML  will  attempt  to  convert them, and error out if it doesn't
   think the date is a real one).  Thus, for example, if a minion were  to
   have  an ID of 4017-16-20 the minion would not start because YAML would
   complain that the date was out of range.  The workaround is  the  same,
   surround the offending string with quotes:

      >>> import yaml
      >>> yaml.safe_load('4017-16-20')
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File "/usr/local/lib/python2.7/site-packages/yaml/__init__.py", line 93, in safe_load
          return load(stream, SafeLoader)
        File "/usr/local/lib/python2.7/site-packages/yaml/__init__.py", line 71, in load
          return loader.get_single_data()
        File "/usr/local/lib/python2.7/site-packages/yaml/constructor.py", line 39, in get_single_data
          return self.construct_document(node)
        File "/usr/local/lib/python2.7/site-packages/yaml/constructor.py", line 43, in construct_document
          data = self.construct_object(node)
        File "/usr/local/lib/python2.7/site-packages/yaml/constructor.py", line 88, in construct_object
          data = constructor(self, node)
        File "/usr/local/lib/python2.7/site-packages/yaml/constructor.py", line 312, in construct_yaml_timestamp
          return datetime.date(year, month, day)
      ValueError: month must be in 1..12
      >>> yaml.safe_load('"4017-16-20"')
      '4017-16-20'

   Keys Limited to 1024 Characters
   Simple keys are limited to a single line and cannot be longer that 1024
   characters.  This is a limitation from PyYaml, as seen in a comment  in
   PyYAML's code, and applies to anything parsed by YAML in Salt.

   Live Python Debug Output
   If  the  minion  or  master  seems to be unresponsive, a SIGUSR1 can be
   passed to the processes to display where in the code they are  running.
   If  encountering  a  situation like this, this debug information can be
   invaluable. First make sure the master of minion  are  running  in  the
   foreground:

      salt-master -l debug
      salt-minion -l debug

   Then  pass  the  signal  to  the  master  or minion when it seems to be
   unresponsive:

      killall -SIGUSR1 salt-master
      killall -SIGUSR1 salt-minion

   Also under BSD and Mac OS  X  in  addition  to  SIGUSR1  signal,  debug
   subroutine  set  up for SIGINFO which has an advantage of being sent by
   Ctrl+T shortcut.

   When filing an issue or sending questions to the  mailing  list  for  a
   problem with an unresponsive daemon this information can be invaluable.

   Salt 0.16.x minions cannot communicate with a 0.17.x master
   As  of  release 0.17.1 you can no longer run different versions of Salt
   on your Master and Minion servers. This is due to a protocol change for
   security  purposes.  The  Salt  team will continue to attempt to ensure
   versions are as backwards compatible as possible.

   Debugging the Master and Minion
   A list of common master and  minion  troubleshooting  steps  provide  a
   starting point for resolving issues you may encounter.

   Frequently Asked Questions
   FAQ
   * Frequently Asked Questions

     * Is Salt open-core?

     * I think I found a bug! What should I do?

     * What ports should I open on my firewall?

     * I'm  seeing  weird  behavior (including but not limited to packages
       not installing their users properly)

     * My script runs every time I run a state.apply. Why?

     * When I run test.ping, why don't the Minions that aren't  responding
       return anything? Returning False would be helpful.

     * How does Salt determine the Minion's id?

     * I'm  trying  to  manage packages/services but I get an error saying
       that the state is not available. Why?

     * Why aren't my custom modules/states/etc. available on my Minions?

     * Module X isn't available, even though the shell command it uses  is
       installed. Why?

     * Can I run different versions of Salt on my Master and Minion?

     * Does Salt support backing up managed files?

     * Is it possible to deploy a file to a specific minion, without other
       minions having access to it?

     * What is the best way to restart a Salt daemon using Salt?

       * Linux/Unix

       * Windows

     * Salting the Salt Master

     * Is Targeting using Grain Data Secure?

     * Why Did the Value for a Grain Change on Its Own?

   Is Salt open-core?
   No. Salt is 100% committed to being open-source, including all  of  our
   APIs.  It  is developed under the Apache 2.0 license, allowing it to be
   used in both open and proprietary projects.

   To expand on this a little:

   There is much argument over the actual definition of "open core".  From
   our standpoint, Salt is open source because

   1. It is a standalone product that anyone is free to use.

   2. It  is  developed  in  the open with contributions accepted from the
      community for the good of the project.

   3. There are no features of Salt itself that are restricted to separate
      proprietary products distributed by SaltStack, Inc.

   4. Because  of  our  Apache  2.0  license,  Salt  can  be  used  as the
      foundation for a project or even a proprietary tool.

   5. Our APIs are open and documented (any lack of  documentation  is  an
      oversight  as  opposed  to  an intentional decision by SaltStack the
      company) and available for use by anyone.

   SaltStack the company does make proprietary products which use Salt and
   its  libraries,  like company is free to do, but we do so via the APIs,
   NOT by forking Salt and creating a different, closed-source version  of
   it for paying customers.

   I think I found a bug! What should I do?
   The salt-users mailing list as well as the salt IRC channel can both be
   helpful resources to confirm if others are  seeing  the  issue  and  to
   assist with immediate debugging.

   To  report a bug to the Salt project, please follow the instructions in
   reporting a bug.

   What ports should I open on my firewall?
   Minions need to be able to connect to the Master on TCP ports 4505  and
   4506.   Minions  do  not  need  any  inbound  ports open. More detailed
   information on firewall settings can be found here.

   I'm seeing weird behavior  (including  but  not  limited  to  packages  not
   installing their users properly)
   This  is  often caused by SELinux.  Try disabling SELinux or putting it
   in permissive mode and see if the weird behavior goes away.

   My script runs every time I run a state.apply. Why?
   You are probably using cmd.run rather than cmd.wait. A  cmd.wait  state
   will  only  run  when  there  has  been  a change in a state that it is
   watching.

   A cmd.run state will run the corresponding command every  time  (unless
   it is prevented from running by the unless or onlyif arguments).

   More details can be found in the documentation for the cmd states.

   When  I  run test.ping, why don't the Minions that aren't responding return
   anything? Returning False would be helpful.
   When  you   run   test.ping   the   Master   tells   Minions   to   run
   commands/functions, and listens for the return data, printing it to the
   screen when it is received.  If it doesn't receive  anything  back,  it
   doesn't have anything to display for that Minion.

   There  are a couple options for getting information on Minions that are
   not responding. One is to use the verbose (-v) option when you run salt
   commands,  as  it  will display "Minion did not return" for any Minions
   which time out.

      salt -v '*' pkg.install zsh

   Another option is to use the manage.down runner:

      salt-run manage.down

   Also, if the Master is under heavy load, it is possible  that  the  CLI
   will  exit  without  displaying  return  data for all targeted Minions.
   However, this doesn't mean that the Minions did not return;  this  only
   means  that the Salt CLI timed out waiting for a response. Minions will
   still send their return data back to the Master once the job completes.
   If   any  expected  Minions  are  missing  from  the  CLI  output,  the
   jobs.list_jobs runner can be used to show the job IDs of the jobs  that
   have  been  run,  and the jobs.lookup_jid runner can be used to get the
   return data for that job.

      salt-run jobs.list_jobs
      salt-run jobs.lookup_jid 20130916125524463507

   If you find that you are often missing Minion return data on  the  CLI,
   only to find it with the jobs runners, then this may be a sign that the
   worker_threads value may need to be  increased  in  the  master  config
   file.  Additionally,  running your Salt CLI commands with the -t option
   will make Salt wait longer for the return data before the  CLI  command
   exits.  For  instance, the below command will wait up to 60 seconds for
   the Minions to return:

      salt -t 60 '*' test.ping

   How does Salt determine the Minion's id?
   If the Minion id is not configured explicitly (using the id parameter),
   Salt  will  determine the id based on the hostname. Exactly how this is
   determined varies a little between operating systems and  is  described
   in detail here.

   I'm  trying  to manage packages/services but I get an error saying that the
   state is not available. Why?
   Salt detects the Minion's operating  system  and  assigns  the  correct
   package  or  service  management  module  based  on  what  is detected.
   However, for certain custom spins and  OS  derivatives  this  detection
   fails.  In  cases  like this, an issue should be opened on our tracker,
   with the following information:

   1. The output of the following command:

         salt <minion_id> grains.items | grep os

   2. The contents of /etc/lsb-release, if present on the Minion.

   Why aren't my custom modules/states/etc. available on my Minions?
   Custom modules are synced to  Minions  when  saltutil.sync_modules,  or
   saltutil.sync_all   is   run.    Custom  modules  are  also  synced  by
   state.apply when run without any arguments.

   Similarly, custom  states  are  synced  to  Minions  when  state.apply,
   saltutil.sync_states, or saltutil.sync_all is run.

   Custom  states  are  also  synced  by  state.apply when run without any
   arguments.

   Other custom types (renderers, outputters, etc.) have similar behavior,
   see the documentation for the saltutil module for more information.

   Module  X  isn't  available,  even  though  the  shell  command  it uses is
   installed. Why?
   This is most likely a PATH issue. Did you custom-compile  the  software
   which  the module requires? RHEL/CentOS/etc. in particular override the
   root   user's   path   in   /etc/init.d/functions,   setting   it    to
   /sbin:/usr/sbin:/bin:/usr/bin,    making    software   installed   into
   /usr/local/bin unavailable to Salt when the Minion is started using the
   initscript.  In  version 2014.1.0, Salt will have a better solution for
   these sort of PATH-related issues,  but  recompiling  the  software  to
   install  it into a location within the PATH should resolve the issue in
   the meantime. Alternatively, you can create a symbolic link within  the
   PATH using a file.symlink state.

      /usr/bin/foo:
        file.symlink:
          - target: /usr/local/bin/foo

   Can I run different versions of Salt on my Master and Minion?
   This  depends  on  the  versions.   In  general, it is recommended that
   Master and Minion versions match.

   When upgrading Salt, the master(s) should  always  be  upgraded  first.
   Backwards compatibility for minions running newer versions of salt than
   their masters is not guaranteed.

   Whenever possible, backwards compatibility between new masters and  old
   minions  will  be  preserved.   Generally,  the  only exception to this
   policy is in case of a security vulnerability.

   Recent examples of backwards compatibility breakage include the  0.17.1
   release (where all backwards compatibility was broken due to a security
   fix), and the 2014.1.0 release (which  retained  compatibility  between
   2014.1.0 masters and 0.17 minions, but broke compatibility for 2014.1.0
   minions and older masters).

   Does Salt support backing up managed files?
   Yes. Salt provides an easy to use addition to your file.managed  states
   that  allow  you  to  back up files via backup_mode, backup_mode can be
   configured on a per state basis, or in the minion config (note that  if
   set  in  the  minion  config this would simply be the default method to
   use, you still need to specify that the file should be backed up!).

   Is it possible to deploy a file to a specific minion, without other minions
   having access to it?
   The  Salt  fileserver  does  not  yet support access control, but it is
   still possible to do this. As of Salt 2015.5.0, the file_tree  external
   pillar  is available, and allows the contents of a file to be loaded as
   Pillar data. This external pillar is capable of assigning Pillar values
   both  to  individual  minions, and to nodegroups. See the documentation
   for details on how to set this up.

   Once the external pillar has been set up, the data can be pushed  to  a
   minion via a file.managed state, using the contents_pillar argument:

      /etc/my_super_secret_file:
        file.managed:
          - user: secret
          - group: secret
          - mode: 600
          - contents_pillar: secret_files:my_super_secret_file

   In this example, the source file would be located in a directory called
   secret_files underneath the file_tree path for the minion.  The  syntax
   for specifying the pillar variable is the same one used for pillar.get,
   with a colon representing a nested dictionary.

   WARNING:
      Deploying binary contents  using  the  file.managed  state  is  only
      supported in Salt 2015.8.4 and newer.

   What is the best way to restart a Salt daemon using Salt?
   Updating  the salt-minion package requires a restart of the salt-minion
   service.  But restarting the service while in the middle of a state run
   interrupts the process of the minion running states and sending results
   back to the master.  It's a tricky problem to solve, and we're  working
   on  it,  but  in  the  meantime  one way of handling this (on Linux and
   UNIX-based operating systems) is to  use  at  (a  job  scheduler  which
   predates  cron)  to  schedule  a  restart  of  the  service.  at is not
   installed by default on most distros, and  requires  a  service  to  be
   running  (usually  called  atd)  in  order to schedule jobs.  Here's an
   example of how to upgrade the salt-minion package at the end of a  Salt
   run,  and  schedule  a service restart for one minute after the package
   update completes.

   Linux/Unix
      salt-minion:
        pkg.installed:
          - name: salt-minion
          - version: 2014.1.7-3.el6
          - order: last
        service.running:
          - name: salt-minion
          - require:
            - pkg: salt-minion
        cmd.run:
          - name: echo service salt-minion restart | at now + 1 minute
          - onchanges:
            - pkg: salt-minion

   To ensure that at is installed and atd is running, the following states
   can  be used (be sure to double-check the package name and service name
   for the distro the minion is running, in  case  they  differ  from  the
   example below.

      at:
        pkg.installed:
          - name: at
        service.running:
          - name: atd
          - enable: True

   An  alternative  to  using  the  atd  daemon  is to fork and disown the
   process.

      restart_minion:
        cmd.run:
          - name: |
              exec 0>&- # close stdin
              exec 1>&- # close stdout
              exec 2>&- # close stderr
              nohup /bin/sh -c 'sleep 10 && salt-call --local service.restart salt-minion' &
          - python_shell: True
          - order: last

   Windows
   For Windows machines, restarting the minion can be  accomplished  using
   the following state:

      schedule-start:
        cmd.run:
          - name: 'start powershell "Restart-Service -Name salt-minion"'
          - order: last

   or running immediately from the command line:

      salt -G kernel:Windows cmd.run 'start powershell "Restart-Service -Name salt-minion"'

   Salting the Salt Master
   In  order  to configure a master server via states, the Salt master can
   also be "salted" in order to enforce state on the Salt master  as  well
   as  the Salt minions. Salting the Salt master requires a Salt minion to
   be installed on the same machine as the  Salt  master.  Once  the  Salt
   minion  is  installed, the minion configuration file must be pointed to
   the local Salt master:

      master: 127.0.0.1

   Once the Salt master has been "salted" with a Salt minion,  it  can  be
   targeted just like any other minion. If the minion on the salted master
   is running, the minion can be targeted  via  any  usual  salt  command.
   Additionally,  the  salt-call command can execute operations to enforce
   state on the salted master without requiring the minion to be running.

   More information about salting the Salt master  can  be  found  in  the
   salt-formula for salt itself:

   https://github.com/saltstack-formulas/salt-formula

   Is Targeting using Grain Data Secure?
   Because  grains  can  be  set  by  users that have access to the minion
   configuration files on the local system,  grains  are  considered  less
   secure  than  other  identifiers  in  Salt.  Use caution when targeting
   sensitive operations or setting pillar values based on grain data.

   When possible, you should target sensitive operations  and  data  using
   the  Minion ID. If the Minion ID of a system changes, the Salt Minion's
   public key must be re-accepted by an administrator on the Salt  Master,
   making it less vulnerable to impersonation attacks.

   Why Did the Value for a Grain Change on Its Own?
   This  is usually the result of an upstream change in an OS distribution
   that replaces or removes something that Salt was using  to  detect  the
   grain.   Fortunately, when this occurs, you can use Salt to fix it with
   a command similar to the following:

      salt -G 'grain:ChangedValue' grains.setvals "{'grain': 'OldValue'}"

   (Replacing grain, ChangedValue, and OldValue with the grain and  values
   that you want to change / set.)

   You  should also file an issue describing the change so it can be fixed
   in Salt.

   Salt Best Practices
   Salt's extreme flexibility  leads  to  many  questions  concerning  the
   structure of configuration files.

   This document exists to clarify these points through examples and code.

   General rules
   1. Modularity and clarity should be emphasized whenever possible.

   2. Create clear relations between pillars and states.

   3. Use variables when it makes sense but don't overuse them.

   4. Store sensitive data in pillar.

   5. Don't  use  grains  for  matching  in  your  pillar top file for any
      sensitive pillars.

   Structuring States and Formulas
   When structuring Salt States and Formulas it is important to begin with
   the  directory  structure. A proper directory structure clearly defines
   the functionality of each state to the user via  visual  inspection  of
   the state's name.

   Reviewing the MySQL Salt Formula it is clear to see the benefits to the
   end-user when reviewing a sample of the available states:

      /srv/salt/mysql/files/
      /srv/salt/mysql/client.sls
      /srv/salt/mysql/map.jinja
      /srv/salt/mysql/python.sls
      /srv/salt/mysql/server.sls

   This directory structure would lead to these states being referenced in
   a top file in the following way:

      base:
        'web*':
          - mysql.client
          - mysql.python
        'db*':
          - mysql.server

   This  clear  definition  ensures  that the user is properly informed of
   what each state will do.

   Another example comes from the vim-formula:

      /srv/salt/vim/files/
      /srv/salt/vim/absent.sls
      /srv/salt/vim/init.sls
      /srv/salt/vim/map.jinja
      /srv/salt/vim/nerdtree.sls
      /srv/salt/vim/pyflakes.sls
      /srv/salt/vim/salt.sls

   Once again viewing how this would look in a top file:

   /srv/salt/top.sls:

      base:
        'web*':
          - vim
          - vim.nerdtree
          - vim.pyflakes
          - vim.salt
        'db*':
          - vim.absent

   The usage of a clear top-level directory  as  well  as  properly  named
   states  reduces  the  overall  complexity  and  leads  a  user  to both
   understand what will be included at a glance and where it is located.

   In addition Formulas should be used as often as possible.

   NOTE:
      Formulas repositories on the saltstack-formulas GitHub  organization
      should  not  be  pointed to directly from systems that automatically
      fetch new updates such as GitFS or similar tooling. Instead formulas
      repositories  should  be  forked  on GitHub or cloned locally, where
      unintended, automatic changes will not take place.

   Structuring Pillar Files
   Pillars are used to  store  secure  and  insecure  data  pertaining  to
   minions. When designing the structure of the /srv/pillar directory, the
   pillars contained within should once again  be  focused  on  clear  and
   concise data which users can easily review, modify, and understand.

   The  /srv/pillar/  directory  is  primarily  controlled  by top.sls. It
   should be noted that the pillar top.sls is not used as  a  location  to
   declare  variables  and  their  values. The top.sls is used as a way to
   include other pillar files and organize the way they are matched  based
   on environments or grains.

   An example top.sls may be as simple as the following:

   /srv/pillar/top.sls:

      base:
        '*':
          - packages

   Any  number  of  matchers  can  be  added  to the base environment. For
   example, here is an expanded version of  the  Pillar  top  file  stated
   above:

   /srv/pillar/top.sls:

      base:
        '*':
          - packages
        'web*':
          - apache
          - vim

   Or  an  even  more  complicated example, using a variety of matchers in
   numerous environments:

   /srv/pillar/top.sls:

      base:
        '*':
          - apache
      dev:
        'os:Debian':
          - match: grain
          - vim
      test:
        '* and not G@os: Debian':
          - match: compound
          - emacs

   It is clear to see through these examples how  the  top  file  provides
   users  with  power  but  when used incorrectly it can lead to confusing
   configurations. This is why it is important to understand that the  top
   file for pillar is not used for variable definitions.

   Each  SLS  file  within the /srv/pillar/ directory should correspond to
   the states which it matches.

   This would mean  that  the  apache  pillar  file  should  contain  data
   relevant  to  Apache.  Structuring files in this way once again ensures
   modularity, and creates a consistent understanding throughout our  Salt
   environment.  Users can expect that pillar variables found in an Apache
   state will live inside of an Apache pillar:

   /srv/pillar/apache.sls:

      apache:
        lookup:
          name: httpd
          config:
            tmpl: /etc/httpd/httpd.conf

   While this pillar file is simple, it shows how a pillar file explicitly
   relates to the state it is associated with.

   Variable Flexibility
   Salt  allows  users  to  define variables in SLS files. When creating a
   state variables should  provide  users  with  as  much  flexibility  as
   possible.  This means that variables should be clearly defined and easy
   to manipulate, and that sane defaults  should  exist  in  the  event  a
   variable is not properly defined. Looking at several examples shows how
   these different items can lead to extensive flexibility.

   Although it is possible to set variables locally, this is generally not
   preferred:

   /srv/salt/apache/conf.sls:

      {% set name = 'httpd' %}
      {% set tmpl = 'salt://apache/files/httpd.conf' %}

      include:
        - apache

      apache_conf:
        file.managed:
          - name: {{ name }}
          - source: {{ tmpl }}
          - template: jinja
          - user: root
          - watch_in:
            - service: apache

   When  generating  this information it can be easily transitioned to the
   pillar where data can be overwritten, modified, and applied to multiple
   states, or locations within a single state:

   /srv/pillar/apache.sls:

      apache:
        lookup:
          name: httpd
          config:
            tmpl: salt://apache/files/httpd.conf

   /srv/salt/apache/conf.sls:

      {% from "apache/map.jinja" import apache with context %}

      include:
        - apache

      apache_conf:
        file.managed:
          - name: {{ salt['pillar.get']('apache:lookup:name') }}
          - source: {{ salt['pillar.get']('apache:lookup:config:tmpl') }}
          - template: jinja
          - user: root
          - watch_in:
            - service: apache

   This  flexibility  provides users with a centralized location to modify
   variables, which is extremely important as an environment grows.

   Modularity Within States
   Ensuring that states  are  modular  is  one  of  the  key  concepts  to
   understand  within Salt. When creating a state a user must consider how
   many times the state could  be  re-used,  and  what  it  relies  on  to
   operate.  Below are several examples which will iteratively explain how
   a user can go from a state which is not very modular to one that is:

   /srv/salt/apache/init.sls:

      httpd:
        pkg.installed: []
        service.running:
          - enable: True

      /etc/httpd/httpd.conf:
        file.managed:
          - source: salt://apache/files/httpd.conf
          - template: jinja
          - watch_in:
            - service: httpd

   The example above is probably the worst-case scenario  when  writing  a
   state.   There is a clear lack of focus by naming both the pkg/service,
   and managed file directly as the state ID. This would lead to  changing
   multiple  requires within this state, as well as others that may depend
   upon the state.

   Imagine if a require was used for the httpd package in  another  state,
   and then suddenly it's a custom package. Now changes need to be made in
   multiple locations which increases the complexity and leads to  a  more
   error prone configuration.

   There is also the issue of having the configuration file located in the
   init, as a user would be unable to simply install the service  and  use
   the default conf file.

   Our  second revision begins to address the referencing by using - name,
   as opposed to direct ID references:

   /srv/salt/apache/init.sls:

      apache:
        pkg.installed:
          - name: httpd
        service.running:
          - name: httpd
          - enable: True

      apache_conf:
        file.managed:
          - name: /etc/httpd/httpd.conf
          - source: salt://apache/files/httpd.conf
          - template: jinja
          - watch_in:
            - service: apache

   The above init file is better than our original,  yet  it  has  several
   issues  which lead to a lack of modularity. The first of these problems
   is the usage of static values  for  items  such  as  the  name  of  the
   service,  the  name  of the managed file, and the source of the managed
   file. When these items are hard coded they become difficult  to  modify
   and  the opportunity to make mistakes arises. It also leads to multiple
   edits that need to occur when changing these items  (imagine  if  there
   were  dozens of these occurrences throughout the state!). There is also
   still the concern of the configuration file data  living  in  the  same
   state as the service and package.

   In  the  next  example  steps  will  be taken to begin addressing these
   issues.  Starting with the addition of a map.jinja file  (as  noted  in
   the Formula documentation), and modification of static values:

   /srv/salt/apache/map.jinja:

      {% set apache = salt['grains.filter_by']({
          'Debian': {
              'server': 'apache2',
              'service': 'apache2',
              'conf': '/etc/apache2/apache.conf',
          },
          'RedHat': {
              'server': 'httpd',
              'service': 'httpd',
              'conf': '/etc/httpd/httpd.conf',
          },
      }, merge=salt['pillar.get']('apache:lookup')) %}

   /srv/pillar/apache.sls:

      apache:
        lookup:
          config:
            tmpl: salt://apache/files/httpd.conf

   /srv/salt/apache/init.sls:

      {% from "apache/map.jinja" import apache with context %}

      apache:
        pkg.installed:
          - name: {{ apache.server }}
        service.running:
          - name: {{ apache.service }}
          - enable: True

      apache_conf:
        file.managed:
          - name: {{ apache.conf }}
          - source: {{ salt['pillar.get']('apache:lookup:config:tmpl') }}
          - template: jinja
          - user: root
          - watch_in:
            - service: apache

   The  changes to this state now allow us to easily identify the location
   of the variables, as well as ensuring they are  flexible  and  easy  to
   modify.   While  this  takes another step in the right direction, it is
   not yet complete.  Suppose the user did not want to  use  the  provided
   conf file, or even their own configuration file, but the default apache
   conf. With the current state setup this is not possible. To attain this
   level of modularity this state will need to be broken into two states.

   /srv/salt/apache/map.jinja:

      {% set apache = salt['grains.filter_by']({
          'Debian': {
              'server': 'apache2',
              'service': 'apache2',
              'conf': '/etc/apache2/apache.conf',
          },
          'RedHat': {
              'server': 'httpd',
              'service': 'httpd',
              'conf': '/etc/httpd/httpd.conf',
          },
      }, merge=salt['pillar.get']('apache:lookup')) %}

   /srv/pillar/apache.sls:

      apache:
        lookup:
          config:
            tmpl: salt://apache/files/httpd.conf

   /srv/salt/apache/init.sls:

      {% from "apache/map.jinja" import apache with context %}

      apache:
        pkg.installed:
          - name: {{ apache.server }}
        service.running:
          - name: {{ apache.service }}
          - enable: True

   /srv/salt/apache/conf.sls:

      {% from "apache/map.jinja" import apache with context %}

      include:
        - apache

      apache_conf:
        file.managed:
          - name: {{ apache.conf }}
          - source: {{ salt['pillar.get']('apache:lookup:config:tmpl') }}
          - template: jinja
          - user: root
          - watch_in:
            - service: apache

   This new structure now allows users to choose whether they only wish to
   install the default Apache, or if  they  wish,  overwrite  the  default
   package,  service,  configuration  file  location, or the configuration
   file itself. In addition to this  the  data  has  been  broken  between
   multiple files allowing for users to identify where they need to change
   the associated data.

   Storing Secure Data
   Secure data refers to any information that you would not wish to  share
   with  anyone  accessing  a  server.  This  could  include  data such as
   passwords, keys, or other information.

   As all data within a state  is  accessible  by  EVERY  server  that  is
   connected it is important to store secure data within pillar. This will
   ensure that only those servers which  require  this  secure  data  have
   access  to  it.  In  this  example  a  use  can  go  from  an  insecure
   configuration to one which is only accessible by the appropriate hosts:

   /srv/salt/mysql/testerdb.sls:

      testdb:
        mysql_database.present:
          - name: testerdb

   /srv/salt/mysql/user.sls:

      include:
        - mysql.testerdb

      testdb_user:
        mysql_user.present:
          - name: frank
          - password: "test3rdb"
          - host: localhost
          - require:
            - sls: mysql.testerdb

   Many users would review this state and see that the password  is  there
   in plain text, which is quite problematic. It results in several issues
   which may not be immediately visible.

   The first of these issues is clear to most users -- the password  being
   visible  in this state. This  means that any minion will have a copy of
   this, and therefore the password which is a major security  concern  as
   minions may not be locked down as tightly as the master server.

   The  other  issue  that  can  be  encountered is access by users on the
   master. If everyone has access to the  states  (or  their  repository),
   then  they are able to review this password. Keeping your password data
   accessible by only a few users is critical for both security and  peace
   of mind.

   There is also the issue of portability. When a state is configured this
   way it results in  multiple  changes  needing  to  be  made.  This  was
   discussed  in  the  sections  above  but it is a critical idea to drive
   home. If states are not portable it may result in more work later!

   Fixing this issue is relatively simple, the content just  needs  to  be
   moved to the associated pillar:

   /srv/pillar/mysql.sls:

      mysql:
        lookup:
          name: testerdb
          password: test3rdb
          user: frank
          host: localhost

   /srv/salt/mysql/testerdb.sls:

      testdb:
        mysql_database.present:
          - name: {{ salt['pillar.get']('mysql:lookup:name') }}

   /srv/salt/mysql/user.sls:

      include:
        - mysql.testerdb

      testdb_user:
        mysql_user.present:
          - name: {{ salt['pillar.get']('mysql:lookup:user') }}
          - password: {{ salt['pillar.get']('mysql:lookup:password') }}
          - host: {{ salt['pillar.get']('mysql:lookup:host') }}
          - require:
            - sls: mysql.testerdb

   Now  that the database details have been moved to the associated pillar
   file, only machines which are targeted via pillar will have  access  to
   these  details.  Access to users who should not be able to review these
   details can also be prevented while ensuring that they are  still  able
   to write states which take advantage of this information.

REMOTE EXECUTION

   Running  pre-defined  or arbitrary commands on remote hosts, also known
   as remote execution, is the core function of Salt. The following  links
   explore  modules  and  returners,  which are two key elements of remote
   execution.

   Salt Execution Modules

   Salt execution modules are called by the  remote  execution  system  to
   perform  a  wide  variety of tasks. These modules provide functionality
   such as installing packages, restarting a  service,  running  a  remote
   command, transferring files, and so on.

      Full list of execution modules
             Contains: a list of core modules that ship with Salt.

      Writing execution modules
             Contains: a guide on how to write Salt modules.

   Remote execution tutorial
   Before  continuing  make  sure  you have a working Salt installation by
   following the installation and the configuration instructions.

      Stuck?

             There are many ways to  get  help  from  the  Salt  community
             including our mailing list and our IRC channel #salt.

   Order your minions around
   Now  that  you have a master and at least one minion communicating with
   each other you can perform commands on the minion via the salt command.
   Salt calls are comprised of three main components:

      salt '<target>' <function> [arguments]

   SEE ALSO:
      salt manpage

   target
   The  target component allows you to filter which minions should run the
   following function. The default filter is a glob on the minion id.  For
   example:

      salt '*' test.ping
      salt '*.example.org' test.ping

   Targets  can  be  based  on  minion system information using the Grains
   system:

      salt -G 'os:Ubuntu' test.ping

   SEE ALSO:
      Grains system

   Targets can be filtered by regular expression:

      salt -E 'virtmach[0-9]' test.ping

   Targets can be explicitly specified in a list:

      salt -L 'foo,bar,baz,quo' test.ping

   Or Multiple target types can be combined in one command:

      salt -C 'G@os:Ubuntu and webser* or E@database.*' test.ping

   function
   A function is some functionality provided by a module. Salt ships  with
   a large collection of available functions. List all available functions
   on your minions:

      salt '*' sys.doc

   Here are some examples:

   Show all currently available minions:

      salt '*' test.ping

   Run an arbitrary shell command:

      salt '*' cmd.run 'uname -a'

   SEE ALSO:
      the full list of modules

   arguments
   Space-delimited arguments to the function:

      salt '*' cmd.exec_code python 'import sys; print sys.version'

   Optional, keyword arguments are also supported:

      salt '*' pip.install salt timeout=5 upgrade=True

   They are always in the form of kwarg=argument.

   Running Commands on Salt Minions
   Salt can be controlled by a command line client by the root user on the
   Salt  master.  The Salt command line client uses the Salt client API to
   communicate  with  the  Salt  master  server.  The   Salt   client   is
   straightforward and simple to use.

   Using the Salt client commands can be easily sent to the minions.

   Each  of these commands accepts an explicit --config option to point to
   either the master or minion configuration file.  If this option is  not
   provided  and  the  default configuration file does not exist then Salt
   falls back to use  the  environment  variables  SALT_MASTER_CONFIG  and
   SALT_MINION_CONFIG.

   SEE ALSO:
      Configuration

   Using the Salt Command
   The Salt command needs a few components to send information to the Salt
   minions. The target minions need to be defined, the  function  to  call
   and any arguments the function requires.

   Defining the Target Minions
   The  first  argument  passed  to  salt, defines the target minions, the
   target minions are accessed via their hostname. The default target type
   is a bash glob:

      salt '*foo.com' sys.doc

   Salt can also define the target minions with regular expressions:

      salt -E '.*' cmd.run 'ls -l | grep foo'

   Or to explicitly list hosts, salt can take a list:

      salt -L foo.bar.baz,quo.qux cmd.run 'ps aux | grep foo'

   More Powerful Targets
   See Targeting.

   Calling the Function
   The function to call on the specified target is placed after the target
   specification.

   New in version 0.9.8.

   Functions may also accept arguments, space-delimited:

      salt '*' cmd.exec_code python 'import sys; print sys.version'

   Optional, keyword arguments are also supported:

      salt '*' pip.install salt timeout=5 upgrade=True

   They are always in the form of kwarg=argument.

   Arguments are formatted as YAML:

      salt '*' cmd.run 'echo "Hello: $FIRST_NAME"' saltenv='{FIRST_NAME: "Joe"}'

   Note: dictionaries must have curly braces around them (like the saltenv
   keyword  argument  above).   This  was  changed in 0.15.1: in the above
   example, the first argument used to be parsed as the dictionary  {'echo
   "Hello': '$FIRST_NAME"'}. This was generally not the expected behavior.

   If  you  want  to test what parameters are actually passed to a module,
   use the test.arg_repr command:

      salt '*' test.arg_repr 'echo "Hello: $FIRST_NAME"' saltenv='{FIRST_NAME: "Joe"}'

   Finding available minion functions
   The  Salt  functions  are  self  documenting,  all  of   the   function
   documentation  can  be  retried  from  the  minions  via  the sys.doc()
   function:

      salt '*' sys.doc

   Compound Command Execution
   If  a  series  of  commands  needs  to  be  sent  to  a  single  target
   specification  then  the commands can be sent in a single publish. This
   can make gathering groups of information faster, and lowers the  stress
   on the network for repeated commands.

   Compound  command  execution  works  by sending a list of functions and
   arguments instead of  sending  a  single  function  and  argument.  The
   functions  are  executed on the minion in the order they are defined on
   the command line, and then the  data  from  all  of  the  commands  are
   returned  in  a  dictionary.  This  means  that the set of commands are
   called in a predictable way,  and  the  returned  data  can  be  easily
   interpreted.

   Executing  compound  commands if done by passing a comma delimited list
   of functions, followed by a comma delimited list of arguments:

      salt '*' cmd.run,test.ping,test.echo 'cat /proc/cpuinfo',,foo

   The trick to look out for here, is that if a function is  being  passed
   no  arguments,  then  there  needs  to  be a placeholder for the absent
   arguments. This is why in the above example, there are two commas right
   next  to  each  other.  test.ping takes no arguments, so we need to add
   another comma, otherwise Salt would attempt to pass "foo" to test.ping.

   If you need to pass arguments that include commas, then make  sure  you
   add spaces around the commas that separate arguments. For example:

      salt '*' cmd.run,test.ping,test.echo 'echo "1,2,3"' , , foo

   You  may  change  the  arguments  separator  using the --args-separator
   option:

      salt --args-separator=:: '*' some.fun,test.echo params with , comma :: foo

   CLI Completion
   Shell completion scripts for the Salt CLI are available in the pkg Salt
   source directory.

   Writing Execution Modules
   Salt execution modules are the functions called by the salt command.

   Modules Are Easy to Write!
   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.    roots
   <salt.fileserver.roots), unless environments are otherwise  defined  in
   the  file_roots config option, the _modules/ directory would be located
   in /srv/salt/_modules on most systems.

   Modules placed in _modules/ will be synced to the minions when  any  of
   the following Salt functions are called:

   * state.apply

   * saltutil.sync_modules

   * saltutil.sync_all

   Note  that a module's default name is its filename (i.e. foo.py becomes
   module foo), but that its name can be overridden by using a __virtual__
   function.

   If  a  Salt  module  has errors and cannot be imported, the Salt minion
   will continue to load without issue and the  module  with  errors  will
   simply be omitted.

   If  adding  a  Cython module the file must be named <modulename>.pyx so
   that the loader knows that the module needs to be imported as a  Cython
   module.  The  compilation of the Cython module is automatic and happens
   when the minion starts, so only the *.pyx file is required.

   Zip Archives as Modules
   Python 2.3 and higher allows developers to directly import zip archives
   containing  Python  code.  By setting enable_zip_modules to True in the
   minion config, the Salt loader will be able to  import  .zip  files  in
   this   fashion.   This   allows   Salt  module  developers  to  package
   dependencies with their modules for ease of deployment, isolation, etc.

   For a user, Zip Archive modules behave just like other  modules.   When
   executing  a function from a module provided as the file my_module.zip,
   a   user   would   call   a   function   within    that    module    as
   my_module.<function>.

   Creating a Zip Archive Module
   A  Zip  Archive  module  is  structured  similarly  to  a simple Python
   package.  The .zip file contains a single directory with the same  name
   as  the module.  The module code traditionally in <module_name>.py goes
   in   <module_name>/__init__.py.    The    dependency    packages    are
   subdirectories of <module_name>/.

   Here is an example directory structure for the lumberjack module, which
   has two library dependencies (sleep and work) to be included.

      modules $ ls -R lumberjack
      __init__.py     sleep           work

      lumberjack/sleep:
      __init__.py

      lumberjack/work:
      __init__.py

   The contents of lumberjack/__init__.py show how to import and use these
   included libraries.

      # Libraries included in lumberjack.zip
      from lumberjack import sleep, work

      def is_ok(person):
          ''' Checks whether a person is really a lumberjack '''
          return sleep.all_night(person) and work.all_day(person)

   Then, create the zip:

      modules $ zip -r lumberjack lumberjack
        adding: lumberjack/ (stored 0%)
        adding: lumberjack/__init__.py (deflated 39%)
        adding: lumberjack/sleep/ (stored 0%)
        adding: lumberjack/sleep/__init__.py (deflated 7%)
        adding: lumberjack/work/ (stored 0%)
        adding: lumberjack/work/__init__.py (deflated 7%)
      modules $ unzip -l lumberjack.zip
      Archive:  lumberjack.zip
        Length     Date   Time    Name
       --------    ----   ----    ----
              0  08-21-15 20:08   lumberjack/
            348  08-21-15 20:08   lumberjack/__init__.py
              0  08-21-15 19:53   lumberjack/sleep/
             83  08-21-15 19:53   lumberjack/sleep/__init__.py
              0  08-21-15 19:53   lumberjack/work/
             81  08-21-15 19:21   lumberjack/work/__init__.py
       --------                   -------
            512                   6 files

   Once   placed   in  file_roots,  Salt  users  can  distribute  and  use
   lumberjack.zip like any other module.

      $ sudo salt minion1 saltutil.sync_modules
      minion1:
        - modules.lumberjack
      $ sudo salt minion1 lumberjack.is_ok 'Michael Palin'
      minion1:
        True

   Cross Calling Execution Modules
   All of the Salt execution modules  are  available  to  each  other  and
   modules can call functions available in other execution modules.

   The  variable __salt__ is packed into the modules after they are loaded
   into the Salt minion.

   The __salt__ variable is a Python dictionary containing all of the Salt
   functions.  Dictionary  keys  are strings representing the names of the
   modules and the values are the functions themselves.

   Salt modules can be cross-called by accessing the value in the __salt__
   dict:

      def foo(bar):
          return __salt__['cmd.run'](bar)

   This  code  will  call  the run function in the cmd module and pass the
   argument bar to it.

   Calling Execution Modules on the Salt Master
   New in version 2016.11.0.

   Execution modules can now also be called via the salt-run command using
   the salt runner.

   Preloaded Execution Module Data
   When  interacting with execution modules often it is nice to be able to
   read  information  dynamically  about  the  minion  or   to   load   in
   configuration parameters for a module.

   Salt  allows  for different types of data to be loaded into the modules
   by the minion.

   Grains Data
   The values detected by the Salt Grains on the minion are available in a
   dict  named __grains__ and can be accessed from within callable objects
   in the Python modules.

   To see the contents of the grains dictionary for a given system in your
   deployment run the grains.items() function:

      salt 'hostname' grains.items --output=pprint

   Any  value  in  a grains dictionary can be accessed as any other Python
   dictionary. For example, the grain representing the minion ID is stored
   in  the  id key and from an execution module, the value would be stored
   in __grains__['id'].

   Module Configuration
   Since parameters for configuring a module may be desired,  Salt  allows
   for configuration information from the  minion configuration file to be
   passed to execution modules.

   Since the minion configuration  file  is  a  YAML  document,  arbitrary
   configuration  data  can be passed in the minion config that is read by
   the modules. It is  therefore  strongly  recommended  that  the  values
   passed  in  the  configuration  file  match  the  module  name. A value
   intended for the test execution module should be named test.<value>.

   The test execution module contains usage of  the  module  configuration
   and  the  default  configuration  file  for  the  minion  contains  the
   information  and  format  used   to   pass   data   to   the   modules.
   salt.modules.test, conf/minion.

   Strings and Unicode
   An  execution   module  author should always assume that strings fed to
   the module have already decoded from strings into Unicode. In Python 2,
   these  will  be  of type 'Unicode' and in Python 3 they will be of type
   str. Calling from a  state  to  other  Salt  sub-systems,  should  pass
   Unicode  (or  bytes  if  passing binary data). In the rare event that a
   state needs to write directly to disk, Unicode should be encoded  to  a
   string   immediately   before  writing  to  disk.  An  author  may  use
   __salt_system_encoding__ to learn what the encoding type of the  system
   is.  For example, 'my_string'.encode(__salt_system_encoding__').

   Outputter Configuration
   Since execution module functions can return different data, and the way
   the data is printed can greatly change the  presentation,  Salt  allows
   for a specific outputter to be set on a function-by-function basis.

   This  is  done  be  declaring an __outputter__ dictionary in the global
   scope of the module.  The __outputter__ dictionary contains  a  mapping
   of function names to Salt outputters.

      __outputter__ = {
          'run': 'txt'
      }

   This  will ensure that the txt outputter is used to display output from
   the run function.

   Virtual Modules
   Virtual modules let you override the name of a module in order  to  use
   the  same name to refer to one of several similar modules. The specific
   module that is loaded for a virtual  name  is  selected  based  on  the
   current platform or environment.

   For  example,  packages  are  managed  across  platforms  using the pkg
   module.  pkg is a virtual module name that is an alias for the specific
   package  manager  module  that  is  loaded  on  a  specific system (for
   example, yumpkg on RHEL/CentOS systems , and aptpkg on Ubuntu).

   Virtual module names are set using the  __virtual__  function  and  the
   virtual name.

   __virtual__ Function
   The __virtual__ function returns either a string, True, False, or False
   with an error string. If a string is returned then the module is loaded
   using  the  name of the string as the virtual name. If True is returned
   the module is loaded  using  the  current  module  name.  If  False  is
   returned the 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.

   NOTE:
      Modules which return a string from __virtual__ that is already  used
      by a module that ships with Salt will _override_ the stock module.

   Returning Error Information from __virtual__
   Optionally,  Salt  plugin  modules, such as execution, state, returner,
   beacon, etc. modules may additionally return a  string  containing  the
   reason  that  a  module could not be loaded.  For example, an execution
   module called cheese and  a  corresponding  state  module  also  called
   cheese,  both  depending  on  a  utility  called  enzymes  should  have
   __virtual__ functions that handle  the  case  when  the  dependency  is
   unavailable.

      '''
      Cheese execution (or returner/beacon/etc.) module
      '''
      try:
          import enzymes
          HAS_ENZYMES = True
      except ImportError:
          HAS_ENZYMES = False

      def __virtual__():
          '''
          only load cheese if enzymes are available
          '''
          if HAS_ENZYMES:
              return 'cheese'
          else:
              return False, 'The cheese execution module cannot be loaded: enzymes unavailable.'

      '''
      Cheese state module
      '''

      def __virtual__():
          '''
          only load cheese if enzymes are available
          '''
          # predicate loading of the cheese state on the corresponding execution module
          if 'cheese.slice' in __salt__:
              return 'cheese'
          else:
              return False, 'The cheese state module cannot be loaded: enzymes unavailable.'

   Examples
   The  package  manager  modules are among the best examples of using the
   __virtual__ function. A table of all the virtual  pkg  modules  can  be
   found here.

   Overriding Virtual Module Providers
   Salt often uses OS grains (os, osrelease, os_family, etc.) to determine
   which module should be loaded as the virtual module for  pkg,  service,
   etc.  Sometimes  this  OS  detection  is  incomplete,  with new distros
   popping up, existing distros changing init systems,  etc.  The  virtual
   modules likely to be affected by this are in the list below (click each
   item for more information):

   * pkg

   * service

   * user

   * shadow

   * group

   If Salt is using the wrong module for  one  of  these,  first  of  all,
   please  report  it  on  the  issue  tracker,  so that this issue can be
   resolved for a future release.  To  make  it  easier  to  troubleshoot,
   please  also provide the grains.items output, taking care to redact any
   sensitive information.

   Then, while waiting for the  SaltStack  development  team  to  fix  the
   issue,  Salt  can be made to use the correct module using the providers
   option in the minion config file:

      providers:
        service: systemd
        pkg: aptpkg

   The above example will force the minion to use the  systemd  module  to
   provide  service  management,  and the aptpkg module to provide package
   management.

   __virtualname__
   __virtualname__ is a variable that is used by the  documentation  build
   system  to  know  the  virtual  name  of  a  module without calling the
   __virtual__ function. Modules that return a string from the __virtual__
   function must also set the __virtualname__ variable.

   To  avoid  setting  the  virtual  name  string twice, you can implement
   __virtual__ to return the value set for __virtualname__ using a pattern
   similar to the following:

      # Define the module's virtual name
      __virtualname__ = 'pkg'

      def __virtual__():
          '''
          Confine this module to Mac OS with Homebrew.
          '''

          if salt.utils.which('brew') and __grains__['os'] == 'MacOS':
              return __virtualname__
          return False

   Documentation
   Salt  execution  modules  are  documented.  The sys.doc() function will
   return the documentation for all available modules:

      salt '*' sys.doc

   The sys.doc function simply prints out  the  docstrings  found  in  the
   modules;  when  writing  Salt  execution  modules,  please  follow  the
   formatting conventions for docstrings  as  they  appear  in  the  other
   modules.

   Adding Documentation to Salt Modules
   It  is  strongly  suggested  that  all  Salt modules have documentation
   added.

   To add documentation add a Python docstring to the function.

      def spam(eggs):
          '''
          A function to make some spam with eggs!

          CLI Example::

              salt '*' test.spam eggs
          '''
          return eggs

   Now when the sys.doc call is executed the  docstring  will  be  cleanly
   returned to the calling terminal.

   Documentation   added   to   execution   modules   in  docstrings  will
   automatically be added to the online web-based documentation.

   Add Execution Module Metadata
   When  writing  a  Python  docstring  for  an  execution   module,   add
   information about the module using the following field lists:

      :maintainer:    Thomas Hatch <[email protected], Seth House <[email protected]>
      :maturity:      new
      :depends:       python-mysqldb
      :platform:      all

   The  maintainer  field is a comma-delimited list of developers who help
   maintain this module.

   The maturity field indicates the level of quality and testing for  this
   module.  Standard labels will be determined.

   The depends field is a comma-delimited list of modules that this module
   depends on.

   The platform field is a comma-delimited list  of  platforms  that  this
   module is known to run on.

   Log Output
   You  can  call  the logger from custom modules to write messages to the
   minion logs.  The  following  code  snippet  demonstrates  writing  log
   messages:

      import logging

      log = logging.getLogger(__name__)

      log.info('Here is Some Information')
      log.warning('You Should Not Do That')
      log.error('It Is Busted')

   Aliasing Functions
   Sometimes  one wishes to use a function name that would shadow a python
   built-in.  A common example would be set(). To support this, append  an
   underscore  to  the  function  definition,  def  set_():,  and  use the
   __func_alias__ feature to provide an alias to the function.

   __func_alias__ is a dictionary where each key is the name of a function
   in  the  module,  and each value is a string representing the alias for
   that function.  When calling  an  aliased  function  from  a  different
   execution  module, state module, or from the cli, the alias name should
   be used.

      __func_alias__ = {
          'set_': 'set',
          'list_': 'list',
      }

   Private Functions
   In Salt, Python callable objects contained within an  execution  module
   are  made  available  to the Salt minion for use. The only exception to
   this rule is a callable object with a name starting with an  underscore
   _.

   Objects Loaded Into the Salt Minion
      def foo(bar):
          return bar

   Objects NOT Loaded into the Salt Minion
      def _foobar(baz): # Preceded with an _
          return baz

      cheese = {} # Not a callable Python object

   Useful Decorators for Modules
   Depends Decorator
   When  writing  execution modules there are many times where some of the
   module will work on all hosts  but  some  functions  have  an  external
   dependency,  such  as  a service that needs to be installed or a binary
   that needs to be present on the system.

   Instead of trying to wrap much of the code in large try/except  blocks,
   a decorator can be used.

   If  the dependencies passed to the decorator don't exist, then the salt
   minion will remove those functions from the module on that host.

   If a fallback_function is defined, it will replace the function instead
   of removing it

      import logging

      from salt.utils.decorators import depends

      log = logging.getLogger(__name__)

      try:
          import dependency_that_sometimes_exists
      except ImportError as e:
          log.trace('Failed to import dependency_that_sometimes_exists: {0}'.format(e))

      @depends('dependency_that_sometimes_exists')
      def foo():
          '''
          Function with a dependency on the "dependency_that_sometimes_exists" module,
          if the "dependency_that_sometimes_exists" is missing this function will not exist
          '''
          return True

      def _fallback():
          '''
          Fallback function for the depends decorator to replace a function with
          '''
          return '"dependency_that_sometimes_exists" needs to be installed for this function to exist'

      @depends('dependency_that_sometimes_exists', fallback_function=_fallback)
      def foo():
          '''
          Function with a dependency on the "dependency_that_sometimes_exists" module.
          If the "dependency_that_sometimes_exists" is missing this function will be
          replaced with "_fallback"
          '''
          return True

   In  addition to global dependencies the depends decorator also supports
   raw booleans.

      from salt.utils.decorators import depends

      HAS_DEP = False
      try:
          import dependency_that_sometimes_exists
          HAS_DEP = True
      except ImportError:
          pass

      @depends(HAS_DEP)
      def foo():
          return True

CONFIGURATION MANAGEMENT

   Salt contains a robust and flexible configuration management framework,
   which is built on the remote execution core. This framework executes on
   the minions, allowing effortless, simultaneous configuration of tens of
   thousands  of  hosts,  by  rendering language specific state files. The
   following links  provide  resources  to  learn  more  about  state  and
   renderers.

   States Express  the  state of a host using small, easy to read, easy to
          understand configuration files. No programming required.

          Full list of states
                 Contains:  list  of  install  packages,   create   users,
                 transfer files, start services, and so on.

          Pillar System
                 Contains: description of Salt's Pillar system.

          Highstate data structure
                 Contains:  a  dry vocabulary and technical representation
                 of the configuration format that states represent.

          Writing states
                 Contains: a guide on how to  write  Salt  state  modules,
                 easily extending Salt to directly manage more software.

   NOTE:
      Salt  execution  modules are different from state modules and cannot
      be called as a state in an SLS file. In other words, this  will  not
      work:

          moe:
            user.rename:
              - new_name: larry
              - onlyif: id moe

      You  must  use the module states to call execution modules directly.
      Here's an example:

          rename_moe:
            module.run:
              - m_name: moe
              - new_name: larry
              - onlyif: id moe

   Renderers
          Renderers use state configuration files written in a variety  of
          languages,  templating  engines,  or files. Salt's configuration
          management system is, under the hood, language agnostic.

          Full list of renderers
                 Contains: a list of renderers.  YAML is one  choice,  but
                 many  systems  are available, from alternative templating
                 engines to the PyDSL language for rendering sls formulas.

          Renderers
                 Contains: more information about renderers.  Salt  states
                 are  only  concerned  with  the  ultimate  highstate data
                 structure, not how the data structure was created.

   How Do I Use Salt States?
   Simplicity, Simplicity, Simplicity

   Many of the most powerful and useful engineering solutions are  founded
   on  simple  principles.  Salt  States  strive to do just that: K.I.S.S.
   (Keep It Stupidly Simple)

   The core of the Salt State system is the SLS, or SaLt State  file.  The
   SLS  is  a  representation of the state in which a system should be in,
   and is set up to contain this data in a simple format.  This  is  often
   called configuration management.

   NOTE:
      This  is just the beginning of using states, make sure to read up on
      pillar Pillar next.

   It is All Just Data
   Before delving into the particulars, it will help  to  understand  that
   the   SLS  file  is  just  a  data  structure  under  the  hood.  While
   understanding that the SLS is just a data structure isn't critical  for
   understanding  and  making  use  of Salt States, it should help bolster
   knowledge of where the real power is.

   SLS files are therefore, in reality, just dictionaries, lists, strings,
   and numbers.  By using this approach Salt can be much more flexible. As
   one writes more state files, it becomes clearer exactly what  is  being
   written.  The  result is a system that is easy to understand, yet grows
   with the needs of the admin or developer.

   The Top File
   The example SLS files in the below sections can be  assigned  to  hosts
   using a file called top.sls. This file is described in-depth here.

   Default Data - YAML
   By  default Salt represents the SLS data in what is one of the simplest
   serialization formats available - YAML.

   A typical SLS file will often look like this in YAML:

   NOTE:
      These demos use some generic service and  package  names,  different
      distributions  often  use different names for packages and services.
      For instance apache should be replaced  with  httpd  on  a  Red  Hat
      system.   Salt  uses  the  name  of  the  init script, systemd name,
      upstart name etc.  based on what the underlying  service  management
      for  the platform. To get a list of the available service names on a
      platform execute the service.get_all salt function.

      Information on how to make states work with  multiple  distributions
      is later in the tutorial.

      apache:
        pkg.installed: []
        service.running:
          - require:
            - pkg: apache

   This  SLS  data will ensure that the package named apache is installed,
   and that the apache service is running. The components can be explained
   in a simple way.

   The  first  line  is  the ID for a set of data, and it is called the ID
   Declaration. This ID sets the name  of  the  thing  that  needs  to  be
   manipulated.

   The second and third lines contain the state module function to be run,
   in the format <state_module>.<function>. The pkg.installed state module
   function  ensures that a software package is installed via the system's
   native package  manager.  The  service.running  state  module  function
   ensures that a given system daemon is running.

   Finally,  on line five, is the word require. This is called a Requisite
   Statement, and it makes sure that the Apache service  is  only  started
   after a successful installation of the apache package.

   Adding Configs and Users
   When  setting  up  a  service  like  an  Apache  web  server, many more
   components may need to be added. The  Apache  configuration  file  will
   most likely be managed, and a user and group may need to be set up.

      apache:
        pkg.installed: []
        service.running:
          - watch:
            - pkg: apache
            - file: /etc/httpd/conf/httpd.conf
            - user: apache
        user.present:
          - uid: 87
          - gid: 87
          - home: /var/www/html
          - shell: /bin/nologin
          - require:
            - group: apache
        group.present:
          - gid: 87
          - require:
            - pkg: apache

      /etc/httpd/conf/httpd.conf:
        file.managed:
          - source: salt://apache/httpd.conf
          - user: root
          - group: root
          - mode: 644

   This  SLS data greatly extends the first example, and includes a config
   file, a user, a group and new requisite statement: watch.

   Adding more states is easy, since the new user  and  group  states  are
   under  the  Apache  ID,  the user and group will be the Apache user and
   group. The require statements will make sure that the user will only be
   made  after  the  group, and that the group will be made only after the
   Apache package is installed.

   Next, the require statement under service was changed to watch, and  is
   now watching 3 states instead of just one. The watch statement does the
   same thing as require, making sure that the  other  states  run  before
   running  the  state  with  a watch, but it adds an extra component. The
   watch statement will run the state's watcher function for  any  changes
   to  the watched states.  So if the package was updated, the config file
   changed, or the user uid modified, then  the  service  state's  watcher
   will  be run. The service state's watcher just restarts the service, so
   in this case, a change in the config file will also trigger  a  restart
   of the respective service.

   Moving Beyond a Single SLS
   When  setting  up  Salt  States in a scalable manner, more than one SLS
   will need to be used. The above examples were in a single SLS file, but
   two  or  more  SLS files can be combined to build out a State Tree. The
   above  example  also  references  a  file  with  a  strange  source   -
   salt://apache/httpd.conf. That file will need to be available as well.

   The SLS files are laid out in a directory structure on the Salt master;
   an SLS is just a file and files to download are just files.

   The Apache example would be laid out in  the  root  of  the  Salt  file
   server like this:

      apache/init.sls
      apache/httpd.conf

   So  the  httpd.conf  is  just  a  file  in the apache directory, and is
   referenced directly.

      Do not use dots in SLS file names or their directories

             The initial implementation of top.sls and include-declaration
             followed the python import model where a slash is represented
             as a period.  This means that a SLS file with a period in the
             name ( besides the suffix period) can not be referenced.  For
             example,  webserver_1.0.sls  is  not  referenceable   because
             webserver_1.0    would    refer    to    the   directory/file
             webserver_1/0.sls

             The same applies for any subdirectories, this  is  especially
             'tricky'  when  git  repos are created.  Another command that
             typically can't render it's output is `state.show_sls`  of  a
             file in a path that contains a dot.

   But  when  using  more than one single SLS file, more components can be
   added to the toolkit. Consider this SSH example:

   ssh/init.sls:

      openssh-client:
        pkg.installed

      /etc/ssh/ssh_config:
        file.managed:
          - user: root
          - group: root
          - mode: 644
          - source: salt://ssh/ssh_config
          - require:
            - pkg: openssh-client

   ssh/server.sls:

      include:
        - ssh

      openssh-server:
        pkg.installed

      sshd:
        service.running:
          - require:
            - pkg: openssh-client
            - pkg: openssh-server
            - file: /etc/ssh/banner
            - file: /etc/ssh/sshd_config

      /etc/ssh/sshd_config:
        file.managed:
          - user: root
          - group: root
          - mode: 644
          - source: salt://ssh/sshd_config
          - require:
            - pkg: openssh-server

      /etc/ssh/banner:
        file:
          - managed
          - user: root
          - group: root
          - mode: 644
          - source: salt://ssh/banner
          - require:
            - pkg: openssh-server

   NOTE:
      Notice that we use two similar ways  of  denoting  that  a  file  is
      managed by Salt. In the /etc/ssh/sshd_config state section above, we
      use  the   file.managed   state   declaration   whereas   with   the
      /etc/ssh/banner state section, we use the file state declaration and
      add a managed attribute to that state declaration. Both ways produce
      an  identical  result;  the  first  way  -- using file.managed -- is
      merely a shortcut.

   Now our State Tree looks like this:

      apache/init.sls
      apache/httpd.conf
      ssh/init.sls
      ssh/server.sls
      ssh/banner
      ssh/ssh_config
      ssh/sshd_config

   This  example  now  introduces  the  include  statement.  The   include
   statement  includes another SLS file so that components found in it can
   be required, watched or as will soon be demonstrated - extended.

   The include statement allows for states to be cross linked. When an SLS
   has  an  include  statement  it  is  literally  extended to include the
   contents of the included SLS files.

   Note that some of the SLS files are called init.sls, while  others  are
   not. More info on what this means can be found in the States Tutorial.

   Extending Included SLS Data
   Sometimes  SLS  data  needs  to be extended. Perhaps the apache service
   needs to watch additional resources, or under certain  circumstances  a
   different file needs to be placed.

   In  these  examples,  the first will add a custom banner to ssh and the
   second will add more watchers to apache to include mod_python.

   ssh/custom-server.sls:

      include:
        - ssh.server

      extend:
        /etc/ssh/banner:
          file:
            - source: salt://ssh/custom-banner

   python/mod_python.sls:

      include:
        - apache

      extend:
        apache:
          service:
            - watch:
              - pkg: mod_python

      mod_python:
        pkg.installed

   The custom-server.sls file uses the extend statement to overwrite where
   the  banner  is being downloaded from, and therefore changing what file
   is being used to configure the banner.

   In the new mod_python SLS the mod_python package  is  added,  but  more
   importantly   the  apache  service  was  extended  to  also  watch  the
   mod_python package.

      Using extend with require or watch

             The extend statement works differently for require or  watch.
             It appends to, rather than replacing the requisite component.

   Understanding the Render System
   Since  SLS  data  is  simply  that  (data),  it  does  not  need  to be
   represented with YAML.  Salt  defaults  to  YAML  because  it  is  very
   straightforward  and  easy  to  learn and use. But the SLS files can be
   rendered from almost any imaginable  medium,  so  long  as  a  renderer
   module is provided.

   The default rendering system is the yaml_jinja renderer. The yaml_jinja
   renderer will first pass the template  through  the  Jinja2  templating
   system, and then through the YAML parser. The benefit here is that full
   programming constructs are available when creating SLS files.

   Other renderers available are yaml_mako and yaml_wempy which  each  use
   the  Mako or Wempy templating system respectively rather than the jinja
   templating system, and more notably, the pure Python  or  py,  pydsl  &
   pyobjects  renderers.   The  py  renderer  allows  for  SLS files to be
   written in pure Python, allowing for the utmost  level  of  flexibility
   and  power when preparing SLS data; while the pydsl renderer provides a
   flexible, domain-specific language for authoring SLS  data  in  Python;
   and the pyobjects renderer gives you a "Pythonic" interface to building
   state data.

   NOTE:
      The templating engines described above aren't just available in  SLS
      files.   They  can  also be used in file.managed states, making file
      management much more dynamic and flexible. Some examples  for  using
      templates in managed files can be found in the documentation for the
      file states, as well as the MooseFS example below.

   Getting to Know the Default - yaml_jinja
   The default  renderer  -  yaml_jinja,  allows  for  use  of  the  jinja
   templating  system. A guide to the Jinja templating system can be found
   here: http://jinja.pocoo.org/docs

   When working with renderers a few very useful bits of data  are  passed
   in.  In  the  case of templating engine based renderers, three critical
   components are available, salt, grains, and  pillar.  The  salt  object
   allows for any Salt function to be called from within the template, and
   grains allows for the Grains to be accessed from within the template. A
   few examples:

   apache/init.sls:

      apache:
        pkg.installed:
          {% if grains['os'] == 'RedHat'%}
          - name: httpd
          {% endif %}
        service.running:
          {% if grains['os'] == 'RedHat'%}
          - name: httpd
          {% endif %}
          - watch:
            - pkg: apache
            - file: /etc/httpd/conf/httpd.conf
            - user: apache
        user.present:
          - uid: 87
          - gid: 87
          - home: /var/www/html
          - shell: /bin/nologin
          - require:
            - group: apache
        group.present:
          - gid: 87
          - require:
            - pkg: apache

      /etc/httpd/conf/httpd.conf:
        file.managed:
          - source: salt://apache/httpd.conf
          - user: root
          - group: root
          - mode: 644

   This  example  is  simple.  If  the  os grain states that the operating
   system is Red Hat, then the name of  the  Apache  package  and  service
   needs to be httpd.

   A  more  aggressive  way to use Jinja can be found here, in a module to
   set up a MooseFS distributed filesystem chunkserver:

   moosefs/chunk.sls:

      include:
        - moosefs

      {% for mnt in salt['cmd.run']('ls /dev/data/moose*').split() %}
      /mnt/moose{{ mnt[-1] }}:
        mount.mounted:
          - device: {{ mnt }}
          - fstype: xfs
          - mkmnt: True
        file.directory:
          - user: mfs
          - group: mfs
          - require:
            - user: mfs
            - group: mfs
      {% endfor %}

      /etc/mfshdd.cfg:
        file.managed:
          - source: salt://moosefs/mfshdd.cfg
          - user: root
          - group: root
          - mode: 644
          - template: jinja
          - require:
            - pkg: mfs-chunkserver

      /etc/mfschunkserver.cfg:
        file.managed:
          - source: salt://moosefs/mfschunkserver.cfg
          - user: root
          - group: root
          - mode: 644
          - template: jinja
          - require:
            - pkg: mfs-chunkserver

      mfs-chunkserver:
        pkg.installed: []
      mfschunkserver:
        service.running:
          - require:
      {% for mnt in salt['cmd.run']('ls /dev/data/moose*') %}
            - mount: /mnt/moose{{ mnt[-1] }}
            - file: /mnt/moose{{ mnt[-1] }}
      {% endfor %}
            - file: /etc/mfschunkserver.cfg
            - file: /etc/mfshdd.cfg
            - file: /var/lib/mfs

   This example shows much more of the available power of Jinja.  Multiple
   for  loops are used to dynamically detect available hard drives and set
   them up to be mounted, and the salt object is used  multiple  times  to
   call shell commands to gather data.

   Introducing the Python, PyDSL, and the Pyobjects Renderers
   Sometimes  the  chosen  default  renderer might not have enough logical
   power to accomplish the needed task.  When  this  happens,  the  Python
   renderer  can  be used. Normally a YAML renderer should be used for the
   majority of SLS files, but an SLS file set to use another renderer  can
   be easily added to the tree.

   This example shows a very basic Python SLS file:

   python/django.sls:

      #!py

      def run():
          '''
          Install the django package
          '''
          return {'include': ['python'],
                  'django': {'pkg': ['installed']}}

   This  is  a very simple example; the first line has an SLS shebang that
   tells Salt to not use the default renderer, but to use the py renderer.
   Then  the  run  function  is  defined,  the  return  value from the run
   function must be a Salt friendly data structure, or better known  as  a
   Salt HighState data structure.

   Alternatively,  using  the  pydsl  renderer,  the  above example can be
   written more succinctly as:

      #!pydsl

      include('python', delayed=True)
      state('django').pkg.installed()

   The pyobjects renderer provides an "Pythonic" object based approach for
   building the state data.  The above example could be written as:

      #!pyobjects

      include('python')
      Pkg.installed("django")

   These  Python  examples  would  look  like this if they were written in
   YAML:

      include:
        - python

      django:
        pkg.installed

   This example clearly illustrates that; one, using the YAML renderer  by
   default  is  a  wise  decision and two, unbridled power can be obtained
   where needed by using a pure Python SLS.

   Running and Debugging Salt States
   Once the rules in an SLS are ready, they should  be  tested  to  ensure
   they  work  properly.  To  invoke  these rules, simply execute salt '*'
   state.apply on the command line. If you get back only hostnames with  a
   : after, but no return, chances are there is a problem with one or more
   of the sls files. On the minion, use the salt-call command  to  examine
   the output for errors:

      salt-call state.apply -l debug

   This should help troubleshoot the issue. The minion can also be started
   in the foreground in debug mode by running salt-minion -l debug.

   Next Reading
   With an understanding of states, the next recommendation is  to  become
   familiar with Salt's pillar interface:
      Pillar Walkthrough

   States tutorial, part 1 - Basic Usage
   The  purpose  of  this  tutorial  is to demonstrate how quickly you can
   configure  a  system  to  be  managed  by  Salt  States.  For  detailed
   information  about  the  state  system  please refer to the full states
   reference.

   This tutorial will walk you through using Salt to configure a minion to
   run the Apache HTTP server and to ensure the server is running.

   Before  continuing  make  sure  you have a working Salt installation by
   following the installation and the configuration instructions.

      Stuck?

             There are many ways to  get  help  from  the  Salt  community
             including our mailing list and our IRC channel #salt.

   Setting up the Salt State Tree
   States  are  stored  in text files on the master and transferred to the
   minions on demand via the master's File Server. The collection of state
   files make up the State Tree.

   To  start  using  a  central state system in Salt, the Salt File Server
   must first be set up. Edit the  master  config  file  (file_roots)  and
   uncomment the following lines:

      file_roots:
        base:
          - /srv/salt

   NOTE:
      If  you  are  deploying  on  FreeBSD  via ports, the file_roots path
      defaults to /usr/local/etc/salt/states.

   Restart the Salt master in order to pick up this change:

      pkill salt-master
      salt-master -d

   Preparing the Top File
   On the master, in the  directory  uncommented  in  the  previous  step,
   (/srv/salt  by  default),  create a new file called top.sls and add the
   following:

      base:
        '*':
          - webserver

   The top file is separated  into  environments  (discussed  later).  The
   default environment is base. Under the base environment a collection of
   minion matches is defined; for now simply specify all hosts (*).

      Targeting minions

             The expressions can use any of the targeting mechanisms  used
             by  Salt  ---  minions  can  be  matched  by glob, PCRE regular
             expression, or by grains. For example:

          base:
            'os:Fedora':
              - match: grain
              - webserver

   Create an sls file
   In  the  same  directory  as  the  top  file,  create  a   file   named
   webserver.sls, containing the following:

      apache:                 # ID declaration
        pkg:                  # state declaration
          - installed         # function declaration

   The  first line, called the id-declaration, is an arbitrary identifier.
   In this case it defines the name of the package to be installed.

   NOTE:
      The package  name  for  the  Apache  httpd  web  server  may  differ
      depending  on  OS or distro --- for example, on Fedora it is httpd but
      on Debian/Ubuntu it is apache2.

   The second line, called the state-declaration,  defines  which  of  the
   Salt  States  we are using. In this example, we are using the pkg state
   to ensure that a given package is installed.

   The third line, called the function-declaration, defines which function
   in the pkg state module to call.

      Renderers

             States  sls  files  can  be  written  in  many  formats. Salt
             requires only a simple data structure and  is  not  concerned
             with  how  that data structure is built. Templating languages
             and DSLs are a dime-a-dozen and everyone has a favorite.

             Building the expected data  structure  is  the  job  of  Salt
             renderers and they are dead-simple to write.

             In  this  tutorial we will be using YAML in Jinja2 templates,
             which is the default format. The default can  be  changed  by
             editing renderer in the master configuration file.

   Install the package
   Next, let's run the state we created. Open a terminal on the master and
   run:

      salt '*' state.apply

   Our master is instructing all targeted minions to run state.apply. When
   this  function  is  executed  without  any  SLS  targets, a minion will
   download the top file and attempt to match the expressions  within  it.
   When the minion does match an expression the modules listed for it will
   be downloaded, compiled, and executed.

   NOTE:
      This action is referred to as a "highstate", and can  be  run  using
      the  state.highstate function.  However, to make the usage easier to
      understand ("highstate" is not necessarily  an  intuitive  name),  a
      state.apply  function  was  added  in  version  2015.5.0, which when
      invoked  without  any  SLS   names   will   trigger   a   highstate.
      state.highstate  still exists and can be used, but the documentation
      (as can be seen above) has been updated to reference state.apply, so
      keep the following in mind as you read the documentation:

      * state.apply invoked without any SLS names will run state.highstate

      * state.apply invoked with SLS names will run state.sls

   Once  completed,  the  minion  will  report  back with a summary of all
   actions taken and all changes made.

   WARNING:
      If you have created custom grain modules, they will not be available
      in  the  top  file  until  after the first highstate. To make custom
      grains available on a minion's first highstate, it is recommended to
      use  this  example  to ensure that the custom grains are synced when
      the minion starts.

      SLS File Namespace

             Note that in the example above, the  SLS  file  webserver.sls
             was  referred  to  simply as webserver. The namespace for SLS
             files when referenced in top.sls  or  an  include-declaration
             follows a few simple rules:

      1. The .sls is discarded (i.e. webserver.sls becomes webserver).

      2.

         Subdirectories can be used for better organization.

                a. Each  subdirectory is represented with a dot (following
                   the Python import model) in  Salt  states  and  on  the
                   command  line .  webserver/dev.sls on the filesystem is
                   referred to as webserver.dev in Salt

                b. Because slashes are represented as dots, SLS files  can
                   not  contain  dots  in the name (other than the dot for
                   the SLS suffix).  The SLS  file  webserver_1.0.sls  can
                   not  be  matched,  and  webserver_1.0  would  match the
                   directory/file webserver_1/0.sls

      3. A file called init.sls in a subdirectory is referred  to  by  the
         path  of  the directory. So, webserver/init.sls is referred to as
         webserver.

      4. If both webserver.sls and  webserver/init.sls  happen  to  exist,
         webserver/init.sls  will be ignored and webserver.sls will be the
         file referred to as webserver.

      Troubleshooting Salt

             If the expected output isn't seen,  the  following  tips  can
             help to narrow down the problem.

      Turn up logging
             Salt  can be quite chatty when you change the logging setting
             to debug:

                 salt-minion -l debug

      Run the minion in the foreground
             By not starting the minion in daemon mode (-d) one  can  view
             any output from the minion as it works:

                 salt-minion

      Increase  the  default timeout value when running salt. For example,
      to change the default timeout to 60 seconds:

          salt -t 60

      For best results, combine all three:

          salt-minion -l debug        # On the minion
          salt '*' state.apply -t 60  # On the master

   Next steps
   This tutorial focused on getting a  simple  Salt  States  configuration
   working.   Part 2 will build on this example to cover more advanced sls
   syntax and will explore more of the states that ship with Salt.

   States tutorial, part 2 - More Complex States, Requisites
   NOTE:
      This tutorial builds on topics covered in part 1. It is  recommended
      that you begin there.

   In  the  last part of the Salt States tutorial we covered the basics of
   installing a package. We will now modify our webserver.sls file to have
   requirements, and use even more Salt States.

   Call multiple States
   You can specify multiple state-declaration under an id-declaration. For
   example, a quick modification to our webserver.sls to also start Apache
   if it is not running:

      apache:
        pkg.installed: []
        service.running:
          - require:
            - pkg: apache

   Try  stopping  Apache before running state.apply once again and observe
   the output.

   NOTE:
      For those running RedhatOS derivatives (Centos, AWS), you will  want
      to specify the service name to be httpd. More on state service here,
      service state.  With the example above, just  add  "-  name:  httpd"
      above the require line and with the same spacing.

   Require other states
   We  now have a working installation of Apache so let's add an HTML file
   to customize our website. It isn't exactly useful  to  have  a  website
   without  a  webserver  so  we  don't want Salt to install our HTML file
   until Apache is installed and running. Include  the  following  at  the
   bottom of your webserver/init.sls file:

      apache:
        pkg.installed: []
        service.running:
          - require:
            - pkg: apache

      /var/www/index.html:                        # ID declaration
        file:                                     # state declaration
          - managed                               # function
          - source: salt://webserver/index.html   # function arg
          - require:                              # requisite declaration
            - pkg: apache                         # requisite reference

   line  7  is  the  id-declaration. In this example it is the location we
   want to install our custom HTML file. (Note: the default location  that
   Apache  serves may differ from the above on your OS or distro. /srv/www
   could also be a likely place to look.)

   Line 8 the state-declaration. This example uses the Salt file state.

   Line 9 is the function-declaration. The managed function will  download
   a file from the master and install it in the location specified.

   Line  10  is  a function-arg-declaration which, in this example, passes
   the source argument to the managed function.

   Line 11 is a requisite-declaration.

   Line 12 is a requisite-reference which refers to a state and an ID.  In
   this example, it is referring to the ID declaration from our example in
   part 1. This declaration tells Salt not to install the HTML file  until
   Apache is installed.

   Next,  create  the  index.html  file  and  save  it  in  the  webserver
   directory:

      <!DOCTYPE html>
      <html>
          <head><title>Salt rocks</title></head>
          <body>
              <h1>This file brought to you by Salt</h1>
          </body>
      </html>

   Last, call state.apply again and the minion will fetch and execute  the
   highstate  as  well  as our HTML file from the master using Salt's File
   Server:

      salt '*' state.apply

   Verify that Apache is now serving your custom HTML.

      require vs. watch

             There are two requisite-declaration, "require", and  "watch".
             Not  every  state  supports  "watch".  The service state does
             support "watch" and will restart a service based on the watch
             condition.

             For  example,  if  you  use Salt to install an Apache virtual
             host configuration file and want to restart  Apache  whenever
             that file is changed you could modify our Apache example from
             earlier as follows:

          /etc/httpd/extra/httpd-vhosts.conf:
            file.managed:
              - source: salt://webserver/httpd-vhosts.conf

          apache:
            pkg.installed: []
            service.running:
              - watch:
                - file: /etc/httpd/extra/httpd-vhosts.conf
              - require:
                - pkg: apache

      If the pkg and service names differ on your OS or distro  of  choice
      you  can  specify each one separately using a name-declaration which
      explained in Part 3.

   Next steps
   In part 3 we will discuss how to use includes, extends, and  templating
   to make a more complete State Tree configuration.

   States tutorial, part 3 - Templating, Includes, Extends
   NOTE:
      This  tutorial  builds on topics covered in part 1 and part 2. It is
      recommended that you begin there.

   This part of the tutorial  will  cover  more  advanced  templating  and
   configuration techniques for sls files.

   Templating SLS modules
   SLS  modules may require programming logic or inline execution. This is
   accomplished with module  templating.  The  default  module  templating
   system  used  is Jinja2  and may be configured by changing the renderer
   value in the master config.

   All states are  passed  through  a  templating  system  when  they  are
   initially  read.  To make use of the templating system, simply add some
   templating markup.  An example of an sls module with templating  markup
   may look like this:

      {% for usr in ['moe','larry','curly'] %}
      {{ usr }}:
        user.present
      {% endfor %}

   This templated sls file once generated will look like this:

      moe:
        user.present
      larry:
        user.present
      curly:
        user.present

   Here's a more complex example:

      # Comments in yaml start with a hash symbol.
      # Since jinja rendering occurs before yaml parsing, if you want to include jinja
      # in the comments you may need to escape them using 'jinja' comments to prevent
      # jinja from trying to render something which is not well-defined jinja.
      # e.g.
      # {# iterate over the Three Stooges using a {% for %}..{% endfor %} loop
      # with the iterator variable {{ usr }} becoming the state ID. #}
      {% for usr in 'moe','larry','curly' %}
      {{ usr }}:
        group:
          - present
        user:
          - present
          - gid_from_name: True
          - require:
            - group: {{ usr }}
      {% endfor %}

   Using Grains in SLS modules
   Often  times  a  state  will  need  to  behave differently on different
   systems.  Salt grains  objects  are  made  available  in  the  template
   context. The grains can be used from within sls modules:

      apache:
        pkg.installed:
          {% if grains['os'] == 'RedHat' %}
          - name: httpd
          {% elif grains['os'] == 'Ubuntu' %}
          - name: apache2
          {% endif %}

   Using Environment Variables in SLS modules
   You  can  use  salt['environ.get']('VARNAME')  to  use  an  environment
   variable in a Salt state.

      MYENVVAR="world" salt-call state.template test.sls

       Create a file with contents from an environment variable:
      file.managed:
        - name: /tmp/hello
        - contents: {{ salt['environ.get']('MYENVVAR') }}

   Error checking:

      {% set myenvvar = salt['environ.get']('MYENVVAR') %}
      {% if myenvvar %}

      Create a file with contents from an environment variable:
        file.managed:
          - name: /tmp/hello
          - contents: {{ salt['environ.get']('MYENVVAR') }}

      {% else %}

      Fail - no environment passed in:
        test:
          A. fail_without_changes

      {% endif %}

   Calling Salt modules from templates
   All of the Salt modules loaded by the minion are available  within  the
   templating  system. This allows data to be gathered in real time on the
   target system. It also allows for shell commands to be run easily  from
   within the sls modules.

   The  Salt  module  functions  are  also  made available in the template
   context as salt:

   The following example illustrates calling the group_to_gid function  in
   the  file  execution  module  with  a single positional argument called
   some_group_that_exists.

      moe:
        user.present:
          - gid: {{ salt['file.group_to_gid']('some_group_that_exists') }}

   One way to think about this might be that the gid key is being assigned
   a value equivelent to the following python pseudo-code:

      import salt.modules.file
      file.group_to_gid('some_group_that_exists')

   Note  that  for  the above example to work, some_group_that_exists must
   exist before the state file is processed by the templating engine.

   Below is an example that uses the network.hw_addr function to  retrieve
   the MAC address for eth0:

      salt['network.hw_addr']('eth0')

   To  examine  the  possible arguments to each execution module function,
   one can examine the module reference documentation </ref/modules/all>:

   Advanced SLS module syntax
   Lastly, we will  cover  some  incredibly  useful  techniques  for  more
   complex State trees.

   Include declaration
   A  previous  example  showed  how  to spread a Salt tree across several
   files.   Similarly,  requisites  span  multiple  files  by   using   an
   include-declaration. For example:

   python/python-libs.sls:

      python-dateutil:
        pkg.installed

   python/django.sls:

      include:
        - python.python-libs

      django:
        pkg.installed:
          - require:
            - pkg: python-dateutil

   Extend declaration
   You  can  modify  previous declarations by using an extend-declaration.
   For example the following modifies the  Apache  tree  to  also  restart
   Apache when the vhosts file is changed:

   apache/apache.sls:

      apache:
        pkg.installed

   apache/mywebsite.sls:

      include:
        - apache.apache

      extend:
        apache:
          service:
            - running
            - watch:
              - file: /etc/httpd/extra/httpd-vhosts.conf

      /etc/httpd/extra/httpd-vhosts.conf:
        file.managed:
          - source: salt://apache/httpd-vhosts.conf

      Using extend with require or watch

             The  extend statement works differently for require or watch.
             It appends to, rather than replacing the requisite component.

   Name declaration
   You can override the id-declaration by using a  name-declaration.   For
   example,  the  previous example is a bit more maintainable if rewritten
   as follows:

   apache/mywebsite.sls:

      include:
        - apache.apache

      extend:
        apache:
          service:
            - running
            - watch:
              - file: mywebsite

      mywebsite:
        file.managed:
          - name: /etc/httpd/extra/httpd-vhosts.conf
          - source: salt://apache/httpd-vhosts.conf

   Names declaration
   Even more  powerful  is  using  a  names-declaration  to  override  the
   id-declaration  for  multiple states at once. This often can remove the
   need for looping in a template. For example, the first example in  this
   tutorial can be rewritten without the loop:

      stooges:
        user.present:
          - names:
            - moe
            - larry
            - curly

   Next steps
   In  part  4  we  will  discuss how to use salt's file_roots to set up a
   workflow in which  states  can  be  "promoted"  from  dev,  to  QA,  to
   production.

   States tutorial, part 4
   NOTE:
      This tutorial builds on topics covered in part 1, part 2 and part 3.
      It is recommended that you begin there.

   This part of the tutorial will show how to use salt's file_roots to set
   up  a  workflow  in  which states can be "promoted" from dev, to QA, to
   production.

   Salt fileserver path inheritance
   Salt's  fileserver  allows  for  more  than  one  root  directory   per
   environment,  like  in  the  below  example,  which  uses  both a local
   directory and a secondary location shared to the salt master via NFS:

      # In the master config file (/etc/salt/master)
      file_roots:
        base:
          - /srv/salt
          - /mnt/salt-nfs/base

   Salt's fileserver collapses the list of root directories into a  single
   virtual  environment  containing  all files from each root. If the same
   file exists at the same relative path in more than one root,  then  the
   top-most   match   "wins".   For   example,  if  /srv/salt/foo.txt  and
   /mnt/salt-nfs/base/foo.txt both exist, then salt://foo.txt  will  point
   to /srv/salt/foo.txt.

   NOTE:
      When using multiple fileserver backends, the order in which they are
      listed in the fileserver_backend parameter  also  matters.  If  both
      roots  and  git backends contain a file with the same relative path,
      and roots appears before git in the  fileserver_backend  list,  then
      the file in roots will "win", and the file in gitfs will be ignored.

      A  more  thorough explanation of how Salt's modular fileserver works
      can be found here. We recommend reading this.

   Environment configuration
   Configure a multiple-environment setup like so:

      file_roots:
        base:
          - /srv/salt/prod
        qa:
          - /srv/salt/qa
          - /srv/salt/prod
        dev:
          - /srv/salt/dev
          - /srv/salt/qa
          - /srv/salt/prod

   Given the path inheritance described above, files within /srv/salt/prod
   would be available in all environments. Files within /srv/salt/qa would
   be  available  in  both  qa,  and  dev.  Finally,  the   files   within
   /srv/salt/dev would only be available within the dev environment.

   Based on the order in which the roots are defined, new files/states can
   be placed within /srv/salt/dev, and pushed out to  the  dev  hosts  for
   testing.

   Those  files/states  can then be moved to the same relative path within
   /srv/salt/qa, and they are  now  available  only  in  the  dev  and  qa
   environments, allowing them to be pushed to QA hosts and tested.

   Finally,  if moved to the same relative path within /srv/salt/prod, the
   files are now available in all three environments.

   Requesting files from specific fileserver environments
   See here for documentation  on  how  to  request  files  from  specific
   environments.

   Practical Example
   As    an   example,   consider   a   simple   website,   installed   to
   /var/www/foobarcom.  Below is a top.sls that can be used to deploy  the
   website:

   /srv/salt/prod/top.sls:

      base:
        'web*prod*':
          - webserver.foobarcom
      qa:
        'web*qa*':
          - webserver.foobarcom
      dev:
        'web*dev*':
          - webserver.foobarcom

   Using pillar, roles can be assigned to the hosts:

   /srv/pillar/top.sls:

      base:
        'web*prod*':
          - webserver.prod
        'web*qa*':
          - webserver.qa
        'web*dev*':
          - webserver.dev

   /srv/pillar/webserver/prod.sls:

      webserver_role: prod

   /srv/pillar/webserver/qa.sls:

      webserver_role: qa

   /srv/pillar/webserver/dev.sls:

      webserver_role: dev

   And finally, the SLS to deploy the website:

   /srv/salt/prod/webserver/foobarcom.sls:

      {% if pillar.get('webserver_role', '') %}
      /var/www/foobarcom:
        file.recurse:
          - source: salt://webserver/src/foobarcom
          - env: {{ pillar['webserver_role'] }}
          - user: www
          - group: www
          - dir_mode: 755
          - file_mode: 644
      {% endif %}

   Given  the  above  SLS,  the source for the website should initially be
   placed in /srv/salt/dev/webserver/src/foobarcom.

   First, let's deploy to dev. Given the configuration in  the  top  file,
   this can be done using state.apply:

      salt --pillar 'webserver_role:dev' state.apply

   However,  in  the  event  that  it is not desirable to apply all states
   configured in the top file (which  could  be  likely  in  more  complex
   setups),  it  is  possible  to  apply just the states for the foobarcom
   website, by invoking state.apply with the  desired  SLS  target  as  an
   argument:

      salt --pillar 'webserver_role:dev' state.apply webserver.foobarcom

   Once  the site has been tested in dev, then the files can be moved from
   /srv/salt/dev/webserver/src/foobarcom                                to
   /srv/salt/qa/webserver/src/foobarcom, and deployed using the following:

      salt --pillar 'webserver_role:qa' state.apply webserver.foobarcom

   Finally,  once  the  site  has been tested in qa, then the files can be
   moved        from        /srv/salt/qa/webserver/src/foobarcom        to
   /srv/salt/prod/webserver/src/foobarcom,    and   deployed   using   the
   following:

      salt --pillar 'webserver_role:prod' state.apply webserver.foobarcom

   Thanks to Salt's fileserver inheritance, even  though  the  files  have
   been  moved to within /srv/salt/prod, they are still available from the
   same salt:// URI in both the qa and dev environments.

   Continue Learning
   The best way to continue learning about Salt States is to read  through
   the  reference  documentation  and to look through examples of existing
   state trees. Many pre-configured state trees can be found on GitHub  in
   the saltstack-formulas collection of repositories.

   If you have any questions, suggestions, or just want to chat with other
   people who are using Salt, we have a very  active  community  and  we'd
   love to hear from you.

   In  addition, by continuing to part 5, you can learn about the powerful
   orchestration of which Salt is capable.

   State System Reference
   Salt offers an interface to manage the configuration or "state" of  the
   Salt  minions.  This  interface  is  a  fully capable mechanism used to
   enforce the state of systems from a central manager.

   Mod Aggregate State Runtime Modifications
   New in version 2014.7.0.

   The mod_aggregate system was added in the 2014.7.0 release of Salt  and
   allows  for  runtime  modification  of the executing state data. Simply
   put, it allows for the data used by Salt's state system to  be  changed
   on  the  fly  at  runtime,  kind of like a configuration management JIT
   compiler or a runtime import system. All in all,  it  makes  Salt  much
   more dynamic.

   How it Works
   The  best  example  is the pkg state. One of the major requests in Salt
   has long been adding the ability to install all packages defined at the
   same  time.  The  mod_aggregate  system  makes  this  a  reality. While
   executing Salt's  state  system,  when  a  pkg  state  is  reached  the
   mod_aggregate  function  in  the  state  module is called. For pkg this
   function scans all of the other states that  are  slated  to  run,  and
   picks up the references to name and pkgs, then adds them to pkgs in the
   first state. The result is a single call to yum, apt-get,  pacman,  etc
   as part of the first package install.

   How to Use it
   NOTE:
      Since  this  option changes the basic behavior of the state runtime,
      after it is enabled states should be  executed  using  test=True  to
      ensure that the desired behavior is preserved.

   In config files
   The  first  way to enable aggregation is with a configuration option in
   either the master or  minion  configuration  files.  Salt  will  invoke
   mod_aggregate  the  first  time  it  encounters a state module that has
   aggregate support.

   If this option is set in the master config it will apply to  all  state
   runs  on all minions, if set in the minion config it will only apply to
   said minion.

   Enable for all states:

      state_aggregate: True

   Enable for only specific state modules:

      state_aggregate:
        - pkg

   In states
   The second way to enable aggregation is with the state-level  aggregate
   keyword.  In  this  configuration,  Salt  will invoke the mod_aggregate
   function the first time it  encounters  this  keyword.  Any  additional
   occurrences  of  the  keyword  will  be  ignored as the aggregation has
   already taken place.

   The following example will trigger mod_aggregate  when  the  lamp_stack
   state is processed resulting in a single call to the underlying package
   manager.

      lamp_stack:
        pkg.installed:
          - pkgs:
            - php
            - mysql-client
          - aggregate: True

      memcached:
        pkg.installed:
          - name: memcached

   Adding mod_aggregate to a State Module
   Adding a  mod_aggregate  routine  to  an  existing  state  module  only
   requires  adding  an  additional  function  to  the state module called
   mod_aggregate.

   The mod_aggregate function just needs to accept  three  parameters  and
   return the low data to use. Since mod_aggregate is working on the state
   runtime level it does need to manipulate low data.

   The three parameters are low, chunks, and running. The  low  option  is
   the  low  data for the state execution which is about to be called. The
   chunks is the list of all of the low data dictionaries which are  being
   executed  by  the runtime and the running dictionary is the return data
   from all of the state executions which have already be executed.

   This example, simplified from  the  pkg  state,  shows  how  to  create
   mod_aggregate functions:

      def mod_aggregate(low, chunks, running):
          '''
          The mod_aggregate function which looks up all packages in the available
          low chunks and merges them into a single pkgs ref in the present low data
          '''
          pkgs = []
          # What functions should we aggregate?
          agg_enabled = [
                  'installed',
                  'latest',
                  'removed',
                  'purged',
                  ]
          # The `low` data is just a dict with the state, function (fun) and
          # arguments passed in from the sls
          if low.get('fun') not in agg_enabled:
              return low
          # Now look into what other things are set to execute
          for chunk in chunks:
              # The state runtime uses "tags" to track completed jobs, it may
              # look familiar with the _|-
              tag = salt.utils.gen_state_tag(chunk)
              if tag in running:
                  # Already ran the pkg state, skip aggregation
                  continue
              if chunk.get('state') == 'pkg':
                  if '__agg__' in chunk:
                      continue
                  # Check for the same function
                  if chunk.get('fun') != low.get('fun'):
                      continue
                  # Pull out the pkg names!
                  if 'pkgs' in chunk:
                      pkgs.extend(chunk['pkgs'])
                      chunk['__agg__'] = True
                  elif 'name' in chunk:
                      pkgs.append(chunk['name'])
                      chunk['__agg__'] = True
          if pkgs:
              if 'pkgs' in low:
                  low['pkgs'].extend(pkgs)
              else:
                  low['pkgs'] = pkgs
          # The low has been modified and needs to be returned to the state
          # runtime for execution
          return low

   Altering States
   NOTE:
      This documentation has been moved here.

   File State Backups
   In  0.10.2  a  new  feature  was  added  for  backing up files that are
   replaced by the file.managed and file.recurse states. The  new  feature
   is  called the backup mode. Setting the backup mode is easy, but it can
   be set in a number of places.

   The backup_mode can be set in the minion config file:

      backup_mode: minion

   Or it can be set for each file:

      /etc/ssh/sshd_config:
        file.managed:
          - source: salt://ssh/sshd_config
          - backup: minion

   Backed-up Files
   The files will be saved in the  minion  cachedir  under  the  directory
   named  file_backup. The files will be in the location relative to where
   they were under the root filesystem and be appended with  a  timestamp.
   This should make them easy to browse.

   Interacting with Backups
   Starting with version 0.17.0, it will be possible to list, restore, and
   delete previously-created backups.

   Listing
   The backups for a given file can be listed using file.list_backups:

      # salt foo.bar.com file.list_backups /tmp/foo.txt
      foo.bar.com:
          ----------
          0:
              ----------
              Backup Time:
                  Sat Jul 27 2013 17:48:41.738027
              Location:
                  /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:41_738027_2013
              Size:
                  13
          1:
              ----------
              Backup Time:
                  Sat Jul 27 2013 17:48:28.369804
              Location:
                  /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013
              Size:
                  35

   Restoring
   Restoring is easy using file.restore_backup, just pass the path and the
   numeric id found with file.list_backups:

      # salt foo.bar.com file.restore_backup /tmp/foo.txt 1
      foo.bar.com:
          ----------
          comment:
              Successfully restored /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013 to /tmp/foo.txt
          result:
              True

   The  existing  file  will be backed up, just in case, as can be seen if
   file.list_backups is run again:

      # salt foo.bar.com file.list_backups /tmp/foo.txt
      foo.bar.com:
          ----------
          0:
              ----------
              Backup Time:
                  Sat Jul 27 2013 18:00:19.822550
              Location:
                  /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_18:00:19_822550_2013
              Size:
                  53
          1:
              ----------
              Backup Time:
                  Sat Jul 27 2013 17:48:41.738027
              Location:
                  /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:41_738027_2013
              Size:
                  13
          2:
              ----------
              Backup Time:
                  Sat Jul 27 2013 17:48:28.369804
              Location:
                  /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013
              Size:
                  35

   NOTE:
      Since no state is being run, restoring a file will not  trigger  any
      watches  for  the file. So, if you are restoring a config file for a
      service, it will likely still be necessary to run a service.restart.

   Deleting
   Deleting backups can be done using file.delete_backup:

      # salt foo.bar.com file.delete_backup /tmp/foo.txt 0
      foo.bar.com:
          ----------
          comment:
              Successfully removed /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_18:00:19_822550_2013
          result:
              True

   Understanding State Compiler Ordering
   NOTE:
      This  tutorial  is  an  intermediate  level  tutorial.  Some   basic
      understanding  of  the  state  system  and  writing Salt Formulas is
      assumed.

   Salt's  state  system  is  built  to  deliver  all  of  the  power   of
   configuration  management  systems without sacrificing simplicity. This
   tutorial is made to help users understand in detail just how the  order
   is defined for state executions in Salt.

   This  tutorial  is  written  to  represent  the  behavior of Salt as of
   version 0.17.0.

   Compiler Basics
   To understand ordering in depth some very  basic  knowledge  about  the
   state  compiler  is very helpful. No need to worry though, this is very
   high level!

   High Data and Low Data
   When defining Salt Formulas in YAML the data that is being  represented
   is referred to by the compiler as High Data. When the data is initially
   loaded into the compiler it is a single large python  dictionary,  this
   dictionary can be viewed raw by running:

      salt '*' state.show_highstate

   This "High Data" structure is then compiled down to "Low Data". The Low
   Data is what is matched up to create individual  executions  in  Salt's
   configuration  management  system.  The  low data is an ordered list of
   single state calls to execute.  Once  the  low  data  is  compiled  the
   evaluation order can be seen.

   The low data can be viewed by running:

      salt '*' state.show_lowstate

   NOTE:
      The  state  execution  module contains MANY functions for evaluating
      the state system and is well worth a read!  These  routines  can  be
      very   useful   when  debugging  states  or  to  help  deepen  one's
      understanding of Salt's state system.

   As an example, a state written thusly:

      apache:
        pkg.installed:
          - name: httpd
        service.running:
          - name: httpd
          - watch:
            - file: apache_conf
            - pkg: apache

      apache_conf:
        file.managed:
          - name: /etc/httpd/conf.d/httpd.conf
          - source: salt://apache/httpd.conf

   Will have High Data which looks like this represented in json:

      {
          "apache": {
              "pkg": [
                  {
                      "name": "httpd"
                  },
                  "installed",
                  {
                      "order": 10000
                  }
              ],
              "service": [
                  {
                      "name": "httpd"
                  },
                  {
                      "watch": [
                          {
                              "file": "apache_conf"
                          },
                          {
                              "pkg": "apache"
                          }
                      ]
                  },
                  "running",
                  {
                      "order": 10001
                  }
              ],
              "__sls__": "blah",
              "__env__": "base"
          },
          "apache_conf": {
              "file": [
                  {
                      "name": "/etc/httpd/conf.d/httpd.conf"
                  },
                  {
                      "source": "salt://apache/httpd.conf"
                  },
                  "managed",
                  {
                      "order": 10002
                  }
              ],
              "__sls__": "blah",
              "__env__": "base"
          }
      }

   The subsequent Low Data will look like this:

      [
          {
              "name": "httpd",
              "state": "pkg",
              "__id__": "apache",
              "fun": "installed",
              "__env__": "base",
              "__sls__": "blah",
              "order": 10000
          },
          {
              "name": "httpd",
              "watch": [
                  {
                      "file": "apache_conf"
                  },
                  {
                      "pkg": "apache"
                  }
              ],
              "state": "service",
              "__id__": "apache",
              "fun": "running",
              "__env__": "base",
              "__sls__": "blah",
              "order": 10001
          },
          {
              "name": "/etc/httpd/conf.d/httpd.conf",
              "source": "salt://apache/httpd.conf",
              "state": "file",
              "__id__": "apache_conf",
              "fun": "managed",
              "__env__": "base",
              "__sls__": "blah",
              "order": 10002
          }
      ]

   This tutorial discusses the Low Data evaluation and the state runtime.

   Ordering Layers
   Salt defines 2 order  interfaces  which  are  evaluated  in  the  state
   runtime and defines these orders in a number of passes.

   Definition Order
   NOTE:
      The  Definition  Order  system can be disabled by turning the option
      state_auto_order to False in the master configuration file.

   The top level of ordering is the Definition Order. The Definition Order
   is the order in which states are defined in salt formulas. This is very
   straightforward on basic states which do not contain include statements
   or a top file, as the states are just ordered from the top of the file,
   but the include system starts to bring in some simple rules for how the
   Definition Order is defined.

   Looking  back  at the "Low Data" and "High Data" shown above, the order
   key has been transparently added to the data to enable  the  Definition
   Order.

   The Include Statement
   Basically,  if  there  is  an  include statement in a formula, then the
   formulas which are included will be run  BEFORE  the  contents  of  the
   formula which is including them. Also, the include statement is a list,
   so they will be loaded in the order in which they are included.

   In the following case:

   foo.sls

      include:
        - bar
        - baz

   bar.sls

      include:
        - quo

   baz.sls

      include:
        - qux

   In the above case if state.apply foo were called then the formulas will
   be loaded in the following order:

   1. quo

   2. bar

   3. qux

   4. baz

   5. foo

   The order Flag
   The  Definition  Order happens transparently in the background, but the
   ordering can be explicitly overridden using the order flag in states:

      apache:
        pkg.installed:
          - name: httpd
          - order: 1

   This order flag will over ride the definition order, this makes it very
   simple  to  create  states  that  are always executed first, last or in
   specific stages, a great  example  is  defining  a  number  of  package
   repositories  that  need  to  be  set up before anything else, or final
   checks that need to be run at the end of a state run  by  using  order:
   last or order: -1.

   When  the order flag is explicitly set the Definition Order system will
   omit setting an order for that state and directly use  the  order  flag
   defined.

   Lexicographical Fall-back
   Salt  states  were  written to ALWAYS execute in the same order. Before
   the introduction of Definition Order in version 0.17.0  everything  was
   ordered  lexicographically  according  to  the  name of the state, then
   function then id.

   This is the way Salt has always ensured that states always run  in  the
   same  order  regardless of where they are deployed, the addition of the
   Definition Order method mealy makes  this  finite  ordering  easier  to
   follow.

   The  lexicographical  ordering  is  still  applied  but it only has any
   effect when two order statements collide. This means that  if  multiple
   states  are  assigned the same order number that they will fall back to
   lexicographical ordering to ensure that every execution  still  happens
   in a finite order.

   NOTE:
      If  running  with  state_auto_order:  False the order key is not set
      automatically, since the Lexicographical order can be  derived  from
      other keys.

   Requisite Ordering
   Salt  states are fully declarative, in that they are written to declare
   the state in which a system should be. This means that  components  can
   require that other components have been set up successfully. Unlike the
   other ordering systems, the Requisite system in Salt  is  evaluated  at
   runtime.

   The  requisite  system  is  also  built  to ensure that the ordering of
   execution never changes, but is always the same  for  a  given  set  of
   states.  This  is accomplished by using a runtime that processes states
   in a completely predictable order instead of using an event loop  based
   system like other declarative configuration management systems.

   Runtime Requisite Evaluation
   The  requisite system is evaluated as the components are found, and the
   requisites are always evaluated in the  same  order.  This  explanation
   will  be followed by an example, as the raw explanation may be a little
   dizzying  at  first  as  it  creates  a  linear  dependency  evaluation
   sequence.

   The  "Low  Data"  is an ordered list or dictionaries, the state runtime
   evaluates each dictionary in the order in which they  are  arranged  in
   the  list.  When  evaluating  a  single  dictionary  it  is checked for
   requisites, requisites are evaluated in order, require then watch  then
   prereq.

   NOTE:
      If  using requisite in statements like require_in and watch_in these
      will be compiled down to require and watch statements before runtime
      evaluation.

   Each requisite contains an ordered list of requisites, these requisites
   are looked up in the list of dictionaries and then executed.  Once  all
   requisites  have  been  evaluated and executed then the requiring state
   can safely be run (or not run if requisites have not been met).

   This means that the requisites are always evaluated in the same  order,
   again ensuring one of the core design principals of Salt's State system
   to ensure that execution is always finite is intact.

   Simple Runtime Evaluation Example
   Given the above  "Low  Data"  the  states  will  be  evaluated  in  the
   following order:

   1. The  pkg.installed  is  executed ensuring that the apache package is
      installed, it contains no requisites  and  is  therefore  the  first
      defined state to execute.

   2. The  service.running  state  is  evaluated but NOT executed, a watch
      requisite is found, therefore they are read in  order,  the  runtime
      first  checks  for  the file, sees that it has not been executed and
      calls for the file state to be evaluated.

   3. The file state is evaluated AND executed, since  it,  like  the  pkg
      state does not contain any requisites.

   4. The  evaluation  of  the service state continues, it next checks the
      pkg requisite and sees that it is met, with all requisites  met  the
      service state is now executed.

   Best Practice
   The  best  practice  in  Salt  is to choose a method and stick with it,
   official states are written using requisites for all associations since
   requisites  create  clean, traceable dependency trails and make for the
   most  portable  formulas.  To  accomplish  something  similar  to   how
   classical imperative systems function all requisites can be omitted and
   the failhard option then set to True in the master configuration,  this
   will stop all state runs at the first instance of a failure.

   In  the  end,  using  requisites  creates  very  tight and fine grained
   states, not  using  requisites  makes  full  sequence  runs  and  while
   slightly  easier  to  write,  and  gives  much  less  control  over the
   executions.

   Extending External SLS Data
   Sometimes a state defined in one SLS file will need to be modified from
   a  separate  SLS file. A good example of this is when an argument needs
   to be overwritten or when a service needs to watch an additional state.

   The Extend Declaration
   The standard way to extend is via the extend  declaration.  The  extend
   declaration is a top level declaration like include and encapsulates ID
   declaration data included from other SLS files. A standard extend looks
   like this:

      include:
        - http
        - ssh

      extend:
        apache:
          file:
            - name: /etc/httpd/conf/httpd.conf
            - source: salt://http/httpd2.conf
        ssh-server:
          service:
            - watch:
              - file: /etc/ssh/banner

      /etc/ssh/banner:
        file.managed:
          - source: salt://ssh/banner

   A  few  critical things happened here, first off the SLS files that are
   going to be extended are included, then  the  extend  dec  is  defined.
   Under  the extend dec 2 IDs are extended, the apache ID's file state is
   overwritten with a new name and source. Then the ssh server is extended
   to  watch  the  banner  file  in  addition  to  anything  it is already
   watching.

   Extend is a Top Level Declaration
   This means that extend can only be called once in an sls, if if is used
   twice  then  only  one  of  the  extend blocks will be read. So this is
   WRONG:

      include:
        - http
        - ssh

      extend:
        apache:
          file:
            - name: /etc/httpd/conf/httpd.conf
            - source: salt://http/httpd2.conf
      # Second extend will overwrite the first!! Only make one
      extend:
        ssh-server:
          service:
            - watch:
              - file: /etc/ssh/banner

   The Requisite in Statement
   Since one of the most common things to do when extending another SLS is
   to  add  states  for  a  service to watch, or anything for a watcher to
   watch, the requisite in statement was added to 0.9.8 to make  extending
   the  watch  and  require  lists easier. The ssh-server extend statement
   above could be more cleanly defined like so:

      include:
        - ssh

      /etc/ssh/banner:
        file.managed:
          - source: salt://ssh/banner
          - watch_in:
            - service: ssh-server

   Rules to Extend By
   There are a few rules to remember when extending states:

   1. Always include the SLS being extended with an include declaration

   2. Requisites (watch and require) are appended to, everything  else  is
      overwritten

   3. extend is a top level declaration, like an ID declaration, cannot be
      declared twice in a single SLS

   4. Many IDs can be extended under the extend declaration

   Failhard Global Option
   Normally, when a state fails Salt continues to execute the remainder of
   the  defined states and will only refuse to execute states that require
   the failed state.

   But the situation may exist, where you would want all  state  execution
   to stop if a single state execution fails. The capability to do this is
   called failing hard.

   State Level Failhard
   A single state can have  a  failhard  set,  this  means  that  if  this
   individual  state fails that all state execution will immediately stop.
   This is a great thing to do if there is a state that sets up a critical
   config  file and setting a require for each state that reads the config
   would be cumbersome.  A good example of this  would  be  setting  up  a
   package manager early on:

      /etc/yum.repos.d/company.repo:
        file.managed:
          - source: salt://company/yumrepo.conf
          - user: root
          - group: root
          - mode: 644
          - order: 1
          - failhard: True

   In  this situation, the yum repo is going to be configured before other
   states, and if it fails to lay down the  config  file,  than  no  other
   states will be executed.

   Global Failhard
   It  may  be  desired to have failhard be applied to every state that is
   executed, if this is the case, then failhard can be set in  the  master
   configuration  file.  Setting failhard in the master configuration file
   will result in failing hard when any minion gathering states  from  the
   master have a state fail.

   This  is  NOT the default behavior, normally Salt will only fail states
   that require a failed state.

   Using the global failhard is generally not recommended,  since  it  can
   result  in  states  not  being executed or even checked. It can also be
   confusing to see states failhard if an admin is not actively aware that
   the failhard has been set.

   To   use   the  global  failhard  set  failhard:  True  in  the  master
   configuration file.

   Global State Arguments
   NOTE:
      This documentation has been moved here.

   Highstate data structure definitions
   The Salt State Tree
   A state tree is a collection of SLS files  and  directories  that  live
   under the directory specified in file_roots.

   NOTE:
      Directory  names  or  filenames  in  the state tree cannot contain a
      period, with the exception of the period in the .sls file suffix.

   Top file
   The main state file that instructs minions what environment and modules
   to use during state execution.

   Configurable via state_top.

   SEE ALSO:
      A detailed description of the top file

   Include declaration
   Defines a list of Module reference strings to include in this SLS.

   Occurs only in the top level of the SLS data structure.

   Example:

      include:
        - edit.vim
        - http.server

   Module reference
   The name of a SLS module defined by a separate SLS file and residing on
   the Salt Master. A module named edit.vim is a reference to the SLS file
   salt://edit/vim.sls.

   ID declaration
   Defines an individual highstate component. Always references a value of
   a  dictionary  containing  keys  referencing  State   declaration   and
   Requisite  declaration.  Can  be  overridden by a Name declaration or a
   Names declaration.

   Occurs on the top level or under the Extend declaration.

   Must be unique across entire state tree. If the same ID declaration  is
   used  twice, only the first one matched will be used. All subsequent ID
   declarations with the same name will be ignored.

   NOTE:
      Naming gotchas

      In Salt versions earlier than 0.9.7, ID declarations containing dots
      would result in unpredictable output.

   Extend declaration
   Extends a Name declaration from an included SLS module. The keys of the
   extend declaration always refer to an  existing  ID  declaration  which
   have been defined in included SLS modules.

   Occurs only in the top level and defines a dictionary.

   States cannot be extended more than once in a single state run.

   Extend  declarations  are useful for adding-to or overriding parts of a
   State declaration that is defined in another SLS file. In the following
   contrived  example,  the  shown  mywebsite.sls file is include -ing and
   extend -ing the apache.sls module in order to add a  watch  declaration
   that  will  restart  Apache  whenever  the  Apache  configuration file,
   mywebsite changes.

      include:
        - apache

      extend:
        apache:
          service:
            - watch:
              - file: mywebsite

      mywebsite:
        file.managed:
          - name: /var/www/mysite

   SEE ALSO:
      watch_in and require_in

      Sometimes it is more convenient to use the  watch_in  or  require_in
      syntax instead of extending another SLS file.

      State Requisites

   State declaration
   A  list which contains one string defining the Function declaration and
   any number of Function arg declaration dictionaries.

   Can, optionally, contain a number of  additional  components  like  the
   name  override  components --- name and names. Can also contain requisite
   declarations.

   Occurs under an ID declaration.

   Requisite declaration
   A list containing requisite references.

   Used to build the action dependency tree. While Salt states are made to
   execute  in  a  deterministic order, this order is managed by requiring
   and watching other Salt states.

   Occurs as a list component under a State declaration or as a key  under
   an ID declaration.

   Requisite reference
   A  single  key  dictionary. The key is the name of the referenced State
   declaration and the value is the ID of the referenced ID declaration.

   Occurs as a single index in a Requisite declaration list.

   Function declaration
   The name of the function to call within the state. A state  declaration
   can contain only a single function declaration.

   For  example,  the  following  state  declaration  calls  the installed
   function in the pkg state module:

      httpd:
        pkg.installed: []

   The function can be declared inline with the state as a shortcut.   The
   actual data structure is compiled to this form:

      httpd:
        pkg:
          - installed

   Where  the  function  is a string in the body of the state declaration.
   Technically when the function is declared in dot notation the  compiler
   converts it to be a string in the state declaration list. Note that the
   use of the first example more than once in an ID declaration is invalid
   yaml.

   INVALID:

      httpd:
        pkg.installed
        service.running

   When passing a function without arguments and another state declaration
   within a single ID declaration, then  the  long  or  "standard"  format
   needs  to  be  used  since otherwise it does not represent a valid data
   structure.

   VALID:

      httpd:
        pkg.installed: []
        service.running: []

   Occurs as the only index in the State declaration list.

   Function arg declaration
   A single key dictionary referencing a Python type which is to be passed
   to  the named Function declaration as a parameter. The type must be the
   data type expected by the function.

   Occurs under a Function declaration.

   For example in the following state declaration user,  group,  and  mode
   are  passed  as  arguments  to  the  managed function in the file state
   module:

      /etc/http/conf/http.conf:
        file.managed:
          - user: root
          - group: root
          - mode: 644

   Name declaration
   Overrides the name argument of a State  declaration.  If  name  is  not
   specified the ID declaration satisfies the name argument.

   The name is always a single key dictionary referencing a string.

   Overriding name is useful for a variety of scenarios.

   For example, avoiding clashing ID declarations. The following two state
   declarations cannot both have /etc/motd as the ID declaration:

      motd_perms:
        file.managed:
          - name: /etc/motd
          - mode: 644

      motd_quote:
        file.append:
          - name: /etc/motd
          - text: "Of all smells, bread; of all tastes, salt."

   Another common reason to override name is if the ID declaration is long
   and  needs to be referenced in multiple places. In the example below it
   is   much   easier   to   specify    mywebsite    than    to    specify
   /etc/apache2/sites-available/mywebsite.com multiple times:

      mywebsite:
        file.managed:
          - name: /etc/apache2/sites-available/mywebsite.com
          - source: salt://mywebsite.com

      a2ensite mywebsite.com:
        cmd.wait:
          - unless: test -L /etc/apache2/sites-enabled/mywebsite.com
          - watch:
            - file: mywebsite

      apache2:
        service.running:
          - watch:
            - file: mywebsite

   Names declaration
   Expands  the contents of the containing State declaration into multiple
   state declarations, each with its own name.

   For example, given the following state declaration:

      python-pkgs:
        pkg.installed:
          - names:
            - python-django
            - python-crypto
            - python-yaml

   Once converted  into  the  lowstate  data  structure  the  above  state
   declaration   will   be   expanded   into  the  following  three  state
   declarations:

      python-django:
        pkg.installed

      python-crypto:
        pkg.installed

      python-yaml:
        pkg.installed

   Other values can be overridden during the  expansion  by  providing  an
   additional dictionary level.

   New in version 2014.7.0.

      ius:
        pkgrepo.managed:
          - humanname: IUS Community Packages for Enterprise Linux 6 - $basearch
          - gpgcheck: 1
          - baseurl: http://mirror.rackspace.com/ius/stable/CentOS/6/$basearch
          - gpgkey: http://dl.iuscommunity.org/pub/ius/IUS-COMMUNITY-GPG-KEY
          - names:
              - ius
              - ius-devel:
                  - baseurl: http://mirror.rackspace.com/ius/development/CentOS/6/$basearch

   Large example
   Here  is  the  layout in yaml using the names of the highdata structure
   components.

      <Include Declaration>:
        - <Module Reference>
        - <Module Reference>

      <Extend Declaration>:
        <ID Declaration>:
          [<overrides>]

      # standard declaration

      <ID Declaration>:
        <State Module>:
          - <Function>
          - <Function Arg>
          - <Function Arg>
          - <Function Arg>
          - <Name>: <name>
          - <Requisite Declaration>:
            - <Requisite Reference>
            - <Requisite Reference>

      # inline function and names

      <ID Declaration>:
        <State Module>.<Function>:
          - <Function Arg>
          - <Function Arg>
          - <Function Arg>
          - <Names>:
            - <name>
            - <name>
            - <name>
          - <Requisite Declaration>:
            - <Requisite Reference>
            - <Requisite Reference>

      # multiple states for single id

      <ID Declaration>:
        <State Module>:
          - <Function>
          - <Function Arg>
          - <Name>: <name>
          - <Requisite Declaration>:
            - <Requisite Reference>
        <State Module>:
          - <Function>
          - <Function Arg>
          - <Names>:
            - <name>
            - <name>
          - <Requisite Declaration>:
            - <Requisite Reference>

   Include and Exclude
   Salt SLS files can include other SLS files and exclude SLS  files  that
   have  been  otherwise  included.  This allows for an SLS file to easily
   extend or manipulate other SLS files.

   Include
   When other SLS files are included, everything defined in  the  included
   SLS  file  will be added to the state run. When including define a list
   of SLS formulas to include:

      include:
        - http
        - libvirt

   The  include  statement  will  include  SLS  formulas  from  the   same
   environment  that  the including SLS formula is in. But the environment
   can be explicitly defined in the configuration to override the  running
   environment,  therefore  if an SLS formula needs to be included from an
   external environment named "dev" the following syntax is used:

      include:
        - dev: http

   NOTE: include does not simply inject the states where you place  it  in
   the  SLS  file.  If  you need to guarantee order of execution, consider
   using requisites.

      Do not use dots in SLS file names or their directories

             The initial implementation of top.sls and include-declaration
             followed the python import model where a slash is represented
             as a period.  This means that a SLS file with a period in the
             name ( besides the suffix period) can not be referenced.  For
             example,  webserver_1.0.sls  is  not  referenceable   because
             webserver_1.0    would    refer    to    the   directory/file
             webserver_1/0.sls

             The same applies for any subdirectories, this  is  especially
             'tricky'  when  git  repos are created.  Another command that
             typically can't render it's output is `state.show_sls`  of  a
             file in a path that contains a dot.

   Relative Include
   In  Salt  0.16.0,  the  capability  to  include  SLS formulas which are
   relative to the running SLS formula  was  added.   Simply  precede  the
   formula name with a .:

      include:
        - .virt
        - .virt.hyper

   In  Salt 2015.8, the ability to include SLS formulas which are relative
   to the parents of the running SLS  formula  was  added.   In  order  to
   achieve this, precede the formula name with more than one . (dot). Much
   like Python's relative import  abilities,  two  or  more  leading  dots
   represent  a  relative  include of the parent or parents of the current
   package, with each .  representing one level after the first.

   The following SLS configuration, if placed within  example.dev.virtual,
   would result in example.http and base being included respectively:

      include:
        - ..http
        - ...base

   Exclude
   The  exclude  statement,  added  in  Salt 0.10.3, allows an SLS to hard
   exclude another SLS file or a specific id. The  component  is  excluded
   after  the  high  data  has been compiled, so nothing should be able to
   override an exclude.

   Since the exclude can remove an id or an sls the type of  component  to
   exclude  needs  to  be defined. An exclude statement that verifies that
   the running highstate does not contain the http sls and the  /etc/vimrc
   id would look like this:

      exclude:
        - sls: http
        - id: /etc/vimrc

   NOTE:
      The  current  state  processing flow checks for duplicate IDs before
      processing excludes. An error occurs if duplicate  IDs  are  present
      even if one of the IDs is targeted by an exclude.

   State System Layers
   The Salt state system is comprised of multiple layers. While using Salt
   does not require  an  understanding  of  the  state  layers,  a  deeper
   understanding  of  how  Salt  compiles  and  manages states can be very
   beneficial.

   Function Call
   The lowest layer of functionality in the state  system  is  the  direct
   state  function  call.  State executions are executions of single state
   functions at the core. These individual functions are defined in  state
   modules and can be called directly via the state.single command.

      salt '*' state.single pkg.installed name='vim'

   Low Chunk
   The  low chunk is the bottom of the Salt state compiler. This is a data
   representation of a single function call. The low chunk is sent to  the
   state caller and used to execute a single state function.

   A single low chunk can be executed manually via the state.low command.

      salt '*' state.low '{name: vim, state: pkg, fun: installed}'

   The  passed  data  reflects  what the state execution system gets after
   compiling the data down from sls formulas.

   Low State
   The Low State layer is the list of low chunks "evaluated" in order.  To
   see what the low state looks like for a highstate, run:

      salt '*' state.show_lowstate

   This  will  display  the raw lowstate in the order which each low chunk
   will be evaluated. The order of evaluation is not necessarily the order
   of  execution,  since  requisites  are  evaluated at runtime. Requisite
   execution and evaluation is  finite;  this  means  that  the  order  of
   execution  can be ascertained with 100% certainty based on the order of
   the low state.

   High Data
   High data is the data structure represented in YAML via SLS files.  The
   High  data structure is created by merging the data components rendered
   inside sls files (or other render systems). The High data can be easily
   viewed   by   executing   the  state.show_highstate  or  state.show_sls
   functions. Since this data is a somewhat complex data structure, it may
   be easier to read using the json, yaml, or pprint outputters:

      salt '*' state.show_highstate --out yaml
      salt '*' state.show_sls edit.vim --out pprint

   SLS
   Above  "High  Data",  the  logical  layers  are  no  longer technically
   required to be executed, or to be executed in a hierarchy.  This  means
   that  how the High data is generated is optional and very flexible. The
   SLS layer allows for many mechanisms to be used to render sls data from
   files  or  to  use the fileserver backend to generate sls and file data
   from external systems.

   The SLS  layer  can  be  called  directly  to  execute  individual  sls
   formulas.

   NOTE:
      SLS  Formulas  have  historically  been  called "SLS files". This is
      because a single SLS was only constituted in a single file. Now  the
      term  "SLS Formula" better expresses how a compartmentalized SLS can
      be expressed in a much more dynamic  way  by  combining  pillar  and
      other sources, and the SLS can be dynamically generated.

   To  call  a  single SLS formula named edit.vim, execute state.apply and
   pass edit.vim as an argument:

      salt '*' state.apply edit.vim

   HighState
   Calling SLS directly logically assigns what states should  be  executed
   from  the context of the calling minion. The Highstate layer is used to
   allow for full contextual assignment of what is executed  where  to  be
   tied  to  groups  of,  or individual, minions entirely from the master.
   This means that  the  environment  of  a  minion,  and  all  associated
   execution  data  pertinent  to  said  minion,  can be assigned from the
   master without needing to execute or configure anything on  the  target
   minion.  This  also  means  that  the minion can independently retrieve
   information about its complete configuration from the master.

   To execute the highstate use state.apply:

      salt '*' state.apply

   Orchestrate
   The orchestrate layer expresses the highest functional layer of  Salt's
   automated   logic  systems.  The  Overstate  allows  for  stateful  and
   functional orchestration of routines from the master.  The  orchestrate
   defines  in  data execution stages which minions should execute states,
   or functions, and in what order using requisite logic.

   The Orchestrate Runner
   NOTE:
      This documentation has been moved here.

   Ordering States
   The way in which configuration management systems  are  executed  is  a
   hotly  debated  topic  in the configuration management world. Two major
   philosophies exist on the subject, to either execute in  an  imperative
   fashion  where  things  are  executed  in  the  order in which they are
   defined, or in a declarative fashion  where  dependencies  need  to  be
   mapped between objects.

   Imperative ordering is finite and generally considered easier to write,
   but declarative  ordering  is  much  more  powerful  and  flexible  but
   generally considered more difficult to create.

   Salt  has  been  created  to  get  the  best of both worlds. States are
   evaluated in a finite order, which guarantees that  states  are  always
   executed  in  the  same  order,  and the states runtime is declarative,
   making Salt fully aware of dependencies via the requisite system.

   State Auto Ordering
   Salt always executes states in a finite manner, meaning that they  will
   always  execute  in  the  same  order  regardless of the system that is
   executing them.  But in Salt 0.17.0, the  state_auto_order  option  was
   added.  This  option  makes  states get evaluated in the order in which
   they are defined in sls files, including the top.sls file.

   The evaluation order makes it easy to know what order the  states  will
   be  executed  in, but it is important to note that the requisite system
   will override the ordering defined in the files, and the  order  option
   described  below  will  also  override  the  order  in which states are
   defined in sls files.

   If  the  classic  ordering  is  preferred  (lexicographic),  then   set
   state_auto_order  to False in the master configuration file. Otherwise,
   state_auto_order defaults to True.

   Requisite Statements
   NOTE:
      The behavior of requisites changed in version 0.9.7 of  Salt.   This
      documentation applies to requisites in version 0.9.7 and later.

   Often  when  setting up states any single action will require or depend
   on another action.  Salt  allows  for  the  building  of  relationships
   between states with requisite statements. A requisite statement ensures
   that the named state is evaluated before the state requiring it.  There
   are  three  types  of requisite statements in Salt, require, watch, and
   prereq.

   These requisite statements are applied to a specific state declaration:

      httpd:
        pkg.installed: []
        file.managed:
          - name: /etc/httpd/conf/httpd.conf
          - source: salt://httpd/httpd.conf
          - require:
            - pkg: httpd

   In this example, the require requisite is used to declare that the file
   /etc/httpd/conf/httpd.conf  should  only  be  set  up  if the pkg state
   executes successfully.

   The requisite system works by finding the states that are required  and
   executing  them  before the state that requires them. Then the required
   states can be evaluated to see if they have executed correctly.

   Require statements can refer to any state defined in  Salt.  The  basic
   examples  are  pkg,  service,  and  file,  but  any  used  state can be
   referenced.

   In addition to state declarations such as pkg,  file,  etc.,  sls  type
   requisites  are  also  recognized,  and essentially allow 'chaining' of
   states. This provides a mechanism to ensure  the  proper  sequence  for
   complex  state  formulas, especially when the discrete states are split
   or groups into separate sls files:

      include:
        - network

      httpd:
        pkg.installed: []
        service.running:
          - require:
            - pkg: httpd
            - sls: network

   In this example, the httpd service running state will  not  be  applied
   (i.e.,  the  httpd  service  will not be started) unless both the httpd
   package is installed AND the network state is satisfied.

   NOTE:
      Requisite matching

      Requisites match on both the ID Declaration and the name  parameter.
      Therefore,  if  using the pkgs or sources argument to install a list
      of packages in a pkg state,  it's  important  to  note  that  it  is
      impossible  to  match  an  individual package in the list, since all
      packages are installed as a single state.

   Multiple Requisites
   The requisite statement is passed as a  list,  allowing  for  the  easy
   addition   of  more  requisites.  Both  requisite  types  can  also  be
   separately declared:

      httpd:
        pkg.installed: []
        service.running:
          - enable: True
          - watch:
            - file: /etc/httpd/conf/httpd.conf
          - require:
            - pkg: httpd
            - user: httpd
            - group: httpd
        file.managed:
          - name: /etc/httpd/conf/httpd.conf
          - source: salt://httpd/httpd.conf
          - require:
            - pkg: httpd
        user.present: []
        group.present: []

   In this example, the httpd service is only going to be started  if  the
   package, user, group, and file are executed successfully.

   Requisite Documentation
   For  detailed  information on each of the individual requisites, please
   look here.

   The Order Option
   Before using the order option, remember  that  the  majority  of  state
   ordering  should  be  done  with  a  requisite-declaration,  and that a
   requisite declaration will override an order option, so  a  state  with
   order option should not require or required by other states.

   The  order  option  is  used  by  adding  an  order  number  to a state
   declaration with the option order:

      vim:
        pkg.installed:
          - order: 1

   By adding the order option to 1 this ensures that the vim package  will
   be  installed  in  tandem  with  any other state declaration set to the
   order 1.

   Any state declared without an order option will be executed  after  all
   states with order options are executed.

   But  this construct can only handle ordering states from the beginning.
   Certain circumstances will present a situation where it is desirable to
   send a state to the end of the line. To do this, set the order to last:

      vim:
        pkg.installed:
          - order: last

   State Providers
   New in version 0.9.8.

   Salt  predetermines what modules should be mapped to what uses based on
   the properties of a system. These determinations are generally made for
   modules that provide things like package and service management.

   Sometimes  in  states, it may be necessary to use an alternative module
   to provide the needed functionality. For instance,  an  very  old  Arch
   Linux  system  may  not  be  running  systemd,  so instead of using the
   systemd service module, you can revert to the default service module:

      httpd:
        service.running:
          - enable: True
          - provider: service

   In  this  instance,   the   basic   service   module   (which   manages
   sysvinit-based  services) will replace the systemd module which is used
   by default on Arch Linux.

   This change only affects this one state though. If it is  necessary  to
   make  this  override  for  most  or every service, it is better to just
   override the provider in the minion config file, as described here.

   Also,  keep  in  mind  that  this  only  works  for  states   with   an
   identically-named virtual module (pkg, service, etc.).

   Arbitrary Module Redirects
   The  provider  statement  can  also  be  used  for more powerful means,
   instead of overwriting or extending  the  module  used  for  the  named
   service   an   arbitrary   module   can  be  used  to  provide  certain
   functionality.

      emacs:
        pkg.installed:
          - provider:
            - cmd: customcmd

   In this example, the state is being instructed to use a  custom  module
   to invoke commands.

   Arbitrary  module  redirects  can  be  used  to dramatically change the
   behavior of a given state.

   Requisites and Other Global State Arguments
   Requisites
   The Salt requisite system  is  used  to  create  relationships  between
   states.  The  core idea being that, when one state is dependent somehow
   on  another,  that  inter-dependency  can  be  easily  defined.   These
   dependencies  are  expressed by declaring the relationships using state
   names and ID's or names.  The generalized form of a requisite target is
   <state  name>  :  <ID  or  name>.   The  specific  form is defined as a
   Requisite Reference

   Requisites come in two types: Direct requisites (such as require),  and
   requisite_ins  (such as require_in). The relationships are directional:
   a direct requisite requires something from another state.   However,  a
   requisite_in  inserts  a  requisite into the targeted state pointing to
   the targeting  state.  The  following  example  demonstrates  a  direct
   requisite:

      vim:
        pkg.installed: []

      /etc/vimrc:
        file.managed:
          - source: salt://edit/vimrc
          - require:
            - pkg: vim

   In the example above, the file /etc/vimrc depends on the vim package.

   Requisite_in  statements  are the opposite. Instead of saying "I depend
   on something", requisite_ins say "Someone depends on me":

      vim:
        pkg.installed:
          - require_in:
            - file: /etc/vimrc

      /etc/vimrc:
        file.managed:
          - source: salt://edit/vimrc

   So here, with a requisite_in, the same thing is accomplished as in  the
   first  example,  but  the  other  way around. The vim package is saying
   "/etc/vimrc depends on  me".  This  will  result  in  a  require  being
   inserted into the /etc/vimrc state which targets the vim state.

   In  the  end,  a  single  dependency  map  is created and everything is
   executed in a finite and predictable order.

   Requisite matching
   Requisites need two pieces  of  information  for  matching:  The  state
   module name -- e.g. pkg --, and the identifier -- e.g. vim --, which can be
   either the ID (the first line in the stanza) or the - name parameter.

      - require:
        - pkg: vim

   Omitting state module in requisites
   New in version 2016.3.0.

   In version 2016.3.0, the state module name was made  optional.  If  the
   state  module  is omitted, all states matching the ID will be required,
   regardless of which module they are using.

      - require:
        - vim

   State target matching
   In order to understand how state targets are matched, it is helpful  to
   know how the state compiler is working. Consider the following example:

      Deploy server package:
        file.managed:
          - name: /usr/local/share/myapp.tar.xz
          - source: salt://myapp.tar.xz

      Extract server package:
        archive.extracted:
          - name: /usr/local/share/myapp
          - source: /usr/local/share/myapp.tar.xz
          - archive_format: tar
          - onchanges:
            - file: Deploy server package

   The  first  formula is converted to a dictionary which looks as follows
   (represented as YAML, some properties omitted for simplicity)  as  High
   Data:

      Deploy server package:
        file:
          - managed
          - name: /usr/local/share/myapp.tar.xz
          - source: salt://myapp.tar.xz

   The  file.managed  format  used in the formula is essentially syntactic
   sugar: at the end, the target is file, which is  used  in  the  Extract
   server package state above.

   Identifier matching
   Requisites  match  on  both  the ID Declaration and the name parameter.
   This means that, in  the  "Deploy  server  package"  example  above,  a
   require  requisite  would  match  with  with  Deploy  server package or
   /usr/local/share/myapp.tar.xz, so either of the following versions  for
   "Extract server package" works:

      # (Archive arguments omitted for simplicity)

      # Match by ID declaration
      Extract server package:
        archive.extracted:
          - onchanges:
            - file: Deploy server package

      # Match by name parameter
      Extract server package:
        archive.extracted:
          - onchanges:
            - file: /usr/local/share/myapp.tar.xz

   Direct Requisite and Requisite_in types
   There are several direct requisite statements that can be used in Salt:

   * require

   * watch

   * prereq

   * use

   * onchanges

   * onfail

   Each direct requisite also has a corresponding requisite_in:

   * require_in

   * watch_in

   * prereq_in

   * use_in

   * onchanges_in

   * onfail_in

   All  of  the  requisites  define specific relationships and always work
   with the dependency logic defined above.

   require
   The use of require demands that the required state executes before  the
   dependent  state. The state containing the require requisite is defined
   as the dependent state. The state specified in the require statement is
   defined  as  the  required  state.  If  the  required state's execution
   succeeds, the dependent  state  will  then  execute.  If  the  required
   state's  execution  fails, the dependent state will not execute. In the
   first example above, the file /etc/vimrc will only  execute  after  the
   vim package is installed successfully.

   Require an Entire SLS File
   As  of  Salt  0.16.0,  it is possible to require an entire sls file. Do
   this first by including the sls  file  and  then  setting  a  state  to
   require the included sls file:

      include:
        - foo

      bar:
        pkg.installed:
          - require:
            - sls: foo

   This  will  add  all  of  the state declarations found in the given sls
   file. This means that every state in sls foo  will  be  required.  This
   makes  it  very  easy  to  batch  large  groups of states easily in any
   requisite statement.

   watch
   watch statements are used to add additional  behavior  when  there  are
   changes in other states.

   NOTE:
      If  a  state should only execute when another state has changes, and
      otherwise do nothing, the new onchanges  requisite  should  be  used
      instead  of watch. watch is designed to add additional behavior when
      there are changes, but otherwise the state executes normally.

   The state containing the watch requisite is  defined  as  the  watching
   state.  The  state  specified  in the watch statement is defined as the
   watched state. When the  watched  state  executes,  it  will  return  a
   dictionary  containing  a key named "changes". Here are two examples of
   state return dictionaries, shown in json for clarity:

      {
          "local": {
              "file_|-/tmp/foo_|-/tmp/foo_|-directory": {
                  "comment": "Directory /tmp/foo updated",
                  "__run_num__": 0,
                  "changes": {
                      "user": "bar"
                  },
                  "name": "/tmp/foo",
                  "result": true
              }
          }
      }

      {
          "local": {
              "pkgrepo_|-salt-minion_|-salt-minion_|-managed": {
                  "comment": "Package repo 'salt-minion' already configured",
                  "__run_num__": 0,
                  "changes": {},
                  "name": "salt-minion",
                  "result": true
              }
          }
      }

   If the "result" of the watched state is True, the watching  state  will
   execute  normally,  and  if  it is False, the watching state will never
   run.  This part of watch  mirrors  the  functionality  of  the  require
   requisite.

   If  the  "result"  of  the  watched state is True and the "changes" key
   contains a  populated  dictionary  (changes  occurred  in  the  watched
   state),  then  the  watch  requisite  can add additional behavior. This
   additional behavior is defined by the  mod_watch  function  within  the
   watching state module. If the mod_watch function exists in the watching
   state module, it will be called in  addition  to  the  normal  watching
   state.  The  return  data  from  the mod_watch function is what will be
   returned to the master in this case; the  return  data  from  the  main
   watching function is discarded.

   If  the "changes" key contains an empty dictionary, the watch requisite
   acts exactly like  the  require  requisite  (the  watching  state  will
   execute  if  "result"  is  True,  and  fail if "result" is False in the
   watched state).

   NOTE:
      Not all state modules contain mod_watch. If mod_watch is absent from
      the  watching state module, the watch requisite behaves exactly like
      a require requisite.

   A good example of using watch is with a service.running state.  When  a
   service  watches  a  state, then the service is reloaded/restarted when
   the watched state changes,  in  addition  to  Salt  ensuring  that  the
   service is running.

      ntpd:
        service.running:
          - watch:
            - file: /etc/ntp.conf
        file.managed:
          - name: /etc/ntp.conf
          - source: salt://ntp/files/ntp.conf

   prereq
   New in version 0.16.0.

   prereq  allows for actions to be taken based on the expected results of
   a state that has not yet been executed. The state containing the prereq
   requisite is defined as the pre-requiring state. The state specified in
   the prereq statement is defined as the pre-required state.

   When a prereq requisite is evaluated, the pre-required state reports if
   it   expects  to  have  any  changes.  It  does  this  by  running  the
   pre-required single state as a test-run  by  enabling  test=True.  This
   test-run  will  return  a  dictionary containing a key named "changes".
   (See the watch section above for examples of "changes" dictionaries.)

   If the "changes" key contains a populated dictionary, it means that the
   pre-required  state expects changes to occur when the state is actually
   executed, as opposed to the test-run. The pre-requiring state will  now
   actually  run.  If  the  pre-requiring state executes successfully, the
   pre-required state will then execute. If the pre-requiring state fails,
   the pre-required state will not execute.

   If  the  "changes"  key  contains  an empty dictionary, this means that
   changes are  not  expected  by  the  pre-required  state.  Neither  the
   pre-required state nor the pre-requiring state will run.

   The  best  way  to  define  how  prereq  operates  is  displayed in the
   following practical example: When a service should be shut down because
   underlying  code  is  going  to  change, the service should be off-line
   while  the  update  occurs.  In  this  example,  graceful-down  is  the
   pre-requiring state and site-code is the pre-required state.

      graceful-down:
        cmd.run:
          - name: service apache graceful
          - prereq:
            - file: site-code

      site-code:
        file.recurse:
          - name: /opt/site_code
          - source: salt://site/code

   In  this  case the apache server will only be shutdown if the site-code
   state expects to deploy fresh  code  via  the  file.recurse  call.  The
   site-code  deployment  will  only  be executed if the graceful-down run
   completes successfully.

   onfail
   New in version 2014.7.0.

   The onfail requisite allows for  reactions  to  happen  strictly  as  a
   response  to the failure of another state. This can be used in a number
   of ways, such as executing a second attempt to  set  up  a  service  or
   begin to execute a separate thread of states because of a failure.

   The onfail requisite is applied in the same way as require as watch:

      primary_mount:
        mount.mounted:
          - name: /mnt/share
          - device: 10.0.0.45:/share
          - fstype: nfs

      backup_mount:
        mount.mounted:
          - name: /mnt/share
          - device: 192.168.40.34:/share
          - fstype: nfs
          - onfail:
            - mount: primary_mount

   NOTE:
      Beginning in the 2016.11.0 release of Salt, onfail uses OR logic for
      multiple listed onfail requisites. Prior to the  2016.11.0  release,
      onfail used AND logic. See Issue #22370 for more information.

   onchanges
   New in version 2014.7.0.

   The onchanges requisite makes a state only apply if the required states
   generate changes, and if the watched state's "result" is True. This can
   be  a  useful  way  to  execute a post hook after changing aspects of a
   system.

   If a state has  multiple  onchanges  requisites  then  the  state  will
   trigger if any of the watched states changes.

   NOTE:
      One  easy-to-make  mistake  is to use onchanges_in when onchanges is
      supposed to be used. For example, the  below  configuration  is  not
      correct:

          myservice:
            pkg.installed:
              - name: myservice
            file.managed:
              - name: /etc/myservice/myservice.conf
              - source: salt://myservice/files/myservice.conf
              - mode: 600
            cmd.run:
              - name: /usr/libexec/myservice/post-changes-hook.sh
              - onchanges_in:
                - file: /etc/myservice/myservice.conf

      This will set up a requisite relationship in which the cmd.run state
      always executes, and the file.managed state  only  executes  if  the
      cmd.run  state  has changes (which it always will, since the cmd.run
      state includes the command results as changes).

      It may semantically seem like the the cmd.run state should only  run
      when  there  are  changes  in  the  file  state,  but  remember that
      requisite relationships involve one state  watching  another  state,
      and  a requisite_in does the opposite: it forces the specified state
      to watch the state with the requisite_in.

      The correct usage would be:

          myservice:
            pkg.installed:
              - name: myservice
            file.managed:
              - name: /etc/myservice/myservice.conf
              - source: salt://myservice/files/myservice.conf
              - mode: 600
            cmd.run:
              - name: /usr/libexec/myservice/post-changes-hook.sh
              - onchanges:
                - file: /etc/myservice/myservice.conf

   use
   The use requisite is used to inherit the arguments passed in another id
   declaration.  This  is  useful  when  many  files need to have the same
   defaults.

      /etc/foo.conf:
        file.managed:
          - source: salt://foo.conf
          - template: jinja
          - mkdirs: True
          - user: apache
          - group: apache
          - mode: 755

      /etc/bar.conf
        file.managed:
          - source: salt://bar.conf
          - use:
            - file: /etc/foo.conf

   The use statement was developed primarily for the networking states but
   can  be used on any states in Salt. This makes sense for the networking
   state because it can define a long list of  options  that  need  to  be
   applied to multiple network interfaces.

   The  use  statement  does  not  inherit the requisites arguments of the
   targeted state. This means also a chain of  use  requisites  would  not
   inherit inherited options.

   The _in versions of requisites
   All  of  the  requisites also have corresponding requisite_in versions,
   which do the reverse of their normal counterparts. The  examples  below
   all  use  require_in  as  the  example,  but  note  that all of the _in
   requisites work the same way: They result in a normal requisite in  the
   targeted   state,  which  targets  the  state  which  has  defines  the
   requisite_in. Thus, a require_in causes the target state to require the
   targeting state. Similarly, a watch_in causes the target state to watch
   the targeting state.  This  pattern  continues  for  the  rest  of  the
   requisites.

   If   a  state  declaration  needs  to  be  required  by  another  state
   declaration then require_in can accommodate it.  Therefore,  these  two
   sls files would be the same in the end:

   Using require

      httpd:
        pkg.installed: []
        service.running:
          - require:
            - pkg: httpd

   Using require_in

      httpd:
        pkg.installed:
          - require_in:
            - service: httpd
        service.running: []

   The  require_in  statement  is  particularly  useful  when  assigning a
   require in a separate sls file. For instance it may be common for httpd
   to  require  components  used to set up PHP or mod_python, but the HTTP
   state does not need to be  aware  of  the  additional  components  that
   require it when it is set up:

   http.sls

      httpd:
        pkg.installed: []
        service.running:
          - require:
            - pkg: httpd

   php.sls

      include:
        - http

      php:
        pkg.installed:
          - require_in:
            - service: httpd

   mod_python.sls

      include:
        - http

      mod_python:
        pkg.installed:
          - require_in:
            - service: httpd

   Now  the  httpd  server  will only start if php or mod_python are first
   verified to be installed. Thus allowing for a requisite to  be  defined
   "after the fact".

   Fire Event Notifications
   New in version 2015.8.0.

   The fire_event option in a state will cause the minion to send an event
   to the Salt Master upon completion of that individual state.

   The following example will cause the minion to send  an  event  to  the
   Salt           Master          with          a          tag          of
   salt/state_result/20150505121517276431/dasalt/nano and  the  result  of
   the  state will be the data field of the event. Notice that the name of
   the state gets added to the tag.

      nano_stuff:
        pkg.installed:
          - name: nano
          - fire_event: True

   In the  following  example  instead  of  setting  fire_event  to  True,
   fire_event is set to an arbitrary string, which will cause the event to
   be             sent             with             this              tag:
   salt/state_result/20150505121725642845/dasalt/custom/tag/nano/finished

      nano_stuff:
        pkg.installed:
          - name: nano
          - fire_event: custom/tag/nano/finished

   Altering States
   The  state  altering  system  is  used  to  make  sure  that states are
   evaluated exactly as the user expects. It can be used to  double  check
   that  a state preformed exactly how it was expected to, or to make 100%
   sure that a state only runs under certain conditions. The use of unless
   or  onlyif  options  help make states even more stateful. The check_cmd
   option helps ensure that the result of a state is evaluated correctly.

   Reload
   reload_modules is a boolean option  that  forces  salt  to  reload  its
   modules  after  a  state  finishes. reload_pillar and reload_grains can
   also be set.  See Reloading Modules.

   Unless
   New in version 2014.7.0.

   The unless requisite specifies that a state should only run when any of
   the  specified  commands return False. The unless requisite operates as
   NAND and is useful in giving more granular control over  when  a  state
   should execute.

   NOTE:  Under  the hood unless calls cmd.retcode with python_shell=True.
   This means the commands referenced by unless will be parsed by a shell,
   so  beware  of  side-effects  as  this  shell will be run with the same
   privileges as the salt-minion. Also be aware that the boolean value  is
   determined  by  the  shell's  concept  of  True  and False, rather than
   Python's concept of True and False.

      vim:
        pkg.installed:
          - unless:
            - rpm -q vim-enhanced
            - ls /usr/bin/vim

   In  the  example  above,  the  state  will  only  run  if  either   the
   vim-enhanced   package   is   not   installed  (returns  False)  or  if
   /usr/bin/vim does not exist (returns False). The state will run if both
   commands return False.

   However, the state will not run if both commands return True.

   Unless checks are resolved for each name to which they are associated.

   For example:

      deploy_app:
        cmd.run:
          - names:
            - first_deploy_cmd
            - second_deploy_cmd
          - unless: ls /usr/bin/vim

   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.

   Onlyif
   New in version 2014.7.0.

   The onlyif requisite specifies that if each command  listed  in  onlyif
   returns  True,  then the state is run. If any of the specified commands
   return False, the state will not run.

   NOTE: Under the hood onlyif calls cmd.retcode  with  python_shell=True.
   This means the commands referenced by onlyif will be parsed by a shell,
   so beware of side-effects as this shell  will  be  run  with  the  same
   privileges  as the salt-minion. Also be aware that the boolean value is
   determined by the shell's  concept  of  True  and  False,  rather  than
   Python's concept of True and False.

      stop-volume:
        module.run:
          - name: glusterfs.stop_volume
          - m_name: work
          - onlyif:
            - gluster volume status work
          - order: 1

      remove-volume:
        module.run:
          - name: glusterfs.delete
          - m_name: work
          - onlyif:
            - gluster volume info work
          - watch:
            - cmd: stop-volume

   The  above example ensures that the stop_volume and delete modules only
   run if the gluster commands return a 0 ret value.

   Listen/Listen_in
   New in version 2014.7.0.

   listen and its counterpart listen_in  trigger  mod_wait  functions  for
   states, when those states succeed and result in changes, similar to how
   watch its counterpart watch_in. Unlike watch and watch_in, listen,  and
   listen_in will not modify the order of states and can be used to ensure
   your  states  are  executed  in  the  order  they  are   defined.   All
   listen/listen_in  actions  will  occur at the end of a state run, after
   all states have completed.

      restart-apache2:
        service.running:
          - name: apache2
          - listen:
            - file: /etc/apache2/apache2.conf

      configure-apache2:
        file.managed:
          - name: /etc/apache2/apache2.conf
          - source: salt://apache2/apache2.conf

   This example will cause apache2 to be restarted when  the  apache2.conf
   file  is changed, but the apache2 restart will happen at the end of the
   state run.

      restart-apache2:
        service.running:
          - name: apache2

      configure-apache2:
        file.managed:
          - name: /etc/apache2/apache2.conf
          - source: salt://apache2/apache2.conf
          - listen_in:
            - service: apache2

   This example does the same as the above example,  but  puts  the  state
   argument on the file resource, rather than the service resource.

   check_cmd
   New in version 2014.7.0.

   Check  Command  is used for determining that a state did or did not run
   as expected.

   NOTE:   Under   the   hood    check_cmd    calls    cmd.retcode    with
   python_shell=True. This means the commands referenced by unless will be
   parsed by a shell, so beware of side-effects as this shell will be  run
   with the same privileges as the salt-minion.

      comment-repo:
        file.replace:
          - name: /etc/yum.repos.d/fedora.repo
          - pattern: ^enabled=0
          - repl: enabled=1
          - check_cmd:
            - ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo

   This  will  attempt to do a replace on all enabled=0 in the .repo file,
   and replace them with enabled=1. The check_cmd is just a bash  command.
   It  will  do  a grep for enabled=0 in the file, and if it finds any, it
   will return a 0, which will be  inverted  by  the  leading  !,  causing
   check_cmd  to  set  the  state as failed. If it returns a 1, meaning it
   didn't find any enabled=0, it  will  be  inverted  by  the  leading  !,
   returning a 0, and declaring the function succeeded.

   NOTE: This requisite check_cmd functions differently than the check_cmd
   of the file.managed state.

   Overriding Checks
   There are two commands used for the above checks.

   mod_run_check is used to check for onlyif and unless. If the goal is to
   override   the   global   check  for  these  to  variables,  include  a
   mod_run_check in the salt/states/ file.

   mod_run_check_cmd is used  to  check  for  the  check_cmd  options.  To
   override  this  one, include a mod_run_check_cmd in the states file for
   the state.

   Startup States
   Sometimes it may be desired that the salt minion execute  a  state  run
   when it is started. This alleviates the need for the master to initiate
   a state run on a new minion and can make provisioning much easier.

   As of Salt 0.10.3 the minion config reads options that allow for states
   to  be  executed  at startup. The options are startup_states, sls_list,
   and top_file.

   The startup_states option can be passed one of a number of arguments to
   define how to execute states. The available options are:

   highstate
          Execute state.apply

   sls    Read in the sls_list option and execute the named sls files

   top    Read in the top_file option and execute states based on that top
          file on the Salt Master

   Examples:
   Execute state.apply to run the highstate when starting the minion:

      startup_states: highstate

   Execute the sls files edit.vim and hyper:

      startup_states: sls

      sls_list:
        - edit.vim
        - hyper

   State Testing
   Executing a Salt state run can potentially change  many  aspects  of  a
   system  and  it may be desirable to first see what a state run is going
   to change before applying the run.

   Salt has a test interface to report on exactly what  will  be  changed,
   this interface can be invoked on any of the major state run functions:

      salt '*' state.apply test=True
      salt '*' state.apply mysls test=True
      salt '*' state.single test=True

   The  test run is mandated by adding the test=True option to the states.
   The return information will show states that will be applied in  yellow
   and the result is reported as None.

   Default Test
   If  the value test is set to True in the minion configuration file then
   states will default to being executed in test mode. If  this  value  is
   set then states can still be run by calling test=False:

      salt '*' state.apply test=False
      salt '*' state.apply mysls test=False
      salt '*' state.single test=False

   The Top File
   Introduction
   Most infrastructures are made up of groups of machines, each machine in
   the group performing a role similar to others. Those groups of machines
   work in concert with each other to create an application stack.

   To  effectively manage those groups of machines, an administrator needs
   to be able to create roles for those groups. For example,  a  group  of
   machines  that  serve  front-end  web  traffic  might  have roles which
   indicate that those machines  should  all  have  the  Apache  webserver
   package installed and that the Apache service should always be running.

   In  Salt,  the file which contains a mapping between groups of machines
   on a network and the configuration roles that should be applied to them
   is called a top file.

   Top  files  are  named top.sls by default and they are so-named because
   they always exist in the "top" of a directory hierarchy  that  contains
   state files.  That directory hierarchy is called a state tree.

   A Basic Example
   Top files have three components:

   * Environment:  A  state tree directory containing a set of state files
     to configure systems.

   * Target: A grouping of machines  which  will  have  a  set  of  states
     applied to them.

   * State  files:  A list of state files to apply to a target. Each state
     file describes one or more states to be configured  and  enforced  on
     the targeted machines.

   The relationship between these three components is nested as follows:

   * Environments contain targets

   * Targets contain states

   Putting  these  concepts  together, we can describe a scenario in which
   all minions with an ID that  begins  with  web  have  an  apache  state
   applied to them:

      base:          # Apply SLS files from the directory root for the 'base' environment
        'web*':      # All minions with a minion_id that begins with 'web'
          - apache   # Apply the state file named 'apache.sls'

   Environments
   Environments  are directory hierarchies which contain a top files and a
   set of state files.

   Environments can be used in many ways, however there is no  requirement
   that  they  be used at all. In fact, the most common way to deploy Salt
   is with a single environment, called base. It is recommended that users
   only  create  multiple  environments  if  they  have  a  use case which
   specifically calls for multiple versions of state trees.

   Getting Started with Top Files
   Each environment is defined inside a salt master configuration variable
   called, file_roots .

   In  the most common single-environment setup, only the base environment
   is defined in file_roots along with only one  directory  path  for  the
   state tree.

      file_roots:
        base:
          - /srv/salt

   In  the above example, the top file will only have a single environment
   to pull from.

   Next   is   a   simple   single-environment   top   file   placed    in
   /srv/salt/top.sls,  illustrating  that for the environment called base,
   all minions will have the  state  files  named  core.sls  and  edit.sls
   applied to them.

      base:
        '*':
          - core
          - edit

   Assuming the file_roots configuration from above, Salt will look in the
   /srv/salt directory for core.sls and edit.sls.

   Multiple Environments
   In some cases, teams may wish to create versioned state trees which can
   be used to test Salt configurations in isolated sets of systems such as
   a staging environment before deploying states into production.

   For this case, multiple environments can be  used  to  accomplish  this
   task.

   To create multiple environments, the file_roots option can be expanded:

      file_roots:
        dev:
          - /srv/salt/dev
        qa:
          - /srv/salt/qa
        prod:
          - /srv/salt/prod

   In  the  above,  we declare three environments: dev, qa and prod.  Each
   environment has a single directory assigned to it.

   Our top file references the environments:

      dev:
        'webserver*':
          - webserver
        'db*':
          - db
      qa:
        'webserver*':
          - webserver
        'db*':
          - db
      prod:
        'webserver*':
          - webserver
        'db*':
          - db

   As seen above, the top file now declares the three environments and for
   each,  targets  are  defined to map globs of minion IDs to state files.
   For example, all minions which have an ID  beginning  with  the  string
   webserver  will have the webserver state from the requested environment
   assigned to it.

   In this manner, a proposed change to a state could first be made  in  a
   state  file  in  /srv/salt/dev  and  then  be  applied  to  development
   webservers before moving the state into QA by copying  the  state  file
   into /srv/salt/qa.

   Choosing an Environment to Target
   The  top  file  is  used  to  assign  a minion to an environment unless
   overridden using the methods described below. The  environment  in  the
   top  file  must  match valid fileserver environment (a.k.a. saltenv) in
   order for any states to be applied  to  that  minion.  When  using  the
   default fileserver backend, environments are defined in file_roots.

   The  states that will be applied to a minion in a given environment can
   be viewed using the state.show_top function.

   Minions may be pinned  to  a  particular  environment  by  setting  the
   environment  value  in  the  minion  configuration file. In doing so, a
   minion will only request files from the  environment  to  which  it  is
   assigned.

   The  environment may also be dynamically selected at runtime by passing
   it to the salt, salt-call or salt-ssh command. This  is  most  commonly
   done  with functions in the state module by using the saltenv argument.
   For example, to run a highstate on all minions, using only the top file
   and  SLS  files  in the prod environment, run: salt '*' state.highstate
   saltenv=prod.

   NOTE:
      Not  all  functions  accept  saltenv  as  an   argument,   see   the
      documentation for an individual function documentation to verify.

   Shorthand
   If you assign only one SLS to a system, as in this example, a shorthand
   is also available:

      base:
        '*': global
      dev:
        'webserver*': webserver
        'db*':        db
      qa:
        'webserver*': webserver
        'db*':        db
      prod:
        'webserver*': webserver
        'db*':        db

   Advanced Minion Targeting
   In addition to globs, minions can be specified in top files a few other
   ways. Some common ones are compound matches and node groups.

   Below  is  a  slightly  more  complex  top  file  example,  showing the
   different types of matches you can perform:

      # All files will be taken from the file path specified in the base
      # environment in the ``file_roots`` configuration value.

      base:
          # All minions get the following three state files applied

          '*':
              - ldap-client
              - networking
              - salt.minion

          # All minions which have an ID that begins with the phrase
          # 'salt-master' will have an SLS file applied that is named
          # 'master.sls' and is in the 'salt' directory, underneath
          # the root specified in the ``base`` environment in the
          # configuration value for ``file_roots``.

          'salt-master*':
              - salt.master

          # Minions that have an ID matching the following regular
          # expression will have the state file called 'web.sls' in the
          # nagios/mon directory applied. Additionally, minions matching
          # the regular expression will also have the 'server.sls' file
          # in the apache/ directory applied.

          # NOTE!
          #
          # Take note of the 'match' directive here, which tells Salt
          # to treat the target string as a regex to be matched!

          '^(memcache|web).(qa|prod).loc$':
              - match: pcre
              - nagios.mon.web
              - apache.server

          # Minions that have a grain set indicating that they are running
          # the Ubuntu operating system will have the state file called
          # 'ubuntu.sls' in the 'repos' directory applied.
          #
          # Again take note of the 'match' directive here which tells
          # Salt to match against a grain instead of a minion ID.

          'os:Ubuntu':
              - match: grain
              - repos.ubuntu

          # Minions that are either RedHat or CentOS should have the 'epel.sls'
          # state applied, from the 'repos/' directory.

          'os:(RedHat|CentOS)':
              - match: grain_pcre
              - repos.epel

          # The three minions with the IDs of 'foo', 'bar' and 'baz' should
          # have 'database.sls' applied.

          'foo,bar,baz':
              - match: list
              - database

          # Any minion for which the pillar key 'somekey' is set and has a value
          # of that key matching 'abc' will have the 'xyz.sls' state applied.

          'somekey:abc':
              - match: pillar
              - xyz

          # All minions which begin with the strings 'nag1' or any minion with
          # a grain set called 'role' with the value of 'monitoring' will have
          # the 'server.sls' state file applied from the 'nagios/' directory.

          'nag1* or G@role:monitoring':
              - match: compound
              - nagios.server

   How Top Files Are Compiled
   When a highstate is executed and an environment  is  specified  (either
   using  the  environment  config  option  or by passing the saltenv when
   executing the highstate), then that environment's top file is the  only
   top  file  used  to  assign states to minions, and only states from the
   specified environment will be run.

   The remainder of this section applies to cases in which a highstate  is
   executed without an environment specified.

   With  no  environment specified, the minion will look for a top file in
   each environment, and each top file will be processed to determine  the
   SLS  files  to  run on the minions. By default, the top files from each
   environment will  be  merged  together.  In  configurations  with  many
   environments,  such  as with GitFS where each branch and tag is treated
   as a distinct environment, this may cause  unexpected  results  as  SLS
   files  from  older  tags  cause defunct SLS files to be included in the
   highstate.  In  cases  like  this,   it   can   be   helpful   to   set
   top_file_merging_strategy  to same to force each environment to use its
   own top file.

      top_file_merging_strategy: same

   Another  option  would  be  to  set  state_top_saltenv  to  a  specific
   environment,  to  ensure  that  any top files in other environments are
   disregarded:

      state_top_saltenv: base

   With GitFS, it can also be helpful to simply manage each  environment's
   top  file  separately,  and/or  manually  specify  the environment when
   executing the highstate to avoid  any  complicated  merging  scenarios.
   gitfs_env_whitelist  and  gitfs_env_blacklist  can also be used to hide
   unneeded branches and tags from GitFS to reduce the number of top files
   in play.

   When  using  multiple environments, it is not necessary to create a top
   file for each environment. The easiest-to-maintain approach is to use a
   single  top  file  placed  in  the  base  environment.  This  is  often
   infeasible with GitFS though, since branching/tagging can easily result
   in  extra  top files. However, when only the default (roots) fileserver
   backend is used, a single top file in the base environment is the  most
   common way of configuring a highstate.

   The  following  minion  configuration  options affect how top files are
   compiled when no environment is specified, it is recommended to  follow
   the below four links to learn more about how these options work:

   * state_top_saltenv

   * top_file_merging_strategy

   * env_order

   * default_top

   Top File Compilation Examples
   For the scenarios below, assume the following configuration:

   /etc/salt/master:

      file_roots:
        base:
          - /srv/salt/base
        dev:
          - /srv/salt/dev
        qa:
          - /srv/salt/qa

   /srv/salt/base/top.sls:

      base:
        '*':
          - base1
      dev:
        '*':
          - dev1
      qa:
        '*':
          - qa1

   /srv/salt/dev/top.sls:

      base:
        'minion1':
          - base2
      dev:
        'minion2':
          - dev2
      qa:
        '*':
          - qa1
          - qa2

   NOTE:
      For  the  purposes of these examples, there is no top file in the qa
      environment.

   Scenario 1 - dev Environment Specified
   In this scenario, the highstate was either invoked with saltenv=dev  or
   the  minion  has  environment:  dev  set in the minion config file. The
   result will be that only the dev2 SLS from the dev environment will  be
   part of the highstate, and it will be applied to minion2, while minion1
   will have no states applied to it.

   If the base environment were specified, the result would be  that  only
   the base1 SLS from the base environment would be part of the highstate,
   and it would be applied to all minions.

   If the qa environment were specified, the highstate would exit with  an
   error.

   Scenario 2 - No Environment Specified, top_file_merging_strategy is merge
   In  this  scenario,  assuming  that the base environment's top file was
   evaluated first, the base1, dev1, and qa1 states would  be  applied  to
   all  minions.  If,  for  instance, the qa environment is not defined in
   /srv/salt/base/top.sls, then because there is no top file  for  the  qa
   environment, no states from the qa environment would be applied.

   Scenario 3 - No Environment Specified, top_file_merging_strategy is same
   Changed  in  version 2016.11.0: In prior versions, "same" did not quite
   work as described below (see here). This has now been corrected. It was
   decided  that  changing  something  like  top  file handling in a point
   release had the potential to unexpectedly impact users' top  files  too
   much,  and  it  would  be  better  to make this correction in a feature
   release.

   In this scenario, base1 from the base environment  is  applied  to  all
   minions.  Additionally,  dev2  from  the  dev environment is applied to
   minion2.

   If default_top is unset (or set  to  base,  which  happens  to  be  the
   default),  then  qa1  from  the  qa  environment will be applied to all
   minions. If default_top were set to dev, then both qa1 and qa2 from the
   qa environment would be applied to all minions.

   Scenario   4  -  No  Environment  Specified,  top_file_merging_strategy  is
   merge_all
   New in version 2016.11.0.

   In this scenario, all configured states in all top files  are  applied.
   From  the base environment, base1 would be applied to all minions, with
   base2 being applied only to minion1. From  the  dev  environment,  dev1
   would  be  applied  to  all  minions,  with  dev2 being applied only to
   minion2.  Finally, from the qa environment, both the qa1 and qa2 states
   will  be  applied to all minions. Note that the qa1 states would not be
   applied twice, even though qa1 appears twice.

   SLS Template Variable Reference
   The template engines available to sls files  and  file  templates  come
   loaded  with  a  number  of  context variables. These variables contain
   information and functions to assist in  the  generation  of  templates.
   See  each  variable below for its availability -- not all variables are
   available in all templating contexts.

   Salt
   The salt variable is available to abstract the salt library  functions.
   This  variable  is  a python dictionary containing all of the functions
   available to the running salt minion.  It  is  available  in  all  salt
   templates.

      {% for file in salt['cmd.run']('ls -1 /opt/to_remove').splitlines() %}
      /opt/to_remove/{{ file }}:
        file.absent
      {% endfor %}

   Opts
   The  opts variable abstracts the contents of the minion's configuration
   file directly to the template. The opts variable is a  dictionary.   It
   is available in all templates.

      {{ opts['cachedir'] }}

   The   config.get   function  also  searches  for  values  in  the  opts
   dictionary.

   Pillar
   The pillar dictionary can be referenced directly, and is  available  in
   all templates:

      {{ pillar['key'] }}

   Using  the  pillar.get  function  via  the  salt  variable is generally
   recommended since a default can be safely set in  the  event  that  the
   value  is  not  available  in  pillar and dictionaries can be traversed
   directly:

      {{ salt['pillar.get']('key', 'failover_value') }}
      {{ salt['pillar.get']('stuff:more:deeper') }}

   Grains
   The grains dictionary makes the minion's grains directly available, and
   is available in all templates:

      {{ grains['os'] }}

   The  grains.get  function can be used to traverse deeper grains and set
   defaults:

      {{ salt['grains.get']('os') }}

   saltenv
   The saltenv variable is available in only in sls files  when  gathering
   the sls from an environment.

      {{ saltenv }}

   sls
   The  sls  variable  contains  the  sls  reference  value,  and  is only
   available in the actual SLS file (not in any files referenced  in  that
   SLS).  The  sls reference value is the value used to include the sls in
   top files or via the include option.

      {{ sls }}

   slspath
   The slspath variable contains the path to the  current  sls  file.  The
   value  of slspath in files referenced in the current sls depends on the
   reference method. For jinja includes slspath is the path to the current
   file. For salt includes slspath is the path to the included file.

      {{ slspath }}

   State Modules
   State  Modules  are  the  components that map to actual enforcement and
   management of Salt states.

   States are Easy to Write!
   State  Modules  should  be  easy  to  write  and  straightforward.  The
   information  passed to the SLS data structures will map directly to the
   states modules.

   Mapping the information from the  SLS  data  is  simple,  this  example
   should illustrate:

      /etc/salt/master: # maps to "name"
        file.managed: # maps to <filename>.<function> - e.g. "managed" in https://github.com/saltstack/salt/tree/develop/salt/states/file.py
          - user: root # one of many options passed to the manage function
          - group: root
          - mode: 644
          - source: salt://salt/master

   Therefore  this  SLS data can be directly linked to a module, function,
   and arguments passed to that function.

   This does issue the  burden,  that  function  names,  state  names  and
   function  arguments should be very human readable inside state modules,
   since they directly define the user interface.

      Keyword Arguments

             Salt passes a number of  keyword  arguments  to  states  when
             rendering   them,   including   the   environment,  a  unique
             identifier for the state, and more.   Additionally,  keep  in
             mind  that the requisites for a state are part of the keyword
             arguments. Therefore, if you  need  to  iterate  through  the
             keyword  arguments  in  a state, these must be considered and
             handled  appropriately.   One  such   example   is   in   the
             pkgrepo.managed  state,  which  needs  to  be  able to handle
             arbitrary keyword arguments and pass them to module execution
             functions.   An example of how these keyword arguments can be
             handled can be found here.

   Using Custom State Modules
   Place your custom state modules inside a _states directory  within  the
   file_roots  specified  by  the  master  config file. These custom state
   modules can then be distributed in  a  number  of  ways.  Custom  state
   modules  are  distributed  when state.apply is run, or by executing the
   saltutil.sync_states or saltutil.sync_all functions.

   Any custom states which have been synced to a minion,  that  are  named
   the same as one of Salt's default set of states, will take the place of
   the default state with the same name. Note that a state's default  name
   is  its filename (i.e. foo.py becomes state foo), but that its name can
   be overridden by using a __virtual__ function.

   Cross Calling Execution Modules from States
   As with Execution Modules, State Modules  can  also  make  use  of  the
   __salt__ and __grains__ data. See cross calling execution modules.

   It  is  important to note that the real work of state management should
   not be done in the state module unless it is needed. A good example  is
   the  pkg  state  module. This module does not do any package management
   work, it just calls the pkg execution module. This makes the pkg  state
   module  completely  generic,  which  is why there is only one pkg state
   module and many backend pkg execution modules.

   On the other hand some modules will require that the logic be placed in
   the state module, a good example of this is the file module. But in the
   vast majority of cases this is  not  the  best  approach,  and  writing
   specific  execution  modules to do the backend work will be the optimal
   solution.

   Cross Calling State Modules
   All of the Salt state modules are available to  each  other  and  state
   modules can call functions available in other state modules.

   The  variable  __states__  is  packed  into  the modules after they are
   loaded into the Salt minion.

   The __states__ variable is a Python dictionary containing  all  of  the
   state  modules.  Dictionary  keys are strings representing the names of
   the modules and the values are the functions themselves.

   Salt state modules can be cross-called by accessing the  value  in  the
   __states__ dict:

      ret = __states__['file.managed'](name='/tmp/myfile', source='salt://myfile')

   This  code  will call the managed function in the file state module and
   pass the arguments name and source to it.

   Return Data
   A State Module must return a dict containing the following keys/values:

   * name: The same value passed to the state as "name".

   * changes: A dict describing  the  changes  made.  Each  thing  changed
     should  be  a key, with its value being another dict with keys called
     "old" and "new" containing the old/new values. For example,  the  pkg
     state's  changes  dict has one key for each package changed, with the
     "old" and "new" keys in its  sub-dict  containing  the  old  and  new
     versions  of  the  package. For example, the final changes dictionary
     for this scenario would look something like this:

        ret['changes'].update({'my_pkg_name': {'old': '',
                                               'new': 'my_pkg_name-1.0'}})

   * result: A tristate value.  True if the action was  successful,  False
     if  it was not, or None if the state was run in test mode, test=True,
     and changes would have been made if the state was  not  run  in  test
     mode.

                 
                                     live mode  test mode 
                 
                 no changes          True       True      
                 
                 successful changes  True       None      
                 
                 failed changes      False      None      
                 

     NOTE:
        Test  mode  does  not predict if the changes will be successful or
        not.

   * comment: A string containing a summary of the result.

   The return data can also, include the pchanges  key,  this  stands  for
   predictive  changes.  The  pchanges  key  informs the State system what
   changes are predicted to occur.

   NOTE:
      States should not return data which cannot  be  serialized  such  as
      frozensets.

   Test State
   All  states  should  check  for  and  support  test being passed in the
   options.  This will return data about what changes would occur  if  the
   state  were  actually  run.  An example of such a check could look like
   this:

      # Return comment of changes if test.
      if __opts__['test']:
          ret['result'] = None
          ret['comment'] = 'State Foo will execute with param {0}'.format(bar)
          return ret

   Make sure to test and return before performing any real actions on  the
   minion.

   NOTE:
      Be sure to refer to the result table listed above and displaying any
      possible changes when writing support for test. Looking for  changes
      in  a  state  is essential to test=true functionality. If a state is
      predicted to have no changes when test=true  (or  test:  true  in  a
      config  file) is used, then the result of the final state should not
      be None.

   Watcher Function
   If the state being written should support the watch  requisite  then  a
   watcher  function  needs to be declared. The watcher function is called
   whenever the watch requisite is invoked and should be  generic  to  the
   behavior of the state itself.

   The  watcher  function should accept all of the options that the normal
   state functions accept  (as  they  will  be  passed  into  the  watcher
   function).

   A watcher function typically is used to execute state specific reactive
   behavior, for instance, the watcher for the service module restarts the
   named  service  and makes it useful for the watcher to make the service
   react to changes in the environment.

   The watcher function also needs to return the same data that  a  normal
   state function returns.

   Mod_init Interface
   Some  states  need  to  execute  something  only once to ensure that an
   environment has been set up, or certain conditions global to the  state
   behavior  can  be  predefined.  This  is  the  realm  of  the  mod_init
   interface.

   A state module can have a function called mod_init which executes  when
   the  first  state  of  this  type is called. This interface was created
   primarily to improve the pkg state. When  packages  are  installed  the
   package  metadata  needs  to  be  refreshed, but refreshing the package
   metadata every time a package is installed is  wasteful.  The  mod_init
   function for the pkg state sets a flag down so that the first, and only
   the first,  package  installation  attempt  will  refresh  the  package
   database  (the  package  database  can  of course be manually called to
   refresh via the refresh option in the pkg state).

   The mod_init function must accept the Low  State  Data  for  the  given
   executing state as an argument. The low state data is a dict and can be
   seen by executing the state.show_lowstate function. Then  the  mod_init
   function  must  return  a  bool.  If the return value is True, then the
   mod_init function will not be executed again, meaning that  the  needed
   behavior  has  been set up. Otherwise, if the mod_init function returns
   False, then the function will be called the next time.

   A good example of the mod_init function  is  found  in  the  pkg  state
   module:

      def mod_init(low):
          '''
          Refresh the package database here so that it only needs to happen once
          '''
          if low['fun'] == 'installed' or low['fun'] == 'latest':
              rtag = __gen_rtag()
              if not os.path.exists(rtag):
                  open(rtag, 'w+').write('')
              return True
          else:
              return False

   The  mod_init  function  in the pkg state accepts the low state data as
   low and then checks to see if the function being  called  is  going  to
   install packages, if the function is not going to install packages then
   there is no need to refresh the  package  database.  Therefore  if  the
   package  database  is  prepared  to  refresh,  then return True and the
   mod_init will not be called the next time a  pkg  state  is  evaluated,
   otherwise  return False and the mod_init will be called next time a pkg
   state is evaluated.

   Log Output
   You can call the logger from custom modules to write  messages  to  the
   minion  logs.  The  following  code  snippet  demonstrates  writing log
   messages:

      import logging

      log = logging.getLogger(__name__)

      log.info('Here is Some Information')
      log.warning('You Should Not Do That')
      log.error('It Is Busted')

   Strings and Unicode
   A state module author should always assume  that  strings  fed  to  the
   module  have  already  decoded  from strings into Unicode. In Python 2,
   these will be of type 'Unicode' and in Python 3 they will  be  of  type
   str.  Calling from a state to other Salt sub-systems, such as execution
   modules should pass Unicode (or bytes if passing binary data).  In  the
   rare event that a state needs to write directly to disk, Unicode should
   be encoded to a string immediately before writing to  disk.  An  author
   may use __salt_system_encoding__ to learn what the encoding type of the
   system is. For example, 'my_string'.encode(__salt_system_encoding__').

   Full State Module Example
   The following is a simplistic  example  of  a  full  state  module  and
   function.  Remember to call out to execution modules to perform all the
   real work. The state module should only perform  "before"  and  "after"
   checks.

   1. Make  a  custom  state module by putting the code into a file at the
      following path: /srv/salt/_states/my_custom_state.py.

   2. Distribute the custom state module to the minions:

         salt '*' saltutil.sync_states

   3. Write a new state to use the custom state  by  making  a  new  state
      file, for instance /srv/salt/my_custom_state.sls.

   4. Add the following SLS configuration to the file created in Step 3:

         human_friendly_state_id:        # An arbitrary state ID declaration.
           my_custom_state:              # The custom state module name.
             - enforce_custom_thing      # The function in the custom state module.
             - name: a_value             # Maps to the ``name`` parameter in the custom function.
             - foo: Foo                  # Specify the required ``foo`` parameter.
             - bar: False                # Override the default value for the ``bar`` parameter.

   Example state module
      import salt.exceptions

      def enforce_custom_thing(name, foo, bar=True):
          '''
          Enforce the state of a custom thing

          This state module does a custom thing. It calls out to the execution module
          ``my_custom_module`` in order to check the current system and perform any
          needed changes.

          name
              The thing to do something to
          foo
              A required argument
          bar : True
              An argument with a default value
          '''
          ret = {
              'name': name,
              'changes': {},
              'result': False,
              'comment': '',
              'pchanges': {},
              }

          # Start with basic error-checking. Do all the passed parameters make sense
          # and agree with each-other?
          if bar == True and foo.startswith('Foo'):
              raise salt.exceptions.SaltInvocationError(
                  'Argument "foo" cannot start with "Foo" if argument "bar" is True.')

          # Check the current state of the system. Does anything need to change?
          current_state = __salt__['my_custom_module.current_state'](name)

          if current_state == foo:
              ret['result'] = True
              ret['comment'] = 'System already in the correct state'
              return ret

          # The state of the system does need to be changed. Check if we're running
          # in ``test=true`` mode.
          if __opts__['test'] == True:
              ret['comment'] = 'The state of "{0}" will be changed.'.format(name)
              ret['pchanges'] = {
                  'old': current_state,
                  'new': 'Description, diff, whatever of the new state',
              }

              # Return ``None`` when running with ``test=true``.
              ret['result'] = None

              return ret

          # Finally, make the actual change and return the result.
          new_state = __salt__['my_custom_module.change_state'](name, foo)

          ret['comment'] = 'The state of "{0}" was changed!'.format(name)

          ret['changes'] = {
              'old': current_state,
              'new': new_state,
          }

          ret['result'] = True

          return ret

   State Management
   State   management,   also  frequently  called  Software  Configuration
   Management (SCM), is a program that puts and  keeps  a  system  into  a
   predetermined  state. It installs software packages, starts or restarts
   services or puts configuration files in  place  and  watches  them  for
   changes.

   Having  a  state  management  system  in place allows one to easily and
   reliably configure and manage a few servers or a few thousand  servers.
   It allows configurations to be kept under version control.

   Salt  States  is  an extension of the Salt Modules that we discussed in
   the previous remote execution  tutorial.  Instead  of  calling  one-off
   executions  the  state  of  a  system  can  be  easily defined and then
   enforced.

   Understanding the Salt State System Components
   The Salt state system is comprised of a  number  of  components.  As  a
   user,  an understanding of the SLS and renderer systems are needed. But
   as a developer, an understanding of Salt states and how  to  write  the
   states is needed as well.

   NOTE:
      States  are  compiled  and  executed  only on minions that have been
      targeted.  To execute functions directly on masters, see runners.

   Salt SLS System
   The primary system used by the Salt state system is the SLS system. SLS
   stands for SaLt State.

   The  Salt  States  are files which contain the information about how to
   configure Salt minions. The states are laid out in a directory tree and
   can be written in many different formats.

   The contents of the files and they way they are laid out is intended to
   be as simple as possible while allowing for  maximum  flexibility.  The
   files  are  laid  out  in states and contains information about how the
   minion needs to be configured.

   SLS File Layout
   SLS files are laid out in the Salt file server.

   A simple layout can look like this:

      top.sls
      ssh.sls
      sshd_config
      users/init.sls
      users/admin.sls
      salt/master.sls
      web/init.sls

   The top.sls file is a key component.  The  top.sls  files  is  used  to
   determine which SLS files should be applied to which minions.

   The  rest of the files with the .sls extension in the above example are
   state files.

   Files without a .sls extensions are seen by the Salt  master  as  files
   that can be downloaded to a Salt minion.

   States  are translated into dot notation. For example, the ssh.sls file
   is seen as the ssh state and the users/admin.sls file is  seen  as  the
   users.admin state.

   Files  named init.sls are translated to be the state name of the parent
   directory, so the web/init.sls file translates to the web state.

   In Salt, everything is a file; there is no "magic translation" of files
   and  file  types.  This  means  that a state file can be distributed to
   minions just like a plain text or binary file.

   SLS Files
   The Salt state files are simple sets of data. Since SLS files are  just
   data they can be represented in a number of different ways.

   The default format is YAML generated from a Jinja template. This allows
   for the states files to have all the language constructs of Python  and
   the simplicity of YAML.

   State files can then be complicated Jinja templates that translate down
   to YAML, or just plain and simple YAML files.

   The State files are simply common data structures such as  dictionaries
   and lists, constructed using a templating language such as YAML.

   Here is an example of a Salt State:

      vim:
        pkg.installed: []

      salt:
        pkg.latest:
          - name: salt
        service.running:
          - names:
            - salt-master
            - salt-minion
          - require:
            - pkg: salt
          - watch:
            - file: /etc/salt/minion

      /etc/salt/minion:
        file.managed:
          - source: salt://salt/minion
          - user: root
          - group: root
          - mode: 644
          - require:
            - pkg: salt

   This  short stanza will ensure that vim is installed, Salt is installed
   and up to date, the salt-master and salt-minion daemons are running and
   the  Salt  minion  configuration  file is in place. It will also ensure
   everything is deployed in the right order and that  the  Salt  services
   are restarted when the watched file updated.

   The Top File
   The  top file controls the mapping between minions and the states which
   should be applied to them.

   The top file specifies  which  minions  should  have  which  SLS  files
   applied and which environments they should draw those SLS files from.

   The top file works by specifying environments on the top-level.

   Each  environment  contains  globs to match minions. Finally, each glob
   contains a list of lists of Salt states to apply to matching minions:

      base:
        '*':
          - salt
          - users
          - users.admin
        'saltmaster.*':
          - match: pcre
          - salt.master

   This above example uses the base environment which is  built  into  the
   default Salt setup.

   The base environment has two globs. First, the '*' glob contains a list
   of SLS files to apply to all minions.

   The second glob contains a  regular  expression  that  will  match  all
   minions  with  an ID matching saltmaster.* and specifies that for those
   minions, the salt.master state should be applied.

   Reloading Modules
   Some Salt states require that specific packages be installed  in  order
   for the module to load. As an example the pip state module requires the
   pip package for proper name and version parsing.

   In most of the common cases, Salt is  clever  enough  to  transparently
   reload the modules. For example, if you install a package, Salt reloads
   modules because some other module or  state  might  require  just  that
   package which was installed.

   On  some  edge-cases  salt might need to be told to reload the modules.
   Consider the following state file which we'll call pep8.sls:

      python-pip:
        cmd.run:
          - name: |
              easy_install --script-dir=/usr/bin -U pip
          - cwd: /

      pep8:
        pip.installed:
          - require:
            - cmd: python-pip

   The above example installs pip using easy_install from  setuptools  and
   installs  pep8  using  pip,  which, as told earlier, requires pip to be
   installed system-wide. Let's execute this state:

      salt-call state.apply pep8

   The execution output would be something like:

      ----------
          State: - pip
          Name:      pep8
          Function:  installed
              Result:    False
              Comment:   State pip.installed found in sls pep8 is unavailable

              Changes:

      Summary
      ------------
      Succeeded: 1
      Failed:    1
      ------------
      Total:     2

   If we executed the state again the output would be:

      ----------
          State: - pip
          Name:      pep8
          Function:  installed
              Result:    True
              Comment:   Package was successfully installed
              Changes:   pep8==1.4.6: Installed

      Summary
      ------------
      Succeeded: 2
      Failed:    0
      ------------
      Total:     2

   Since we installed pip using cmd, Salt  has  no  way  to  know  that  a
   system-wide package was installed.

   On  the second execution, since the required pip package was installed,
   the state executed correctly.

   NOTE:
      Salt does not reload modules on every state  run  because  doing  so
      would greatly slow down state execution.

   So how do we solve this edge-case? reload_modules!

   reload_modules  is a boolean option recognized by salt on all available
   states which forces salt to reload  its  modules  once  a  given  state
   finishes.

   The modified state file would now be:

      python-pip:
        cmd.run:
          - name: |
              easy_install --script-dir=/usr/bin -U pip
          - cwd: /
          - reload_modules: true

      pep8:
        pip.installed:
          - require:
            - cmd: python-pip

   Let's run it, once:

      salt-call state.apply pep8

   The output is:

      ----------
          State: - pip
          Name:      pep8
          Function:  installed
              Result:    True
              Comment:   Package was successfully installed
              Changes:   pep8==1.4.6: Installed

      Summary
      ------------
      Succeeded: 2
      Failed:    0
      ------------
      Total:     2

UTILITY MODULES - CODE REUSE IN CUSTOM MODULES

   New in version 2015.5.0.

   Changed in version 2016.11.0: These can now be synced to the Master for
   use in custom Runners, and in custom execution  modules  called  within
   Pillar SLS files.

   When  extending  Salt  by  writing  custom  (state  modules), execution
   modules, etc., sometimes there is a need for a function to be available
   to  more  than  just  one  kind of custom module. For these cases, Salt
   supports what are called "utility  modules".  These  modules  are  like
   normal  execution  modules,  but  instead of being invoked in Salt code
   using __salt__, the __utils__ prefix is used instead.

   For example, assuming the following simple  utility  module,  saved  to
   salt://_utils/foo.py

      # -*- coding: utf-8 -*-
      '''
      My utils module
      ---------------

      This module contains common functions for use in my other custom types.
      '''

      def bar():
          return 'baz'

   Once  synced  to  a  minion,  this function would be available to other
   custom Salt types like so:

      # -*- coding: utf-8 -*-
      '''
      My awesome execution module
      ---------------------------
      '''

      def observe_the_awesomeness():
          '''
          Prints information from my utility module

          CLI Example:

          .. code-block:: bash

              salt '*' mymodule.observe_the_awesomeness
          '''
          print __utils__['foo.bar']()

   Utility modules, like any other kind of Salt extension, support using a
   __virtual__  function  to conditionally load them, or load them under a
   different namespace. For instance, if the  utility  module  above  were
   named  salt://_utils/mymodule.py  it  could be made to be loaded as the
   foo utility module with a __virtual__ function.

      # -*- coding: utf-8 -*-
      '''
      My utils module
      ---------------

      This module contains common functions for use in my other custom types.
      '''

      def __virtual__():
          '''
          Load as a different name
          '''
          return 'foo'

      def bar():
          return 'baz'

   These are, of course, contrived examples, but they should serve to show
   some of the possibilities opened up by writing utility modules. Keep in
   mind though that States still have  access  to  all  of  the  execution
   modules,  so  it  is  not necessary to write a utility module to make a
   function available to both a state and an execution  module.  One  good
   use  case  for  utililty modules is one where it is necessary to invoke
   the same function from a  custom  outputter/returner,  as  well  as  an
   execution module.

   Utility  modules placed in salt://_utils/ will be synced to the minions
   when any of the following Salt functions are called:

   * state.apply

   * saltutil.sync_utils

   * saltutil.sync_all

   To sync to the Master, use either of the following:

   * saltutil.sync_utils

   * saltutil.sync_all

EVENTS & REACTOR

   Event System
   The Salt Event System is used to fire off events enabling  third  party
   applications or external processes to react to behavior within Salt.

   The event system is comprised of a two primary components:

      * The event sockets which publishes events.

      * The  event library which can listen to events and send events into
        the salt system.

   Event types
   Salt Master Events
   These events are fired on the Salt Master event bus. This list  is  not
   comprehensive.

   Authentication events
   salt/auth
          Fired  when  a  minion performs an authentication check with the
          master.

          Variables

                 * id -- The minion ID.

                 * act -- The current status of the  minion  key:  accept,
                   pend, reject.

                 * pub -- The minion public key.

          NOTE:
             Minions fire auth events on fairly regular basis for a number
             of reasons.  Writing reactors to respond  to  events  through
             the  auth  cycle  can  lead  to  infinite reactor event loops
             (minion tries to auth, reactor responds  by  doing  something
             that  generates  another auth event, minion sends auth event,
             etc.).      Consider     reacting     to     salt/key      or
             salt/minion/<MID>/start or firing a custom event tag instead.

   Start events
   salt/minion/<MID>/start
          Fired every time a minion connects to the Salt master.

          Variables
                 id -- The minion ID.

   Key events
   salt/key
          Fired  when  accepting  and  rejecting  minions keys on the Salt
          master.  These happen as a result of actions undertaken  by  the
          salt-key command.

          Variables

                 * id -- The minion ID.

                 * act  --  The  new  status  of  the  minion key: accept,
                   delete,

   WARNING:
      If a master is in auto_accept mode,  salt/key  events  will  not  be
      fired  when  the  keys  are accepted.  In addition, pre-seeding keys
      (like happens through Salt-Cloud) will not  cause  firing  of  these
      events.

   Job events
   salt/job/<JID>/new
          Fired as a new job is sent out to minions.

          Variables

                 * jid -- The job ID.

                 * tgt  --  The  target  of  the  job:  *,  a  minion  ID,
                   G@os_family:RedHat, etc.

                 * tgt_type -- The type of targeting  used:  glob,  grain,
                   compound, etc.

                 * fun  --  The  function  to  run  on minions: test.ping,
                   network.interfaces, etc.

                 * arg -- A list of arguments to pass to the function that
                   will be called.

                 * minions  -- A list of minion IDs that Salt expects will
                   return data for this job.

                 * user -- The name of the user that ran  the  command  as
                   defined in Salt's Publisher ACL or external auth.

   salt/job/<JID>/ret/<MID>
          Fired each time a minion returns data for a job.

          Variables

                 * id -- The minion ID.

                 * jid -- The job ID.

                 * retcode -- The return code for the job.

                 * fun -- The function the minion ran. E.g., test.ping.

                 * return -- The data returned from the execution module.

   salt/job/<JID>/prog/<MID>/<RUN NUM>
          Fired  each  time  a  each  function  in  a  state run completes
          execution. Must be enabled using the state_events option.

          Variables

                 * data  --  The  data  returned  from  the  state  module
                   function.

                 * id -- The minion ID.

                 * jid -- The job ID.

   Runner Events
   salt/run/<JID>/new
          Fired as a runner begins execution

          Variables

                 * jid -- The job ID.

                 * fun  --  The  name of the runner function, with runner.
                   prepended to it (e.g. runner.jobs.lookup_jid)

                 * fun_args -- The arguments passed to the runner function
                   (e.g.  ['20160829225914848058'])

                 * user -- The user who executed the runner (e.g. root)

   salt/run/<JID>/ret
          Fired when a runner function returns

          Variables

                 * jid -- The job ID.

                 * fun  --  The  name of the runner function, with runner.
                   prepended to it (e.g. runner.jobs.lookup_jid)

                 * fun_args -- The arguments passed to the runner function
                   (e.g.  ['20160829225914848058'])

                 * return -- The data returned by the runner function

   salt/run/<JID>/args
          New in version 2016.11.0.

          Fired by the state.orchestrate runner

          Variables

                 * name  --  The  ID declaration for the orchestration job
                   (i.e.  the  line   above   salt.state,   salt.function,
                   salt.runner, etc.)

                 * type  --  The type of orchestration job being run (e.g.
                   state)

                 * tgt -- The target expression  (e.g.  *).  Included  for
                   state and function types only.

                 * args -- The args passed to the orchestration job. Note:
                   for  state  and  function  types,  also   includes   an
                   expr_form  which  shows what kind of match (glob, pcre,
                   etc.) was used.

   Presence Events
   salt/presence/present
          Events fired on a regular interval  about  currently  connected,
          newly  connected, or recently disconnected minions. Requires the
          presence_events setting to be enabled.

          Variables
                 present -- A list of minions that are currently connected
                 to the Salt master.

   salt/presence/change
          Fired  when  the  Presence system detects new minions connect or
          disconnect.

          Variables

                 * new -- A list of minions that have connected since  the
                   last presence event.

                 * lost  -- A list of minions that have disconnected since
                   the last presence event.

   Cloud Events
   Unlike other Master events, salt-cloud events are not fired  on  behalf
   of  a  Salt Minion. Instead, salt-cloud events are fired on behalf of a
   VM. This is because the minion-to-be may not yet exist to  fire  events
   to or also may have been destroyed.

   This  behavior  is reflected by the name variable in the event data for
   salt-cloud  events  as  compared  to   the   id   variable   for   Salt
   Minion-triggered events.

   salt/cloud/<VM NAME>/creating
          Fired when salt-cloud starts the VM creation process.

          Variables

                 * name -- the name of the VM being created.

                 * event -- description of the event.

                 * provider -- the cloud provider of the VM being created.

                 * profile -- the cloud profile for the VM being created.

   salt/cloud/<VM NAME>/deploying
          Fired  when  the VM is available and salt-cloud begins deploying
          Salt to the new VM.

          Variables

                 * name -- the name of the VM being created.

                 * event -- description of the event.

                 * kwargs -- options available as  the  deploy  script  is
                   invoked: conf_file, deploy_command, display_ssh_output,
                   host, keep_tmp, key_filename, make_minion, minion_conf,
                   name,     parallel,     preseed_minion_keys,    script,
                   script_args, script_env, sock_dir, start_action,  sudo,
                   tmp_dir, tty, username

   salt/cloud/<VM NAME>/requesting
          Fired when salt-cloud sends the request to create a new VM.

          Variables

                 * event -- description of the event.

                 * location -- the location of the VM being requested.

                 * kwargs   --  options  available  as  the  VM  is  being
                   requested:  Action,  ImageId,  InstanceType,   KeyName,
                   MaxCount, MinCount, SecurityGroup.1

   salt/cloud/<VM NAME>/querying
          Fired when salt-cloud queries data for a new instance.

          Variables

                 * event -- description of the event.

                 * instance_id -- the ID of the new VM.

   salt/cloud/<VM NAME>/tagging
          Fired when salt-cloud tags a new instance.

          Variables

                 * event -- description of the event.

                 * tags -- tags being set on the new instance.

   salt/cloud/<VM NAME>/waiting_for_ssh
          Fired  while the salt-cloud deploy process is waiting for ssh to
          become available on the new instance.

          Variables

                 * event -- description of the event.

                 * ip_address -- IP address of the new instance.

   salt/cloud/<VM NAME>/deploy_script
          Fired once the deploy script is finished.

          Variables
                 event -- description of the event.

   salt/cloud/<VM NAME>/created
          Fired once the new instance has been fully created.

          Variables

                 * name -- the name of the VM being created.

                 * event -- description of the event.

                 * instance_id -- the ID of the new instance.

                 * provider -- the cloud provider of the VM being created.

                 * profile -- the cloud profile for the VM being created.

   salt/cloud/<VM NAME>/destroying
          Fired when salt-cloud requests the destruction of an instance.

          Variables

                 * name -- the name of the VM being created.

                 * event -- description of the event.

                 * instance_id -- the ID of the new instance.

   salt/cloud/<VM NAME>/destroyed
          Fired when an instance has been destroyed.

          Variables

                 * name -- the name of the VM being created.

                 * event -- description of the event.

                 * instance_id -- the ID of the new instance.

   Listening for Events
   Salt's Event Bus is used heavily within Salt and it is also written  to
   integrate heavily with existing tooling and scripts. There is a variety
   of ways to consume it.

   From the CLI
   The quickest way to watch the event bus is by calling  the  state.event
   runner:

      salt-run state.event pretty=True

   That  runner  is  designed to interact with the event bus from external
   tools and shell scripts. See the documentation for more examples.

   Remotely via the REST API
   Salt's event bus can be  consumed  salt.netapi.rest_cherrypy.app.Events
   as an HTTP stream from external tools or services.

      curl -SsNk https://salt-api.example.com:8000/events?token=05A3

   From Python
   Python  scripts  can  access the event bus only as the same system user
   that Salt is running as.

   The event system is accessed via the event  library  and  can  only  be
   accessed  by the same system user that Salt is running as. To listen to
   events a SaltEvent object needs to be created and  then  the  get_event
   function  needs  to  be  run.  The  SaltEvent  object needs to know the
   location that the Salt Unix sockets are kept. In the configuration this
   is   the   sock_dir   option.   The   sock_dir   option   defaults   to
   "/var/run/salt/master" on most systems.

   The following code will check for a single event:

      import salt.config
      import salt.utils.event

      opts = salt.config.client_config('/etc/salt/master')

      event = salt.utils.event.get_event(
              'master',
              sock_dir=opts['sock_dir'],
              transport=opts['transport'],
              opts=opts)

      data = event.get_event()

   Events will also use a "tag". Tags allow for events to be  filtered  by
   prefix.  By default all events will be returned. If only authentication
   events are desired, then pass the tag "salt/auth".

   The get_event method has a default poll time assigned of 5 seconds.  To
   change this time set the "wait" option.

   The  following  example  will only listen for auth events and will wait
   for 10 seconds instead of the default 5.

      data = event.get_event(wait=10, tag='salt/auth')

   To retrieve the tag as well as the event data, pass full=True:

      evdata = event.get_event(wait=10, tag='salt/job', full=True)

      tag, data = evdata['tag'], evdata['data']

   Instead of looking for a single event, the iter_events  method  can  be
   used to make a generator which will continually yield salt events.

   The iter_events method also accepts a tag but not a wait time:

      for data in event.iter_events(tag='salt/auth'):
          print(data)

   And  finally  event  tags  can  be  globbed, such as they can be in the
   Reactor, using the fnmatch library.

      import fnmatch

      import salt.config
      import salt.utils.event

      opts = salt.config.client_config('/etc/salt/master')

      sevent = salt.utils.event.get_event(
              'master',
              sock_dir=opts['sock_dir'],
              transport=opts['transport'],
              opts=opts)

      while True:
          ret = sevent.get_event(full=True)
          if ret is None:
              continue

          if fnmatch.fnmatch(ret['tag'], 'salt/job/*/ret/*'):
              do_something_with_job_return(ret['data'])

   Firing Events
   It is possible to fire events on either the minion's local  bus  or  to
   fire events intended for the master.

   To  fire  a  local  event  from the minion on the command line call the
   event.fire execution function:

      salt-call event.fire '{"data": "message to be sent in the event"}' 'tag'

   To fire an event to be sent up to the master from the minion  call  the
   event.send  execution function. Remember YAML can be used at the CLI in
   function arguments:

      salt-call event.send 'myco/mytag/success' '{success: True, message: "It works!"}'

   If a process is listening on the minion, it may be useful for a user on
   the master to fire an event to it:

      # Job on minion
      import salt.utils.event

      event = salt.utils.event.MinionEvent(**__opts__)

      for evdata in event.iter_events(tag='customtag/'):
          return evdata # do your processing here...

      salt minionname event.fire '{"data": "message for the minion"}' 'customtag/african/unladen'

   Firing Events from Python
   From Salt execution modules
   Events  can  be very useful when writing execution modules, in order to
   inform various processes on the master when a certain  task  has  taken
   place. This is easily done using the normal cross-calling syntax:

      # /srv/salt/_modules/my_custom_module.py

      def do_something():
          '''
          Do something and fire an event to the master when finished

          CLI Example::

              salt '*' my_custom_module:do_something
          '''
          # do something!
          __salt__['event.send']('myco/my_custom_module/finished', {
              'finished': True,
              'message': "The something is finished!",
          })

   From Custom Python Scripts
   Firing  events  from custom Python code is quite simple and mirrors how
   it is done at the CLI:

      import salt.client

      caller = salt.client.Caller()

      caller.sminion.functions['event.send'](
          'myco/myevent/success',
          {
              'success': True,
              'message': "It works!",
          }
      )

   Beacons
   Beacons  let  you  use  the  Salt  event  system  to  monitor  non-Salt
   processes.  The  beacon system allows the minion to hook into a variety
   of system processes  and  continually  monitor  these  processes.  When
   monitored  activity occurs in a system process, an event is sent on the
   Salt event bus that can be used to trigger a reactor.

   Salt beacons can currently monitor and send Salt events for many system
   activities, including:

   * file system changes

   * system load

   * service status

   * shell activity, such as user login

   * network and disk usage

   See beacon modules for a current list.

   NOTE:
      Salt beacons are an event generation mechanism. Beacons leverage the
      Salt reactor system to make changes when beacon events occur.

   Configuring Beacons
   Salt beacons do not require any changes to the system  components  that
   are being 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:

      beacons:
        inotify:
          /etc/important_file: {}
          /opt: {}

   The beacon system, like many others in Salt, can also be configured via
   the minion pillar, grains, or local config file.

   NOTE:
      The inotify beacon only works  on  OSes  that  have  inotify  kernel
      support.  Currently this excludes FreeBSD, Mac OS X, and Windows.

   Beacon Monitoring Interval
   Beacons  monitor  on a 1-second interval by default. To set a different
   interval, provide an interval  argument  to  a  beacon.  The  following
   beacons run on 5- and 10-second intervals:

      beacons:
        inotify:
          /etc/important_file: {}
          /opt: {}
          interval: 5
          disable_during_state_run: True
        load:
          1m:
            - 0.0
            - 2.0
          5m:
            - 0.0
            - 1.5
          15m:
            - 0.1
            - 1.0
          interval: 10

   Avoiding Event Loops
   It  is  important  to  carefully consider the possibility of creating a
   loop between a reactor and a beacon. For example, one might  set  up  a
   beacon  which  monitors  whether  a  file is read which in turn fires a
   reactor to run a state which in turn reads the file  and  re-fires  the
   beacon.

   To   avoid  these  types  of  scenarios,  the  disable_during_state_run
   argument may be set. If a state run is in progress, the beacon will not
   be  run on its regular interval until the minion detects that the state
   run has completed, at which  point  the  normal  beacon  interval  will
   resume.

      beacons:
        inotify:
          /etc/important_file: {}
          disable_during_state_run: True

   NOTE:
      For beacon writers:  If you need extra stuff to happen, like closing
      file handles for the disable_during_state_run to actually work,  you
      can  add a close() function to the beacon to run those extra things.
      See the inotify beacon.

   Beacon Example
   This example demonstrates configuring the inotify beacon to  monitor  a
   file  for  changes, and then restores the file to its original contents
   if a change was made.

   NOTE:
      The inotify beacon requires Pyinotify  on  the  minion,  install  it
      using salt myminion pkg.install python-inotify.

   Create Watched File
   Create the file named /etc/important_file and add some simple content:

      important_config: True

   Add Beacon Configs to Minion
   On    the   Salt   minion,   add   the   following   configuration   to
   /etc/salt/minion.d/beacons.conf:

      beacons:
        inotify:
          /etc/important_file:
            mask:
              - modify
          disable_during_state_run: True

   Save the configuration file and restart the minion service. The  beacon
   is now set up to notify salt upon modifications made to the file.

   NOTE:
      The  disable_during_state_run:  True  parameter prevents the inotify
      beacon from generating reactor events due to salt  itself  modifying
      the file.

   View Events on the Master
   On  your  Salt  master,  start  the  event  runner  using the following
   command:

      salt-run state.event pretty=true

   This runner displays events as they are received by the master  on  the
   Salt  event bus. To test the beacon you set up in the previous section,
   make and save a modification  to  /etc/important_file.  You'll  see  an
   event similar to the following on the event bus:

      salt/beacon/larry/inotify//etc/important_file       {
       "_stamp": "2015-09-09T15:59:37.972753",
       "data": {
           "change": "IN_IGNORED",
           "id": "larry",
           "path": "/etc/important_file"
       },
       "tag": "salt/beacon/larry/inotify//etc/important_file"
      }

   This indicates that the event is being captured and sent correctly. Now
   you can create a reactor to take action when this event occurs.

   Create a Reactor
   This reactor reverts the file named /etc/important_file to the contents
   provided by salt each time it is modified.

   Reactor SLS
   On your Salt master, create a file named /srv/reactor/revert.sls.

   NOTE:
      If the /srv/reactor directory doesn't exist, create it.

          mkdir -p /srv/reactor

   Add the following to /srv/reactor/revert.sls:

      revert-file:
        local.state.apply:
          - tgt: {{ data['data']['id'] }}
          - mods: maintain_important_file

   NOTE:
      In addition to setting disable_during_state_run: True for an inotify
      beacon whose reaction is to modify the watched file, it is important
      to ensure the state applied is also idempotent.

   NOTE:
      The  expression {{ data['data']['id] }} is correct as it matches the
      event structure shown above.

   State SLS
   Create the state sls file referenced by the  reactor  sls  file.   This
   state file will be located at /srv/salt/maintain_important_file.sls.

      important_file:
        file.managed:
          - name: /etc/important_file
          - contents: |
              important_config: True

   Master Config
   Configure  the  master  to  map  the inotify beacon event to the revert
   reaction in /etc/salt/master.d/reactor.conf:

      reactor:
        - salt/beacon/*/inotify//etc/important_file:
          - /srv/reactor/revert.sls

   NOTE:
      You can have only one top level reactor section, so if  one  already
      exists, add this code to the existing section. See Understanding the
      Structure of Reactor  Formulas  to  learn  more  about  reactor  SLS
      syntax.

   Start the Salt Master in Debug Mode
   To help with troubleshooting, start the Salt master in debug mode:

      service salt-master stop
      salt-master -l debug

   When  debug logging is enabled, event and reactor data are displayed so
   you can discover syntax and other issues.

   Trigger the Reactor
   On your minion, make and save another change to /etc/important_file. On
   the  Salt master, you'll see debug messages that indicate the event was
   received and the state.apply job was sent. When you inspect the file on
   the  minion,  you'll  see  that the file contents have been restored to
   important_config: True.

   All beacons are configured using a  similar  process  of  enabling  the
   beacon,  writing a reactor SLS (and state SLS if needed), and mapping a
   beacon event to the reactor SLS.

   Writing Beacon Plugins
   Beacon plugins use the standard Salt loader system, meaning  that  many
   of  the  constructs  from  other plugin systems holds true, such as the
   __virtual__ function.

   The important function in the Beacon Plugin  is  the  beacon  function.
   When  the  beacon  is configured to run, this function will be executed
   repeatedly by the minion. The beacon function  therefore  cannot  block
   and should be as lightweight as possible. The beacon also must return a
   list of dicts, each dict in the list will be translated into  an  event
   on the master.

   Beacons  may  also  choose  to  implement a __validate__ function which
   takes the beacon configuration as an argument and ensures  that  it  is
   valid prior to continuing. This function is called automatically by the
   Salt loader when a beacon is loaded.

   Please see the inotify beacon as an example.

   The beacon Function
   The beacons system will look for a function named beacon in the module.
   If this function is not present then the beacon will not be fired. This
   function is called on a regular basis and defaults to being  called  on
   every iteration of the minion, which can be tens to hundreds of times a
   second. This means that the beacon function cannot block and should not
   be CPU or IO intensive.

   The  beacon  function  will  be  passed  in  the  configuration for the
   executed  beacon.  This  makes  it  easy  to   establish   a   flexible
   configuration for each called beacon. This is also the preferred way to
   ingest the beacon's configuration as it allows for the configuration to
   be  dynamically  updated while the minion is running by configuring the
   beacon in the minion's pillar.

   The Beacon Return
   The information returned from  the  beacon  is  expected  to  follow  a
   predefined  structure.  The  returned  value  needs  to  be  a  list of
   dictionaries (standard python dictionaries are  preferred,  no  ordered
   dicts are needed).

   The  dictionaries represent individual events to be fired on the minion
   and master event buses. Each dict is  a  single  event.  The  dict  can
   contain  any  arbitrary  keys  but  the 'tag' key will be extracted and
   added to the tag of the fired event.

   The return data structure would look something like this:

      [{'changes': ['/foo/bar'], 'tag': 'foo'},
       {'changes': ['/foo/baz'], 'tag': 'bar'}]

   Calling Execution Modules
   Execution modules are still the preferred location  for  all  work  and
   system  interaction  to  happen  in  Salt. For this reason the __salt__
   variable is available inside the beacon.

   Please be careful when calling functions in __salt__, while this is the
   preferred  means  of  executing complicated routines in Salt not all of
   the execution modules have been written with beacons in mind. Watch out
   for  execution modules that may be CPU intense or IO bound. Please feel
   free to add new  execution  modules  and  functions  to  back  specific
   beacons.

   Distributing Custom Beacons
   Custom  beacons  can  be  distributed  to  minions  using saltutil, see
   Dynamic Module Distribution.

   Reactor System
   Salt's Reactor system gives Salt the  ability  to  trigger  actions  in
   response to an event. It is a simple interface to watching Salt's event
   bus for event tags that match a given pattern and then running  one  or
   more commands in response.

   This  system  binds  sls  files  to event tags on the master. These sls
   files then define reactions. This means that the reactor system has two
   parts.  First,  the  reactor  option  needs  to  be  set  in the master
   configuration file.  The reactor option allows for  event  tags  to  be
   associated  with  sls  reaction files. Second, these reaction files use
   highdata (like the state system) to define reactions to be executed.

   Event System
   A basic understanding of the event system  is  required  to  understand
   reactors.  The event system is a local ZeroMQ PUB interface which fires
   salt events. This  event  bus  is  an  open  system  used  for  sending
   information notifying Salt and other systems about operations.

   The  event  system  fires  events  with a very specific criteria. Every
   event has a tag. Event tags allow  for  fast  top  level  filtering  of
   events.  In  addition to the tag, each event has a data structure. This
   data structure is a dict, which contains information about the event.

   Mapping Events to Reactor SLS Files
   Reactor SLS files and event tags are associated in  the  master  config
   file.       By     default     this     is     /etc/salt/master,     or
   /etc/salt/master.d/reactor.conf.

   New in version 2014.7.0: Added Reactor support for salt:// file paths.

   In the master config section 'reactor:' is a list of event tags  to  be
   matched and each event tag has a list of reactor SLS files to be run.

      reactor:                            # Master config section "reactor"

        - 'salt/minion/*/start':          # Match tag "salt/minion/*/start"
          - /srv/reactor/start.sls        # Things to do when a minion starts
          - /srv/reactor/monitor.sls      # Other things to do

        - 'salt/cloud/*/destroyed':       # Globs can be used to match tags
          - /srv/reactor/destroy/*.sls    # Globs can be used to match file names

        - 'myco/custom/event/tag':        # React to custom event tags
          - salt://reactor/mycustom.sls   # Reactor files can come from the salt fileserver

   NOTE:
      In the above example, salt://reactor/mycustom.sls refers to the base
      environment. To pull this file from a different environment, use the
      querystring                       syntax                       (e.g.
      salt://reactor/mycustom.sls?saltenv=reactor).

   Reactor sls files are similar to state and pillar sls files.  They  are
   by  default  yaml  +  Jinja  templates  and are passed familiar context
   variables.

   They differ because of the addition of the tag and data variables.

   * The tag variable is just the tag in the fired event.

   * The data variable is the event's data dict.

   Here is a simple reactor sls:

      {% if data['id'] == 'mysql1' %}
      highstate_run:
        local.state.apply:
          - tgt: mysql1
      {% endif %}

   This simple reactor file uses Jinja to further refine the  reaction  to
   be made.  If the id in the event data is mysql1 (in other words, if the
   name of the minion is mysql1) then the following reaction  is  defined.
   The  same data structure and compiler used for the state system is used
   for the reactor system. The only difference is that the data is matched
   up  to  the salt command API and the runner system.  In this example, a
   command  is  published  to  the  mysql1  minion  with  a  function   of
   state.apply. Similarly, a runner can be called:

      {% if data['data']['orchestrate'] == 'refresh' %}
      orchestrate_run:
        runner.state.orchestrate
      {% endif %}

   This  example will execute the state.orchestrate runner and initiate an
   orchestrate execution.

   The Goal of Writing Reactor SLS Files
   Reactor SLS files share the familiar syntax from Salt States but  there
   are  important  differences. The goal of a Reactor file is to process a
   Salt event as quickly as possible and then to optionally  start  a  new
   process in response.

   1. The Salt Reactor watches Salt's event bus for new events.

   2. The  event  tag  is matched against the list of event tags under the
      reactor section in the Salt Master config.

   3. The SLS files for any matches are Rendered  into  a  data  structure
      that represents one or more function calls.

   4. That  data  structure  is  given  to  a  pool  of worker threads for
      execution.

   Matching and rendering Reactor SLS files  is  done  sequentially  in  a
   single  process.  Complex  Jinja  that  calls  out to slow Execution or
   Runner modules slows down the rendering and causes other  reactions  to
   pile  up  behind the current one. The worker pool is designed to handle
   complex and long-running processes such as Salt Orchestrate.

   tl;dr: Rendering Reactor SLS files MUST be simple and  quick.  The  new
   process started by the worker threads can be long-running.

   Jinja Context
   Reactor  files  only have access to a minimal Jinja context. grains and
   pillar are not available. The salt  object  is  available  for  calling
   Runner  and  Execution modules but it should be used sparingly and only
   for quick tasks for the reasons mentioned above.

   Advanced State System Capabilities
   Reactor SLS files, by design,  do  not  support  Requisites,  ordering,
   onlyif/unless  conditionals  and  most  other  powerful constructs from
   Salt's State system.

   Complex Master-side operations are best performed by Salt's Orchestrate
   system  so  using  the Reactor to kick off an Orchestrate run is a very
   common pairing.

   For example:

      # /etc/salt/master.d/reactor.conf
      # A custom event containing: {"foo": "Foo!", "bar: "bar*", "baz": "Baz!"}
      reactor:
        - myco/custom/event:
          - /srv/reactor/some_event.sls

      # /srv/reactor/some_event.sls
      invoke_orchestrate_file:
        runner.state.orchestrate:
          - mods: orch.do_complex_thing
          - pillar:
              event_tag: {{ tag }}
              event_data: {{ data | json() }}

      # /srv/salt/orch/do_complex_thing.sls
      {% set tag = salt.pillar.get('event_tag') %}
      {% set data = salt.pillar.get('event_data') %}

      # Pass data from the event to a custom runner function.
      # The function expects a 'foo' argument.
      do_first_thing:
        salt.runner:
          - name: custom_runner.custom_function
          - foo: {{ data.foo }}

      # Wait for the runner to finish then send an execution to minions.
      # Forward some data from the event down to the minion's state run.
      do_second_thing:
        salt.state:
          - tgt: {{ data.bar }}
          - sls:
            - do_thing_on_minion
          - pillar:
              baz: {{ data.baz }}
          - require:
            - salt: do_first_thing

   Beacons and Reactors
   An event initiated by a beacon, when it arrives at the master  will  be
   wrapped inside a second event, such that the data object containing the
   beacon information will be data['data'], rather than data.

   For example, to access the id field of the beacon event  in  a  reactor
   file,  you  will need to reference {{ data['data']['id'] }} rather than
   {{ data['id'] }} as for events initiated directly on the event bus.

   See the beacon documentation for examples.

   Fire an event
   To fire an event from a minion call event.send

      salt-call event.send 'foo' '{orchestrate: refresh}'

   After this is called, any reactor sls files matching event tag foo will
   execute with {{ data['data']['orchestrate'] }} equal to 'refresh'.

   See salt.modules.event for more information.

   Knowing what event is being fired
   The  best  way  to  see  exactly what events are fired and what data is
   available in each event is to use the state.event runner.

   SEE ALSO:
      Common Salt Events

   Example usage:

      salt-run state.event pretty=True

   Example output:

      salt/job/20150213001905721678/new       {
          "_stamp": "2015-02-13T00:19:05.724583",
          "arg": [],
          "fun": "test.ping",
          "jid": "20150213001905721678",
          "minions": [
              "jerry"
          ],
          "tgt": "*",
          "tgt_type": "glob",
          "user": "root"
      }
      salt/job/20150213001910749506/ret/jerry {
          "_stamp": "2015-02-13T00:19:11.136730",
          "cmd": "_return",
          "fun": "saltutil.find_job",
          "fun_args": [
              "20150213001905721678"
          ],
          "id": "jerry",
          "jid": "20150213001910749506",
          "retcode": 0,
          "return": {},
          "success": true
      }

   Debugging the Reactor
   The best window into the Reactor is to run the master in the foreground
   with  debug  logging  enabled.  The output will include when the master
   sees the event, what the master does in response to that event, and  it
   will  also include the rendered SLS file (or any errors generated while
   rendering the SLS file).

   1. Stop the master.

   2. Start the master manually:

         salt-master -l debug

   3. Look for log entries in the form:

         [DEBUG   ] Gathering reactors for tag foo/bar
         [DEBUG   ] Compiling reactions for tag foo/bar
         [DEBUG   ] Rendered data from file: /path/to/the/reactor_file.sls:
         <... Rendered output appears here. ...>

      The rendered output is the result of the Jinja parsing and is a good
      way to view the result of referencing Jinja variables. If the result
      is empty then Jinja produced an empty result and  the  Reactor  will
      ignore it.

   Understanding the Structure of Reactor Formulas
   I.e.,  when  to  use `arg` and `kwarg` and when to specify the function
   arguments directly.

   While the reactor system uses the same  basic  data  structure  as  the
   state  system,  the  functions  that  will  be  called  using that data
   structure are different functions than  are  called  via  Salt's  state
   system.  The  Reactor  can call Runner modules using the runner prefix,
   Wheel modules using the wheel prefix, and can also cause minions to run
   Execution modules using the local prefix.

   Changed  in  version  2014.7.0: The cmd prefix was renamed to local for
   consistency with other parts of Salt. A backward-compatible  alias  was
   added for cmd.

   The  Reactor  runs  on the master and calls functions that exist on the
   master. In the case of Runner and Wheel functions the Reactor can  just
   call  those  functions  directly since they exist on the master and are
   run on the master.

   In the case of functions that exist on minions and are run on  minions,
   the  Reactor  still  needs to call a function on the master in order to
   send the necessary data to the minion so the minion  can  execute  that
   function.

   The Reactor calls functions exposed in Salt's Python API documentation.
   and thus the structure of Reactor files very transparently reflects the
   function signatures of those functions.

   Calling Execution modules on Minions
   The Reactor sends commands down to minions in the exact same way Salt's
   CLI interface does. It calls a function  locally  on  the  master  that
   sends the name of the function as well as a list of any arguments and a
   dictionary of any keyword arguments  that  the  minion  should  use  to
   execute that function.

   Specifically, the Reactor calls the async version of this function. You
   can see that function has 'arg' and 'kwarg' parameters which  are  both
   values that are sent down to the minion.

   Executing  remote  commands  maps to the LocalClient interface which is
   used by the salt command. This interface more specifically maps to  the
   cmd_async  method  inside of the LocalClient class. This means that the
   arguments passed are being passed to  the  cmd_async  method,  not  the
   remote  method.  A  field  starts  with  local  to  use the LocalClient
   subsystem. The result is,  to  execute  a  remote  command,  a  reactor
   formula would look like this:

      clean_tmp:
        local.cmd.run:
          - tgt: '*'
          - arg:
            - rm -rf /tmp/*

   The  arg option takes a list of arguments as they would be presented on
   the command line, so the above declaration is the same as running  this
   salt command:

      salt '*' cmd.run 'rm -rf /tmp/*'

   Use the expr_form argument to specify a matcher:

      clean_tmp:
        local.cmd.run:
          - tgt: 'os:Ubuntu'
          - expr_form: grain
          - arg:
            - rm -rf /tmp/*

      clean_tmp:
        local.cmd.run:
          - tgt: 'G@roles:hbase_master'
          - expr_form: compound
          - arg:
            - rm -rf /tmp/*

   NOTE:
      An  easy  mistake  to  make  here  is  to  use  tgt_type  instead of
      expr_form, since the job cache and events all refer to the targeting
      method  as  tgt_type.  As of the Nitrogen release of Salt, expr_form
      will be deprecated in favor of using tgt_type,  to  help  with  this
      confusion.

   Any other parameters in the LocalClient().cmd() method can be specified
   as well.

   Executing Reactors from the Minion
   The minion can be setup to use the Reactor via a reactor engine.   This
   just  sets  up  and listens to the minions event bus, instead of to the
   masters.

   The biggest difference is that you have to use the caller method on the
   Reactor, which is the equivalent of salt-call, to run your commands.

   Reactor Engine setup

      clean_tmp:
        caller.cmd.run:
          - arg:
            - rm -rf /tmp/*

   NOTE:
      Masterless Minions use this Reactor

      This  is  the  only  way  to  run  the Reactor if you use masterless
      minions.

   Calling Runner modules and Wheel modules
   Calling Runner modules and Wheel modules from the Reactor uses  a  more
   direct  syntax  since the function is being executed locally instead of
   sending a command to a remote system to be executed there. There are no
   'arg'  or  'kwarg'  parameters  (unless  the  Runner  function or Wheel
   function accepts a parameter with either of those names.)

   For example:

      clear_the_grains_cache_for_all_minions:
        runner.cache.clear_grains

   If the the runner takes  arguments  then  they  must  be  specified  as
   keyword arguments.

      spin_up_more_web_machines:
        runner.cloud.profile:
          - prof: centos_6
          - instances:
            - web11       # These VM names would be generated via Jinja in a
            - web12       # real-world example.

   To   determine   the   proper   names  for  the  arguments,  check  the
   documentation or source code for the runner function you wish to call.

   Passing event data to Minions or Orchestrate as Pillar
   An  interesting  trick  to  pass  data  from  the  Reactor  script   to
   state.apply  is  to  pass it as inline Pillar data since both functions
   take a keyword argument named pillar.

   The following example uses Salt's Reactor to listen for the event  that
   is  fired when the key for a new minion is accepted on the master using
   salt-key.

   /etc/salt/master.d/reactor.conf:

      reactor:
        - 'salt/key':
          - /srv/salt/haproxy/react_new_minion.sls

   The Reactor then fires a :state.apply command targeted to  the  HAProxy
   servers and passes the ID of the new minion from the event to the state
   file via inline Pillar.

   /srv/salt/haproxy/react_new_minion.sls:

      {% if data['act'] == 'accept' and data['id'].startswith('web') %}
      add_new_minion_to_pool:
        local.state.apply:
          - tgt: 'haproxy*'
          - arg:
            - haproxy.refresh_pool
          - kwarg:
              pillar:
                new_minion: {{ data['id'] }}
      {% endif %}

   The above command is equivalent to the following command at the CLI:

      salt 'haproxy*' state.apply haproxy.refresh_pool 'pillar={new_minion: minionid}'

   This works with Orchestrate files as well:

      call_some_orchestrate_file:
        runner.state.orchestrate:
          - mods: some_orchestrate_file
          - pillar:
              stuff: things

   Which is equivalent to the following command at the CLI:

      salt-run state.orchestrate some_orchestrate_file pillar='{stuff: things}'

   Finally, that data is available in the  state  file  using  the  normal
   Pillar  lookup  syntax.  The  following  example is grabbing web server
   names and IP addresses from Salt Mine. If this state  is  invoked  from
   the  Reactor  then the custom Pillar value from above will be available
   and the new minion will be added to the pool but with the disabled flag
   so that HAProxy won't yet direct traffic to it.

   /srv/salt/haproxy/refresh_pool.sls:

      {% set new_minion = salt['pillar.get']('new_minion') %}

      listen web *:80
          balance source
          {% for server,ip in salt['mine.get']('web*', 'network.interfaces', ['eth0']).items() %}
          {% if server == new_minion %}
          server {{ server }} {{ ip }}:80 disabled
          {% else %}
          server {{ server }} {{ ip }}:80 check
          {% endif %}
          {% endfor %}

   A Complete Example
   In  this example, we're going to assume that we have a group of servers
   that will come online at random and need  to  have  keys  automatically
   accepted.  We'll  also  add  that  we  don't  want  all  servers  being
   automatically accepted. For this example, we'll assume that  all  hosts
   that  have  an id that starts with 'ink' will be automatically accepted
   and have state.apply executed. On top of this, we're going to add  that
   a  host  coming  up  that was replaced (meaning a new key) will also be
   accepted.

   Our master configuration  will  be  rather  simple.  All  minions  that
   attempte to authenticate will match the tag of salt/auth. When it comes
   to the minion key being accepted,  we  get  a  more  refined  tag  that
   includes the minion id, which we can use for matching.

   /etc/salt/master.d/reactor.conf:

      reactor:
        - 'salt/auth':
          - /srv/reactor/auth-pending.sls
        - 'salt/minion/ink*/start':
          - /srv/reactor/auth-complete.sls

   In  this  sls  file, we say that if the key was rejected we will delete
   the key on the master and then also tell the master to ssh  in  to  the
   minion  and  tell it to restart the minion, since a minion process will
   die if the key is rejected.

   We also say that if the key is pending and the id starts  with  ink  we
   will  accept  the  key.  A minion that is waiting on a pending key will
   retry authentication every ten seconds by default.

   /srv/reactor/auth-pending.sls:

      {# Ink server failed to authenticate -- remove accepted key #}
      {% if not data['result'] and data['id'].startswith('ink') %}
      minion_remove:
        wheel.key.delete:
          - match: {{ data['id'] }}
      minion_rejoin:
        local.cmd.run:
          - tgt: salt-master.domain.tld
          - arg:
            - ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "{{ data['id'] }}" 'sleep 10 && /etc/init.d/salt-minion restart'
      {% endif %}

      {# Ink server is sending new key -- accept this key #}
      {% if 'act' in data and data['act'] == 'pend' and data['id'].startswith('ink') %}
      minion_add:
        wheel.key.accept:
          - match: {{ data['id'] }}
      {% endif %}

   No if statements are needed here because we already limited this action
   to just Ink servers in the master configuration.

   /srv/reactor/auth-complete.sls:

      {# When an Ink server connects, run state.apply. #}
      highstate_run:
        local.state.apply:
          - tgt: {{ data['id'] }}
          - ret: smtp

   The  above  will  also  return  the  highstate  result  data  using the
   smtp_return returner (use virtualname like when using from the  command
   line with --return).  The returner needs to be configured on the minion
   for this to work.   See  salt.returners.smtp_return  documentation  for
   that.

   Syncing Custom Types on Minion Start
   Salt  will  sync  all  custom types (by running a saltutil.sync_all) on
   every highstate. However, there is a chicken-and-egg  issue  where,  on
   the  initial  highstate,  a minion will not yet have these custom types
   synced when the top file is first compiled. This can be  worked  around
   with a simple reactor which watches for minion_start events, which each
   minion fires when it first starts up and connects to the master.

   On the master, create /srv/reactor/sync_grains.sls with  the  following
   contents:

      sync_grains:
        local.saltutil.sync_grains:
          - tgt: {{ data['id'] }}

   And in the master config file, add the following reactor configuration:

      reactor:
        - 'minion_start':
          - /srv/reactor/sync_grains.sls

   This  will  cause the master to instruct each minion to sync its custom
   grains when it starts, making these grains available when  the  initial
   highstate is executed.

   Other  types can be synced by replacing local.saltutil.sync_grains with
   local.saltutil.sync_modules, local.saltutil.sync_all, or whatever  else
   suits the intended use case.

ORCHESTRATION

   Orchestrate Runner
   Orchestration is accomplished in salt primarily through the Orchestrate
   Runner. Added in version 0.17.0, this Salt  Runner  can  use  the  full
   suite   of  requisites  available  in  states,  and  can  also  execute
   states/functions using salt-ssh.

   The Orchestrate Runner
   New in version 0.17.0.

   NOTE:
      Orchestrate Deprecates OverState

      The Orchestrate Runner  (originally  called  the  state.sls  runner)
      offers  all  the  functionality  of  the  OverState,  but  with some
      advantages:

      * All requisites available in states can be used.

      * The states/functions will also work on salt-ssh minions.

      The Orchestrate Runner was  added  with  the  intent  to  eventually
      deprecate  the OverState system, however the OverState will still be
      maintained until Salt 2015.8.0.

   The orchestrate runner generalizes the Salt  state  system  to  a  Salt
   master   context.    Whereas  the  state.sls,  state.highstate,  et  al
   functions are concurrently and  independently  executed  on  each  Salt
   minion,  the state.orchestrate runner is executed on the master, giving
   it a master-level view and  control  over  requisites,  such  as  state
   ordering  and  conditionals.   This allows for inter minion requisites,
   like ordering the application of states on different minions that  must
   not  happen simultaneously, or for halting the state run on all minions
   if a minion fails one of its states.

   If you want to setup a load balancer in  front  of  a  cluster  of  web
   servers,  for example, you can ensure the load balancer is setup before
   the web servers or stop the state run altogether if one of the  minions
   does not set up correctly.

   The state.sls, state.highstate, et al functions allow you to statefully
   manage each minion and  the  state.orchestrate  runner  allows  you  to
   statefully manage your entire infrastructure.

   Executing the Orchestrate Runner
   The  Orchestrate Runner command format is the same as for the state.sls
   function, except that since  it  is  a  runner,  it  is  executed  with
   salt-run  rather  than salt.  Assuming you have a state.sls file called
   /srv/salt/orch/webserver.sls the following command run  on  the  master
   will apply the states defined in that file.

      salt-run state.orchestrate orch.webserver

   NOTE:
      state.orch is a synonym for state.orchestrate

   Changed  in  version  2014.1.1:  The  runner  function  was  renamed to
   state.orchestrate to  avoid  confusion  with  the  state.sls  execution
   function. In versions 0.17.0 through 2014.1.0, state.sls must be used.

   Masterless Orchestration
   New in version 2016.11.0.

   To  support  salt  orchestration on masterless minions, the Orchestrate
   Runner is available as an execution module. The syntax  for  masterless
   orchestration  is  exactly  the same, but it uses the salt-call command
   and the minion configuration must contain the file_mode: local  option.
   Alternatively, use salt-call --local on the command line.

      salt-call --local state.orchestrate orch.webserver

   NOTE:
      Masterless  orchestration supports only the salt.state command in an
      sls file; it does not (currently) support the salt.function command.

   Examples
   Function
   To execute a function, use salt.function:

      # /srv/salt/orch/cleanfoo.sls
      cmd.run:
        salt.function:
          - tgt: '*'
          - arg:
            - rm -rf /tmp/foo

      salt-run state.orchestrate orch.cleanfoo

   If you omit the "name" argument, the  ID  of  the  state  will  be  the
   default  name,  or  in  the case of salt.function, the execution module
   function  to  run.  You  can  specify  the  "name"  argument  to  avoid
   conflicting IDs:

      copy_some_file:
        salt.function:
          - name: file.copy
          - tgt: '*'
          - arg:
            - /path/to/file
            - /tmp/copy_of_file
          - kwarg:
              remove_existing: true

   State
   To execute a state, use salt.state.

      # /srv/salt/orch/webserver.sls
      install_nginx:
        salt.state:
          - tgt: 'web*'
          - sls:
            - nginx

      salt-run state.orchestrate orch.webserver

   Highstate
   To run a highstate, set highstate: True in your state config:

      # /srv/salt/orch/web_setup.sls
      webserver_setup:
        salt.state:
          - tgt: 'web*'
          - highstate: True

      salt-run state.orchestrate orch.web_setup

   More Complex Orchestration
   Many  states/functions  can  be configured in a single file, which when
   combined with the full suite of  requisites,  can  be  used  to  easily
   configure    complex    orchestration    tasks.    Additionally,    the
   states/functions will be executed  in  the  order  in  which  they  are
   defined,  unless  prevented  from doing so by any requisites, as is the
   default in SLS files since 0.17.0.

      bootstrap_servers:
        salt.function:
          - name: cmd.run
          - tgt: 10.0.0.0/24
          - tgt_type: ipcidr
          - arg:
            - bootstrap

      storage_setup:
        salt.state:
          - tgt: 'role:storage'
          - tgt_type: grain
          - sls: ceph
          - require:
            - salt: webserver_setup

      webserver_setup:
        salt.state:
          - tgt: 'web*'
          - highstate: True

   Given the above  setup,  the  orchestration  will  be  carried  out  as
   follows:

   1. The  shell  command bootstrap will be executed on all minions in the
      10.0.0.0/24 subnet.

   2. A Highstate will be run on all minions whose ID starts  with  "web",
      since the storage_setup state requires it.

   3. Finally,  the  ceph SLS target will be executed on all minions which
      have a grain called role with a value of storage.

   NOTE:
      Remember, salt-run is always executed on the master.

SALT SSH

   Getting Started
   Salt SSH is very easy to use, simply set up a basic roster file of  the
   systems  to  connect  to  and run salt-ssh commands in a similar way as
   standard salt commands.

   * Salt ssh is considered production ready in version 2014.7.0

   * Python is required on the remote system (unless using the  -r  option
     to send raw ssh commands)

   * On  many systems, the salt-ssh executable will be in its own package,
     usually named salt-ssh

   * The  Salt  SSH  system  does  not   supersede   the   standard   Salt
     communication systems, it simply offers an SSH-based alternative that
     does not require ZeroMQ and a remote agent. Be aware that  since  all
     communication  with  Salt SSH is executed via SSH it is substantially
     slower than standard Salt with ZeroMQ.

   * At the moment fileserver operations must be wrapped  to  ensure  that
     the  relevant  files  are  delivered with the salt-ssh commands.  The
     state module is an exception, which compiles the  state  run  on  the
     master,  and in the process finds all the references to salt:// paths
     and copies those files down in the same tarball  as  the  state  run.
     However, needed fileserver wrappers are still under development.

   Salt SSH Roster
   The  roster  system  in  Salt  allows  for  remote minions to be easily
   defined.

   NOTE:
      See the SSH roster docs for more details.

   Simply   create   the   roster   file,   the   default   location    is
   /etc/salt/roster:

      web1: 192.168.42.1

   This  is  a very basic roster file where a Salt ID is being assigned to
   an IP address. A more elaborate roster can be created:

      web1:
        host: 192.168.42.1 # The IP addr or DNS hostname
        user: fred         # Remote executions will be executed as user fred
        passwd: foobarbaz  # The password to use for login, if omitted, keys are used
        sudo: True         # Whether to sudo to root, not enabled by default
      web2:
        host: 192.168.42.2

   NOTE:
      sudo works only if NOPASSWD is set for user  in  /etc/sudoers:  fred
      ALL=(ALL) NOPASSWD: ALL

   Deploy ssh key for salt-ssh
   By  default, salt-ssh will generate key pairs for ssh, the default path
   will be /etc/salt/pki/master/ssh/salt-ssh.rsa

   You can use ssh-copy-id, (the OpenSSH key deployment  tool)  to  deploy
   keys to your servers.

      ssh-copy-id -i /etc/salt/pki/master/ssh/salt-ssh.rsa.pub [email protected]

   One  could also create a simple shell script, named salt-ssh-copy-id.sh
   as follows:

      #!/bin/bash
      if [ -z $1 ]; then
         echo $0 [email protected]
         exit 0
      fi
      ssh-copy-id -i /etc/salt/pki/master/ssh/salt-ssh.rsa.pub $1

   NOTE:
      Be certain to chmod +x salt-ssh-copy-id.sh.

      ./salt-ssh-copy-id.sh [email protected]
      ./salt-ssh-copy-id.sh [email protected]

   Once keys are successfully deployed, salt-ssh can be  used  to  control
   them.

   Alternatively  ssh  agent forwarding can be used by setting the priv to
   agent-forwarding.

   Calling Salt SSH
   NOTE:
      salt-ssh on RHEL/CentOS 5

      The salt-ssh command requires at least  python  2.6,  which  is  not
      installed  by  default on RHEL/CentOS 5.  An easy workaround in this
      situation is to use the -r option to run a raw  shell  command  that
      installs python26:

          salt-ssh centos-5-minion -r 'yum -y install epel-release ; yum -y install python26'

   The  salt-ssh  command can be easily executed in the same way as a salt
   command:

      salt-ssh '*' test.ping

   Commands with salt-ssh follow the same syntax as the salt command.

   The standard salt functions are available! The output is  the  same  as
   salt   and   many   of   the  same  flags  are  available.  Please  see
   http://docs.saltstack.com/ref/cli/salt-ssh.html   for   all   of    the
   available options.

   Raw Shell Calls
   By  default  salt-ssh runs Salt execution modules on the remote system,
   but salt-ssh can also execute raw shell commands:

      salt-ssh '*' -r 'ifconfig'

   States Via Salt SSH
   The Salt State system can also be used with salt-ssh. The state  system
   abstracts  the  same  interface to the user in salt-ssh as it does when
   using standard salt. The intent  is  that  Salt  Formulas  defined  for
   standard salt will work seamlessly with salt-ssh and vice-versa.

   The standard Salt States walkthroughs function by simply replacing salt
   commands with salt-ssh.

   Targeting with Salt SSH
   Due to the fact that the targeting approach differs in  salt-ssh,  only
   glob  and regex targets are supported as of this writing, the remaining
   target systems still need to be implemented.

   NOTE:
      By default, Grains are settable through salt-ssh. By default,  these
      grains will not be persisted across reboots.

      See the "thin_dir" setting in Roster documentation for more details.

   Configuring Salt SSH
   Salt  SSH  takes  its  configuration  from a master configuration file.
   Normally, this file is in /etc/salt/master. If  one  wishes  to  use  a
   customized  configuration  file,  the -c option to Salt SSH facilitates
   passing in a directory to look inside for a  configuration  file  named
   master.

   Minion Config
   New in version 2015.5.1.

   Minion  config  options  can  be  defined  globally  using  the  master
   configuration option ssh_minion_opts. It  can  also  be  defined  on  a
   per-minion basis with the minion_opts entry in the roster.

   Running Salt SSH as non-root user
   By default, Salt read all the configuration from /etc/salt/. If you are
   running Salt SSH with a regular user you have to modify some  paths  or
   you  will  get  "Permission  denied"  messages.  You have to modify two
   parameters: pki_dir and cachedir. Those should point  to  a  full  path
   writable for the user.

   It's  recommended  not  to  modify /etc/salt for this purpose. Create a
   private copy of /etc/salt for the user and  run  the  command  with  -c
   /new/config/path.

   Define CLI Options with Saltfile
   If  you are commonly passing in CLI options to salt-ssh, you can create
   a Saltfile to automatically use these options. This is common if you're
   managing several different salt projects on the same server.

   So  you  can cd into a directory that has a Saltfile with the following
   YAML contents:

      salt-ssh:
        config_dir: path/to/config/dir
        ssh_max_procs: 30
        ssh_wipe: True

   Instead of  having  to  call  salt-ssh  --config-dir=path/to/config/dir
   --max-procs=30 --wipe \* test.ping you can call salt-ssh \* test.ping.

   Boolean-style options should be specified in their YAML representation.

   NOTE:
      The  option keys specified must match the destination attributes for
      the       options       specified        in        the        parser
      salt.utils.parsers.SaltSSHOptionParser.  For example, in the case of
      the --wipe command  line  option,  its  dest  is  configured  to  be
      ssh_wipe and thus this is what should be configured in the Saltfile.
      Using the names of flags for this option, being  wipe:  True  or  w:
      True, will not work.

   NOTE:
      For  the  Saltfile to be automatically detected it needs to be named
      Saltfile with a capital S  and  be  readable  by  the  user  running
      salt-ssh.

   Debugging salt-ssh
   One common approach for debugging salt-ssh is to simply use the tarball
   that salt ships to the remote machine and call salt-call directly.

   To determine the location of salt-call, simply run  salt-ssh  with  the
   -ltrace flag and look for a line containing the string, SALT_ARGV. This
   contains the salt-call command that salt-ssh attempted to execute.

   It is recommended that one modify this command a bit by removing the -l
   quiet,  --metadata  and  --output  json  to get a better idea of what's
   going on on the target system.

   Salt Rosters
   Salt rosters are pluggable systems added in Salt 0.17.0  to  facilitate
   the  salt-ssh  system.   The roster system was created because salt-ssh
   needs a means to  identify  which  systems  need  to  be  targeted  for
   execution.

   SEE ALSO:
      all-salt.roster

   NOTE:
      The Roster System is not needed or used in standard Salt because the
      master does not need to be initially aware of target systems,  since
      the Salt Minion checks itself into the master.

   Since  the  roster  system  is pluggable, it can be easily augmented to
   attach to any existing systems to gather information about what servers
   are  presently  available  and  should  be  attached to by salt-ssh. By
   default the roster file is located at /etc/salt/roster.

   How Rosters Work
   The roster system compiles a data structure internally referred  to  as
   targets.  The  targets is a list of target systems and attributes about
   how to connect to said systems.  The  only  requirement  for  a  roster
   module in Salt is to return the targets data structure.

   Targets Data
   The  information  which  can  be  stored  in  a  roster  target  is the
   following:

      <Salt ID>:       # The id to reference the target system with
          host:        # The IP address or DNS name of the remote host
          user:        # The user to log in as
          passwd:      # The password to log in with

          # Optional parameters
          port:        # The target system's ssh port number
          sudo:        # Boolean to run command via sudo
          sudo_user:   # Str: Set this to execute Salt as a sudo user other than root.
                       # This user must be in the same system group as the remote user
                       # that is used to login and is specified above. Alternatively,
                       # the user must be a super-user.
          tty:         # Boolean: Set this option to True if sudo is also set to
                       # True and requiretty is also set on the target system
          priv:        # File path to ssh private key, defaults to salt-ssh.rsa
                       # The priv can also be set to agent-forwarding to not specify
                       # a key, but use ssh agent forwarding
          timeout:     # Number of seconds to wait for response when establishing
                       # an SSH connection
          minion_opts: # Dictionary of minion opts
          thin_dir:    # The target system's storage directory for Salt
                       # components. Defaults to /tmp/salt-<hash>.
          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)

   thin_dir
   Salt needs to upload a standalone environment to the target system, and
   this  defaults  to  /tmp/salt-<hash>. This directory will be cleaned up
   per normal systems operation.

   If you  need  a  persistent  Salt  environment,  for  instance  to  set
   persistent grains, this value will need to be changed.

SALT CLOUD

   Configuration
   Salt  Cloud provides a powerful interface to interact with cloud hosts.
   This interface  is  tightly  integrated  with  Salt,  and  new  virtual
   machines   are  automatically  connected  to  your  Salt  master  after
   creation.

   Since  Salt  Cloud  is  designed  to  be  an  automated  system,   most
   configuration is done using the following YAML configuration files:

   * /etc/salt/cloud:   The   main  configuration  file,  contains  global
     settings that apply to all cloud hosts. See Salt Cloud Configuration.

   * /etc/salt/cloud.providers.d/*.conf: Contains settings that  configure
     a  specific  cloud host, such as credentials, region settings, and so
     on. Since configuration varies significantly between each cloud host,
     a separate file should be created for each cloud host. In Salt Cloud,
     a provider is synonymous  with  a  cloud  host  (Amazon  EC2,  Google
     Compute Engine, Rackspace, and so on).  See Provider Specifics.

   * /etc/salt/cloud.profiles.d/*.conf:  Contains  settings  that define a
     specific VM type. A profile defines the systems specs and image,  and
     any  other  settings that are specific to this VM type. Each specific
     VM type is called a profile, and multiple profiles can be defined  in
     a  profile  file.   Each  profile  references  a parent provider that
     defines the cloud host in which  the  VM  is  created  (the  provider
     settings  are  in the provider configuration explained above).  Based
     on your needs, you might define different profiles for  web  servers,
     database servers, and so on. See VM Profiles.

   Configuration Inheritance
   Configuration  settings are inherited in order from the cloud config =>
   providers => profile.  [image]

   For example, if you wanted to  use  the  same  image  for  all  virtual
   machines for a specific provider, the image name could be placed in the
   provider file. This value is inherited by all profiles  that  use  that
   provider, but is overridden if a image name is defined in the profile.

   Most  configuration  settings  can  be  defined  in  any file, the main
   difference being how that setting is inherited.

   QuickStart
   The Salt Cloud Quickstart walks you through defining a provider,  a  VM
   profile, and shows you how to create virtual machines using Salt Cloud.

   Note  that  if  you  installed Salt via Salt Bootstrap, it may not have
   automatically installed salt-cloud for  you.  Use  your  distribution's
   package  manager  to  install the salt-cloud package from the same repo
   that you used to install Salt.  These repos will automatically be setup
   by Salt Bootstrap.

   If there is no salt-cloud package, install with pip install salt-cloud.

   Using Salt Cloud
   salt-cloud
   Provision virtual machines in the cloud with Salt

   Synopsis
      salt-cloud -m /etc/salt/cloud.map

      salt-cloud -m /etc/salt/cloud.map NAME

      salt-cloud -m /etc/salt/cloud.map NAME1 NAME2

      salt-cloud -p PROFILE NAME

      salt-cloud -p PROFILE NAME1 NAME2 NAME3 NAME4 NAME5 NAME6

   Description
   Salt  Cloud is the system used to provision virtual machines on various
   public clouds via a cleanly controlled profile and mapping system.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   Execution Options
   -L LOCATION, --location=LOCATION
          Specify which region to connect to.

   -a ACTION, --action=ACTION
          Perform an action that may be specific to this  cloud  provider.
          This  argument  requires  one  or  more  instance  names  to  be
          specified.

   -f <FUNC-NAME> <PROVIDER>, --function=<FUNC-NAME> <PROVIDER>
          Perform an function that may be specific to this cloud provider,
          that  does  not  apply  to an instance. This argument requires a
          provider to be specified (i.e.: nova).

   -p PROFILE, --profile=PROFILE
          Select a single profile to build the named cloud VMs  from.  The
          profile must be defined in the specified profiles file.

   -m MAP, --map=MAP
          Specify  a  map  file to use. If used without any other options,
          this option will ensure that all of the mapped VMs are  created.
          If the named VM already exists then it will be skipped.

   -H, --hard
          When  specifying  a  map file, the default behavior is to ensure
          that all of the VMs specified in the map file  are  created.  If
          the  --hard option is set, then any VMs that exist on configured
          cloud providers that are not specified in the map file  will  be
          destroyed.  Be  advised that this can be a destructive operation
          and should be used with care.

   -d, --destroy
          Pass in the name(s) of VMs to destroy,  salt-cloud  will  search
          the  configured  cloud  providers  for  the  specified names and
          destroy the VMs. Be advised that this is a destructive operation
          and  should  be  used with care. Can be used in conjunction with
          the -m option to specify a map of VMs to be deleted.

   -P, --parallel
          Normally  when  building  many  cloud  VMs  they  are   executed
          serially.  The  -P  option  will  run  each  cloud vm build in a
          separate process allowing for large groups of VMs to be build at
          once.

          Be  advised  that some cloud provider's systems don't seem to be
          well suited for this influx of vm creation. When creating  large
          groups of VMs watch the cloud provider carefully.

   -u, --update-bootstrap
          Update salt-bootstrap to the latest stable bootstrap release.

   -y, --assume-yes
          Default yes in answer to all confirmation questions.

   -k, --keep-tmp
          Do not remove files from /tmp/ after deploy.sh finishes.

   --show-deploy-args
          Include  the  options  used  to  deploy  the  minion in the data
          returned.

   --script-args=SCRIPT_ARGS
          Script  arguments  to  be  fed  to  the  bootstrap  script  when
          deploying the VM.

   Query Options
   -Q, --query
          Execute  a  query  and  return  some information about the nodes
          running on configured cloud providers

   -F, --full-query
          Execute a query and print out all  available  information  about
          all  cloud  VMs.   Can be used in conjunction with -m to display
          only information about the specified map.

   -S, --select-query
          Execute a query and print out  selected  information  about  all
          cloud  VMs.   Can be used in conjunction with -m to display only
          information about the specified map.

   --list-providers
          Display a list of configured providers.

   --list-profiles
          New in version 2014.7.0.

          Display a list of configured profiles. Pass in a cloud  provider
          to   view   the   provider's   associated   profiles,   such  as
          digital_ocean, or  pass  in  all  to  list  all  the  configured
          profiles.

   Cloud Providers Listings
   --list-locations=LIST_LOCATIONS
          Display  a  list  of  locations  available  in  configured cloud
          providers. Pass the cloud provider that available locations  are
          desired  on,  aka  "linode", or pass "all" to list locations for
          all configured cloud providers

   --list-images=LIST_IMAGES
          Display  a  list  of  images  available  in   configured   cloud
          providers.  Pass  the  cloud  provider that available images are
          desired on, aka "linode", or pass "all" to list images  for  all
          configured cloud providers

   --list-sizes=LIST_SIZES
          Display a list of sizes available in configured cloud providers.
          Pass the cloud provider that available sizes are desired on, aka
          "AWS",  or  pass  "all"  to  list sizes for all configured cloud
          providers

   Cloud Credentials
   --set-password=<USERNAME> <PROVIDER>
          Configure password for a cloud  provider  and  save  it  to  the
          keyring.   PROVIDER  can  be specified with or without a driver,
          for example: "--set-password bob  rackspace"  or  more  specific
          "--set-password bob rackspace:openstack" DEPRECATED!

   Output Options
   --out  Pass  in an alternative outputter to display the return of data.
          This outputter can be any of the available outputters:
             grains, highstate, json, key,  overstatestage,  pprint,  raw,
             txt, yaml

          Some  outputters  are  formatted  only  for  data  returned from
          specific functions; for instance, the grains outputter will  not
          work for non-grains data.

          If  an  outputter  is used that does not support the data passed
          into it, then Salt will fall back on the  pprint  outputter  and
          display the return data using the Python pprint standard library
          module.

          NOTE:
             If using --out=json, you will probably want --static as well.
             Without  the  static  option,  you  will  get a separate JSON
             string per minion which makes JSON output invalid as a whole.
             This  is  due to using an iterative outputter. So if you want
             to feed it to a JSON parser, use --static as well.

   --out-indent OUTPUT_INDENT, --output-indent OUTPUT_INDENT
          Print the output indented  by  the  provided  value  in  spaces.
          Negative   values   disable   indentation.  Only  applicable  in
          outputters that support indentation.

   --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
          Write the output to the specified file.

   --no-color
          Disable all colored output

   --force-color
          Force colored output

          NOTE:
             When using colored output the color codes are as follows:

             green denotes success,  red  denotes  failure,  blue  denotes
             changes  and  success  and  yellow  denotes a expected future
             change in configuration.

   Examples
   To create 4 VMs named web1, web2, db1, and db2 from specified profiles:

      salt-cloud -p fedora_rackspace web1 web2 db1 db2

   To read in a map file and create all VMs specified therein:

      salt-cloud -m /path/to/cloud.map

   To read in a map file and create all VMs specified therein in parallel:

      salt-cloud -m /path/to/cloud.map -P

   To delete any VMs specified in the map file:

      salt-cloud -m /path/to/cloud.map -d

   To delete any VMs NOT specified in the map file:

      salt-cloud -m /path/to/cloud.map -H

   To display the status of all VMs specified in the map file:

      salt-cloud -m /path/to/cloud.map -Q

   See also
   salt-cloud(7) salt(7) salt-master(1) salt-minion(1)

   Salt Cloud basic usage
   Salt Cloud needs, at least, one configured Provider and Profile  to  be
   functional.

   Creating a VM
   To create a VM with salt cloud, use command:

      salt-cloud -p <profile> name_of_vm

   Assuming there is a profile configured as following:

      fedora_rackspace:
          provider: my-rackspace-config
          image: Fedora 17
          size: 256 server
          script: bootstrap-salt

   Then, the command to create new VM named fedora_http_01 is:

      salt-cloud -p fedora_rackspace fedora_http_01

   Destroying a VM
   To destroy a created-by-salt-cloud VM, use command:

      salt-cloud -d name_of_vm

   For example, to delete the VM created on above example, use:

      salt-cloud -d fedora_http_01

   VM Profiles
   Salt cloud designates virtual machines inside the profile configuration
   file.     The    profile     configuration     file     defaults     to
   /etc/salt/cloud.profiles  and  is  a yaml configuration. The syntax for
   declaring profiles is simple:

      fedora_rackspace:
          provider: my-rackspace-config
          image: Fedora 17
          size: 256 server
          script: bootstrap-salt

   It should be noted that the script option defaults  to  bootstrap-salt,
   and  does  not  normally need to be specified. Further examples in this
   document will not show the script option.

   A few key pieces of information need to  be  declared  and  can  change
   based on the cloud provider. A number of additional parameters can also
   be inserted:

      centos_rackspace:
        provider: my-rackspace-config
        image: CentOS 6.2
        size: 1024 server
        minion:
          master: salt.example.com
          append_domain: webs.example.com
          grains:
            role: webserver

   The image must be selected from available images. Similarly, sizes must
   be  selected  from the list of sizes. To get a list of available images
   and sizes use the following command:

      salt-cloud --list-images openstack
      salt-cloud --list-sizes openstack

   Some parameters can be specified in the main Salt  cloud  configuration
   file and then are applied to all cloud profiles. For instance if only a
   single cloud provider is being used then the  provider  option  can  be
   declared in the Salt cloud configuration file.

   Multiple Configuration Files
   In addition to /etc/salt/cloud.profiles, profiles can also be specified
   in any file matching cloud.profiles.d/*conf which  is  a  sub-directory
   relative   to   the   profiles   configuration   file(with   the  above
   configuration file as an  example,  /etc/salt/cloud.profiles.d/*.conf).
   This  allows  for  more extensible configuration, and plays nicely with
   various configuration management  tools  as  well  as  version  control
   systems.

   Larger Example
      rhel_ec2:
        provider: my-ec2-config
        image: ami-e565ba8c
        size: t1.micro
        minion:
          cheese: edam

      ubuntu_ec2:
        provider: my-ec2-config
        image: ami-7e2da54e
        size: t1.micro
        minion:
          cheese: edam

      ubuntu_rackspace:
        provider: my-rackspace-config
        image: Ubuntu 12.04 LTS
        size: 256 server
        minion:
          cheese: edam

      fedora_rackspace:
        provider: my-rackspace-config
        image: Fedora 17
        size: 256 server
        minion:
          cheese: edam

      cent_linode:
        provider: my-linode-config
        image: CentOS 6.2 64bit
        size: Linode 512

      cent_gogrid:
        provider: my-gogrid-config
        image: 12834
        size: 512MB

      cent_joyent:
        provider: my-joyent-config
        image: centos-7
        size: g4-highram-16G

   Cloud Map File
   A  number  of options exist when creating virtual machines. They can be
   managed directly from profiles and the command  line  execution,  or  a
   more  complex map file can be created. The map file allows for a number
   of  virtual  machines  to  be  created  and  associated  with  specific
   profiles.  The map file is designed to be run once to create these more
   complex scenarios using salt-cloud.

   Map files have a simple format, specify a profile and then  a  list  of
   virtual machines to make from said profile:

      fedora_small:
        - web1
        - web2
        - web3
      fedora_high:
        - redis1
        - redis2
        - redis3
      cent_high:
        - riak1
        - riak2
        - riak3

   This  map  file  can  then  be  called to roll out all of these virtual
   machines. Map files are called from the salt-cloud command with the  -m
   option:

      $ salt-cloud -m /path/to/mapfile

   Remember, that as with direct profile provisioning the -P option can be
   passed to create the virtual machines in parallel:

      $ salt-cloud -m /path/to/mapfile -P

   NOTE:
      Due  to  limitations  in  the  GoGrid  API,  instances   cannot   be
      provisioned  in parallel with the GoGrid driver. Map files will work
      with GoGrid, but  the  -P  argument  should  not  be  used  on  maps
      referencing GoGrid instances.

   A map file can also be enforced to represent the total state of a cloud
   deployment by using the --hard option. When using the hard  option  any
   vms that exist but are not specified in the map file will be destroyed:

      $ salt-cloud -m /path/to/mapfile -P -H

   Be  careful with this argument, it is very dangerous! In fact, it is so
   dangerous that in order to use it, you must explicitly enable it in the
   main configuration file.

      enable_hard_maps: True

   A map file can include grains and minion configuration options:

      fedora_small:
        - web1:
            minion:
              log_level: debug
            grains:
              cheese: tasty
              omelet: du fromage
        - web2:
            minion:
              log_level: warn
            grains:
              cheese: more tasty
              omelet: with peppers

   A map file may also be used with the various query options:

      $ salt-cloud -m /path/to/mapfile -Q
      {'ec2': {'web1': {'id': 'i-e6aqfegb',
                           'image': None,
                           'private_ips': [],
                           'public_ips': [],
                           'size': None,
                           'state': 0}},
               'web2': {'Absent'}}

   ...or with the delete option:

      $ salt-cloud -m /path/to/mapfile -d
      The following virtual machines are set to be destroyed:
        web1
        web2

      Proceed? [N/y]

   WARNING:
      Specifying  Nodes  with Maps on the Command Line Specifying the name
      of a node or nodes with the maps options on the command line is  not
      supported.  This  is  especially  important  to  remember when using
      --destroy with maps; salt-cloud will ignore any arguments passed  in
      which  are  not  directly  relevant  to  the  map  file.  When using
      ``--destroy`` with a map,  every  node  in  the  map  file  will  be
      deleted!   Maps  don't provide any useful information for destroying
      individual nodes, and should not be used to destroy a  subset  of  a
      map.

   Setting up New Salt Masters
   Bootstrapping a new master in the map is as simple as:

      fedora_small:
        - web1:
            make_master: True
        - web2
        - web3

   Notice  that  ALL  bootstrapped minions from the map will answer to the
   newly created salt-master.

   To make any of the bootstrapped minions  answer  to  the  bootstrapping
   salt-master as opposed to the newly created salt-master, as an example:

      fedora_small:
        - web1:
            make_master: True
            minion:
              master: <the local master ip address>
              local_master: True
        - web2
        - web3

   The  above  says  the  minion  running on the newly created salt-master
   responds to the local master, ie, the master used  to  bootstrap  these
   VMs.

   Another example:

      fedora_small:
        - web1:
            make_master: True
        - web2
        - web3:
            minion:
              master: <the local master ip address>
              local_master: True

   The above example makes the web3 minion answer to the local master, not
   the newly created master.

   Cloud Actions
   Once a VM has been created, there are a number of actions that  can  be
   performed  on it. The "reboot" action can be used across all providers,
   but all other actions are specific to the cloud provider. In  order  to
   perform  an action, you may specify it from the command line, including
   the name(s) of the VM to perform the action on:

      $ salt-cloud -a reboot vm_name
      $ salt-cloud -a reboot vm1 vm2 vm2

   Or you may specify a map which includes all VMs to perform  the  action
   on:

      $ salt-cloud -a reboot -m /path/to/mapfile

   The following is a list of actions currently supported by salt-cloud:

      all providers:
          - reboot
      ec2:
          - start
          - stop
      joyent:
          - stop
      linode:
          - start
          - stop

   Another  useful  reference  for  viewing more salt-cloud actions is the
   :ref:Salt Cloud Feature Matrix <salt-cloud-feature-matrix>

   Cloud Functions
   Cloud functions work much the same way as cloud  actions,  except  that
   they  don't  perform an operation on a specific instance, and so do not
   need a machine name to be specified. However,  since  they  perform  an
   operation   on  a  specific  cloud  provider,  that  provider  must  be
   specified.

      $ salt-cloud -f show_image ec2 image=ami-fd20ad94

   There are three  universal  salt-cloud  functions  that  are  extremely
   useful for gathering information about instances on a provider basis:

   * list_nodes:  Returns some general information about the instances for
     the given provider.

   * list_nodes_full: Returns all information about the instances for  the
     given provider.

   * list_nodes_select: Returns select information about the instances for
     the given provider.

      $ salt-cloud -f list_nodes linode
      $ salt-cloud -f list_nodes_full linode
      $ salt-cloud -f list_nodes_select linode

   Another useful reference for viewing salt-cloud functions is  the  Salt
   Cloud Feature Matrix.

   Core Configuration
   Install Salt Cloud
   Salt  Cloud  is  now  part of Salt proper.  It was merged in as of Salt
   version 2014.1.0.

   On Ubuntu, install Salt Cloud by using following command:

      sudo add-apt-repository ppa:saltstack/salt
      sudo apt-get update
      sudo apt-get install salt-cloud

   If using  Salt  Cloud  on  OS  X,  curl-ca-bundle  must  be  installed.
   Presently,  this package is not available via brew, but it is available
   using MacPorts:

      sudo port install curl-ca-bundle

   Salt Cloud depends on apache-libcloud.  Libcloud can be  installed  via
   pip with pip install apache-libcloud.

   Installing Salt Cloud for development
   Installing Salt for development enables Salt Cloud development as well,
   just make sure apache-libcloud is installed as per above paragraph.

   See these instructions: Installing Salt for development.

   Core Configuration
   A number of core configuration options and some options that are global
   to  the  VM  profiles  can  be  set in the cloud configuration file. By
   default this file is located at /etc/salt/cloud.

   Thread Pool Size
   When salt cloud is operating in parallel mode via the -P argument,  you
   can  control the thread pool size by specifying the pool_size parameter
   with a positive integer value.

   By default, the thread pool size will be set to the number of VMs  that
   salt cloud is operating on.

      pool_size: 10

   Minion Configuration
   The  default  minion  configuration  is  set  up  in this file. Minions
   created by  salt-cloud  derive  their  configuration  from  this  file.
   Almost  all parameters found in Configuring the Salt Minion can be used
   here.

      minion:
        master: saltmaster.example.com

   In particular, this is the location to specify the location of the salt
   master and its listening port, if the port is not set to the default.

   Similar  to  most  other  settings,  Minion  configuration settings are
   inherited across configuration files. For example, the  master  setting
   might be contained in the main cloud configuration file as demonstrated
   above, but additional  settings  can  be  placed  in  the  provider  or
   profile:

      ec2-web:
        size: t1.micro
        minion:
          environment: test
          startup_states: sls
          sls_list:
            - web

   Cloud Configuration Syntax
   The data specific to interacting with public clouds is set up here.

   Cloud  provider  configuration settings can live in several places. The
   first is in /etc/salt/cloud:

      # /etc/salt/cloud
      providers:
        my-aws-migrated-config:
          id: HJGRYCILJLKJYG
          key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
          keyname: test
          securitygroup: quick-start
          private_key: /root/test.pem
          driver: ec2

   Cloud   provider   configuration   data   can   also   be   housed   in
   /etc/salt/cloud.providers        or       any       file       matching
   /etc/salt/cloud.providers.d/*.conf. All files in any of these locations
   will be parsed for cloud provider data.

   Using the example configuration above:

      # /etc/salt/cloud.providers
      # or could be /etc/salt/cloud.providers.d/*.conf
      my-aws-config:
        id: HJGRYCILJLKJYG
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        keyname: test
        securitygroup: quick-start
        private_key: /root/test.pem
        driver: ec2

   NOTE:
      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.  For example:

      production-config:
        - id: HJGRYCILJLKJYG
          key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
          keyname: test
          securitygroup: quick-start
          private_key: /root/test.pem
          driver: ec2

        - user: example_user
          apikey: 123984bjjas87034
          driver: rackspace

   However, using this configuration method requires a change with profile
   configuration blocks.  The provider alias needs to  have  the  provider
   key value appended as in the following example:

      rhel_aws_dev:
        provider: production-config:ec2
        image: ami-e565ba8c
        size: t1.micro

      rhel_aws_prod:
        provider: production-config:ec2
        image: ami-e565ba8c
        size: High-CPU Extra Large Instance

      database_prod:
        provider: production-config:rackspace
        image: Ubuntu 12.04 LTS
        size: 256 server

   Notice  that  because  of  the multiple entries, one has to be explicit
   about  the  provider  alias  and  name,   from   the   above   example,
   production-config: ec2.

   This  data  interactions  with  the  salt-cloud  binary  regarding  its
   --list-location, --list-images, and --list-sizes which  needs  a  cloud
   provider  as  an  argument.  The argument used should be the configured
   cloud provider alias. If  the  provider  alias  has  multiple  entries,
   <provider-alias>: <provider-name> should be used.

   To allow for a more extensible configuration, --providers-config, which
   defaults to /etc/salt/cloud.providers, was added to the cli parser.  It
   allows  for  the  providers'  configuration  to  be added on a per-file
   basis.

   Pillar Configuration
   It is possible to configure cloud providers using pillars. This is only
   used  when  inside  the  cloud  module. You can setup a variable called
   cloud that contains your profile and provider to pass that  information
   to  the  cloud servers instead of having to copy the full configuration
   to every minion. In your pillar file,  you  would  use  something  like
   this:

      cloud:
        ssh_key_name: saltstack
        ssh_key_file: /root/.ssh/id_rsa
        update_cachedir: True
        diff_cache_events: True
        change_password: True

        providers:
          my-nova:
            identity_url: https://identity.api.rackspacecloud.com/v2.0/
            compute_region: IAD
            user: myuser
            api_key: apikey
            tenant: 123456
            driver: nova

          my-openstack:
            identity_url: https://identity.api.rackspacecloud.com/v2.0/tokens
            user: user2
            apikey: apikey2
            tenant: 654321
            compute_region: DFW
            driver: openstack
            compute_name: cloudServersOpenStack

        profiles:
          ubuntu-nova:
            provider: my-nova
            size: performance1-8
            image: bb02b1a3-bc77-4d17-ab5b-421d89850fca
            script_args: git develop

          ubuntu-openstack:
            provider: my-openstack
            size: performance1-8
            image: bb02b1a3-bc77-4d17-ab5b-421d89850fca
            script_args: git develop

   Cloud Configurations
   Scaleway
   To  use  Salt Cloud with Scaleway, you need to get an access key and an
   API token. API tokens  are  unique  identifiers  associated  with  your
   Scaleway account.  To retrieve your access key and API token, log-in to
   the Scaleway control panel, open the pull-down  menu  on  your  account
   name and click on "My Credentials" link.

   If you do not have API token you can create one by clicking the "Create
   New Token" button on the right corner.

      my-scaleway-config:
        access_key: 15cf404d-4560-41b1-9a0c-21c3d5c4ff1f
        token: a7347ec8-5de1-4024-a5e3-24b77d1ba91d
        driver: scaleway

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax   for   the   provider  required  field  would  be  provider:
      my-scaleway-config.

   Rackspace
   Rackspace cloud requires two  configuration  options;  a  user  and  an
   apikey:

      my-rackspace-config:
        user: example_user
        apikey: 123984bjjas87034
        driver: rackspace

   NOTE:
      In  the  cloud  profile  that  uses this provider configuration, the
      syntax  for  the  provider  required  field   would   be   provider:
      my-rackspace-config.

   Amazon AWS
   A number of configuration options are required for Amazon AWS including
   id, key, keyname, securitygroup, and private_key:

      my-aws-quick-start:
        id: HJGRYCILJLKJYG
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        keyname: test
        securitygroup: quick-start
        private_key: /root/test.pem
        driver: ec2

      my-aws-default:
        id: HJGRYCILJLKJYG
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        keyname: test
        securitygroup: default
        private_key: /root/test.pem
        driver: ec2

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax  for  the  provider  required field would be either provider:
      my-aws-quick-start or provider: my-aws-default.

   Linode
   Linode requires a single API key, but the default  root  password  also
   needs to be set:

      my-linode-config:
        apikey: asldkgfakl;sdfjsjaslfjaklsdjf;askldjfaaklsjdfhasldsadfghdkf
        password: F00barbaz
        ssh_pubkey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKHEOLLbeXgaqRQT9NBAopVz366SdYc0KKX33vAnq+2R user@host
        ssh_key_file: ~/.ssh/id_ed25519
        driver: linode

   The password needs to be 8 characters and contain lowercase, uppercase,
   and numbers.

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax   for   the   provider  required  field  would  be  provider:
      my-linode-config

   Joyent Cloud
   The Joyent cloud requires three configuration parameters: The  username
   and  password  that  are used to log into the Joyent system, as well as
   the location of the private SSH key associated with the Joyent account.
   The  SSH  key  is  needed  to  send the provisioning commands up to the
   freshly created virtual machine.

      my-joyent-config:
        user: fred
        password: saltybacon
        private_key: /root/joyent.pem
        driver: joyent

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax   for   the   provider  required  field  would  be  provider:
      my-joyent-config

   GoGrid
   To use Salt Cloud with GoGrid, log into the GoGrid  web  interface  and
   create  an  API key. Do this by clicking on "My Account" and then going
   to the API Keys tab.

   The apikey and the sharedsecret configuration parameters need to be set
   in the configuration file to enable interfacing with GoGrid:

      my-gogrid-config:
        apikey: asdff7896asdh789
        sharedsecret: saltybacon
        driver: gogrid

   NOTE:
      In  the  cloud  profile  that  uses this provider configuration, the
      syntax  for  the  provider  required  field   would   be   provider:
      my-gogrid-config.

   OpenStack
   OpenStack  configuration  differs  between providers, and at the moment
   several options need to be specified. This module has  been  officially
   tested  against  the  HP  and  the  Rackspace implementations, and some
   examples are provided for both.

      # For HP
      my-openstack-hp-config:
        identity_url:
        'https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/'
        compute_name: Compute
        compute_region: 'az-1.region-a.geo-1'
        tenant: myuser-tenant1
        user: myuser
        ssh_key_name: mykey
        ssh_key_file: '/etc/salt/hpcloud/mykey.pem'
        password: mypass
        driver: openstack

      # For Rackspace
      my-openstack-rackspace-config:
        identity_url: 'https://identity.api.rackspacecloud.com/v2.0/tokens'
        compute_name: cloudServersOpenStack
        protocol: ipv4
        compute_region: DFW
        protocol: ipv4
        user: myuser
        tenant: 5555555
        password: mypass
        driver: openstack

   If you have an API key for your provider, it may be  specified  instead
   of a password:

      my-openstack-hp-config:
        apikey: 901d3f579h23c8v73q9

      my-openstack-rackspace-config:
        apikey: 901d3f579h23c8v73q9

   NOTE:
      In  the  cloud  profile  that  uses this provider configuration, the
      syntax for the provider required field  would  be  either  provider:
      my-openstack-hp-config or provider: my-openstack-rackspace-config.

   You  will  certainly  need  to  configure  the user, tenant, and either
   password or apikey.

   If your OpenStack instances only have private IP addresses and  a  CIDR
   range  of private addresses are not reachable from the salt-master, you
   may set your preference to have Salt ignore it:

      my-openstack-config:
        ignore_cidr: 192.168.0.0/16

   For  in-house  OpenStack  Essex  installation,   libcloud   needs   the
   service_type :

      my-openstack-config:
        identity_url: 'http://control.openstack.example.org:5000/v2.0/'
        compute_name : Compute Service
        service_type : compute

   DigitalOcean
   Using Salt for DigitalOcean requires a client_key and an api_key. These
   can be found in the DigitalOcean web interface, in  the  "My  Settings"
   section, under the API Access tab.

      my-digitalocean-config:
        driver: digital_ocean
        personal_access_token: xxx
        location: New York 1

   NOTE:
      In  the  cloud  profile  that  uses this provider configuration, the
      syntax  for  the  provider  required  field   would   be   provider:
      my-digital-ocean-config.

   Parallels
   Using  Salt with Parallels requires a user, password and URL. These can
   be obtained from your cloud provider.

      my-parallels-config:
        user: myuser
        password: xyzzy
        url: https://api.cloud.xmission.com:4465/paci/v1.0/
        driver: parallels

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax   for   the   provider  required  field  would  be  provider:
      my-parallels-config.

   Proxmox
   Using Salt with Proxmox requires a user, password, and URL.  These  can
   be obtained from your cloud host. Both PAM and PVE users can be used.

      my-proxmox-config:
        driver: proxmox
        user: saltcloud@pve
        password: xyzzy
        url: your.proxmox.host

   NOTE:
      In  the  cloud  profile  that  uses this provider configuration, the
      syntax  for  the  provider  required  field   would   be   provider:
      my-proxmox-config.

   LXC
   The  lxc  driver  uses  saltify  to  install  salt  and  attach the lxc
   container as a new lxc minion. As soon as we can, we  manage  baremetal
   operation  over  SSH.  You  can  also destroy those containers via this
   driver.

      devhost10-lxc:
        target: devhost10
        driver: lxc

   And in the map file:

      devhost10-lxc:
        provider: devhost10-lxc
        from_container: ubuntu
        backing: lvm
        sudo: True
        size: 3g
        ip: 10.0.3.9
        minion:
          master: 10.5.0.1
          master_port: 4506
        lxc_conf:
          - lxc.utsname: superlxc

   NOTE:
      In the cloud profile that  uses  this  provider  configuration,  the
      syntax   for   the   provider  required  field  would  be  provider:
      devhost10-lxc.

   Saltify
   The Saltify driver is a new, experimental driver  designed  to  install
   Salt on a remote machine, virtual or bare metal, using SSH. This driver
   is useful for provisioning machines which are  already  installed,  but
   not  Salted.  For  more  information  about  using  this driver and for
   configuration examples, please see the Gettting  Started  with  Saltify
   documentation.

   Extending Profiles and Cloud Providers Configuration
   As of 0.8.7, the option to extend both the profiles and cloud providers
   configuration and avoid duplication  was  added.  The  extends  feature
   works  on  the current profiles configuration, but, regarding the cloud
   providers configuration, only works in the new  syntax  and  respective
   configuration    files,    i.e.    /etc/salt/salt/cloud.providers    or
   /etc/salt/cloud.providers.d/*.conf.

   NOTE:
      Extending  cloud  profiles  and  providers  is  not  recursive.  For
      example, a profile that is extended by a second profile is possible,
      but the second profile cannot be extended by a third profile.

      Also, if a profile (or provider) is extending  another  profile  and
      each contains a list of values, the lists from the extending profile
      will override the list from the original profile. The lists are  not
      merged together.

   Extending Profiles
   Some  example  usage  on  how  to  use  extends with profiles. Consider
   /etc/salt/salt/cloud.profiles containing:

      development-instances:
        provider: my-ec2-config
        size: t1.micro
        ssh_username: ec2_user
        securitygroup:
          - default
        deploy: False

      Amazon-Linux-AMI-2012.09-64bit:
        image: ami-54cf5c3d
        extends: development-instances

      Fedora-17:
        image: ami-08d97e61
        extends: development-instances

      CentOS-5:
        provider: my-aws-config
        image: ami-09b61d60
        extends: development-instances

   The above configuration,  once  parsed  would  generate  the  following
   profiles data:

      [{'deploy': False,
        'image': 'ami-08d97e61',
        'profile': 'Fedora-17',
        'provider': 'my-ec2-config',
        'securitygroup': ['default'],
        'size': 't1.micro',
        'ssh_username': 'ec2_user'},
       {'deploy': False,
        'image': 'ami-09b61d60',
        'profile': 'CentOS-5',
        'provider': 'my-aws-config',
        'securitygroup': ['default'],
        'size': 't1.micro',
        'ssh_username': 'ec2_user'},
       {'deploy': False,
        'image': 'ami-54cf5c3d',
        'profile': 'Amazon-Linux-AMI-2012.09-64bit',
        'provider': 'my-ec2-config',
        'securitygroup': ['default'],
        'size': 't1.micro',
        'ssh_username': 'ec2_user'},
       {'deploy': False,
        'profile': 'development-instances',
        'provider': 'my-ec2-config',
        'securitygroup': ['default'],
        'size': 't1.micro',
        'ssh_username': 'ec2_user'}]

   Pretty cool right?

   Extending Providers
   Some  example  usage  on  how to use extends within the cloud providers
   configuration.  Consider /etc/salt/salt/cloud.providers containing:

      my-develop-envs:
        - id: HJGRYCILJLKJYG
          key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
          keyname: test
          securitygroup: quick-start
          private_key: /root/test.pem
          location: ap-southeast-1
          availability_zone: ap-southeast-1b
          driver: ec2

        - user: [email protected]
          password: mypass
          ssh_key_name: mykey
          ssh_key_file: '/etc/salt/ibm/mykey.pem'
          location: Raleigh
          driver: ibmsce

      my-productions-envs:
        - extends: my-develop-envs:ibmsce
          user: [email protected]
          location: us-east-1
          availability_zone: us-east-1

   The above configuration,  once  parsed  would  generate  the  following
   providers data:

      'providers': {
          'my-develop-envs': [
              {'availability_zone': 'ap-southeast-1b',
               'id': 'HJGRYCILJLKJYG',
               'key': 'kdjgfsgm;woormgl/aserigjksjdhasdfgn',
               'keyname': 'test',
               'location': 'ap-southeast-1',
               'private_key': '/root/test.pem',
               'driver': 'aws',
               'securitygroup': 'quick-start'
              },
              {'location': 'Raleigh',
               'password': 'mypass',
               'driver': 'ibmsce',
               'ssh_key_file': '/etc/salt/ibm/mykey.pem',
               'ssh_key_name': 'mykey',
               'user': '[email protected]'
              }
          ],
          'my-productions-envs': [
              {'availability_zone': 'us-east-1',
               'location': 'us-east-1',
               'password': 'mypass',
               'driver': 'ibmsce',
               'ssh_key_file': '/etc/salt/ibm/mykey.pem',
               'ssh_key_name': 'mykey',
               'user': '[email protected]'
              }
          ]
      }

   Windows Configuration
   Spinning up Windows Minions
   It is possible to use Salt Cloud to spin up Windows instances, and then
   install Salt on them. This functionality  is  available  on  all  cloud
   providers  that  are  supported  by  Salt  Cloud.  However,  it may not
   necessarily be available on all Windows images.

   Requirements
   Salt Cloud makes use of impacket and winexe to set up the Windows  Salt
   Minion installer.

   impacket   is   usually   available  as  either  the  impacket  or  the
   python-impacket  package,   depending   on   the   distribution.   More
   information on impacket can be found at the project home:

   * impacket project home

   winexe    is   less   commonly   available   in   distribution-specific
   repositories.   However,  it  is  currently  being  built  for  various
   distributions in 3rd party channels:

   * RPMs at pbone.net

   * openSUSE Build Service

   Optionally  WinRM  can  be  used instead of winexe if the python module
   pywinrm is available and WinRM  is  supported  on  the  target  Windows
   version. Information on pywinrm can be found at the project home:

   * pywinrm project home

   Additionally,  a  copy  of  the  Salt  Minion Windows installer must be
   present on the system on which Salt Cloud is  running.  This  installer
   may be downloaded from saltstack.com:

   * SaltStack Download Area

   Firewall Settings
   Because  Salt Cloud makes use of smbclient and winexe, port 445 must be
   open on the target image. This port is not generally open by default on
   a standard Windows distribution, and care must be taken to use an image
   in which this port is open, or the Windows firewall is disabled.

   If supported by the cloud provider, a PowerShell script may be used  to
   open  up  this port automatically, using the cloud provider's userdata.
   The following script would open up port 445, and apply the changes:

      <powershell>
      New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
      Set-Item (dir wsman:\localhost\Listener\*\Port -Recurse).pspath 445 -Force
      Restart-Service winrm
      </powershell>

   For EC2, this script may be saved as  a  file,  and  specified  in  the
   provider or profile configuration as userdata_file. For instance:

      userdata_file: /etc/salt/windows-firewall.ps1

   If you are using WinRM on EC2 the HTTPS port for the WinRM service must
   also be enabled in your userdata. By default EC2  Windows  images  only
   have  insecure  HTTP  enabled. To enable HTTPS and basic authentication
   required by pywinrm consider the following userdata example:

      <powershell>
      New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
      New-NetFirewallRule -Name "WINRM5986" -DisplayName "WINRM5986" -Protocol TCP -LocalPort 5986

      winrm quickconfig -q
      winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
      winrm set winrm/config '@{MaxTimeoutms="1800000"}'
      winrm set winrm/config/service/auth '@{Basic="true"}'

      $SourceStoreScope = 'LocalMachine'
      $SourceStorename = 'Remote Desktop'

      $SourceStore = New-Object  -TypeName System.Security.Cryptography.X509Certificates.X509Store  -ArgumentList $SourceStorename, $SourceStoreScope
      $SourceStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly)

      $cert = $SourceStore.Certificates | Where-Object  -FilterScript {
          $_.subject -like '*'
      }

      $DestStoreScope = 'LocalMachine'
      $DestStoreName = 'My'

      $DestStore = New-Object  -TypeName System.Security.Cryptography.X509Certificates.X509Store  -ArgumentList $DestStoreName, $DestStoreScope
      $DestStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
      $DestStore.Add($cert)

      $SourceStore.Close()
      $DestStore.Close()

      winrm create winrm/config/listener?Address=*+Transport=HTTPS  `@`{Hostname=`"($certId)`"`;CertificateThumbprint=`"($cert.Thumbprint)`"`}

      Restart-Service winrm
      </powershell>

   No certificate store is available by default on EC2 images and creating
   one does not seem possible without an MMC (cannot be automated). To use
   the default EC2 Windows images the above copies the RDP store.

   Configuration
   Configuration is set as usual, with some extra configuration  settings.
   The location of the Windows installer on the machine that Salt Cloud is
   running on must be specified. This may be done in any  of  the  regular
   configuration files (main, providers, profiles, maps). For example:

   Setting the installer in /etc/salt/cloud.providers:

      my-softlayer:
        driver: softlayer
        user: MYUSER1138
        apikey: 'e3b68aa711e6deadc62d5b76355674beef7cc3116062ddbacafe5f7e465bfdc9'
        minion:
          master: saltmaster.example.com
        win_installer: /root/Salt-Minion-2014.7.0-AMD64-Setup.exe
        win_username: Administrator
        win_password: letmein
        smb_port: 445

   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).

   Auto-Generated Passwords on EC2
   On EC2, when the win_password is set to auto, Salt Cloud will query EC2
   for an auto-generated password. This password is expected  to  take  at
   least  4  minutes  to  generate,  adding  additional time to the deploy
   process.

   When the EC2 API is queried for the auto-generated password, it will be
   returned  in  a  message  encrypted  with  the  specified keyname. This
   requires that the appropriate private_key file is also specified.  Such
   a profile configuration might look like:

      windows-server-2012:
        provider: my-ec2-config
        image: ami-c49c0dac
        size: m1.small
        securitygroup: windows
        keyname: mykey
        private_key: /root/mykey.pem
        userdata_file: /etc/salt/windows-firewall.ps1
        win_installer: /root/Salt-Minion-2014.7.0-AMD64-Setup.exe
        win_username: Administrator
        win_password: auto

   Cloud Provider Specifics
   Getting Started With Aliyun ECS
   The  Aliyun  ECS  (Elastic Computer Service) is one of the most popular
   public cloud hosts in China. This cloud host  can  be  used  to  manage
   aliyun instance using salt-cloud.

   http://www.aliyun.com/

   Dependencies
   This driver requires the Python requests library to be installed.

   Configuration
   Using Salt for Aliyun ECS requires aliyun access key id and key secret.
   These can be found in the aliyun web interface, in  the  "User  Center"
   section, under "My Service" tab.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-aliyun-config:
        # aliyun Access Key ID
        id: wDGEwGregedg3435gDgxd
        # aliyun Access Key Secret
        key: GDd45t43RDBTrkkkg43934t34qT43t4dgegerGEgg
        location: cn-qingdao
        driver: aliyun

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Profiles
   Cloud Profiles
   Set  up  an  initial  profile  at  /etc/salt/cloud.profiles  or  in the
   /etc/salt/cloud.profiles.d/ directory:

      aliyun_centos:
          provider: my-aliyun-config
          size: ecs.t1.small
          location: cn-qingdao
          securitygroup: G1989096784427999
          image: centos6u3_64_20G_aliaegis_20130816.vhd

   Sizes can be obtained using the --list-sizes option for the  salt-cloud
   command:

      # salt-cloud --list-sizes my-aliyun-config
      my-aliyun-config:
          ----------
          aliyun:
              ----------
              ecs.c1.large:
                  ----------
                  CpuCoreCount:
                      8
                  InstanceTypeId:
                      ecs.c1.large
                  MemorySize:
                      16.0

      ...SNIP...

   Images   can  be  obtained  using  the  --list-images  option  for  the
   salt-cloud command:

      # salt-cloud --list-images my-aliyun-config
      my-aliyun-config:
          ----------
          aliyun:
              ----------
              centos5u8_64_20G_aliaegis_20131231.vhd:
                  ----------
                  Architecture:
                      x86_64
                  Description:

                  ImageId:
                      centos5u8_64_20G_aliaegis_20131231.vhd
                  ImageName:
                      CentOS 5.8 64
                  ImageOwnerAlias:
                      system
                  ImageVersion:
                      1.0
                  OSName:
                      CentOS  5.8 64
                  Platform:
                      CENTOS5
                  Size:
                      20
                  Visibility:
                      public
      ...SNIP...

   Locations can be obtained using the  --list-locations  option  for  the
   salt-cloud command:

      my-aliyun-config:
          ----------
          aliyun:
              ----------
              cn-beijing:
                  ----------
                  LocalName:
                      
                  RegionId:
                      cn-beijing
              cn-hangzhou:
                  ----------
                  LocalName:
                      
                  RegionId:
                      cn-hangzhou
              cn-hongkong:
                  ----------
                  LocalName:
                      
                  RegionId:
                      cn-hongkong
              cn-qingdao:
                  ----------
                  LocalName:
                      
                  RegionId:
                      cn-qingdao

   Security  Group  can be obtained using the -f list_securitygroup option
   for the salt-cloud command:

      # salt-cloud --location=cn-qingdao -f list_securitygroup my-aliyun-config
      my-aliyun-config:
          ----------
          aliyun:
              ----------
              G1989096784427999:
                  ----------
                  Description:
                      G1989096784427999
                  SecurityGroupId:
                      G1989096784427999

   NOTE:
      Aliyun ECS REST API documentation is available from Aliyun ECS API.

   Getting Started With Azure
   New in version 2014.1.0.

   Azure is a cloud service by Microsoft providing virtual  machines,  SQL
   services,  media services, and more. This document describes how to use
   Salt Cloud to create a virtual machine on Azure, with Salt installed.

   More     information      about      Azure      is      located      at
   http://www.windowsazure.com/.

   Dependencies
   * Microsoft Azure SDK for Python >= 1.0.2

   * The python-requests library, for Python < 2.7.9.

   * A Microsoft Azure account

   * OpenSSL (to generate the certificates)

   * Salt

   NOTE:
      The  Azure  driver  is  currently being updated to work with the new
      version of the Python Azure SDK, 1.0.0. However until  that  process
      is  complete,  this driver will not work with Azure 1.0.0. Please be
      sure you're running on a minimum version of  0.10.2  and  less  than
      version 1.0.0.

      See Issue #27980 for more information.

   Configuration
   Set up the provider config at /etc/salt/cloud.providers.d/azure.conf:

      # Note: This example is for /etc/salt/cloud.providers.d/azure.conf

      my-azure-config:
        driver: azure
        subscription_id: 3287abc8-f98a-c678-3bde-326766fd3617
        certificate_path: /etc/salt/azure.pem

        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Optional
        management_host: management.core.windows.net

   The certificate used must be generated by the user. OpenSSL can be used
   to create the management certificates. Two certificates are  needed:  a
   .cer file, which is uploaded to Azure, and a .pem file, which is stored
   locally.

   To create the .pem file, execute the following command:

      openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/salt/azure.pem -out /etc/salt/azure.pem

   To create the .cer file, execute the following command:

      openssl x509 -inform pem -in /etc/salt/azure.pem -outform der -out /etc/salt/azure.cer

   After creating these files, the .cer file will need to be  uploaded  to
   Azure   via  the  "Upload  a  Management  Certificate"  action  of  the
   "Management Certificates" tab within  the  "Settings"  section  of  the
   management portal.

   Optionally,  a  management_host may be configured, if necessary for the
   region.

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Cloud Profiles
   Set up an initial profile at /etc/salt/cloud.profiles:

      azure-ubuntu:
        provider: my-azure-config
        image: 'b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-12_04_3-LTS-amd64-server-20131003-en-us-30GB'
        size: Small
        location: 'East US'
        ssh_username: azureuser
        ssh_password: verybadpass
        slot: production
        media_link: 'http://portalvhdabcdefghijklmn.blob.core.windows.net/vhds'
        virtual_network_name: azure-virtual-network
        subnet_name: azure-subnet

   These options are described in more detail below. Once configured,  the
   profile can be realized with a salt command:

      salt-cloud -p azure-ubuntu newinstance

   This will create an salt minion instance named newinstance in Azure. If
   the command  was  executed  on  the  salt-master,  its  Salt  key  will
   automatically be signed on the master.

   Once   the  instance  has  been  created  with  salt-minion  installed,
   connectivity to it can be verified with Salt:

      salt newinstance test.ping

   Profile Options
   The following options are currently available for Azure.

   provider
   The     name     of     the     provider     as      configured      in
   /etc/salt/cloud.providers.d/azure.conf.

   image
   The  name  of  the image to use to create a VM. Available images can be
   viewed using the following command:

      salt-cloud --list-images my-azure-config

   size
   The name of the size to use to create a  VM.  Available  sizes  can  be
   viewed using the following command:

      salt-cloud --list-sizes my-azure-config

   location
   The  name of the location to create a VM in. Available locations can be
   viewed using the following command:

      salt-cloud --list-locations my-azure-config

   affinity_group
   The name of the affinity group to create a VM in. Either a location  or
   an  affinity_group  may be specified, but not both. See Affinity Groups
   below.

   ssh_username
   The user to use to log into the newly-created VM to install Salt.

   ssh_password
   The password to use to log into the newly-created VM to install Salt.

   slot
   The environment to which the hosted service is deployed.  Valid  values
   are staging or production. When set to production, the resulting URL of
   the new VM will be <vm_name>.cloudapp.net. When  set  to  staging,  the
   resulting URL will contain a generated hash instead.

   media_link
   This  is the URL of the container that will store the disk that this VM
   uses.  Currently, this container  must  already  exist.  If  a  VM  has
   previously  been  created in the associated account, a container should
   already exist. In the web interface, go into the Storage area and click
   one of the available storage selections. Click the Containers link, and
   then copy the URL from the container that will be  used.  It  generally
   looks like:

      http://portalvhdabcdefghijklmn.blob.core.windows.net/vhds

   service_name
   The  name  of  the  service  in  which to create the VM. If this is not
   specified, then a service will be created with the same name as the VM.

   virtual_network_name
   Optional. The name of the virtual network for the VM to join.  If  this
   is not specified, then no virtual network will be joined.

   subnet_name
   Optional.  The  name of the subnet in the virtual network for the VM to
   join.  Requires that a virtual_network_name is specified.

   Show Instance
   This action is a  thin  wrapper  around  --full-query,  which  displays
   details  on  a  single  instance  only.  In an environment with several
   machines, this will save  a  user  from  having  to  sort  through  all
   instance data, just to examine a single instance.

      salt-cloud -a show_instance myinstance

   Destroying VMs
   There  are  certain  options which can be specified in the global cloud
   configuration file (usually /etc/salt/cloud) which affect Salt  Cloud's
   behavior when a VM is destroyed.

   cleanup_disks
   New in version 2015.8.0.

   Default  is False. When set to True, Salt Cloud will wait for the VM to
   be destroyed, then attempt to destroy the main disk that is  associated
   with the VM.

   cleanup_vhds
   New in version 2015.8.0.

   Default  is  False. Requires cleanup_disks to be set to True. When also
   set to True, Salt Cloud will ask Azure to  delete  the  VHD  associated
   with the disk that is also destroyed.

   cleanup_services
   New in version 2015.8.0.

   Default  is  False. Requires cleanup_disks to be set to True. When also
   set to True, Salt Cloud will wait for the disk to  be  destroyed,  then
   attempt  to  remove the service that is associated with the VM. Because
   the disk belongs to the service, the disk must be destroyed before  the
   service can be.

   Managing Hosted Services
   New in version 2015.8.0.

   An  account  can  have one or more hosted services. A hosted service is
   required in order to create a VM. However, as  mentioned  above,  if  a
   hosted  service  is  not  specified when a VM is created, then one will
   automatically be created with the  name  of  the  name.  The  following
   functions are also available.

   create_service
   Create a hosted service. The following options are available.

   name
   Required. The name of the hosted service to create.

   label
   Required. A label to apply to the hosted service.

   description
   Optional. A longer description of the hosted service.

   location
   Required, if affinity_group is not set. The location in which to create
   the hosted service. Either the location or the affinity_group  must  be
   set, but not both.

   affinity_group
   Required, if location is not set. The affinity group in which to create
   the hosted service. Either the location or the affinity_group  must  be
   set, but not both.

   extended_properties
   Optional.  Dictionary  containing  name/value  pairs  of hosted service
   properties.  You can have a maximum of 50 extended property  name/value
   pairs.  The  maximum  length of the Name element is 64 characters, only
   alphanumeric characters and underscores are valid in the Name, and  the
   name  must  start with a letter.  The value has a maximum length of 255
   characters.

   CLI Example
   The following example illustrates creating a hosted service.

      salt-cloud -f create_service my-azure name=my-service label=my-service location='West US'

   show_service
   Return details about a specific hosted service. Can also be called with
   get_service.

      salt-cloud -f show_storage my-azure name=my-service

   list_services
   List all hosted services associates with the subscription.

      salt-cloud -f list_services my-azure-config

   delete_service
   Delete a specific hosted service.

      salt-cloud -f delete_service my-azure name=my-service

   Managing Storage Accounts
   New in version 2015.8.0.

   Salt Cloud can manage storage accounts associated with the account. The
   following functions are available. Deprecated marked as deprecated  are
   marked as such as per the SDK documentation, but are still included for
   completeness with the SDK.

   create_storage
   Create a storage account. The following options are supported.

   name
   Required. The name of the storage account to create.

   label
   Required. A label to apply to the storage account.

   description
   Optional. A longer description of the storage account.

   location
   Required, if affinity_group is not set. The location in which to create
   the  storage account. Either the location or the affinity_group must be
   set, but not both.

   affinity_group
   Required, if location is not set. The affinity group in which to create
   the  storage account. Either the location or the affinity_group must be
   set, but not both.

   extended_properties
   Optional. Dictionary containing name/value  pairs  of  storage  account
   properties.   You can have a maximum of 50 extended property name/value
   pairs. The maximum length of the Name element is  64  characters,  only
   alphanumeric  characters and underscores are valid in the Name, and the
   name must start with a letter. The value has a maximum  length  of  255
   characters.

   geo_replication_enabled
   Deprecated. Replaced by the account_type parameter.

   account_type
   Specifies  whether  the  account  supports  locally-redundant  storage,
   geo-redundant  storage,  zone-redundant   storage,   or   read   access
   geo-redundant storage. Possible values are:

   * Standard_LRS

   * Standard_ZRS

   * Standard_GRS

   * Standard_RAGRS

   CLI Example
   The following example illustrates creating a storage account.

      salt-cloud -f create_storage my-azure name=my-storage label=my-storage location='West US'

   list_storage
   List all storage accounts associates with the subscription.

      salt-cloud -f list_storage my-azure-config

   show_storage
   Return  details  about  a  specific storage account. Can also be called
   with get_storage.

      salt-cloud -f show_storage my-azure name=my-storage

   update_storage
   Update details  concerning  a  storage  account.  Any  of  the  options
   available  in  create_storage  can  be  used,  but  the  name cannot be
   changed.

      salt-cloud -f update_storage my-azure name=my-storage label=my-storage

   delete_storage
   Delete a specific storage account.

      salt-cloud -f delete_storage my-azure name=my-storage

   show_storage_keys
   Returns the primary and secondary access keys for the specified storage
   account.

      salt-cloud -f show_storage_keys my-azure name=my-storage

   regenerate_storage_keys
   Regenerate  storage  account  keys.  Requires  a key_type ("primary" or
   "secondary") to be specified.

      salt-cloud -f regenerate_storage_keys my-azure name=my-storage key_type=primary

   Managing Disks
   New in version 2015.8.0.

   When a VM is created, a disk will also be created for it. The following
   functions  are  available  for  managing  disks.  Deprecated  marked as
   deprecated are marked as such as per the  SDK  documentation,  but  are
   still included for completeness with the SDK.

   show_disk
   Return details about a specific disk. Can also be called with get_disk.

      salt-cloud -f show_disk my-azure name=my-disk

   list_disks
   List all disks associates with the account.

      salt-cloud -f list_disks my-azure

   update_disk
   Update details for a disk. The following options are available.

   name
   Required. The name of the disk to update.

   has_operating_system
   Deprecated.

   label
   Required. The label for the disk.

   media_link
   Deprecated.  The  location  of  the  disk in the account, including the
   storage container that it is in. This should not need to be changed.

   new_name
   Deprecated. If renaming the disk, the new name.

   os
   Deprecated.

   CLI Example
   The following example illustrates updating a disk.

      salt-cloud -f update_disk my-azure name=my-disk label=my-disk

   delete_disk
   Delete a specific disk.

      salt-cloud -f delete_disk my-azure name=my-disk

   Managing Service Certificates
   New in version 2015.8.0.

   Stored at the cloud service level, these certificates are used by  your
   deployed  services.  For  more information on service certificates, see
   the following link:

   * Manage Certificates

   The following functions are available.

   list_service_certificates
   List service certificates associated with the account.

      salt-cloud -f list_service_certificates my-azure

   show_service_certificate
   Show the data for a specific service certificate  associated  with  the
   account.  The name, thumbprint, and thumbalgorithm can be obtained from
   list_service_certificates.     Can     also     be     called      with
   get_service_certificate.

      salt-cloud -f show_service_certificate my-azure name=my_service_certificate \
          thumbalgorithm=sha1 thumbprint=0123456789ABCDEF

   add_service_certificate
   Add  a  service  certificate  to  the  account.  This  requires  that a
   certificate already exists, which is then added  to  the  account.  For
   more information on creating the certificate itself, see:

   * Create a Service Certificate for Azure

   The following options are available.

   name
   Required.  The  name  of  the  hosted service that the certificate will
   belong to.

   data
   Required. The base-64 encoded form of the pfx file.

   certificate_format
   Required. The service certificate format. The only supported  value  is
   pfx.

   password
   The certificate password.

      salt-cloud -f add_service_certificate my-azure name=my-cert \
          data='...CERT_DATA...' certificate_format=pfx password=verybadpass

   delete_service_certificate
   Delete  a  service  certificate from the account. The name, thumbprint,
   and thumbalgorithm can be obtained from list_service_certificates.

      salt-cloud -f delete_service_certificate my-azure \
          name=my_service_certificate \
          thumbalgorithm=sha1 thumbprint=0123456789ABCDEF

   Managing Management Certificates
   New in version 2015.8.0.

   A Azure management certificate is  an  X.509  v3  certificate  used  to
   authenticate an agent, such as Visual Studio Tools for Windows Azure or
   a client application that uses the Service Management  API,  acting  on
   behalf  of  the  subscription  owner  to manage subscription resources.
   Azure management certificates are uploaded to Azure and stored  at  the
   subscription level. The management certificate store can hold up to 100
   certificates  per  subscription.  These  certificates   are   used   to
   authenticate your Windows Azure deployment.

   For  more  information  on  management  certificates, see the following
   link.

   * Manage Certificates

   The following functions are available.

   list_management_certificates
   List management certificates associated with the account.

      salt-cloud -f list_management_certificates my-azure

   show_management_certificate
   Show the data for a specific management certificate associated with the
   account.  The name, thumbprint, and thumbalgorithm can be obtained from
   list_management_certificates.    Can    also     be     called     with
   get_management_certificate.

      salt-cloud -f show_management_certificate my-azure name=my_management_certificate \
          thumbalgorithm=sha1 thumbprint=0123456789ABCDEF

   add_management_certificate
   Management  certificates  must  have a key length of at least 2048 bits
   and  should  reside  in  the  Personal  certificate  store.  When   the
   certificate  is  installed on the client, it should contain the private
   key of the certificate. To upload to the certificate to  the  Microsoft
   Azure  Management Portal, you must export it as a .cer format file that
   does not contain the private key.  For  more  information  on  creating
   management certificates, see the following link:

   * Create and Upload a Management Certificate for Azure

   The following options are available.

   public_key
   A base64 representation of the management certificate public key.

   thumbprint
   The thumb print that uniquely identifies the management certificate.

   data
   The certificate's raw data in base-64 encoded .cer format.

      salt-cloud -f add_management_certificate my-azure public_key='...PUBKEY...' \
          thumbprint=0123456789ABCDEF data='...CERT_DATA...'

   delete_management_certificate
   Delete a management certificate from the account. The thumbprint can be
   obtained from list_management_certificates.

      salt-cloud -f delete_management_certificate my-azure thumbprint=0123456789ABCDEF

   Virtual Network Management
   New in version 2015.8.0.

   The following are functions for managing virtual networks.

   list_virtual_networks
   List input endpoints associated with the deployment.

      salt-cloud -f list_virtual_networks my-azure service=myservice deployment=mydeployment

   Managing Input Endpoints
   New in version 2015.8.0.

   Input endpoints are used to  manage  port  access  for  roles.  Because
   endpoints  cannot  be  managed by the Azure Python SDK, Salt Cloud uses
   the  API  directly.   With  versions  of  Python  before   2.7.9,   the
   requests-python  package  needs  to  be  installed in order for this to
   work. Additionally, the following needs  to  be  set  in  the  master's
   configuration file:

      backend: requests

   The following functions are available.

   list_input_endpoints
   List input endpoints associated with the deployment

      salt-cloud -f list_input_endpoints my-azure service=myservice deployment=mydeployment

   show_input_endpoint
   Show an input endpoint associated with the deployment

      salt-cloud -f show_input_endpoint my-azure service=myservice \
          deployment=mydeployment name=SSH

   add_input_endpoint
   Add  an input endpoint to the deployment. Please note that there may be
   a  delay  before  the  changes  show  up.  The  following  options  are
   available.

   service
   Required. The name of the hosted service which the VM belongs to.

   deployment
   Required.  The name of the deployment that the VM belongs to. If the VM
   was created with Salt Cloud, the deployment name probably  matches  the
   VM name.

   role
   Required.  The  name  of the role that the VM belongs to. If the VM was
   created with Salt Cloud, the role name probably matches the VM name.

   name
   Required. The name of the input endpoint. This  typically  matches  the
   port that the endpoint is set to. For instance, port 22 would be called
   SSH.

   port
   Required. The public  (Internet-facing)  port  that  is  used  for  the
   endpoint.

   local_port
   Optional.  The  private port on the VM itself that will be matched with
   the port.  This is typically the same as the port. If this value is not
   specified, it will be copied from port.

   protocol
   Required. Either tcp or udp.

   enable_direct_server_return
   Optional. If an internal load balancer exists in the account, it can be
   used with a direct server return. The default value  is  False.  Please
   see the following article for an explanation of this option.

   * Load Balancing for Azure Infrastructure Services

   timeout_for_tcp_idle_connection
   Optional.  The default value is 4. Please see the following article for
   an explanation of this option.

   * Configurable Idle Timeout for Azure Load Balancer

   CLI Example
   The following example illustrates adding an input endpoint.

      salt-cloud -f add_input_endpoint my-azure service=myservice \
          deployment=mydeployment role=myrole name=HTTP local_port=80 \
          port=80 protocol=tcp enable_direct_server_return=False \
          timeout_for_tcp_idle_connection=4

   update_input_endpoint
   Updates the details for a specific input  endpoint.  All  options  from
   add_input_endpoint are supported.

      salt-cloud -f update_input_endpoint my-azure service=myservice \
          deployment=mydeployment role=myrole name=HTTP local_port=80 \
          port=80 protocol=tcp enable_direct_server_return=False \
          timeout_for_tcp_idle_connection=4

   delete_input_endpoint
   Delete  an  input  endpoint from the deployment. Please note that there
   may be a delay before the changes show up.   The  following  items  are
   required.

   CLI Example
   The following example illustrates deleting an input endpoint.

   service
   The name of the hosted service which the VM belongs to.

   deployment
   The  name  of  the  deployment  that  the  VM belongs to. If the VM was
   created with Salt Cloud, the deployment name probably  matches  the  VM
   name.

   role
   The name of the role that the VM belongs to. If the VM was created with
   Salt Cloud, the role name probably matches the VM name.

   name
   The name of the input endpoint. This typically matches  the  port  that
   the endpoint is set to. For instance, port 22 would be called SSH.

      salt-cloud -f delete_input_endpoint my-azure service=myservice \
          deployment=mydeployment role=myrole name=HTTP

   Managing Affinity Groups
   New in version 2015.8.0.

   Affinity  groups  allow  you  to  group your Azure services to optimize
   performance.  All services and VMs within an  affinity  group  will  be
   located  in  the  same region. For more information on Affinity groups,
   see the following link:

   * Create an Affinity Group in the Management Portal

   The following functions are available.

   list_affinity_groups
   List input endpoints associated with the account

      salt-cloud -f list_affinity_groups my-azure

   show_affinity_group
   Show an affinity group associated with the account

      salt-cloud -f show_affinity_group my-azure service=myservice \
          deployment=mydeployment name=SSH

   create_affinity_group
   Create a new affinity group. The following options are supported.

   name
   Required. The name of the new affinity group.

   location
   Required. The region in which the affinity group lives.

   label
   Required. A label describing the new affinity group.

   description
   Optional. A longer description of the affinity group.

      salt-cloud -f create_affinity_group my-azure name=my_affinity_group \
         label=my-affinity-group location='West US'

   update_affinity_group
   Update an affinity group's properties

      salt-cloud -f update_affinity_group my-azure name=my_group label=my_group

   delete_affinity_group
   Delete a specific affinity group associated with the account

      salt-cloud -f delete_affinity_group my-azure name=my_affinity_group

   Managing Blob Storage
   New in version 2015.8.0.

   Azure storage containers and their contents can be  managed  with  Salt
   Cloud.  This  is  not  as  elegant  as using one of the other available
   clients in Windows, but it benefits Linux and Unix users, as there  are
   fewer options available on those platforms.

   Blob Storage Configuration
   Blob  storage  must  be  configured differently than the standard Azure
   configuration.  Both  a  storage_account  and  a  storage_key  must  be
   specified  either through the Azure provider configuration (in addition
   to the other Azure configuration) or via the command line.

      storage_account: mystorage
      storage_key: ffhj334fDSGFEGDFGFDewr34fwfsFSDFwe==

   storage_account
   This is  one  of  the  storage  accounts  that  is  available  via  the
   list_storage function.

   storage_key
   Both  a  primary and a secondary storage_key can be obtained by running
   the show_storage_keys function. Either key may be used.

   Blob Functions
   The following functions are  made  available  through  Salt  Cloud  for
   managing blog storage.

   make_blob_url
   Creates the URL to access a blob

      salt-cloud -f make_blob_url my-azure container=mycontainer blob=myblob

   container
   Name of the container.

   blob
   Name of the blob.

   account
   Name  of  the  storage account. If not specified, derives the host base
   from the provider configuration.

   protocol
   Protocol to use: 'http' or 'https'. If not specified, derives the  host
   base from the provider configuration.

   host_base
   Live  host  base URL.  If not specified, derives the host base from the
   provider configuration.

   list_storage_containers
   List containers associated with the storage account

      salt-cloud -f list_storage_containers my-azure

   create_storage_container
   Create a storage container

      salt-cloud -f create_storage_container my-azure name=mycontainer

   name
   Name of container to create.

   meta_name_values
   Optional. A dict with name_value pairs to associate with the  container
   as metadata. Example:{'Category':'test'}

   blob_public_access
   Optional. Possible values include: container, blob

   fail_on_exist
   Specify whether to throw an exception when the container exists.

   show_storage_container
   Show a container associated with the storage account

      salt-cloud -f show_storage_container my-azure name=myservice

   name
   Name of container to show.

   show_storage_container_metadata
   Show a storage container's metadata

      salt-cloud -f show_storage_container_metadata my-azure name=myservice

   name
   Name of container to show.

   lease_id
   If  specified,  show_storage_container_metadata  only  succeeds  if the
   container's lease is active and matches this ID.

   set_storage_container_metadata
   Set a storage container's metadata

      salt-cloud -f set_storage_container my-azure name=mycontainer \
          x_ms_meta_name_values='{"my_name": "my_value"}'

   name
   Name of  existing  container.   meta_name_values  ````````````  A  dict
   containing  name,  value  for  metadata.   Example: {'category':'test'}
   lease_id  ````  If   specified,   set_storage_container_metadata   only
   succeeds if the container's lease is active and matches this ID.

   show_storage_container_acl
   Show a storage container's acl

      salt-cloud -f show_storage_container_acl my-azure name=myservice

   name
   Name of existing container.

   lease_id
   If   specified,   show_storage_container_acl   only   succeeds  if  the
   container's lease is active and matches this ID.

   set_storage_container_acl
   Set a storage container's acl

      salt-cloud -f set_storage_container my-azure name=mycontainer

   name
   Name of existing container.

   signed_identifiers
   SignedIdentifers instance

   blob_public_access
   Optional. Possible values include: container, blob

   lease_id
   If  specified,   set_storage_container_acl   only   succeeds   if   the
   container's lease is active and matches this ID.

   delete_storage_container
   Delete a container associated with the storage account

      salt-cloud -f delete_storage_container my-azure name=mycontainer

   name
   Name of container to create.

   fail_not_exist
   Specify whether to throw an exception when the container exists.

   lease_id
   If specified, delete_storage_container only succeeds if the container's
   lease is active and matches this ID.

   lease_storage_container
   Lease a container associated with the storage account

      salt-cloud -f lease_storage_container my-azure name=mycontainer

   name
   Name of container to create.

   lease_action
   Required. Possible values: acquire|renew|release|break|change

   lease_id
   Required if the container has an active lease.

   lease_duration
   Specifies the duration of the lease, in seconds, or negative  one  (-1)
   for  a lease that never expires. A non-infinite lease can be between 15
   and 60 seconds. A lease duration  cannot  be  changed  using  renew  or
   change.  For  backwards compatibility, the default is 60, and the value
   is only used on an acquire operation.

   lease_break_period
   Optional. For a break operation,  this  is  the  proposed  duration  of
   seconds  that  the lease should continue before it is broken, between 0
   and 60 seconds. This break period is only used if it  is  shorter  than
   the  time  remaining on the lease. If longer, the time remaining on the
   lease is used. A new lease will  not  be  available  before  the  break
   period has expired, but the lease may be held for longer than the break
   period. If this header does  not  appear  with  a  break  operation,  a
   fixed-duration  lease  breaks after the remaining lease period elapses,
   and an infinite lease breaks immediately.

   proposed_lease_id
   Optional for acquire, required for change. Proposed lease ID, in a GUID
   string format.

   list_blobs
   List blobs associated with the container

      salt-cloud -f list_blobs my-azure container=mycontainer

   container
   The name of the storage container

   prefix
   Optional.  Filters  the  results to return only blobs whose names begin
   with the specified prefix.

   marker
   Optional. A string value that identifies the portion of the list to  be
   returned  with  the next list operation. The operation returns a marker
   value within the response body if the list returned was  not  complete.
   The  marker  value may then be used in a subsequent call to request the
   next set of list items. The marker value is opaque to the client.

   maxresults
   Optional. Specifies the maximum number of blobs  to  return,  including
   all  BlobPrefix elements. If the request does not specify maxresults or
   specifies a value greater than 5,000, the  server  will  return  up  to
   5,000  items.  Setting maxresults to a value less than or equal to zero
   results in error response code 400 (Bad Request).

   include
   Optional. Specifies one or more datasets to include in the response. To
   specify  more  than  one of these options on the URI, you must separate
   each option with a comma. Valid values are:

      snapshots:
          Specifies that snapshots should be included in the
          enumeration. Snapshots are listed from oldest to newest in
          the response.
      metadata:
          Specifies that blob metadata be returned in the response.
      uncommittedblobs:
          Specifies that blobs for which blocks have been uploaded,
          but which have not been committed using Put Block List
          (REST API), be included in the response.
      copy:
          Version 2012-02-12 and newer. Specifies that metadata
          related to any current or previous Copy Blob operation
          should be included in the response.

   delimiter
   Optional. When the  request  includes  this  parameter,  the  operation
   returns  a  BlobPrefix  element  in  the  response  body that acts as a
   placeholder for all blobs whose names begin with the same substring  up
   to  the  appearance  of the delimiter character. The delimiter may be a
   single character or a string.

   show_blob_service_properties
   Show a blob's service properties

      salt-cloud -f show_blob_service_properties my-azure

   set_blob_service_properties
   Sets the properties of a  storage  account's  Blob  service,  including
   Windows Azure Storage Analytics. You can also use this operation to set
   the default request version for all incoming requests that do not  have
   a version specified.

      salt-cloud -f set_blob_service_properties my-azure

   properties
   a StorageServiceProperties object.

   timeout
   Optional. The timeout parameter is expressed in seconds.

   show_blob_properties
   Returns all user-defined metadata, standard HTTP properties, and system
   properties for the blob.

      salt-cloud -f show_blob_properties my-azure container=mycontainer blob=myblob

   container
   Name of existing container.

   blob
   Name of existing blob.

   lease_id
   Required if the blob has an active lease.

   set_blob_properties
   Set a blob's properties

      salt-cloud -f set_blob_properties my-azure

   container
   Name of existing container.

   blob
   Name of existing blob.

   blob_cache_control
   Optional. Modifies the cache control string for the blob.

   blob_content_type
   Optional. Sets the blob's content type.

   blob_content_md5
   Optional. Sets the blob's MD5 hash.

   blob_content_encoding
   Optional. Sets the blob's content encoding.

   blob_content_language
   Optional. Sets the blob's content language.

   lease_id
   Required if the blob has an active lease.

   blob_content_disposition
   Optional.   Sets   the   blob's   Content-Disposition   header.     The
   Content-Disposition    response   header   field   conveys   additional
   information about how to process the response payload, and also can  be
   used  to attach additional metadata. For example, if set to attachment,
   it indicates that the user-agent should not display the  response,  but
   instead  show a Save As dialog with a filename other than the blob name
   specified.

   put_blob
   Upload a blob

      salt-cloud -f put_blob my-azure container=base name=top.sls blob_path=/srv/salt/top.sls
      salt-cloud -f put_blob my-azure container=base name=content.txt blob_content='Some content'

   container
   Name of existing container.

   name
   Name of existing blob.

   blob_path
   The path on the local machine of the file to upload as a  blob.  Either
   this or blob_content must be specified.

   blob_content
   The  actual  content to be uploaded as a blob. Either this or blob_path
   must me specified.

   cache_control
   Optional. The Blob service stores this value but does not use or modify
   it.

   content_language
   Optional. Specifies the natural languages used by this resource.

   content_md5
   Optional.  An MD5 hash of the blob content. This hash is used to verify
   the integrity of  the  blob  during  transport.  When  this  header  is
   specified,  the  storage  service checks the hash that has arrived with
   the one that was sent. If the two hashes do not  match,  the  operation
   will fail with error code 400 (Bad Request).

   blob_content_type
   Optional. Set the blob's content type.

   blob_content_encoding
   Optional. Set the blob's content encoding.

   blob_content_language
   Optional. Set the blob's content language.

   blob_content_md5
   Optional. Set the blob's MD5 hash.

   blob_cache_control
   Optional. Sets the blob's cache control.

   meta_name_values
   A dict containing name, value for metadata.

   lease_id
   Required if the blob has an active lease.

   get_blob
   Download a blob

      salt-cloud -f get_blob my-azure container=base name=top.sls local_path=/srv/salt/top.sls
      salt-cloud -f get_blob my-azure container=base name=content.txt return_content=True

   container
   Name of existing container.

   name
   Name of existing blob.

   local_path
   The  path  on the local machine to download the blob to. Either this or
   return_content must be specified.

   return_content
   Whether or not to  return  the  content  directly  from  the  blob.  If
   specified, must be True or False. Either this or the local_path must be
   specified.

   snapshot
   Optional. The snapshot parameter is an opaque DateTime value that, when
   present, specifies the blob snapshot to retrieve.

   lease_id
   Required if the blob has an active lease.

   progress_callback
   callback  for  progress  with  signature function(current, total) where
   current is the number of bytes transferred so far,  and  total  is  the
   size of the blob.

   max_connections
   Maximum  number  of  parallel  connections  to  use  when the blob size
   exceeds 64MB.  Set to 1 to download the blob chunks sequentially.   Set
   to  2  or  more to download the blob chunks in parallel. This uses more
   system resources but will download faster.

   max_retries
   Number of times to retry download of blob chunk if an error occurs.

   retry_wait
   Sleep time in secs between retries.

   Getting Started With DigitalOcean
   DigitalOcean  is  a  public  cloud  host  that  specializes  in   Linux
   instances.

   Configuration
   Using  Salt  for  DigitalOcean  requires  a  personal_access_token,  an
   ssh_key_file, and at least one SSH  key  name  in  ssh_key_names.  More
   ssh_key_names  can  be  added  by separating each key with a comma. The
   personal_access_token can be found in the DigitalOcean web interface in
   the  "Apps & API" section. The SSH key name can be found under the "SSH
   Keys" section.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-digitalocean-config:
        driver: digital_ocean
        personal_access_token: xxx
        ssh_key_file: /path/to/ssh/key/file
        ssh_key_names: my-key-name,my-key-name-2
        location: New York 1

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Profiles
   Cloud Profiles
   Set up  an  initial  profile  at  /etc/salt/cloud.profiles  or  in  the
   /etc/salt/cloud.profiles.d/ directory:

      digitalocean-ubuntu:
        provider: my-digitalocean-config
        image: 14.04 x64
        size: 512MB
        location: New York 1
        private_networking: True
        backups_enabled: True
        ipv6: True
        create_dns_record: True

   Locations  can  be  obtained  using the --list-locations option for the
   salt-cloud command:

      # salt-cloud --list-locations my-digitalocean-config
      my-digitalocean-config:
          ----------
          digital_ocean:
              ----------
              Amsterdam 1:
                  ----------
                  available:
                      False
                  features:
                      [u'backups']
                  name:
                      Amsterdam 1
                  sizes:
                      []
                  slug:
                      ams1
      ...SNIP...

   Sizes can be obtained using the --list-sizes option for the  salt-cloud
   command:

      # salt-cloud --list-sizes my-digitalocean-config
      my-digitalocean-config:
          ----------
          digital_ocean:
              ----------
              512MB:
                  ----------
                  cost_per_hour:
                      0.00744
                  cost_per_month:
                      5.0
                  cpu:
                      1
                  disk:
                      20
                  id:
                      66
                  memory:
                      512
                  name:
                      512MB
                  slug:
                      None
      ...SNIP...

   Images   can  be  obtained  using  the  --list-images  option  for  the
   salt-cloud command:

      # salt-cloud --list-images my-digitalocean-config
      my-digitalocean-config:
          ----------
          digital_ocean:
              ----------
              10.1:
                  ----------
                  created_at:
                      2015-01-20T20:04:34Z
                  distribution:
                      FreeBSD
                  id:
                      10144573
                  min_disk_size:
                      20
                  name:
                      10.1
                  public:
                      True
      ...SNIP...

   Profile Specifics:
   ssh_username
   If using a FreeBSD image from Digital Ocean, you'll  need  to  set  the
   ssh_username setting to freebsd in your profile configuration.

      digitalocean-freebsd:
        provider: my-digitalocean-config
        image: 10.2
        size: 512MB
        ssh_username: freebsd

   Miscellaneous Information
   NOTE:
      DigitalOcean's  concept  of  Applications  is  nothing  more  than a
      pre-configured instance (same as a normal Droplet).  You  will  find
      examples  such  Docker  0.7 Ubuntu 13.04 x64 and Wordpress on Ubuntu
      12.10 when using the --list-images option. These names can  be  used
      just  like  the  rest  of  the standard instances when specifying an
      image in the cloud profile configuration.

   NOTE:
      If your domain's DNS is managed with DigitalOcean, and  your  minion
      name   matches   your  DigitalOcean  managed  DNS  domain,  you  can
      automatically create A and AAA records for newly  created  droplets.
      Use  create_dns_record:  True  in your config to enable this. Adding
      delete_dns_record: True to also delete records  when  a  droplet  is
      destroyed  is optional. Due to limitations in salt-cloud design, the
      destroy code does not have access to the VM config data. WHETHER YOU
      ADD  create_dns_record:  True  OR  NOT,  salt-cloud  WILL attempt to
      delete your DNS records  if  the  minion  name  matches.  This  will
      prevent advertising any recycled IP addresses for destroyed minions.

   NOTE:
      If  you  need to perform the bootstrap using the local interface for
      droplets, this can be done by setting ssh_interface: private in your
      config.  By  default  the  salt-cloud script would run on the public
      interface however if firewall is preventing the  connection  to  the
      Droplet  over the public interface you might need to set this option
      to  connect  via  private  interface.  Also,  to  use  this  feature
      private_networking: True must be set in the config.

   NOTE:
      Additional documentation is available from DigitalOcean.

   Getting Started With AWS EC2
   Amazon  EC2  is a very widely used public cloud platform and one of the
   core platforms Salt Cloud has been built to support.

   Previously, the suggested driver for AWS EC2 was the aws  driver.  This
   has been deprecated in favor of the ec2 driver. Configuration using the
   old aws driver will still function, but that driver  is  no  longer  in
   active development.

   Dependencies
   This driver requires the Python requests library to be installed.

   Configuration
   The  following example illustrates some of the options that can be set.
   These parameters are discussed in more detail below.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-ec2-southeast-public-ips:
        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Set up grains information, which will be common for all nodes
        # using this provider
        grains:
          node_type: broker
          release: 1.0.1

        # Specify whether to use public or private IP for deploy script.
        #
        # Valid options are:
        #     private_ips - The salt-cloud command is run inside the EC2
        #     public_ips - The salt-cloud command is run outside of EC2
        #
        ssh_interface: public_ips

        # Optionally configure the Windows credential validation number of
        # retries and delay between retries.  This defaults to 10 retries
        # with a one second delay betwee retries
        win_deploy_auth_retries: 10
        win_deploy_auth_retry_delay: 1

        # Set the EC2 access credentials (see below)
        #
        id: 'use-instance-role-credentials'
        key: 'use-instance-role-credentials'

        # Make sure this key is owned by root with permissions 0400.
        #
        private_key: /etc/salt/my_test_key.pem
        keyname: my_test_key
        securitygroup: default

        # Optionally configure default region
        # Use salt-cloud --list-locations <provider> to obtain valid regions
        #
        location: ap-southeast-1
        availability_zone: ap-southeast-1b

        # Configure which user to use to run the deploy script. This setting is
        # dependent upon the AMI that is used to deploy. It is usually safer to
        # configure this individually in a profile, than globally. Typical users
        # are:
        #
        # Amazon Linux -> ec2-user
        # RHEL         -> ec2-user
        # CentOS       -> ec2-user
        # Ubuntu       -> ubuntu
        #
        ssh_username: ec2-user

        # Optionally add an IAM profile
        iam_profile: 'arn:aws:iam::123456789012:instance-profile/ExampleInstanceProfile'

        driver: ec2

      my-ec2-southeast-private-ips:
        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Specify whether to use public or private IP for deploy script.
        #
        # Valid options are:
        #     private_ips - The salt-master is also hosted with EC2
        #     public_ips - The salt-master is hosted outside of EC2
        #
        ssh_interface: private_ips

        # Optionally configure the Windows credential validation number of
        # retries and delay between retries.  This defaults to 10 retries
        # with a one second delay betwee retries
        win_deploy_auth_retries: 10
        win_deploy_auth_retry_delay: 1

        # Set the EC2 access credentials (see below)
        #
        id: 'use-instance-role-credentials'
        key: 'use-instance-role-credentials'

        # Make sure this key is owned by root with permissions 0400.
        #
        private_key: /etc/salt/my_test_key.pem
        keyname: my_test_key

        # This one should NOT be specified if VPC was not configured in AWS to be
        # the default. It might cause an error message which says that network
        # interfaces and an instance-level security groups may not be specified
        # on the same request.
        #
        securitygroup: default

        # Optionally configure default region
        #
        location: ap-southeast-1
        availability_zone: ap-southeast-1b

        # Configure which user to use to run the deploy script. This setting is
        # dependent upon the AMI that is used to deploy. It is usually safer to
        # configure this individually in a profile, than globally. Typical users
        # are:
        #
        # Amazon Linux -> ec2-user
        # RHEL         -> ec2-user
        # CentOS       -> ec2-user
        # Ubuntu       -> ubuntu
        #
        ssh_username: ec2-user

        # Optionally add an IAM profile
        iam_profile: 'my other profile name'

        driver: ec2

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Access Credentials
   The id and key settings may be found in the Security  Credentials  area
   of the AWS Account page:

   https://portal.aws.amazon.com/gp/aws/securityCredentials

   Both  are located in the Access Credentials area of the page, under the
   Access Keys tab. The id setting is labeled Access Key ID, and  the  key
   setting is labeled Secret Access Key.

   Note:  if either id or key is set to 'use-instance-role-credentials' it
   is assumed that Salt is running on an AWS instance,  and  the  instance
   role credentials will be retrieved and used.  Since both the id and key
   are required parameters for the AWS ec2 provider, it is recommended  to
   set both to 'use-instance-role-credentials' for this functionality.

   A  "static"  and  "permanent"  Access  Key  ID  and  Secret  Key can be
   specified, but this is not recommended.  Instance role keys are rotated
   on  a  regular  basis, and are the recommended method of specifying AWS
   credentials.

   Windows Deploy Timeouts
   For Windows instances, it may take longer than normal for the  instance
   to be ready.  In these circumstances, the provider configuration can be
   configured     with     a     win_deploy_auth_retries     and/or      a
   win_deploy_auth_retry_delay  setting, which default to 10 retries and a
   one second delay between retries.  These retries and timeouts relate to
   validating the Administrator password once AWS provides the credentials
   via the AWS API.

   Key Pairs
   In order to create an instance with Salt installed  and  configured,  a
   key  pair  will  need  to  be  created.  This  can  be  done in the EC2
   Management Console, in the Key Pairs area. These key pairs  are  unique
   to  a  specific  region. Keys in the us-east-1 region can be configured
   at:

   https://console.aws.amazon.com/ec2/home?region=us-east-1#s=KeyPairs

   Keys in the us-west-1 region can be configured at

   https://console.aws.amazon.com/ec2/home?region=us-west-1#s=KeyPairs

   ...and so on. When creating a key pair,  the  browser  will  prompt  to
   download a pem file. This file must be placed in a directory accessible
   by Salt Cloud, with permissions set to either 0400 or 0600.

   Security Groups
   An instance on EC2 needs to belong to a security group. Like key pairs,
   these are unique to a specific region. These are also configured in the
   EC2 Management Console. Security groups for the us-east-1 region can be
   configured at:

   https://console.aws.amazon.com/ec2/home?region=us-east-1#s=SecurityGroups

   ...and so on.

   A security group defines firewall rules which an instance  will  adhere
   to. If the salt-master is configured outside of EC2, the security group
   must open the SSH port (usually port 22) in order  for  Salt  Cloud  to
   install Salt.

   IAM Profile
   Amazon  EC2 instances support the concept of an instance profile, which
   is a logical container for the IAM role. At the time that you launch an
   EC2  instance, you can associate the instance with an instance profile,
   which in turn corresponds to the IAM role. Any software  that  runs  on
   the EC2 instance is able to access AWS using the permissions associated
   with the IAM role.

   Scaffolding the profile is a 2-step configuration process:

   1. Configure an IAM Role from the IAM Management Console.

   2. Attach this role to a new profile. It can be done with the AWS CLI:

             > aws iam create-instance-profile --instance-profile-name PROFILE_NAME
             > aws iam add-role-to-instance-profile --instance-profile-name PROFILE_NAME --role-name ROLE_NAME

   Once the profile is created, you can use the PROFILE_NAME to  configure
   your cloud profiles.

   Cloud Profiles
   Set up an initial profile at /etc/salt/cloud.profiles:

      base_ec2_private:
        provider: my-ec2-southeast-private-ips
        image: ami-e565ba8c
        size: t2.micro
        ssh_username: ec2-user

      base_ec2_public:
        provider: my-ec2-southeast-public-ips
        image: ami-e565ba8c
        size: t2.micro
        ssh_username: ec2-user

      base_ec2_db:
        provider: my-ec2-southeast-public-ips
        image: ami-e565ba8c
        size: m1.xlarge
        ssh_username: ec2-user
        volumes:
          - { 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
        sync_after_install: grains

      base_ec2_vpc:
        provider: my-ec2-southeast-public-ips
        image: ami-a73264ce
        size: m1.xlarge
        ssh_username: ec2-user
        script:  /etc/salt/cloud.deploy.d/user_data.sh
        network_interfaces:
          - DeviceIndex: 0
            PrivateIpAddresses:
              - Primary: True
            #auto assign public ip (not EIP)
            AssociatePublicIpAddress: True
            SubnetId: subnet-813d4bbf
            SecurityGroupId:
              - sg-750af413
        del_root_vol_on_destroy: True
        del_all_vol_on_destroy: True
        volumes:
          - { size: 10, device: /dev/sdf }
          - { size: 10, device: /dev/sdg, type: io1, iops: 1000 }
          - { size: 10, device: /dev/sdh, type: io1, iops: 1000 }
        tag: {'Environment': 'production', 'Role': 'database'}
        sync_after_install: grains

   The profile can now be realized with a salt command:

      # salt-cloud -p base_ec2 ami.example.com
      # salt-cloud -p base_ec2_public ami.example.com
      # salt-cloud -p base_ec2_private ami.example.com

   This  will  create an instance named ami.example.com in EC2. The minion
   that is installed on this instance will have an id of  ami.example.com.
   If  the  command  was  executed  on  the salt-master, its Salt key will
   automatically be signed on the master.

   Once  the  instance  has  been  created  with  salt-minion   installed,
   connectivity to it can be verified with Salt:

      # salt 'ami.example.com' test.ping

   Required Settings
   The following settings are always required for EC2:

      # Set the EC2 login data
      my-ec2-config:
        id: HJGRYCILJLKJYG
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        keyname: test
        securitygroup: quick-start
        private_key: /root/test.pem
        driver: ec2

   Optional Settings
   EC2  allows a userdata file to be passed to the instance to be created.
   This functionality was added to Salt in the 2015.5.0 release.

      my-ec2-config:
        # Pass userdata to the instance to be created
        userdata_file: /etc/salt/my-userdata-file

   EC2 allows a location  to  be  set  for  servers  to  be  deployed  in.
   Availability  zones  exist inside regions, and may be added to increase
   specificity.

      my-ec2-config:
        # Optionally configure default region
        location: ap-southeast-1
        availability_zone: ap-southeast-1b

   EC2 instances can have a  public  or  private  IP,  or  both.  When  an
   instance  is  deployed,  Salt Cloud needs to log into it via SSH to run
   the deploy script.  By default, the public IP will be used for this. If
   the salt-cloud command is run from another EC2 instance, the private IP
   should be used.

      my-ec2-config:
        # Specify whether to use public or private IP for deploy script
        # private_ips or public_ips
        ssh_interface: public_ips

   Many EC2 instances do not allow remote  access  to  the  root  user  by
   default.   Instead,  another user must be used to run the deploy script
   using sudo. Some common usernames include ec2-user (for Amazon  Linux),
   ubuntu (for Ubuntu instances), admin (official Debian) and bitnami (for
   images provided by Bitnami).

      my-ec2-config:
        # Configure which user to use to run the deploy script
        ssh_username: ec2-user

   Multiple usernames can be provided,  in  which  case  Salt  Cloud  will
   attempt  to  guess  the  correct username. This is mostly useful in the
   main configuration file:

      my-ec2-config:
        ssh_username:
          - ec2-user
          - ubuntu
          - admin
          - bitnami

   Multiple security groups can also be specified in the same fashion:

      my-ec2-config:
        securitygroup:
          - default
          - extra

   EC2 instances can be added to an AWS Placement Group by specifying  the
   placementgroup option:

      my-ec2-config:
        placementgroup: my-aws-placement-group

   Your  instances  may  optionally  make  use  of EC2 Spot Instances. The
   following example will request that spot instances  be  used  and  your
   maximum  bid will be $0.10. Keep in mind that different spot prices may
   be needed based on the current value of the various EC2 instance sizes.
   You can check current and past spot instance pricing via the EC2 API or
   AWS Console.

      my-ec2-config:
        spot_config:
          spot_price: 0.10

   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'.

   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
   instance size goes above your maximum bid.

   The following parameters may be set in the cloud configuration file  to
   control various aspects of the spot instance launching:

   * wait_for_spot_timeout:  seconds  to  wait  before  giving  up on spot
     instance launch (default=600)

   * wait_for_spot_interval: seconds to wait in between  polling  requests
     to determine if a spot instance is available (default=30)

   * wait_for_spot_interval_multiplier:   a   multiplier  to  add  to  the
     interval in between requests, which is useful if  AWS  is  throttling
     your requests (default=1)

   * wait_for_spot_max_failures:  maximum number of failures before giving
     up on launching your spot instance (default=10)

   If you find that you're being throttled by AWS while polling  for  spot
   instances,  you  can set the following in your core cloud configuration
   file that will double the polling interval after each request to AWS.

      wait_for_spot_interval: 1
      wait_for_spot_interval_multiplier: 2

   See the AWS Spot Instances documentation for more information.

   Block device mappings enable you to specify additional EBS  volumes  or
   instance  store  volumes when the instance is launched. This setting is
   also available on each cloud profile. Note that the number of  instance
   stores varies by instance type.  If more mappings are provided than are
   supported by the instance type, mappings will be created in  the  order
   provided  and  additional  mappings  will  be  ignored. Consult the AWS
   documentation for a listing  of  the  available  instance  stores,  and
   device names.

      my-ec2-config:
        block_device_mappings:
          - DeviceName: /dev/sdb
            VirtualName: ephemeral0
          - DeviceName: /dev/sdc
            VirtualName: ephemeral1

   You  can  also use block device mappings to change the size of the root
   device at the provisioning time. For example, assuming the root  device
   is  '/dev/sda',  you  can  set  its size to 100G by using the following
   configuration.

      my-ec2-config:
        block_device_mappings:
          - DeviceName: /dev/sda
            Ebs.VolumeSize: 100
            Ebs.VolumeType: gp2
            Ebs.SnapshotId: dummy0
          - DeviceName: /dev/sdb
            # required for devices > 2TB
            Ebs.VolumeType: gp2
            Ebs.VolumeSize: 3001

   Existing EBS volumes  may  also  be  attached  (not  created)  to  your
   instances  or you can create new EBS volumes based on EBS snapshots. To
   simply attach an existing volume use the volume_id parameter.

      device: /dev/xvdj
      volume_id: vol-12345abcd

   Or, to  create  a  volume  from  an  EBS  snapshot,  use  the  snapshot
   parameter.

      device: /dev/xvdj
      snapshot: snap-abcd12345

   Note that volume_id will take precedence over the snapshot parameter.

   Tags can be set once an instance has been launched.

      my-ec2-config:
          tag:
              tag0: value
              tag1: value

   Setting up a Master inside EC2
   Salt  Cloud  can  configure  Salt  Masters  as well as Minions. Use the
   make_master setting to use this functionality.

      my-ec2-config:
        # Optionally install a Salt Master in addition to the Salt Minion
        make_master: True

   When creating a Salt Master inside EC2 with make_master: True, or  when
   the  Salt  Master  is  already  located  and  configured inside EC2, by
   default, minions connect to the master's public IP address during  Salt
   Cloud's provisioning process. Depending on how your security groups are
   defined, the minions may or may not be able  to  communicate  with  the
   master.  In  order to use the master's private IP in EC2 instead of the
   public IP, set the salt_interface to private_ips.

      my-ec2-config:
        # Optionally set the IP configuration to private_ips
        salt_interface: private_ips

   Modify EC2 Tags
   One of the features of EC2 is the ability to tag  resources.  In  fact,
   under  the  hood,  the  names  given to EC2 instances by salt-cloud are
   actually just stored as a tag called Name. Salt Cloud has  the  ability
   to manage these tags:

      salt-cloud -a get_tags mymachine
      salt-cloud -a set_tags mymachine tag1=somestuff tag2='Other stuff'
      salt-cloud -a del_tags mymachine tag1,tag2,tag3

   It  is  possible  to manage tags on any resource in EC2 with a Resource
   ID, not just instances:

      salt-cloud -f get_tags my_ec2 resource_id=af5467ba
      salt-cloud -f set_tags my_ec2 resource_id=af5467ba tag1=somestuff
      salt-cloud -f del_tags my_ec2 resource_id=af5467ba tag1,tag2,tag3

   Rename EC2 Instances
   As mentioned above,  EC2  instances  are  named  via  a  tag.  However,
   renaming  an  instance  by renaming its tag will cause the salt keys to
   mismatch. A rename function exists which renames both the instance, and
   the salt keys.

      salt-cloud -a rename mymachine newname=yourmachine

   Rename on Destroy
   When  instances  on  EC2 are destroyed, there will be a lag between the
   time that the action is sent, and the time that Amazon  cleans  up  the
   instance.  During  this  time,  the  instance still retains a Name tag,
   which will cause a collision if the creation of an  instance  with  the
   same  name  is  attempted  before the cleanup occurs. In order to avoid
   such collisions, Salt Cloud can be configured to rename instances  when
   they are destroyed. The new name will look something like:

      myinstance-DEL20f5b8ad4eb64ed88f2c428df80a1a0c

   In  order  to  enable  this,  add  rename_on_destroy  line  to the main
   configuration file:

      my-ec2-config:
        rename_on_destroy: True

   Listing Images
   Normally, images can be queried on a  cloud  provider  by  passing  the
   --list-images argument to Salt Cloud. This still holds true for EC2:

      salt-cloud --list-images my-ec2-config

   However,  the  full  list  of  images  on  EC2  is extremely large, and
   querying all of the available images may cause Salt Cloud to behave  as
   if  frozen.  Therefore,  the  default  behavior  of  this option may be
   modified, by adding an owner argument to the provider configuration:

      owner: aws-marketplace

   The possible values for this setting are amazon, aws-marketplace, self,
   <AWS account ID> or all. The default setting is amazon.  Take note that
   all and aws-marketplace may cause Salt Cloud to  appear  as  if  it  is
   freezing, as it tries to handle the large amount of data.

   It  is  also  possible  to  perform this query using different settings
   without modifying  the  configuration  files.  To  do  this,  call  the
   avail_images function directly:

      salt-cloud -f avail_images my-ec2-config owner=aws-marketplace

   EC2 Images
   The  following  are  lists of available AMI images, generally sorted by
   OS. These lists are on 3rd-party websites,  are  not  managed  by  Salt
   Stack  in  any way. They are provided here as a reference for those who
   are interested, and contain  no  warranty  (express  or  implied)  from
   anyone  affiliated  with Salt Stack. Most of them have never been used,
   much less tested, by the Salt Stack team.

   * Arch Linux

   * FreeBSD

   * Fedora

   * CentOS

   * Ubuntu

   * Debian

   * OmniOS

   * All Images on Amazon

   show_image
   This is a function that describes an AMI on EC2. This will give insight
   as  to  the  defaults  that  will  be  applied  to  an instance using a
   particular AMI.

      $ salt-cloud -f show_image ec2 image=ami-fd20ad94

   show_instance
   This action is a  thin  wrapper  around  --full-query,  which  displays
   details  on  a  single  instance  only.  In an environment with several
   machines, this will save  a  user  from  having  to  sort  through  all
   instance data, just to examine a single instance.

      $ salt-cloud -a show_instance myinstance

   ebs_optimized
   This  argument  enables  switching  of  the  EbsOptimized setting which
   default to 'false'. Indicates whether the instance is optimized for EBS
   I/O.  This optimization provides dedicated throughput to Amazon EBS and
   an optimized configuration stack to  provide  optimal  Amazon  EBS  I/O
   performance. This optimization isn't available with all instance types.
   Additional usage charges apply when using an EBS-optimized instance.

   This setting can be added to the profile or map file for an instance.

   If set to True, this setting will enable an instance to be EbsOptimized

      ebs_optimized: True

   This can also be set as a cloud  provider  setting  in  the  EC2  cloud
   configuration:

      my-ec2-config:
        ebs_optimized: True

   del_root_vol_on_destroy
   This  argument overrides the default DeleteOnTermination setting in the
   AMI for the EBS root volumes for an instance. Many AMIs contain 'false'
   as  a  default, resulting in orphaned volumes in the EC2 account, which
   may unknowingly be charged to the account. This setting can be added to
   the profile or map file for an instance.

   If set, this setting will apply to the root EBS volume

      del_root_vol_on_destroy: True

   This  can  also  be  set  as  a cloud provider setting in the EC2 cloud
   configuration:

      my-ec2-config:
        del_root_vol_on_destroy: True

   del_all_vols_on_destroy
   This argument overrides the default DeleteOnTermination setting in  the
   AMI  for  the  not-root  EBS volumes for an instance. Many AMIs contain
   'false' as a default, resulting in orphaned volumes in the EC2 account,
   which  may  unknowingly  be charged to the account. This setting can be
   added to the profile or map file for an instance.

   If set, this setting will apply to any  (non-root)  volumes  that  were
   created by salt-cloud using the 'volumes' setting.

   The  volumes  will not be deleted under the following conditions * If a
   volume is detached before terminating the instance *  If  a  volume  is
   created without this setting and attached to the instance

      del_all_vols_on_destroy: True

   This  can  also  be  set  as  a cloud provider setting in the EC2 cloud
   configuration:

      my-ec2-config:
        del_all_vols_on_destroy: True

   The setting for this may be changed  on  all  volumes  of  an  existing
   instance using one of the following commands:

      salt-cloud -a delvol_on_destroy myinstance
      salt-cloud -a keepvol_on_destroy myinstance
      salt-cloud -a show_delvol_on_destroy myinstance

   The setting for this may be changed on a volume on an existing instance
   using one of the following commands:

      salt-cloud -a delvol_on_destroy myinstance device=/dev/sda1
      salt-cloud -a delvol_on_destroy myinstance volume_id=vol-1a2b3c4d
      salt-cloud -a keepvol_on_destroy myinstance device=/dev/sda1
      salt-cloud -a keepvol_on_destroy myinstance volume_id=vol-1a2b3c4d
      salt-cloud -a show_delvol_on_destroy myinstance device=/dev/sda1
      salt-cloud -a show_delvol_on_destroy myinstance volume_id=vol-1a2b3c4d

   EC2 Termination Protection
   EC2 allows the user to enable and disable termination protection  on  a
   specific  instance.  An instance with this protection enabled cannot be
   destroyed. The EC2  driver  adds  a  show_term_protect  action  to  the
   regular EC2 functionality.

      salt-cloud -a show_term_protect mymachine
      salt-cloud -a enable_term_protect mymachine
      salt-cloud -a disable_term_protect mymachine

   Alternate Endpoint
   Normally, EC2 endpoints are build using the region and the service_url.
   The resulting endpoint would follow this pattern:

      ec2.<region>.<service_url>

   This results in an endpoint that looks like:

      ec2.us-east-1.amazonaws.com

   There are other projects that support an EC2 compatibility layer, which
   this  scheme does not account for. This can be overridden by specifying
   the endpoint directly in the main cloud configuration file:

      my-ec2-config:
        endpoint: myendpoint.example.com:1138/services/Cloud

   Volume Management
   The EC2 driver has several functions and actions for management of  EBS
   volumes.

   Creating Volumes
   A  volume  may  be  created, independent of an instance. A zone must be
   specified.  A size or a snapshot may be specified (in GiB). If  neither
   is  given,  a  default  size  of  10 GiB will be used. If a snapshot is
   given, the size of the snapshot will be used.

   The following parameters may also be set (when providing a snapshot  OR
   size):

   * type:  choose  between  standard  (magnetic  disk), gp2 (SSD), or io1
     (provisioned IOPS).  (default=standard)

   * iops: the number of IOPS (only applicable to  io1  volumes)  (default
     varies on volume size)

   * encrypted: enable encryption on the volume (default=false)

      salt-cloud -f create_volume ec2 zone=us-east-1b
      salt-cloud -f create_volume ec2 zone=us-east-1b size=10
      salt-cloud -f create_volume ec2 zone=us-east-1b snapshot=snap12345678
      salt-cloud -f create_volume ec2 size=10 type=standard
      salt-cloud -f create_volume ec2 size=10 type=gp2
      salt-cloud -f create_volume ec2 size=10 type=io1 iops=1000

   Attaching Volumes
   Unattached volumes may be attached to an instance. The following values
   are required; name or instance_id, volume_id, and device.

      salt-cloud -a attach_volume myinstance volume_id=vol-12345 device=/dev/sdb1

   Show a Volume
   The details about an existing volume may be retrieved.

      salt-cloud -a show_volume myinstance volume_id=vol-12345
      salt-cloud -f show_volume ec2 volume_id=vol-12345

   Detaching Volumes
   An existing volume may be detached from an instance.

      salt-cloud -a detach_volume myinstance volume_id=vol-12345

   Deleting Volumes
   A volume that is not attached to an instance may be deleted.

      salt-cloud -f delete_volume ec2 volume_id=vol-12345

   Managing Key Pairs
   The EC2 driver has the ability to manage key pairs.

   Creating a Key Pair
   A key pair is required in order to create an instance. When creating  a
   key pair with this function, the return data will contain a copy of the
   private key.  This private key is not stored by  Amazon,  will  not  be
   obtainable past this point, and should be stored immediately.

      salt-cloud -f create_keypair ec2 keyname=mykeypair

   Importing a Key Pair
      salt-cloud -f import_keypair ec2 keyname=mykeypair file=/path/to/id_rsa.pub

   Show a Key Pair
   This  function  will  show  the  details  related  to  a  key pair, not
   including the private key itself (which is not stored by Amazon).

      salt-cloud -f show_keypair ec2 keyname=mykeypair

   Delete a Key Pair
   This function removes the key pair from Amazon.

      salt-cloud -f delete_keypair ec2 keyname=mykeypair

   Launching instances into a VPC
   Simple launching into a VPC
   In the amazon web interface, identify the id or the name of the  subnet
   into which your image should be created. Then, edit your cloud.profiles
   file like so:-

      profile-id:
        provider: provider-name
        subnetid: subnet-XXXXXXXX
        image: ami-XXXXXXXX
        size: m1.medium
        ssh_username: ubuntu
        securitygroupid:
          - sg-XXXXXXXX
        securitygroupname:
          - AnotherSecurityGroup
          - AndThirdSecurityGroup

   Note  that  'subnetid'  takes   precedence   over   'subnetname',   but
   'securitygroupid'  and  'securitygroupname'  are  merged  toghether  to
   generate a single list for SecurityGroups of instances.

   Specifying interface properties
   New in version 2014.7.0.

   Launching into a VPC allows you to specify more complex  configurations
   for the network interfaces of your virtual machines, for example:-

      profile-id:
        provider: provider-name
        image: ami-XXXXXXXX
        size: m1.medium
        ssh_username: ubuntu

        # Do not include either 'subnetid', 'subnetname', 'securitygroupid' or
        # 'securitygroupname' here if you are going to manually specify
        # interface configuration
        #
        network_interfaces:
          - DeviceIndex: 0
            SubnetId: subnet-XXXXXXXX
            SecurityGroupId:
              - sg-XXXXXXXX

            # Uncomment this line if you would like to set an explicit private
            # IP address for the ec2 instance
            #
            # PrivateIpAddress: 192.168.1.66

            # Uncomment this to associate an existing Elastic IP Address with
            # this network interface:
            #
            # associate_eip: eipalloc-XXXXXXXX

            # You can allocate more than one IP address to an interface. Use the
            # 'ip addr list' command to see them.
            #
            # SecondaryPrivateIpAddressCount: 2

            # Uncomment this to allocate a new Elastic IP Address to this
            # interface (will be associated with the primary private ip address
            # of the interface
            #
            # allocate_new_eip: True

            # Uncomment this instead to allocate a new Elastic IP Address to
            # both the primary private ip address and each of the secondary ones
            #
            allocate_new_eips: True

            # Uncomment this if you're creating NAT instances. Allows an instance
            # to accept IP packets with destinations other than itself.
            # SourceDestCheck: False

   Note  that  it  is  an  error  to  assign  a  'subnetid', 'subnetname',
   'securitygroupid'  or  'securitygroupname'  to  a  profile  where   the
   interfaces  are  manually  configured  like this. These are both really
   properties of each network interface, not of the machine itself.

   Getting Started With GoGrid
   GoGrid is a public cloud host that supports Linux and Windows.

   Configuration
   To use Salt Cloud with GoGrid log into the  GoGrid  web  interface  and
   create  an  API key. Do this by clicking on "My Account" and then going
   to the API Keys tab.

   The apikey and the sharedsecret configuration parameters need to be set
   in the configuration file to enable interfacing with GoGrid:

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-gogrid-config:
        driver: gogrid
        apikey: asdff7896asdh789
        sharedsecret: saltybacon

   NOTE:
      A Note about using Map files with GoGrid:

      Due   to   limitations  in  the  GoGrid  API,  instances  cannot  be
      provisioned in parallel with the GoGrid driver. Map files will  work
      with  GoGrid,  but  the  -P  argument  should  not  be  used on maps
      referencing GoGrid instances.

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Profiles
   Cloud Profiles
   Set up  an  initial  profile  at  /etc/salt/cloud.profiles  or  in  the
   /etc/salt/cloud.profiles.d/ directory:

      gogrid_512:
        provider: my-gogrid-config
        size: 512MB
        image: CentOS 6.2 (64-bit) w/ None

   Sizes  can be obtained using the --list-sizes option for the salt-cloud
   command:

      # salt-cloud --list-sizes my-gogrid-config
      my-gogrid-config:
          ----------
          gogrid:
              ----------
              512MB:
                  ----------
                  bandwidth:
                      None
                  disk:
                      30
                  driver:
                  get_uuid:
                  id:
                      512MB
                  name:
                      512MB
                  price:
                      0.095
                  ram:
                      512
                  uuid:
                      bde1e4d7c3a643536e42a35142c7caac34b060e9
      ...SNIP...

   Images  can  be  obtained  using  the  --list-images  option  for   the
   salt-cloud command:

      # salt-cloud --list-images my-gogrid-config
      my-gogrid-config:
          ----------
          gogrid:
              ----------
              CentOS 6.4 (64-bit) w/ None:
                  ----------
                  driver:
                  extra:
                      ----------
                  get_uuid:
                  id:
                      18094
                  name:
                      CentOS 6.4 (64-bit) w/ None
                  uuid:
                      bfd4055389919e01aa6261828a96cf54c8dcc2c4
      ...SNIP...

   Assigning IPs
   New in version 2015.8.0.

   The  GoGrid API allows IP addresses to be manually assigned. Salt Cloud
   supports this functionality by allowing an IP address to  be  specified
   using  the  assign_public_ip argument. This likely makes the most sense
   inside a map file, but it may also be used inside a profile.

      gogrid_512:
        provider: my-gogrid-config
        size: 512MB
        image: CentOS 6.2 (64-bit) w/ None
        assign_public_ip: 11.38.257.42

   Getting Started With Google Compute Engine
   Google Compute Engine (GCE) is Google-infrastructure as a service  that
   lets  you run your large-scale computing workloads on virtual machines.
   This document covers how to use Salt Cloud to provision and manage your
   virtual machines hosted within Google's infrastructure.

   You  can  find  out  more  about  GCE  and  other Google Cloud Platform
   services at https://cloud.google.com.

   Dependencies
   * LibCloud >= 0.14.1

   * A Google Cloud Platform account with Compute Engine enabled

   * A registered Service Account for authorization

   * Oh, and obviously you'll need salt

   Google Compute Engine Setup
   1. Sign up for Google Cloud Platform

      Go to https://cloud.google.com and use your Google account  to  sign
      up for Google Cloud Platform and complete the guided instructions.

   2. Create a Project

      Next,  go  to  the  console  at https://cloud.google.com/console and
      create a new Project.  Make sure to select your new Project  if  you
      are not automatically directed to the Project.

      Projects are a way of grouping together related users, services, and
      billing.  You may opt to create multiple Projects and the  remaining
      instructions  will need to be completed for each Project if you wish
      to use GCE and Salt Cloud to manage your virtual machines.

   3. Enable the Google Compute Engine service

      In your Project, either just click Compute Engine to the left, or go
      to  the  APIs  &  auth  section  and APIs link and enable the Google
      Compute Engine service.

   4. Create a Service Account

      To set up authorization, navigate to APIs & auth  section  and  then
      the  Credentials  link  and  click  the CREATE NEW CLIENT ID button.
      Select Service Account and click the Create Client ID  button.  This
      will  automatically  download  a .json file, which may or may not be
      used in later steps, depending on your version of libcloud.

      Look for a new Service Account section in the page  and  record  the
      generated  email address for the matching key/fingerprint. The email
      address will be used in  the  service_account_email_address  of  the
      /etc/salt/cloud.providers  or the /etc/salt/cloud.providers.d/*.conf
      file.

   5. Key Format

      NOTE:
         If you are using libcloud >= 0.17.0 it is  recommended  that  you
         use  the  JSON  format  file you downloaded above and skip to the
         Provider Configuration section below,  using  the  JSON  file  in
         place of 'NEW.pem' in the documentation.

         If  you  are  using an older version of libcloud or are unsure of
         the version you have, please follow  the  instructions  below  to
         generate and format a new P12 key.

      In  the  new  Service  Account  section, click Generate new P12 key,
      which will automatically download a .p12 private key file. The  .p12
      private  key  needs  to  be  converted  to  a format compatible with
      libcloud.  This new Google-generated private key was encrypted using
      notasecret as a passphrase. Use the following command and record the
      location of the converted private key and record  the  location  for
      use in the service_account_private_key of the /etc/salt/cloud file:

         openssl pkcs12 -in ORIG.p12 -passin pass:notasecret \
         -nodes -nocerts | openssl rsa -out NEW.pem

   Provider Configuration
   Set  up  the  provider  cloud  config  at  /etc/salt/cloud.providers or
   /etc/salt/cloud.providers.d/*.conf:

      gce-config:
        # Set up the Project name and Service Account authorization
        project: "your-project-id"
        service_account_email_address: "[email protected]"
        service_account_private_key: "/path/to/your/NEW.pem"

        # Set up the location of the salt master
        minion:
          master: saltmaster.example.com

        # Set up grains information, which will be common for all nodes
        # using this provider
        grains:
          node_type: broker
          release: 1.0.1

        driver: gce

   NOTE:
      The value provided for  project  must  not  contain  underscores  or
      spaces  and  is  labeled  as  "Project  ID" on the Google Developers
      Console.

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Profile Configuration
   Set   up   an   initial   profile   at   /etc/salt/cloud.profiles    or
   /etc/salt/cloud.profiles.d/*.conf:

      my-gce-profile:
        image: centos-6
        size: n1-standard-1
        location: europe-west1-b
        network: default
        tags: '["one", "two", "three"]'
        metadata: '{"one": "1", "2": "two"}'
        use_persistent_disk: True
        delete_boot_pd: False
        deploy: True
        make_master: False
        provider: gce-config

   The profile can be realized now with a salt command:

      salt-cloud -p my-gce-profile gce-instance

   This will create an salt minion instance named gce-instance in GCE.  If
   the command  was  executed  on  the  salt-master,  its  Salt  key  will
   automatically be signed on the master.

   Once  the  instance  has  been  created  with  a salt-minion installed,
   connectivity to it can be verified with Salt:

      salt gce-instance test.ping

   GCE Specific Settings
   Consult the  sample  profile  below  for  more  information  about  GCE
   specific  settings. Some of them are mandatory and are properly labeled
   below but typically also include a hard-coded default.

   Initial Profile
   Set   up   an   initial   profile   at   /etc/salt/cloud.profiles    or
   /etc/salt/cloud.profiles.d/gce.conf:

      my-gce-profile:
        image: centos-6
        size: n1-standard-1
        location: europe-west1-b
        network: default
        tags: '["one", "two", "three"]'
        metadata: '{"one": "1", "2": "two"}'
        use_persistent_disk: True
        delete_boot_pd: False
        ssh_interface: public_ips
        external_ip: "ephemeral"

   image
   Image  is  used to define what Operating System image should be used to
   for the  instance.  Examples  are  Debian  7  (wheezy)  and  CentOS  6.
   Required.

   size
   A  'size',  in  GCE terms, refers to the instance's 'machine type'. See
   the on-line documentation for a complete list  of  GCE  machine  types.
   Required.

   location
   A  'location',  in  GCE terms, refers to the instance's 'zone'. GCE has
   the notion of both Regions (e.g. us-central1,  europe-west1,  etc)  and
   Zones (e.g. us-central1-a, us-central1-b, etc). Required.

   network
   Use  this setting to define the network resource for the instance.  All
   GCE projects contain a network named 'default' but it's possible to use
   this  setting  to  create  instances  belonging  to a different network
   resource.

   tags
   GCE supports instance/network tags and this setting allows you  to  set
   custom  tags.  It should be a list of strings and must be parse-able by
   the python ast.literal_eval() function to convert it to a python list.

   metadata
   GCE supports instance metadata and  this  setting  allows  you  to  set
   custom  metadata.  It  should  be  a  hash  of  key/value  strings  and
   parse-able by the python ast.literal_eval() function to convert it to a
   python dictionary.

   use_persistent_disk
   Use  this  setting  to ensure that when new instances are created, they
   will  use  a  persistent  disk  to  preserve  data   between   instance
   terminations and re-creations.

   delete_boot_pd
   In  the  event that you wish the boot persistent disk to be permanently
   deleted when you destroy an instance, set delete_boot_pd to True.

   ssh_interface
   New in version 2015.5.0.

   Specify whether to use public or private IP for deploy script.

   Valid options are:

   * private_ips: The salt-master is also hosted with GCE

   * public_ips: The salt-master is hosted outside of GCE

   external_ip
   Per instance setting: Used a named fixed IP address to this host.

   Valid options are:

   * ephemeral: The host will use a GCE ephemeral IP

   * None: No external IP will be configured on this host.

   Optionally, pass the name of a GCE address to use a fixed  IP  address.
   If the address does not already exist, it will be created.

   ex_disk_type
   GCE  supports  two  different  disk types, pd-standard and pd-ssd.  The
   default disk type setting is pd-standard. To specify using an SSD disk,
   set pd-ssd as the value.

   New in version 2014.7.0.

   ip_forwarding
   GCE  instances  can  be enabled to use IP Forwarding. When set to True,
   this options allows the instance to send/receive  non-matching  src/dst
   packets. Default is False.

   New in version 2015.8.1.

   Profile with scopes
   Scopes can be specified by setting the optional ex_service_accounts key
   in your cloud profile.  The  following  example  enables  the  bigquery
   scope.

      my-gce-profile:
       image: centos-6
        ssh_username: salt
        size: f1-micro
        location: us-central1-a
        network: default
        tags: '["one", "two", "three"]'
        metadata: '{"one": "1", "2": "two",
                    "sshKeys": ""}'
        use_persistent_disk: True
        delete_boot_pd: False
        deploy: False
        make_master: False
        provider: gce-config
        ex_service_accounts:
          - scopes:
            - bigquery

   Email can also be specified as an (optional) parameter.

      my-gce-profile:
      ...snip
        ex_service_accounts:
          - scopes:
            - bigquery
            email: default

   There  can  be  multiple  entries  for scopes since ex-service_accounts
   accepts a list of dictionaries.  For  more  information  refer  to  the
   libcloud documentation on specifying service account scopes.

   SSH Remote Access
   GCE  instances  do not allow remote access to the root user by default.
   Instead, another user must be used to run the deploy script using sudo.
   Append    something    like   this   to   /etc/salt/cloud.profiles   or
   /etc/salt/cloud.profiles.d/*.conf:

      my-gce-profile:
          ...

          # SSH to GCE instances as gceuser
          ssh_username: gceuser

          # Use the local private SSH key file located here
          ssh_keyfile: /etc/cloud/google_compute_engine

   If you have not already used this SSH key to login to instances in this
   GCE  project  you will also need to add the public key to your projects
   metadata at https://cloud.google.com/console. You could also add it via
   the metadata setting too:

      my-gce-profile:
          ...

          metadata: '{"one": "1", "2": "two",
                      "sshKeys": "gceuser:ssh-rsa <Your SSH Public Key> gceuser@host"}'

   Single instance details
   This  action  is  a  thin  wrapper  around --full-query, which displays
   details on a single instance  only.  In  an  environment  with  several
   machines,  this  will  save  a  user  from  having  to sort through all
   instance data, just to examine a single instance.

      salt-cloud -a show_instance myinstance

   Destroy, persistent disks, and metadata
   As noted in the provider configuration, it's possible to force the boot
   persistent  disk  to be deleted when you destroy the instance.  The way
   that this has been implemented is  to  use  the  instance  metadata  to
   record the cloud profile used when creating the instance.  When destroy
   is called, if the instance  contains  a  salt-cloud-profile  key,  it's
   value  is  used  to  reference  the  matching  profile  to determine if
   delete_boot_pd is set to True.

   Be aware that any GCE instances created with salt  cloud  will  contain
   this custom salt-cloud-profile metadata entry.

   List various resources
   It's also possible to list several GCE resources similar to what can be
   done with other providers.  The following commands can be used to  list
   GCE zones (locations), machine types (sizes), and images.

      salt-cloud --list-locations gce
      salt-cloud --list-sizes gce
      salt-cloud --list-images gce

   Persistent Disk
   The Compute Engine provider provides functions via salt-cloud to manage
   your Persistent Disks. You can create and  destroy  disks  as  well  as
   attach and detach them from running instances.

   Create
   When creating a disk, you can create an empty disk and specify its size
   (in GB), or specify either an 'image' or 'snapshot'.

      salt-cloud -f create_disk gce disk_name=pd location=us-central1-b size=200

   Delete
   Deleting a disk only requires the name of the disk to delete

      salt-cloud -f delete_disk gce disk_name=old-backup

   Attach
   Attaching a disk to an existing instance  is  really  an  'action'  and
   requires both an instance name and disk name. It's possible to use this
   ation to create bootable persistent disks if necessary. Compute  Engine
   also supports attaching a persistent disk in READ_ONLY mode to multiple
   instances at the same time (but then cannot be attached  in  READ_WRITE
   to any instance).

      salt-cloud -a attach_disk myinstance disk_name=pd mode=READ_WRITE boot=yes

   Detach
   Detaching  a  disk  is  also  an  action  against  an instance and only
   requires the name of the disk. Note that this does not safely sync  and
   umount  the  disk  from  the instance. To ensure no data loss, you must
   first make sure the disk is unmounted from the instance.

      salt-cloud -a detach_disk myinstance disk_name=pd

   Show disk
   It's also possible to look up the details for  an  existing  disk  with
   either a function or an action.

      salt-cloud -a show_disk myinstance disk_name=pd
      salt-cloud -f show_disk gce disk_name=pd

   Create snapshot
   You can take a snapshot of an existing disk's content. The snapshot can
   then in turn be used to create other persistent  disks.  Note  that  to
   prevent  data corruption, it is strongly suggested that you unmount the
   disk prior to taking a snapshot. You must name the snapshot and provide
   the name of the disk.

      salt-cloud -f create_snapshot gce name=backup-20140226 disk_name=pd

   Delete snapshot
   You  can delete a snapshot when it's no longer needed by specifying the
   name of the snapshot.

      salt-cloud -f delete_snapshot gce name=backup-20140226

   Show snapshot
   Use this function to look up information about the snapshot.

      salt-cloud -f show_snapshot gce name=backup-20140226

   Networking
   Compute  Engine  supports  multiple  private  networks   per   project.
   Instances  within  a  private  network can easily communicate with each
   other  by  an  internal  DNS  service  that  resolves  instance  names.
   Instances  within  a  private  network can also communicate with either
   directly without needing special routing or firewall rules even if they
   span different regions/zones.

   Networks  also  support  custom  firewall  rules.  By  default, traffic
   between instances on the same private network is open to all ports  and
   protocols.  Inbound SSH traffic (port 22) is also allowed but all other
   inbound traffic is blocked.

   Create network
   New networks require a name  and  CIDR  range.  New  instances  can  be
   created  and  added  to this network by setting the network name during
   create. It is not  possible  to  add/remove  existing  instances  to  a
   network.

      salt-cloud -f create_network gce name=mynet cidr=10.10.10.0/24

   Destroy network
   Destroy  a  network by specifying the name. Make sure that there are no
   instances associated with the network prior to deleting  it  or  you'll
   have a bad day.

      salt-cloud -f delete_network gce name=mynet

   Show network
   Specify the network name to view information about the network.

      salt-cloud -f show_network gce name=mynet

   Create address
   Create a new named static IP address in a region.

      salt-cloud -f create_address gce name=my-fixed-ip region=us-central1

   Delete address
   Delete an existing named fixed IP address.

      salt-cloud -f delete_address gce name=my-fixed-ip region=us-central1

   Show address
   View details on a named address.

      salt-cloud -f show_address gce name=my-fixed-ip region=us-central1

   Create firewall
   You'll  need to create custom firewall rules if you want to allow other
   traffic than what is described above. For instance, if you  run  a  web
   service  on your instances, you'll need to explicitly allow HTTP and/or
   SSL traffic.  The firewall rule must have a name and it  will  use  the
   'default'   network   unless   otherwise  specified  with  a  'network'
   attribute. Firewalls also support instance tags for source/destination

      salt-cloud -f create_fwrule gce name=web allow=tcp:80,tcp:443,icmp

   Delete firewall
   Deleting a firewall rule will prevent any  previously  allowed  traffic
   for the named firewall rule.

      salt-cloud -f delete_fwrule gce name=web

   Show firewall
   Use this function to review an existing firewall rule's information.

      salt-cloud -f show_fwrule gce name=web

   Load Balancer
   Compute  Engine  possess  a load-balancer feature for splitting traffic
   across multiple instances. Please reference  the  documentation  for  a
   more complete description.

   The   load-balancer  functionality  is  slightly  different  than  that
   described in Google's documentation.  The  concept  of  TargetPool  and
   ForwardingRule  are  consolidated  in salt-cloud/libcloud.  HTTP Health
   Checks are optional.

   HTTP Health Check
   HTTP Health Checks can be used as  a  means  to  toggle  load-balancing
   across  instance  members, or to detect if an HTTP site is functioning.
   A common use-case is to set up a health check URL and if  you  want  to
   toggle  traffic  on/off  to  an  instance,  you can temporarily have it
   return a non-200 response.  A non-200 response to  the  load-balancer's
   health  check  will  keep  the  LB  from sending any new traffic to the
   "down" instance.  Once the instance's health check URL beings returning
   200-responses,  the  LB  will again start to send traffic to it. Review
   Compute Engine's documentation for allowable parameters.  You  can  use
   the following salt-cloud functions to manage your HTTP health checks.

      salt-cloud -f create_hc gce name=myhc path=/ port=80
      salt-cloud -f delete_hc gce name=myhc
      salt-cloud -f show_hc gce name=myhc

   Load-balancer
   When  creating  a  new  load-balancer, it requires a name, region, port
   range, and list of members. There are  other  optional  parameters  for
   protocol,  and list of health checks. Deleting or showing details about
   the LB only requires the name.

      salt-cloud -f create_lb gce name=lb region=... ports=80 members=w1,w2,w3
      salt-cloud -f delete_lb gce name=lb
      salt-cloud -f show_lb gce name=lb

   You can also create a load balancer using a named  fixed  IP  addressby
   specifying  the name of the address.  If the address does not exist yet
   it will be created.

      salt-cloud -f create_lb gce name=my-lb region=us-central1 ports=234 members=s1,s2,s3 address=my-lb-ip

   Attach and Detach LB
   It is possible to  attach  or  detach  an  instance  from  an  existing
   load-balancer.   Both  the instance and load-balancer must exist before
   using these functions.

      salt-cloud -f attach_lb gce name=lb member=w4
      salt-cloud -f detach_lb gce name=lb member=oops

   Getting Started With HP Cloud
   HP Cloud is a  major  public  cloud  platform  and  uses  the  libcloud
   openstack  driver.  The current version of OpenStack that HP Cloud uses
   is Havana. When an instance is booted, it must have a floating IP added
   to  it  in  order  to  connect  to it and further below you will see an
   example that adds context to this statement.

   Set up a cloud provider configuration file
   To use the openstack driver for HP Cloud, set  up  the  cloud  provider
   configuration file as in the example shown below:

   /etc/salt/cloud.providers.d/hpcloud.conf:

      hpcloud-config:
        # Set the location of the salt-master
        #
        minion:
          master: saltmaster.example.com

        # Configure HP Cloud using the OpenStack plugin
        #
        identity_url: https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens
        compute_name: Compute
        protocol: ipv4

        # Set the compute region:
        #
        compute_region: region-b.geo-1

        # Configure HP Cloud authentication credentials
        #
        user: myname
        tenant: myname-project1
        password: xxxxxxxxx

        # keys to allow connection to the instance launched
        #
        ssh_key_name: yourkey
        ssh_key_file: /path/to/key/yourkey.priv

        driver: openstack

   The subsequent example that follows is using the openstack driver.

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Compute Region
   Originally,  HP  Cloud,  in  its  OpenStack  Essex version (1.0), had 3
   availability zones in one region, US West (region-a.geo-1), which  each
   behaved each as a region.

   This  has since changed, and the current OpenStack Havana version of HP
   Cloud (1.1) now has simplified this and now has two regions  to  choose
   from:

      region-a.geo-1 -> US West
      region-b.geo-1 -> US East

   Authentication
   The  user  is  the  same  user  as  is  used  to  log into the HP Cloud
   management UI. The  tenant  can  be  found  in  the  upper  left  under
   "Project/Region/Scope".  It is often named the same as user albeit with
   a -project1 appended.  The password is of course what you created  your
   account  with.  The  management  UI  also has other information such as
   being able to select US East or US West.

   Set up a cloud profile config file
   The profile shown below  is  a  know  working  profile  for  an  Ubuntu
   instance.  The  profile  configuration  file is stored in the following
   location:

   /etc/salt/cloud.profiles.d/hp_ae1_ubuntu.conf:

      hp_ae1_ubuntu:
          provider: hp_ae1
          image: 9302692b-b787-4b52-a3a6-daebb79cb498
          ignore_cidr: 10.0.0.1/24
          networks:
            - floating: Ext-Net
          size: standard.small
          ssh_key_file: /root/keys/test.key
          ssh_key_name: test
          ssh_username: ubuntu

   Some important things about the example above:

   * The image parameter can use either the image name or image  ID  which
     you can obtain by running in the example below (this case US East):

      # salt-cloud --list-images hp_ae1

   * The  parameter  ignore_cidr  specifies a range of addresses to ignore
     when trying to connect to the instance. In this case, it's the  range
     of IP addresses used for an private IP of the instance.

   * The  parameter  networks  is  very  important to include. In previous
     versions of Salt Cloud, this is what made it possible for  salt-cloud
     to  be  able  to  attach  a  floating  IP to the instance in order to
     connect to the instance and set up the minion. The current version of
     salt-cloud doesn't require it, though having it is of no harm either.
     Newer versions of salt-cloud will use  this,  and  without  it,  will
     attempt to find a list of floating IP addresses to use regardless.

   * The  ssh_key_file  and  ssh_key_name  are  the keys that will make it
     possible to connect to the instance to set up the minion

   * The ssh_username parameter, in this case, being that the  image  used
     will  be ubuntu, will make it possible to not only log in but install
     the minion

   Launch an instance
   To instantiate a machine based on this profile (example):

      # salt-cloud -p hp_ae1_ubuntu ubuntu_instance_1

   After  several  minutes,   this   will   create   an   instance   named
   ubuntu_instance_1  running  in  HP Cloud in the US East region and will
   set up the minion and then return information about the  instance  once
   completed.

   Manage the instance
   Once   the  instance  has  been  created  with  salt-minion  installed,
   connectivity to it can be verified with Salt:

      # salt ubuntu_instance_1 ping

   SSH to the instance
   Additionally, the instance can be accessed via SSH using  the  floating
   IP assigned to it

      # ssh ubuntu@<floating ip>

   Using a private IP
   Alternatively,  in  the cloud profile, using the private IP to log into
   the instance to set up the minion is another  option,  particularly  if
   salt-cloud  is  running  within the cloud on an instance that is on the
   same network with all the other instances (minions)

   The example below is a modified version of the previous  example.  Note
   the use of ssh_interface:

      hp_ae1_ubuntu:
          provider: hp_ae1
          image: 9302692b-b787-4b52-a3a6-daebb79cb498
          size: standard.small
          ssh_key_file: /root/keys/test.key
          ssh_key_name: test
          ssh_username: ubuntu
          ssh_interface: private_ips

   With this setup, salt-cloud will use the private IP address to ssh into
   the instance and set up the salt-minion

   Getting Started With Joyent
   Joyent is a public cloud host that supports  SmartOS,  Linux,  FreeBSD,
   and Windows.

   Dependencies
   This driver requires the Python requests library to be installed.

   Configuration
   The Joyent cloud requires three configuration parameters. The user name
   and password that are used to log  into  the  Joyent  system,  and  the
   location of the private ssh key associated with the Joyent account. The
   ssh key is needed to send the provisioning commands up to  the  freshly
   created virtual machine.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-joyent-config:
        driver: joyent
        user: fred
        password: saltybacon
        private_key: /root/mykey.pem
        keyname: mykey

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Profiles
   Cloud Profiles
   Set  up  an  initial  profile  at  /etc/salt/cloud.profiles  or  in the
   /etc/salt/cloud.profiles.d/ directory:

      joyent_512
        provider: my-joyent-config
        size: g4-highcpu-512M
        image: ubuntu-16.04

   Sizes can be obtained using the --list-sizes option for the  salt-cloud
   command:

      # salt-cloud --list-sizes my-joyent-config
      my-joyent-config:
          ----------
          joyent:
              ----------
              g4-highcpu-512M:
                  ----------
                  default:
                      False
                  description:
                      Compute Optimized 512M RAM - 1 vCPU - 10 GB Disk
                  disk:
                      10240
                  group:
                      Compute Optimized
                  id:
                      14aea8fc-d0f8-11e5-bfe4-a7458dbc6c99
                  lwps:
                      4000
                  memory:
                      512
                  name:
                      g4-highcpu-512M
                  swap:
                      2048
                  vcpus:
                      0
                  version:
                      1.0.3
      ...SNIP...

   Images   can  be  obtained  using  the  --list-images  option  for  the
   salt-cloud command:

      # salt-cloud --list-images my-joyent-config
      my-joyent-config:
          ----------
          joyent:
              ----------
              base:
                  ----------
                  description:
                      A 32-bit SmartOS image with just essential packages
                      installed. Ideal for users who are comfortabl e with
                      setting up their own environment and tools.
                  files:
                      |_
                        ----------
                        compression:
                            gzip
                        sha1:
                            b00a77408ddd9aeac85085b68b1cd22a07353956
                        size:
                            106918297
                  homepage:
                      http://wiki.joyent.com/jpc2/Base+Instance
                  id:
                      00aec452-6e81-11e4-8474-ebfec9a1a911
                  name:
                      base
                  os:
                      smartos
                  owner:
                      9dce1460-0c4c-4417-ab8b-25ca478c5a78
                  public:
                      True
                  published_at:
                      2014-11-17T17:41:46Z
                  requirements:
                      ----------
                  state:
                      active
                  type:
                      smartmachine
                  version:
                      14.3.0

      ...SNIP...

   SmartDataCenter
   This driver can also be used with the Joyent  SmartDataCenter  project.
   More details can be found at:

   Using  SDC  requires  that an api_host_suffix is set. The default value
   for this is .api.joyentcloud.com. All characters, including the leading
   ., should be included:

      api_host_suffix: .api.myhostname.com

   Miscellaneous Configuration
   The  following  configuration  items  can  be set in either provider or
   profile confuration files.

   use_ssl
   When set to True (the default), attach https:// to any  URL  that  does
   not  already  have  http://  or https:// included at the beginning. The
   best practice is to leave the protocol out of the  URL,  and  use  this
   setting to manage it.

   verify_ssl
   When  set to True (the default), the underlying web library will verify
   the SSL certificate. This should only be set to False for debugging.`

   Getting Started With LXC
   The LXC module is designed to install Salt in an  LXC  container  on  a
   controlled and possibly remote minion.

   In other words, Salt will connect to a minion, then from that minion:

   * Provision and configure a container for networking access

   * Use those modules to deploy salt and re-attach to master.

        * lxc runner

        * lxc module

        * seed

   Limitations
   * You can only act on one minion and one provider at a time.

   * Listing images must be targeted to a particular LXC provider (nothing
     will be outputted with all)

   Operation
   Salt's LXC support does use lxc.init via  the  lxc.cloud_init_interface
   and seeds the minion via seed.mkconfig.

   You  can  provide to those lxc VMs a profile and a network profile like
   if you were directly using the minion module.

   Order of operation:

   * Create the LXC container on the desired minion (clone or template)

   * Change LXC config options (if any need to be changed)

   * Start container

   * Change base passwords if any

   * Change base DNS configuration if necessary

   * Wait for LXC container to be up and ready for ssh

   * Test SSH connection and bailout in error

   * Upload deploy script and seeds, then re-attach the minion.

   Provider configuration
   Here is a simple provider configuration:

      # Note: This example goes in /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.
      devhost10-lxc:
        target: devhost10
        driver: lxc

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Profile configuration
   Please  read  tutorial-lxc  before  anything   else.    And   specially
   tutorial-lxc-profiles.

   Here are the options to configure your containers:

      target Host minion id to install the lxc Container into

      lxc_profile
             Name  of  the  profile  or  inline  options  for  the  LXC vm
             creation/cloning, please see tutorial-lxc-profiles-container.

      network_profile
             Name of the profile or inline options for the LXC vm  network
             settings, please see tutorial-lxc-profiles-network.

      nic_opts
             Totally  optional.   Per  interface  new-style  configuration
             options mappings which  will  override  any  profile  default
             option:

                 eth0: {'mac': '00:16:3e:01:29:40',
                               'gateway': None, (default)
                               'link': 'br0', (default)
                               'gateway': None, (default)
                               'netmask': '', (default)
                               'ip': '22.1.4.25'}}

      password
             password for root and sysadmin users

      dnsservers
             List of DNS servers to use. This is optional.

      minion minion configuration (see Minion Configuration in Salt Cloud)

      bootstrap_delay
             specify  the  time  to  wait  (in  seconds) between container
             creation and salt bootstrap execution. It is useful to ensure
             that all essential services have started before the bootstrap
             script is executed. By default there's no wait  time  between
             container  creation  and  bootstrap unless you are on systemd
             where we wait that the system is no more in starting state.

      bootstrap_shell
             shell for bootstraping script (default: /bin/sh)

      script defaults to salt-boostrap

      script_args
             arguments which are given to the bootstrap script.   the  {0}
             placeholder  will  be replaced by the path which contains the
             minion config and key files, eg:

                 script_args="-c {0}"

   Using profiles:

      # Note: This example would go in /etc/salt/cloud.profiles or any file in the
      # /etc/salt/cloud.profiles.d/ directory.
      devhost10-lxc:
        provider: devhost10-lxc
        lxc_profile: foo
        network_profile: bar
        minion:
          master: 10.5.0.1
          master_port: 4506

   Using inline profiles (eg to override the network bridge):

      devhost11-lxc:
        provider: devhost10-lxc
        lxc_profile:
          clone_from: foo
        network_profile:
          etho:
            link: lxcbr0
        minion:
          master: 10.5.0.1
          master_port: 4506

   Using a lxc template instead of a clone:

      devhost11-lxc:
        provider: devhost10-lxc
        lxc_profile:
          template: ubuntu
          # options:
          #   release: trusty
        network_profile:
          etho:
            link: lxcbr0
        minion:
          master: 10.5.0.1
          master_port: 4506

   Static ip:

      # Note: This example would go in /etc/salt/cloud.profiles or any file in the
      # /etc/salt/cloud.profiles.d/ directory.
      devhost10-lxc:
        provider: devhost10-lxc
        nic_opts:
          eth0:
            ipv4: 10.0.3.9
        minion:
          master: 10.5.0.1
          master_port: 4506

   DHCP:

      # Note: This example would go in /etc/salt/cloud.profiles or any file in the
      # /etc/salt/cloud.profiles.d/ directory.
      devhost10-lxc:
        provider: devhost10-lxc
        minion:
          master: 10.5.0.1
          master_port: 4506

   Driver Support
   * Container creation

   * Image listing (LXC templates)

   * Running container information (IP addresses, etc.)

   Getting Started With Linode
   Linode is a public cloud host with a focus on Linux instances.

   Starting with the 2015.8.0 release of  Salt,  the  Linode  driver  uses
   Linode's  native  REST API. There are no external dependencies required
   to use the Linode driver, other than a Linode account.

   Provider Configuration
   Linode requires a single API key, but the default root password for new
   instances  also  needs  to  be  set.  The  password  needs  to be eight
   characters and contain lowercase, uppercase, and numbers.

   Set    up    the    provider    cloud     configuration     file     at
   /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/*.conf.

      my-linode-config:
        apikey: 'asldkgfakl;sdfjsjaslfjaklsdjf;askldjfaaklsjdfhasldsadfghdkf'
        password: 'F00barbaz'
        driver: linode

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Profile Configuration
   Linode  profiles  require a provider, size, image, and location. Set up
   an   initial   profile   at   /etc/salt/cloud.profiles   or   in    the
   /etc/salt/cloud.profiles.d/ directory:

      linode_1024:
        provider: my-linode-config
        size: Linode 2048
        image: CentOS 7
        location: London, England, UK

   The profile can be realized now with a salt command:

      salt-cloud -p linode_1024 linode-instance

   This  will  create  an  salt  minion  instance named linode-instance in
   Linode. If the command was executed on the salt-master,  its  Salt  key
   will automatically be signed on the master.

   Once  the  instance  has  been  created  with  a salt-minion installed,
   connectivity to it can be verified with Salt:

      salt linode-instance test.ping

   Listing Sizes
   Sizes can be obtained using the --list-sizes option for the  salt-cloud
   command:

      # salt-cloud --list-sizes my-linode-config
      my-linode-config:
          ----------
          linode:
              ----------
              Linode 1024:
                  ----------
                  AVAIL:
                      ----------
                      10:
                          500
                      2:
                          500
                      3:
                          500
                      4:
                          500
                      6:
                          500
                      7:
                          500
                      8:
                          500
                      9:
                          500
                  CORES:
                      1
                  DISK:
                      24
                  HOURLY:
                      0.015
                  LABEL:
                      Linode 1024
      ...SNIP...

   Listing Images
   Images   can  be  obtained  using  the  --list-images  option  for  the
   salt-cloud command:

      # salt-cloud --list-images my-linode-config
      my-linode-config:
          ----------
          linode:
              ----------
              Arch Linux 2015.02:
                  ----------
                  CREATE_DT:
                      2015-02-20 14:17:16.0
                  DISTRIBUTIONID:
                      138
                  IS64BIT:
                      1
                  LABEL:
                      Arch Linux 2015.02
                  MINIMAGESIZE:
                      800
                  REQUIRESPVOPSKERNEL:
                      1
      ...SNIP...

   Listing Locations
   Locations can be obtained using the  --list-locations  option  for  the
   salt-cloud command:

      # salt-cloud --list-locations my-linode-config
      my-linode-config:
          ----------
          linode:
              ----------
              Atlanta, GA, USA:
                  ----------
                  ABBR:
                      atlanta
                  DATACENTERID:
                      4
                  LOCATION:
                      Atlanta, GA, USA
      ...SNIP...

   Linode Specific Settings
   There  are  several  options outlined below that can be added to either
   the Linode provider of profile configuration files.  Some  options  are
   mandatory  and  are properly labeled below but typically also include a
   hard-coded default.

   image
   Image is used to define what Operating System image should be used  for
   the  instance.  Examples are Ubuntu 14.04 LTS and CentOS 7. This option
   should be specified in the profile config. Required.

   location
   Location is used to define which Linode data center the  instance  will
   reside in.  Required.

   size
   Size  is  used  to  define  the  instance's  "plan type" which includes
   memory, storage, and price. Required.

   assign_private_ip
   New in version 2016.3.0.

   Assigns a private IP address to a Linode when set to True.  Default  is
   False.

   ssh_interface
   New in version 2016.3.0.

   Specify  whether  to  use a public or private IP for the deploy script.
   Valid options are:

   * public_ips: The salt-master is hosted outside of Linode. Default.

   * private_ips: The salt-master is also hosted within Linode.

   If specifying private_ips, the Linodes must be hosted within  the  same
   data center and have the Network Helper enabled on your entire account.
   The instance that is running the Salt-Cloud provisioning  command  must
   also have a private IP assigned to it.

   Newer  accounts  created  on  Linode  have  the  Network Helper setting
   enabled by default, account-wide. Legacy  accounts  do  not  have  this
   setting enabled by default. To enable the Network Helper on your Linode
   account, please see Linode's Network Helper documentation.

   If you're running into problems, be sure to restart the  instance  that
   is  running  Salt  Cloud  after  adding  its  own private IP address or
   enabling the Network Helper.

   clonefrom
   Setting the clonefrom option to a specified instance  enables  the  new
   instance  to be cloned from the named instance instead of being created
   from scratch. If using the clonefrom option, it is likely a  good  idea
   to also specify script_args: -C if a minion is already installed on the
   to-be-cloned  instance.  See  the  Cloning  section  below   for   more
   information.

   Cloning
   To  clone  a  Linode,  add  a  profile  with  a  clonefrom  key,  and a
   script_args: -C.  clonefrom should be the name of the  Linode  that  is
   the  source  for  the  clone.   script_args:  -C  passes  a  -C  to the
   salt-bootstrap script, which only configures the minion and doesn't try
   to install a new copy of salt-minion. This way the minion gets new keys
   and the keys get pre-seeded on the  master,  and  the  /etc/salt/minion
   file has the right minion 'id:' declaration.

   Cloning requires a post 2015-02-01 salt-bootstrap.

   It is safest to clone a stopped machine. To stop a machine run

      salt-cloud -a stop machine_to_clone

   To  create a new machine based on another machine, add an entry to your
   linode cloud profile that looks like this:

      li-clone:
        provider: my-linode-config
        clonefrom: machine_to_clone
        script_args: -C -F

   Then run salt-cloud as normal, specifying -p li-clone. The profile name
   can be anything; It doesn't have to be li-clone.

   clonefrom:  is  the name of an existing machine in Linode from which to
   clone.  Script_args: -C -F is necessary to avoid re-deploying Salt  via
   salt-bootstrap.  -C will just re-deploy keys so the new minion will not
   have a duplicate key or minion_id on the Master, and -F  will  force  a
   rewrite  of  the  Minion  config  file  on  the new Minion. If -F isn't
   provided, the new Minion will have the  machine_to_clone's  Minion  ID,
   instead of its own Minion ID, which can cause problems.

   NOTE:
      Pull  Request  #733 to the salt-bootstrap repo makes the -F argument
      non-necessary. Once that change is released into a stable version of
      the  Bootstrap  Script,  the  -C argument will be sufficient for the
      script_args setting.

   If the machine_to_clone does not have Salt  installed  on  it,  refrain
   from  using  the script_args: -C -F altogether, because the new machine
   will need to have Salt installed.

   Getting Started with OpenNebula
   OpenNebula is an open-source solution for the comprehensive  management
   of virtualized data centers to enable the mixed use of private, public,
   and hybrid IaaS clouds.

   Dependencies
   The driver requires Python's lxml library  to  be  installed.  It  also
   requires an OpenNebula installation running version 4.12 or greater.

   Configuration
   The  following example illustrates some of the options that can be set.
   These parameters are discussed in more detail below.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-opennebula-provider:
        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Define xml_rpc setting which Salt-Cloud uses to connect to the OpenNebula API. Required.
        #
        xml_rpc: http://localhost:2633/RPC2

        # Define the OpenNebula access credentials. This can be the main "oneadmin" user that OpenNebula uses as the
        # OpenNebula main admin, or it can be a user defined in the OpenNebula instance. Required.
        #
        user: oneadmin
        password: JHGhgsayu32jsa

        # Define the private key location that is used by OpenNebula to access new VMs. This setting is required if
        # provisioning new VMs or accessing VMs previously created with the associated public key.
        #
        private_key: /path/to/private/key

        driver: opennebula

   Access Credentials
   The Salt Cloud driver for OpenNebula  was  written  using  OpenNebula's
   native  XML RPC API. Every interaction with OpenNebula's API requires a
   username and password to make the connection from the  machine  running
   Salt  Cloud  to  API  running  on the OpenNebula instance. Based on the
   access credentials passed in, OpenNebula filters the commands that  the
   user  can  perform or the information for which the user can query. For
   example, the images that a user can view with a  --list-images  command
   are  the images that the connected user and the connected user's groups
   can access.

   Key Pairs
   Salt Cloud needs to be able to access a virtual  machine  in  order  to
   install the Salt Minion by using a public/private key pair. The virtual
   machine will need to be seeded with the public key, which is laid  down
   by  the  OpenNebula  template.  Salt  Cloud then uses the corresponding
   private key, provided by the private_key setting in the cloud  provider
   file, to SSH into the new virtual machine.

   To seed the virtual machine with the public key, the public key must be
   added  to  the  OpenNebula  template.  If  using  the  OpenNebula   web
   interface,  navigate  to  the  template,  then  click Update. Click the
   Context  tab.  Under  the  Network  &  SSH  section,  click   Add   SSH
   Contextualization  and  paste  the  public  key  in the Public Key box.
   Don't forget to save your changes by clicking the green Update button.

   NOTE:
      The key pair must not have a pass-phrase.

   Cloud Profiles
   Set up an initial profile at  either  /etc/salt/cloud.profiles  or  the
   /etc/salt/cloud.profiles.d/ directory.

      my-opennebula-profile:
        provider: my-opennebula-provider
        image: Ubuntu-14.04

   The profile can now be realized with a salt command:

      salt-cloud -p my-opennebula-profile my-new-vm

   This  will  create  a  new  instance named my-new-vm in OpenNebula. The
   minion that is installed on this instance will  have  a  minion  id  of
   my-new-vm. If the command was executed on the salt-master, its Salt key
   will automatically be signed on the master.

   Once  the  instance  has  been  created  with  salt-minion   installed,
   connectivity to it can be verified with Salt:

      salt my-new-vm test.ping

   OpenNebula  uses  an  image  -->  template --> virtual machine paradigm
   where the template draws on the image, or disk,  and  virtual  machines
   are created from templates. Because of this, there is no need to define
   a size in the cloud profile. The size of the virtual machine is defined
   in the template.

   Required Settings
   The following settings are always required for OpenNebula:

      my-opennebula-config:
        xml_rpc: http://localhost:26633/RPC2
        user: oneadmin
        password: JHGhgsayu32jsa
        driver: opennebula

   Required Settings for VM Deployment
   The  settings defined in the Required Settings section are required for
   all interactions with OpenNebula. However,  when  deploying  a  virtual
   machine  via  Salt  Cloud,  an additional setting, private_key, is also
   required:

      my-opennebula-config:
        private_key: /path/to/private/key

   Listing Images
   Images can be  queried  on  OpenNebula  by  passing  the  --list-images
   argument to Salt Cloud:

      salt-cloud --list-images opennebula

   Listing Locations
   In  OpenNebula,  locations are defined as hosts. Locations, or "hosts",
   can be querried on OpenNebula by passing the --list-locations  argument
   to Salt Cloud:

      salt-cloud --list-locations opennebula

   Listing Sizes
   Sizes are defined by templates in OpenNebula. As such, the --list-sizes
   call returns an empty dictionary since there are no sizes to return.

   Additional OpenNebula API Functionality
   The Salt Cloud driver for OpenNebula  was  written  using  OpenNebula's
   native  XML  RPC  API. As such, many --function and --action calls were
   added to the OpenNebula driver to enhance  support  for  an  OpenNebula
   infrastructure  with  additional  control  from  Salt  Cloud.  See  the
   OpenNebula function definitions for more information.

   Access via DNS entry instead of IP
   Some OpenNebula installations do not assign IP addresses  to  new  VMs,
   instead they establish the new VM's hostname based on OpenNebula's name
   of the VM, and then allocate  an  IP  out  of  DHCP  with  dynamic  DNS
   attaching  the  hostname.  This driver supports this behavior by adding
   the entry fqdn_base to  the  driver  configuration  or  the  OpenNebula
   profile  with  a  value  matching the base fully-qualified domain.  For
   example:

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-opennebula-provider:
        [...]
        fqdn_base: corp.example.com
        [...]

   Getting Started With OpenStack
   OpenStack is one the most popular cloud projects. It's an  open  source
   project  to  build public and/or private clouds. You can use Salt Cloud
   to launch OpenStack instances.

   Dependencies
   * Libcloud >= 0.13.2

   Configuration
   * Using  the  new  format,  set   up   the   cloud   configuration   at
     /etc/salt/cloud.providers                                          or
     /etc/salt/cloud.providers.d/openstack.conf:

      my-openstack-config:
        # Set the location of the salt-master
        #
        minion:
          master: saltmaster.example.com

        # Configure the OpenStack driver
        #
        identity_url: http://identity.youopenstack.com/v2.0/tokens
        compute_name: nova
        protocol: ipv4

        compute_region: RegionOne

        # Configure Openstack authentication credentials
        #
        user: myname
        password: 123456
        # tenant is the project name
        tenant: myproject

        driver: openstack

        # skip SSL certificate validation (default false)
        insecure: false

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Using nova client to get information from OpenStack
   One of the best ways to get information about OpenStack  is  using  the
   novaclient python package (available in pypi as python-novaclient). The
   client configuration is a set of environment variables that you can get
   from  the Dashboard. Log in and then go to Project -> Access & security
   -> API Access and download the "OpenStack RC file". Then:

      source /path/to/your/rcfile
      nova credentials
      nova endpoints

   In the  nova  endpoints  output  you  can  see  the  information  about
   compute_region and compute_name.

   Compute Region
   It  depends on the OpenStack cluster that you are using. Please, have a
   look at the previous sections.

   Authentication
   The user and password is the same user as  is  used  to  log  into  the
   OpenStack Dashboard.

   Profiles
   Here is an example of a profile:

      openstack_512:
        provider: my-openstack-config
        size: m1.tiny
        image: cirros-0.3.1-x86_64-uec
        ssh_key_file: /tmp/test.pem
        ssh_key_name: test
        ssh_interface: private_ips

   The following list explains some of the important properties.

   size   can  be  one  of  the  options  listed  in  the  output  of nova
          flavor-list.

   image  can be  one  of  the  options  listed  in  the  output  of  nova
          image-list.

   ssh_key_file
          The  SSH private key that the salt-cloud uses to SSH into the VM
          after its first booted in order to execute a command or  script.
          This  private  key's public key must be the openstack public key
          inserted into the authorized_key's file of the  VM's  root  user
          account.

   ssh_key_name
          The  name  of the openstack SSH public key that is inserted into
          the authorized_keys file of the VM's root user account. Prior to
          using  this  public  key, you must use openstack commands or the
          horizon web UI to load that key into the tenant's account.  Note
          that  this  openstack  tenant must be the one you defined in the
          cloud provider.

   ssh_interface
          This option allows you to create a VM without a  public  IP.  If
          this  option  is  omitted  and the VM does not have a public IP,
          then the salt-cloud waits for a certain period of time and  then
          destroys the VM. With the nova drive, private cloud networks can
          be defined here.

   For more information concerning cloud profiles, see here.

   change_password
   If  no  ssh_key_file  is  provided,  and  the  server  already  exists,
   change_password  will  use  the  api to change the root password of the
   server so that it can be bootstrapped.

      change_password: True

   userdata_file
   Use userdata_file to specify the userdata file to upload for  use  with
   cloud-init if available.

      userdata_file: /etc/salt/cloud-init/packages.yml

   Getting Started With Parallels
   Parallels  Cloud Server is a product by Parallels that delivers a cloud
   hosting solution. The PARALLELS module for Salt Cloud  enables  you  to
   manage instances hosted using PCS. Further information can be found at:

   http://www.parallels.com/products/pcs/

   * Using   the   old   format,   set   up  the  cloud  configuration  at
     /etc/salt/cloud:

      # Set up the location of the salt master
      #
      minion:
          master: saltmaster.example.com

      # Set the PARALLELS access credentials (see below)
      #
      PARALLELS.user: myuser
      PARALLELS.password: badpass

      # Set the access URL for your PARALLELS host
      #
      PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/

   * Using  the  new  format,  set   up   the   cloud   configuration   at
     /etc/salt/cloud.providers                                          or
     /etc/salt/cloud.providers.d/parallels.conf:

      my-parallels-config:
        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Set the PARALLELS access credentials (see below)
        #
        user: myuser
        password: badpass

        # Set the access URL for your PARALLELS provider
        #
        url: https://api.cloud.xmission.com:4465/paci/v1.0/
        driver: parallels

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Access Credentials
   The user, password, and url will be provided to you by your cloud host.
   These are all required in order for the PARALLELS driver to work.

   Cloud Profiles
   Set    up   an   initial   profile   at   /etc/salt/cloud.profiles   or
   /etc/salt/cloud.profiles.d/parallels.conf:

      parallels-ubuntu:
          provider: my-parallels-config
          image: ubuntu-12.04-x86_64

   The profile can be realized now with a salt command:

      # salt-cloud -p parallels-ubuntu myubuntu

   This will create an instance named myubuntu  on  the  cloud  host.  The
   minion  that is installed on this instance will have an id of myubuntu.
   If the command was executed on  the  salt-master,  its  Salt  key  will
   automatically be signed on the master.

   Once   the  instance  has  been  created  with  salt-minion  installed,
   connectivity to it can be verified with Salt:

      # salt myubuntu test.ping

   Required Settings
   The following settings are always required for PARALLELS:

   * Using the old cloud configuration format:

      PARALLELS.user: myuser
      PARALLELS.password: badpass
      PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/

   * Using the new cloud configuration format:

      my-parallels-config:
        user: myuser
        password: badpass
        url: https://api.cloud.xmission.com:4465/paci/v1.0/
        driver: parallels

   Optional Settings
   Unlike other cloud providers in Salt Cloud, Parallels does not  utilize
   a  size  setting.  This  is  because  Parallels  allows the end-user to
   specify a more detailed  configuration  for  their  instances  than  is
   allowed  by many other cloud hosts. The following options are available
   to be used in a profile, with their default settings listed.

      # Description of the instance. Defaults to the instance name.
      desc: <instance_name>

      # How many CPU cores, and how fast they are (in MHz)
      cpu_number: 1
      cpu_power: 1000

      # How many megabytes of RAM
      ram: 256

      # Bandwidth available, in kbps
      bandwidth: 100

      # How many public IPs will be assigned to this instance
      ip_num: 1

      # Size of the instance disk (in GiB)
      disk_size: 10

      # Username and password
      ssh_username: root
      password: <value from PARALLELS.password>

      # The name of the image, from ``salt-cloud --list-images parallels``
      image: ubuntu-12.04-x86_64

   Getting Started With ProfitBricks
   ProfitBricks provides an enterprise-grade Infrastructure as  a  Service
   (IaaS)  solution  that  can  be  managed  through a browser-based "Data
   Center Designer" (DCD) tool or via an easy to use API. A unique feature
   of  the  ProfitBricks platform is that it allows you to define your own
   settings for cores, memory, and disk  size  without  being  tied  to  a
   particular server size.

   Dependencies
   * profitbricks >= 2.3.4

   Configuration
   * Using   the   new   format,   set   up  the  cloud  configuration  at
     /etc/salt/cloud.providers                                          or
     /etc/salt/cloud.providers.d/profitbricks.conf:

      my-profitbricks-config:
        driver: profitbricks

        # Set the location of the salt-master
        #
        minion:
          master: saltmaster.example.com

        # Configure ProfitBricks authentication credentials
        #
        username: [email protected]
        password: 123456
        # datacenter is the UUID of a pre-existing virtual data center.
        datacenter: 9e6709a0-6bf9-4bd6-8692-60349c70ce0e
        # Connect to public LAN ID 1.
        public_lan: 1
        ssh_public_key: /path/to/id_rsa.pub
        ssh_private_key: /path/to/id_rsa

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Virtual Data Center
   ProfitBricks  uses  the  concept  of  Virtual  Data  Centers. These are
   logically  separated  from  one  another  and  allow  you  to  have   a
   self-contained   environment  for  all  servers,  volumes,  networking,
   snapshots, and so forth.

   A list of existing virtual data  centers  can  be  retrieved  with  the
   following command:

      salt-cloud -f list_datacenters my-profitbricks-config

   Authentication
   The  username  and  password are the same as those used to log into the
   ProfitBricks "Data Center Designer".

   Profiles
   Here is an example of a profile:

      profitbricks_staging
        provider: my-profitbricks-config
        size: Micro Instance
        image: 2f98b678-6e7e-11e5-b680-52540066fee9
        cores: 2
        ram: 4096
        public_lan: 1
        private_lan: 2
        ssh_public_key: /path/to/id_rsa.pub
        ssh_private_key: /path/to/id_rsa
        ssh_interface: private_lan

      profitbricks_production:
        provider: my-profitbricks-config
        image: Ubuntu-15.10-server-2016-05-01
        disk_type: SSD
        disk_size: 40
        cores: 8
        cpu_family: INTEL_XEON
        ram: 32768
        public_lan: 1
        private_lan: 2
        public_firewall_rules:
          Allow SSH:
            protocol: TCP
            source_ip: 1.2.3.4
            port_range_start: 22
            port_range_end: 22
          Allow Ping:
            protocol: ICMP
            icmp_type: 8
        ssh_public_key: /path/to/id_rsa.pub
        ssh_private_key: /path/to/id_rsa
        ssh_interface: private_lan
        volumes:
          db_data:
            disk_size: 500
          db_log:
            disk_size: 50
            disk_type: SSD

   The following list explains some of the important properties.

   size   Can be one of the options listed in the output of the  following
          command:

      salt-cloud --list-sizes my-profitbricks

   image  Can  be one of the options listed in the output of the following
          command:

      salt-cloud --list-images my-profitbricks

   disk_size
          This option allows you to override  the  size  of  the  disk  as
          defined by the size. The disk size is set in gigabytes (GB).

   disk_type
          This  option  allow  the  disk type to be set to HDD or SSD. The
          default is HDD.

   cores  This option allows you to override the number of  CPU  cores  as
          defined by the size.

   ram    This  option allows you to override the amount of RAM defined by
          the size.  The value must be a multiple of 256, e.g.  256,  512,
          768, 1024, and so forth.

   public_lan
          This option will connect the server to the specified public LAN.
          If no LAN exists, then a new public LAN  will  be  created.  The
          value accepts a LAN ID (integer).

   public_firewall_rules
          This  option allows for a list of firewall rules assigned to the
          public network interface.

          Firewall Rule Name:
                 protocol:  <protocol>  (TCP,   UDP,   ICMP)   source_mac:
                 <source-mac>     source_ip:     <source-ip>    target_ip:
                 <target-ip>     port_range_start:      <port-range-start>
                 port_range_end:  <port-range-end>  icmp_type: <icmp-type>
                 icmp_code: <icmp-code>

   private_lan
          This option will connect the server  to  the  specified  private
          LAN.  If  no LAN exists, then a new private LAN will be created.
          The value accepts a LAN ID (integer).

   private_firewall_rules
          This option allows for a list of firewall rules assigned to  the
          private network interface.

          Firewall Rule Name:
                 protocol:   <protocol>   (TCP,   UDP,  ICMP)  source_mac:
                 <source-mac>    source_ip:     <source-ip>     target_ip:
                 <target-ip>      port_range_start:     <port-range-start>
                 port_range_end: <port-range-end>  icmp_type:  <icmp-type>
                 icmp_code: <icmp-code>

   ssh_private_key
          Full path to the SSH private key file.

   ssh_public_key
          Full path to the SSH public key file.

   ssh_interface
          This  option  will  use  the private LAN IP for node connections
          (such as as bootstrapping the node) instead of  the  public  LAN
          IP. The value accepts 'private_lan'.

   cpu_family
          This  option  allow  the  CPU family to be set to AMD_OPTERON or
          INTEL_XEON.  The default is AMD_OPTERON.

   volumes:
          This option allows a list of additional  volumes  by  name  that
          will be created and attached to the server. Each volume requires
          'disk_size' and, optionally, 'disk_type'. The default is HDD.

   deploy Set to False if Salt should not be installed on the node.

   wait_for_timeout
          The timeout to wait in seconds for provisioning  resources  such
          as servers.  The default wait_for_timeout is 15 minutes.

   For more information concerning cloud profiles, see here.

   Getting Started With Proxmox
   Proxmox   Virtual  Environment  is  a  complete  server  virtualization
   management solution, based on OpenVZ(in  Proxmox  up  to  3.4)/LXC(from
   Proxmox  4.0  and  up)  and  full  virtualization  with  KVM.   Further
   information can be found at:

   http://www.proxmox.org/

   Dependencies
   * IPy >= 0.81

   * requests >= 2.2.1

   Please note: This module allows you to create OpenVZ/LXC containers and
   KVM  VMs,  but  installing  Salt  on it will only be done on containers
   rather than a KVM virtual machine.

   * Set  up  the  cloud  configuration  at  /etc/salt/cloud.providers  or
     /etc/salt/cloud.providers.d/proxmox.conf:

      my-proxmox-config:
        # Set up the location of the salt master
        #
        minion:
          master: saltmaster.example.com

        # Set the PROXMOX access credentials (see below)
        #
        user: myuser@pve
        password: badpass

        # Set the access URL for your PROXMOX host
        #
        url: your.proxmox.host
        driver: proxmox

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Access Credentials
   The user, password, and url will be provided to you by your cloud host.
   These are all required in order for the PROXMOX driver to work.

   Cloud Profiles
   Set   up   an   initial   profile   at   /etc/salt/cloud.profiles    or
   /etc/salt/cloud.profiles.d/proxmox.conf:

   * Configure a profile to be used:

      proxmox-ubuntu:
          provider: my-proxmox-config
          image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz
          technology: lxc

          # host needs to be set to the configured name of the proxmox host
          # and not the ip address or FQDN of the server
          host: myvmhost
          ip_address: 192.168.100.155
          password: topsecret

   The profile can be realized now with a salt command:

      # salt-cloud -p proxmox-ubuntu myubuntu

   This  will  create  an  instance  named myubuntu on the cloud host. The
   minion that is installed on this  instance  will  have  a  hostname  of
   myubuntu.  If the command was executed on the salt-master, its Salt key
   will automatically be signed on the master.

   Once  the  instance  has  been  created  with  salt-minion   installed,
   connectivity to it can be verified with Salt:

      # salt myubuntu test.ping

   Required Settings
   The following settings are always required for PROXMOX:

   * Using the new cloud configuration format:

      my-proxmox-config:
        driver: proxmox
        user: saltcloud@pve
        password: xyzzy
        url: your.proxmox.host

   Optional Settings
   Unlike  other cloud providers in Salt Cloud, Proxmox does not utilize a
   size setting. This is because Proxmox allows the end-user to specify  a
   more  detailed  configuration  for  their instances, than is allowed by
   many other cloud providers. The following options are available  to  be
   used in a profile, with their default settings listed.

      # Description of the instance.
      desc: <instance_name>

      # How many CPU cores, and how fast they are (in MHz)
      cpus: 1
      cpuunits: 1000

      # How many megabytes of RAM
      memory: 256

      # How much swap space in MB
      swap: 256

      # Whether to auto boot the vm after the host reboots
      onboot: 1

      # Size of the instance disk (in GiB)
      disk: 10

      # Host to create this vm on
      host: myvmhost

      # Nameservers. Defaults to host
      nameserver: 8.8.8.8 8.8.4.4

      # Username and password
      ssh_username: root
      password: <value from PROXMOX.password>

      # The name of the image, from ``salt-cloud --list-images proxmox``
      image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz

      # Whether or not to verify the SSL cert on the Proxmox host
      verify_ssl: False

      # Network interfaces, netX
      net0: name=eth0,bridge=vmbr0,ip=dhcp

   QEMU
   Some   functionnalities   works   differently  if  you  use  'qemu'  as
   technology. In order to  create  a  new  VM  with  qemu,  you  need  to
   specificy  some  more  information.  You can also clone a qemu template
   which already is on your Proxmox server.

   QEMU profile file (for a new VM):

      proxmox-win7:
        # Image of the new VM
        image: image.iso # You can get all your available images using 'salt-cloud --list-images provider_name' (Ex: 'salt-cloud --list-images my-proxmox-config')

        # Technology used to create the VM ('qemu', 'openvz'(on Proxmox <4.x) or 'lxc'(on Proxmox 4.x+))
        technology: qemu

        # Proxmox node name
        host: node_name

        # Proxmox password
        password: your_password

        # Workaround https://github.com/saltstack/salt/issues/27821
        size: ''

        # RAM size (MB)
        memory: 2048

        # OS Type enum (other / wxp / w2k / w2k3 / w2k8 / wvista / win7 / win8 / l24 / l26 / solaris)
        ostype: win7

        # Hard disk location
        sata0: <location>:<size>, format=<qcow2/vmdk/raw>, size=<size>GB #Example: local:120,format=qcow2,size=120GB

        #CD/DVD Drive
        ide2: <content_location>,media=cdrom #Example: local:iso/name.iso,media=cdrom

        # Network Device
        net0:<model>,bridge=<bridge> #Example: e1000,bridge=vmbr0

        # Enable QEMU Guest Agent (0 / 1)
        agent: 1

        # VM name
        name: Test

   More information about these parameters can be found on Proxmox API  (
   http://pve.proxmox.com/pve2-api-doc/)   under   the  'POST'  method  of
   nodes/{node}/qemu

   QEMU profile file (for a clone):

      proxmox-win7:
        # Enable Clone
        clone: 1

        # New VM description
        clone_description: 'description'

        # New VM name
        clone_name: 'name'

        # New VM format (qcow2 / raw / vmdk)
        clone_format: qcow2

        # Full clone (1) or Link clone (0)
        clone_full: 0

        # VMID of Template to clone
        clone_from: ID

        # Technology used to create the VM ('qemu' or 'lxc')
        technology: qemu

        # Proxmox node name
        host: node_name

        # Proxmox password
        password: your_password

        # Workaround https://github.com/saltstack/salt/issues/27821
        size: ''

   More information can be found on Proxmox API under the 'POST' method of
   /nodes/{node}/qemu/{vmid}/clone

   NOTE:
      The  Proxmox API offers a lot more options and parameters, which are
      not yet supported by this salt-cloud 'overlay'.  Feel  free  to  add
      your  contribution  by  forking  the github repository and modifying
      the following file: salt/salt/cloud/clouds/proxmox.py An easy way to
      support more parameters for VM creation would be to add the names of
      the optional parameters in the 'create_nodes(
      vm_
      )' function, under the 'qemu' technology. But it requires you to dig
      into the code ...

   Getting Started With Rackspace
   Rackspace  is  a  major  public  cloud platform which may be configured
   using either the rackspace or the openstack driver, depending  on  your
   needs.

   Please  note  that  the  rackspace  driver is intended only for 1st gen
   instances, aka, "the old cloud" at Rackspace. It is  required  for  1st
   gen instances, but will not work with OpenStack-based instances. Unless
   you explicitly have a reason to use it, it is highly  recommended  that
   you use the openstack driver instead.

   Dependencies
   * Libcloud >= 0.13.2

   Configuration
   To   use   the   openstack  driver  (recommended),  set  up  the  cloud
   configuration at
          /etc/salt/cloud.providers                                     or
          /etc/salt/cloud.providers.d/rackspace.conf:

      my-rackspace-config:
        # Set the location of the salt-master
        #
        minion:
          master: saltmaster.example.com

        # Configure Rackspace using the OpenStack plugin
        #
        identity_url: 'https://identity.api.rackspacecloud.com/v2.0/tokens'
        compute_name: cloudServersOpenStack
        protocol: ipv4

        # Set the compute region:
        #
        compute_region: DFW

        # Configure Rackspace authentication credentials
        #
        user: myname
        tenant: 123456
        apikey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

        driver: openstack

   To use the rackspace driver, set up the cloud configuration at
          /etc/salt/cloud.providers                                     or
          /etc/salt/cloud.providers.d/rackspace.conf:

      my-rackspace-config:
        driver: rackspace
        # The Rackspace login user
        user: fred
        # The Rackspace user's apikey
        apikey: 901d3f579h23c8v73q9

   The settings that follow are for using  Rackspace  with  the  openstack
   driver, and will not work with the rackspace driver.

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Compute Region
   Rackspace currently has six compute regions which may be used:

      DFW -> Dallas/Forth Worth
      ORD -> Chicago
      SYD -> Sydney
      LON -> London
      IAD -> Northern Virginia
      HKG -> Hong Kong

   Note: Currently the LON region is only available with a UK account, and
   UK accounts cannot access other regions

   Authentication
   The user is the same user as is used to log into the Rackspace  Control
   Panel.  The  tenant and apikey can be found in the API Keys area of the
   Control Panel. The apikey will be labeled as API Key (and may  need  to
   be generated), and tenant will be labeled as Cloud Account Number.

   An  initial  profile  can  be configured in /etc/salt/cloud.profiles or
   /etc/salt/cloud.profiles.d/rackspace.conf:

      openstack_512:
          provider: my-rackspace-config
          size: 512 MB Standard
          image: Ubuntu 12.04 LTS (Precise Pangolin)

   To instantiate a machine based on this profile:

      # salt-cloud -p openstack_512 myinstance

   This  will  create  a  virtual  machine  at  Rackspace  with  the  name
   myinstance.   This  operation  may  take  several  minutes to complete,
   depending on the current load at the Rackspace data center.

   Once  the  instance  has  been  created  with  salt-minion   installed,
   connectivity to it can be verified with Salt:

      # salt myinstance test.ping

   RackConnect Environments
   Rackspace   offers   a   hybrid  hosting  configuration  option  called
   RackConnect that allows you to use a physical firewall  appliance  with
   your  cloud servers. When this service is in use the public_ip assigned
   by nova will be replaced by a NAT ip on the firewall. For salt-cloud to
   work properly it must use the newly assigned "access ip" instead of the
   Nova assigned public ip. You can enable that capability by adding  this
   to your profiles:

      openstack_512:
          provider: my-openstack-config
          size: 512 MB Standard
          image: Ubuntu 12.04 LTS (Precise Pangolin)
          rackconnect: True

   Managed Cloud Environments
   Rackspace  offers  a  managed  service level of hosting. As part of the
   managed service level you have the ability to choose from base of  lamp
   installations  on cloud server images.  The post build process for both
   the base and the lamp installations used Chef to install things such as
   the  cloud  monitoring  agent and the cloud backup agent. It also takes
   care of installing the lamp stack if selected. In order to prevent  the
   post  installation process from stomping over the bootstrapping you can
   add the below to your profiles.

      openstack_512:
          provider: my-rackspace-config
          size: 512 MB Standard
          image: Ubuntu 12.04 LTS (Precise Pangolin)
          managedcloud: True

   First and Next Generation Images
   Rackspace provides two sets of virtual machine images, first, and  next
   generation.  As  of  0.8.9  salt-cloud  will  default to using the next
   generation images. To force the use of first generation images, on  the
   profile configuration please add:

      FreeBSD-9.0-512:
        provider: my-rackspace-config
        size: 512 MB Standard
        image: FreeBSD 9.0
        force_first_gen: True

   Private Subnets
   By  default  salt-cloud  will not add Rackspace private networks to new
   servers. To enable a private network to a server instantiated  by  salt
   cloud,  add  the  following  section  to  the  provider file (typically
   /etc/salt/cloud.providers.d/rackspace.conf)

      networks:
        - fixed:
          # This is the private network
          - private-network-id
          # This is Rackspace's "PublicNet"
          - 00000000-0000-0000-0000-000000000000
          # This is Rackspace's "ServiceNet"
          - 11111111-1111-1111-1111-111111111111

   To get the Rackspace private network ID, go to Networking, Networks and
   hover over the private network name.

   The  order  of the networks in the above code block does not map to the
   order of the ethernet devices on newly  created  servers.    Public  IP
   will  always be first ( eth0 ) followed by servicenet ( eth1 ) and then
   private networks.

   Enabling the private network per above gives the option  of  using  the
   private  subnet  for  all  master-minion  communication,  including the
   bootstrap install of salt-minion.  To enable  the  minion  to  use  the
   private  subnet,  update the master: line in the minion: section of the
   providers file.  To configure the master to only listen on the  private
   subnet  IP,  update the interface: line in the /etc/salt/master file to
   be the private subnet IP of the salt master.

   Getting Started With Saltify
   The Saltify driver is a new, experimental driver for installing Salt on
   existing machines (virtual or bare metal).

   Dependencies
   The Saltify driver has no external dependencies.

   Configuration
   Because  the Saltify driver does not use an actual cloud provider host,
   it has a simple provider configuration. The only thing that is required
   to  be  set  is  the  driver  name,  and  any  other potentially useful
   information, like the location of the salt-master:

      # Note: This example is for /etc/salt/cloud.providers file or any file in
      # the /etc/salt/cloud.providers.d/ directory.

      my-saltify-config:
        minion:
          master: 111.222.333.444
        provider: saltify

   Profiles
   Saltify requires a profile to be configured for each machine that needs
   Salt    installed.   The   initial   profile   can   be   set   up   at
   /etc/salt/cloud.profiles   or   in   the    /etc/salt/cloud.profiles.d/
   directory.  Each  profile requires both an ssh_host and an ssh_username
   key parameter as well as either an key_filename or a password.

   Profile configuration example:

      # /etc/salt/cloud.profiles.d/saltify.conf

      salt-this-machine:
        ssh_host: 12.34.56.78
        ssh_username: root
        key_filename: '/etc/salt/mysshkey.pem'
        provider: my-saltify-config

   The machine can now be "Salted" with the following command:

      salt-cloud -p salt-this-machine my-machine

   This will install salt on the machine specified by the  cloud  profile,
   salt-this-machine,   and  will  give  the  machine  the  minion  id  of
   my-machine. If the command was executed on the  salt-master,  its  Salt
   key will automatically be signed on the master.

   Once  a  salt-minion  has  been successfully installed on the instance,
   connectivity to it can be verified with Salt:

      salt my-machine test.ping

   Using Map Files
   The settings explained in the section above may also be set  in  a  map
   file.  An  example  of  how  to  use the Saltify driver with a map file
   follows:

      # /etc/salt/saltify-map

      make_salty:
        - my-instance-0:
            ssh_host: 12.34.56.78
            ssh_username: root
            password: very-bad-password
        - my-instance-1:
            ssh_host: 44.33.22.11
            ssh_username: root
            password: another-bad-pass

   Note: When using a cloud map with the Saltify driver, the name  of  the
   profile  to  use, in this case make_salty, must be defined in a profile
   config. For example:

      # /etc/salt/cloud.profiles.d/saltify.conf

      make_salty:
        provider: my-saltify-config

   The machines listed in the map file can now be "Salted" by applying the
   following salt map command:

      salt-cloud -m /etc/salt/saltify-map

   This command will install salt on the machines specified in the map and
   will  give  each  machine  their  minion  id   of   my-instance-0   and
   my-instance-1,  respectively.  If  the  command  was  executed  on  the
   salt-master, its Salt key will automatically be signed on the master.

   Connectivity to the new "Salted" instances can  now  be  verified  with
   Salt:

      salt 'my-instance-*' test.ping

   Getting Started With Scaleway
   Scaleway  is the first IaaS host worldwide to offer an ARM based cloud.
   It's the ideal platform  for  horizontal  scaling  with  BareMetal  SSD
   servers.  The  solution  provides  on  demand  resources: it comes with
   on-demand SSD storage, movable IPs ,  images,  security  group  and  an
   Object Storage solution. https://scaleway.com

   Configuration
   Using  Salt  for Scaleway, requires an access key and an API token. API
   tokens are unique identifiers associated with  your  Scaleway  account.
   To  retrieve  your  access  key  and  API token, log-in to the Scaleway
   control panel, open the pull-down menu on your account name  and  click
   on "My Credentials" link.

   If you do not have API token you can create one by clicking the "Create
   New Token" button on the right corner.

      # Note: This example is for /etc/salt/cloud.providers or any file in the
      # /etc/salt/cloud.providers.d/ directory.

      my-scaleway-config:
        access_key: 15cf404d-4560-41b1-9a0c-21c3d5c4ff1f
        token: a7347ec8-5de1-4024-a5e3-24b77d1ba91d
        driver: scaleway

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider definitions was renamed  to
      driver.  This  change  was made to avoid confusion with the provider
      parameter that is used in cloud profile definitions. Cloud  provider
      definitions  now  use  driver to refer to the Salt cloud module that
      provides the underlying functionality to connect to  a  cloud  host,
      while  cloud  profiles continue to use provider to refer to provider
      configurations that you define.

   Profiles
   Cloud Profiles
   Set up  an  initial  profile  at  /etc/salt/cloud.profiles  or  in  the
   /etc/salt/cloud.profiles.d/ directory:

      scalewa-ubuntu:
        provider: my-scaleway-config
        image: Ubuntu Trusty (14.04 LTS)

   Images   can  be  obtained  using  the  --list-images  option  for  the
   salt-cloud command:

      #salt-cloud --list-images my-scaleway-config
      my-scaleway-config:
        ----------
        scaleway:
            ----------
            069fd876-eb04-44ab-a9cd-47e2fa3e5309:
                ----------
                arch:
                    arm
                creation_date:
                    2015-03-12T09:35:45.764477+00:00
                default_bootscript:
                    {u'kernel': {u'dtb': u'', u'title': u'Pimouss 3.2.34-30-std', u'id': u'cfda4308-cd6f-4e51-9744-905fc0da370f', u'path': u'kernel/pimouss-uImage-3.2.34-30-std'}, u'title': u'3.2.34-std #30 (stable)', u'id': u'c5af0215-2516-4316-befc-5da1cfad609c', u'initrd': {u'path': u'initrd/c1-uInitrd', u'id': u'1be14b1b-e24c-48e5-b0b6-7ba452e42b92', u'title': u'C1 initrd'}, u'bootcmdargs': {u'id': u'd22c4dde-e5a4-47ad-abb9-d23b54d542ff', u'value': u'ip=dhcp boot=local root=/dev/nbd0 USE_XNBD=1 nbd.max_parts=8'}, u'organization': u'11111111-1111-4111-8111-111111111111', u'public': True}
                extra_volumes:
                    []
                id:
                    069fd876-eb04-44ab-a9cd-47e2fa3e5309
                modification_date:
                    2015-04-24T12:02:16.820256+00:00
                name:
                    Ubuntu Vivid (15.04)
                organization:
                    a283af0b-d13e-42e1-a43f-855ffbf281ab
                public:
                    True
                root_volume:
                    {u'name': u'distrib-ubuntu-vivid-2015-03-12_10:32-snapshot', u'id': u'a6d02e63-8dee-4bce-b627-b21730f35a05', u'volume_type': u'l_ssd', u'size': 50000000000L}
      ...

   Execute a query and return all information about the nodes  running  on
   configured  cloud  providers  using  the  -Q  option for the salt-cloud
   command:

      # salt-cloud -F
      [INFO    ] salt-cloud starting
      [INFO    ] Starting new HTTPS connection (1): api.scaleway.com
      my-scaleway-config:
        ----------
        scaleway:
            ----------
            salt-manager:
                ----------
                creation_date:
                    2015-06-03T08:17:38.818068+00:00
                hostname:
                    salt-manager
      ...

   NOTE:
      Additional  documentation   about   Scaleway   can   be   found   at
      https://www.scaleway.com/docs.

   Getting Started With SoftLayer
   SoftLayer  is  a  public  cloud  host,  and  baremetal hardware hosting
   service.

   Dependencies
   The SoftLayer driver for Salt Cloud  requires  the  softlayer  package,
   which is available at PyPI:

   https://pypi.python.org/pypi/SoftLayer

   This package can be installed using pip or easy_install:

      # pip install softlayer
      # easy_install softlayer

   Configuration
   Set up the cloud config at /etc/salt/cloud.providers:

      # Note: These examples are for /etc/salt/cloud.providers

        my-softlayer:
          # Set up the location of the salt master
          minion:
            master: saltmaster.example.com

          # Set the SoftLayer access credentials (see below)
          user: MYUSER1138
          apikey: 'e3b68aa711e6deadc62d5b76355674beef7cc3116062ddbacafe5f7e465bfdc9'

          driver: softlayer

        my-softlayer-hw:
          # Set up the location of the salt master
          minion:
            master: saltmaster.example.com

          # Set the SoftLayer access credentials (see below)
          user: MYUSER1138
          apikey: 'e3b68aa711e6deadc62d5b76355674beef7cc3116062ddbacafe5f7e465bfdc9'

          driver: softlayer_hw

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Access Credentials
   The  user setting is the same user as is used to log into the SoftLayer
   Administration area. The apikey setting is found inside the Admin  area
   after logging in:

   * Hover over the Account menu item.

   * Click the Users link.

   * Find the API Key column and click View.

   Profiles
   Cloud Profiles
   Set up an initial profile at /etc/salt/cloud.profiles:

      base_softlayer_ubuntu:
        provider: my-softlayer
        image: UBUNTU_LATEST
        cpu_number: 1
        ram: 1024
        disk_size: 100
        local_disk: True
        hourly_billing: True
        domain: example.com
        location: sjc01
        # Optional
        max_net_speed: 1000
        private_vlan: 396
        private_network: True
        private_ssh: True
        # May be used _instead_of_ image
        global_identifier: 320d8be5-46c0-dead-cafe-13e3c51

   Most  of  the  above  items  are required; optional items are specified
   below.

   image
   Images to build an  instance  can  be  found  using  the  --list-images
   option:

      # salt-cloud --list-images my-softlayer

   The setting used will be labeled as template.

   cpu_number
   This  is  the  number of CPU cores that will be used for this instance.
   This number may be dependent upon the image that is used. For instance:

      Red Hat Enterprise Linux 6 - Minimal Install (64 bit) (1 - 4 Core):
          ----------
          name:
              Red Hat Enterprise Linux 6 - Minimal Install (64 bit) (1 - 4 Core)
          template:
              REDHAT_6_64
      Red Hat Enterprise Linux 6 - Minimal Install (64 bit) (5 - 100 Core):
          ----------
          name:
              Red Hat Enterprise Linux 6 - Minimal Install (64 bit) (5 - 100 Core)
          template:
              REDHAT_6_64

   Note that the template (meaning, the image option) for both of these is
   the same, but the names suggests how many CPU cores are supported.

   ram
   This  is  the amount of memory, in megabytes, that will be allocated to
   this instance.

   disk_size
   The amount of disk space that will  be  allocated  to  this  image,  in
   gigabytes.

      base_softlayer_ubuntu:
        disk_size: 100

   Using Multiple Disks
   New in version 2015.8.1.

   SoftLayer  allows  up  to 5 disks to be specified for a virtual machine
   upon creation. Multiple disks can be specified either as a  list  or  a
   comma-delimited  string. The first disk_size specified in the string or
   list will be the first disk size assigned to the VM.

   List Example:

      base_softlayer_ubuntu:
             disk_size: ['100', '20', '20']

   String Example:

      base_softlayer_ubuntu:
             disk_size: '100, 20, 20'

   local_disk
   When true the disks for the computing instance will be  provisioned  on
   the host which it runs, otherwise SAN disks will be provisioned.

   hourly_billing
   When  true  the  computing  instance  will  be  billed on hourly usage,
   otherwise it will be billed on a monthly basis.

   domain
   The domain name that will be used in the FQDN (Fully  Qualified  Domain
   Name) for this instance. The domain setting will be used in conjunction
   with the instance name to form the FQDN.

   use_fqdn
   If set to True, the Minion  will  be  identified  by  the  FQDN  (Fully
   Qualified  Domain  Name)  which  is  a  result  of combining the domain
   configuration value and the Minion name specified either via the CLI or
   a  map  file  rather than only using the short host name, or Minion ID.
   Default is False.

   New in version 2016.3.0.

   For example, if the value of domain is example.com and  a  new  VM  was
   created via the CLI with salt-cloud -p base_softlayer_ubuntu my-vm, the
   resulting Minion ID would be my-vm.example.com.

   NOTE:
      When enabling the use_fqdn setting, the Minion ID will be  the  FQDN
      and  will  interact  with salt commands with the FQDN instead of the
      short hostname. However,  due  to  the  way  the  SoftLayer  API  is
      constructed,  some  Salt  Cloud  functions  such as listing nodes or
      destroying VMs will only list the short hostname of the  VM  instead
      of the FQDN.

   Example output displaying the SoftLayer hostname quirk mentioned in the
   note above (note the Minion ID is my-vm.example.com, but the VM  to  be
   destroyed is listed with its short hostname, my-vm):

      # salt-key -L
      Accepted Keys:
      my-vm.example.com
      Denied Keys:
      Unaccepted Keys:
      Rejected Keys:
      #
      #
      # salt my-vm.example.com test.ping
      my-vm.example.com:
          True
      #
      #
      # salt-cloud -d my-vm.example.com
      [INFO    ] salt-cloud starting
      [INFO    ] POST https://api.softlayer.com/xmlrpc/v3.1/SoftLayer_Account
      The following virtual machines are set to be destroyed:
        softlayer-config:
          softlayer:
            my-vm

      Proceed? [N/y] y
      ... proceeding
      [INFO    ] Destroying in non-parallel mode.
      [INFO    ] POST https://api.softlayer.com/xmlrpc/v3.1/SoftLayer_Account
      [INFO    ] POST https://api.softlayer.com/xmlrpc/v3.1/SoftLayer_Virtual_Guest
      softlayer-config:
          ----------
          softlayer:
              ----------
              my-vm:
                  True

   location
   Images  to  build  an  instance can be found using the --list-locations
   option:

      # salt-cloud --list-location my-softlayer

   max_net_speed
   Specifies the connection speed for the instance's  network  components.
   This setting is optional. By default, this is set to 10.

   post_uri
   Specifies the uri location of the script to be downloaded and run after
   the instance is provisioned.

   New in version 2015.8.1.

   Example:

      base_softlayer_ubuntu:
             post_uri: 'https://SOMESERVERIP:8000/myscript.sh'

   public_vlan
   If it is necessary for an instance to  be  created  within  a  specific
   frontend  VLAN,  the  ID  for  that VLAN can be specified in either the
   provider or profile configuration.

   This ID can be queried using  the  list_vlans  function,  as  described
   below. This setting is optional.

   private_vlan
   If  it  is  necessary  for  an instance to be created within a specific
   backend VLAN, the ID for that VLAN  can  be  specified  in  either  the
   provider or profile configuration.

   This  ID  can  be  queried  using the list_vlans function, as described
   below. This setting is optional.

   private_network
   If a server is to only be used internally, meaning it does not  have  a
   public  VLAN  associated with it, this value would be set to True. This
   setting is optional. The default is False.

   private_ssh
   Whether to run the deploy script on the  server  using  the  public  IP
   address  or  the  private  IP  address. If set to True, Salt Cloud will
   attempt to SSH into the new server using the private  IP  address.  The
   default is False. This settiong is optional.

   global_identifier
   When  creating  an instance using a custom template, this option is set
   to  the  corresponding  value  obtained  using  the  list_custom_images
   function.  This  option  will not be used if an image is set, and if an
   image is not set, it is required.

   The profile can be realized now with a salt command:

      # salt-cloud -p base_softlayer_ubuntu myserver

   Using the above configuration, this will create myserver.example.com.

   Once  the  instance  has  been  created  with  salt-minion   installed,
   connectivity to it can be verified with Salt:

      # salt 'myserver.example.com' test.ping

   Cloud Profiles
   Set up an initial profile at /etc/salt/cloud.profiles:

      base_softlayer_hw_centos:
        provider: my-softlayer-hw
        # CentOS 6.0 - Minimal Install (64 bit)
        image: 13963
        # 2 x 2.0 GHz Core Bare Metal Instance - 2 GB Ram
        size: 1921
        # 500GB SATA II
        hdd: 1267
        # San Jose 01
        location: 168642
        domain: example.com
        # Optional
        vlan: 396
        port_speed: 273
        banwidth: 248

   Most  of  the  above  items  are required; optional items are specified
   below.

   image
   Images to build an  instance  can  be  found  using  the  --list-images
   option:

      # salt-cloud --list-images my-softlayer-hw

   A  list of id`s and names will be provided. The `name will describe the
   operating system and architecture. The id will be  the  setting  to  be
   used in the profile.

   size
   Sizes to build an instance can be found using the --list-sizes option:

      # salt-cloud --list-sizes my-softlayer-hw

   A  list of id`s and names will be provided. The `name will describe the
   speed and quantity of CPU cores, and the  amount  of  memory  that  the
   hardware  will  contain.  The  id will be the setting to be used in the
   profile.

   hdd
   There is currently only one size of  hard  disk  drive  (HDD)  that  is
   available for hardware instances on SoftLayer:

      1267: 500GB SATA II

   The hdd setting in the profile should be 1267. Other sizes may be added
   in the future.

   location
   Locations to build an instance can be  found  using  the  --list-images
   option:

      # salt-cloud --list-locations my-softlayer-hw

   A  list  of  IDs and names will be provided. The location will describe
   the location in human terms. The id will be the setting to be  used  in
   the profile.

   domain
   The  domain  name that will be used in the FQDN (Fully Qualified Domain
   Name) for this instance. The domain setting will be used in conjunction
   with the instance name to form the FQDN.

   vlan
   If  it  is  necessary  for  an instance to be created within a specific
   VLAN, the ID for that VLAN can be specified in either the  provider  or
   profile configuration.

   This  ID  can  be  queried  using the list_vlans function, as described
   below.

   port_speed
   Specifies the speed for  the  instance's  network  port.  This  setting
   refers  to  an  ID within the SoftLayer API, which sets the port speed.
   This setting is optional. The default is 273, or,  100  Mbps  Public  &
   Private Networks. The following settings are available:

   * 273: 100 Mbps Public & Private Networks

   * 274: 1 Gbps Public & Private Networks

   * 21509: 10 Mbps Dual Public & Private Networks (up to 20 Mbps)

   * 21513: 100 Mbps Dual Public & Private Networks (up to 200 Mbps)

   * 2314: 1 Gbps Dual Public & Private Networks (up to 2 Gbps)

   * 272: 10 Mbps Public & Private Networks

   bandwidth
   Specifies  the  network  bandwidth  available  for  the  instance. This
   setting refers to an ID  within  the  SoftLayer  API,  which  sets  the
   bandwidth.  This  setting  is optional. The default is 248, or, 5000 GB
   Bandwidth. The following settings are available:

   * 248: 5000 GB Bandwidth

   * 129: 6000 GB Bandwidth

   * 130: 8000 GB Bandwidth

   * 131: 10000 GB Bandwidth

   * 36: Unlimited Bandwidth (10 Mbps Uplink)

   * 125: Unlimited Bandwidth (100 Mbps Uplink)

   Actions
   The following actions are currently supported  by  the  SoftLayer  Salt
   Cloud driver.

   show_instance
   This  action  is  a  thin  wrapper  around --full-query, which displays
   details on a single instance  only.  In  an  environment  with  several
   machines,  this  will  save  a  user  from  having  to sort through all
   instance data, just to examine a single instance.

      $ salt-cloud -a show_instance myinstance

   Functions
   The following functions are currently supported by the  SoftLayer  Salt
   Cloud driver.

   list_vlans
   This  function  lists  all  VLANs  associated with the account, and all
   known data from the SoftLayer API concerning those VLANs.

      $ salt-cloud -f list_vlans my-softlayer
      $ salt-cloud -f list_vlans my-softlayer-hw

   The id returned in this list is necessary  for  the  vlan  option  when
   creating an instance.

   list_custom_images
   This  function  lists any custom templates associated with the account,
   that can be used to create a new instance.

      $ salt-cloud -f list_custom_images my-softlayer

   The globalIdentifier  returned  in  this  list  is  necessary  for  the
   global_identifier   option  when  creating  an  image  using  a  custom
   template.

   Optional Products for SoftLayer HW
   The softlayer_hw driver supports the ability to add optional  products,
   which  are supported by SoftLayer's API. These products each have an ID
   associated with them, that can be  passed  into  Salt  Cloud  with  the
   optional_products option:

      softlayer_hw_test:
        provider: my-softlayer-hw
        # CentOS 6.0 - Minimal Install (64 bit)
        image: 13963
        # 2 x 2.0 GHz Core Bare Metal Instance - 2 GB Ram
        size: 1921
        # 500GB SATA II
        hdd: 1267
        # San Jose 01
        location: 168642
        domain: example.com
        optional_products:
          # MySQL for Linux
          - id: 28
          # Business Continuance Insurance
          - id: 104

   These  values  can  be manually obtained by looking at the source of an
   order page on the SoftLayer web interface.  For  convenience,  many  of
   these values are listed here:

   Public Secondary IP Addresses
   * 22: 4 Public IP Addresses

   * 23: 8 Public IP Addresses

   Primary IPv6 Addresses
   * 17129: 1 IPv6 Address

   Public Static IPv6 Addresses
   * 1481: /64 Block Static Public IPv6 Addresses

   OS-Specific Addon
   * 17139: XenServer Advanced for XenServer 6.x

   * 17141: XenServer Enterprise for XenServer 6.x

   * 2334: XenServer Advanced for XenServer 5.6

   * 2335: XenServer Enterprise for XenServer 5.6

   * 13915: Microsoft WebMatrix

   * 21276: VMware vCenter 5.1 Standard

   Control Panel Software
   * 121: cPanel/WHM with Fantastico and RVskin

   * 20778: Parallels Plesk Panel 11 (Linux) 100 Domain w/ Power Pack

   * 20786: Parallels Plesk Panel 11 (Windows) 100 Domain w/ Power Pack

   * 20787:  Parallels  Plesk  Panel  11 (Linux) Unlimited Domain w/ Power
     Pack

   * 20792: Parallels Plesk Panel 11 (Windows) Unlimited Domain  w/  Power
     Pack

   * 2340: Parallels Plesk Panel 10 (Linux) 100 Domain w/ Power Pack

   * 2339: Parallels Plesk Panel 10 (Linux) Unlimited Domain w/ Power Pack

   * 13704:  Parallels  Plesk Panel 10 (Windows) Unlimited Domain w/ Power
     Pack

   Database Software
   * 29: MySQL 5.0 for Windows

   * 28: MySQL for Linux

   * 21501: Riak 1.x

   * 20893: MongoDB

   * 30: Microsoft SQL Server 2005 Express

   * 92: Microsoft SQL Server 2005 Workgroup

   * 90: Microsoft SQL Server 2005 Standard

   * 94: Microsoft SQL Server 2005 Enterprise

   * 1330: Microsoft SQL Server 2008 Express

   * 1340: Microsoft SQL Server 2008 Web

   * 1337: Microsoft SQL Server 2008 Workgroup

   * 1334: Microsoft SQL Server 2008 Standard

   * 1331: Microsoft SQL Server 2008 Enterprise

   * 2179: Microsoft SQL Server 2008 Express R2

   * 2173: Microsoft SQL Server 2008 Web R2

   * 2183: Microsoft SQL Server 2008 Workgroup R2

   * 2180: Microsoft SQL Server 2008 Standard R2

   * 2176: Microsoft SQL Server 2008 Enterprise R2

   Anti-Virus & Spyware Protection
   * 594: McAfee VirusScan Anti-Virus - Windows

   * 414: McAfee Total Protection - Windows

   Insurance
   * 104: Business Continuance Insurance

   Monitoring
   * 55: Host Ping

   * 56: Host Ping and TCP Service Monitoring

   Notification
   * 57: Email and Ticket

   Advanced Monitoring
   * 2302: Monitoring Package - Basic

   * 2303: Monitoring Package - Advanced

   * 2304: Monitoring Package - Premium Application

   Response
   * 58: Automated Notification

   * 59: Automated Reboot from Monitoring

   * 60: 24x7x365 NOC Monitoring, Notification, and Response

   Intrusion Detection & Protection
   * 413: McAfee Host Intrusion Protection w/Reporting

   Hardware & Software Firewalls
   * 411: APF Software Firewall for Linux

   * 894: Microsoft Windows Firewall

   * 410: 10Mbps Hardware Firewall

   * 409: 100Mbps Hardware Firewall

   * 408: 1000Mbps Hardware Firewall

   Getting Started with VEXXHOST
   VEXXHOST is a  cloud  computing  host  which  provides  Canadian  cloud
   computing  services  which  are  based in Monteral and use the libcloud
   OpenStack driver.   VEXXHOST  currently  runs  the  Havana  release  of
   OpenStack.   When  provisioning new instances, they automatically get a
   public IP and private IP address.  Therefore, you do not need to assign
   a floating IP to access your instance after it's booted.

   Cloud Provider Configuration
   To  use  the  openstack  driver for the VEXXHOST public cloud, you will
   need to set up the cloud provider configuration file as in the  example
   below:

   /etc/salt/cloud.providers.d/vexxhost.conf: In order to use the VEXXHOST
   public cloud, you will need to setup  a  cloud  provider  configuration
   file as in the example below which uses the OpenStack driver.

      my-vexxhost-config:
        # Set the location of the salt-master
        #
        minion:
          master: saltmaster.example.com

        # Configure VEXXHOST using the OpenStack plugin
        #
        identity_url: http://auth.api.thenebulacloud.com:5000/v2.0/tokens
        compute_name: nova

        # Set the compute region:
        #
        compute_region: na-yul-nhs1

        # Configure VEXXHOST authentication credentials
        #
        user: your-tenant-id
        password: your-api-key
        tenant: your-tenant-name

        # keys to allow connection to the instance launched
        #
        ssh_key_name: yourkey
        ssh_key_file: /path/to/key/yourkey.priv

        driver: openstack

   NOTE:
      Changed in version 2015.8.0.

      The  provider parameter in cloud provider definitions was renamed to
      driver. This change was made to avoid confusion  with  the  provider
      parameter  that is used in cloud profile definitions. Cloud provider
      definitions now use driver to refer to the Salt  cloud  module  that
      provides  the  underlying  functionality to connect to a cloud host,
      while cloud profiles continue to use provider to refer  to  provider
      configurations that you define.

   Authentication
   All  of the authentication fields that you need can be found by logging
   into your VEXXHOST customer center.  Once you've logged  in,  you  will
   need to click on "CloudConsole" and then click on "API Credentials".

   Cloud Profile Configuration
   In  order to get the correct image UUID and the instance type to use in
   the cloud profile, you can run the following command respectively:

      # salt-cloud --list-images=vexxhost-config
      # salt-cloud --list-sizes=vexxhost-config

   Once you have that, you can go ahead and create a  new  cloud  profile.
   This profile will build an Ubuntu 12.04 LTS nb.2G instance.

   /etc/salt/cloud.profiles.d/vh_ubuntu1204_2G.conf:

      vh_ubuntu1204_2G:
        provider: my-vexxhost-config
        image: 4051139f-750d-4d72-8ef0-074f2ccc7e5a
        size: nb.2G

   Provision an instance
   To  create  an  instance  based  on  the sample profile that we created
   above, you can run the following salt-cloud command.

      # salt-cloud -p vh_ubuntu1204_2G vh_instance1

   Typically, instances  are  provisioned  in  under  30  seconds  on  the
   VEXXHOST  public  cloud.  After the instance provisions, it will be set
   up a minion and then return all  the  instance  information  once  it's
   complete.

   Once  the  instance  has been setup, you can test connectivity to it by
   running the following command:

      # salt vh_instance1 test.ping

   You can now continue to provision  new  instances  and  they  will  all
   automatically  be set up as minions of the master you've defined in the
   configuration file.

   Getting Started With Virtualbox
   The Virtualbox cloud module allows you to  manage  a  local  Virtualbox
   hypervisor. Remote hypervisors may come later on.

   Dependencies
   The  virtualbox module for Salt Cloud requires the Virtualbox SDK which
   is contained in a virtualbox installation from

   https://www.virtualbox.org/wiki/Downloads

   Configuration
   The Virtualbox cloud module just needs to use the virtualbox driver for
   now. Virtualbox will be run as the running user.

   /etc/salt/cloud.providers                                            or
   /etc/salt/cloud.providers.d/virtualbox.conf:

      virtualbox-config:
         driver: virtualbox

   Profiles
   Set   up   an   initial   profile   at   /etc/salt/cloud.profiles    or
   /etc/salt/cloud.profiles.d/virtualbox.conf:

      virtualbox-test:
          provider: virtualbox-config
          clonefrom: VM_to_clone_from
          # Optional
          power_on: True
          deploy: True
          ssh_username: a_username
          password: a_password
          sudo: a_username
          sudo_password: a_password
          # Example minion config
          minion:
              master: localhost
          make_master: True

   clonefrom Mandatory
          Enter the name of the VM/template to clone from.

   So  far  only machines can only be cloned and automatically provisioned
   by Salt Cloud.

   Provisioning
   In order to provision when creating a new machine power_on  and  deploy
   have to be True.

   Furthermore to connect to the VM ssh_username and password will have to
   be set.

   sudo and sudo_password are the credentials for getting root  access  in
   order to deploy salt

   Actions
   start  Attempt  to  boot  a VM by name. VMs should have unique names in
          order to boot the correct one.

   stop   Attempt to stop a VM. This is akin to  a  force  shutdown  or  5
          second press.

   Functions
   show_image
          Show  all  available  information  about a VM given by the image
          parameter

             $ salt-cloud -f show_image virtualbox image=my_vm_name

   Getting Started With VMware
   New in version 2015.5.4.

   Author: Nitin Madhok <[email protected]>

   The VMware cloud module allows you to  manage  VMware  ESX,  ESXi,  and
   vCenter.

   Dependencies
   The vmware module for Salt Cloud requires the pyVmomi package, which is
   available at PyPI:

   https://pypi.python.org/pypi/pyvmomi

   This package can be installed using pip or easy_install:

      pip install pyvmomi
      easy_install pyvmomi

   NOTE:
      Version 6.0 of pyVmomi has some problems with SSL error handling  on
      certain  versions  of  Python.  If using version 6.0 of pyVmomi, the
      machine that you are running the proxy minion process from must have
      either  Python  2.7.9 or newer This is due to an upstream dependency
      in pyVmomi 6.0 that is not supported in Python version 2.6 to 2.7.8.
      If  the  version  of Python running the salt-cloud command is not in
      the supported range, you will need to install an earlier version  of
      pyVmomi. See Issue #29537 for more information.

   Configuration
   The VMware cloud module needs the vCenter or ESX/ESXi URL, username and
   password   to   be   set   up   in   the   cloud    configuration    at
   /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/vmware.conf:

      my-vmware-config:
        driver: vmware
        user: 'DOMAIN\user'
        password: 'verybadpass'
        url: '10.20.30.40'

      vcenter01:
        driver: vmware
        user: 'DOMAIN\user'
        password: 'verybadpass'
        url: 'vcenter01.domain.com'
        protocol: 'https'
        port: 443

      vcenter02:
        driver: vmware
        user: 'DOMAIN\user'
        password: 'verybadpass'
        url: 'vcenter02.domain.com'
        protocol: 'http'
        port: 80

      esx01:
        driver: vmware
        user: 'admin'
        password: 'verybadpass'
        url: 'esx01.domain.com'

   NOTE:
      Optionally, protocol and port can be specified if the vCenter server
      is not using the defaults. Default is protocol: https and port: 443.

   NOTE:
      Changed in version 2015.8.0.

      The provider parameter in cloud provider configuration  was  renamed
      to  driver.   This  change  was  made  to  avoid  confusion with the
      provider parameter that is  used  in  cloud  profile  configuration.
      Cloud  provider  configuration  now  uses  driver  to  refer  to the
      salt-cloud driver that  provides  the  underlying  functionality  to
      connect  to  a  cloud  provider,  while  cloud profile configuration
      continues  to  use  provider  to  refer  to   the   cloud   provider
      configuration that you define.

   Profiles
   Set    up   an   initial   profile   at   /etc/salt/cloud.profiles   or
   /etc/salt/cloud.profiles.d/vmware.conf:

      vmware-centos6.5:
        provider: vcenter01
        clonefrom: test-vm

        ## Optional arguments
        num_cpus: 4
        memory: 8GB
        devices:
          cd:
            CD/DVD drive 1:
              device_type: datastore_iso_file
              iso_path: "[nap004-1] vmimages/tools-isoimages/linux.iso"
            CD/DVD drive 2:
              device_type: client_device
              mode: atapi
              controller: IDE 2
            CD/DVD drive 3:
              device_type: client_device
              mode: passthrough
              controller: IDE 3
          disk:
            Hard disk 1:
              size: 30
            Hard disk 2:
              size: 20
              controller: SCSI controller 2
            Hard disk 3:
              size: 5
              controller: SCSI controller 3
          network:
            Network adapter 1:
              name: 10.20.30-400-Test
              switch_type: standard
              ip: 10.20.30.123
              gateway: [10.20.30.110]
              subnet_mask: 255.255.255.128
              domain: example.com
            Network adapter 2:
              name: 10.30.40-500-Dev-DHCP
              adapter_type: e1000
              switch_type: distributed
            Network adapter 3:
              name: 10.40.50-600-Prod
              adapter_type: vmxnet3
              switch_type: distributed
              ip: 10.40.50.123
              gateway: [10.40.50.110]
              subnet_mask: 255.255.255.128
              domain: example.com
          scsi:
            SCSI controller 1:
              type: lsilogic
            SCSI controller 2:
              type: lsilogic_sas
              bus_sharing: virtual
            SCSI controller 3:
              type: paravirtual
              bus_sharing: physical
          ide:
            IDE 2
            IDE 3

        domain: example.com
        dns_servers:
          - 123.127.255.240
          - 123.127.255.241
          - 123.127.255.242

        resourcepool: Resources
        cluster: Prod

        datastore: HUGE-DATASTORE-Cluster
        folder: Development
        datacenter: DC1
        host: c4212n-002.domain.com
        template: False
        power_on: True
        extra_config:
          mem.hotadd: 'yes'
          guestinfo.foo: bar
          guestinfo.domain: foobar.com
          guestinfo.customVariable: customValue

        deploy: True
        customization: True
        private_key: /root/.ssh/mykey.pem
        ssh_username: cloud-user
        password: veryVeryBadPassword
        minion:
          master: 123.127.193.105

        file_map:
          /path/to/local/custom/script: /path/to/remote/script
          /path/to/local/file: /path/to/remote/file
          /srv/salt/yum/epel.repo: /etc/yum.repos.d/epel.repo

        hardware_version: 10
        image: centos64Guest

        #For Windows VM
        win_username: Administrator
        win_password: administrator
        win_organization_name: ABC-Corp
        plain_text: True
        win_installer: /root/Salt-Minion-2015.8.4-AMD64-Setup.exe
        win_user_fullname: Windows User

   provider
          Enter the name that was specified when the cloud provider config
          was created.

   clonefrom
          Enter  the  name  of  the  VM/template  to  clone  from.  If not
          specified, the VM will be created without cloning.

   num_cpus
          Enter the number of vCPUS that you want the VM/template to have.
          If not specified, the current VM/template's vCPU count is used.

   cores_per_socket
          New in version 2016.11.0.

          Enter the number of cores per vCPU that you want the VM/template
          to have. If not specified, this will default to 1.

          NOTE:
             Cores per socket should be less than or equal  to  the  total
             number of vCPUs assigned to the VM/template.

   memory Enter  the  memory  size  (in  MB  or  GB)  that  you  want  the
          VM/template to have. If not specified, the current VM/template's
          memory size is used. Example memory: 8GB or memory: 8192MB.

   devices
          Enter  the  device specifications here. Currently, the following
          devices can be created or reconfigured:

          cd     Enter the CD/DVD drive specification here. If the  CD/DVD
                 drive   doesn't  exist,  it  will  be  created  with  the
                 specified configuration.  If  the  CD/DVD  drive  already
                 exists,  it will be reconfigured with the specifications.
                 The following options can be specified per CD/DVD drive:

                 device_type
                        Specify how  the  CD/DVD  drive  should  be  used.
                        Currently  supported  types  are client_device and
                        datastore_iso_file.   Default   is    device_type:
                        client_device

                 iso_path
                        Enter  the  path  to  the  iso file present on the
                        datastore only if device_type: datastore_iso_file.
                        The   syntax   to   specify   this   is  iso_path:
                        "[datastoreName]
                        vmimages/tools-isoimages/linux.iso". This field is
                        ignored if device_type: client_device

                 mode   Enter the mode of connection only if  device_type:
                        client_device.   Currently   supported  modes  are
                        passthrough and atapi. This field  is  ignored  if
                        device_type:  datastore_iso_file. Default is mode:
                        passthrough

                 controller
                        Specify the IDE controller  label  to  which  this
                        drive   should   be   attached.   This  should  be
                        specified only when creating  both  the  specified
                        IDE  controller as well as the CD/DVD drive at the
                        same time.

          disk   Enter the disk  specification  here.  If  the  hard  disk
                 doesn't exist, it will be created with the provided size.
                 If the hard disk already exists, it will be  expanded  if
                 the provided size is greater than the current size of the
                 disk.

                 size   Enter the size of disk in GB

                 thin_provision
                        Specifies  whether  the  disk   should   be   thin
                        provisioned  or  not.  Default  is thin_provision:
                        False.

                 controller
                        Specify the SCSI controller label  to  which  this
                        disk should be attached.  This should be specified
                        only  when  creating  both  the   specified   SCSI
                        controller  as  well  as the hard disk at the same
                        time.

          network
                 Enter the network  adapter  specification  here.  If  the
                 network adapter doesn't exist, a new network adapter will
                 be created with the  specified  network  name,  type  and
                 other  configuration.  If  the  network  adapter  already
                 exists, it will be reconfigured with the  specifications.
                 The  following  additional  options  can be specified per
                 network adapter (See example above):

                 name   Enter  the  network  name  you  want  the  network
                        adapter to be mapped to.

                 adapter_type
                        Enter the network adapter type you want to create.
                        Currently supported  types  are  vmxnet,  vmxnet2,
                        vmxnet3,   e1000   and  e1000e.   If  no  type  is
                        specified, by default vmxnet3 will be used.

                 switch_type
                        Enter the type of  switch  to  use.  This  decides
                        whether  to  use  a  standard  switch network or a
                        distributed virtual portgroup. Currently supported
                        types  are  standard  for  standard portgroups and
                        distributed for distributed virtual portgroups.

                 ip     Enter the static IP you want the  network  adapter
                        to  be mapped to. If the network specified is DHCP
                        enabled, you do not have to specify this.

                 gateway
                        Enter the gateway for the network as  a  list.  If
                        the  network specified is DHCP enabled, you do not
                        have to specify this.

                 subnet_mask
                        Enter the subnet mask  for  the  network.  If  the
                        network specified is DHCP enabled, you do not have
                        to specify this.

                 domain Enter the domain  to  be  used  with  the  network
                        adapter. If the network specified is DHCP enabled,
                        you do not have to specify this.

          scsi   Enter the SCSI controller specification here. If the SCSI
                 controller  doesn't  exist, a new SCSI controller will be
                 created of the specified type.  If  the  SCSI  controller
                 already   exists,   it  will  be  reconfigured  with  the
                 specifications. The following additional options  can  be
                 specified per SCSI controller:

                 type   Enter the SCSI controller type you want to create.
                        Currently   supported    types    are    lsilogic,
                        lsilogic_sas   and   paravirtual.   Type  must  be
                        specified when creating a new SCSI controller.

                 bus_sharing
                        Specify this if sharing of virtual  disks  between
                        virtual machines is desired.  The following can be
                        specified:

                        virtual
                               Virtual disks can be shared between virtual
                               machines on the same server.

                        physical
                               Virtual disks can be shared between virtual
                               machines on any server.

                        no     Virtual  disks  cannot  be  shared  between
                               virtual machines.

          ide    Enter  the  IDE controller specification here. If the IDE
                 controller doesn't exist, a new IDE  controller  will  be
                 created. If the IDE controller already exists, no further
                 changes to it will me made.

   domain Enter the global  domain  name  to  be  used  for  DNS.  If  not
          specified  and  if  the  VM name is a FQDN, domain is set to the
          domain from the VM name. Default is local.

   dns_servers
          Enter the list of DNS servers to use in order of priority.

   resourcepool
          Enter the name of the resourcepool  to  which  the  new  virtual
          machine   should  be  attached.  This  determines  what  compute
          resources will be available to the clone.

          NOTE:

             * For a clone operation from a virtual machine, it  will  use
               the  same  resourcepool  as  the  original  virtual machine
               unless specified.

             * For a clone operation from a template to a virtual machine,
               specifying  either this or cluster is required. If both are
               specified, the resourcepool value will be used.

             * For a clone operation  to  a  template,  this  argument  is
               ignored.

   cluster
          Enter  the  name  of  the  cluster  whose  resource pool the new
          virtual machine should be attached to.

          NOTE:

             * For a clone operation from a virtual machine, it  will  use
               the  same  cluster's  resourcepool  as the original virtual
               machine unless specified.

             * For a clone operation from a template to a virtual machine,
               specifying either this or resourcepool is required. If both
               are specified, the resourcepool value will be used.

             * For a clone operation  to  a  template,  this  argument  is
               ignored.

   datastore
          Enter  the  name of the datastore or the datastore cluster where
          the virtual machine should be located on  physical  storage.  If
          not specified, the current datastore is used.

          NOTE:

             * If  you  specify  a  datastore  cluster  name,  DRS Storage
               recommendation is automatically applied.

             * If you specify a datastore name, DRS Storage recommendation
               is disabled.

   folder Enter  the  name of the folder that will contain the new virtual
          machine.

          NOTE:

             * For  a  clone  operation  from  a  VM/template,   the   new
               VM/template  will  be  added  to  the  same folder that the
               original VM/template belongs to unless specified.

             * If both folder and datacenter  are  specified,  the  folder
               value will be used.

   datacenter
          Enter  the  name  of  the  datacenter  that will contain the new
          virtual machine.

          NOTE:

             * For  a  clone  operation  from  a  VM/template,   the   new
               VM/template  will  be  added  to  the  same folder that the
               original VM/template belongs to unless specified.

             * If both folder and datacenter  are  specified,  the  folder
               value will be used.

   host   Enter  the  name  of  the  target host where the virtual machine
          should be registered.

          If not specified:

          NOTE:

             * If resource pool is not specified, current host is used.

             * If  resource  pool  is  specified,  and  the  target   pool
               represents a stand-alone host, the host is used.

             * If   resource  pool  is  specified,  and  the  target  pool
               represents a DRS-enabled cluster, a host selected by DRS is
               used.

             * If   resource   pool  is  specified  and  the  target  pool
               represents   a   cluster   without    DRS    enabled,    an
               InvalidArgument exception be thrown.

   template
          Specifies  whether the new virtual machine should be marked as a
          template or not.  Default is template: False.

   power_on
          Specifies whether the new virtual machine should be  powered  on
          or not. If template: True is set, this field is ignored. Default
          is power_on: True.

   extra_config
          Specifies  the  additional  configuration  information  for  the
          virtual  machine.  This  describes a set of modifications to the
          additional options. If the key is already present,  it  will  be
          reset  with  the  new value provided. Otherwise, a new option is
          added. Keys with empty values will be removed.

   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 power_on: False is set, this  field
          is ignored and salt will not be installed.

   customization
          Specify  whether the new virtual machine should be customized or
          not. If customization: False is set,  the  new  virtual  machine
          will not be customized.  Default is customization: True.

   private_key
          Specify  the path to the private key to use to be able to ssh to
          the VM.

   ssh_username
          Specify the username to use in order to ssh to the  VM.  Default
          is root

   password
          Specify  a  password  to  use  in  order  to  ssh  to the VM. If
          private_key is specified, you do not need to specify this.

   minion Specify custom minion configuration you want the salt minion  to
          have.  A  good  example  would  be  to specify the master as the
          IP/DNS name of the master.

   file_map
          Specify file/files you  want  to  copy  to  the  VM  before  the
          bootstrap script is run and salt is installed. A good example of
          using this would be if you need to put custom repo files on  the
          server  in  case  your  server  will be in a private network and
          cannot reach external networks.

   hardware_version
          Specify the virtual hardware version for the vm/template that is
          supported by the host.

   image  Specify  the  guest  id  of the VM. For a full list of supported
          values see the VMware vSphere documentation:

          http://pubs.vmware.com/vsphere-60/topic/com.vmware.wssdk.apiref.doc/vim.vm.GuestOsDescriptor.GuestOsIdentifier.html

          NOTE:
             For a clone operation, this argument is ignored.

   win_username
          Specify windows vm administrator account.

          NOTE:
             Windows template should have "administrator" account.

   win_password
          Specify windows vm administrator account password.

          NOTE:
             During  network  configuration  (if network specified), it is
             used to specify new administrator password for the machine.

   win_organization_name

          Specify windows vm  user's  organization.  Default  organization
          name is Organization
                 VMware vSphere documentation:

          https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html

   win_user_fullname

          Specify windows vm user's fullname. Default fullname is  Windows
          User
                 VMware vSphere documentation:

          https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html

   plain_text
          Flag to specify whether or not the password is  in  plain  text,
          rather than encrypted.  VMware vSphere documentation:

          https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.Password.html

   win_installer
          Specify windows minion client installer path

   Cloning a VM
   Cloning VMs/templates is the easiest and the preferred way to work with
   VMs using the VMware driver.

   NOTE:
      Cloning  operations  are  unsupported  on  standalone  ESXi hosts, a
      vCenter server will be required.

   Example of a minimal profile:

      my-minimal-clone:
        provider: vcenter01
        clonefrom: 'test-vm'

   When cloning  a  VM,  all  the  profile  configuration  parameters  are
   optional and the configuration gets inherited from the clone.

   Example to add/resize a disk:

      my-disk-example:
        provider: vcenter01
        clonefrom: 'test-vm'

        devices:
          disk:
            Hard disk 1:
              size: 30

   Depending  on  the  configuration of the VM that is getting cloned, the
   disk in the resulting clone will differ.

   NOTE:

      * If the VM has no disk named 'Hard disk 1' an empty disk  with  the
        specified size will be added to the clone.

      * If the VM has a disk named 'Hard disk 1' and the size specified is
        larger than the original disk, an empty disk  with  the  specified
        size will be added to the clone.

      * If the VM has a disk named 'Hard disk 1' and the size specified is
        smaller than the original disk, an empty disk  with  the  original
        size will be added to the clone.

   Example to reconfigure the memory and number of vCPUs:

      my-disk-example:
        provider: vcenter01
        clonefrom: 'test-vm'

        memory: 16GB
        num_cpus: 8

   Cloning a Template
   Cloning  a  template  works similar to cloning a VM except for the fact
   that a resource pool or cluster must be specified additionally  in  the
   profile.

   Example of a minimal profile:

      my-template-clone:
       provider: vcenter01
       clonefrom: 'test-template'
       cluster: 'Prod'

   Cloning from a Snapshot
   New in version 2016.3.5.

   Cloning  from  a snapshot requires that one of the supported options be
   set in the cloud profile.

   Supported        options         are         createNewChildDiskBacking,
   moveChildMostDiskBacking,     moveAllDiskBackingsAndAllowSharing    and
   moveAllDiskBackingsAndDisallowSharing.

   Example of a minimal profile:

      my-template-clone:
        provider: vcenter01
        clonefrom: 'salt_vm'
        snapshot:
          disk_move_type: createNewChildDiskBacking
          # these types are also supported
          # disk_move_type: moveChildMostDiskBacking
          # disk_move_type: moveAllDiskBackingsAndAllowSharing
          # disk_move_type: moveAllDiskBackingsAndDisallowSharing

   Creating a VM
   New in version 2016.3.0.

   Creating a VM from scratch means that  more  configuration  has  to  be
   specified  in  the  profile  because  there  is  no  place  to  inherit
   configuration from.

   NOTE:
      Unlike most cloud drivers that use  prepared  images,  creating  VMs
      using VMware cloud driver needs an installation method that requires
      no human interaction.  For Example: preseeded ISO, kickstart URL  or
      network PXE boot.

   Example of a minimal profile:

      my-minimal-profile:
        provider: esx01
        datastore: esx01-datastore
        resourcepool: Resources
        folder: vm

   NOTE:
      The example above contains the minimum required configuration needed
      to create a VM from scratch. The resulting VM will only have 1 VCPU,
      32MB of RAM and will not have any storage or networking.

   Example of a complete profile:

      my-complete-example:
        provider: esx01
        datastore: esx01-datastore
        resourcepool: Resources
        folder: vm

        num_cpus: 2
        memory: 8GB

        image: debian7_64Guest

        devices:
          scsi:
            SCSI controller 0:
              type: lsilogic_sas
          ide:
            IDE 0
            IDE 1
          disk:
            Hard disk 0:
              controller: 'SCSI controller 0'
              size: 20
              mode: 'independent_nonpersistent'
          cd:
            CD/DVD drive 0:
              controller: 'IDE 0'
              device_type: datastore_iso_file
              iso_path: '[esx01-datastore] debian-8-with-preseed.iso'
          network:
            Network adapter 0:
              name: 'VM Network'
              swith_type: standard

   NOTE:
      Depending on VMware ESX/ESXi version, an exact match for image might
      not be available. In such cases, the closest match to another  image
      should be used. In the example above, a Debian 8 VM is created using
      the image debian7_64Guest which is for a Debian 7 guest.

   Specifying disk backing mode
   New in version 2016.3.5.

   Disk backing mode can now be specified when cloning a VM.  This  option
   can be set in the cloud profile as shown in example below:

      my-vm:
        provider: esx01
        datastore: esx01-datastore
        resourcepool: Resources
        folder: vm

        devices:
          disk:
            Hard disk 1:
              mode: 'independent_nonpersistent'
              size: 42

            Hard disk 2:
              mode: 'independent_nonpersistent'

   Miscellaneous Options
   Miscellaneous Salt Cloud Options
   This  page  describes  various  miscellaneous options available in Salt
   Cloud

   Deploy Script Arguments
   Custom deploy scripts are unlikely  to  need  custom  arguments  to  be
   passed  to  them, but salt-bootstrap has been extended quite a bit, and
   this may be necessary. script_args  can  be  specified  in  either  the
   profile or the map file, to pass arguments to the deploy script:

      ec2-amazon:
        provider: my-ec2-config
        image: ami-1624987f
        size: t1.micro
        ssh_username: ec2-user
        script: bootstrap-salt
        script_args: -c /tmp/

   This has also been tested to work with pipes, if needed:

      script_args: | head

   Selecting the File Transport
   By  default,  Salt  Cloud  uses  SFTP to transfer files to Linux hosts.
   However, if SFTP is not available, or  specific  SCP  functionality  is
   needed, Salt Cloud can be configured to use SCP instead.

      file_transport: sftp
      file_transport: scp

   Sync After Install
   Salt  allows  users  to create custom modules, grains, and states which
   can  be  synchronised  to  minions  to   extend   Salt   with   further
   functionality.

   This  option will inform Salt Cloud to synchronise your custom modules,
   grains, states or all these to  the  minion  just  after  it  has  been
   created.  For  this  to happen, the following line needs to be added to
   the main cloud configuration file:

      sync_after_install: all

   The available options for this setting are:

      modules
      grains
      states
      all

   Setting Up New Salt Masters
   It has become increasingly common for users to set up  multi-hierarchal
   infrastructures using Salt Cloud. This sometimes involves setting up an
   instance to be a master in addition to a minion. With that in mind, you
   can now lay down master configuration on a machine by specifying master
   options in the profile or map file.

      make_master: True

   This will cause Salt Cloud to generate master keys  for  the  instance,
   and tell salt-bootstrap to install the salt-master package, in addition
   to the salt-minion package.

   The default master configuration is usually appropriate for most users,
   and  will  not be changed unless specific master configuration has been
   added to the profile or map:

      master:
        user: root
        interface: 0.0.0.0

   Setting Up a Salt Syndic with Salt Cloud
   In addition to setting up  new  Salt  Masters,  syndic`s  can  also  be
   provisioned using Salt Cloud. In order to set up a Salt Syndic via Salt
   Cloud, a Salt Master needs to be installed on the  new  machine  and  a
   master  configuration  file needs to be set up using the ``make_master`
   setting. This setting can be 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 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:

      master:
        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.  See the syndic documentation for more information.

   SSH Port
   By default ssh port is set to port 22. If you want to use a custom port
   in provider, profile, or map blocks use ssh_port option.

   New in version 2015.5.0.

      ssh_port: 2222

   SSH Port
   By default ssh port is set to port 22. If you want to use a custom port
   in provider, profile, or map blocks use ssh_port option.

      ssh_port: 2222

   Delete SSH Keys
   When  Salt  Cloud deploys an instance, the SSH pub key for the instance
   is added to the known_hosts file for the user that ran  the  salt-cloud
   command.  When an instance is deployed, a cloud host generally recycles
   the IP address for the instance.  When Salt Cloud attempts to deploy an
   instance  using a recycled IP address that has previously been accessed
   from the same machine, the old key in the known_hosts file will cause a
   conflict.

   In order to mitigate this issue, Salt Cloud can be configured to remove
   old keys from the known_hosts file when destroying the node.  In  order
   to  do  this,  the  following  line needs to be added to the main cloud
   configuration file:

      delete_sshkeys: True

   Keeping /tmp/ Files
   When Salt Cloud deploys an instance,  it  uploads  temporary  files  to
   /tmp/  for  salt-bootstrap  to  put in place. After the script has run,
   they are deleted. To keep these  files  around  (mostly  for  debugging
   purposes), the --keep-tmp option can be added:

      salt-cloud -p myprofile mymachine --keep-tmp

   For  those  wondering why /tmp/ was used instead of /root/, this had to
   be done for images which require the use of sudo, and therefore do  not
   allow  remote  root logins, even for file transfers (which makes /root/
   unavailable).

   Hide Output From Minion Install
   By default Salt Cloud will stream the output  from  the  minion  deploy
   script  directly  to  STDOUT.  Although  this  can been very useful, in
   certain cases you may wish to switch this  off.  The  following  config
   option is there to enable or disable this output:

      display_ssh_output: False

   Connection Timeout
   There  are several stages when deploying Salt where Salt Cloud needs to
   wait for something to happen. The VM getting it's IP address, the  VM's
   SSH port is available, etc.

   If  you  find  that  the  Salt  Cloud  defaults are not enough and your
   deployment fails because Salt Cloud did not wait log enough, there  are
   some settings you can tweak.

      Note

             All  settings  should  be  provided  in  lowercase All values
             should be provided in seconds

   You can tweak these settings globally, per cloud provider, or event per
   profile definition.

   wait_for_ip_timeout
   The  amount of time Salt Cloud should wait for a VM to start and get an
   IP back from the cloud host.   Default:  varies  by  cloud  provider  (
   between 5 and 25 minutes)

   wait_for_ip_interval
   The  amount of time Salt Cloud should sleep while querying for the VM's
   IP.  Default: varies by cloud provider ( between .5 and 10 seconds)

   ssh_connect_timeout
   The amount of  time  Salt  Cloud  should  wait  for  a  successful  SSH
   connection  to  the  VM.  Default: varies by cloud provider  (between 5
   and 15 minutes)

   wait_for_passwd_timeout
   The amount of time until an  ssh  connection  can  be  established  via
   password  or  ssh  key.   Default:  varies by cloud provider (mostly 15
   seconds)

   wait_for_passwd_maxtries
   The number of attempts to connect to the VM until we abandon.  Default:
   15 attempts

   wait_for_fun_timeout
   Some  cloud  drivers  check  for  an  available  IP or a successful SSH
   connection using a function, namely, SoftLayer, and  SoftLayer-HW.  So,
   the  amount  of  time  Salt  Cloud  should  retry such functions before
   failing.  Default: 15 minutes.

   wait_for_spot_timeout
   The amount of time Salt Cloud should wait before an EC2  Spot  instance
   is  available. This setting is only available for the EC2 cloud driver.
   Default: 10  minutes

   Salt Cloud Cache
   Salt Cloud can maintain a cache of node data, for supported  providers.
   The following options manage this functionality.

   update_cachedir
   On  supported  cloud  providers,  whether or not to maintain a cache of
   nodes returned from a --full-query. The data will be stored in  msgpack
   format                                                            under
   <SALT_CACHEDIR>/cloud/active/<DRIVER>/<PROVIDER>/<NODE_NAME>.p.    This
   setting can be True or False.

   diff_cache_events
   When   the   cloud  cachedir  is  being  managed,  if  differences  are
   encountered between the data that is returned live from the cloud  host
   and the data in the cache, fire events which describe the changes. This
   setting can be True or False.

   Some of these events will contain data which describe a  node.  Because
   some   of   the   fields  returned  may  contain  sensitive  data,  the
   cache_event_strip_fields configuration option  exists  to  strip  those
   fields from the event return.

      cache_event_strip_fields:
        - password
        - priv_key

   The following are events that can be fired based on this data.

   salt/cloud/minionid/cache_node_new
   A  new  node  was  found  on the cloud host which was not listed in the
   cloud cachedir. A dict describing the new node will be contained in the
   event.

   salt/cloud/minionid/cache_node_missing
   A  node  that  was previously listed in the cloud cachedir is no longer
   available on the cloud host.

   salt/cloud/minionid/cache_node_diff
   One or more pieces of data in the cloud cachedir  has  changed  on  the
   cloud  host.  A  dict  containing both the old and the new data will be
   contained in the event.

   SSH Known Hosts
   Normally when bootstrapping a VM, salt-cloud will ignore the  SSH  host
   key.  This  is  because  it  does  not know what the host key is before
   starting (because it doesn't exist yet). If strict host key checking is
   turned  on  without the key in the known_hosts file, then the host will
   never be available, and cannot be bootstrapped.

   If a provider is able to  determine  the  host  key  before  trying  to
   bootstrap  it,  that  provider's  driver  can add it to the known_hosts
   file, and then turn on strict host key checking. This can be set up  in
   the  main cloud configuration file (normally /etc/salt/cloud) or in the
   provider-specific configuration file:

      known_hosts_file: /path/to/.ssh/known_hosts

   If this is not set, it will default to /dev/null, and strict  host  key
   checking will be turned off.

   It  is  highly recommended that this option is not set, unless the user
   has verified that the provider supports this  functionality,  and  that
   the image being used is capable of providing the necessary information.
   At this time, only the EC2 driver supports this functionality.

   SSH Agent
   New in version 2015.5.0.

   If the ssh key is not stored on the server salt-cloud is being run  on,
   set  ssh_agent,  and  salt-cloud  will  use  the forwarded ssh-agent to
   authenticate.

      ssh_agent: True

   File Map Upload
   New in version 2014.7.0.

   The file_map option allows an arbitrary group of files to  be  uploaded
   to   the   target   system  before  running  the  deploy  script.  This
   functionality requires a  provider  uses  salt.utils.cloud.bootstrap(),
   which is currently limited to the ec2, gce, openstack and nova drivers.

   The  file_map  can be configured globally in /etc/salt/cloud, or in any
   cloud provider or profile file. For example, to upload an extra package
   or  a  custom  deploy script, a cloud profile using file_map might look
   like:

      ubuntu14:
        provider: ec2-config
        image: ami-98aa1cf0
        size: t1.micro
        ssh_username: root
        securitygroup: default
        file_map:
          /local/path/to/custom/script: /remote/path/to/use/custom/script
          /local/path/to/package: /remote/path/to/store/package

   Troubleshooting Steps
   Troubleshooting Salt Cloud
   This page describes various steps for troubleshooting problems that may
   arise while using Salt Cloud.

   Virtual Machines Are Created, But Do Not Respond
   Are  TCP  ports  4505  and  4506  open  on  the master? This is easy to
   overlook on new masters. Information on how to open firewall  ports  on
   various platforms can be found here.

   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.

      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 deployment which would otherwise not be obvious:

      salt-cloud -p myprofile myinstance -l debug

   Keep in mind that a number of messages will appear that look  at  first
   like  errors,  but  are  in  fact  intended  to give developers factual
   information to assist in debugging. A number of  messages  that  appear
   will  be  for cloud providers that you do not have configured; in these
   cases, the message usually is intended to confirm  that  they  are  not
   configured.

   Salt Bootstrap
   By  default,  Salt  Cloud  uses  the Salt Bootstrap script to provision
   instances:

   This script is packaged with Salt Cloud, but  may  be  updated  without
   updating the Salt package:

      salt-cloud -u

   The Bootstrap Log
   If  the  default  deploy script was used, there should be a file in the
   /tmp/ directory called bootstrap-salt.log. This file contains the  full
   output  from  the  deployment,  including  any  errors  that  may  have
   occurred.

   Keeping Temp Files
   Salt Cloud uploads minion-specific files to  instances  once  they  are
   available  via  SSH, and then executes a deploy script to put them into
   the correct place and install Salt. The --keep-tmp option will instruct
   Salt  Cloud  not to remove those files when finished with them, so that
   the user may inspect them for problems:

      salt-cloud -p myprofile myinstance --keep-tmp

   By default, Salt Cloud will create a directory on the  target  instance
   called  /tmp/.saltcloud/.  This  directory  should be owned by the user
   that is to execute the deploy script, and should  have  permissions  of
   0700.

   Most cloud hosts are configured to use root as the default initial user
   for deployment, and as such, this directory and all files in it  should
   be owned by the root user.

   The /tmp/.saltcloud/ directory should the following files:

   * A deploy.sh script. This script should have permissions of 0755.

   * A .pem and .pub key named after the minion. The .pem file should have
     permissions of 0600. Ensure that the .pem and .pub  files  have  been
     properly copied to the /etc/salt/pki/minion/ directory.

   * A  file  called  minion.  This  file  should  have been copied to the
     /etc/salt/ directory.

   * Optionally, a file called grains. This file, if present, should  have
     been copied to the /etc/salt/ directory.

   Unprivileged Primary Users
   Some  cloud  hosts,  most  notably EC2, are configured with a different
   primary user.  Some common examples are ec2-user, ubuntu,  fedora,  and
   bitnami.   In these cases, the /tmp/.saltcloud/ directory and all files
   in it should be owned by this user.

   Some cloud hosts, such as EC2, are  configured  to  not  require  these
   users  to provide a password when using the sudo command. Because it is
   more secure to require sudo users to provide a  password,  other  hosts
   are configured that way.

   If  this  instance  is  required  to provide a password, it needs to be
   configured in Salt Cloud. A password for sudo to use may  be  added  to
   either the provider configuration or the profile configuration:

      sudo_password: mypassword

   /tmp/ is Mounted as noexec
   It  is  more  secure to mount the /tmp/ directory with a noexec option.
   This is uncommon on most  cloud  hosts,  but  very  common  in  private
   environments.  To  see  if the /tmp/ directory is mounted this way, run
   the following command:

      mount | grep tmp

   The if the output of this command includes a line that looks like this,
   then the /tmp/ directory is mounted as noexec:

      tmpfs on /tmp type tmpfs (rw,noexec)

   If this is the case, then the deploy_command will need to be changed in
   order to run the deploy script through  the  sh  command,  rather  than
   trying  to  execute  it  directly.  This may be specified in either the
   provider or the profile config:

      deploy_command: sh /tmp/.saltcloud/deploy.sh

   Please note that by default, Salt Cloud  will  place  its  files  in  a
   directory  called  /tmp/.saltcloud/. This may be also be changed in the
   provider or profile configuration:

      tmp_dir: /tmp/.saltcloud/

   If this directory is  changed,  then  the  deploy_command  need  to  be
   changed in order to reflect the tmp_dir configuration.

   Executing the Deploy Script Manually
   If all of the files needed for deployment were successfully uploaded to
   the  correct  locations,  and  contain  the  correct  permissions   and
   ownerships,  the  deploy  script  may  be executed manually in order to
   check for other issues:

      cd /tmp/.saltcloud/
      ./deploy.sh

   Extending Salt Cloud
   Writing Cloud Driver Modules
   Salt Cloud runs on a module system similar to the  main  Salt  project.
   The  modules  inside saltcloud exist in the salt/cloud/clouds directory
   of the salt source.

   There are two basic  types  of  cloud  modules.  If  a  cloud  host  is
   supported  by libcloud, then using it is the fastest route to getting a
   module written. The Apache Libcloud project is located at:

   http://libcloud.apache.org/

   Not every cloud host is supported by libcloud. Additionally, not  every
   feature in a supported cloud host is necessarily supported by libcloud.
   In either of these cases, a module can be created which does  not  rely
   on libcloud.

   All Driver Modules
   The  following functions are required by all driver modules, whether or
   not they are based on libcloud.

   The __virtual__() Function
   This function determines whether or  not  to  make  this  cloud  module
   available upon execution. Most often, it uses get_configured_provider()
   to determine if the necessary configuration has been  set  up.  It  may
   also check for necessary imports, to decide whether to load the module.
   In most cases, it will return a True or False value. If the name of the
   driver  used  does  not  match  the  filename, then that name should be
   returned instead of True. An example of this may be seen in  the  Azure
   module:

   https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/msazure.py

   The get_configured_provider() Function
   This function uses config.is_provider_configured() to determine  wither
   all  required information for this driver has been configured. The last
   value in the list of required settings should be followed by a comma.

   Libcloud Based Modules
   Writing a cloud module based on  libcloud  has  two  major  advantages.
   First  of  all,  much of the work has already been done by the libcloud
   project. Second, most of the functions necessary to Salt  have  already
   been added to the Salt Cloud project.

   The create() Function
   The  most  important  function that does need to be manually written is
   the create() function. This is  what  is  used  to  request  a  virtual
   machine  to  be  created  by  the  cloud  host,  wait  for it to become
   available, and then (optionally) log in and install Salt on it.

   A good example to follow for writing a cloud  driver  module  based  on
   libcloud is the module provided for Linode:

   https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/linode.py

   The basic flow of a create() function is as follows:

   * Send a request to the cloud host to create a virtual machine.

   * Wait for the virtual machine to become available.

   * Generate kwargs to be used to deploy Salt.

   * Log into the virtual machine and deploy Salt.

   * Return a data structure  that  describes  the  newly-created  virtual
     machine.

   At  various points throughout this function, events may be fired on the
   Salt event bus. Four of these events, which are  described  below,  are
   required. Other events may be added by the user, where appropriate.

   When  the  create()  function  is called, it is passed a data structure
   called vm_. This dict contains a composite  of  information  describing
   the  virtual  machine  to  be  created.  A dict called __opts__ is also
   provided by Salt, which contains the options used to run Salt Cloud, as
   well as a set of configuration and environment variables.

   The  first thing the create() function must do is fire an event stating
   that  it  has  started  the  create  process.  This  event  is   tagged
   salt/cloud/<vm  name>/creating.  The  payload contains the names of the
   VM, profile, and provider.

   A set of kwargs is then usually created,  to  describe  the  parameters
   required by the cloud host to request the virtual machine.

   An  event  is then fired to state that a virtual machine is about to be
   requested.   It  is  tagged  as  salt/cloud/<vm  name>/requesting.  The
   payload contains most or all of the parameters that will be sent to the
   cloud host. Any private information (such as passwords) should  not  be
   sent in the event.

   After  a  request  is  made,  a set of deploy kwargs will be generated.
   These will be used to install  Salt  on  the  target  machine.  Windows
   options  are  supported at this point, and should be generated, even if
   the cloud host does not currently support Windows. This will save  time
   in the future if the host does eventually decide to support Windows.

   An  event  is  then  fired to state that the deploy process is about to
   begin. This event is tagged salt/cloud/<vm name>/deploying. The payload
   for the event will contain a set of deploy kwargs, useful for debugging
   purposed. Any private data, including  passwords  and  keys  (including
   public keys) should be stripped from the deploy kwargs before the event
   is fired.

   If    any    Windows    options    have    been    passed    in,    the
   salt.utils.cloud.deploy_windows()  function  will be called. Otherwise,
   it will be assumed that the target is a Linux or Unix machine, and  the
   salt.utils.cloud.deploy_script() will be called.

   Both  of  these  functions  will  wait for the target machine to become
   available, then the necessary port to log in, then a  successful  login
   that  can  be  used to install Salt. Minion configuration and keys will
   then be uploaded  to  a  temporary  directory  on  the  target  by  the
   appropriate function. On a Windows target, the Windows Minion Installer
   will be run in silent mode. On a Linux/Unix  target,  a  deploy  script
   (bootstrap-salt.sh, by default) will be run, which will auto-detect the
   operating system, and install Salt using its  native  package  manager.
   These do not need to be handled by the developer in the cloud module.

   The salt.utils.cloud.validate_windows_cred() function has been extended
   to take the number of retries and  retry_delay  parameters  in  case  a
   specific   cloud  host  has  a  delay  between  providing  the  Windows
   credentials and the credentials being  available  for  use.   In  their
   create()  function,  or  as a a sub-function called during the creation
   process,  developers  should  use   the   win_deploy_auth_retries   and
   win_deploy_auth_retry_delay  parameters from the provider configuration
   to allow the end-user the ability to customize the number of tries  and
   delay between tries for their particular host.

   After the appropriate deploy function completes, a final event is fired
   which describes the virtual machine that has just  been  created.  This
   event  is tagged salt/cloud/<vm name>/created. The payload contains the
   names of the VM, profile, and provider.

   Finally, a dict (queried from the provider)  which  describes  the  new
   virtual machine is returned to the user. Because this data is not fired
   on the event bus it can, and should, return  any  passwords  that  were
   returned  by  the  cloud  host. In some cases (for example, Rackspace),
   this is the only time that the password can be  queried  by  the  user;
   post-creation  queries  may not contain password information (depending
   upon the host).

   The libcloudfuncs Functions
   A number of other functions are required for all cloud hosts.  However,
   with  libcloud-based  modules,  these  are all provided for free by the
   libcloudfuncs library. The following two lines set up the imports:

      from salt.cloud.libcloudfuncs import *   # pylint: disable=W0614,W0401
      from salt.utils import namespaced_function

   And then a series of declarations will  make  the  necessary  functions
   available within the cloud module.

      get_size = namespaced_function(get_size, globals())
      get_image = namespaced_function(get_image, globals())
      avail_locations = namespaced_function(avail_locations, globals())
      avail_images = namespaced_function(avail_images, globals())
      avail_sizes = namespaced_function(avail_sizes, globals())
      script = namespaced_function(script, globals())
      destroy = namespaced_function(destroy, globals())
      list_nodes = namespaced_function(list_nodes, globals())
      list_nodes_full = namespaced_function(list_nodes_full, globals())
      list_nodes_select = namespaced_function(list_nodes_select, globals())
      show_instance = namespaced_function(show_instance, globals())

   If   necessary,  these  functions  may  be  replaced  by  removing  the
   appropriate declaration line, and then adding the function as normal.

   These functions are required for all cloud modules, and  are  described
   in detail in the next section.

   Non-Libcloud Based Modules
   In  some  cases,  using  libcloud is not an option. This may be because
   libcloud has not yet included the necessary driver itself, or it may be
   that  the driver that is included with libcloud does not contain all of
   the necessary features required by the  developer.  When  this  is  the
   case, some or all of the functions in libcloudfuncs may be replaced. If
   they are all replaced, the libcloud imports should be absent  from  the
   Salt Cloud module.

   A good example of a non-libcloud driver is the DigitalOcean driver:

   https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/digital_ocean.py

   The create() Function
   The  create()  function  must  be   created   as   described   in   the
   libcloud-based module documentation.

   The get_size() Function
   This  function  is  only necessary for libcloud-based modules, and does
   not need to exist otherwise.

   The get_image() Function
   This function is only necessary for libcloud-based  modules,  and  does
   not need to exist otherwise.

   The avail_locations() Function
   This  function returns a list of locations available, if the cloud host
   uses multiple data centers. It is not necessary if the cloud host  uses
   only  one data center. It is normally called using the --list-locations
   option.

      salt-cloud --list-locations my-cloud-provider

   The avail_images() Function
   This function returns  a  list  of  images  available  for  this  cloud
   provider. There are not currently any known cloud providers that do not
   provide this functionality, though  they  may  refer  to  images  by  a
   different  name (for example, "templates"). It is normally called using
   the --list-images option.

      salt-cloud --list-images my-cloud-provider

   The avail_sizes() Function
   This function  returns  a  list  of  sizes  available  for  this  cloud
   provider.   Generally, this refers to a combination of RAM, CPU, and/or
   disk space. This  functionality  may  not  be  present  on  some  cloud
   providers.  For example, the Parallels module breaks down RAM, CPU, and
   disk space into separate options, whereas  in  other  providers,  these
   options  are  baked  into  the  image.  It is normally called using the
   --list-sizes option.

      salt-cloud --list-sizes my-cloud-provider

   The script() Function
   This function builds the  deploy  script  to  be  used  on  the  remote
   machine.  It is likely to be moved into the salt.utils.cloud library in
   the near future, as it is  very  generic  and  can  usually  be  copied
   wholesale  from  another  module.  An excellent example is in the Azure
   driver.

   The destroy() Function
   This function irreversibly destroys a  virtual  machine  on  the  cloud
   provider.   Before  doing so, it should fire an event on the Salt event
   bus. The tag for this event is  salt/cloud/<vm  name>/destroying.  Once
   the virtual machine has been destroyed, another event is fired. The tag
   for that event is salt/cloud/<vm name>/destroyed.

   This function is normally called with the -d options:

      salt-cloud -d myinstance

   The list_nodes() Function
   This function returns a list of nodes available on this cloud provider,
   using the following fields:

   * id (str)

   * image (str)

   * size (str)

   * state (str)

   * private_ips (list)

   * public_ips (list)

   No  other  fields should be returned in this function, and all of these
   fields  should  be  returned,  even  if  empty.  The  private_ips   and
   public_ips  fields  should always be of a list type, even if empty, and
   the other fields should always be of  a  str  type.  This  function  is
   normally called with the -Q option:

      salt-cloud -Q

   The list_nodes_full() Function
   All  information  available  about all nodes should be returned in this
   function.  The fields in  the  list_nodes()  function  should  also  be
   returned,  even  if  they  would  not normally be provided by the cloud
   provider. This is because some functions both within Salt and 3rd party
   will  break  if  an  expected  field  is  not present. This function is
   normally called with the -F option:

      salt-cloud -F

   The list_nodes_select() Function
   This function returns only the fields specified in the  query.selection
   option  in /etc/salt/cloud. Because this function is so generic, all of
   the heavy lifting has been moved into the salt.utils.cloud library.

   A function to call list_nodes_select() still needs to  be  present.  In
   general, the following code can be used as-is:

      def list_nodes_select(call=None):
          '''
          Return a list of the VMs that are on the provider, with select fields
          '''
          return salt.utils.cloud.list_nodes_select(
              list_nodes_full('function'), __opts__['query.selection'], call,
          )

   However,  depending  on the cloud provider, additional variables may be
   required.  For instance, some modules use a conn object, or may need to
   pass  other  options  into  list_nodes_full(). In this case, be sure to
   update the function appropriately:

      def list_nodes_select(conn=None, call=None):
          '''
          Return a list of the VMs that are on the provider, with select fields
          '''
          if not conn:
              conn = get_conn()   # pylint: disable=E0602

          return salt.utils.cloud.list_nodes_select(
              list_nodes_full(conn, 'function'),
              __opts__['query.selection'],
              call,
          )

   This function is normally called with the -S option:

      salt-cloud -S

   The show_instance() Function
   This function is used to display all of the information about a  single
   node  that  is  available  from the cloud provider. The simplest way to
   provide this is usually to call list_nodes_full(), and return just  the
   data for the requested node. It is normally called as an action:

      salt-cloud -a show_instance myinstance

   Actions and Functions
   Extra  functionality may be added to a cloud provider in the form of an
   --action or  a  --function.  Actions  are  performed  against  a  cloud
   instance/virtual  machine,  and functions are performed against a cloud
   provider.

   Actions
   Actions are calls that are performed against  a  specific  instance  or
   virtual  machine.  The  show_instance action should be available in all
   cloud modules.  Actions are normally called with the -a option:

      salt-cloud -a show_instance myinstance

   Actions must accept a name as a first argument, may optionally  support
   any  number  of  kwargs  as appropriate, and must accept an argument of
   call, with a default of None.

   Before performing any other work, an action should normally verify that
   it  has been called correctly. It may then perform the desired feature,
   and return useful information to the user. A basic action looks like:

      def show_instance(name, call=None):
      '''
      Show the details from EC2 concerning an AMI
      '''
      if call != 'action':
          raise SaltCloudSystemExit(
              'The show_instance action must be called with -a or --action.'
          )

      return _get_node(name)

   Please note that generic kwargs, if used, are passed through to actions
   as kwargs and not **kwargs. An example of this is seen in the Functions
   section.

   Functions
   Functions are called  that  are  performed  against  a  specific  cloud
   provider.  An  optional  function  that  is often useful is show_image,
   which describes an image in detail. Functions are normally called  with
   the -f option:

      salt-cloud -f show_image my-cloud-provider image='Ubuntu 13.10 64-bit'

   A  function  may  accept  any number of kwargs as appropriate, and must
   accept an argument of call with a default of None.

   Before performing any other work, a  function  should  normally  verify
   that  it  has  been  called  correctly. It may then perform the desired
   feature, and return useful information to the user.  A  basic  function
   looks like:

      def show_image(kwargs, call=None):
          '''
          Show the details from EC2 concerning an AMI
          '''
          if call != 'function':
              raise SaltCloudSystemExit(
                  'The show_image action must be called with -f or --function.'
              )

          params = {'ImageId.1': kwargs['image'],
                    'Action': 'DescribeImages'}
          result = query(params)
          log.info(result)

          return result

   Take note that generic kwargs are passed through to functions as kwargs
   and not **kwargs.

   Cloud deployment scripts
   Salt Cloud works  primarily  by  executing  a  script  on  the  virtual
   machines  as soon as they become available. The script that is executed
   is referenced in the cloud profile as the script.  In  older  versions,
   this was the os argument. This was changed in 0.8.2.

   A  number  of  legacy  scripts  exist  in  the  deploy directory in the
   saltcloud source tree. The preferred method is  currently  to  use  the
   salt-bootstrap  script.  A stable version is included with each release
   tarball starting with 0.8.4. The most updated version can be found at:

   https://github.com/saltstack/salt-bootstrap

   Note that, somewhat counter-intuitively, this script is  referenced  as
   bootstrap-salt in the configuration.

   You  can  specify  a  deploy  script  in  the  cloud configuration file
   (/etc/salt/cloud by default):

      script: bootstrap-salt

   Or in a provider:

      my-provider:
        # snip...
        script: bootstrap-salt

   Or in a profile:

      my-profile:
        provider: my-provider
        # snip...
        script: bootstrap-salt

   If you do not specify a script argument  in  your  cloud  configuration
   file,    provider   configuration   or   profile   configuration,   the
   "bootstrap-salt" script will be used by default.

   Other Generic Deploy Scripts
   If you want to be assured of always using  the  latest  Salt  Bootstrap
   script,  there  are  a  few  generic  templates available in the deploy
   directory of your saltcloud source tree:

      curl-bootstrap
      curl-bootstrap-git
      python-bootstrap
      wget-bootstrap
      wget-bootstrap-git

   These are  example  scripts  which  were  designed  to  be  customized,
   adapted,  and refit to meet your needs. One important use of them is to
   pass options to the salt-bootstrap script, such as updating to specific
   git tags.

   Custom Deploy Scripts
   If  the  Salt  Bootstrap script does not meet your needs, you may write
   your own.  The script should  be  written  in  shell  and  is  a  Jinja
   template.  Deploy scripts need to execute a number of functions to do a
   complete salt setup. These functions include:

   1. Install the salt minion. If this can be  done  via  system  packages
      this method is HIGHLY preferred.

   2. Add  the salt minion keys before the minion is started for the first
      time.  The minion keys are available as strings that can  be  copied
      into place in the Jinja template under the dict named "vm".

   3. Start the salt-minion daemon and enable it at startup time.

   4. Set  up  the  minion  configuration  file  from  the  "minion"  data
      available in the Jinja template.

   A good, well commented example of this process is the Fedora deployment
   script:

   https://github.com/saltstack/salt-cloud/blob/master/saltcloud/deploy/Fedora.sh

   A number of  legacy  deploy  scripts  are  included  with  the  release
   tarball.  None of them are as functional or complete as Salt Bootstrap,
   and are still included for academic purposes.

   Custom deploy scripts are picked up  from  /etc/salt/cloud.deploy.d  by
   default,  but  you  can  change the location of deploy scripts with the
   cloud configuration deploy_scripts_search_path. Additionally,  if  your
   deploy script has the extension .sh, you can leave out the extension in
   your configuration.

   For  example,  if   your   custom   deploy   script   is   located   in
   /etc/salt/cloud.deploy.d/my_deploy.sh,  you could specify it in a cloud
   profile like this:

      my-profile:
        provider: my-provider
        # snip...
        script: my_deploy

   You're also free to use the full path to the script if you like.  Using
   full    paths,    your    script    doesn't   have   to   live   inside
   /etc/salt/cloud.deploy.d   or   whatever   you've    configured    with
   deploy_scripts_search_path.

   Post-Deploy Commands
   Once  a  minion  has  been  deployed,  it  has the option to run a salt
   command.  Normally, this would be the state.apply, which  would  finish
   provisioning  the  VM.  Another  common  option (for testing) is to use
   test.ping. This is configured in the main cloud config file:

      start_action: state.apply

   This is currently considered to be experimental functionality, and  may
   not  work  well  with  all cloud hosts. If you experience problems with
   Salt Cloud hanging after  Salt  is  deployed,  consider  using  Startup
   States instead:

   http://docs.saltstack.com/ref/states/startup.html

   Skipping the Deploy Script
   For whatever reason, you may want to skip the deploy script altogether.
   This results in a VM being spun up  much  faster,  with  absolutely  no
   configuration.  This can be set from the command line:

      salt-cloud --no-deploy -p micro_aws my_instance

   Or it can be set from the main cloud config file:

      deploy: False

   Or it can be set from the provider's configuration:

      RACKSPACE.user: example_user
      RACKSPACE.apikey: 123984bjjas87034
      RACKSPACE.deploy: False

   Or even on the VM's profile settings:

      ubuntu_aws:
        provider: my-ec2-config
        image: ami-7e2da54e
        size: t1.micro
        deploy: False

   The default for deploy is True.

   In the profile, you may also set the script option to None:

      script: None

   This  is  the  slowest  option,  since it still uploads the None deploy
   script and executes it.

   Updating Salt Bootstrap
   Salt Bootstrap can be updated automatically with salt-cloud:

      salt-cloud -u
      salt-cloud --update-bootstrap

   Bear in mind that this updates to the latest stable version from:

   https://bootstrap.saltstack.com/stable/bootstrap-salt.sh

   To update Salt  Bootstrap  script  to  the  develop  version,  run  the
   following command on the Salt minion host with salt-cloud installed:

      salt-call config.gather_bootstrap_script 'https://bootstrap.saltstack.com/develop/bootstrap-salt.sh'

   Or just download the file manually:

      curl -L 'https://bootstrap.saltstack.com/develop' > /etc/salt/cloud.deploy.d/bootstrap-salt.sh

   Keeping /tmp/ Files
   When  Salt  Cloud  deploys  an  instance, it uploads temporary files to
   /tmp/ for salt-bootstrap to put in place. After  the  script  has  run,
   they  are  deleted.  To  keep  these files around (mostly for debugging
   purposes), the --keep-tmp option can be added:

      salt-cloud -p myprofile mymachine --keep-tmp

   For those wondering why /tmp/ was used instead of /root/, this  had  to
   be  done for images which require the use of sudo, and therefore do not
   allow remote root logins, even for file transfers (which  makes  /root/
   unavailable).

   Deploy Script Arguments
   Custom  deploy  scripts  are  unlikely  to  need custom arguments to be
   passed to them, but salt-bootstrap has been extended quite a  bit,  and
   this  may  be  necessary.  script_args  can  be specified in either the
   profile or the map file, to pass arguments to the deploy script:

      aws-amazon:
        provider: my-ec2-config
        image: ami-1624987f
        size: t1.micro
        ssh_username: ec2-user
        script: bootstrap-salt
        script_args: -c /tmp/

   This has also been tested to work with pipes, if needed:

      script_args: | head

   Using Salt Cloud from Salt
   Using the Salt Modules for Cloud
   In addition to the salt-cloud command, Salt Cloud can  be  called  from
   Salt,  in a variety of different ways. Most users will be interested in
   either the execution module  or  the  state  module,  but  it  is  also
   possible to call Salt Cloud as a runner.

   Because  the  actual  work  will  be  performed on a remote minion, the
   normal Salt Cloud configuration must exist on any  target  minion  that
   needs to execute a Salt Cloud command.  Because Salt Cloud now supports
   breaking out configuration into individual files, the configuration  is
   easily  managed  using  Salt's  own  file.managed  state  function. For
   example, the following  directories  allow  this  configuration  to  be
   managed easily:

      /etc/salt/cloud.providers.d/
      /etc/salt/cloud.profiles.d/

   Minion Keys
   Keep  in mind that when creating minions, Salt Cloud will create public
   and private minion keys, upload them  to  the  minion,  and  place  the
   public  key on the machine that created the minion. It will not attempt
   to place any public minion keys on the master, unless the minion  which
   was  used  to  create  the  instance  is  also the Salt Master. This is
   because granting arbitrary minions access to modify keys on the  master
   is a serious security risk, and must be avoided.

   Execution Module
   The  cloud  module  is  available  to use from the command line. At the
   moment, almost every standard Salt Cloud feature is available  to  use.
   The following commands are available:

   list_images
   This  command  is designed to show images that are available to be used
   to create an instance using Salt Cloud. In general they are used in the
   creation  of  profiles,  but  may  also  be  used to create an instance
   directly (see  below).   Listing  images  requires  a  provider  to  be
   configured, and specified:

      salt myminion cloud.list_images my-cloud-provider

   list_sizes
   This command is designed to show sizes that are available to be used to
   create an instance using Salt Cloud. In general they are  used  in  the
   creation  of  profiles,  but  may  also  be  used to create an instance
   directly (see below). This command  is  not  available  for  all  cloud
   providers; see the provider-specific documentation for details. Listing
   sizes requires a provider to be configured, and specified:

      salt myminion cloud.list_sizes my-cloud-provider

   list_locations
   This command is designed to show locations that  are  available  to  be
   used  to  create an instance using Salt Cloud. In general they are used
   in the creation of profiles, but may also be used to create an instance
   directly  (see  below).  This  command  is  not available for all cloud
   providers; see the provider-specific documentation for details. Listing
   locations requires a provider to be configured, and specified:

      salt myminion cloud.list_locations my-cloud-provider

   query
   This  command  is  used  to  query  all configured cloud providers, and
   display all instances associated with those accounts.  By  default,  it
   will run a standard query, returning the following fields:

   id     The name or ID of the instance, as used by the cloud provider.

   image  The disk image that was used to create this instance.

   private_ips
          Any public IP addresses currently assigned to this instance.

   public_ips
          Any private IP addresses currently assigned to this instance.

   size   The  size of the instance; can refer to RAM, CPU(s), disk space,
          etc., depending on the cloud provider.

   state  The  running  state  of  the  instance;  for  example,  running,
          stopped,   pending,  etc.  This  state  is  dependent  upon  the
          provider.

   This command may also be used to perform  a  full  query  or  a  select
   query, as described below. The following usages are available:

      salt myminion cloud.query
      salt myminion cloud.query list_nodes
      salt myminion cloud.query list_nodes_full

   full_query
   This  command behaves like the query command, but lists all information
   concerning each instance as provided by the cloud provider, in addition
   to the fields returned by the query command.

      salt myminion cloud.full_query

   select_query
   This  command  behaves like the query command, but only returned select
   fields as defined in the /etc/salt/cloud configuration file.  A  sample
   configuration for this section of the file might look like:

      query.selection:
        - id
        - key_name

   This  configuration  would  only return the id and key_name fields, for
   those cloud providers that support those  two  fields.  This  would  be
   called using the following command:

      salt myminion cloud.select_query

   profile
   This  command  is  used  to  create an instance using a profile that is
   configured on the target minion. Please note that the profile  must  be
   configured before this command can be used with it.

      salt myminion cloud.profile ec2-centos64-x64 my-new-instance

   Please  note  that  the execution module does not run in parallel mode.
   Using multiple minions to  create  instances  can  effectively  perform
   parallel instance creation.

   create
   This  command  is similar to the profile command, in that it is used to
   create a new instance. However, it does not require  a  profile  to  be
   pre-configured.    Instead,  all  of  the  options  that  are  normally
   configured in a profile are passed directly to Salt Cloud to create the
   instance:

      salt myminion cloud.create my-ec2-config my-new-instance \
          image=ami-1624987f size='t1.micro' ssh_username=ec2-user \
          securitygroup=default delvol_on_destroy=True

   Please  note  that  the execution module does not run in parallel mode.
   Using multiple minions to  create  instances  can  effectively  perform
   parallel instance creation.

   destroy
   This  command is used to destroy an instance or instances. This command
   will search all configured providers and remove any  instance(s)  which
   matches  the  name(s)  passed  in here. The results of this command are
   non-reversable and should be used with caution.

      salt myminion cloud.destroy myinstance
      salt myminion cloud.destroy myinstance1,myinstance2

   action
   This command implements both the action and the function commands  used
   in  the  standard  salt-cloud  command.  If  one of the standard action
   commands is used, an instance name must be  provided.  If  one  of  the
   standard  function  commands  is used, a provider configuration must be
   named.

      salt myminion cloud.action start instance=myinstance
      salt myminion cloud.action show_image provider=my-ec2-config \
          image=ami-1624987f

   The actions available are largely dependent upon  the  module  for  the
   specific  cloud  provider.  The following actions are available for all
   cloud providers:

   list_nodes
          This is a direct call to the query function as described  above,
          but  is  only  performed  against  a  single  cloud  provider. A
          provider configuration must be included.

   list_nodes_select
          This is a direct call to the full_query  function  as  described
          above,  but is only performed against a single cloud provider. A
          provider configuration must be included.

   list_nodes_select
          This is a direct call to the select_query function as  described
          above, but is only performed against a single cloud provider.  A
          provider configuration must be included.

   show_instance
          This is a thin wrapper around list_nodes, which returns the full
          information  about  a  single instance. An instance name must be
          provided.

   State Module
   A subset of the execution module is available through the  cloud  state
   module.  Not  all  functions  are  currently included, because there is
   currently  insufficient  code  for  them  to  perform  statefully.  For
   example, a command to create an instance may be issued with a series of
   options, but those options  cannot  currently  be  statefully  managed.
   Additional  states  to manage these options will be released at a later
   time.

   cloud.present
   This state will ensure that an instance is present inside a  particular
   cloud   provider.   Any  option  that  is  normally  specified  in  the
   cloud.create execution module and function may be  declared  here,  but
   only the actual presence of the instance will be managed statefully.

      my-instance-name:
        cloud.present:
          - provider: my-ec2-config
          - image: ami-1624987f
          - size: 't1.micro'
          - ssh_username: ec2-user
          - securitygroup: default
          - delvol_on_destroy: True

   cloud.profile
   This  state will ensure that an instance is present inside a particular
   cloud provider. This function calls the cloud.profile execution  module
   and  function,  but  as with cloud.present, only the actual presence of
   the instance will be managed statefully.

      my-instance-name:
        cloud.profile:
          - profile: ec2-centos64-x64

   cloud.absent
   This state will ensure that an instance (identified by name)  does  not
   exist  in  any  of the cloud providers configured on the target minion.
   Please note that this state is non-reversable  and  may  be  considered
   especially destructive when issued as a cloud state.

      my-instance-name:
        cloud.absent

   Runner Module
   The cloud runner module is executed on the master, and performs actions
   using the configuration and Salt modules on  the  master  itself.  This
   means that any public minion keys will also be properly accepted by the
   master.

   Using the functions in the runner module is  no  different  than  using
   those in the execution module, outside of the behavior described in the
   above paragraph.  The following  functions  are  available  inside  the
   runner:

   * list_images

   * list_sizes

   * list_locations

   * query

   * full_query

   * select_query

   * profile

   * destroy

   * action

   Outside of the standard usage of salt-run itself, commands are executed
   as usual:

      salt-run cloud.profile ec2-centos64-x86_64 my-instance-name

   CloudClient
   The execution,  state,  and  runner  modules  ultimately  all  use  the
   CloudClient  library  that  ships  with  Salt.  To  use the CloudClient
   library locally (either on the master or a  minion),  create  a  client
   object and issue a command against it:

      import salt.cloud
      import pprint
      client = salt.cloud.CloudClient('/etc/salt/cloud')
      nodes = client.query()
      pprint.pprint(nodes)

   Reactor
   Examples  of  using  the  reactor  with Salt Cloud are available in the
   ec2-autoscale-reactor and salt-cloud-reactor formulas.

   Feature Comparison
   Feature Matrix
   A number of features are available in most cloud hosts, but not all are
   available  everywhere.  This may be because the feature isn't supported
   by the cloud host itself, or it may only be that the  feature  has  not
   yet  been added to Salt Cloud. In a handful of cases, it is because the
   feature does not make sense for a particular cloud  provider  (Saltify,
   for instance).

   This matrix shows which features are available in which cloud hosts, as
   far as Salt Cloud is concerned. This is not a comprehensive list of all
   features  available  in all cloud hosts, and should not be used to make
   business decisions concerning choosing a cloud  host.  In  most  cases,
   adding  support  for  a  feature  to  Salt Cloud requires only a little
   effort.

   Legacy Drivers
   Both AWS and Rackspace are listed as "Legacy". This  is  because  those
   drivers  have  been  replaced by other drivers, which are generally the
   preferred method for working with those hosts.

   The EC2 driver should be used instead of the AWS driver, when possible.
   The  OpenStack  driver  should be used instead of the Rackspace driver,
   unless the user is  dealing  with  instances  in  "the  old  cloud"  in
   Rackspace.

   Note for Developers
   When  adding  new features to a particular cloud host, please make sure
   to add the feature to this table. Additionally, if you notice a feature
   that  is  not  properly  listed  here,  pull  requests  to  fix them is
   appreciated.

   Standard Features
   These are features that are available for almost every cloud host.












   Actions
   These  are  features  that  are  performed  on a specific instance, and
   require an instance name to be passed in. For example:

      # salt-cloud -a attach_volume ami.example.com






















   Functions
   These  are  features  that  are  performed  against  a  specific  cloud
   provider,  and  require  the  name of the provider to be passed in. For
   example:

      # salt-cloud -f list_images my_digitalocean









































   Tutorials
   Salt Cloud Quickstart
   Salt  Cloud  is built-in to Salt, and the easiest way to run Salt Cloud
   is directly from your Salt Master.

   Note that if you installed Salt via Salt Bootstrap,  it  may  not  have
   automatically  installed  salt-cloud  for  you. Use your distribution's
   package manager to install the salt-cloud package from  the  same  repo
   that you used to install Salt.  These repos will automatically be setup
   by Salt Bootstrap.

   If there is no salt-cloud package, install with pip install salt-cloud.

   This quickstart walks you through the basic steps of setting up a cloud
   host and defining some virtual machines to create.

   NOTE:
      Salt Cloud has its own process and does not rely on the Salt Master,
      so it can be installed on a standalone minion instead of  your  Salt
      Master.

   Define a Provider
   The  first  step  is  to  add  the  credentials  for  your  cloud host.
   Credentials and other settings provided by the cloud host are stored in
   provider  configuration  files.  Provider  configurations  contain  the
   details needed to connect to a cloud host such as EC2, GCE,  Rackspace,
   etc.,  and  any  global options that you want set on your cloud minions
   (such as the location of your Salt Master).

   On your Salt Master, browse to /etc/salt/cloud.providers.d/ and  create
   a   file   called   <provider>.conf,  replacing  <provider>  with  ec2,
   softlayer, and so on. The name helps you identify the contents, and  is
   not important as long as the file ends in .conf.

   Next,  browse  to  the Provider specifics and add any required settings
   for your cloud host to this file. Here is an example for Amazon EC2:

      my-ec2:
        driver: ec2
        # Set the EC2 access credentials (see below)
        #
        id: 'HJGRYCILJLKJYG'
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        # Make sure this key is owned by root with permissions 0400.
        #
        private_key: /etc/salt/my_test_key.pem
        keyname: my_test_key
        securitygroup: default
        # Optional: Set up the location of the Salt Master
        #
        minion:
          master: saltmaster.example.com

   The required configuration varies between cloud hosts so make sure  you
   read the provider specifics.

   List Cloud Provider Options
   You  can  now  query  the  cloud  provider you configured for available
   locations, images, and sizes. This information is used when you set  up
   VM profiles.

      salt-cloud --list-locations <provider_name>  # my-ec2 in the previous example
      salt-cloud --list-images <provider_name>
      salt-cloud --list-sizes <provider_name>

   Replace <provider_name> with the name of the provider configuration you
   defined.

   Create VM Profiles
   On your Salt Master, browse to /etc/salt/cloud.profiles.d/ and create a
   file  called  <profile>.conf,  replacing <profile> with ec2, softlayer,
   and so on. The file must end in .conf.

   You can now add any custom profiles you'd like to define to this  file.
   Here are a few examples:

      micro_ec2:
        provider: my-ec2
        image: ami-d514f291
        size: t1.micro

      medium_ec2:
        provider: my-ec2
        image: ami-d514f291
        size: m3.medium

      large_ec2:
        provider: my-ec2
        image: ami-d514f291
        size: m3.large

   Notice  that the provider in our profile matches the provider name that
   we defined? That is how Salt Cloud knows how to connect to to  a  cloud
   host to create a VM with these attributes.

   Create VMs
   VMs are created by calling salt-cloud with the following options:

      salt-cloud -p <profile> <name1> <name2> ...

   For example:

      salt-cloud -p micro_ec2 minion1 minion2

   Destroy VMs
   Add a -d and the minion name you provided to destroy:

      salt-cloud -d minion1 minion2

   Query VMs
   You can view details about the VMs you've created using --query:

      salt-cloud --query

   Cloud Map
   Now  that  you  know  how to create and destoy individual VMs, next you
   should learn how to use a cloud map to create a number of VMs at once.

   Cloud maps let you define a map  of  your  infrastructure  and  quickly
   provision  any  number  of VMs. On subsequent runs, any VMs that do not
   exist are created,  and  VMs  that  are  already  configured  are  left
   unmodified.

   See Cloud Map File.

   Using Salt Cloud with the Event Reactor
   One  of  the  most powerful features of the Salt framework is the Event
   Reactor.  As the Reactor was in development, Salt Cloud  was  regularly
   updated  to  take  advantage  of  the Reactor upon completion. As such,
   various aspects of both the creation and destruction of instances  with
   Salt  Cloud  fire  events  to the Salt Master, which can be used by the
   Event Reactor.

   Event Structure
   As of this writing, all events in Salt Cloud have a tag, which includes
   the ID of the instance being managed, and a payload which describes the
   task that is currently being handled. A Salt Cloud tag looks like:

      salt/cloud/<minion_id>/<task>

   For instance, the first event fired when  creating  an  instance  named
   web1 would look like:

      salt/cloud/web1/creating

   Assuming  this  instance  is  using the ec2-centos profile, which is in
   turn using the ec2-config provider, the payload for this tag would look
   like:

      {'name': 'web1',
       'profile': 'ec2-centos',
       'provider': 'ec2-config:ec2'}

   Available Events
   When  an instance is created in Salt Cloud, whether by map, profile, or
   directly through an API, a minimum of five events are  normally  fired.
   More  may  be  available, depending upon the cloud provider being used.
   Some of the common events are described below.

   salt/cloud/<minion_id>/creating
   This event states simply that the process to  create  an  instance  has
   begun. At this point in time, no actual work has begun. The payload for
   this event includes:

   name profile provider

   salt/cloud/<minion_id>/requesting
   Salt Cloud is about to make a request to the cloud provider  to  create
   an  instance.  At this point, all of the variables required to make the
   request have been gathered, and the payload of the event  will  reflect
   those  variables  which  do  not normally pose a security risk. What is
   returned here  is  dependent  upon  the  cloud  provider.  Some  common
   variables are:

   name image size location

   salt/cloud/<minion_id>/querying
   The  instance  has  been  successfully  requested,  but  the  necessary
   information to log into the instance (such as IP address)  is  not  yet
   available.  This  event  marks the beginning of the process to wait for
   this information.

   The payload for this event normally only includes the instance_id.

   salt/cloud/<minion_id>/waiting_for_ssh
   The information required to log into the instance has  been  retrieved,
   but  the  instance  is  not necessarily ready to be accessed. Following
   this event, Salt Cloud will wait for the IP address  to  respond  to  a
   ping,  then  wait  for  the specified port (usually 22) to respond to a
   connection, and on Linux systems, for SSH  to  become  available.  Salt
   Cloud will attempt to issue the date command on the remote system, as a
   means to check for availability. If no ssh_username has been specified,
   a  list  of usernames (starting with root) will be attempted. If one or
   more usernames was configured for ssh_username, they will be  added  to
   the beginning of the list, in order.

   The payload for this event normally only includes the ip_address.

   salt/cloud/<minion_id>/deploying
   The  necessary  port has been detected as available, and now Salt Cloud
   can log into the instance, upload any files used  for  deployment,  and
   run  the  deploy script. Once the script has completed, Salt Cloud will
   log back into the instance and remove any remaining files.

   A number of variables are used to deploy instances, and the majority of
   these  will  be  available in the payload. Any keys, passwords or other
   sensitive data will be scraped from the payload. Most of the  variables
   returned  will  be  related  to the profile or provider config, and any
   default values that could have been changed in the profile or provider,
   but weren't.

   salt/cloud/<minion_id>/created
   The  deploy  sequence has completed, and the instance is now available,
   Salted, and ready for use. This event is the final task for Salt Cloud,
   before returning instance information to the user and exiting.

   The  payload  for  this  event  contains  little  more than the initial
   creating event. This event is required in all cloud providers.

   Configuring the Event Reactor
   The Event Reactor is built into the Salt Master process, and as such is
   configured  via  the master configuration file. Normally this will be a
   YAML   file   located   at   /etc/salt/master.   Additionally,   master
   configuration   items  can  be  stored,  in  YAML  format,  inside  the
   /etc/salt/master.d/ directory.

   These configuration items may be stored in  either  location;  however,
   they  may  only  be  stored  in  one  location.  For organizational and
   security purposes, it may be best  to  create  a  single  configuration
   file,   which   contains   only   Event   Reactor   configuration,   at
   /etc/salt/master.d/reactor.

   The Event Reactor uses a top-level configuration item  called  reactor.
   This  block  contains  a  list of tags to be watched for, each of which
   also includes a list of sls files. For instance:

      reactor:
        - 'salt/minion/*/start':
          - '/srv/reactor/custom-reactor.sls'
        - 'salt/cloud/*/created':
          - '/srv/reactor/cloud-alert.sls'
        - 'salt/cloud/*/destroyed':
          - '/srv/reactor/cloud-destroy-alert.sls'

   The above configuration configures reactors for three  different  tags:
   one  which  is fired when a minion process has started and is available
   to receive commands, one which is fired when a cloud instance has  been
   created, and one which is fired when a cloud instance is destroyed.

   Note  that  each  tag  contains a wildcard (*) in it. For each of these
   tags, this will normally refer to a minion_id. This is not required  of
   event tags, but is very common.

   Reactor SLS Files
   Reactor  sls  files should be placed in the /srv/reactor/ directory for
   consistency between environments, but this is not currently enforced by
   Salt.

   Reactor  sls  files follow a similar format to other sls files in Salt.
   By default they are written in YAML and can be templated  using  Jinja,
   but  since  they  are  processed  through  Salt's rendering system, any
   available renderer (JSON, Mako, Cheetah, etc.) can be used.

   As with other sls files, each stanza will start with a declaration  ID,
   followed  by  the  function  to  run,  and  then any arguments for that
   function. For example:

      # /srv/reactor/cloud-alert.sls
      new_instance_alert:
        cmd.pagerduty.create_event:
          - tgt: alertserver
          - kwarg:
              description: "New instance: {{ data['name'] }}"
              details: "New cloud instance created on {{ data['provider'] }}"
              service_key: 1626dead5ecafe46231e968eb1be29c4
              profile: my-pagerduty-account

   When the Event Reactor receives  an  event  notifying  it  that  a  new
   instance  has  been  created,  this  sls  will create a new incident in
   PagerDuty, using the configured PagerDuty account.

   The declaration ID in this example is new_instance_alert. The  function
   called  is cmd.pagerduty.create_event. The cmd portion of this function
   specifies that an execution module and function will be called, in this
   case, the pagerduty.create_event function.

   Because  an  execution  module  is  specified,  a  target (tgt) must be
   specified on which to call the function. In this case, a minion  called
   alertserver has been used. Any arguments passed through to the function
   are declared in the kwarg block.

   Example: Reactor-Based Highstate
   When Salt Cloud creates an instance, by default  it  will  install  the
   Salt  Minion  onto  the  instance,  along  with  any  specified  minion
   configuration, and automatically  accept  that  minion's  keys  on  the
   master.  One  of  the  configuration  options  that can be specified is
   startup_states, which is commonly set to highstate. This will tell  the
   minion  to  immediately  apply a highstate, as soon as it is able to do
   so.

   This can present a problem with some system images on some cloud hosts.
   For instance, Salt Cloud can be configured to log in as either the root
   user, or a user with sudo access. While some hosts commonly use  images
   that  lock  out  remote  root  access  and  require  a  user  with sudo
   privileges to log in (notably EC2, with  their  ec2-user  login),  most
   cloud  hosts  fall  back  to  root  as the default login on all images,
   including  for  operating  systems  (such  as  Ubuntu)  which  normally
   disallow remote root login.

   For  users  of  these  operating  systems,  it is understandable that a
   highstate would include  configuration  to  block  remote  root  logins
   again.  However,  Salt  Cloud  may  not  have  finished cleaning up its
   deployment files by the time the minion process has started, and kicked
   off a highstate run. Users have reported errors from Salt Cloud getting
   locked out while trying to clean up after itself.

   The goal of a startup state may be achieved using  the  Event  Reactor.
   Because  a  minion  fires an event when it is able to receive commands,
   this event can effectively be used inside the reactor  system  instead.
   The following will point the reactor system to the right sls file:

      reactor:
        - 'salt/cloud/*/created':
          - '/srv/reactor/startup_highstate.sls'

   And  the  following  sls  file will start a highstate run on the target
   minion:

      # /srv/reactor/startup_highstate.sls
      reactor_highstate:
        cmd.state.apply:
          - tgt: {{ data['name'] }}

   Because this event will not be fired until Salt Cloud  has  cleaned  up
   after itself, the highstate run will not step on salt-cloud's toes. And
   because  every  file  on  the   minion   is   configurable,   including
   /etc/salt/minion, the startup_states can still be configured for future
   minion restarts, if desired.

SALT PROXY MINION

   Proxy minions are a developing Salt feature  that  enables  controlling
   devices  that,  for whatever reason, cannot run a standard salt-minion.
   Examples include network gear that has an API but  runs  a  proprietary
   OS,  devices  with  limited  CPU or memory, or devices that could run a
   minion, but for security reasons, will not.

   Proxy minions are not an "out of the box" feature.  Because  there  are
   an  infinite  number of controllable devices, you will most likely have
   to write the interface yourself. Fortunately, this is only as difficult
   as  the  actual  interface to the proxied device.  Devices that have an
   existing Python module (PyUSB for example) would be  relatively  simple
   to  interface.   Code  to  control a device that has an HTML REST-based
   interface should be easy.  Code to control your typical housecat  would
   be excellent source material for a PhD thesis.

   Salt   proxy-minions   provide   the   'plumbing'  that  allows  device
   enumeration and discovery, control, status, remote execution, and state
   management.

   See  the  Proxy Minion Walkthrough for an end-to-end demonstration of a
   working REST-based proxy minion.

   See the Proxy Minion SSH Walkthrough for an end-to-end demonstration of
   a working SSH proxy minion.

   See  Proxyminion  States  to  configure  and run salt-proxy on a remote
   minion. Specify all your master side proxy (pillar)  configuration  and
   use this state to remotely configure proxies on one or more minions.

   See  Proxyminion  Beacon to help with easy configuration and management
   of salt-proxy processes.

   New in 2016.11.0
   Proxy minions now support configuration files with names ending in '
   *
   .conf' and placed in /etc/salt/proxy.d.

   Proxy  minions  can   now   be   configured   in   /etc/salt/proxy   or
   /etc/salt/proxy.d  instead of just pillar.  Configuration format is the
   same as it would be in pillar.

   New in 2016.3
   The deprecated config option enumerate_proxy_minions has been removed.

   As mentioned  in  earlier  documentation,  the  add_proxymodule_to_opts
   configuration  variable  defaults to False in this release.  This means
   if   you   have    proxymodules    or    other    code    looking    in
   __opts__['proxymodule']  you  will  need  to  set this variable in your
   /etc/salt/proxy file, or modify your code to use the __proxy__ injected
   variable.

   The  __proxyenabled__  directive  now  only applies to grains and proxy
   modules themselves.  Standard execution modules and state  modules  are
   not prevented from loading for proxy minions.

   Enhancements  in  grains  processing  have  made  the  __proxyenabled__
   directive somewhat redundant in  dynamic  grains  code.   It  is  still
   required,  but  best  practices  for the __virtual__ function in grains
   files have  changed.   It  is  now  recommended  that  the  __virtual__
   functions  check  to  make  sure  they are being loaded for the correct
   proxytype, example below:

      def __virtual__():
          '''
          Only work on proxy
          '''
          try:
              if salt.utils.is_proxy() and \
                 __opts__['proxy']['proxytype'] == 'ssh_sample':
                  return __virtualname__
          except KeyError:
              pass

          return False

   The try/except block above exists because  grains  are  processed  very
   early  in  the proxy minion startup process, sometimes earlier than the
   proxy key in the __opts__ dictionary is populated.

   Grains are loaded so early in startup that no dunder  dictionaries  are
   present, so __proxy__, __salt__, etc. are not available.  Custom grains
   located in /srv/salt/_grains and in the salt install  grains  directory
   can  now take a single argument, proxy, that is identical to __proxy__.
   This enables patterns like

      def get_ip(proxy):
          '''
          Ask the remote device what IP it has
          '''
          return {'ip':proxy['proxymodulename.get_ip']()}

   Then the grain ip will contain  the  result  of  calling  the  get_ip()
   function in the proxymodule called proxymodulename.

   Proxy   modules   now   benefit   from   including  a  function  called
   initialized().  This function should return True if the proxy's  init()
   function  has  been successfully called.  This is needed to make grains
   processing easier.

   Finally, if there is a function called grains in  the  proxymodule,  it
   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 False in
   this release.  It will default to True in the release after next.   The
   next release is 2016.11.0, the following is Nitrogen.

   New in 2015.8.2
   BREAKING  CHANGE:  Adding  the  proxymodule  variable   to  __opts__ is
   deprecated.   The  proxymodule  variable   has   been   moved   a   new
   globally-injected  variable  called __proxy__.  A related configuration
   option called add_proxymodule_to_opts has been added  and  defaults  to
   True.   In the next major release, 2016.3.0, this variable will default
   to False.

   In the meantime, proxies that functioned under 2015.8.0 and  .1  should
   continue  to work under 2015.8.2.  You should rework your proxy code to
   use __proxy__ as soon as possible.

   The rest_sample example proxy minion has been updated to use __proxy__.

   This change was made because proxymodules are a LazyLoader object,  but
   LazyLoaders  cannot  be  serialized.   __opts__ gets serialized, and so
   things  like  saltutil.sync_all   and   state.highstate   would   throw
   exceptions.

   Support has been added to Salt's loader allowing custom proxymodules to
   be placed in salt://_proxy.  Proxy minions that need these modules will
   need  to  be restarted to pick up any changes.  A corresponding utility
   function, saltutil.sync_proxymodules, has  been  added  to  sync  these
   modules to minions.

   In  addition,  a salt.utils helper function called is_proxy() was added
   to make it easier to tell when the running minion is a proxy minion.

   New in 2015.8
   Starting with the 2015.8 release of Salt, proxy processes are no longer
   forked  off  from  a  controlling minion.  Instead, they have their own
   script salt-proxy which  takes  mostly  the  same  arguments  that  the
   standard  Salt minion does with the addition of --proxyid.  This is the
   id that the salt-proxy will use  to  identify  itself  to  the  master.
   Proxy configurations are still best kept in Pillar and their format has
   not changed.

   This change allows for  better  process  control  and  logging.   Proxy
   processes  can now be listed with standard process management utilities
   (ps from the command line).  Also, a full  Salt  minion  is  no  longer
   required  (though it is still strongly recommended) on machines hosting
   proxies.

   Getting Started
   The following diagram may be helpful in understanding the structure  of
   a Salt installation that includes proxy-minions: [image]

   The  key  thing  to  remember  is the left-most section of the diagram.
   Salt's nature is to have a minion connect to a master, then the  master
   may  control the minion.  However, for proxy minions, the target device
   cannot run a minion.

   After the proxy minion is started and initiates its connection  to  the
   'dumb'  device, it connects back to the salt-master and for all intents
   and purposes looks like just another minion to the Salt master.

   To create support for a proxied device one needs to create four things:

   1. The proxy_connection_module (located in salt/proxy).

   2. The grains support code (located in salt/grains).

   3. Salt modules specific to the controlled device.

   4. Salt states specific to the controlled device.

   Configuration parameters
   Proxy minions require no configuration parameters in /etc/salt/master.

   Salt's Pillar system is ideally suited  for  configuring  proxy-minions
   (though  they  can  be configured in /etc/salt/proxy as well).  Proxies
   can either be designated via a pillar file in pillar_roots, or  through
   an  external  pillar.   External  pillars  afford  the  opportunity for
   interfacing with a configuration management system, database, or  other
   knowledgeable  system  that that may already contain all the details of
   proxy targets.  To use static files in pillar_roots, pattern your files
   after the following examples, which are based on the diagram above:

   /srv/pillar/top.sls

      base:
        dumbdevice1:
          - dumbdevice1
        dumbdevice2:
          - dumbdevice2
        dumbdevice3:
          - dumbdevice3
        dumbdevice4:
          - dumbdevice4
        dumbdevice5:
          - dumbdevice5
        dumbdevice6:
          - dumbdevice6
        dumbdevice7:
          - dumbdevice7

   /srv/pillar/dumbdevice1.sls

      proxy:
        proxytype: networkswitch
        host: 172.23.23.5
        username: root
        passwd: letmein

   /srv/pillar/dumbdevice2.sls

      proxy:
        proxytype: networkswitch
        host: 172.23.23.6
        username: root
        passwd: letmein

   /srv/pillar/dumbdevice3.sls

      proxy:
        proxytype: networkswitch
        host: 172.23.23.7
        username: root
        passwd: letmein

   /srv/pillar/dumbdevice4.sls

      proxy:
        proxytype: i2c_lightshow
        i2c_address: 1

   /srv/pillar/dumbdevice5.sls

      proxy:
        proxytype: i2c_lightshow
        i2c_address: 2

   /srv/pillar/dumbdevice6.sls

      proxy:
        proxytype: 433mhz_wireless

   /srv/pillar/dumbdevice7.sls

      proxy:
        proxytype: sms_serial
        deventry: /dev/tty04

   Note  the contents of each minioncontroller key may differ widely based
   on the type of device that the proxy-minion is managing.

   In the above example

   * dumbdevices 1, 2, and 3 are network switches that have  a  management
     interface available at a particular IP address.

   * dumbdevices 4 and 5 are very low-level devices controlled over an i2c
     bus.  In this case the devices are physically  connected  to  machine
     'minioncontroller2',  and  are  addressable  on  the i2c bus at their
     respective i2c addresses.

   * dumbdevice6 is  a  433  MHz  wireless  transmitter,  also  physically
     connected to minioncontroller2

   * dumbdevice7  is an SMS gateway connected to machine minioncontroller3
     via a serial port.

   Because of the way pillar works, each of the salt-proxy processes  that
   fork  off  the  proxy  minions  will  only see the keys specific to the
   proxies it will be handling.

   Proxies  can  be  configured  in  /etc/salt/proxy  or  with  files   in
   /etc/salt/proxy.d as of Salt's 2016.11.0 release.

   Also,  in  general, proxy-minions are lightweight, so the machines that
   run them could conceivably control a large number of devices.   To  run
   more  than  one proxy from a single machine, simply start an additional
   proxy process with --proxyid set to the id to which you want the  proxy
   to  bind.   It  is  possible for the proxy services to be spread across
   many machines if necessary, or intentionally run on machines that  need
   to  control  devices  because  of some physical interface (e.g. i2c and
   serial above).  Another  reason  to  divide  proxy  services  might  be
   security.  In more secure environments only certain machines may have a
   network path to certain devices.

   Proxymodules
   A proxy module encapsulates all the code necessary to interface with  a
   device.   Proxymodules are located inside the salt.proxy module, or can
   be placed in the  _proxy  directory  in  your  file_roots  (default  is
   /srv/salt/_proxy.  At a minimum a proxymodule object must implement the
   following functions:

   __virtual__(): This function performs the same duty that  it  does  for
   other  types  of  Salt  modules.   Logic  goes here to determine if the
   module can be loaded, checking for the presence of  Python  modules  on
   which  the proxy depends.  Returning False will prevent the module from
   loading.

   init(opts): Perform any initialization that the device needs.  This  is
   a  good  place  to  bring  up  a  persistent connection to a device, or
   authenticate to create a persistent authorization token.

   initialized(): Returns True if init() was successfully called.

   shutdown(): Code to cleanly shut  down  or  close  a  connection  to  a
   controlled device goes here.  This function must exist, but can contain
   only the keyword pass if there is no shutdown logic required.

   ping(): While not required, it is highly recommended that this function
   also  be  defined  in the proxymodule. The code for ping should contact
   the controlled device and make sure it is really available.

   grains(): Rather than including grains in /srv/salt/_grains or  in  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 False in 2016.3 but will default to  True  in
   the release code-named Nitrogen.

   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.

   Here  is an example proxymodule used to interface to a very simple REST
   server.  Code for the server is in the salt-contrib GitHub repository

   This proxymodule enables  "service"  enumeration,  starting,  stopping,
   restarting, and status; "package" installation, and a ping.

      # -*- coding: utf-8 -*-
      '''
      This is a simple proxy-minion designed to connect to and communicate with
      the bottle-based web service contained in https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example
      '''
      from __future__ import absolute_import

      # Import python libs
      import logging
      import salt.utils.http

      HAS_REST_EXAMPLE = True

      # This must be present or the Salt loader won't load this module
      __proxyenabled__ = ['rest_sample']

      # Variables are scoped to this module so we can have persistent data
      # across calls to fns in here.
      GRAINS_CACHE = {}
      DETAILS = {}

      # Want logging!
      log = logging.getLogger(__file__)

      # This does nothing, it's here just as an example and to provide a log
      # entry when the module is loaded.
      def __virtual__():
          '''
          Only return if all the modules are available
          '''
          log.debug('rest_sample proxy __virtual__() called...')
          return True

      # Every proxy module needs an 'init', though you can
      # just put DETAILS['initialized'] = True here if nothing
      # else needs to be done.

      def init(opts):
          log.debug('rest_sample proxy init() called...')
          DETAILS['initialized'] = True

          # Save the REST URL
          DETAILS['url'] = opts['proxy']['url']

          # Make sure the REST URL ends with a '/'
          if not DETAILS['url'].endswith('/'):
              DETAILS['url'] += '/'

      def initialized():
          '''
          Since grains are loaded in many different places and some of those
          places occur before the proxy can be initialized, return whether
          our init() function has been called
          '''
          return DETAILS.get('initialized', False)

      def grains():
          '''
          Get the grains from the proxied device
          '''
          if not DETAILS.get('grains_cache', {}):
              r = salt.utils.http.query(DETAILS['url']+'info', decode_type='json', decode=True)
              DETAILS['grains_cache'] = r['dict']
          return DETAILS['grains_cache']

      def grains_refresh():
          '''
          Refresh the grains from the proxied device
          '''
          DETAILS['grains_cache'] = None
          return grains()

      def fns():
          return {'details': 'This key is here because a function in '
                            'grains/rest_sample.py called fns() here in the proxymodule.'}

      def service_start(name):
          '''
          Start a "service" on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'service/start/'+name, decode_type='json', decode=True)
          return r['dict']

      def service_stop(name):
          '''
          Stop a "service" on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'service/stop/'+name, decode_type='json', decode=True)
          return r['dict']

      def service_restart(name):
          '''
          Restart a "service" on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'service/restart/'+name, decode_type='json', decode=True)
          return r['dict']

      def service_list():
          '''
          List "services" on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'service/list', decode_type='json', decode=True)
          return r['dict']

      def service_status(name):
          '''
          Check if a service is running on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'service/status/'+name, decode_type='json', decode=True)
          return r['dict']

      def package_list():
          '''
          List "packages" installed on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'package/list', decode_type='json', decode=True)
          return r['dict']

      def package_install(name, **kwargs):
          '''
          Install a "package" on the REST server
          '''
          cmd = DETAILS['url']+'package/install/'+name
          if kwargs.get('version', False):
              cmd += '/'+kwargs['version']
          else:
              cmd += '/1.0'
          r = salt.utils.http.query(cmd, decode_type='json', decode=True)
          return r['dict']

      def fix_outage():
          r = salt.utils.http.query(DETAILS['url']+'fix_outage')
          return r

      def uptodate(name):

          '''
          Call the REST endpoint to see if the packages on the "server" are up to date.
          '''
          r = salt.utils.http.query(DETAILS['url']+'package/remove/'+name, decode_type='json', decode=True)
          return r['dict']

      def package_remove(name):

          '''
          Remove a "package" on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'package/remove/'+name, decode_type='json', decode=True)
          return r['dict']

      def package_status(name):
          '''
          Check the installation status of a package on the REST server
          '''
          r = salt.utils.http.query(DETAILS['url']+'package/status/'+name, decode_type='json', decode=True)
          return r['dict']

      def ping():
          '''
          Is the REST server up?
          '''
          r = salt.utils.http.query(DETAILS['url']+'ping', decode_type='json', decode=True)
          try:
              return r['dict'].get('ret', False)
          except Exception:
              return False

      def shutdown(opts):
          '''
          For this proxy shutdown is a no-op
          '''
          log.debug('rest_sample proxy shutdown() called...')

   Grains are data about minions.  Most proxied devices will have a paltry
   amount of data as compared to a typical Linux server.   By  default,  a
   proxy  minion  will have several grains taken from the host.  Salt core
   code requires values for kernel, os, and os_family--all  of  these  are
   forced to be proxy for proxy-minions.

   To  add  others  to your proxy minion for a particular device, create a
   file in salt/grains  named  [proxytype].py  and  place  inside  it  the
   different  functions  that  need  to be run to collect the data you are
   interested in.  Here's an example.   Note  the  function  below  called
   proxy_functions.   It  demonstrates  how  a  grains function can take a
   single argument, which will be set to the value of  __proxy__.   Dunder
   variables  are  not yet injected into Salt processes at the time grains
   are loaded, so this enables us to get a handle to the proxymodule so we
   can  cross-call  the  functions  therein  used to commmunicate with the
   controlled device.

   Note that as of 2016.3, grains values  can  also  be  calculated  in  a
   function  called  grains()  in  the  proxymodule itself.  This might be
   useful if a proxymodule author wants to keep all the code for the proxy
   interface  in  the same place instead of splitting it between 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  will
   default to True in the release code-named Nitrogen.

   The __proxyenabled__ directive
   In  previous versions of Salt the __proxyenabled__ directive controlled
   loading of  all  Salt  modules  for  proxies  (e.g.  grains,  execution
   modules, state modules).  From 2016.3 on, the only modules that respect
   __proxyenabled__ are grains and proxy modules.  These modules  need  to
   be told which proxy they work with.

   __proxyenabled__  is a list, and can contain a single '*' to indicate a
   grains module works with all proxies.

   Example from salt/grains/rest_sample.py:

      # -*- coding: utf-8 -*-
      '''
      Generate baseline proxy minion grains
      '''
      from __future__ import absolute_import
      import salt.utils

      __proxyenabled__ = ['rest_sample']

      __virtualname__ = 'rest_sample'

      def __virtual__():
          try:
              if salt.utils.is_proxy() and __opts__['proxy']['proxytype'] == 'rest_sample':
                  return __virtualname__
          except KeyError:
              pass

          return False

   Salt Proxy Minion End-to-End Example
   The following is walkthrough that documents how to run  a  sample  REST
   service  and configure one or more proxy minions to talk to and control
   it.

   1. Ideally, create a  Python  virtualenv  in  which  to  run  the  REST
      service.   This  is  not strictly required, but without a virtualenv
      you will need to install bottle via pip globally on your system

   2. Clone   https://github.com/saltstack/salt-contrib   and   copy   the
      contents  of  the  directory proxyminion_rest_example somewhere on a
      machine that is reachable from the machine on which you want to  run
      the salt-proxy.  This machine needs Python 2.7 or later.

   3. Install bottle version 0.12.8 via pip or easy_install

      pip install bottle==0.12.8

   4. Run python rest.py --help for usage

   5. Start the REST API on an appropriate port and IP.

   6. Load  the REST service's status page in your browser by going to the
      IP/port combination (e.g. http://127.0.0.1:8000)

   7. You should  see  a  page  entitled  "Salt  Proxy  Minion"  with  two
      sections,  one  for "services" and one for "packages" and you should
      see a log entry in the terminal where you started the  REST  process
      indicating that the index page was retrieved.
   [image]

   Now, configure your salt-proxy.

   1. Edit /etc/salt/proxy and add an entry for your master's location

      master: localhost

   2. On  your  salt-master,  ensure  that  pillar is configured properly.
      Select an ID for your proxy (in this example we will name the  proxy
      with the letter 'p' followed by the port the proxy is answering on).
      In your pillar topfile, place an entry for your proxy:

      base:
        'p8000':
          - p8000

   This says that Salt's pillar should load  some  values  for  the  proxy
   p8000 from the file /srv/pillar/p8000.sls (if you have not changed your
   default pillar_roots)

   3. In the pillar root for your base environment, create this file:

      p8000.sls
      ---------

      proxy:
        proxytype: rest_sample
        url: http://<IP your REST listens on>:port

   In other words, if your REST service  is  listening  on  port  8000  on
   127.0.0.1 the 'url' key above should say url: http://127.0.0.1:8000

   4. Make sure your salt-master is running.

   5. Start the salt-proxy in debug mode

      salt-proxy --proxyid=p8000 -l debug

   6. Accept your proxy's key on your salt-master

      salt-key -y -a p8000
      The following keys are going to be accepted:
      Unaccepted Keys:
      p8000
      Key for minion p8000 accepted.

   7. Now  you  should  be  able  to  ping your proxy.  When you ping, you
      should see a log entry in the terminal where  the  REST  service  is
      running.

      salt p8000 test.ping

   8. The  REST  service  implements a degenerately simple pkg and service
      provider as well as a small set of grains.  To "install" a  package,
      use  a standard pkg.install.  If you pass '==' and a verrsion number
      after the package name then the service will parse that  and  accept
      that as the package's version.

   9. Try   running  salt  p8000  grains.items  to  see  what  grains  are
      available.  You can target proxies via grains if you like.

   10.
      You can also start and stop the available services (apache, redbull,
      and postgresql with service.start, etc.

   11.
      States  can be written to target the proxy.  Feel free to experiment
      with them.

   SSH Proxymodules
   See above for a general introduction to writing proxy modules.  All  of
   the  guidelines that apply to REST are the same for SSH.  This sections
   specifically talks about the SSH proxy module and explains the  working
   of the example proxy module ssh_sample.

   Here is a simple example proxymodule used to interface to a device over
   SSH.  Code for the SSH shell is in the salt-contrib GitHub repository

   This proxymodule enables "package" installation.

      # -*- coding: utf-8 -*-
      '''
      This is a simple proxy-minion designed to connect to and communicate with
      a server that exposes functionality via SSH.
      This can be used as an option when the device does not provide
      an api over HTTP and doesn't have the python stack to run a minion.
      '''
      from __future__ import absolute_import

      # Import python libs
      import json
      import logging

      # Import Salt's libs
      from salt.utils.vt_helper import SSHConnection
      from salt.utils.vt import TerminalException

      # This must be present or the Salt loader won't load this module
      __proxyenabled__ = ['ssh_sample']

      DETAILS = {}

      # Want logging!
      log = logging.getLogger(__file__)

      # This does nothing, it's here just as an example and to provide a log
      # entry when the module is loaded.
      def __virtual__():
          '''
          Only return if all the modules are available
          '''
          log.info('ssh_sample proxy __virtual__() called...')

          return True

      def init(opts):
          '''
          Required.
          Can be used to initialize the server connection.
          '''
          try:
              DETAILS['server'] = SSHConnection(host=__opts__['proxy']['host'],
                                                username=__opts__['proxy']['username'],
                                                password=__opts__['proxy']['password'])
              # connected to the SSH server
              out, err = DETAILS['server'].sendline('help')

          except TerminalException as e:
              log.error(e)
              return False

      def shutdown(opts):
          '''
          Disconnect
          '''
          DETAILS['server'].close_connection()

      def parse(out):
          '''
          Extract json from out.

          Parameter
              out: Type string. The data returned by the
              ssh command.
          '''
          jsonret = []
          in_json = False
          for ln_ in out.split('\n'):
              if '{' in ln_:
                  in_json = True
              if in_json:
                  jsonret.append(ln_)
              if '}' in ln_:
                  in_json = False
          return json.loads('\n'.join(jsonret))

      def package_list():
          '''
          List "packages" by executing a command via ssh
          This function is called in response to the salt command

          ..code-block::bash
              salt target_minion pkg.list_pkgs

          '''
          # Send the command to execute
          out, err = DETAILS['server'].sendline('pkg_list')

          # "scrape" the output and return the right fields as a dict
          return parse(out)

      def package_install(name, **kwargs):
          '''
          Install a "package" on the REST server
          '''
          cmd = 'pkg_install ' + name
          if 'version' in kwargs:
              cmd += '/'+kwargs['version']
          else:
              cmd += '/1.0'

          # Send the command to execute
          out, err = DETAILS['server'].sendline(cmd)

          # "scrape" the output and return the right fields as a dict
          return parse(out)

      def package_remove(name):
          '''
          Remove a "package" on the REST server
          '''
          cmd = 'pkg_remove ' + name

          # Send the command to execute
          out, err = DETAILS['server'].sendline(cmd)

          # "scrape" the output and return the right fields as a dict
          return parse(out)

   Connection Setup
   The init() method is responsible for  connection  setup.  It  uses  the
   host,  username  and  password  config  variables defined in the pillar
   data. The prompt kwarg can be  passed  to  SSHConnection  if  your  SSH
   server's  prompt differs from the example's prompt (Cmd). Instantiating
   the SSHConnection class establishes an SSH connection to the ssh server
   (using Salt VT).

   Command execution
   The package_* methods use the SSH connection (established in init()) to
   send  commands  out  to  the  SSH  server.  The  sendline()  method  of
   SSHConnection  class can be used to send commands out to the server. In
   the above example we send commands like pkg_list  or  pkg_install.  You
   can send any SSH command via this utility.

   Output parsing
   Output  returned  by  sendline() is a tuple of strings representing the
   stdout and the stderr respectively. In the toy example shown we  simply
   scrape  the  output  and convert it to a python dictionary, as shown in
   the parse method. You can tailor this  method  to  match  your  parsing
   logic.

   Connection teardown
   The  shutdown  method is responsible for calling the close_connection()
   method of SSHConnection class. This ends  the  SSH  connection  to  the
   server.

   For more information please refer to class SSHConnection.

   Salt Proxy Minion SSH End-to-End Example
   The  following  is  walkthrough  that documents how to run a sample SSH
   service and configure one or more proxy minions to talk to and  control
   it.

   1. This  walkthrough  uses  a custom SSH shell to provide an end to end
      example.  Any other shells can be used too.

   2. Setup      the      proxy      command      shell      as      shown
      https://github.com/saltstack/salt-contrib/tree/master/proxyminion_ssh_example

   Now, configure your salt-proxy.

   1. Edit /etc/salt/proxy and add an entry for your master's location

      master: localhost
      multiprocessing: False

   2. On your salt-master, ensure  that  pillar  is  configured  properly.
      Select  an ID for your proxy (in this example we will name the proxy
      with the letter 'p' followed by the port the proxy is answering on).
      In your pillar topfile, place an entry for your proxy:

      base:
        'p8000':
          - p8000

   This  says  that  Salt's  pillar  should load some values for the proxy
   p8000 from the file /srv/pillar/p8000.sls (if you have not changed your
   default pillar_roots)

   3. In the pillar root for your base environment, create this file:

      p8000.sls
      ---------

      proxy:
        proxytype: ssh_sample
        host: saltyVM
        username: salt
        password: badpass

   4. Make sure your salt-master is running.

   5. Start the salt-proxy in debug mode

      salt-proxy --proxyid=p8000 -l debug

   6. Accept your proxy's key on your salt-master

      salt-key -y -a p8000
      The following keys are going to be accepted:
      Unaccepted Keys:
      p8000
      Key for minion p8000 accepted.

   7. Now you should be able to run commands on your proxy.

      salt p8000 pkg.list_pkgs

   8. The  SSH shell implements a degenerately simple pkg.  To "install" a
      package, use a  standard  pkg.install.   If  you  pass  '=='  and  a
      verrsion  number  after the package name then the service will parse
      that and accept that as the package's version.
   New in version 2015.8.3.

   Proxy Minion Beacon
   The salt proxy beacon  is  meant  to  facilitate  configuring  multiple
   proxies  on  one  or many minions. This should simplify configuring and
   managing multiple salt-proxy processes.

   1. On your salt-master, ensure  that  pillar  is  configured  properly.
      Select  an ID for your proxy (in this example we will name the proxy
      'p8000').  In your pillar topfile, place an entry for your proxy:

      base:
        'p8000':
          - p8000

   This says that Salt's pillar should load  some  values  for  the  proxy
   p8000 from the file /srv/pillar/p8000.sls (if you have not changed your
   default pillar_roots)

   2. In the pillar root for your base environment, create this file:

      p8000.sls
      ---------

      proxy:
        # set proxytype for your proxymodule
        proxytype: ssh_sample
        host: saltyVM
        username: salt
        password: badpass

   This should complete the proxy setup for p8000

   3. Configure the salt_proxy beacon

      beacons:
        salt_proxy:
          - p8000: {}

   Once  this  beacon  is  configured  it  will  automatically  start  the
   salt-proxy  process. If the salt-proxy process is terminated the beacon
   will re-start it.

   4. Accept your proxy's key on your salt-master

      salt-key -y -a p8000
      The following keys are going to be accepted:
      Unaccepted Keys:
      p8000
      Key for minion p8000 accepted.

   5. Now you should be able to run commands on your proxy.

      salt p8000 pkg.list_pkgs
   New in version 2015.8.2.

   Proxy Minion States
   Salt proxy state can be used to deploy, configure and run a  salt-proxy
   instance  on  your  minion. Configure proxy settings on the master side
   and the state configures and runs salt-proxy on the remote end.

   1. On your salt-master, ensure  that  pillar  is  configured  properly.
      Select  an ID for your proxy (in this example we will name the proxy
      'p8000').  In your pillar topfile, place an entry for your proxy:

      base:
        'p8000':
          - p8000

   This says that Salt's pillar should load  some  values  for  the  proxy
   p8000 from the file /srv/pillar/p8000.sls (if you have not changed your
   default pillar_roots)

   2. In the pillar root for your base environment, create this file:

      p8000.sls
      ---------

      proxy:
        # set proxytype for your proxymodule
        proxytype: ssh_sample
        host: saltyVM
        username: salt
        password: badpass

   3. Create the following  state  in  your  state  tree  (let's  name  it
      salt_proxy.sls)

      salt-proxy-configure:
        salt_proxy.configure_proxy:
          - proxyname: p8000
          - start: True # start the process if it isn't running

   4. Make sure your salt-master and salt-minion are running.

   5. Run  the  state  salt_proxy  on  the  minion  where  you want to run
      salt-proxy

   Example using state.sls to configure and run salt-proxy

      # salt device_minion state.sls salt_proxy

   This starts salt-proxy on device_minion

   6. Accept your proxy's key on your salt-master

      salt-key -y -a p8000
      The following keys are going to be accepted:
      Unaccepted Keys:
      p8000
      Key for minion p8000 accepted.

   7. Now you should be able to run commands on your proxy.

      salt p8000 pkg.list_pkgs

   ESXi Proxy Minion
   New in version 2015.8.4.

   NOTE:
      This tutorial assumes basic knowledge of Salt. To get up  to  speed,
      check out the Salt Walkthrough.

      This  tutorial  also  assumes  a  basic  understanding of Salt Proxy
      Minions. If you're  unfamiliar  with  Salt's  Proxy  Minion  system,
      please  read  the Salt Proxy Minion documentation and the Salt Proxy
      Minion End-to-End Example tutorial.

      The third assumption that this tutorial makes is that you also  have
      a  basic  understanding of ESXi hosts. You can learn more about ESXi
      hosts on VMware's various resources.

   Salt's ESXi Proxy Minion allows a VMware ESXi host to be treated as  an
   individual  Salt  Minion,  without installing a Salt Minion on the ESXi
   host.

   Since an ESXi host may not necessarily run on an OS capable of  hosting
   a Python stack, the ESXi host can't run a regular Salt Minion directly.
   Therefore, Salt's Proxy Minion functionality enables you  to  designate
   another  machine  to  host a proxy process that "proxies" communication
   from the Salt Master to the ESXi host.  The master  does  not  know  or
   care that the ESXi target is not a "real" Salt Minion.

   More  in-depth  conceptual reading on Proxy Minions can be found in the
   Proxy Minion section of Salt's documentation.

   Salt's ESXi Proxy Minion was added in the 2015.8.4 release of Salt.

   NOTE:
      Be aware that some functionality  for  the  ESXi  Proxy  Minion  may
      depend on the type of license attached the ESXi host(s).

      For  example,  certain  services  are  only  available to manipulate
      service state or  policies  with  a  VMware  vSphere  Enterprise  or
      Enterprise  Plus license, while others are available with a Standard
      license. The ntpd  service  is  restricted  to  an  Enterprise  Plus
      license, while ssh is available via the Standard license.

      Please see the vSphere Comparison page for more information.

   Dependencies
   Manipulation  of  the ESXi host via a Proxy Minion requires the machine
   running the Proxy Minion process to have the ESXCLI package (and all of
   it's dependencies) and the pyVmomi Python Library to be installed.

   ESXi Password
   The ESXi Proxy Minion uses VMware's API to perform tasks on the host as
   if it was a regular Salt Minion. In order to access  the  API  that  is
   already  running  on  the ESXi host, the ESXi host must have a username
   and password that is used to log into the host. The username is usually
   root.  Before Salt can access the ESXi host via VMware's API, a default
   password must be set on the host.

   pyVmomi
   The pyVmomi Python library must be installed on  the  machine  that  is
   running the proxy process. pyVmomi can be installed via pip:

      pip install pyVmomi

   NOTE:
      Version  6.0 of pyVmomi has some problems with SSL error handling on
      certain versions of Python. If using version  6.0  of  pyVmomi,  the
      machine that you are running the proxy minion process from must have
      either Python 2.6, Python  2.7.9,  or  newer.  This  is  due  to  an
      upstream  dependency  in pyVmomi 6.0 that is not supported in Python
      version 2.7 to 2.7.8. If the version of  Python  running  the  proxy
      process  is  not in the supported range, you will need to install an
      earlier version of pyVmomi. See Issue #29537 for more information.

   Based on the note above, to install an earlier version of pyVmomi  than
   the version currently listed in PyPi, run the following:

      pip install pyVmomi==5.5.0.2014.1.1

   The  5.5.0.2014.1.1  is  a  known stable version that the original ESXi
   Proxy Minion was developed against.

   ESXCLI
   Currently, about a third of the  functions  used  for  the  ESXi  Proxy
   Minion  require  the ESXCLI package be installed on the machine running
   the Proxy Minion process.

   The ESXCLI package is also referred to as the VMware  vSphere  CLI,  or
   vCLI.  VMware  provides  vCLI  package  installation  instructions  for
   vSphere 5.5 and vSphere 6.0.

   Once all of the required dependencies are in place and the vCLI package
   is installed, you can check to see if you can connect to your ESXi host
   by running the following command:

      esxcli -s <host-location> -u <username> -p <password> system syslog config get

   If the connection was successful, ESXCLI was successfully installed  on
   your  system.   You should see output related to the ESXi host's syslog
   configuration.

   Configuration
   There are several places where various configuration values need to  be
   set in order for the ESXi Proxy Minion to run and connect properly.

   Proxy Config File
   On  the  machine  that  will  be running the Proxy Minon process(es), a
   proxy config file must be in place. This file should be located in  the
   /etc/salt/  directory  and  should  be  named proxy. If the file is not
   there by default, create it.

   This file should contain the location of your Salt Master that the Salt
   Proxy will connect to.

   Example Proxy Config File:

      # /etc/salt/proxy

      master: <salt-master-location>

   Pillar Profiles
   Proxy  minions  get their configuration from Salt's Pillar. Every proxy
   must have a stanza in Pillar and a reference  in  the  Pillar  top-file
   that matches the Proxy ID. At a minimum for communication with the ESXi
   host, the pillar should look like this:

      proxy:
        proxytype: esxi
        host: <ip or dns name of esxi host>
        username: <ESXi username>
        passwords:
          - first_password
          - second_password
          - third_password

   Some other optional settings are protocol and port. These can be  added
   to the pillar configuration.

   proxytype
   The  proxytype  key  and value pair is critical, as it tells Salt which
   interface to load from the proxy directory in Salt's install hierarchy,
   or  from  /srv/salt/_proxy on the Salt Master (if you have created your
   own proxy module, for example). To use this ESXi Proxy Module, set this
   to esxi.

   host
   The location, or ip/dns, of the ESXi host. Required.

   username
   The username used to login to the ESXi host, such as root. Required.

   passwords
   A  list  of  passwords to be used to try and login to the ESXi host. At
   least one password in this list is required.

   The proxy integration will try the passwords listed  in  order.  It  is
   configured this way so you can have a regular password and the password
   you   may   be   updating   for   an   ESXi   host   either   via   the
   vsphere.update_host_password  execution  module  function  or  via  the
   esxi.password_present state function. This way, after the  password  is
   changed,  you  should  not  need to restart the proxy minion--it should
   just pick up the the new password provided in the list.  You  can  then
   change pillar at will to move that password to the front and retire the
   unused ones.

   Use-case/reasoning for using a list of passwords: You are setting up an
   ESXi  host  for  the  first  time,  and  the  host comes with a default
   password.  You know that you'll be changing this password  during  your
   initial  setup from the default to a new password. If you only have one
   password option, and if you have a state  changing  the  password,  any
   remote  execution commands or states that run after the password change
   will not be able to run on the host until the password  is  updated  in
   Pillar and the Proxy Minion process is restarted.

   This allows you to use any number of potential fallback passwords.

   NOTE:
      When  a  password  is  changed  on  the  host  to one in the list of
      possible passwords, the further down on the list  the  password  is,
      the  longer  individual commands will take to return. This is due to
      the nature of pyVmomi's login system. We have to wait for the  first
      attempt to fail before trying the next password on the list.

      This  scenario  is  especially true, and even slower, when the proxy
      minion first starts. If  the  correct  password  is  not  the  first
      password  on  the  list, it may take up to a minute for test.ping to
      respond with a  True  result.  Once  the  initial  authorization  is
      complete, the responses for commands will be a little faster.

      To  avoid  these longer waiting periods, SaltStack recommends moving
      the correct password to the top of the list and restarting the proxy
      minion at your earliest convenience.

   protocol
   If  the  ESXi host is not using the default protocol, set this value to
   an alternate protocol. Default is https. For example:

   port
   If the ESXi host is not using the default port, set this  value  to  an
   alternate port. Default is 443.

   Example Configuration Files
   An  example of all of the basic configurations that need to be in place
   before starting the Proxy Minion processes includes  the  Proxy  Config
   File, Pillar Top File, and any individual Proxy Minion Pillar files.

   In this example, we'll assuming there are two ESXi hosts to connect to.
   Therefore, we'll be creating two Proxy Minion config files, one  config
   for each ESXi host.

   Proxy Config File:

      # /etc/salt/proxy

      master: <salt-master-location>

   Pillar Top File:

      # /srv/pillar/top.sls

      base:
        'esxi-1':
          - esxi-1
        'esxi-2':
          - esxi-2

   Pillar Config File for the first ESXi host, esxi-1:

      # /srv/pillar/esxi-1.sls

      proxy:
        proxytype: esxi
        host: esxi-1.example.com
        username: 'root'
        passwords:
          - bad-password-1
          - backup-bad-password-1

   Pillar Config File for the second ESXi host, esxi-2:

      # /srv/pillar/esxi-2.sls

      proxy:
        proxytype: esxi
        host: esxi-2.example.com
        username: 'root'
        passwords:
          - bad-password-2
          - backup-bad-password-2

   Starting the Proxy Minion
   Once all of the correct configuration files are in place, it is time to
   start the proxy processes!

   1. First, make sure your Salt Master is running.

   2. Start the first Salt Proxy, in  debug  mode,  by  giving  the  Proxy
      Minion  process  and ID that matches the config file name created in
      the Configuration section.

      salt-proxy --proxyid='esxi-1' -l debug

   1. Accept the esxi-1 Proxy Minion's key on the Salt Master:

      # salt-key -L
      Accepted Keys:
      Denied Keys:
      Unaccepted Keys:
      esxi-1
      Rejected Keys:
      #
      # salt-key -a esxi-1
      The following keys are going to be accepted:
      Unaccepted Keys:
      esxi-1
      Proceed? [n/Y] y
      Key for minion esxi-1 accepted.

   1. Repeat for the second Salt Proxy, this  time  we'll  run  the  proxy
      process as a daemon, as an example.

      salt-proxy --proxyid='esxi-2' -d

   1. Accept the esxi-2 Proxy Minion's key on the Salt Master:

      # salt-key -L
      Accepted Keys:
      esxi-1
      Denied Keys:
      Unaccepted Keys:
      esxi-2
      Rejected Keys:
      #
      # salt-key -a esxi-1
      The following keys are going to be accepted:
      Unaccepted Keys:
      esxi-2
      Proceed? [n/Y] y
      Key for minion esxi-1 accepted.

   1. Check and see if your Proxy Minions are responding:

      # salt 'esxi-*' test.ping
      esxi-1:
          True
      esxi-3:
          True

   Executing Commands
   Now  that you've configured your Proxy Minions and have them responding
   successfully to a test.ping, we can start  executing  commands  against
   the ESXi hosts via Salt.

   It's important to understand how this particular proxy works, and there
   are a couple of important pieces to be  aware  of  in  order  to  start
   running remote execution and state commands against the ESXi host via a
   Proxy Minion: the vSphere Execution Module, the ESXi Execution  Module,
   and the ESXi State Module.

   vSphere Execution Module
   The  Salt.modules.vsphere is a standard Salt execution module that does
   the bulk of the work for the ESXi Proxy Minion. If you pull up the docs
   for  it  you'll  see  that  almost  every  function in the module takes
   credentials (username and password) and a target  host  argument.  When
   credentials  and  a  host  aren't  passed,  Salt  runs commands through
   pyVmomi or ESXCLI against the local machine. If you wanted,  you  could
   run  functions  from  this  module  on any machine where an appropriate
   version of pyVmomi and ESXCLI are installed,  and  that  machine  would
   reach out over the network and communicate with the ESXi host.

   You'll  notice that most of the functions in the vSphere module require
   a host, username, and password. These parameters are contained  in  the
   Pillar  files  and passed through to the function via the proxy process
   that is already running. You don't need  to  provide  these  parameters
   when  you  execute  the  commands.  See  the  Running  Remote Execution
   Commands section below for an example.

   ESXi Execution Module
   In order for the Pillar information set up in the Configuration section
   above  to  be  passed  to  the  function  call in the vSphere Execution
   Module, the salt.modules.esxi execution module acts as a "shim" between
   the vSphere execution module functions and the proxy process.

   The "shim" takes the authentication credentials specified in the Pillar
   files and passes them through to  the  host,  username,  password,  and
   optional  protocol  and  port options required by the vSphere Execution
   Module functions.

   If the function takes more positional, or keyword,  arguments  you  can
   append  them  to  the call. It's this shim that speaks to the ESXi host
   through the proxy, arranging for the credentials  and  hostname  to  be
   pulled from the Pillar section for the ESXi Proxy Minion.

   Because  of  the presence of the shim, to lookup documentation for what
   functions you can use to interface with the ESXi host, you'll  want  to
   look in salt.modules.vsphere instead of salt.modules.esxi.

   Running Remote Execution Commands
   To  run  commands  from  the Salt Master to execute, via the ESXi Proxy
   Minion,   against   the   ESXi   host,    you    use    the    esxi.cmd
   <vsphere-function-name> syntax to call functions located in the vSphere
   Execution Module. Both args  and  kwargs  needed  for  various  vsphere
   execution  module  functions  must  be  passed through in a kwarg- type
   manor. For example:

      salt 'esxi-*' esxi.cmd system_info
      salt 'exsi-*' esxi.cmd get_service_running service_name='ssh'

   ESXi State Module
   The ESXi State Module functions similarly to other state  modules.  The
   "shim" provided by the ESXi Execution Module passes the necessary host,
   username, and password credentials through, so those options don't need
   to  be  provided in the state. Other than that, state files are written
   and executed just like any other Salt state. See the  salt.modules.esxi
   state for ESXi state functions.

   The  follow state file is an example of how to configure various pieces
   of an  ESXi  host  including  enabling  SSH,  uploading  and  SSH  key,
   configuring  a  coredump network config, syslog, ntp, enabling VMotion,
   resetting a host password, and more.

      # /srv/salt/configure-esxi.sls

      configure-host-ssh:
        esxi.ssh_configured:
          - service_running: True
          - ssh_key_file: /etc/salt/ssh_keys/my_key.pub
          - service_policy: 'automatic'
          - service_restart: True
          - certificate_verify: True

      configure-host-coredump:
        esxi.coredump_configured:
          - enabled: True
          - dump_ip: 'my-coredump-ip.example.com'

      configure-host-syslog:
        esxi.syslog_configured:
          - syslog_configs:
              loghost: ssl://localhost:5432,tcp://10.1.0.1:1514
              default-timeout: 120
          - firewall: True
          - reset_service: True
          - reset_syslog_config: True
          - reset_configs: loghost,default-timeout

      configure-host-ntp:
        esxi.ntp_configured:
          - service_running: True
          - ntp_servers:
            - 192.174.1.100
            - 192.174.1.200
          - service_policy: 'automatic'
          - service_restart: True

      configure-vmotion:
        esxi.vmotion_configured:
          - enabled: True

      configure-host-vsan:
        esxi.vsan_configured:
          - enabled: True
          - add_disks_to_vsan: True

      configure-host-password:
        esxi.password_present:
          - password: 'new-bad-password'

   States are called via the ESXi Proxy Minion just as  they  would  on  a
   regular minion.  For example:

      salt 'esxi-*' state.sls configure-esxi test=true
      salt 'esxi-*' state.sls configure-esxi

   Relevant Salt Files and Resources
   * ESXi Proxy Minion

   * ESXi Execution Module

   * ESXi State Module

   * Salt Proxy Minion Docs

   * Salt Proxy Minion End-to-End Example

   * vSphere Execution Module

SALT VIRT

   The  Salt  Virt cloud controller capability was initially added to Salt
   in version 0.14.0 as an alpha technology.

   The initial Salt Virt system supports core cloud operations:

   * Virtual machine deployment

   * Inspection of deployed VMs

   * Virtual machine migration

   * Network profiling

   * Automatic VM integration with all aspects of Salt

   * Image Pre-seeding

   Many  features  are  currently  under  development   to   enhance   the
   capabilities of the Salt Virt systems.

   NOTE:
      It  is noteworthy that Salt was originally developed with the intent
      of using the Salt communication system as the backbone  to  a  cloud
      controller.   This  means  that  the  Salt  Virt  system  is  not an
      afterthought, simply a system that  took  the  back  seat  to  other
      development.  The  original  attempt  to  develop  the cloud control
      aspects of Salt was a project called  butter.   This  project  never
      took  off, but was functional and proves the early viability of Salt
      to be a cloud controller.

   WARNING:
      Salt Virt does not work with KVM that is running in a VM.  KVM  must
      be running on the base hardware.

   Salt Virt Tutorial
   A  tutorial about how to get Salt Virt up and running has been added to
   the tutorial section:

   Cloud Controller Tutorial

   The Salt Virt Runner
   The point of interaction with the cloud controller is the virt  runner.
   The virt runner comes with routines to execute specific virtual machine
   routines.

   Reference documentation for the  virt  runner  is  available  with  the
   runner module documentation:

   Virt Runner Reference

   Based on Live State Data
   The  Salt  Virt  system is based on using Salt to query live data about
   hypervisors and then using the data gathered to  make  decisions  about
   cloud operations. This means that no external resources are required to
   run Salt Virt, and that the information gathered  about  the  cloud  is
   live and accurate.

   Deploy from Network or Disk
   Virtual Machine Disk Profiles
   Salt Virt allows for the disks created for deployed virtual machines to
   be finely configured. The configuration  is  a  simple  data  structure
   which  is  read  from  the  config.option  function,  meaning  that the
   configuration can be stored in  the  minion  config  file,  the  master
   config file, or the minion's pillar.

   This  configuration  option  is called virt.disk. The default virt.disk
   data structure looks like this:

      virt.disk:
        default:
          - system:
            size: 8192
            format: qcow2
            model: virtio

   NOTE:
      The format and model does not need to be defined, Salt will  default
      to the optimal format used by the underlying hypervisor, in the case
      of kvm this it is qcow2 and virtio.

   This configuration sets up a disk profile called default.  The  default
   profile creates a single system disk on the virtual machine.

   Define More Profiles
   Many  environments  will  require  more  complex  disk profiles and may
   require more than one profile, this can be easily accomplished:

      virt.disk:
        default:
          - system:
              size: 8192
        database:
          - system:
              size: 8192
          - data:
              size: 30720
        web:
          - system:
              size: 1024
          - logs:
              size: 5120

   This configuration allows for one of three  profiles  to  be  selected,
   allowing virtual machines to be created with different storage needs of
   the deployed vm.

   Virtual Machine Network Profiles
   Salt Virt allows for the network devices created for  deployed  virtual
   machines  to  be  finely configured. The configuration is a simple data
   structure which is read from the config.option function,  meaning  that
   the  configuration  can be stored in the minion config file, the master
   config file, or the minion's pillar.

   This configuration option is called virt.nic. By default  the  virt.nic
   option is empty but defaults to a data structure which looks like this:

      virt.nic:
        default:
          eth0:
            bridge: br0
            model: virtio

   NOTE:
      The  model  does  not  need  to be defined, Salt will default to the
      optimal model used by the underlying hypervisor, in the case of  kvm
      this model is virtio

   This  configuration  sets  up  a  network  profile  called default. The
   default profile creates a single Ethernet device on the virtual machine
   that  is  bridged to the hypervisor's br0 interface. This default setup
   does not require setting up the  virt.nic  configuration,  and  is  the
   reason  why  a  default install only requires setting up the br0 bridge
   device on the hypervisor.

   Define More Profiles
   Many environments will require more complex network  profiles  and  may
   require more than one profile, this can be easily accomplished:

      virt.nic:
        dual:
          eth0:
            bridge: service_br
          eth1:
            bridge: storage_br
        single:
          eth0:
            bridge: service_br
        triple:
          eth0:
            bridge: service_br
          eth1:
            bridge: storage_br
          eth2:
            bridge: dmz_br
        all:
          eth0:
            bridge: service_br
          eth1:
            bridge: storage_br
          eth2:
            bridge: dmz_br
          eth3:
            bridge: database_br
        dmz:
          eth0:
            bridge: service_br
          eth1:
            bridge: dmz_br
        database:
          eth0:
            bridge: service_br
          eth1:
            bridge: database_br

   This  configuration  allows  for  one  of  six profiles to be selected,
   allowing virtual machines to  be  created  which  attach  to  different
   network depending on the needs of the deployed vm.

   Salt as a Cloud Controller
   In Salt 0.14.0, an advanced cloud control system were introduced, allow
   private cloud vms to be managed directly  with  Salt.  This  system  is
   generally referred to as Salt Virt.

   The  Salt  Virt  system  already  exists  and  is installed within Salt
   itself, this means that besides setting up  Salt,  no  additional  salt
   code needs to be deployed.

   NOTE:
      The libvirt python module and the certtool binary are required.

   The  main  goal  of  Salt  Virt is to facilitate a very fast and simple
   cloud. The cloud that can scale and is fully featured. Salt Virt  comes
   with  the  ability  to  set  up  and  manage  complex  virtual  machine
   networking, powerful image and disk  management,  as  well  as  virtual
   machine migration with and without shared storage.

   This  means  that  Salt Virt can be used to create a cloud from a blade
   center and a SAN, but can also create a cloud out of a swarm  of  Linux
   Desktops  without  a  single  shared storage system. Salt Virt can make
   clouds from truly commodity hardware, but can also stand up  the  power
   of specialized hardware as well.

   Setting up Hypervisors
   The  first  step to set up the hypervisors involves getting the correct
   software installed and setting up the hypervisor network interfaces.

   Installing Hypervisor Software
   Salt Virt is made to be hypervisor  agnostic  but  currently  the  only
   fully implemented hypervisor is KVM via libvirt.

   The required software for a hypervisor is libvirt and kvm. For advanced
   features install libguestfs or qemu-nbd.

   NOTE:
      Libguestfs and qemu-nbd allow  for  virtual  machine  images  to  be
      mounted  before startup and get pre-seeded with configurations and a
      salt minion

   This sls will set up the needed software for a hypervisor, and run  the
   routines to set up the libvirt pki keys.

   NOTE:
      Package  names and setup used is Red Hat specific, different package
      names will be required for different platforms

      libvirt:
        pkg.installed: []
        file.managed:
          - name: /etc/sysconfig/libvirtd
          - contents: 'LIBVIRTD_ARGS="--listen"'
          - require:
            - pkg: libvirt
        virt.keys:
          - require:
            - pkg: libvirt
        service.running:
          - name: libvirtd
          - require:
            - pkg: libvirt
            - network: br0
            - libvirt: libvirt
          - watch:
            - file: libvirt

      libvirt-python:
        pkg.installed: []

      libguestfs:
        pkg.installed:
          - pkgs:
            - libguestfs
            - libguestfs-tools

   Hypervisor Network Setup
   The hypervisors will need to be running a network bridge  to  serve  up
   network  devices  for  virtual  machines,  this  formula  will set up a
   standard bridge on a hypervisor connecting the bridge to eth0:

      eth0:
        network.managed:
          - enabled: True
          - type: eth
          - bridge: br0

      br0:
        network.managed:
          - enabled: True
          - type: bridge
          - proto: dhcp
          - require:
            - network: eth0

   Virtual Machine Network Setup
   Salt Virt comes with a system to model the network interfaces  used  by
   the deployed virtual machines; by default a single interface is created
   for the deployed virtual machine and is bridged to br0.  To  get  going
   with  the  default  networking  setup, ensure that the bridge interface
   named br0 exists on the hypervisor and is bridged to an active  network
   device.

   NOTE:
      To  use  more  advanced  networking in Salt Virt, read the Salt Virt
      Networking document:

      Salt Virt Networking

   Libvirt State
   One of the challenges  of  deploying  a  libvirt  based  cloud  is  the
   distribution  of  libvirt  certificates.  These  certificates allow for
   virtual machine migration. Salt comes with a system used to auto deploy
   these  certificates.   Salt  manages  the  signing  authority  key  and
   generates keys for libvirt clients on the master, signs them  with  the
   certificate  authority  and  uses  pillar  to  distribute them. This is
   managed via the libvirt state.  Simply  execute  this  formula  on  the
   minion to ensure that the certificate is in place and up to date:

   NOTE:
      The above formula includes the calls needed to set up libvirt keys.

      libvirt_keys:
        virt.keys

   Getting Virtual Machine Images Ready
   Salt  Virt,  requires  that virtual machine images be provided as these
   are not generated on the fly. Generating these virtual  machine  images
   differs greatly based on the underlying platform.

   Virtual  machine  images  can be manually created using KVM and running
   through the installer, but this process is not recommended since it  is
   very manual and prone to errors.

   Virtual   Machine   generation  applications  are  available  for  many
   platforms:

   kiwi: (openSUSE, SLES, RHEL, CentOS)
          https://suse.github.io/kiwi/

   vm-builder:
          https://wiki.debian.org/VMBuilder

          SEE ALSO:
             vmbuilder-formula

   Once virtual machine images are available, the easiest way to make them
   available  to  Salt Virt is to place them in the Salt file server. Just
   copy an image into /srv/salt and it can now be used by Salt Virt.

   For purposes of this demo, the file name centos.img will be used.

   Existing Virtual Machine Images
   Many existing Linux distributions  distribute  virtual  machine  images
   which  can be used with Salt Virt. Please be advised that NONE OF THESE
   IMAGES ARE SUPPORTED BY SALTSTACK.

   CentOS
   These images have been prepared for OpenNebula but should work  without
   issue  with  Salt  Virt,  only  the  raw  qcow  image  file  is needed:
   http://wiki.centos.org/Cloud/OpenNebula

   Fedora Linux
   Images     for     Fedora     Linux     can     be     found      here:
   http://fedoraproject.org/en/get-fedora#clouds

   openSUSE
   http://download.opensuse.org/repositories/openSUSE:/Leap:/42.1:/Images/images

   (look for JeOS-for-kvm-and-xen variant)

   SUSE
   https://www.suse.com/products/server/jeos

   Ubuntu Linux
   Images     for     Ubuntu     Linux     can     be     found      here:
   http://cloud-images.ubuntu.com/

   Using Salt Virt
   With  hypervisors  set  up  and  virtual machine images ready, Salt can
   start issuing cloud commands.

   Start by running a Salt Virt hypervisor info command:

      salt-run virt.hyper_info

   This will query what the  running  hypervisor  stats  are  and  display
   information  for  all  configured  hypervisors.  This command will also
   validate that the hypervisors are properly configured.

   Now  that  hypervisors  are  available  a  virtual   machine   can   be
   provisioned. The virt.init routine will create a new virtual machine:

      salt-run virt.init centos1 2 512 salt://centos.img

   This  command  assumes that the CentOS virtual machine image is sitting
   in the root of the  Salt  fileserver.  Salt  Virt  will  now  select  a
   hypervisor  to  deploy  the new virtual machine on and copy the virtual
   machine image down to the hypervisor.

   Once the VM image has been copied down the new virtual machine will  be
   seeded.   Seeding  the VMs involves setting pre-authenticated Salt keys
   on the new VM and if needed, will install the Salt Minion on the new VM
   before it is started.

   NOTE:
      The biggest bottleneck in starting VMs is when the Salt Minion needs
      to be installed. Making sure that the source VM images already  have
      Salt installed will GREATLY speed up virtual machine deployment.

   Now  that  the  new  VM  has  been  prepared,  it  can  be seen via the
   virt.query command:

      salt-run virt.query

   This command  will  return  data  about  all  of  the  hypervisors  and
   respective virtual machines.

   Now that the new VM is booted it should have contacted the Salt Master,
   a test.ping will reveal if the new VM is running.

   Migrating Virtual Machines
   Salt Virt comes with full support for virtual  machine  migration,  and
   using the libvirt state in the above formula makes migration possible.

   A  few things need to be available to support migration. Many operating
   systems turn on firewalls when originally set up, the firewall needs to
   be  opened  up  to  allow  for libvirt and kvm to cross communicate and
   execution  migration  routines.  On  Red  Hat  based   hypervisors   in
   particular port 16514 needs to be opened on hypervisors:

      iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 16514 -j ACCEPT

   NOTE:
      More  in-depth  information regarding distribution specific firewall
      settings can read in:

      Opening the Firewall up for Salt

   Salt also needs an additional  flag  to  be  turned  on  as  well.  The
   virt.tunnel  option  needs to be turned on. This flag tells Salt to run
   migrations securely via the libvirt TLS tunnel and to use  port  16514.
   Without  virt.tunnel libvirt tries to bind to random ports when running
   migrations. To turn on virt.tunnel simple apply it to the master config
   file:

      virt.tunnel: True

   Once  the  master  config has been updated, restart the master and send
   out a call to the minions to refresh the  pillar  to  pick  up  on  the
   change:

      salt \* saltutil.refresh_modules

   Now,  migration  routines  can  be run! To migrate a VM, simply run the
   Salt Virt migrate routine:

      salt-run virt.migrate centos <new hypervisor>

   VNC Consoles
   Salt Virt also sets up VNC consoles by  default,  allowing  for  remote
   visual  consoles  to  be  oped  up.  The  information from a virt.query
   routine will display the vnc console port for the specific vms:

      centos
        CPU: 2
        Memory: 524288
        State: running
        Graphics: vnc - hyper6:5900
        Disk - vda:
          Size: 2.0G
          File: /srv/salt-images/ubuntu2/system.qcow2
          File Format: qcow2
        Nic - ac:de:48:98:08:77:
          Source: br0
          Type: bridge

   The line Graphics: vnc - hyper6:5900 holds  the  key.  First  the  port
   named, in this case 5900, will need to be available in the hypervisor's
   firewall.  Once the port is open, then the console can be easily opened
   via vncviewer:

      vncviewer hyper6:5900

   By  default  there  is  no  VNC  security  set up on these ports, which
   suggests that keeping them firewalled and mandating that SSH tunnels be
   used  to  access  these VNC interfaces. Keep in mind that activity on a
   VNC interface that is accessed can be viewed by  any  other  user  that
   accesses  that  same  VNC  interface, and any other user logging in can
   also operate with the logged in user on the virtual machine.

   Conclusion
   Now with Salt Virt running, new hypervisors  can  be  seamlessly  added
   just  by running the above states on new bare metal machines, and these
   machines will be instantly available to Salt Virt.

COMMAND LINE REFERENCE

   salt-call
   salt-call
   Synopsis
      salt-call [options]

   Description
   The salt-call command is used to run  module  functions  locally  on  a
   minion  instead of executing them from the master. Salt-call is used to
   run   a   Standalone   Minion,   and   was   originally   created   for
   troubleshooting.

   The  Salt  Master  is  contacted  to  retrieve  state  files  and other
   resources during execution unless the --local option is specified.

   NOTE:
      salt-call commands execute from the current  user's  shell  context,
      while salt commands execute from the system's default context.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   --hard-crash
          Raise  any  original  exception  rather  than exiting gracefully
          Default: False

   -g, --grains
          Return the information generated by the Salt grains

   -m MODULE_DIRS, --module-dirs=MODULE_DIRS
          Specify an additional directory to pull modules from.   Multiple
          directories   can  be  provided  by  passing  -m  /--module-dirs
          multiple times.

   -d, --doc, --documentation
          Return the documentation for the specified  module  or  for  all
          modules if none are specified

   --master=MASTER
          Specify the master to use. The minion must be authenticated with
          the master. If this option is omitted, the master  options  from
          the  minion config will be used. If multi masters are set up the
          first listed master that responds will be used.

   --return RETURNER
          Set salt-call to pass the return data to one  or  many  returner
          interfaces.   To  use  many  returner interfaces specify a comma
          delimited list of returners.

   --local
          Run salt-call locally, as if there was no master running.

   --file-root=FILE_ROOT
          Set this directory as the base file root.

   --pillar-root=PILLAR_ROOT
          Set this directory as the base pillar root.

   --retcode-passthrough
          Exit with the salt call retcode and not the salt binary retcode

   --metadata
          Print out the execution metadata as well  as  the  return.  This
          will print out the outputter data, the return code, etc.

   --id=ID
          Specify  the minion id to use. If this option is omitted, the id
          option from the minion config will be used.

   --skip-grains
          Do not load grains.

   --refresh-grains-cache
          Force a refresh of the grains cache

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/minion.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   Output Options
   --out  Pass  in an alternative outputter to display the return of data.
          This outputter can be any of the available outputters:
             grains, highstate, json, key,  overstatestage,  pprint,  raw,
             txt, yaml

          Some  outputters  are  formatted  only  for  data  returned from
          specific functions; for instance, the grains outputter will  not
          work for non-grains data.

          If  an  outputter  is used that does not support the data passed
          into it, then Salt will fall back on the  pprint  outputter  and
          display the return data using the Python pprint standard library
          module.

          NOTE:
             If using --out=json, you will probably want --static as well.
             Without  the  static  option,  you  will  get a separate JSON
             string per minion which makes JSON output invalid as a whole.
             This  is  due to using an iterative outputter. So if you want
             to feed it to a JSON parser, use --static as well.

   --out-indent OUTPUT_INDENT, --output-indent OUTPUT_INDENT
          Print the output indented  by  the  provided  value  in  spaces.
          Negative   values   disable   indentation.  Only  applicable  in
          outputters that support indentation.

   --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
          Write the output to the specified file.

   --no-color
          Disable all colored output

   --force-color
          Force colored output

          NOTE:
             When using colored output the color codes are as follows:

             green denotes success,  red  denotes  failure,  blue  denotes
             changes  and  success  and  yellow  denotes a expected future
             change in configuration.

   See also
   salt(1) salt-master(1) salt-minion(1)

   salt
   salt
   Synopsis
      salt '*' [ options ] sys.doc

      salt -E '.*' [ options ] sys.doc cmd

      salt -G 'os:Arch.*' [ options ] test.ping

      salt -C 'G@os:Arch.* and webserv* or G@kernel:FreeBSD' [  options  ]
      test.ping

   Description
   Salt  allows  for  commands  to  be  executed  across a swath of remote
   systems in parallel.  This  means  that  remote  systems  can  be  both
   controlled and queried with ease.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   -t TIMEOUT, --timeout=TIMEOUT
          The  timeout  in  seconds  to  wait  for  replies  from the Salt
          minions. The timeout number specifies how long the command  line
          client will wait to query the minions and check on running jobs.
          Default: 5

   -s, --static
          By default as of version 0.9.8 the salt command returns data  to
          the  console  as  it  is  received  from  minions,  but previous
          releases would return data only after all data was received. Use
          the  static  option  to only return the data with a hard timeout
          and after all minions have returned.  Without the static option,
          you  will get a separate JSON string per minion which makes JSON
          output invalid as a whole.

   --async
          Instead of waiting for the job to run on minions only print  the
          job id of the started execution and complete.

   --state-output=STATE_OUTPUT
          New in version 0.17.

          Override  the  configured  state_output value for minion output.
          One of full, terse, mixed, changes or filter.  Default: full.

   --subset=SUBSET
          Execute the routine on a random subset of the targeted  minions.
          The  minions  will be verified that they have the named function
          before executing. The  SUBSET  argument  is  the  count  of  the
          minions to target.

   -v VERBOSE, --verbose
          Turn  on  verbosity  for the salt call, this will cause the salt
          command to print out extra data like the job id.

   --hide-timeout
          Instead of showing the return data for all minions. This  option
          prints only the online minions which could be reached.

   -b BATCH, --batch-size=BATCH
          Instead of executing on all targeted minions at once, execute on
          a progressive set of minions. This option takes an  argument  in
          the form of an explicit number of minions to execute at once, or
          a percentage of minions to execute on.

   -a EAUTH, --auth=EAUTH
          Pass in an external authentication medium to  validate  against.
          The  credentials  will  be  prompted  for. The options are auto,
          keystone, ldap, pam, and stormpath. Can  be  used  with  the  -T
          option.

   -T, --make-token
          Used  in  conjunction  with  the -a option. This creates a token
          that allows for the authenticated user to send commands  without
          needing to re-authenticate.

   --return=RETURNER
          Choose  an  alternative  returner  to  call on the minion, if an
          alternative returner is used then the return will not come  back
          to  the  command  line  but will be sent to the specified return
          system.  The options are carbon, cassandra, couchbase,  couchdb,
          elasticsearch,  etcd,  hipchat,  local,  local_cache,  memcache,
          mongo, mysql, odbc, postgres, redis, sentry, slack,  sms,  smtp,
          sqlite3, syslog, and xmpp.

   -d, --doc, --documentation
          Return  the  documentation for the module functions available on
          the minions

   --args-separator=ARGS_SEPARATOR
          Set the special argument used as  a  delimiter  between  command
          arguments of compound commands. This is useful when one wants to
          pass commas as arguments to some of the commands in  a  compound
          command.

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/master.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   Target Selection
   The default matching that Salt utilizes is shell-style globbing  around
   the                   minion                   id.                  See
   https://docs.python.org/2/library/fnmatch.html#module-fnmatch.

   -E, --pcre
          The target expression will be  interpreted  as  a  PCRE  regular
          expression rather than a shell glob.

   -L, --list
          The  target  expression will be interpreted as a comma-delimited
          list; example: server1.foo.bar,server2.foo.bar,example7.quo.qux

   -G, --grain
          The target expression matches values returned by the Salt grains
          system on the minions. The target expression is in the format of
          '<grain value>:<glob expression>'; example: 'os:Arch*'

          This was changed in version 0.9.8  to  accept  glob  expressions
          instead   of  regular  expression.  To  use  regular  expression
          matching with grains, use the --grain-pcre option.

   --grain-pcre
          The target expression matches values returned by the Salt grains
          system on the minions. The target expression is in the format of
          '<grain value>:< regular expression>'; example: 'os:Arch.*'

   -N, --nodegroup
          Use a predefined compound target  defined  in  the  Salt  master
          configuration file.

   -R, --range
          Instead of using shell globs to evaluate the target, use a range
          expression to identify  targets.  Range  expressions  look  like
          %cluster.

          Using  the  Range  option requires that a range server is set up
          and the location of the range server is referenced in the master
          configuration file.

   -C, --compound
          Utilize  many target definitions to make the call very granular.
          This option takes a group of targets separated by and or or. The
          default  matcher  is  a glob as usual. If something other than a
          glob is used, preface it with  the  letter  denoting  the  type;
          example:  'webserv* and G@os:Debian or E@db*' Make sure that the
          compound target is encapsulated in quotes.

   -I, --pillar
          Instead of using shell globs  to  evaluate  the  target,  use  a
          pillar  value  to identify targets. The syntax for the target is
          the pillar key followed by a glob expression: "role:production*"

   -S, --ipcidr
          Match based on Subnet (CIDR notation) or IPv4 address.

   Output Options
   --out  Pass in an alternative outputter to display the return of  data.
          This outputter can be any of the available outputters:
             grains,  highstate,  json,  key, overstatestage, pprint, raw,
             txt, yaml

          Some outputters  are  formatted  only  for  data  returned  from
          specific  functions; for instance, the grains outputter will not
          work for non-grains data.

          If an outputter is used that does not support  the  data  passed
          into  it,  then  Salt will fall back on the pprint outputter and
          display the return data using the Python pprint standard library
          module.

          NOTE:
             If using --out=json, you will probably want --static as well.
             Without the static option,  you  will  get  a  separate  JSON
             string per minion which makes JSON output invalid as a whole.
             This is due to using an iterative outputter. So if  you  want
             to feed it to a JSON parser, use --static as well.

   --out-indent OUTPUT_INDENT, --output-indent OUTPUT_INDENT
          Print  the  output  indented  by  the  provided value in spaces.
          Negative  values  disable  indentation.   Only   applicable   in
          outputters that support indentation.

   --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
          Write the output to the specified file.

   --no-color
          Disable all colored output

   --force-color
          Force colored output

          NOTE:
             When using colored output the color codes are as follows:

             green  denotes  success,  red  denotes  failure, blue denotes
             changes and success and  yellow  denotes  a  expected  future
             change in configuration.

   See also
   salt(7) salt-master(1) salt-minion(1)

   salt-cloud
   salt-cp
   salt-cp
   Copy a file to a set of systems

   Synopsis
      salt-cp '*' [ options ] SOURCE DEST

      salt-cp -E '.*' [ options ] SOURCE DEST

      salt-cp -G 'os:Arch.*' [ options ] SOURCE DEST

   Description
   Salt copy copies a local file out to all of the Salt minions matched by
   the given target.

   Salt copy is only intended for use with small files (< 100KB).  If  you
   need  to  copy  large  files  out to minions please use the cp.get_file
   function.

   Note: salt-cp uses salt's publishing mechanism. This means the  privacy
   of  the  contents  of the file on the wire is completely dependent upon
   the transport in use. In addition, if the salt-master is  running  with
   debug  logging  it  is  possible  that the contents of the file will be
   logged to disk.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   -t TIMEOUT, --timeout=TIMEOUT
          The timeout in  seconds  to  wait  for  replies  from  the  Salt
          minions.  The timeout number specifies how long the command line
          client will wait to query the minions and check on running jobs.
          Default: 5

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/master.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   Target Selection
   The default matching that Salt utilizes is shell-style globbing  around
   the                   minion                   id.                  See
   https://docs.python.org/2/library/fnmatch.html#module-fnmatch.

   -E, --pcre
          The target expression will be  interpreted  as  a  PCRE  regular
          expression rather than a shell glob.

   -L, --list
          The  target  expression will be interpreted as a comma-delimited
          list; example: server1.foo.bar,server2.foo.bar,example7.quo.qux

   -G, --grain
          The target expression matches values returned by the Salt grains
          system on the minions. The target expression is in the format of
          '<grain value>:<glob expression>'; example: 'os:Arch*'

          This was changed in version 0.9.8  to  accept  glob  expressions
          instead   of  regular  expression.  To  use  regular  expression
          matching with grains, use the --grain-pcre option.

   --grain-pcre
          The target expression matches values returned by the Salt grains
          system on the minions. The target expression is in the format of
          '<grain value>:< regular expression>'; example: 'os:Arch.*'

   -N, --nodegroup
          Use a predefined compound target  defined  in  the  Salt  master
          configuration file.

   -R, --range
          Instead of using shell globs to evaluate the target, use a range
          expression to identify  targets.  Range  expressions  look  like
          %cluster.

          Using  the  Range  option requires that a range server is set up
          and the location of the range server is referenced in the master
          configuration file.

   See also
   salt(1) salt-master(1) salt-minion(1)

   salt-extend
   salt-extend
   A  utilty  to generate extensions to the Salt source-code. This is used
   for :

   * Adding new execution modules, state modules

   * Adding unit tests to existing modules

   * Adding integration tests to existing modules

   Synopsis
      salt-extend --help

   Description
   salt-extend is a templating tool for  extending  SaltStack.  If  you're
   looking  to add a module to SaltStack, then the salt-extend utility can
   guide you through the process.

   You can use Salt Extend to quickly create templated modules for  adding
   new behaviours to some of the module subsystems within Salt.

   Salt  Extend  takes a template directory and merges it into a SaltStack
   source code directory.

   See also: Salt Extend.

   Options
   --extension, -e
          The  extension  type  you  want   to   develop,   e.g.   module,
          module_unit, state

   --salt-directory, -o
          The path to the salt installation, defaults to .

   --name, -n
          The module name for the new module

   --description, -d
          A description of the new extension

   --no-merge
          Don't  merge  the  new  module  into  the  Salt source directory
          specified by --salt-directory, save to a temporary directory and
          print the directory path

   --debug
          Print debug messages to stdout

   See also
   salt-api(1)    salt-call(1)    salt-cloud(1)   salt-cp(1)   salt-key(1)
   salt-main(1)  salt-master(1)  salt-minion(1)  salt-run(1)   salt-ssh(1)
   salt-syndic(1)

   salt-key
   salt-key
   Synopsis
      salt-key [ options ]

   Description
   Salt-key executes simple management of Salt server public keys used for
   authentication.

   On initial connection, a Salt minion sends its public key to  the  Salt
   master.  This  key  must  be accepted using the salt-key command on the
   Salt master.

   Salt minion keys can be in one of the following states:

   * unaccepted: key is waiting to be accepted.

   * accepted: key was accepted and the minion can  communicate  with  the
     Salt master.

   * rejected:  key was rejected using the salt-key command. In this state
     the minion does not receive any communication from the Salt master.

   * denied: key was rejected automatically  by  the  Salt  master.   This
     occurs when a minion has a duplicate ID, or when a minion was rebuilt
     or had new keys generated and the previous key was not  deleted  from
     the  Salt  master.  In  this  state  the  minion does not receive any
     communication from the Salt master.

   To change the state of a minion key, use -d to delete the key and  then
   accept or reject the key.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   -u USER, --user=USER
          Specify user to run salt-key

   --hard-crash
          Raise  any  original  exception  rather than exiting gracefully.
          Default is False.

   -q, --quiet
          Suppress output

   -y, --yes
          Answer 'Yes' to all questions presented, defaults to False

   --rotate-aes-key=ROTATE_AES_KEY
          Setting this to False prevents the master  from  refreshing  the
          key  session  when keys are deleted or rejected, this lowers the
          security of the key  deletion/rejection  operation.  Default  is
          True.

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/minion.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   Output Options
   --out  Pass  in an alternative outputter to display the return of data.
          This outputter can be any of the available outputters:
             grains, highstate, json, key,  overstatestage,  pprint,  raw,
             txt, yaml

          Some  outputters  are  formatted  only  for  data  returned from
          specific functions; for instance, the grains outputter will  not
          work for non-grains data.

          If  an  outputter  is used that does not support the data passed
          into it, then Salt will fall back on the  pprint  outputter  and
          display the return data using the Python pprint standard library
          module.

          NOTE:
             If using --out=json, you will probably want --static as well.
             Without  the  static  option,  you  will  get a separate JSON
             string per minion which makes JSON output invalid as a whole.
             This  is  due to using an iterative outputter. So if you want
             to feed it to a JSON parser, use --static as well.

   --out-indent OUTPUT_INDENT, --output-indent OUTPUT_INDENT
          Print the output indented  by  the  provided  value  in  spaces.
          Negative   values   disable   indentation.  Only  applicable  in
          outputters that support indentation.

   --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
          Write the output to the specified file.

   --no-color
          Disable all colored output

   --force-color
          Force colored output

          NOTE:
             When using colored output the color codes are as follows:

             green denotes success,  red  denotes  failure,  blue  denotes
             changes  and  success  and  yellow  denotes a expected future
             change in configuration.

   Actions
   -l ARG, --list=ARG
          List the public keys. The args pre, un, and unaccepted will list
          unaccepted/unsigned    keys.   acc   or   accepted   will   list
          accepted/signed keys. rej or rejected will list  rejected  keys.
          Finally, all will list all keys.

   -L, --list-all
          List all public keys. (Deprecated: use --list all)

   -a ACCEPT, --accept=ACCEPT
          Accept  the  specified  public  key  (use --include-all to match
          rejected keys in addition to pending keys). Globs are supported.

   -A, --accept-all
          Accepts all pending keys.

   -r REJECT, --reject=REJECT
          Reject the specified public  key  (use  --include-all  to  match
          accepted keys in addition to pending keys). Globs are supported.

   -R, --reject-all
          Rejects all pending keys.

   --include-all
          Include non-pending keys when accepting/rejecting.

   -p PRINT, --print=PRINT
          Print the specified public key.

   -P, --print-all
          Print all public keys

   -d DELETE, --delete=DELETE
          Delete the specified key. Globs are supported.

   -D, --delete-all
          Delete all keys.

   -f FINGER, --finger=FINGER
          Print the specified key's fingerprint.

   -F, --finger-all
          Print all keys' fingerprints.

   Key Generation Options
   --gen-keys=GEN_KEYS
          Set a name to generate a keypair for use with salt

   --gen-keys-dir=GEN_KEYS_DIR
          Set  the  directory  to  save the generated keypair.  Only works
          with 'gen_keys_dir' option; default is the current directory.

   --keysize=KEYSIZE
          Set the keysize for the  generated  key,  only  works  with  the
          '--gen-keys'  option,  the  key  size  must  be  2048 or higher,
          otherwise it will be rounded up to 2048. The default is 2048.

   --gen-signature
          Create  a  signature  file  of  the  master's  public-key  named
          master_pubkey_signature.  The  signature can be sent to a minion
          in the master's auth-reply and enables the minion to verify  the
          master's  public-key  cryptographically.  This  requires  a  new
          signing-key-pair   which   can   be   auto-created   with    the
          --auto-create parameter.

   --priv=PRIV
          The private-key file to create a signature with

   --signature-path=SIGNATURE_PATH
          The path where the signature file should be written

   --pub=PUB
          The public-key file to create a signature for

   --auto-create
          Auto-create a signing key-pair if it does not yet exist

   See also
   salt(7) salt-master(1) salt-minion(1)

   salt-master
   salt-master
   The Salt master daemon, used to control the Salt minions

   Synopsis
      salt-master [ options ]

   Description
   The master daemon controls the Salt minions

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   -u USER, --user=USER
          Specify user to run salt-master

   -d, --daemon
          Run salt-master as a daemon

   --pid-file PIDFILE
          Specify     the    location    of    the    pidfile.    Default:
          /var/run/salt-master.pid

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/master.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt(1) salt(7) salt-minion(1)

   salt-minion
   salt-minion
   The Salt minion daemon, receives commands from a remote Salt master.

   Synopsis
      salt-minion [ options ]

   Description
   The  Salt  minion  receives  commands  from the central Salt master and
   replies with the results of said commands.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   -u USER, --user=USER
          Specify user to run salt-minion

   -d, --daemon
          Run salt-minion as a daemon

   --pid-file PIDFILE
          Specify    the    location    of    the    pidfile.     Default:
          /var/run/salt-minion.pid

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/minion.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt(1) salt(7) salt-master(1)

   salt-proxy
   salt-proxy
   Receives commands from a Salt master  and  proxies  these  commands  to
   devices that are unable to run a full minion.

   Synopsis
      salt-proxy [ options ]

   Description
   The  Salt  proxy minion receives commands from a Salt master, transmits
   appropriate commands to devices that are unable to run  a  minion,  and
   replies with the results of said commands.

   Options
   --proxyid
          The minion id that this proxy will assume.  This is required.

   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   -u USER, --user=USER
          Specify user to run salt-proxy

   -d, --daemon
          Run salt-proxy as a daemon

   --pid-file PIDFILE
          Specify     the    location    of    the    pidfile.    Default:
          /var/run/salt-proxy-<id>.pid

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/minion.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt(1) salt(7) salt-master(1) salt-minion(1)

   salt-run
   salt-run
   Execute a Salt runner

   Synopsis
      salt-run RUNNER

   Description
   salt-run  is  the  frontend  command  for executing Salt Runners.  Salt
   runners are simple modules used to execute convenience functions on the
   master

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   -t TIMEOUT, --timeout=TIMEOUT
          The  timeout  in  seconds  to  wait  for  replies  from the Salt
          minions. The timeout number specifies how long the command  line
          client will wait to query the minions and check on running jobs.
          Default: 1

   --hard-crash
          Raise any original exception  rather  than  exiting  gracefully.
          Default is False.

   -d, --doc, --documentation
          Display  documentation for runners, pass a module or a runner to
          see documentation on only that module/runner.

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/master.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt(1) salt-master(1) salt-minion(1)

   salt-ssh
   salt-ssh
   Synopsis
      salt-ssh '*' [ options ] sys.doc

      salt-ssh -E '.*' [ options ] sys.doc cmd

   Description
   Salt  SSH  allows  for  salt routines to be executed using only SSH for
   transport

   Options
   -r, --raw, --raw-shell
          Execute a raw shell command.

   --priv Specify the SSH private key file to be used for authentication.

   --roster
          Define which roster system to use, this defines  if  a  database
          backend,  scanner,  or  custom roster system is used. Default is
          the flat file roster.

   --roster-file
          Define an alternative  location  for  the  default  roster  file
          location.  The default roster file is called roster and is found
          in the same directory as the master config file.

          New in version 2014.1.0.

   --refresh, --refresh-cache
          Force a refresh of the master side data cache  of  the  target's
          data.  This is needed if a target's grains have been changed and
          the auto refresh timeframe has not been reached.

   --max-procs
          Set the number of concurrent minions to communicate  with.  This
          value  defines  how  many  processes  are opened up at a time to
          manage  connections,  the  more  running  process   the   faster
          communication should be, default is 25.

   -i, --ignore-host-keys
          Disables  StrictHostKeyChecking  to  relax acceptance of new and
          unknown host keys.

   --no-host-keys
          Fully ignores ssh host keys which by  default  are  honored  and
          connections  would ask for approval. Useful if the host key of a
          remote  server  has  changed  and   would   still   error   with
          --ignore-host-keys.

   --passwd
          Set the default password to attempt to use when authenticating.

   --key-deploy
          Set  this  flag to attempt to deploy the authorized ssh key with
          all minions.  This  combined  with  --passwd  can  make  initial
          deployment of keys very fast and easy.

   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains the configuration files for Salt  master  and  minions.
          The default location on most systems is /etc/salt.

   Target Selection
   The  default matching that Salt utilizes is shell-style globbing around
   the                  minion                   id.                   See
   https://docs.python.org/2/library/fnmatch.html#module-fnmatch.

   -E, --pcre
          The  target  expression  will  be  interpreted as a PCRE regular
          expression rather than a shell glob.

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/ssh.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   Output Options
   --out  Pass  in an alternative outputter to display the return of data.
          This outputter can be any of the available outputters:
             grains, highstate, json, key,  overstatestage,  pprint,  raw,
             txt, yaml

          Some  outputters  are  formatted  only  for  data  returned from
          specific functions; for instance, the grains outputter will  not
          work for non-grains data.

          If  an  outputter  is used that does not support the data passed
          into it, then Salt will fall back on the  pprint  outputter  and
          display the return data using the Python pprint standard library
          module.

          NOTE:
             If using --out=json, you will probably want --static as well.
             Without  the  static  option,  you  will  get a separate JSON
             string per minion which makes JSON output invalid as a whole.
             This  is  due to using an iterative outputter. So if you want
             to feed it to a JSON parser, use --static as well.

   --out-indent OUTPUT_INDENT, --output-indent OUTPUT_INDENT
          Print the output indented  by  the  provided  value  in  spaces.
          Negative   values   disable   indentation.  Only  applicable  in
          outputters that support indentation.

   --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
          Write the output to the specified file.

   --no-color
          Disable all colored output

   --force-color
          Force colored output

          NOTE:
             When using colored output the color codes are as follows:

             green denotes success,  red  denotes  failure,  blue  denotes
             changes  and  success  and  yellow  denotes a expected future
             change in configuration.

   See also
   salt(7) salt-master(1) salt-minion(1)

   salt-syndic
   salt-syndic
   The Salt syndic daemon, a special minion that passes  through  commands
   from a higher master

   Synopsis
      salt-syndic [ options ]

   Description
   The  Salt  syndic daemon, a special minion that passes through commands
   from a higher master.

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   -u USER, --user=USER
          Specify user to run salt-syndic

   -d, --daemon
          Run salt-syndic as a daemon

   --pid-file PIDFILE
          Specify    the    location    of    the    pidfile.     Default:
          /var/run/salt-syndic.pid

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/master.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt(1) salt-master(1) salt-minion(1)

   salt-api
   salt-api
   Start interfaces used to remotely connect to the salt master

   Synopsis
      salt-api

   Description
   The Salt API system manages network api connectors for the Salt Master

   Options
   --version
          Print the version of Salt that is running.

   --versions-report
          Show program's dependencies and version number, and then exit

   -h, --help
          Show the help message and exit

   -c CONFIG_DIR, --config-dir=CONFIG_dir
          The location of the Salt configuration directory. This directory
          contains  the  configuration  files for Salt master and minions.
          The default location on most systems is /etc/salt.

   -d, --daemon
          Run the salt-api as a daemon

   --pid-file=PIDFILE
          Specify    the    location    of    the    pidfile.     Default:
          /var/run/salt-api.pid

   Logging Options
   Logging   options   which   override   any   settings  defined  on  the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/api.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   See also
   salt-api(7) salt(7) salt-master(1)

   spm
   spm
   Salt Package Manager

   Synopsis
      spm <command> [<argument>]

   Description
   spm is the  frontend  command  for  managing  Salt  packages.  Packages
   normally  only  include  formulas,  meaning  a  group of SLS files that
   install into the file_roots on the Salt Master, but  Salt  modules  can
   also be installed.

   Options
   -y, --assume-yes
          Assume  yes  instead  of  prompting  the other whether or not to
          proceed with a particular command. Default is False.

   -f, --force
          When presented with a course of action that spm  would  normally
          refuse to perform, that action will be performed anyway. This is
          often destructive, and should be used with caution.

   Logging Options
   Logging  options  which  override   any   settings   defined   on   the
   configuration files.

   -l LOG_LEVEL, --log-level=LOG_LEVEL
          Console  logging  log  level. One of all, garbage, trace, debug,
          info, warning, error, quiet. Default: warning.

   --log-file=LOG_FILE
          Log file path. Default: /var/log/salt/spm.

   --log-file-level=LOG_LEVEL_LOGFILE
          Logfile logging log level. One of all,  garbage,  trace,  debug,
          info, warning, error, quiet. Default: warning.

   Commands
   update_repo
          Connect  to remote repositories locally configured on the system
          and download their metadata.

   install
          Install a package from a configured SPM repository.  Requires  a
          package name.

   remove Remove  an installed package from the system. Requires a package
          name.

   info   List information about an installed package. Requires a  package
          name.

   files  List files belonging to an installed package. Requires a package
          name.

   local  Perform one of the  above  options  (except  for  remove)  on  a
          package  file,  instead  of  on a package in a repository, or an
          installed package. Requires a valid path to a local file on  the
          system.

   build  Build  a  package  from  a  directory containing a FORMULA file.
          Requires a valid path to a local directory on the system.

   create_repo
          Scan a directory for  valid  SPM  package  files  and  build  an
          SPM-METADATA file in that directory which describes them.

   See also
   salt(1) salt-master(1) salt-minion(1)

SALT MODULE REFERENCE

   This  section  contains  a  list of the Python modules that are used to
   extend the various subsystems within Salt.

   auth modules
                 
                 auto          An "Always Approved" eauth 
                               interface to test against, 
                               not intended for           
                 
                 django        Provide     authentication 
                               using Django Web Framework 
                 
                 keystone      Provide     authentication 
                               using OpenStack Keystone   
                 
                 ldap          Provide     authentication 
                               using simple LDAP binds    
                 
                 mysql         Provide     authentication 
                               using MySQL.               
                 

                 pam           Authenticate against PAM   
                 
                 pki           Authenticate  via  a   PKI 
                               certificate.               
                 
                 rest          Provide     authentication 
                               using a REST call          
                 
                 sharedsecret  Provide     authentication 
                               using   configured  shared 
                               secret                     
                 
                 stormpath     Provide     authentication 
                               using Stormpath.           
                 
                 yubico        Provide     authentication 
                               using YubiKey.             
                 

   salt.auth.auto
   An "Always Approved" eauth interface to test against, not intended  for
   production use

   salt.auth.auto.auth(username, password)
          Authenticate!

   salt.auth.django
   Provide authentication using Django Web Framework

   depends

          * Django Web Framework

   Django  authentication  depends on the presence of the django framework
   in the PYTHONPATH, the Django project's settings.py file being  in  the
   PYTHONPATH  and  accessible  via the DJANGO_SETTINGS_MODULE environment
   variable.

   Django auth can be defined like any other eauth module:

      external_auth:
        django:
          fred:
            - .*
            - '@runner'

   This will authenticate Fred  via  Django  and  allow  him  to  run  any
   execution module and all runners.

   The  authorization  details can optionally be located inside the Django
   database.  The relevant entry in the models.py  file  would  look  like
   this:

      class SaltExternalAuthModel(models.Model):
          user_fk = models.ForeignKey(auth.User)
          minion_matcher = models.CharField()
          minion_fn = models.CharField()

   The  external_auth  clause  in  the  master config would then look like
   this:

      external_auth:
        django:
          ^model: <fully-qualified reference to model class>

   When a user attempts to authenticate via Django, Salt will  import  the
   package  indicated  via  the  keyword ^model.  That model must have the
   fields indicated above, though the model DOES  NOT  have  to  be  named
   'SaltExternalAuthModel'.

   salt.auth.django.auth(username, password)
          Simple Django auth

   salt.auth.django.django_auth_setup()
          Prepare the connection to the Django authentication framework

   salt.auth.django.retrieve_auth_entries(u=None)

          Parameters
                 u -- Username to filter for

          Returns
                 Dictionary   that   can  be  slotted  into  the  __opts__
                 structure for eauth that designates the  user  associated
                 ACL

          Database records such as:

              
              username    minion_or_fn_matcher  minion_fn          
              
              fred                              test.ping          
              
              fred        server1               network.interfaces 
              
              fred        server1               raid.list          
              
              fred        server2               .*                 
              
              guru        .*                                       
              
              smartadmin  server1               .*                 
              

          Should result in an eauth config such as:

             fred:
               - test.ping
               - server1:
                   - network.interfaces
                   - raid.list
               - server2:
                   - .*
             guru:
               - .*
             smartadmin:
               - server1:
                 - .*

   salt.auth.keystone
   Provide authentication using OpenStack Keystone

   depends

          * keystoneclient Python module

   salt.auth.keystone.auth(username, password)
          Try and authenticate

   salt.auth.keystone.get_auth_url()
          Try and get the URL from the config, else return localhost

   salt.auth.ldap
   Provide authentication using simple LDAP binds

   depends

          * ldap Python module

   salt.auth.ldap.auth(username, password)
          Simple LDAP auth

   salt.auth.ldap.expand_ldap_entries(entries, opts=None)

          Parameters

                 * entries -- ldap subtree in external_auth config option

                 * opts -- Opts to use when __opts__ not defined

          Returns
                 Dictionary with all allowed operations

          Takes the ldap subtree in the external_auth  config  option  and
          expands it with actual minion names

          webadmins%: <all users in the AD 'webadmins' group>

                 *

                   server1

                          * .*

                 * ldap(OU=webservers,dc=int,dc=bigcompany,dc=com)       -
                   test.ping - service.restart

                 * ldap(OU=Domain Controllers,dc=int,dc=bigcompany,dc=com)
                   - allowed_fn_list_attribute^

          This  function  only  gets called if auth.ldap.activedirectory =
          True

   salt.auth.ldap.groups(username, **kwargs)
          Authenticate against an LDAP group

          Behavior is highly dependent on if Active Directory is in use.

          AD handles group membership very differently than OpenLDAP.  See
          the   External   Authentication  documentation  for  a  thorough
          discussion of available parameters for customizing the search.

          OpenLDAP allows you to search for all groups  in  the  directory
          and  returns members of those groups.  Then we check against the
          username entered.

   salt.auth.mysql
   Provide authentication using MySQL.

   When using MySQL as an authentication backend, you will need to  create
   or use an existing table that has a username and a password column.

   To  get started, create a simple table that holds just a username and a
   password. The password field will hold a SHA256 checksum.

      CREATE TABLE `users` (
        `id` int(11) NOT NULL AUTO_INCREMENT,
        `username` varchar(25) DEFAULT NULL,
        `password` varchar(70) DEFAULT NULL,
        PRIMARY KEY (`id`)
      ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;

   To create a user within MySQL, execute the following statement.

      INSERT INTO users VALUES (NULL, 'diana', SHA2('secret', 256))

      mysql_auth:
        hostname: localhost
        database: SaltStack
        username: root
        password: letmein
        auth_sql: 'SELECT username FROM users WHERE username = "{0}" AND password = SHA2("{1}", 256)'

   The auth_sql contains the SQL that will validate a user to ensure  they
   are  correctly  authenticated.  This is where you can specify other SQL
   queries to authenticate users.

   Enable MySQL authentication.

      external_auth:
        mysql:
          damian:
            - test.*

   depends

          * MySQL-python Python module

   salt.auth.mysql.auth(username, password)
          Authenticate using a MySQL user table

   salt.auth.pam
   Authenticate against PAM

   Provides an  authenticate  function  that  will  allow  the  caller  to
   authenticate  a user against the Pluggable Authentication Modules (PAM)
   on the system.

   Implemented using ctypes, so no compilation is necessary.

   There is one extra configuration option for pam.  The pam_service  that
   is authenticated against.  This defaults to login

      auth.pam.service: login

   NOTE:
      PAM authentication will not work for the root user.

      The Python interface to PAM does not support authenticating as root.

   class salt.auth.pam.PamConv
          Wrapper class for pam_conv structure

   class salt.auth.pam.PamHandle
          Wrapper class for pam_handle_t

   class salt.auth.pam.PamMessage
          Wrapper class for pam_message structure

   class salt.auth.pam.PamResponse
          Wrapper class for pam_response structure

   salt.auth.pam.auth(username, password, **kwargs)
          Authenticate via pam

   salt.auth.pam.authenticate(username, password)
          Returns True if the given username and password authenticate for
          the given service.  Returns False otherwise

          username: the username to authenticate

          password: the password in plain text

   salt.auth.pam.groups(username, *args, **kwargs)
          Retrieve groups for a given user for this auth provider

          Uses system groups

   salt.auth.pki
   Authenticate via a PKI certificate.

   NOTE:
      This module is Experimental and should be used with caution

   Provides an  authenticate  function  that  will  allow  the  caller  to
   authenticate  a  user  via  their  public  cert  against  a pre-defined
   Certificate Authority.

   TODO: Add a 'ca_dir' option to configure a directory of CA files, a  la
   Apache.

   depends

          * pyOpenSSL module

   salt.auth.pki.auth(username, password, **kwargs)
          Returns  True  if  the  given  user  cert  (password is the cert
          contents) was issued by the CA and  if  cert's  Common  Name  is
          equal to username.

          Returns False otherwise.

          username: we need it to run the auth function from CLI/API;
                 it should be in master config auth/acl

          password:  contents of user certificate (pem-encoded user public
          key);
                 why "password"? For CLI, it's the only available name

          Configure the CA cert in the master config file:

             external_auth:
               pki:
                 ca_file: /etc/pki/tls/ca_certs/trusted-ca.crt
                 your_user:
                   - .*

   salt.auth.rest module
   Provide authentication using a REST call

   REST auth can be defined like any other eauth module:

      external_auth:
        rest:
          ^url: https://url/for/rest/call
          fred:
            - .*
            - '@runner'

   If there are entries underneath the ^url entry  then  they  are  merged
   with  any responses from the REST call.  In the above example, assuming
   the  REST  call  does  not  return  any  additional  ACLs,  this   will
   authenticate  Fred  via  a REST call and allow him to run any execution
   module and all runners.

   The REST call should return a JSON object that maps to a regular  eauth
   YAML structure as above.

   salt.auth.rest.auth(username, password)
          REST authentication

   salt.auth.sharedsecret
   Provide authentication using configured shared secret

      external_auth:
        sharedsecret:
          fred:
            - .*
            - '@jobs'

   The  shared  secret  should  be  added to the master configuration, for
   example in /etc/salt/master.d/sharedsecret.conf (make sure that file is
   only readable by the user running the master):

      sharedsecret: OIUHF_CHANGE_THIS_12h88

   This auth module should be used with caution. It was initially designed
   to work with a frontal that takes care of authentication  (for  example
   kerberos)  and  places  the  shared  secret  in the HTTP headers to the
   salt-api call. This salt-api call should really be done on localhost to
   avoid someone eavesdropping on the shared secret.

   See  the  documentation  for  cherrypy  to  setup  the  headers in your
   frontal.

   New in version Beryllium.

   salt.auth.sharedsecret.auth(username, sharedsecret, **kwargs)
          Shared secret authentication

   salt.auth.stormpath
   Provide authentication using Stormpath.

   This  driver  requires  some  extra  configuration  beyond  that  which
   Stormpath normally requires.

      stormpath:
        apiid: 1234567890
        apikey: 1234567890/ABCDEF
        # Can use an application ID
        application: 6789012345
        # Or can use a directory ID
        directory: 3456789012
        # But not both

   New in version 2015.8.0.

   salt.auth.stormpath.auth(username, password)
          Authenticate using a Stormpath directory or application

   salt.auth.yubico
   Provide authentication using YubiKey.

   New in version 2015.5.0.

   depends
          yubico-client Python module

   To get your YubiKey API key you will need to visit the website below.

   https://upgrade.yubico.com/getapikey/

   The resulting page will show the generated Client ID (aka AuthID or API
   ID) and the generated API key (Secret Key). Make a note of both and use
   these two values in your /etc/salt/master configuration.
      /etc/salt/master

          yubico_users:
            damian:
              id: 12345
              key: ABCDEFGHIJKLMNOPQRSTUVWXYZ

          external_auth:
            yubico:
              damian:
                - test.*

   Please wait five to ten minutes after generating the key before testing
   so that the API key will be updated on all the YubiCloud servers.

   salt.auth.yubico.auth(username, password)
          Authenticate against yubico server

   beacon modules
               
               adb               Beacon to emit adb  device 
                                 state  changes for Android 
                                 devices                    
               
               avahi_announce    Beacon  to  announce   via 
                                 avahi (zeroconf)           
               
               bonjour_announce  Beacon   to  announce  via 
                                 Bonjour (zeroconf)         
               
               btmp              Beacon to fire  events  at 
                                 failed login of users      
               
               diskusage         Beacon   to  monitor  disk 
                                 usage.                     
               
               glxinfo           Beacon  to  emit  when   a 
                                 display  is available to a 
                                 linux machine              
               
               haproxy           Watch current  connections 
                                 of      haproxy     server 
                                 backends.                  
               
               inotify           Watch files and  translate 
                                 the   changes   into  salt 
                                 events                     
               
               journald          A simple beacon  to  watch 
                                 journald    for   specific 
                                 entries                    
               
               load              Beacon to emit system load 
                                 averages                   
               

               memusage          Beacon  to  monitor memory 
                                 usage.                     
               
               network_info      Beacon     to      monitor 
                                 statistics  from  ethernet 
                                 adapters                   
               
               network_settings  Beacon to monitor  network 
                                 adapter setting changes on 
                                 Linux                      
               
               pkg               Watch for pkgs  that  have 
                                 upgrades,   then  fire  an 
                                 event.                     
               
               proxy_example     Example beacon to use with 
                                 salt-proxy                 
               
               ps                Send    events    covering 
                                 service status             
               
               salt_proxy        Beacon   to   manage   and 
                                 report the status of       
               
               service           Send    events    covering 
                                 service status             
               
               sh                Watch the  shell  commands 
                                 being executed actively.   
               
               status            The   status   beacon   is 
                                 intended to send  a  basic 
                                 health  check  event up to 
                                 the  master,  this  allows 
                                 for  event driven routines 
                                 based on  presence  to  be 
                                 set up.                    
               
               twilio_txt_msg    Beacon to emit Twilio text 
                                 messages                   
               
               wtmp              Beacon to fire  events  at 
                                 login    of    users    as 
                                 registered  in  the   wtmp 
                                 file                       
               

   salt.beacons.adb module
   Beacon to emit adb device state changes for Android devices

   New in version 2016.3.0.

   salt.beacons.adb.beacon(config)
          Emit the status of all devices returned by adb

          Specify  the device states that should emit an event, there will
          be an event for each device  with  the  event  type  and  device
          specified.

             beacons:
               adb:
                 - states:
                     - offline
                     - unauthorized
                     - missing
                 - no_devices_event: True
                 - battery_low: 25

   salt.beacons.avahi_announce module
   Beacon to announce via avahi (zeroconf)

   New in version 2016.11.0.

   Dependencies
   * python-avahi

   * dbus-python

   salt.beacons.avahi_announce.beacon(config)
          Broadcast values via zeroconf

          If  the  announced  values  are  static,  it  is  adviced to set
          run_once: True (do not poll) on the beacon configuration.

          The following are required configuration settings:
                 'servicetype': The service type to announce.  'port': The
                 port  of  the service to announce.  'txt': The TXT record
                 of the service being announced as a dict.

                    Grains can be used to  define  TXT  values  using  the
                    syntax:
                           grains.<grain_name>

                    or:    grains.<grain_name>[i]

                    where  i  is  an integer representing the index of the
                    grain to use. If the grain is not a list, the index is
                    ignored.

          The following are optional configuration settings:

                 'servicename':  Set the name of the service. Will use the
                 hostname from
                        __grains__['host'] if not set.

                 'reset_on_change': If true and there is a change  in  TXT
                 records
                        detected,  it will stop announcing the service and
                        then  restart   announcing   the   service.   This
                        interruption   in   service  announcement  may  be
                        desirable if the client relies on changes  in  the
                        browse  records  to  update  its  cache of the TXT
                        records.  Defaults to False.

                 'reset_wait':  The  number  of  seconds  to  wait   after
                 announcement stops
                        announcing  and  before  it restarts announcing in
                        the case where there is a change  in  TXT  records
                        detected  and 'reset_on_change' is True.  Defaults
                        to 0.

                 'copy_grains': If set to True, it will  copy  the  grains
                 passed into
                        the  beacon  when  it  backs  them up to check for
                        changes on the next iteration.  Normally,  instead
                        of  copy,  it would use straight value assignment.
                        This will allow detection  of  changes  to  grains
                        where  the grains are modified in-place instead of
                        completely replaced.  In-place grains changes  are
                        not  currently  done in the main Salt code but may
                        be done due to  a  custom  plug-in.   Defaults  to
                        False.

          Example Config

             beacons:
               avahi_announce:
                 run_once: True
                 servicetype: _demo._tcp
                 port: 1234
                 txt:
                   ProdName: grains.productname
                   SerialNo: grains.serialnumber
                   Comments: 'this is a test'

   salt.beacons.bonjour_announce module
   Beacon to announce via Bonjour (zeroconf)

   salt.beacons.bonjour_announce.beacon(config)
          Broadcast values via zeroconf

          If  the  announced  values  are  static,  it  is  adviced to set
          run_once: True (do not poll) on the beacon configuration.

          The following are required configuration settings:
                 'servicetype': The service type to announce.  'port': The
                 port  of  the service to announce.  'txt': The TXT record
                 of the service being announced as a dict.

                    Grains can be used to  define  TXT  values  using  the
                    syntax:
                           grains.<grain_name>

                    or:    grains.<grain_name>[i]

                    where  i  is  an integer representing the index of the
                    grain to use. If the grain is not a list, the index is
                    ignored.

          The following are optional configuration settings:

                 'servicename':  Set the name of the service. Will use the
                 hostname from
                        __grains__['host'] if not set.

                 'reset_on_change': If true and there is a change  in  TXT
                 records
                        detected,  it will stop announcing the service and
                        then  restart   announcing   the   service.   This
                        interruption   in   service  announcement  may  be
                        desirable if the client relies on changes  in  the
                        browse  records  to  update  its  cache of the TXT
                        records.  Defaults to False.

                 'reset_wait':  The  number  of  seconds  to  wait   after
                 announcement stops
                        announcing  and  before  it restarts announcing in
                        the case where there is a change  in  TXT  records
                        detected  and 'reset_on_change' is True.  Defaults
                        to 0.

                 'copy_grains': If set to True, it will  copy  the  grains
                 passed into
                        the  beacon  when  it  backs  them up to check for
                        changes on the next iteration.  Normally,  instead
                        of  copy,  it would use straight value assignment.
                        This will allow detection  of  changes  to  grains
                        where  the grains are modified in-place instead of
                        completely replaced.  In-place grains changes  are
                        not  currently  done in the main Salt code but may
                        be done due to  a  custom  plug-in.   Defaults  to
                        False.

          Example Config

             beacons:
               bonjour_announce:
                 run_once: True
                 servicetype: _demo._tcp
                 port: 1234
                 txt:
                   ProdName: grains.productname
                   SerialNo: grains.serialnumber
                   Comments: 'this is a test'

   salt.beacons.btmp
   Beacon to fire events at failed login of users

      beacons:
        btmp: {}

   salt.beacons.btmp.beacon(config)
          Read  the  last  btmp  file and return information on the failed
          logins

             beacons:
               btmp: {}

   salt.beacons.diskusage
   Beacon to monitor disk usage.

   New in version 2015.5.0.

   depends
          python-psutil

   salt.beacons.diskusage.beacon(config)
          Monitor the disk usage of the minion

          Specify thresholds for each disk and only emit a beacon  if  any
          of them are exceeded.

             beacons:
               diskusage:
                 - /: 63%
                 - /mnt/nfs: 50%

          Windows drives must be quoted to avoid yaml syntax errors

             beacons:
               diskusage:
                 -  interval: 120
                 - 'c:': 90%
                 - 'd:': 50%

   salt.beacons.glxinfo module
   Beacon to emit when a display is available to a linux machine

   New in version 2016.3.0.

   salt.beacons.glxinfo.beacon(config)
          Emit the status of a connected display to the minion

          Mainly  this is used to detect when the display fails to connect
          for whatever reason.

             beacons:
               glxinfo:
                 user: frank
                 screen_event: True

   salt.beacons.haproxy module
   Watch current connections of haproxy server backends.   Fire  an  event
   when over a specified threshold.

   New in version 2016.11.0.

   salt.beacons.haproxy.beacon(config)
          Check  if  current number of sessions of a server for a specific
          haproxy backend is over a defined threshold.

             beacons:
               haproxy:
                 - www-backend:
                     threshold: 45
                     servers:
                       - web1
                       - web2
                 - interval: 120

   salt.beacons.inotify
   Watch files and translate the changes into salt events

   depends

          * pyinotify Python module >= 0.9.5

   Caution
          Using generic mask  options  like  open,  access,  ignored,  and
          closed_nowrite  with  reactors  can  easily cause the reactor to
          loop on itself. To mitigate this behavior, consider setting  the
          disable_during_state_run    flag   to   True   in   the   beacon
          configuration.

   note   The inotify beacon only works on OSes that have  inotify  kernel
          support.   Currently  this  excludes  FreeBSD,  Mac  OS  X,  and
          Windows.

   salt.beacons.inotify.beacon(config)
          Watch the configured files

          Example Config

             beacons:
               inotify:
                 /path/to/file/or/dir:
                   mask:
                     - open
                     - create
                     - close_write
                   recurse: True
                   auto_add: True
                   exclude:
                     - /path/to/file/or/dir/exclude1
                     - /path/to/file/or/dir/exclude2
                     - /path/to/file/or/dir/regex[a-m]*$:
                         regex: True

          The mask list can contain the following events (the default mask
          is create, delete, and modify):

          * access            - File accessed

          * attrib            - File metadata changed

          * close_nowrite     - Unwritable file closed

          * close_write       - Writable file closed

          * create            - File created in watched directory

          * delete            - File deleted from watched directory

          * delete_self       - Watched file or directory deleted

          * modify            - File modified

          * moved_from        - File moved out of watched directory

          * moved_to          - File moved into watched directory

          * move_self         - Watched file moved

          * open              - File opened

          The mask can also contain the following options:

          * dont_follow       - Don't dereference symbolic links

          * excl_unlink        -  Omit events for children after they have
            been unlinked

          * oneshot           - Remove watch after one event

          * onlydir           - Operate only if name is directory

          recurse:
                 Recursively watch files in the directory

          auto_add:
                 Automatically start watching files that  are  created  in
                 the watched directory

          exclude:
                 Exclude  directories  or  files from triggering events in
                 the watched directory.  Can use regex if regex is set  to
                 True

   salt.beacons.journald
   A simple beacon to watch journald for specific entries

   salt.beacons.journald.beacon(config)
          The  journald beacon allows for the systemd journal to be parsed
          and linked objects to be turned into events.

          This beacons config will return all sshd jornal entries

             beacons:
               journald:
                 sshd:
                   SYSLOG_IDENTIFIER: sshd
                   PRIORITY: 6

   salt.beacons.load
   Beacon to emit system load averages

   salt.beacons.load.beacon(config)
          Emit the load averages of this host.

          Specify thresholds for each load average and only emit a  beacon
          if any of them are exceeded.

          onchangeonly:  when  onchangeonly  is  True the beacon will fire
          events  only  when  the  load  average   pass   one   threshold.
          Otherwise,  it  will fire an event at each beacon interval.  The
          default is False.

          emitatstartup: when emitatstartup is False the beacon  will  not
          fire
                 event  when  the  minion  is reload. Applicable only when
                 onchangeonly is True.  The default is True.

             beacons:
               load:
                 1m:
                   - 0.0
                   - 2.0
                 5m:
                   - 0.0
                   - 1.5
                 15m:
                   - 0.1
                   - 1.0
                 emitatstartup: True
                 onchangeonly: False

   salt.beacons.memusage module
   Beacon to monitor memory usage.

   New in version 2016.3.0.

   depends
          python-psutil

   salt.beacons.memusage.beacon(config)
          Monitor the memory usage of the minion

          Specify thresholds for percent used and only emit a beacon if it
          is exceeded.

             beacons:
               memusage:
                 - percent: 63%

   salt.beacons.network_info
   Beacon to monitor statistics from ethernet adapters

   New in version 2015.5.0.

   salt.beacons.network_info.beacon(config)
          Emit the network statistics of this host.

          Specify  thresholds for each network stat and only emit a beacon
          if any of them are exceeded.

          Emit beacon when any values are equal to configured values.

             beacons:
               network_info:
                 eth0:
                     - type: equal
                     - bytes_sent: 100000
                     - bytes_recv: 100000
                     - packets_sent: 100000
                     - packets_recv: 100000
                     - errin: 100
                     - errout: 100
                     - dropin: 100
                     - dropout: 100

          Emit beacon when any values are greater than configured values.

             beacons:
               network_info:
                 eth0:
                     - type: greater
                     - bytes_sent: 100000
                     - bytes_recv: 100000
                     - packets_sent: 100000
                     - packets_recv: 100000
                     - errin: 100
                     - errout: 100
                     - dropin: 100
                     - dropout: 100

   salt.beacons.network_settings
   Beacon to monitor network adapter setting changes on Linux

   New in version 2016.3.0.

   class salt.beacons.network_settings.Hashabledict
          Helper class that implements a hash function for a dictionary

   salt.beacons.network_settings.beacon(config)
          Watch for changes on network settings

          By default, the beacon will emit when there is a value change on
          one  of  the  settings  on  watch.  The  config also support the
          onvalue parameter for each setting, which instruct the beacon to
          only emit if the setting changed to the value defined.

          Example Config

             beacons:
               network_settings:
                 eth0:
                   ipaddr:
                   promiscuity:
                     onvalue: 1
                 eth1:
                   linkmode:

          The config above will check for value changes on eth0 ipaddr and
          eth1 linkmode. It  will  also  emit  if  the  promiscuity  value
          changes to 1.

          Beacon  items  can use the * wildcard to make a definition apply
          to several interfaces. For example an eth* would  apply  to  all
          ethernet interfaces.

          Setting the argument coalesce = True will combine all the beacon
          results on a single event.   The  example  below  shows  how  to
          trigger coalesced results:

             beacons:
               network_settings:
                 coalesce: True
                 eth0:
                   ipaddr:
                   promiscuity:

   salt.beacons.pkg
   Watch for pkgs that have upgrades, then fire an event.

   New in version 2016.3.0.

   salt.beacons.pkg.beacon(config)
          Check  if installed packages are the latest versions and fire an
          event for those that have upgrades.

             beacons:
               pkg:
                 - pkgs:
                     - zsh
                     - apache2
                 - refresh: True

   salt.beacons.proxy_example module
   Example beacon to use with salt-proxy

      beacons:
        proxy_example:
          endpoint: beacon

   salt.beacons.proxy_example.beacon(config)
          Called         several         times         each         second
          https://docs.saltstack.com/en/latest/topics/beacons/#the-beacon-function

             beacons:
               proxy_example:
                 endpoint: beacon

   salt.beacons.ps module
   Send events covering service status

   salt.beacons.ps.beacon(config)
          Scan for processes and fire events

          Example Config

             beacons:
               ps:
                 salt-master: running
                 mysql: stopped

          The config above sets up beacons to  check  that  processes  are
          running or stopped.

   salt.beacons.salt_proxy module
   Beacon  to  manage  and  report  the  status  of one or more salt proxy
   processes

   New in version 2015.8.3.

   salt.beacons.salt_proxy.beacon(proxies)
          Handle configured proxies

             beacons:
               salt_proxy:
                 - p8000: {}
                 - p8001: {}

   salt.beacons.service
   Send events covering service status

   salt.beacons.service.beacon(config)
          Scan for the configured services and fire events

          Example Config

             beacons:
               service:
                 salt-master:
                 mysql:

          The config above sets up beacons to check  for  the  salt-master
          and mysql services.

          The config also supports two other parameters for each service:

          onchangeonly:  when  onchangeonly  is  True the beacon will fire
          events only when the service status changes.  Otherwise, it will
          fire an event at each beacon interval.  The default is False.

          emitatstartup:  when  emitatstartup is False the beacon will not
          fire event when the  minion  is  reload.  Applicable  only  when
          onchangeonly is True.  The default is True.

          uncleanshutdown:  If  uncleanshutdown is present it should point
          to the location of a pid file for the  service.   Most  services
          will  not  clean up this pid file if they are shutdown uncleanly
          (e.g. via kill -9) or if they are  terminated  through  a  crash
          such  as a segmentation fault.  If the file is present, then the
          beacon will add uncleanshutdown: True  to  the  event.   If  not
          present,  the field will be False.  The field is only added when
          the service is NOT running. Omitting the configuration  variable
          altogether will turn this feature off.

          Please  note  that  some init systems can remove the pid file if
          the service registers as crashed. One such example is  nginx  on
          CentOS  7,  where the service unit removes the pid file when the
          service shuts down (IE: the pid file is observed as removed when
          kill   -9   is   sent   to   the   nginx  master  process).  The
          'uncleanshutdown' option might not be of much use there,  unless
          the unit file is modified.

          Here is an example that will fire an event whenever the state of
          nginx changes and report an uncleanshutdown.   This  example  is
          for Arch, which places nginx's pid file in /run.

             beacons:
               service:
                 nginx:
                   onchangeonly: True
                   uncleanshutdown: /run/nginx.pid

   salt.beacons.sh
   Watch  the shell commands being executed actively. This beacon requires
   strace.

   salt.beacons.sh.beacon(config)
          Scan the shell execve routines. This  beacon  will  convert  all
          login shells

             beacons:
               sh: {}

   salt.beacons.status module
   The  status beacon is intended to send a basic health check event up to
   the master, this allows for event driven routines based on presence  to
   be set up.

   The  intention  of  this  beacon  is  to  add the config options to add
   monitoring stats to the health beacon making it a  one  stop  shop  for
   gathering systems health and status data

   New in version 2016.11.0.

   To  configure this beacon to use the defaults, set up an empty dict for
   it in the minion config:

      beacons:
        status: {}

   By default, all of the information from the following execution  module
   functions will be returned:

      * loadavg

      * cpustats

      * meminfo

      * vmstats

      * time

   You can also configure your own set of functions to be returned:

      beacons:
        status:
          - time:
            - all
          - loadavg:
            - all

   You  may  also  configure  only certain fields from each function to be
   returned.  For instance, the loadavg  function  returns  the  following
   fields:

      * 1-min

      * 5-min

      * 15-min

   If  you  wanted  to  return only the 1-min and 5-min fields for loadavg
   then you would configure:

      beacons:
        status:
          - loadavg:
            - 1-min
            - 5-min

   Other functions only return a single value  instead  of  a  dictionary.
   With these, you may specify all or 0. The following are both valid:

      beacons:
        status:
          - time:
            - all

      beacons:
        status:
          - time:
            - 0

   If a status function returns a list, you may return the index marker or
   markers for specific list items:

      beacons:
        status:
          - w:
            - 0
            - 1
            - 2

   salt.beacons.status.beacon(config)
          Return status for requested information

   salt.beacons.twilio_txt_msg
   Beacon to emit Twilio text messages

   salt.beacons.twilio_txt_msg.beacon(config)
          Emit a dict name "texts" whose value is a list of texts.

             beacons:
               twilio_txt_msg:
                 account_sid: "<account sid>"
                 auth_token: "<auth token>"
                 twilio_number: "+15555555555"
                 interval: 10

   salt.beacons.wtmp
   Beacon to fire events at login of users as registered in the wtmp file

      beacons:
        wtmp: {}

   salt.beacons.wtmp.beacon(config)
          Read the last wtmp file and return information on the logins

             beacons:
               wtmp: {}

   engine modules
                
                 docker_events    Send  events  from  Docker
                                  events
                
                 http_logstash    HTTP Logstash engine
                
                 logentries       An   engine   that   sends
                                  events to  the  Logentries
                                  logging service.
                
                 logstash         An   engine   that   reads
                                  messages  from  the   salt
                                  event  bus and pushes them
                                  onto a logstash endpoint.
                
                 reactor          Setup Reactor
                
                 redis_sentinel   An   engine   that   reads
                                  messages  from  the  redis
                                  sentinel pubsub and  sends
                                  reactor  events  based  on
                                  the  channels   they   are
                                  subscribed to.
                
                 slack            An   engine   that   reads
                                  messages  from  Slack  and
                                  sends  them  to  the  Salt
                                  event bus.
                
                 sqs_events       An       engine       that
                                  continuously         reads
                                  messages  from   SQS   and
                                  fires them as events.
                
                 test             A  simple test engine, not
                                  intended for real use  but
                                  as an example
                
                 thorium          Manage the Thorium complex
                                  event reaction system
                
                                                           
   salt.engines.docker_events module                            
   Send events from Docker events :Depends:   Docker API >= 1.22
                                                           
   salt.engines.docker_events.start(docker_url='unix://var/run/docker.sock',
   timeout=60, tag='salt/engines/docker_events')             
          Scan for Docker eventsand fire events             
                                                           
          Example Config                                    
                                                           
             engines:                                       
               docker_events:                               
                docker_url: unix://var/run/docker.sock      
                                                           
          The  config  above sets up engines to listen for events from the
          Dockerdaemon and publish them to the Salt event bus.
                                                           
   salt.engines.http_logstash                                   
   HTTP Logstash engine                                         
   An engine that reads messagesfrom the salt event bus and pushes  them
   onto a logstash endpoint via HTTP requests.               
                                                           
   configuration                                           
          Example configuration                             
                                                           
             engines:                                       
               -http_logstash:                             
                    url: http://blabla.com/salt-stuff       
                    tags:                                  
                        - salt/job/*/new                    
                        - salt/job/*/ret/*                  
                    funs:                                  
                        - probes.results                    
                        - bgp.config                        
                                                           
   salt.engines.http_logstash.start(url, funs=None, tags=None)
          Listento salt events and forward them to logstash via HTTP.
                                                           
   salt.engines.logentries                                      
   An engine that sends events to the Logentries logging service.
                                                           
   maintainer                                              
          Jimmy Tang (jimmy_tang@rapid7.com)                 
                                                           
   maturity                                                
          New                                              
                                                           
   depends                                                 
          ssl, certifi                                      
                                                           
   platform                                                
          all                                              
                                                           
   To  enable this engine the master and/or minion will need the following
   python libraries                                         
      ssl certifi                                           
                                                           
   If you are running a new enough version of python then thessl  library
   will be present already.                                 
                                                           
   You  will  also  need  the following values configured in the minion or
   master config.                                           
                                                           
   configuration                                           
                                                           
          Example configuration                             
                                                           
                engines:                                   
                                                           
                       * logentries: endpoint: data.logentries.com  port:
                         10000                                   token:
                         057af3e2-1c05-47c5-882a-5cd644655dbf
                                                           
   The 'token' can be obtained from the Logentries service.  
                                                           
   To test this engine                                      
                                                           
          salt '*' test.ping cmd.run uptime                  
                                                           
   salt.engines.logentries.start(endpoint='data.logentries.com',
   port=10000, token=None, tag='salt/engines/logentries')    
          Listento salt events and forward them to Logentries
                                                           
   salt.engines.logstash                                        
   An  engine  that reads messages from the salt event bus and pushes them
   onto a logstash endpoint.                                
                                                           
   configuration                                           
                                                           
          Example configuration                             
                                                           
                engines:                                   
                                                           
                       * logstash: host: log.my_network.com port: 5959
                                                           
   depends                                                 
          logstash                                          
                                                           
   salt.engines.logstash.start(host,                           port=5959,
   tag='salt/engine/logstash')                              
          Listento salt events and forward them to logstash 
                                                           
   salt.engines.reactor module                                  
   Setup Reactor                                           
                                                           
   Example Config in Master or Minion config                 
                                                           
      engines:                                             
        reactor:                                           
          refresh_interval: 60                              
          workerthreads: 10                                
          workerhwm: 10000                                 
                                                           
      reactor:                                             
        - 'salt/cloud/*/destroyed':                          
          - /srv/reactor/destroy/*.sls                       
                                                           
   salt.engines.redis_sentinel module                            
   An  engine that reads messages from the redis sentinel pubsub and sends
   reactor events based on the channels they are subscribed to.

   configuration

          Example configuration

                 engines:

                        *

                          redis_sentinel:

                                 hosts: matching:  'board*'  port:   26379
                                        interface: eth2

                                 channels:

                                        * '+switch-master'

                                        * '+odown'

                                        * '-odown'

   depends
          redis

   salt.engines.slack module
   An  engine  that  reads  messages from Slack and sends them to the Salt
   event bus.  Alternatively Salt commands can be sent to the Salt  master
   via  Slack  by  setting the control parameter to True and using command
   prefaced with a !.

   configuration
          Example configuration

             engines:
                 slack:
                    token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'
                    control: True
                    valid_users:
                        - garethgreenaway
                    valid_commands:
                        - test.ping
                        - cmd.run
                        - list_jobs
                        - list_commands
                    aliases:
                        list_jobs:
                            cmd: jobs.list_jobs
                        list_commands:
                            cmd: pillar.get salt:engines:slack:valid_commands target=saltmaster

   depends
          slackclient

   salt.engines.slack.start(token,     aliases=None,     valid_users=None,
   valid_commands=None,             control=False,            trigger='!',
   tag='salt/engines/slack')
          Listen to Slack events and forward them to Salt

   salt.engines.sqs_events
   An engine that continuously reads messages from SQS and fires  them  as
   events.

   Note that long polling is utilized to avoid excessive CPU usage.

   New in version 2015.8.0.

   depends
          boto

   Configuration
   This engine can be run on the master or on a minion.

   Example Config:

      sqs.keyid: GKTADJGHEIQSXMKKRBJ08H
      sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
      sqs.message_format: json

   Explicit  sqs credentials are accepted but this engine can also utilize
   IAM roles assigned to the instance through Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More Information available at:

      http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

   If IAM roles are not (or for boto version < 2.5.1)  used  you  need  to
   specify  them either in a pillar or in the config file of the master or
   minion, as appropriate:

   To deserialize the message from json:

      sqs.message_format: json

   It's also possible to specify key, keyid and region via a profile:

      sqs.keyid: GKTADJGHEIQSXMKKRBJ08H
      sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   A region may also be specified in the configuration:

      sqs.region: us-east-1

   If a region is not specified, the default is us-east-1.

   It's also possible to specify key, keyid and region via a profile:

      myprofile:
        keyid: GKTADJGHEIQSXMKKRBJ08H
        key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
        region: us-east-1

   Additionally you can define cross account sqs:

      engines:
        - sqs_events:
            queue: prod
            owner_acct_id: 111111111111

   salt.engines.sqs_events.start(queue,                      profile=None,
   tag='salt/engine/sqs', owner_acct_id=None)
          Listen to sqs and fire message on event bus

   salt.engines.test
   A simple test engine, not intended for real use but as an example

   salt.engines.test.start()
          Listen to events and write them to a log file

   salt.engines.thorium module
   Manage the Thorium complex event reaction system

   salt.engines.thorium.start(grains=False, grain_keys=None, pillar=False,
   pillar_keys=None)
          Execute the Thorium runtime

   fileserver modules
                   
                   azurefs   The  backend  for  serving 
                             files  from the Azure blob 
                             storage service.           
                   
                   gitfs     Git Fileserver Backend     
                   
                   hgfs      Mercurial       Fileserver 
                             Backend                    
                   
                   minionfs  Fileserver  backend  which 
                             serves files pushed to the 
                             Master                     
                   
                   roots     The  default  file  server 
                             backend                    
                   

                   s3fs      Amazon    S3    Fileserver 
                             Backend                    
                   
                   svnfs     Subversion      Fileserver 
                             Backend                    
                   

   salt.fileserver.azurefs
   The backend for serving files from the Azure blob storage service.

   To enable, add azurefs to the fileserver_backend option in  the  Master
   config file.

      fileserver_backend:
        - azurefs

   Each  environment is configured as a storage container. The name of the
   container must match the name of the environment.  The  storage_account
   is  the  name  of  the storage account inside Azure where the container
   lives, and the storage_key is the access  key  used  for  that  storage
   account:

      azurefs_envs:
        base:
          storage_account: my_storage
          storage_key: frehgfw34fWGegG07fwsfw343tGFDSDGDFGD==

   With  this  configuration, multiple storage accounts can be used with a
   single salt instrastructure.

   salt.fileserver.gitfs
   Git Fileserver Backend

   With this backend, branches and tags in a  remote  git  repository  are
   exposed to salt as different environments.

   To  enable,  add  git  to  the  fileserver_backend option in the Master
   config file.

      fileserver_backend:
        - git

   As of Salt 2014.7.0, the Git  fileserver  backend  supports  GitPython,
   pygit2,  and  dulwich  to  provide the Python interface to git. If more
   than one of these are present, the order of preference  for  which  one
   will  be  chosen  is  the  same as the order in which they were listed:
   pygit2, GitPython, dulwich (keep in mind,  this  order  is  subject  to
   change).

   An  optional  master  config  parameter (gitfs_provider) can be used to
   specify which provider should be used.

   More detailed information on how to use gitfs can be found in the Gitfs
   Walkthrough.

   NOTE:
      Minimum requirements

      To  use  GitPython for gitfs requires a minimum GitPython version of
      0.3.0, as well as the git CLI utility. Instructions  for  installing
      GitPython can be found here.

      To use pygit2 for gitfs requires a minimum pygit2 version of 0.20.3.
      pygit2 0.20.3  requires  libgit2  0.20.0.  pygit2  and  libgit2  are
      developed  alongside  one another, so it is recommended to keep them
      both at the same major release to  avoid  unexpected  behavior.  For
      example,  pygit2  0.21.x requires libgit2 0.21.x, pygit2 0.22.x will
      require libgit2 0.22.x, etc.

      To find stale refs, pygit2 additionally requires the git CLI utility
      to be installed.

   salt.fileserver.hgfs
   Mercurial Fileserver Backend

   To enable, add hg to the fileserver_backend option in the Master config
   file.

      fileserver_backend:
        - hg

   After enabling this backend, branches, bookmarks, and tags in a  remote
   mercurial  repository  are  exposed  to salt as different environments.
   This feature is managed by the fileserver_backend option  in  the  salt
   master config file.

   This  fileserver  has an additional option hgfs_branch_method that will
   set  the  desired  branch  method.  Possible  values   are:   branches,
   bookmarks,  or  mixed.  If  using branches or mixed, the default branch
   will be mapped to base.

   Changed in version 2014.1.0: The hgfs_base master config parameter  was
   added, allowing for a branch other than default to be used for the base
   environment, and allowing for a base environment to be  specified  when
   using an hgfs_branch_method of bookmarks.

   depends

          * mercurial

          * python bindings for mercurial (python-hglib)

   salt.fileserver.minionfs
   Fileserver backend which serves files pushed to the Master

   The  cp.push  function  allows  Minions to push files up to the Master.
   Using this backend, these pushed files are exposed to other Minions via
   the Salt fileserver.

   To  enable  minionfs,  file_recv  needs to be set to True in the master
   config file (otherwise cp.push will not be allowed to push files to the
   Master), and minion must be added to the fileserver_backends list.

      fileserver_backend:
        - minion

   Other      minionfs      settings      include:     minionfs_whitelist,
   minionfs_blacklist, minionfs_mountpoint, and minionfs_env.

   SEE ALSO:
      tutorial-minionfs

   salt.fileserver.roots
   The default file server backend

   This  fileserver  backend  serves  files  from   the   Master's   local
   filesystem.  If  fileserver_backend is not defined in the Master config
   file, then this backend is enabled by default. If it  is  defined  then
   roots must be in the fileserver_backend list to enable this backend.

      fileserver_backend:
        - roots

   Fileserver  environments are defined using the file_roots configuration
   option.

   salt.fileserver.s3fs
   Amazon S3 Fileserver Backend

   This backend exposes directories in S3 buckets as Salt environments. To
   enable  this  backend, add s3fs to the fileserver_backend option in the
   Master config file.

      fileserver_backend:
        - s3fs

   S3 credentials must also be set in the master config file:

      s3.keyid: GKTADJGHEIQSXMKKRBJ08H
      s3.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   Alternatively, if on EC2 these credentials can be automatically  loaded
   from instance metadata.

   This fileserver supports two modes of operation for the buckets:

   1. A single bucket per environment

         s3.buckets:
           production:
             - bucket1
             - bucket2
           staging:
             - bucket3
             - bucket4

   2. Multiple environments per bucket

         s3.buckets:
           - bucket1
           - bucket2
           - bucket3
           - bucket4

   Note  that  bucket  names must be all lowercase both in the AWS console
   and in Salt, otherwise you may encounter SignatureDoesNotMatch errors.

   A  multiple-environment  bucket  must  adhere  to  the  following  root
   directory structure:

      s3://<bucket name>/<environment>/<files>

   NOTE:
      This  fileserver  back-end  requires  the  use  of  the  MD5 hashing
      algorithm.  MD5 may not be compliant with all security policies.

   salt.fileserver.svnfs
   Subversion Fileserver Backend

   After enabling this backend, branches, and tags in a remote  subversion
   repository  are  exposed  to  salt as different environments. To enable
   this backend, add svn to the fileserver_backend option  in  the  Master
   config file.

      fileserver_backend:
        - svn

   This  backend  assumes  a  standard  svn  layout  with  directories for
   branches, tags, and trunk, at the repository root.

   depends

          * subversion

          * pysvn

   Changed in version 2014.7.0: The paths to the trunk, branches, and tags
   have  been  made  configurable,  via  the  config  options svnfs_trunk,
   svnfs_branches,  and  svnfs_tags.   svnfs_mountpoint  was  also  added.
   Finally, support for per-remote configuration parameters was added. See
   the documentation for more information.

   grains modules
                 
                 chronos      Generate   chronos   proxy 
                              minion grains.             
                 
                 core         The  static  grains, these 
                              are the core, or built  in 
                              grains.                    
                 
                 disks        Detect disks               
                 
                 esxi         Generate   baseline  proxy 
                              minion  grains  for   ESXi 
                              hosts.                     
                 
                 extra                                   
                 
                 fx2          Generate   baseline  proxy 
                              minion grains for Dell FX2 
                              chassis.                   
                 
                 junos        Grains for junos.          
                 
                 marathon     Generate   marathon  proxy 
                              minion grains.             
                 
                 mdadm        Detect MDADM RAIDs         
                 
                 opts         Simple grain to merge  the 
                              opts   into   the   grains 
                              directly if the grain_opts 
                 
                 philips_hue  Static  grains   for   the 
                              Philips HUE lamps          
                 
                 rest_sample  Generate   baseline  proxy 
                              minion grains              
                 

   salt.grains.chronos
   Generate chronos proxy minion grains.

   New in version 2015.8.2.

   salt.grains.core
   The static grains, these are the core, or built in grains.

   When grains are loaded they are not loaded in the same way that modules
   are  loaded,  grain  functions are detected and executed, the functions
   MUST return a dict which will be applied to the main grains dict.  This
   module will always be executed first, so that any grains loaded here in
   the core module can be overwritten just by returning dict keys with the
   same value as those returned here

   salt.grains.core.append_domain()
          Return append_domain if set

   salt.grains.core.dns()
          Parse the resolver configuration file
             New in version 2016.3.0.

   salt.grains.core.get_machine_id()
          Provide the machine-id

   salt.grains.core.get_master()
          Provides the minion with the name of its master.  This is useful
          in states to target other services running on the master.

   salt.grains.core.get_server_id()
          Provides an integer based on the FQDN of a machine.   Useful  as
          server-id  in  MySQL replication or anywhere else you'll need an
          ID like this.

   salt.grains.core.hostname()
          Return fqdn, hostname, domainname

   salt.grains.core.hwaddr_interfaces()
          Provide  a  dict  of  the  connected  interfaces  and  their  hw
          addresses (Mac Address)

   salt.grains.core.id_()
          Return the id

   salt.grains.core.ip4_interfaces()
          Provide  a  dict  of  the  connected  interfaces  and  their ip4
          addresses The addresses will  be  passed  as  a  list  for  each
          interface

   salt.grains.core.ip6_interfaces()
          Provide  a  dict  of  the  connected  interfaces  and  their ip6
          addresses The addresses will  be  passed  as  a  list  for  each
          interface

   salt.grains.core.ip_fqdn()
          Return ip address and FQDN grains

   salt.grains.core.ip_interfaces()
          Provide  a  dict  of  the  connected  interfaces  and  their  ip
          addresses The addresses will  be  passed  as  a  list  for  each
          interface

   salt.grains.core.locale_info()

          Provides
                 defaultlanguage defaultencoding

   salt.grains.core.os_data()
          Return grains pertaining to the operating system

   salt.grains.core.path()
          Return the path

   salt.grains.core.pythonexecutable()
          Return the python executable in use

   salt.grains.core.pythonpath()
          Return the Python path

   salt.grains.core.pythonversion()
          Return the Python version

   salt.grains.core.saltpath()
          Return the path of the salt module

   salt.grains.core.saltversion()
          Return the version of salt

   salt.grains.core.saltversioninfo()
          Return the version_info of salt
             New in version 0.17.0.

   salt.grains.core.zmqversion()
          Return the zeromq version

   salt.grains.disks
   Detect disks

   salt.grains.disks.disks()
          Return list of disk devices

   salt.grains.esxi
   Generate baseline proxy minion grains for ESXi hosts.

   ., versionadded:: 2015.8.4

   salt.grains.extra
   salt.grains.extra.config()
          Return the grains set in the grains file

   salt.grains.extra.shell()
          Return the default shell to use on this system

   salt.grains.fx2
   Generate  baseline  proxy  minion  grains  for  Dell  FX2 chassis.  The
   challenge is that most of Salt isn't bootstrapped yet, so  we  need  to
   repeat   a   bunch   of   things   that   would   normally   happen  in
   proxy/fx2.py--just enough to get data from the chassis  to  include  in
   grains.

   salt.grains.junos
   Grains for junos.  NOTE this is a little complicated--junos can only be
   accessed via salt-proxy-minion.Thus, some grains make sense to get them
   from the minion (PYTHONPATH), but others don't (ip_interfaces)

   salt.grains.marathon
   Generate marathon proxy minion grains.

   New in version 2015.8.2.

   salt.grains.mdadm
   Detect MDADM RAIDs

   salt.grains.mdadm.mdadm()
          Return list of mdadm devices

   salt.grains.opts
   Simple  grain  to  merge  the  opts  into  the  grains  directly if the
   grain_opts configuration value is set

   salt.grains.opts.opts()
          Return the minion configuration settings

   salt.grains.philips_hue
   Static grains for the Philips HUE lamps

   New in version 2015.8.3.

   salt.grains.rest_sample
   Generate baseline proxy minion grains

   salt.grains.rest_sample.proxy_functions(proxy)
          The loader will execute functions with one argument and  pass  a
          reference  to  the  proxymodules  LazyLoader  object.   However,
          grains sometimes get called  before  the  LazyLoader  object  is
          setup so proxy might be None.

   execution modules
      Virtual modules

   salt.modules.pkg
   pkg  is  a  virtual  module  that  is fulfilled by one of the following
   modules:

               
               Execution Module  Used for                   
               
               aptpkg            Debian/Ubuntu-based        
                                 distros      which     use 
                                 apt-get(8)   for   package 
                                 management                 
               
               brew              Mac OS software management 
                                 using Homebrew             
               
               ebuild            Gentoo-based       systems 
                                 (utilizes    the   portage 
                                 python module as  well  as 
                                 emerge(1))                 
               
               freebsdpkg        FreeBSD-based  OSes  using 
                                 pkg_add(1)                 
               
               openbsdpkg        OpenBSD-based  OSes  using 
                                 pkg_add(1)                 
               
               pacman            Arch  Linux-based  distros 
                                 using pacman(8)            
               
               pkgin             NetBSD-based  OSes   using 
                                 pkgin(1)                   
               
               pkgng             FreeBSD-based  OSes  using 
                                 pkg(8)                     
               
               pkgutil           Solaris-based  OSes  using 
                                 OpenCSW's pkgutil(1)       
               
               solarispkg        Solaris-based  OSes  using 
                                 pkgadd(1M)                 
               
               solarisips        Solaris-based  OSes  using 
                                 IPS pkg(1)                 
               
               win_pkg           Salt's   Windows   Package 
                                 Manager                    
                                 <windows-package-manager   
               
               yumpkg            RedHat-based  distros  and 
                                 derivatives  using  yum(8) 
                                 or dnf(8)                  
               
               zypper            SUSE-based  distros  using 
                                 zypper(8)                  
               


acme                       ACME   /   Let's   Encrypt                                   

aliases                    Manage  the information in                                   

alternatives               Support  for  Alternatives                                   


apache                     Support for Apache                                           

apcups                     Module for apcupsd                                           

apf                        Support    for    Advanced                                   

aptpkg                     Support for APT  (Advanced                                   

archive                    A     module    to    wrap                                   

artifactory                Module     for    fetching                                   

at                         Wrapper module for at(1)                                     

augeas_cfg                 Manages      configuration                                   

aws_sqs                    Support   for  the  Amazon                                   

bamboohr                   Support for BambooHR                                         

bcache                     Module for managing BCache                                   

beacons                    Module  for  managing  the                                   

bigip                      An execution module  which                                   

blockdev                   Module for managing  block                                   

bluez                      Support    for   Bluetooth                                   

boto_apigateway            Connection   module    for                                   

boto_asg                   Connection    module   for                                   

boto_cfn                   Connection   module    for                                   

boto_cloudtrail            Connection    module   for                                   

boto_cloudwatch            Connection   module    for                                   

boto_cognitoidentity       Connection    module   for                                   

boto_datapipeline          Connection   module    for                                   

boto_dynamodb              Connection    module   for                                   

boto_ec2                   Connection   module    for                                   

boto_elasticache           Connection    module   for                                   

boto_elasticsearch_domain  Connection   module    for                                   

boto_elb                   Connection   module    for                                   

boto_iam                   Connection    module   for                                   

boto_iot                   Connection   module    for                                   

boto_kms                   Connection    module   for                                   

boto_lambda                Connection   module    for                                   

boto_rds                   Connection    module   for                                   

boto_route53               Connection   module    for                                   

boto_secgroup              Connection    module   for                                   

boto_sns                   Connection   module    for                                   

boto_sqs                   Connection    module   for                                   

boto_vpc                   Connection   module    for                                   

bower                      Manage   and  query  Bower                                   

bridge                     Module for  gathering  and                                   

bsd_shadow                 Manage    the     password                                   

btrfs                      Module  for managing BTRFS                                   

cabal                      Manage  and  query   Cabal                                   

cassandra                  Cassandra  NoSQL  Database                                   

cassandra_cql              Cassandra Database Module                                    

chassis                    Glue execution  module  to                                   

chef                       Execute chef in server  or                                   

chocolatey                 A   dead   simple   module                                   

chronos                    Module  providing a simple                                   

cloud                      Salt-specific    interface                                   

cmdmod                     A module for shelling out.                                   

composer                   Use  composer  to  install                                   

config                     Return config information                                    

consul                     Interact with Consul                                         


container_resource         Common  resources  for LXC                                   

cp                         Minion  side functions for                                   

cpan                       Manage Perl modules  using                                   

cron                       Work with cron                                               

csf                        Support  for Config Server                                   

cyg                        Manage cygwin packages.                                      

cytest                                                                                  

daemontools                daemontools        service                                   

data                       Manage a local  persistent                                   

ddns                       Support   for   RFC   2136                                   

deb_apache                 Support for Apache                                           

deb_postgres               Module to provide Postgres                                   

debbuild                   Debian   Package   builder                                   

debconfmod                 Support for Debconf                                          

debian_ip                  The  networking module for                                   

debian_service             Service support for Debian                                   

defaults                                                                                

devmap                     Device-Mapper module                                         

dig                        Compendium of generic  DNS                                   

disk                       Module  for managing disks                                   

djangomod                  Manage Django sites                                          

dnsmasq                    Module    for     managing                                   

dnsutil                    Compendium  of generic DNS                                   

dockercompose              Module      to      import                                   

dockerio                   Management    of    Docker                                   

dockerng                   Management    of    Docker                                   

dpkg                       Support for DEB packages                                     

drac                       Manage Dell DRAC                                             

dracr                      Manage Dell DRAC.                                            

drbd                       DRBD administration module                                   

ebuild                     Support for Portage                                          

eix                        Support for Eix                                              

elasticsearch              Elasticsearch     -      A                                   

environ                    Support  for  getting  and                                   

eselect                    Support    for    eselect,                                   

esxi                       Glues  the  VMware vSphere                                   

etcd_mod                   Execution module  to  work                                   

ethtool                    Module for running ethtool                                   

event                      Use the Salt Event  System                                   

extfs                      Module     for    managing                                   

file                       Manage  information  about                                   

firewalld                  Support for firewalld.                                       

freebsd_sysctl             Module  for  viewing   and                                   

freebsdjail                The   jail   module    for                                   

freebsdkmod                Module  to  manage FreeBSD                                   

freebsdpkg                 Remote   package   support                                   
                       using pkg_add(1)                                             

freebsdports               Install  software from the                                   
                       FreeBSD ports(7) system                                      

freebsdservice             The  service  module   for                                   

gem                        Manage ruby gems.                                            

genesis                    Module     for    managing                                   

gentoo_service             Top level package  command                                   

gentoolkitmod              Support for Gentoolkit                                       

git                        Support for the Git SCM                                      

github                     Module   for   interacting                                   


glance                     Module     for    handling                                   

glusterfs                  Manage a glusterfs pool                                      

gnomedesktop               GNOME implementations                                        

gpg                        Manage  a  GPG  keychains,                                   

grains                     Return/control  aspects of                                   

group                                                                                   

groupadd                   Manage  groups  on  Linux,                                   

grub_legacy                Support for GRUB Legacy                                      

guestfs                    Interact    with   virtual                                   

hadoop                     Support for hadoop                                           

haproxyconn                Support for haproxy                                          

hashutil                   A  collection  of  hashing                                   

hg                         Support for the  Mercurial                                   

hipchat                    Module     for     sending                                   

hosts                      Manage the information  in                                   

htpasswd                   Support    for    htpasswd                                   

http                       Module for making  various                                   

ifttt                      Support for IFTTT                                            

ilo                        Manage HP ILO                                                

img                        Virtual    machine   image                                   

incron                     Work with incron                                             

influx                     InfluxDB -  A  distributed                                   

infoblox                   Module     for    managing                                   

ini_manage                 Edit ini files                                               

inspectlib                                                                              

inspectlib.collector                                                                    

inspectlib.dbhandle                                                                     

inspectlib.exceptions                                                                   

inspectlib.query                                                                        

introspect                 Functions    to    perform                                   

ipmi                       Support IPMI commands over                                   

ipset                      Support for ipset                                            

iptables                   Support for iptables                                         

iwtools                    Support for Wireless Tools                                   

jboss7                     Module  for managing JBoss                                   

jboss7_cli                 Module    for    low-level                                   

jenkins                    Module   for   controlling                                   

junos                      Module for interfacing  to                                   

k8s                        Salt   module   to  manage                                   

kapacitor                  Kapacitor        execution                                   

kerberos                   Manage Kerberos KDC                                          

key                        Functions   to   view  the                                   

keyboard                   Module     for    managing                                   

keystone                   Module     for    handling                                   

kmod                       Module  to  manage   Linux                                   

launchctl                  Module  for the management                                   

layman                     Support for Layman                                           

ldap3                      Query  and  modify an LDAP                                   

ldapmod                    Salt   interface  to  LDAP                                   

linux_acl                  Support  for  Linux   File                                   

linux_ip                   The  networking module for                                   

linux_lvm                  Support for Linux LVM2                                       

linux_sysctl               Module  for  viewing   and                                   

localemod                  Module    for     managing                                   

locate                     Module   for   using   the                                   


logadm                     Module     for    managing                                   

logrotate                  Module     for    managing                                   

lvs                        Support  for  LVS   (Linux                                   

lxc                        Control  Linux  Containers                                   

mac_assistive              This module allows you  to                                   

mac_brew                   Homebrew for Mac OS X                                        

mac_defaults               Set defaults on Mac OS                                       

mac_desktop                Mac OS  X  implementations                                   

mac_group                  Manage groups  on  Mac  OS                                   

mac_keychain               Install  certificates into                                   

mac_package                Install pkg, dmg and  .app                                   

mac_pkgutil                Installer support  for  OS                                   

mac_ports                  Support for MacPorts under                                   

mac_power                  Module for  editing  power                                   

mac_service                The service module for Mac                                   

mac_shadow                 New in version 2016.3.0.                                     

mac_softwareupdate         Support      for       the                                   

mac_user                   Manage  users  on  Mac  OS                                   

mac_sysctl                 Module   for  viewing  and                                   

mac_system                 New in version 2016.3.0.                                     

mac_timezone               Module     for     editing                                   

mac_user                   Manage  users  on  Mac  OS                                   

mac_xattr                  This module allows you  to                                   

makeconf                   Support   for    modifying                                   

marathon                   Module  providing a simple                                   

match                      The  match  module  allows                                   

mdadm                      Salt module to manage RAID                                   

mdata                      Module    for   managaging                                   

memcached                  Module for  Management  of                                   

mine                       The  function cache system                                   

minion                     Module      to     provide                                   

mod_random                 Provides     access     to                                   

modjk                      Control   Modjk   via  the                                   

mongodb                    Module  to provide MongoDB                                   

monit                      Monit service module.                                        

moosefs                    Module for  gathering  and                                   

mount                      Salt module to manage Unix                                   

mssql                      Module  to  provide MS SQL                                   

munin                      Run  munin  plugins/checks                                   

mysql                      Module  to  provide  MySQL                                   

nacl                       This module helps  include                                   

nagios                     Run  nagios plugins/checks                                   

nagios_rpc                 Check   Host   &   Service                                   

napalm_bgp                 NAPALM BGP                                                   

napalm_network             NAPALM Network                                               

napalm_ntp                 NAPALM NTP                                                   

napalm_probes              NAPALM Probes                                                

netaddress                 Module     for     getting                                   

netbsd_sysctl              Module   for  viewing  and                                   


netbsdservice              The   service  module  for                                   

netscaler                  Module to  provide  Citrix                                   

network                    Module  for  gathering and                                   

neutron                    Module     for    handling                                   

nfs3                       Module  for  managing  NFS                                   

nftables                   Support for nftables                                         

nginx                      Support for nginx                                            

nova                       Module     for    handling                                   

npm                        Manage   and   query   NPM                                   

nspawn                     Manage nspawn containers                                     

nxos                       Execution module for Cisco                                   

omapi                      This module interacts with                                   

openbsd_sysctl             Module   for  viewing  and                                   

openbsdpkg                 Package     support    for                                   

openbsdrcctl               The rcctl  service  module                                   

openbsdservice             The   service  module  for                                   

openstack_config           Modify,    retrieve,    or                                   

openvswitch                Support for Open vSwitch -                                   

opkg                       Support for Opkg                                             

oracle                     Oracle DataBase connection                                   

osquery                    Support  for   OSQuery   -                                   
                       https://osquery.io.                                          

pacman                     A  module  to  wrap pacman                                   

pagerduty                  Module  for  Firing Events                                   

pagerduty_util             Module    for    manageing                                   

pam                        Support for pam                                              

parallels                  Manage  Parallels  Desktop                                   
                       VMs   with   prlctl    and                                   
                       prlsrvctl.                                                   

parted                     Module     for    managing                                   

pcs                        Configure                a                                   

pecl                       Manage       PHP      pecl                                   

philips_hue                Philips HUE  lamps  module                                   

pillar                     Extract  the  pillar  data                                   

pip                        Install  Python   packages                                   

pkg_resource               Resources  needed  by  pkg                                   

pkgin                      Package  support for pkgin                                   

pkgng                      Support for pkgng, the new                                   

pkgutil                    Pkgutil     support    for                                   

portage_config             Configure portage(5)                                         

postfix                    Support for Postfix                                          

postgres                   Module to provide Postgres                                   

poudriere                  Support for poudriere                                        

powerpath                  powerpath support.                                           

proxy                      This  module allows you to                                   

ps                         A   salt   interface    to                                   

publish                    Publish a command  from  a                                   

puppet                     Execute puppet routines                                      

pushbullet                 Module     for     sending                                   
                       https://www.pushbullet.com)                                  

pushover_notify            Module for sending messages                                  
                       https://www.pushover.net)                                    

pw_group                   Manage groups on FreeBSD                                     

pw_user                    Manage   users   with   the                                  

pyenv                      Manage python installations                                  

qemu_img                   Qemu-img Command Wrapper                                     

qemu_nbd                   Qemu Command Wrapper                                         


quota                      Module for managing  quotas                                  

rabbitmq                   Module  to provide RabbitMQ                                  

raet_publish               Publish a  command  from  a                                  

rallydev                   Support for RallyDev                                         

random_org                 Module    for    retrieving                                  

rbenv                      Manage  ruby  installations                                  

rdp                        Manage   RDP   Service   on                                  

redismod                   Module   to  provide  redis                                  

reg                                                                                     

rest_package               Package  support  for   the                                  

rest_service               Provide  the service module                                  

restartcheck               checkrestart  functionality                                  

ret                        Module  to  integrate  with                                  

rh_ip                      The networking  module  for                                  

rh_service                 Service     support     for                                  

riak                       Riak Salt Module                                             

rpm                        Support for rpm                                              

rpmbuild                   RPM Package builder system                                   

rsync                      Wrapper for rsync                                            

runit                      runit service module                                         

rvm                        Manage  ruby  installations                                  

s3                         Connection    module    for                                  

s6                         s6 service module                                            

salt_proxy                 Salt proxy module                                            

saltcloudmod               Control a salt cloud system                                  

saltutil                   The Saltutil module is used                                  

schedule                   Module   for  managing  the                                  

scsi                       SCSI administration module                                   

sdb                        Module   for   Manipulating                                  

seed                       Virtual    machine    image                                  

selinux                    Execute calls on selinux                                     

sensors                    Read lm-sensors                                              

serverdensity_device       Wrapper    around    Server                                  

service                    If Salt's OS detection does                                  

shadow                     Manage  the  shadow file on                                  

slack_notify               Module for sending messages                                  

slsutil                    Utility  functions  for use                                  

smartos_imgadm             Module for  running  imgadm                                  

smartos_nictagadm          Module      for     running                                  

smartos_virt               virst  compatibility module                                  

smartos_vmadm              Module  for  running  vmadm                                  

smbios                     Interface to SMBIOS/DMI                                      

smf                        Service support for Solaris                                  

smtp                       Module for Sending Messages                                  

solaris_fmadm              Module  for  running  fmadm                                  

solaris_group              Manage groups on Solaris                                     

solaris_shadow             Manage     the     password                                  

solaris_system             Support     for     reboot,                                  

solaris_user               Manage   users   with   the                                  

solarisips                 IPS pkg support for Solaris                                  

solarispkg                 Package support for Solaris                                  

solr                       Apache Solr Salt Module                                      

splunk                     Module for interop with the                                  

splunk_search              Module for interop with the                                  


sqlite3                    Support for SQLite3                                          

ssh                        Manage      client      ssh                                  

ssh_package                Service  support  for   the                                  

ssh_service                Provide  the service module                                  

state                      Control the state system on                                  

status                     Module    for     returning                                  

stormpath                  Support for Stormpath                                        

supervisord                Provide the service  module                                  

svn                        Subversion SCM                                               

swift                      Module     for     handling                                  

sysbench                   The  'sysbench'  module  is                                  

sysfs                      Module for interfacing with                                  

syslog_ng                  Module      for     getting                                  

sysmod                     The  sys  module   provides                                  

sysrc                      sysrc module for FreeBSD                                     

system                     Support     for     reboot,                                  

system_profiler            System Profiler Module                                       

systemd                    Provides the service module                                  

telemetry                  Connection    module    for                                  

temp                       Simple module for  creating                                  

test                       Module     for      running                                  

test_virtual               Module      for     running                                  

timezone                   Module     for     managing                                  

tls                        A salt module for SSL/TLS.                                   

tomcat                     Support for Tomcat                                           

trafficserver              Apache    Traffic    Server                                  

tuned                      Interface   to   Red    Hat                                  

twilio_notify              Module   for  notifications                                  

udev                       Manage and query udev info                                   

upstart                    Module for  the  management                                  

uptime                     Wrapper around uptime API                                    

user                                                                                    

useradd                    Manage   users   with   the                                  

uwsgi                      uWSGI     stats      server                                  
                       https://uwsgi-docs.readthedocs.io/en/latest/StatsServer.html 

varnish                    Support for Varnish                                          

vbox_guest                 VirtualBox Guest Additions installer                         

vboxmanage                 Support for VirtualBox using the VBoxManage command          

victorops                  Support for VictorOps                                        

virt                       Work with virtual machines managed by libvirt                

virtualenv_mod             Create virtualenv environments.                              

vsphere                    Manage VMware vCenter servers and ESXi hosts.                

win_autoruns               Module  for  listing  programs  that  automatically  run  on 

win_certutil               This  module  allows  you  to  install certificates into the 

win_dacl                   Manage DACLs on Windows                                      

win_disk                   Module for gathering disk information on Windows             

win_dism                   Install features/packages for Windows using DISM,  which  is 

win_dns_client             Module for configuring DNS Client on Windows systems         

win_dsc                    Module for working with DSC (Alpha)                          

win_file                   Manage information about files on the minion, set/read user, 

win_firewall               Module for configuring Windows Firewall                      

win_groupadd               Manage groups on Windows                                     

win_iis                    Microsoft  IIS   site   management   via   WebAdministration 

win_ip                     The networking module for Windows based systems              

win_license                This  module  allows  you  to  manage  windows licensing via 

win_network                Module for gathering and managing network information        

win_ntp                    Management of NTP servers on Windows                         

win_path                   Manage the Windows System PATH                               

win_pkg                    A module to manage software on Windows                       


win_powercfg               This module allows you to control the power  settings  of  a 

win_repo                   Module  to  manage  Windows  software  repo  on a Standalone 

win_servermanager          Manage Windows features  via  the  ServerManager  powershell 

win_service                Windows Service module.                                      

win_shadow                 Manage the shadow file                                       

win_status                 Module for returning various status data about a minion.     

win_system                 Module for managing windows systems.                         

win_task                   Windows Task Scheduler Module ..                             

win_timezone               Module for managing timezone on Windows systems.             

win_update                 Module for running windows updates.                          

win_useradd                Module for managing Windows Users                            

win_wua                    Module for managing Windows Updates using the Windows Update 

x509                       Manage X509 certificates                                     

xapi                       This module (mostly) uses the XenAPI to manage  Xen  virtual 

xbps-pkg                                                                                

xfs                        Module for managing XFS file systems.                        

xmpp                       Module for Sending Messages via XMPP (a.k.a.                 

yumpkg                     Support for YUM/DNF                                          

zabbix                     Support for Zabbix                                           

zcbuildout                 Management of zc.buildout                                    

zenoss                     Module for working with the Zenoss API                       

zfs                        Salt interface to ZFS commands                               

zk_concurrency             Concurrency controls in zookeeper                            

znc                        znc - An advanced IRC bouncer                                

zpool                      Module for running ZFS zpool command                         

zypper                     Package support for openSUSE via the zypper package manager  


   salt.modules.acme module
   ACME / Let's Encrypt module
   This   module  currently  uses  letsencrypt-auto,  which  needs  to  be
   available in the path or in /opt/letsencrypt/.

   NOTE:
      Currently only the webroot authentication is tested/implemented.

   NOTE:
      Installation & configuration of the Let's  Encrypt  client  can  for
      example                 be                 done                using
      https://github.com/saltstack-formulas/letsencrypt-formula

   WARNING:
      Be sure to set at least accept-tos = True in cli.ini!

   Most parameters will fall back to cli.ini defaults if None is given.

   salt.modules.acme.cert(name,  aliases=None,  email=None,  webroot=None,
   test_cert=False,  renew=None,  keysize=None, server=None, owner='root',
   group='root')
          Obtain/renew a certificate  from  an  ACME  CA,  probably  Let's
          Encrypt.

          Parameters

                 * name  --  Common  Name  of the certificate (DNS name of
                   certificate)

                 * aliases -- subjectAltNames  (Additional  DNS  names  on
                   certificate)

                 * email  --  e-mail  address  for  interaction  with ACME
                   provider

                 * webroot -- True  or  full  path  to  webroot  used  for
                   authentication

                 * test_cert  --  Request  a  certificate  from  the Happy
                   Hacker Fake CA (mutually exclusive with 'server')

                 * renew -- True/'force' to force a renewal, or  a  window
                   of renewal before expiry in days

                 * keysize -- RSA key bits

                 * server -- API endpoint to talk to

                 * owner -- owner of private key

                 * group -- group of private key

          Returns
                 dict   with   'result'   True/False/None,  'comment'  and
                 certificate's expiry date ('not_after')

          CLI example:

             salt 'gitlab.example.com' acme.cert dev.example.com "[gitlab.example.com]" test_cert=True renew=14 webroot=/opt/gitlab/embedded/service/gitlab-rails/public

   salt.modules.acme.certs()
          Return a list of active certificates

          CLI example:

             salt 'vhost.example.com' acme.certs

   salt.modules.acme.expires(name)
          The expiry date of a certificate in ISO format

          Parameters
                 name -- CommonName of cert

          CLI example:

             salt 'gitlab.example.com' acme.expires dev.example.com

   salt.modules.acme.has(name)
          Test if a certificate is in the Let's Encrypt Live directory

          Parameters
                 name -- CommonName of cert

          Code example:

             if __salt__['acme.has']('dev.example.com'):
                 log.info('That is one nice certificate you have there!')

   salt.modules.acme.info(name)
          Return information about a certificate

          NOTE:
             Will output tls.cert_info if  that's  available,  or  OpenSSL
             text if not

          Parameters
                 name -- CommonName of cert

          CLI example:

             salt 'gitlab.example.com' acme.info dev.example.com

   salt.modules.acme.needs_renewal(name, window=None)
          Check if a certicate needs renewal

          Parameters

                 * name -- CommonName of cert

                 * window -- Window in days to renew earlier or True/force
                   to just return True

          Code example:

             if __salt__['acme.needs_renewal']('dev.example.com'):
                 __salt__['acme.cert']('dev.example.com', **kwargs)
             else:
                 log.info('Your certificate is still good')

   salt.modules.acme.renew_by(name, window=None)
          Date in ISO format when a certificate should first be renewed

          Parameters

                 * name -- CommonName of cert

                 * window -- number of days  before  expiry  when  renewal
                   should take place

   salt.modules.aliases
   Manage the information in the aliases file

   salt.modules.aliases.get_target(alias)
          Return the target associated with an alias

          CLI Example:

             salt '*' aliases.get_target alias

   salt.modules.aliases.has_target(alias, target)
          Return true if the alias/target is set

          CLI Example:

             salt '*' aliases.has_target alias target

   salt.modules.aliases.list_aliases()
          Return the aliases found in the aliases file in this format:

             {'alias': 'target'}

          CLI Example:

             salt '*' aliases.list_aliases

   salt.modules.aliases.rm_alias(alias)
          Remove an entry from the aliases file

          CLI Example:

             salt '*' aliases.rm_alias alias

   salt.modules.aliases.set_target(alias, target)
          Set the entry in the aliases file for the given alias, this will
          overwrite any previous entry for the given alias or create a new
          one if it does not exist.

          CLI Example:

             salt '*' aliases.set_target alias target

   salt.modules.alternatives
   Support for Alternatives system

   codeauthor
          Radek Rada <[email protected]>

   salt.modules.alternatives.auto(name)
          Trigger  alternatives to set the path for <name> as specified by
          priority.

          CLI Example:

             salt '*' alternatives.auto name

   salt.modules.alternatives.check_exists(name, path)
          Check if the given path is an alternative for a name.

          New in version 2015.8.4.

          CLI Example:

             salt '*' alternatives.check_exists name path

   salt.modules.alternatives.check_installed(name, path)
          Check  if  the  current  highest-priority  match  for  a   given
          alternatives link is set to the desired path

          CLI Example:

             salt '*' alternatives.check_installed name path

   salt.modules.alternatives.display(name)
          Display alternatives settings for defined command name

          CLI Example:

             salt '*' alternatives.display editor

   salt.modules.alternatives.install(name, link, path, priority)
          Install symbolic links determining default commands

          CLI Example:

             salt '*' alternatives.install editor /usr/bin/editor /usr/bin/emacs23 50

   salt.modules.alternatives.remove(name, path)
          Remove symbolic links determining the default commands.

          CLI Example:

             salt '*' alternatives.remove name path

   salt.modules.alternatives.set(name, path)
          Manually set the alternative <path> for <name>.

          CLI Example:

             salt '*' alternatives.set name path

   salt.modules.alternatives.show_current(name)
          Display  the  current  highest-priority  alternative for a given
          alternatives link

          CLI Example:

             salt '*' alternatives.show_current editor

   salt.modules.alternatives.show_link(name)
          Display master link for the alternative

          New in version 2015.8.13,2016.3.4,2016.11.0.

          CLI Example:

             salt '*' alternatives.show_link editor

   salt.modules.apache
   Support for Apache

   NOTE:
      The functions in here are generic functions designed  to  work  with
      all  implementations  of Apache. Debian-specific functions have been
      moved into deb_apache.py, but  will  still  load  under  the  apache
      namespace when a Debian-based system is detected.

   salt.modules.apache.config(name, config, edit=True)
          Create VirtualHost configuration files

          name   File for the virtual host

          config VirtualHost configurations

          NOTE:
             This  function is not meant to be used from the command line.
             Config is meant to be an ordered dict of all  of  the  apache
             configs.

          CLI Example:

             salt '*' apache.config /etc/httpd/conf.d/ports.conf config="[{'Listen': '22'}]"

   salt.modules.apache.directives()
          Return  list  of directives together with expected arguments and
          places where the directive is valid (apachectl -L)

          CLI Example:

             salt '*' apache.directives

   salt.modules.apache.fullversion()
          Return server version (apachectl -V)

          CLI Example:

             salt '*' apache.fullversion

   salt.modules.apache.modules()
          Return list of static and shared modules (apachectl -M)

          CLI Example:

             salt '*' apache.modules

   salt.modules.apache.server_status(profile='default')
          Get Information from the Apache server-status handler

          NOTE:
             The server-status handler is disabled by default.   In  order
             for  this  function  to  work  it  needs  to be enabled.  See
             http://httpd.apache.org/docs/2.2/mod/mod_status.html

          The following configuration needs to  exists  in  pillar/grains.
          Each  entry  nested  in  apache.server-status  is a profile of a
          vhost/server.  This  would  give  support  for  multiple  apache
          servers/vhosts.

             apache.server-status:
               default:
                 url: http://localhost/server-status
                 user: someuser
                 pass: password
                 realm: 'authentication realm for digest passwords'
                 timeout: 5

          CLI Examples:

             salt '*' apache.server_status
             salt '*' apache.server_status other-profile

   salt.modules.apache.servermods()
          Return list of modules compiled into the server (apachectl -l)

          CLI Example:

             salt '*' apache.servermods

   salt.modules.apache.signal(signal=None)
          Signals httpd to start, restart, or stop.

          CLI Example:

             salt '*' apache.signal restart

   salt.modules.apache.useradd(pwfile, user, password, opts='')
          Add  HTTP  user using the htpasswd command. If the htpasswd file
          does not exist, it will be created. Valid options  that  can  be
          passed are:

             n  Don't update file; display results on stdout.
             m  Force MD5 hashing of the password (default).
             d  Force CRYPT(3) hashing of the password.
             p  Do not hash the password (plaintext).
             s  Force SHA1 hashing of the password.

          CLI Examples:

             salt '*' apache.useradd /etc/httpd/htpasswd larry badpassword
             salt '*' apache.useradd /etc/httpd/htpasswd larry badpass opts=ns

   salt.modules.apache.userdel(pwfile, user)
          Delete HTTP user from the specified htpasswd file.

          CLI Example:

             salt '*' apache.userdel /etc/httpd/htpasswd larry

   salt.modules.apache.version()
          Return server version (apachectl -v)

          CLI Example:

             salt '*' apache.version

   salt.modules.apache.vhosts()
          Show the settings as parsed from the config file (currently only
          shows the virtualhost settings) (apachectl  -S).   Because  each
          additional virtual host adds to the execution time, this command
          may require a long timeout be specified by using -t 10.

          CLI Example:

             salt -t 10 '*' apache.vhosts

   salt.modules.apcups
   Module for apcupsd

   salt.modules.apcups.status()
          Return apcaccess output

          CLI Example:

             salt '*' apcups.status

   salt.modules.apcups.status_battery()
          Return true if running on battery power

          CLI Example:

             salt '*' apcups.status_battery

   salt.modules.apcups.status_charge()
          Return battery charge

          CLI Example:

             salt '*' apcups.status_charge

   salt.modules.apcups.status_load()
          Return load

          CLI Example:

             salt '*' apcups.status_load

   salt.modules.apf
   Support for Advanced Policy Firewall (APF)
   maintainer
          Mostafa Hussein <[email protected]>

   maturity
          new

   depends
          python-iptables

   platform
          Linux

   salt.modules.apf.allow(ip, port=None)
          Add host (IP/FQDN) to allow_hosts.rules and immediately load new
          rule into firewall CLI Example:

             salt '*' apf.allow 127.0.0.1

   salt.modules.apf.deny(ip)
          Add  host (IP/FQDN) to deny_hosts.rules and immediately load new
          rule into firewall CLI Example:

             salt '*' apf.deny 1.2.3.4

   salt.modules.apf.disable()
          Stop (flush) all firewall rules CLI Example:

             salt '*' apf.disable

   salt.modules.apf.enable()
          Load all firewall rules CLI Example:

             salt '*' apf.enable

   salt.modules.apf.refresh()
          Refresh & resolve dns names in trust rules CLI Example:

             salt '*' apf.refresh

   salt.modules.apf.reload()
          Stop (flush) & reload firewall rules CLI Example:

             salt '*' apf.reload

   salt.modules.apf.remove(ip)
          Remove host from [glob]*_hosts.rules and immediately remove rule
          from firewall CLI Example:

             salt '*' apf.remove 1.2.3.4

   salt.modules.apf.running()
          Check apf status CLI Example:

             salt '*' apf.running

   salt.modules.aptpkg
   Support for APT (Advanced Packaging Tool)

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   NOTE:
      For  virtual  package  support, either the python-apt or dctrl-tools
      package must be installed.

      For repository management, the python-apt package must be installed.

   salt.modules.aptpkg.autoremove(list_only=False, purge=False)
          New in version 2015.5.0.

          Remove packages not required by another  package  using  apt-get
          autoremove.

          list_only
                 False   Only   retrieve   the  list  of  packages  to  be
                 auto-removed, do not actually perform the auto-removal.

          purge  False Also remove package config data  when  autoremoving
                 packages.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' pkg.autoremove
             salt '*' pkg.autoremove list_only=True
             salt '*' pkg.autoremove purge=True

   salt.modules.aptpkg.del_repo(repo, **kwargs)
          Delete a repo from the sources.list / sources.list.d

          If  the  .list  file  is in the sources.list.d directory and the
          file that the repo exists in does not  contain  any  other  repo
          configuration, the file itself will be deleted.

          The  repo passed in must be a fully formed repository definition
          string.

          CLI Examples:

             salt '*' pkg.del_repo "myrepo definition"

   salt.modules.aptpkg.del_repo_key(name=None, **kwargs)
          New in version 2015.8.0.

          Remove a repo key using apt-key del

          name   Repo from which to remove the key. Unnecessary  if  keyid
                 is passed.

          keyid  The KeyID of the GPG key to remove

          keyid_ppa
                 False  If  set  to  True,  the  repo's GPG key ID will be
                 looked up from ppa.launchpad.net and removed.

                 NOTE:
                    Setting this option to True  requires  that  the  name
                    param also be passed.

          CLI Examples:

             salt '*' pkg.del_repo_key keyid=0123ABCD
             salt '*' pkg.del_repo_key name='ppa:foo/bar' keyid_ppa=True

   salt.modules.aptpkg.expand_repo_def(**kwargs)
          Take  a  repository  definition  and  expand  it to the full pkg
          repository dict that can be used  for  comparison.   This  is  a
          helper  function  to make the Debian/Ubuntu apt sources sane for
          comparison in the pkgrepo states.

          This is designed to be called from pkgrepo states and will  have
          little use being called on the CLI.

   salt.modules.aptpkg.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying any packages will return a list of  _every_  file  on
          the system's package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_dict httpd
             salt '*' pkg.file_dict httpd postfix
             salt '*' pkg.file_dict

   salt.modules.aptpkg.file_list(*packages)
          List  the  files  that  belong  to a package. Not specifying any
          packages will return a list of  _every_  file  on  the  system's
          package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.aptpkg.get_repo(repo, **kwargs)
          Display a repo from the sources.list / sources.list.d

          The repo passed in needs to be a complete repo entry.

          CLI Examples:

             salt '*' pkg.get_repo "myrepo definition"

   salt.modules.aptpkg.get_selections(pattern=None, state=None)
          View package state from the dpkg database.

          Returns a dict of dicts containing the state, and package names:

             {'<host>':
                 {'<state>': ['pkg1',
                              ...
                             ]
                 },
                 ...
             }

          CLI Example:

             salt '*' pkg.get_selections
             salt '*' pkg.get_selections 'python-*'
             salt '*' pkg.get_selections state=hold
             salt '*' pkg.get_selections 'openssh*' state=hold

   salt.modules.aptpkg.hold(name=None, pkgs=None, sources=None, **kwargs)
          New in version 2014.7.0.

          Set package in 'hold' state, meaning it will not be upgraded.

          name   The name of the package, e.g., 'tmux'

                 CLI Example:

                    salt '*' pkg.hold <package name>

          pkgs   A  list  of  packages to hold. Must be passed as a python
                 list.

                 CLI Example:

                    salt '*' pkg.hold pkgs='["foo", "bar"]'

   salt.modules.aptpkg.info_installed(*names)
          Return the information of the named package(s) installed on  the
          system.

          New in version 2015.8.1.

          names  The   names   of   the   packages  for  which  to  return
                 information.

          CLI example:

             salt '*' pkg.info_installed <package1>
             salt '*' pkg.info_installed <package1> <package2> <package3> ...

   salt.modules.aptpkg.install(name=None,  refresh=False,   fromrepo=None,
   skip_verify=False,      debconf=None,      pkgs=None,     sources=None,
   reinstall=False, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any apt-get/dpkg  commands  spawned  by  Salt  when  the
          salt-minion   service   is   restarted.  (see  KillMode  in  the
          systemd.kill(5) manpage for more information). If desired, usage
          of  systemd-run(1)  can be suppressed by setting a config option
          called systemd.scope, with a value of False (no quotes).

          Install the passed package, add refresh=True to update the  dpkg
          database.

          name   The  name  of the package to be installed. Note that this
                 parameter is ignored if either  "pkgs"  or  "sources"  is
                 passed.  Additionally,  please  note that this option can
                 only  be  used  to  install  packages  from  a   software
                 repository.  To  install a package file manually, use the
                 "sources" option.

                 32-bit packages can be installed  on  64-bit  systems  by
                 appending  the  architecture designation (:i386, etc.) to
                 the end of the package name.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 Whether or not to refresh  the  package  database  before
                 installing.

          cache_valid_time
             New in version 2016.11.0.

             Skip  refreshing  the package database if refresh has already
             occurred within <value> seconds

          fromrepo
                 Specify a  package  repository  to  install  from  (e.g.,
                 apt-get -t unstable install somepackage)

          skip_verify
                 Skip     the     GPG     verification     check    (e.g.,
                 --allow-unauthenticated,   or   --force-bad-verify    for
                 install from package file).

          debconf
                 Provide  the  path  to  a debconf answers file, processed
                 before installation.

          version
                 Install  a  specific  version  of   the   package,   e.g.
                 1.2.3~0ubuntu0. Ignored if "pkgs" or "sources" is passed.

          reinstall
                 False  Specifying reinstall=True will use apt-get install
                 --reinstall  rather  than  simply  apt-get  install   for
                 requested packages that are already installed.

                 If  a  version  is  specified with the requested package,
                 then apt-get install --reinstall will only be used if the
                 installed version matches the requested version.

                 New in version 2015.8.0.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must be passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo", "bar"]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "1.2.3-0ubuntu0"}]'

          sources
                 A list of DEB packages to install. Must be  passed  as  a
                 list of dicts, with the keys being package names, and the
                 values being the source URI or local path to the package.
                 Dependencies  are  automatically  resolved  and marked as
                 auto-installed.

                 32-bit packages can be installed  on  64-bit  systems  by
                 appending  the  architecture designation (:i386, etc.) to
                 the end of the package name.

                 Changed in version 2014.7.0.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.deb"},{"bar": "salt://bar.deb"}]'

          force_yes
                 Passes --force-yes to the  apt-get  command.   Don't  use
                 this unless you know what you're doing.

                 New in version 0.17.4.

          install_recommends
                 Whether  to  install  the packages marked as recommended.
                 Default is True.

                 New in version 2015.5.0.

          only_upgrade
                 Only upgrade the packages, if they are already installed.
                 Default is False.

                 New in version 2015.5.0.

          force_conf_new
                 Always  install  the  new  version  of  any configuration
                 files.

                 New in version 2015.8.0.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.aptpkg.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          A  specific  repo  can  be  requested using the fromrepo keyword
          argument.

          cache_valid_time
             New in version 2016.11.0.

             Skip refreshing the package database if refresh  has  already
             occurred within <value> seconds

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package name> fromrepo=unstable
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.aptpkg.list_pkgs(versions_as_list=False,    removed=False,
   purge_desired=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          removed
                 If True, then only packages which have been removed  (but
                 not purged) will be returned.

          purge_desired
                 If  True, then only packages which have been marked to be
                 purged, but can't  be  purged  due  to  their  status  as
                 dependencies   for  other  installed  packages,  will  be
                 returned.  Note  that  these  packages  will  appear   in
                 installed

                 Changed  in  version 2014.1.1: Packages in this state now
                 correctly show up in the output of this function.

          NOTE:
             External dependencies

             Virtual package resolution requires the  dctrl-tools  package
             to be installed. Virtual packages will show a version of 1.

          CLI Example:

             salt '*' pkg.list_pkgs
             salt '*' pkg.list_pkgs versions_as_list=True

   salt.modules.aptpkg.list_repos()
          Lists all repos in the sources.list (and sources.lists.d) files

          CLI Example:

             salt '*' pkg.list_repos
             salt '*' pkg.list_repos disabled=True

   salt.modules.aptpkg.list_upgrades(refresh=True,      dist_upgrade=True,
   **kwargs)
          List all available package upgrades.

          refresh
                 Whether to refresh the package  database  before  listing
                 upgrades.  Default: True.

          cache_valid_time
             New in version 2016.11.0.

             Skip  refreshing  the package database if refresh has already
             occurred within <value> seconds

          dist_upgrade
                 Whether  to  list  the  upgrades  using  dist-upgrade  vs
                 upgrade.  Default is to use dist-upgrade.

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.aptpkg.mod_repo(repo, saltenv='base', **kwargs)
          Modify  one  or  more  values  for a repo.  If the repo does not
          exist, it will be created, so long as  the  definition  is  well
          formed.  For Ubuntu the ppa:<project>/repo format is acceptable.
          ppa: format can only be used to create a new repository.

          The following options are available to modify a repo definition:

             comps  a comma separated list of  components  for  the  repo,
                    e.g. main

             file   a file name to be used

             keyserver
                    keyserver to get gpg key from

             keyid  key id to load with the keyserver argument

             key_url
                    URL to a GPG key to add to the APT GPG keyring

             consolidate
                    if  True,  will  attempt  to  de-dup  and  consolidate
                    sources

             comments
                    Sometimes you want to supply  additional  information,
                    but  not  as  enabled configuration. Anything supplied
                    for this list will be saved in the repo  configuration
                    with a comment marker (#) in front.

                    New in version 2015.8.9.

             NOTE:
                 Due  to the way keys are stored for APT, there is a known
                 issue where the  key  won't  be  updated  unless  another
                 change is made at the same time.  Keys should be properly
                 added on initial configuration.

          CLI Examples:

             salt '*' pkg.mod_repo 'myrepo definition' uri=http://new/uri
             salt '*' pkg.mod_repo 'myrepo definition' comps=main,universe

   salt.modules.aptpkg.owner(*paths)
          New in version 2014.7.0.

          Return the name of the package that owns the file. Multiple file
          paths  can  be  passed.  Like  pkg.version,  if a single path is
          passed, a string will be returned, and  if  multiple  paths  are
          passed,   a  dictionary  of  file/package  name  pairs  will  be
          returned.

          If the file is not owned by a package, or is not present on  the
          minion, then an empty string will be returned for that path.

          CLI Example:

             salt '*' pkg.owner /usr/bin/apachectl
             salt '*' pkg.owner /usr/bin/apachectl /usr/bin/basename

   salt.modules.aptpkg.purge(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing  any  apt-get/dpkg  commands  spawned  by  Salt when the
          salt-minion  service  is  restarted.  (see   KillMode   in   the
          systemd.kill(5) manpage for more information). If desired, usage
          of systemd-run(1) can be suppressed by setting a  config  option
          called systemd.scope, with a value of False (no quotes).

          Remove  packages  via apt-get purge along with all configuration
          files.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.aptpkg.refresh_db(cache_valid_time=0)
          Updates  the  APT  database  to  latest  packages   based   upon
          repositories

          Returns  a  dict,  with the keys being package databases and the
          values being the result of the update attempt. Values can be one
          of the following:

          * True: Database updated successfully

          * False: Problem updating database

          * None: Database already up-to-date

          cache_valid_time
             New in version 2016.11.0.

             Skip  refreshing  the package database if refresh has already
             occurred within <value> seconds

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.aptpkg.remove(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any apt-get/dpkg  commands  spawned  by  Salt  when  the
          salt-minion   service   is   restarted.  (see  KillMode  in  the
          systemd.kill(5) manpage for more information). If desired, usage
          of  systemd-run(1)  can be suppressed by setting a config option
          called systemd.scope, with a value of False (no quotes).

          Remove packages using apt-get remove.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.aptpkg.set_selections(path=None,           selection=None,
   clear=False, saltenv='base')
          Change package state in the dpkg database.

          The state can be any one of, documented in dpkg(1):

          * install

          * hold

          * deinstall

          * purge

          This  command  is  commonly used to mark specific packages to be
          held from being upgraded, that is,  to  be  kept  at  a  certain
          version.  When  a  state  is changed to anything but being held,
          then it is typically followed by apt-get -u dselect-upgrade.

          Note: Be careful with the clear argument, since  it  will  start
          with setting all packages to deinstall state.

          Returns  a  dict  of dicts containing the package names, and the
          new and old versions:

             {'<host>':
                 {'<package>': {'new': '<new-state>',
                                'old': '<old-state>'}
                 },
                 ...
             }

          CLI Example:

             salt '*' pkg.set_selections selection='{"install": ["netcat"]}'
             salt '*' pkg.set_selections selection='{"hold": ["openssh-server", "openssh-client"]}'
             salt '*' pkg.set_selections salt://path/to/file
             salt '*' pkg.set_selections salt://path/to/file clear=True

   salt.modules.aptpkg.unhold(name=None,     pkgs=None,      sources=None,
   **kwargs)
          New in version 2014.7.0.

          Set package current in 'hold' state to install state, meaning it
          will be upgraded.

          name   The name of the package, e.g., 'tmux'

                 CLI Example:

                    salt '*' pkg.unhold <package name>

          pkgs   A list of packages to hold. Must be passed  as  a  python
                 list.

                 CLI Example:

                    salt '*' pkg.unhold pkgs='["foo", "bar"]'

   salt.modules.aptpkg.upgrade(refresh=True, dist_upgrade=False, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing  any  apt-get/dpkg  commands  spawned  by  Salt when the
          salt-minion  service  is  restarted.  (see   KillMode   in   the
          systemd.kill(5) manpage for more information). If desired, usage
          of systemd-run(1) can be suppressed by setting a  config  option
          called systemd.scope, with a value of False (no quotes).

          Upgrades   all   packages   via   apt-get   upgrade  or  apt-get
          dist-upgrade if  dist_upgrade is True.

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          dist_upgrade
                 Whether to perform  the  upgrade  using  dist-upgrade  vs
                 upgrade.  Default is to use upgrade.

                 New in version 2014.7.0.

          cache_valid_time
             New in version 2016.11.0.

             Skip  refreshing  the package database if refresh has already
             occurred within <value> seconds

          force_conf_new
                 Always install  the  new  version  of  any  configuration
                 files.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.aptpkg.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.aptpkg.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          string if not installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.aptpkg.version_cmp(pkg1, pkg2, ignore_epoch=False)
          Do  a  cmp-style comparison on two packages. Return -1 if pkg1 <
          pkg2, 0 if pkg1 == pkg2, and 1 if pkg1 > pkg2.  Return  None  if
          there was a problem making the comparison.

          ignore_epoch
                 False  Set  to  True  to  ignore the epoch when comparing
                 versions

                 New in version 2015.8.10,2016.3.2.

          CLI Example:

             salt '*' pkg.version_cmp '0.2.4-0ubuntu1' '0.2.4.1-0ubuntu1'

   salt.modules.archive
   A module to wrap (non-Windows) archive calls

   New in version 2014.1.0.

   salt.modules.archive.cmd_unzip(zip_file,      dest,      excludes=None,
   options=None,     template=None,     runas=None,     trim_output=False,
   password=None)
          New in version 2015.5.0: In versions 2014.7.x and earlier,  this
          function was known as archive.unzip.

          Uses the unzip command to unpack zip files. This command is part
          of the Info-ZIP suite of tools, and  is  typically  packaged  as
          simply unzip.

          zip_file
                 Path of zip file to be unpacked

          dest   The  destination  directory into which the file should be
                 unpacked

          excludes
                 None Comma-separated list of files  not  to  unpack.  Can
                 also be passed in a Python list.

          template
                 None  Can be set to 'jinja' or another supported template
                 engine to render the command arguments before execution:

                    salt '*' archive.cmd_unzip template=jinja /tmp/zipfile.zip '/tmp/{{grains.id}}' excludes=file_1,file_2

          options
                 Optional when using  zip  archives,  ignored  when  usign
                 other  archives  files.  This is mostly used to overwrite
                 exsiting files with o.  This options are only  used  when
                 unzip binary is used.

                 New in version 2016.3.1.

          runas  None  Unpack the zip file as the specified user. Defaults
                 to the user under which the minion is running.

                 New in version 2015.5.0.

          trim_output
                 False The number of files we  should  output  on  success
                 before  the rest are trimmed, if this is set to True then
                 it will default to 100

          password
                 Password to use with password protected zip files

                 NOTE:
                    This is not considered secure. It  is  recommended  to
                    instead  use  archive.unzip for password-protected ZIP
                    files. If a password is  used  here,  then  the  unzip
                    command  run  to extract the ZIP file will not show up
                    in the minion log like most shell commands  Salt  runs
                    do. However, the password will still be present in the
                    events logged to the  minion  log  at  the  debug  log
                    level.  If  the  minion  is  logging at debug (or more
                    verbose), then  be  advised  that  the  password  will
                    appear in the log.

                 New in version 2016.11.0.

          CLI Example:

             salt '*' archive.cmd_unzip /tmp/zipfile.zip /home/strongbad/ excludes=file_1,file_2

   salt.modules.archive.cmd_zip(zip_file,      sources,     template=None,
   cwd=None, runas=None)
          New in version 2015.5.0: In versions 2014.7.x and earlier,  this
          function was known as archive.zip.

          Uses  the  zip command to create zip files. This command is part
          of the Info-ZIP suite of tools, and  is  typically  packaged  as
          simply zip.

          zip_file
                 Path of zip file to be created

          sources
                 Comma-separated  list  of  sources  to include in the zip
                 file. Sources can also be passed in a Python list.

          template
                 None Can be set to 'jinja' or another supported  template
                 engine to render the command arguments before execution:

                    salt '*' archive.cmd_zip template=jinja /tmp/zipfile.zip /tmp/sourcefile1,/tmp/{{grains.id}}.txt

          cwd    None  Use  this  argument  along  with  relative paths in
                 sources to create zip files  which  do  not  contain  the
                 leading  directories. If not specified, the zip file will
                 be created as if the cwd was /, and creating a  zip  file
                 of  /foo/bar/baz.txt  will contain the parent directories
                 foo and  bar.  To  create  a  zip  file  containing  just
                 baz.txt, the following command would be used:

                    salt '*' archive.cmd_zip /tmp/baz.zip baz.txt cwd=/foo/bar

                 New in version 2014.7.1.

          runas  None  Create the zip file as the specified user. Defaults
                 to the user under which the minion is running.

                 New in version 2015.5.0.

          CLI Example:

             salt '*' archive.cmd_zip /tmp/zipfile.zip /tmp/sourcefile1,/tmp/sourcefile2

   salt.modules.archive.gunzip(gzipfile,    template=None,     runas=None,
   options=None)
          Uses the gunzip command to unpack gzip files

          template
                 None  Can be set to 'jinja' or another supported template
                 engine to render the command arguments before execution:

                    salt '*' archive.gunzip template=jinja /tmp/{{grains.id}}.txt.gz

          runas  None The user with which to run the gzip command line

          options
                 None Pass any additional arguments to gzip

                 New in version 2016.3.4.

          CLI Example:

             # Create /tmp/sourcefile.txt
             salt '*' archive.gunzip /tmp/sourcefile.txt.gz
             salt '*' archive.gunzip /tmp/sourcefile.txt options='--verbose'

   salt.modules.archive.gzip(sourcefile,    template=None,     runas=None,
   options=None)
          Uses the gzip command to create gzip files

          template
                 None  Can be set to 'jinja' or another supported template
                 engine to render the command arguments before execution:

                    salt '*' archive.gzip template=jinja /tmp/{{grains.id}}.txt

          runas  None The user with which to run the gzip command line

          options
                 None Pass any additional arguments to gzip

                 New in version 2016.3.4.

          CLI Example:

             # Create /tmp/sourcefile.txt.gz
             salt '*' archive.gzip /tmp/sourcefile.txt
             salt '*' archive.gzip /tmp/sourcefile.txt options='-9 --verbose'

   salt.modules.archive.is_encrypted(name, clean=False, saltenv='base')
          New in version 2016.11.0.

          Returns True if the zip archive is password-protected, False  if
          not.  If  the specified file is not a ZIP archive, an error will
          be raised.

          clean  False Set this value to True to delete the path  referred
                 to  by  name  once  the  contents  have been listed. This
                 option should be used with care.

                 NOTE:
                    If there is an error listing the  archive's  contents,
                    the  cached  file  will  not  be removed, to allow for
                    troubleshooting.

          CLI Examples:

             salt '*' archive.is_encrypted /path/to/myfile.zip
             salt '*' archive.is_encrypted salt://foo.zip
             salt '*' archive.is_encrypted https://domain.tld/myfile.zip clean=True
             salt '*' archive.is_encrypted ftp://10.1.2.3/foo.zip

   salt.modules.archive.list(name,   archive_format=None,    options=None,
   clean=False, verbose=False, saltenv='base')
          New in version 2016.11.0.

          List the files and directories in an tar, zip, or rar archive.

          NOTE:
             This  function  will  only  provide results for XZ-compressed
             archives if the xz CLI command is available, as  Python  does
             not  at  this  time  natively  support  XZ compression in its
             tarfile module. Keep in mind however that most Linux  distros
             ship with xz already installed.

             To check if a given minion has xz, the following Salt command
             can be run:

                 salt minion_id cmd.which xz

             If None is returned, then xz  is  not  present  and  must  be
             installed.   It is widely available and should be packaged as
             either xz or xz-utils.

          name   Path/URL of archive

          archive_format
                 Specify the format of the archive (tar, zip, or rar).  If
                 this  argument  is  omitted,  the  archive format will be
                 guessed based on the value of the name parameter.

          options
                 For tar archives only. This function  will,  by  default,
                 try  to  use  the tarfile module from the Python standard
                 library to get  a  list  of  files/directories.  If  this
                 method  fails,  then it will fall back to using the shell
                 to decompress the archive to stdout and pipe the  results
                 to   tar   -tf   -   to  produce  a  list  of  filenames.
                 XZ-compressed    archives    are    already     supported
                 automatically, but in the event that the tar archive uses
                 a different sort of compression not supported natively by
                 tarfile,  this  option  can  be used to specify a command
                 that will decompress the archive to stdout. For example:

                    salt minion_id archive.list /path/to/foo.tar.gz options='gzip --decompress --stdout'

                 NOTE:
                    It is not necessary to manually  specify  options  for
                    gzip'ed  archives,  as  gzip  compression  is natively
                    supported by tarfile.

          clean  False Set this value to True to delete the path  referred
                 to  by  name  once  the  contents  have been listed. This
                 option should be used with care.

                 NOTE:
                    If there is an error listing the  archive's  contents,
                    the  cached  file  will  not  be removed, to allow for
                    troubleshooting.

          verbose
                 False If False, this  function  will  return  a  list  of
                 files/dirs  in  the  archive.  If  True, it will return a
                 dictionary categorizing  the  paths  into  separate  keys
                 containing  the  directory  names,  file  names, and also
                 directories/files  present  in  the  top  level  of   the
                 archive.

          saltenv
                 base  Specifies  the fileserver environment from which to
                 retrieve archive. This is only applicable when archive is
                 a file from the salt:// fileserver.

          CLI Examples:

             salt '*' archive.list /path/to/myfile.tar.gz
             salt '*' archive.list salt://foo.tar.gz
             salt '*' archive.list https://domain.tld/myfile.zip
             salt '*' archive.list ftp://10.1.2.3/foo.rar

   salt.modules.archive.rar(rarfile,   sources,  template=None,  cwd=None,
   runas=None)
          Uses rar for Linux to create rar files

          rarfile
                 Path of rar file to be created

          sources
                 Comma-separated list of sources to  include  in  the  rar
                 file. Sources can also be passed in a Python list.

          cwd    None  Run  the  rar command from the specified directory.
                 Use this argument  along  with  relative  file  paths  to
                 create  rar  files  which  do  not  contain  the  leading
                 directories. If not specified, this will default  to  the
                 home  directory  of  the user under which the salt minion
                 process is running.

                 New in version 2014.7.1.

          template
                 None Can be set to 'jinja' or another supported  template
                 engine to render the command arguments before execution:

                    salt '*' archive.rar template=jinja /tmp/rarfile.rar '/tmp/sourcefile1,/tmp/{{grains.id}}.txt'

          CLI Example:

             salt '*' archive.rar /tmp/rarfile.rar /tmp/sourcefile1,/tmp/sourcefile2

   salt.modules.archive.tar(options,   tarfile,  sources=None,  dest=None,
   cwd=None, template=None, runas=None)

          NOTE:
             This function  has  changed  for  version  0.17.0.  In  prior
             versions,  the  cwd and template arguments must be specified,
             with the source directories/files coming as a space-separated
             list  at  the  end  of  the  command.  Beginning with 0.17.0,
             sources must be a  comma-separated  list,  and  the  cwd  and
             template arguments are optional.

          Uses the tar command to pack, unpack, etc. tar files

          options
                 Options to pass to the tar command

                 Changed  in  version  2015.8.0: The mandatory - prefixing
                 has been removed.  An options  string  beginning  with  a
                 --long-option, would have uncharacteristically needed its
                 first - removed under the former scheme.

                 Also, tar will parse its  options  differently  if  short
                 options  are used with or without a preceding -, so it is
                 better to not confuse  the  user  into  thinking  they're
                 using  the  non--  format, when really they are using the
                 with-- format.

          tarfile
                 The filename of the tar archive to pack/unpack

          sources
                 Comma delimited list of files to pack into  the  tarfile.
                 Can also be passed as a Python list.

          dest   The  destination  directory  into  which  to  unpack  the
                 tarfile

          cwd    None The directory in which the  tar  command  should  be
                 executed.  If  not  specified,  will  default to the home
                 directory of the user under which the salt minion process
                 is running.

          template
                 None  Can be set to 'jinja' or another supported template
                 engine to render the command arguments before execution:

                    salt '*' archive.tar -cjvf /tmp/salt.tar.bz2 {{grains.saltpath}} template=jinja

          CLI Examples:

             # Create a tarfile
             salt '*' archive.tar -cjvf /tmp/tarfile.tar.bz2 /tmp/file_1,/tmp/file_2
             # Unpack a tarfile
             salt '*' archive.tar xf foo.tar dest=/target/directory

   salt.modules.archive.unrar(rarfile, dest, excludes=None, template=None,
   runas=None, trim_output=False)
          Uses rar for Linux to unpack rar files

          rarfile
                 Name of rar file to be unpacked

          dest   The  destination  directory  into which to unpack the rar
                 file

          template
                 None Can be set to 'jinja' or another supported  template
                 engine to render the command arguments before execution:

                    salt '*' archive.unrar template=jinja /tmp/rarfile.rar /tmp/{{grains.id}}/ excludes=file_1,file_2

          trim_output
                 False  The  number  of  files we should output on success
                 before the rest are trimmed, if this is set to True  then
                 it will default to 100

          CLI Example:

             salt '*' archive.unrar /tmp/rarfile.rar /home/strongbad/ excludes=file_1,file_2

   salt.modules.archive.unzip(zip_file, dest, excludes=None, options=None,
   template=None,    runas=None,     trim_output=False,     password=None,
   extract_perms=True)
          Uses the zipfile Python module to unpack zip files

          Changed  in version 2015.5.0: This function was rewritten to use
          Python's native zip file support.   The  old  functionality  has
          been  preserved  in  the  new  function  archive.cmd_unzip.  For
          versions  2014.7.x  and   earlier,   see   the   archive.cmd_zip
          documentation.

          zip_file
                 Path of zip file to be unpacked

          dest   The  destination  directory into which the file should be
                 unpacked

          excludes
                 None Comma-separated list of files  not  to  unpack.  Can
                 also be passed in a Python list.

          options
                 This  options are only used when unzip binary is used. In
                 this function is ignored.

                 New in version 2016.3.1.

          template
                 None Can be set to 'jinja' or another supported  template
                 engine to render the command arguments before execution:

                    salt '*' archive.unzip template=jinja /tmp/zipfile.zip /tmp/{{grains.id}}/ excludes=file_1,file_2

          runas  None  Unpack the zip file as the specified user. Defaults
                 to the user under which the minion is running.

          trim_output
                 False The number of files we  should  output  on  success
                 before  the rest are trimmed, if this is set to True then
                 it will default to 100

          CLI Example:

             salt '*' archive.unzip /tmp/zipfile.zip /home/strongbad/ excludes=file_1,file_2

          password
                 Password to use with password protected zip files

                 NOTE:
                    The password will be present in the events  logged  to
                    the  minion  log  file  at the debug log level. If the
                    minion is logging at debug (or more verbose), then  be
                    advised that the password will appear in the log.

                 New in version 2016.3.0.

          extract_perms
                 True   The   Python   zipfile  module  does  not  extract
                 file/directory attributes by default. When this  argument
                 is  set  to  True,  Salt  will  attempt to apply the file
                 permision attributes to the extracted files/folders.

                 On Windows, only the read-only flag will be extracted  as
                 set   within   the   zip  file,  other  attributes  (i.e.
                 user/group permissions) are ignored.

                 Set this argument to False to disable this behavior.

                 New in version 2016.11.0.

          CLI Example:

             salt '*' archive.unzip /tmp/zipfile.zip /home/strongbad/ password='BadPassword'

   salt.modules.archive.zip(zip_file,  sources,  template=None,  cwd=None,
   runas=None)
          Uses the zipfile Python module to create zip files

          Changed  in version 2015.5.0: This function was rewritten to use
          Python's native zip file support.   The  old  functionality  has
          been preserved in the new function archive.cmd_zip. For versions
          2014.7.x and earlier, see the archive.cmd_zip documentation.

          zip_file
                 Path of zip file to be created

          sources
                 Comma-separated list of sources to  include  in  the  zip
                 file. Sources can also be passed in a Python list.

          template
                 None  Can be set to 'jinja' or another supported template
                 engine to render the command arguments before execution:

                    salt '*' archive.zip template=jinja /tmp/zipfile.zip /tmp/sourcefile1,/tmp/{{grains.id}}.txt

          cwd    None Use this  argument  along  with  relative  paths  in
                 sources  to  create  zip  files  which do not contain the
                 leading directories. If not specified, the zip file  will
                 be  created  as if the cwd was /, and creating a zip file
                 of /foo/bar/baz.txt will contain the  parent  directories
                 foo  and  bar.  To  create  a  zip  file  containing just
                 baz.txt, the following command would be used:

                    salt '*' archive.zip /tmp/baz.zip baz.txt cwd=/foo/bar

          runas  None Create the zip file as the specified user.  Defaults
                 to the user under which the minion is running.

          CLI Example:

             salt '*' archive.zip /tmp/zipfile.zip /tmp/sourcefile1,/tmp/sourcefile2

   salt.modules.artifactory
   Module for fetching artifacts from Artifactory

   salt.modules.artifactory.get_latest_release(artifactory_url,
   repository,  group_id,   artifact_id,   packaging,   target_dir='/tmp',
   target_file=None, classifier=None, username=None, password=None)
          Gets the latest release of the artifact

          artifactory_url
                 URL of artifactory instance

          repository
                 Release  repository  in  artifactory to retrieve artifact
                 from, for example: libs-releases

          group_id
                 Group Id of the artifact

          artifact_id
                 Artifact Id of the artifact

          packaging
                 Packaging type (jar,war,ear,etc)

          target_dir
                 Target directory to download artifact to (default: /tmp)

          target_file
                 Target file to download artifact to  (by  default  it  is
                 target_dir/artifact_id-version.packaging)

          classifier
                 Artifact   classifier   name  (ex:  sources,javadoc,etc).
                 Optional parameter.

          username
                 Artifactory username. Optional parameter.

          password
                 Artifactory password. Optional parameter.

   salt.modules.artifactory.get_latest_snapshot(artifactory_url,
   repository,   group_id,   artifact_id,   packaging,  target_dir='/tmp',
   target_file=None, classifier=None, username=None, password=None)
          Gets latest snapshot of the given artifact

          artifactory_url
                 URL of artifactory instance

          repository
                 Snapshot repository in artifactory to  retrieve  artifact
                 from, for example: libs-snapshots

          group_id
                 Group Id of the artifact

          artifact_id
                 Artifact Id of the artifact

          packaging
                 Packaging type (jar,war,ear,etc)

          target_dir
                 Target directory to download artifact to (default: /tmp)

          target_file
                 Target  file  to  download  artifact to (by default it is
                 target_dir/artifact_id-snapshot_version.packaging)

          classifier
                 Artifact  classifier  name   (ex:   sources,javadoc,etc).
                 Optional parameter.

          username
                 Artifactory username. Optional parameter.

          password
                 Artifactory password. Optional parameter.

   salt.modules.artifactory.get_release(artifactory_url,       repository,
   group_id,   artifact_id,   packaging,    version,    target_dir='/tmp',
   target_file=None, classifier=None, username=None, password=None)
          Gets the specified release of the artifact

          artifactory_url
                 URL of artifactory instance

          repository
                 Release  repository  in  artifactory to retrieve artifact
                 from, for example: libs-releases

          group_id
                 Group Id of the artifact

          artifact_id
                 Artifact Id of the artifact

          packaging
                 Packaging type (jar,war,ear,etc)

          version
                 Version of the artifact

          target_dir
                 Target directory to download artifact to (default: /tmp)

          target_file
                 Target file to download artifact to  (by  default  it  is
                 target_dir/artifact_id-version.packaging)

          classifier
                 Artifact   classifier   name  (ex:  sources,javadoc,etc).
                 Optional parameter.

          username
                 Artifactory username. Optional parameter.

          password
                 Artifactory password. Optional parameter.

   salt.modules.artifactory.get_snapshot(artifactory_url,      repository,
   group_id,   artifact_id,   packaging,  version,  snapshot_version=None,
   target_dir='/tmp',  target_file=None,  classifier=None,  username=None,
   password=None)
          Gets snapshot of the desired version of the artifact

          artifactory_url
                 URL of artifactory instance

          repository
                 Snapshot  repository  in artifactory to retrieve artifact
                 from, for example: libs-snapshots

          group_id
                 Group Id of the artifact

          artifact_id
                 Artifact Id of the artifact

          packaging
                 Packaging type (jar,war,ear,etc)

          version
                 Version of the artifact

          target_dir
                 Target directory to download artifact to (default: /tmp)

          target_file
                 Target file to download artifact to  (by  default  it  is
                 target_dir/artifact_id-snapshot_version.packaging)

          classifier
                 Artifact   classifier   name  (ex:  sources,javadoc,etc).
                 Optional parameter.

          username
                 Artifactory username. Optional parameter.

          password
                 Artifactory password. Optional parameter.

   salt.modules.at
   Wrapper module for at(1)

   Also, a 'tag' feature has been added to more easily tag jobs.

   salt.modules.at.at(*args, **kwargs)
          Add a job to the queue.

          The 'timespec'  follows  the  format  documented  in  the  at(1)
          manpage.

          CLI Example:

             salt '*' at.at <timespec> <cmd> [tag=<tag>] [runas=<user>]
             salt '*' at.at 12:05am '/sbin/reboot' tag=reboot
             salt '*' at.at '3:05am +3 days' 'bin/myscript' tag=nightly runas=jim

   salt.modules.at.atc(jobid)
          Print the at(1) script that will run for the passed job id. This
          is mostly for debugging so the output will just be text.

          CLI Example:

             salt '*' at.atc <jobid>

   salt.modules.at.atq(tag=None)
          List all queued and running jobs or only those with an  optional
          'tag'.

          CLI Example:

             salt '*' at.atq
             salt '*' at.atq [tag]
             salt '*' at.atq [job number]

   salt.modules.at.atrm(*args)
          Remove jobs from the queue.

          CLI Example:

             salt '*' at.atrm <jobid> <jobid> .. <jobid>
             salt '*' at.atrm all
             salt '*' at.atrm all [tag]

   salt.modules.at.jobcheck(**kwargs)
          Check  the job from queue.  The kwargs dict include 'hour minute
          day month year tag runas' Other parameters will be ignored.

          CLI Example:

             salt '*' at.jobcheck runas=jam day=13
             salt '*' at.jobcheck day=13 month=12 year=13 tag=rose

   salt.modules.augeas_cfg
   Manages configuration files via augeas

   This module requires the augeas Python module.

   WARNING:
      Minimal installations of Debian and Ubuntu have been  seen  to  have
      packaging bugs with python-augeas, causing the augeas module to fail
      to import. If the minion has the augeas module  installed,  but  the
      functions  in  this  execution  module  fail  to  run  due  to being
      unavailable, first restart the salt-minion service. If  the  problem
      persists past that, the following command can be run from the master
      to determine what is causing the import to fail:

          salt minion-id cmd.run 'python -c "from augeas import Augeas"'

      For affected Debian/Ubuntu hosts, installing libpython2.7  has  been
      known to resolve the issue.

   salt.modules.augeas_cfg.execute(context=None,  lens=None,  commands=(),
   load_path=None)
          Execute Augeas commands

          New in version 2014.7.0.

          CLI Example:

             salt '*' augeas.execute /files/etc/redis/redis.conf \
             commands='["set bind 0.0.0.0", "set maxmemory 1G"]'

          context
                 The Augeas context

          lens   The Augeas lens to use

          commands
                 The Augeas commands to execute

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be  searched in. This is in addition to the standard load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.augeas_cfg.get(path, value='', load_path=None)
          Get a value for a specific augeas path

          CLI Example:

             salt '*' augeas.get /files/etc/hosts/1/ ipaddr

          path   The path to get the value of

          value  The optional value to get

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be  searched in. This is in addition to the standard load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.augeas_cfg.ls(path, load_path=None)
          List the direct children of a node

          CLI Example:

             salt '*' augeas.ls /files/etc/passwd

          path   The path to list

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be  searched in. This is in addition to the standard load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.augeas_cfg.match(path, value='', load_path=None)
          Get matches for path expression

          CLI Example:

             salt '*' augeas.match /files/etc/services/service-name ssh

          path   The path to match

          value  The value to match on

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be  searched in. This is in addition to the standard load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.augeas_cfg.remove(path, load_path=None)
          Get matches for path expression

          CLI Example:

             salt '*' augeas.remove \
             /files/etc/sysctl.conf/net.ipv4.conf.all.log_martians

          path   The path to remove

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be  searched in. This is in addition to the standard load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.augeas_cfg.setvalue(*args)
          Set a value for a specific augeas path

          CLI Example:

             salt '*' augeas.setvalue /files/etc/hosts/1/canonical localhost

          This will set the first entry in /etc/hosts to localhost

          CLI Example:

             salt '*' augeas.setvalue /files/etc/hosts/01/ipaddr 192.168.1.1 \
                                      /files/etc/hosts/01/canonical test

          Adds a new host to /etc/hosts the  ip  address  192.168.1.1  and
          hostname test

          CLI Example:

             salt '*' augeas.setvalue prefix=/files/etc/sudoers/ \
                      "spec[user = '%wheel']/user" "%wheel" \
                      "spec[user = '%wheel']/host_group/host" 'ALL' \
                      "spec[user = '%wheel']/host_group/command[1]" 'ALL' \
                      "spec[user = '%wheel']/host_group/command[1]/tag" 'PASSWD' \
                      "spec[user = '%wheel']/host_group/command[2]" '/usr/bin/apt-get' \
                      "spec[user = '%wheel']/host_group/command[2]/tag" NOPASSWD

          Ensures that the following line is present in /etc/sudoers:

             %wheel ALL = PASSWD : ALL , NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

   salt.modules.augeas_cfg.tree(path, load_path=None)
          Returns recursively the complete tree of a node

          CLI Example:

             salt '*' augeas.tree /files/etc/

          path   The base of the recursive listing

          New in version 2016.3.0.

          load_path
                 A colon-spearated list of directories that modules should
                 be searched in. This is in addition to the standard  load
                 path and the directories in AUGEAS_LENS_LIB.

   salt.modules.aws_sqs
   Support for the Amazon Simple Queue Service.

   salt.modules.aws_sqs.create_queue(name, region, opts=None, user=None)
          Creates a queue with the correct name.

          name   Name of the SQS queue to create

          region Region to create the SQS queue in

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          CLI Example:
             salt '*' aws_sqs.create_queue <sqs queue> <region>

   salt.modules.aws_sqs.delete_message(queue,    region,    receipthandle,
   opts=None, user=None)
          Delete one or more messages from a queue in a region

          queue  The name of the queue to delete messages from

          region Region where SQS queues exists

          receipthandle
                 The  ReceiptHandle  of  the  message   to   delete.   The
                 ReceiptHandle    is   obtained   in   the   return   from
                 receive_message

          opts   None Any additional options to add to the command line

          user   None Run as a user other than what the minion runs as

          CLI Example:

             salt '*' aws_sqs.delete_message <sqs queue> <region> receipthandle='<sqs ReceiptHandle>'

          New in version 2014.7.0.

   salt.modules.aws_sqs.delete_queue(name, region, opts=None, user=None)
          Deletes a queue in the region.

          name   Name of the SQS queue to deletes

          region Name of the region to delete the queue from

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          CLI Example:
             salt '*' aws_sqs.delete_queue <sqs queue> <region>

   salt.modules.aws_sqs.list_queues(region, opts=None, user=None)
          List the queues in the selected region.

          region Region to list SQS queues for

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          CLI Example:
             salt '*' aws_sqs.list_queues <region>

   salt.modules.aws_sqs.queue_exists(name, region, opts=None, user=None)
          Returns True or False on whether the queue exists in the region

          name   Name of the SQS queue to search for

          region Name of the region to search for the queue in

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          CLI Example:
             salt '*' aws_sqs.queue_exists <sqs queue> <region>

   salt.modules.aws_sqs.receive_message(queue, region,  num=1,  opts=None,
   user=None)
          Receive one or more messages from a queue in a region

          queue  The name of the queue to receive messages from

          region Region where SQS queues exists

          num    1 The max number of messages to receive

          opts   None Any additional options to add to the command line

          user   None Run as a user other than what the minion runs as

          CLI Example:

             salt '*' aws_sqs.receive_message <sqs queue> <region>
             salt '*' aws_sqs.receive_message <sqs queue> <region> num=10

          New in version 2014.7.0.

   salt.modules.bamboohr
   Support for BambooHR

   New in version 2015.8.0.

   Requires a subdomain and an apikey in /etc/salt/minion:

   salt.modules.bamboohr.list_employees(order_by='id')
          Show all employees for this company.

          CLI Example:
             salt myminion bamboohr.list_employees

          By default, the return data will be keyed by ID. However, it can
          be ordered by any other field. Keep in mind that  if  the  field
          that  is  chosen  contains  duplicate  values (i.e., location is
          used, for a company which only  has  one  location),  then  each
          duplicate value will be overwritten by the previous.  Therefore,
          it is advisable to only sort by fields that are guaranteed to be
          unique.

          CLI Examples:
             salt   myminion   bamboohr.list_employees   order_by=id  salt
             myminion  bamboohr.list_employees  order_by=displayName  salt
             myminion bamboohr.list_employees order_by=workEmail

   salt.modules.bamboohr.list_meta_fields()
          Show all meta data fields for this company.

          CLI Example:
             salt myminion bamboohr.list_meta_fields

   salt.modules.bamboohr.list_users(order_by='id')
          Show all users for this company.

          CLI Example:
             salt myminion bamboohr.list_users

          By default, the return data will be keyed by ID. However, it can
          be ordered by any other field. Keep in mind that  if  the  field
          that  is  chosen  contains  duplicate  values (i.e., location is
          used, for a company which only  has  one  location),  then  each
          duplicate value will be overwritten by the previous.  Therefore,
          it is advisable to only sort by fields that are guaranteed to be
          unique.

          CLI Examples:
             salt  myminion  bamboohr.list_users order_by=id salt myminion
             bamboohr.list_users order_by=email

   salt.modules.bamboohr.show_employee(emp_id, fields=None)
          Show all employees for this company.

          CLI Example:
             salt myminion bamboohr.show_employee 1138

          By    default,    the    fields    normally    returned     from
          bamboohr.list_employees are returned. These fields are:

             * canUploadPhoto

             * department

             * displayName

             * firstName

             * id

             * jobTitle

             * lastName

             * location

             * mobilePhone

             * nickname

             * photoUploaded

             * photoUrl

             * workEmail

             * workPhone

             * workPhoneExtension

          If needed, a different set of fields may be specified, separated
          by commas:

          CLI Example:
             salt       myminion        bamboohr.show_employee        1138
             displayName,dateOfBirth

          A    list    of    available    fields    can    be   found   at
          http://www.bamboohr.com/api/documentation/employees.php

   salt.modules.bamboohr.update_employee(emp_id,   key=None,   value=None,
   items=None)
          Update  one or more items for this employee. Specifying an empty
          value will clear it for that employee.

          CLI Examples:
             salt myminion bamboohr.update_employee  1138  nickname  Curly
             salt  myminion bamboohr.update_employee 1138 nickname '' salt
             myminion  bamboohr.update_employee  1138  items='{"nickname":
             "Curly"}    salt   myminion   bamboohr.update_employee   1138
             items='{"nickname": ""}

   salt.modules.bcache module
   Module for managing BCache sets

   BCache is a block-level caching mechanism  similar  to  ZFS  L2ARC/ZIL,
   dm-cache  and  fscache.   It  works by formatting one block device as a
   cache set, then adding backend devices (which need to be  formatted  as
   such) to the set and activating them.

   It's available in Linux mainline kernel since 3.10

   https://www.kernel.org/doc/Documentation/bcache.txt

   This module needs the bcache userspace tools to function.

   salt.modules.bcache.attach(dev=None)
          Attach  a backing devices to a cache set If no dev is given, all
          backing devices will be attached.

          CLI example:

             salt '*' bcache.attach sdc
             salt '*' bcache.attach /dev/bcache1

          Returns
                 bool or None if nuttin' happened

   salt.modules.bcache.back_make(dev, cache_mode='writeback', force=False,
   attach=True, bucket_size=None)
          Create  a  backing  device for attachment to a set.  Because the
          block size must be the same, a cache set already needs to exist.

          CLI example:

             salt '*' bcache.back_make sdc cache_mode=writeback attach=True

          Parameters

                 * cache_mode -- writethrough, writeback,  writearound  or
                   none.

                 * force -- Overwrite existing bcaches

                 * attach  -- Immediately attach the backing device to the
                   set

                 * bucket_size -- Size of a bucket (see kernel doc)

   salt.modules.bcache.cache_make(dev,     reserved=None,     force=False,
   block_size=None, bucket_size=None, attach=True)
          Create  BCache  cache  on  a  block  device.   If  blkdiscard is
          available the entire device will be properly cleared in advance.

          CLI example:

             salt '*' bcache.cache_make sdb reserved=10% block_size=4096

          Parameters

                 * reserved --

                   if dev is a full device, create a partition table  with
                   this size empty.

                   NOTE:
                      this   increases   the   amount  of  reserved  space
                      available to  SSD  garbage  collectors,  potentially
                      (vastly) increasing performance

                 * block_size  --  Block  size  of  the cache; defaults to
                   devices' logical block size

                 * force -- Overwrite existing BCache sets

                 * attach  --  Attach   all   existing   backend   devices
                   immediately

   salt.modules.bcache.config(dev=None, **kwargs)
          Show or update config of a bcache device.

          If no device is given, operate on the cache set itself.

          CLI example:

             salt '*' bcache.config
             salt '*' bcache.config bcache1
             salt '*' bcache.config errors=panic journal_delay_ms=150
             salt '*' bcache.config bcache1 cache_mode=writeback writeback_percent=15

          Returns
                 config or True/False

   salt.modules.bcache.detach(dev=None)
          Detach  a backing device(s) from a cache set If no dev is given,
          all backing devices will be attached.

          Detaching a backing device will flush it's  write  cache.   This
          should  leave  the  underlying device in a consistent state, but
          might take a while.

          CLI example:

             salt '*' bcache.detach sdc
             salt '*' bcache.detach bcache1

   salt.modules.bcache.device(dev,       stats=False,        config=False,
   internals=False, superblock=False)
          Check the state of a single bcache device

          CLI example:

             salt '*' bcache.device bcache0
             salt '*' bcache.device /dev/sdc stats=True

          Parameters

                 * stats -- include statistics

                 * settings -- include all settings

                 * internals -- include all internals

                 * superblock -- include superblock info

   salt.modules.bcache.start()
          Trigger a start of the full bcache system through udev.

          CLI example:

             salt '*' bcache.start

   salt.modules.bcache.status(stats=False,  config=False, internals=False,
   superblock=False, alldevs=False)
          Show the full status of the BCache  system  and  optionally  all
          it's involved devices

          CLI example:

             salt '*' bcache.status
             salt '*' bcache.status stats=True
             salt '*' bcache.status internals=True alldevs=True

          Parameters

                 * stats -- include statistics

                 * config -- include settings

                 * internals -- include internals

                 * superblock -- include superblock

   salt.modules.bcache.stop(dev=None)
          Stop  a bcache device If no device is given, all backing devices
          will be detached from the  cache,  which  will  subsequently  be
          stopped.

          WARNING:
             'Stop'  on  an  individual backing device means hard-stop; no
             attempt at flushing will be done and the bcache  device  will
             seemingly 'disappear' from the device lists

          CLI example:

             salt '*' bcache.stop

   salt.modules.bcache.super(dev)
          Read out BCache SuperBlock

          CLI example:

             salt '*' bcache.device bcache0
             salt '*' bcache.device /dev/sdc

   salt.modules.bcache.uuid(dev=None)
          Return  the  bcache  UUID  of  a  block device.  If no device is
          given, the Cache UUID is returned.

          CLI example:

             salt '*' bcache.uuid
             salt '*' bcache.uuid /dev/sda
             salt '*' bcache.uuid bcache0

   salt.modules.beacons
   Module for managing the Salt beacons on a minion

   New in version 2015.8.0.

   salt.modules.beacons.add(name, beacon_data, **kwargs)
          Add a beacon on the minion

          Parameters

                 * name -- Name of the beacon to configure

                 * beacon_data   --   Dictionary   or   list    containing
                   configuration for beacon.

          Returns
                 Boolean and status message on success or failure of add.

          CLI Example:

             salt '*' beacons.add ps "{'salt-master': 'stopped', 'apache2': 'stopped'}"

   salt.modules.beacons.delete(name, **kwargs)
          Delete a beacon item

          Parameters
                 name -- Name of the beacon to delete

          Returns
                 Boolean  and  status  message  on  success  or failure of
                 delete.

          CLI Example:

             salt '*' beacons.delete ps

             salt '*' beacons.delete load

   salt.modules.beacons.disable(**kwargs)
          Disable all beaconsd jobs on the minion

          Returns
                 Boolean and status  message  on  success  or  failure  of
                 disable.

          CLI Example:

             salt '*' beacons.disable

   salt.modules.beacons.disable_beacon(name, **kwargs)
          Disable beacon on the minion

          Name   Name of the beacon to disable.

          Returns
                 Boolean  and  status  message  on  success  or failure of
                 disable.

          CLI Example:

             salt '*' beacons.disable_beacon ps

   salt.modules.beacons.enable(**kwargs)
          Enable all beacons on the minion

          Returns
                 Boolean and status  message  on  success  or  failure  of
                 enable.

          CLI Example:

             salt '*' beacons.enable

   salt.modules.beacons.enable_beacon(name, **kwargs)
          Enable beacon on the minion

          Name   Name of the beacon to enable.

          Returns
                 Boolean  and  status  message  on  success  or failure of
                 enable.

          CLI Example:

             salt '*' beacons.enable_beacon ps

   salt.modules.beacons.list(return_yaml=True)
          List the beacons currently configured on the minion

          Parameters
                 return_yaml -- Whether to return YAML  formatted  output,
                 default True

          Returns
                 List of currently configured Beacons.

          CLI Example:

             salt '*' beacons.list

   salt.modules.beacons.modify(name, beacon_data, **kwargs)
          Modify an existing beacon

          Parameters

                 * name -- Name of the beacon to configure

                 * beacon_data  --  Dictionary  or list containing updated
                   configuration for beacon.

          Returns
                 Boolean and status  message  on  success  or  failure  of
                 modify.

          CLI Example:

             salt '*' beacons.modify ps "{'salt-master': 'stopped', 'apache2': 'stopped'}"

   salt.modules.beacons.save()
          Save all beacons on the minion

          Returns
                 Boolean and status message on success or failure of save.

          CLI Example:

             salt '*' beacons.save

   salt.modules.bigip
   An execution module which can manipulate an f5 bigip via iControl REST

          maturity
                 develop

          platform
                 f5_bigip_11.6

   salt.modules.bigip.add_pool_member(hostname,  username, password, name,
   member)
          A function to connect to a bigip device and add a new member  to
          an existing pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          member The name of the member to add i.e. 10.1.1.2:80

          CLI Example:

             salt '*' bigip.add_pool_members bigip admin admin my-pool 10.2.2.1:80

   salt.modules.bigip.commit_transaction(hostname,   username,   password,
   label)
          A function to connect to a bigip device and commit  an  existing
          transaction.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          label  the  label  of  this transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.commit_transaction bigip admin admin my_transaction

   salt.modules.bigip.create_monitor(hostname,     username,     password,
   monitor_type, name, **kwargs)
          A function to connect to a bigip device and create a monitor.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to create

          name   The name of the monitor to create

          kwargs Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

          CLI Example:

             salt '*' bigip.create_monitor bigip admin admin http my-http-monitor timeout=10 interval=5

   salt.modules.bigip.create_node(hostname,  username,   password,   name,
   address, trans_label=None)
          A function to connect to a bigip device and create a node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node

          address
                 The address of the node

          trans_label
                 The  label  of  the  transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.create_node bigip admin admin 10.1.1.2

   salt.modules.bigip.create_pool(hostname,  username,   password,   name,
   members=None,    allow_nat=None,   allow_snat=None,   description=None,
   gateway_failsafe_device=None,             ignore_persisted_weight=None,
   ip_tos_to_client=None,  ip_tos_to_server=None, link_qos_to_client=None,
   link_qos_to_server=None,                      load_balancing_mode=None,
   min_active_members=None,                           min_up_members=None,
   min_up_members_action=None, min_up_members_checking=None, monitor=None,
   profiles=None,  queue_depth_limit=None, queue_on_connection_limit=None,
   queue_time_limit=None,  reselect_tries=None,  service_down_action=None,
   slow_ramp_time=None)
          A function to connect to a bigip device and create a pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to create.

          members
                 List  of comma delimited pool members to add to the pool.
                 i.e. 10.1.1.1:80,10.1.1.2:80,10.1.1.3:80

          allow_nat
                 [yes | no]

          allow_snat
                 [yes | no]

          description
                 [string]

          gateway_failsafe_device
                 [string]

          ignore_persisted_weight
                 [enabled | disabled]

          ip_tos_to_client
                 [pass-through | [integer]]

          ip_tos_to_server
                 [pass-through | [integer]]

          link_qos_to_client
                 [pass-through | [integer]]

          link_qos_to_server
                 [pass-through | [integer]]

          load_balancing_mode
                 [dynamic-ratio-member     |     dynamic-ratio-node      |
                 fastest-app-response        |        fastest-node       |
                 least-connections-members  |   least-connections-node   |
                 least-sessions   |   observed-member  |  observed-node  |
                 predictive-member       |        predictive-node        |
                 ratio-least-connections-member                          |
                 ratio-least-connections-node | ratio-member |  ratio-node
                 |        ratio-session        |       round-robin       |
                 weighted-least-connections-member                       |
                 weighted-least-connections-node]

          min_active_members
                 [integer]

          min_up_members
                 [integer]

          min_up_members_action
                 [failover | reboot | restart-all]

          min_up_members_checking
                 [enabled | disabled]

          monitor
                 [name]

          profiles
                 [none | profile_name]

          queue_depth_limit
                 [integer]

          queue_on_connection_limit
                 [enabled | disabled]

          queue_time_limit
                 [integer]

          reselect_tries
                 [integer]

          service_down_action
                 [drop | none | reselect | reset]

          slow_ramp_time
                 [integer]

          CLI Example:

             salt '*' bigip.create_pool bigip admin admin my-pool 10.1.1.1:80,10.1.1.2:80,10.1.1.3:80 monitor=http

   salt.modules.bigip.create_profile(hostname,     username,     password,
   profile_type, name, **kwargs)
          A function to connect to a bigip device and create a profile.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ... [arg=key1:val1,key2:val2] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

          Creating Complex Args
                 Profiles  can  get  pretty  complicated  in  terms of the
                 amount of possible  config  options.  Use  the  following
                 shorthand  to  create  complex  arguments  such as lists,
                 dictionaries, and lists of  dictionaries.  An  option  is
                 also provided to pass raw json as well.

                 lists [i,i,i]:
                        param='item1,item2,item3'

                 Dictionary [k:v,k:v,k,v]:
                        param='key-1:val-1,key-2:val2,key-3:va-3'

                 List of Dictionaries [k:v,k:v|k:v,k:v|k:v,k:v]:
                        param='key-1:val-1,key-2:val-2|key-1:val-1,key-2:val-2|key-1:val-1,key-2:val-2'

                 JSON: 'j{ ... }j':
                        cert-key-chain='j{    "default":     {     "cert":
                        "default.crt",   "chain":   "default.crt",  "key":
                        "default.key" } }j'

                 Escaping Delimiters:
                        Use \, or \: or  \|  to  escape  characters  which
                        shouldn't    be   treated   as   delimiters   i.e.
                        ciphers='DEFAULT\:!SSLv3'

          CLI Examples:

             salt '*' bigip.create_profile bigip admin admin http my-http-profile defaultsFrom='/Common/http'
             salt '*' bigip.create_profile bigip admin admin http my-http-profile defaultsFrom='/Common/http' \
                 enforcement=maxHeaderCount:3200,maxRequests:10

   salt.modules.bigip.create_virtual(hostname, username,  password,  name,
   destination,    pool=None,    address_status=None,   auto_lasthop=None,
   bwc_policy=None,        cmp_enabled=None,        connection_limit=None,
   dhcp_relay=None,      description=None,      fallback_persistence=None,
   flow_eviction_policy=None,       gtm_score=None,       ip_forward=None,
   ip_protocol=None,          internal=None,          twelve_forward=None,
   last_hop_pool=None, mask=None, mirror=None,  nat64=None,  persist=None,
   profiles=None,    policies=None,    rate_class=None,   rate_limit=None,
   rate_limit_mode=None,     rate_limit_dst=None,     rate_limit_src=None,
   rules=None,      related_rules=None,      reject=None,     source=None,
   source_address_translation=None,     source_port=None,      state=None,
   traffic_classes=None,    translate_address=None,   translate_port=None,
   vlans=None)
          A function to connect to a bigip device  and  create  a  virtual
          server.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to create

          destination
                 [ [virtual_address_name:port] | [ipv4:port] | [ipv6.port]
                 ]

          pool   [ [pool_name] | none]

          address_status
                 [yes | no]

          auto_lasthop
                 [default | enabled | disabled ]

          bwc_policy
                 [none] | string]

          cmp_enabled
                 [yes | no]

          dhcp_relay
                 [yes | no]

          connection_limit
                 [integer]

          description
                 [string]

          state  [disabled | enabled]

          fallback_persistence
                 [none | [profile name] ]

          flow_eviction_policy
                 [none | [eviction policy name] ]

          gtm_score
                 [integer]

          ip_forward
                 [yes | no]

          ip_protocol
                 [any | protocol]

          internal
                 [yes | no]

          twelve_forward
                 (12-forward) [yes | no]

          last_hop-pool
                 [ [pool_name] | none]

          mask   { [ipv4] | [ipv6] }

          mirror { [disabled | enabled | none] }

          nat64  [enabled | disabled]

          persist
                 [none | profile1,profile2,profile3 ... ]

          profiles
                 [none | default | profile1,profile2,profile3 ... ]

          policies
                 [none | default | policy1,policy2,policy3 ... ]

          rate_class
                 [name]

          rate_limit
                 [integer]

          rate_limit_mode
                 [destination   |   object    |    object-destination    |
                 object-source  |  object-source-destination  |  source  |
                 source-destination]

          rate_limit_dst
                 [integer]

          rate_limitsrc
                 [integer]

          rules  [none | [rule_one,rule_two ...] ]

          related_rules
                 [none | [rule_one,rule_two ...] ]

          reject [yes | no]

          source { [ipv4[/prefixlen]] | [ipv6[/prefixlen]] }

          source_address_translation
                 [none | snat:pool_name | lsn | automap ]

          source_port
                 [change | preserve | preserve-strict]

          state  [enabled | disabled]

          traffic_classes
                 [none | default | class_one,class_two ... ]

          translate_address
                 [enabled | disabled]

          translate_port
                 [enabled | disabled]

          vlans  [none |  default  |  [enabled|disabled]:vlan1,vlan2,vlan3
                 ... ]

          CLI Examples:

             salt '*' bigip.create_virtual bigip admin admin my-virtual-3 26.2.2.5:80 \
                 pool=my-http-pool-http profiles=http,tcp

             salt '*' bigip.create_virtual bigip admin admin my-virtual-3 43.2.2.5:80 \
                 pool=test-http-pool-http profiles=http,websecurity persist=cookie,hash \
                 policies=asm_auto_l7_policy__http-virtual \
                 rules=_sys_APM_ExchangeSupport_helper,_sys_https_redirect \
                 related_rules=_sys_APM_activesync,_sys_APM_ExchangeSupport_helper \
                 source_address_translation=snat:my-snat-pool \
                 translate_address=enabled translate_port=enabled \
                 traffic_classes=my-class,other-class \
                 vlans=enabled:external,internal

   salt.modules.bigip.delete_monitor(hostname,     username,     password,
   monitor_type, name)
          A function to connect to a bigip device and delete  an  existing
          monitor.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to delete

          name   The name of the monitor to delete

          CLI Example:

             salt '*' bigip.delete_monitor bigip admin admin http my-http-monitor

   salt.modules.bigip.delete_node(hostname,   username,   password,  name,
   trans_label=None)
          A function to connect to a bigip device and  delete  a  specific
          node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node which will be deleted.

          trans_label
                 The  label  of  the  transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.delete_node bigip admin admin my-node

   salt.modules.bigip.delete_pool(hostname, username, password, name)
          A function to connect to a bigip device and  delete  a  specific
          pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool which will be deleted

          CLI Example:

             salt '*' bigip.delete_node bigip admin admin my-pool

   salt.modules.bigip.delete_pool_member(hostname,   username,   password,
   name, member)
          A function to connect to a bigip device and  delete  a  specific
          pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          member The name of the pool member to delete

          CLI Example:

             salt '*' bigip.delete_node bigip admin admin my-pool 10.2.2.2:80

   salt.modules.bigip.delete_profile(hostname,     username,     password,
   profile_type, name)
          A function to connect to a bigip device and delete  an  existing
          profile.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to delete

          name   The name of the profile to delete

          CLI Example:

             salt '*' bigip.delete_profile bigip admin admin http my-http-profile

   salt.modules.bigip.delete_transaction(hostname,   username,   password,
   label)
          A function to connect to a bigip device and delete  an  existing
          transaction.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          label  The  label  of  this transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.delete_transaction bigip admin admin my_transaction

   salt.modules.bigip.delete_virtual(hostname, username, password, name)
          A function to connect to a bigip device and  delete  a  specific
          virtual.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to delete

          CLI Example:

             salt '*' bigip.delete_virtual bigip admin admin my-virtual

   salt.modules.bigip.list_monitor(hostname,      username,      password,
   monitor_type, name=None)
          A function to connect to a bigip device  and  list  an  existing
          monitor.   If  no  name  is  provided  than  all monitors of the
          specified type will be listed.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor(s) to list

          name   The name of the monitor to list

          CLI Example:

             salt '*' bigip.list_monitor bigip admin admin http my-http-monitor

   salt.modules.bigip.list_node(hostname, username,  password,  name=None,
   trans_label=None)
          A  function to connect to a bigip device and list all nodes or a
          specific node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to list. If  no  name  is  specified
                 than all nodes will be listed.

          trans_label
                 The  label  of  the  transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.list_node bigip admin admin my-node

   salt.modules.bigip.list_pool(hostname, username, password, name=None)
          A function to connect to a bigip device and list all pools or  a
          specific pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The  name  of  the  pool to list. If no name is specified
                 then all pools will be listed.

          CLI Example:

             salt '*' bigip.list_pool bigip admin admin my-pool

   salt.modules.bigip.list_profile(hostname,      username,      password,
   profile_type, name=None)
          A  function  to  connect  to a bigip device and list an existing
          profile.  If no name  is  provided  than  all  profiles  of  the
          specified type will be listed.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile(s) to list

          name   The name of the profile to list

          CLI Example:

             salt '*' bigip.list_profile bigip admin admin http my-http-profile

   salt.modules.bigip.list_transaction(hostname,    username,    password,
   label)
          A function to connect to a bigip device  and  list  an  existing
          transaction.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          label  the  label  of  this transaction stored within the grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.list_transaction bigip admin admin my_transaction

   salt.modules.bigip.list_virtual(hostname,      username,      password,
   name=None)
          A function to connect to a bigip device and list all virtuals or
          a specific virtual.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to list. If no name is  specified
                 than all virtuals will be listed.

          CLI Example:

             salt '*' bigip.list_virtual bigip admin admin my-virtual

   salt.modules.bigip.modify_monitor(hostname,     username,     password,
   monitor_type, name, **kwargs)
          A function to connect to a bigip device and modify  an  existing
          monitor.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to modify

          name   The name of the monitor to modify

          kwargs Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

          CLI Example:

             salt '*' bigip.modify_monitor bigip admin admin http my-http-monitor  timout=16 interval=6

   salt.modules.bigip.modify_node(hostname,  username,   password,   name,
   connection_limit=None,       description=None,      dynamic_ratio=None,
   logging=None, monitor=None, rate_limit=None, ratio=None,  session=None,
   state=None, trans_label=None)
          A  function  to connect to a bigip device and modify an existing
          node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to modify

          connection_limit
                 [integer]

          description
                 [string]

          dynamic_ratio
                 [integer]

          logging
                 [enabled | disabled]

          monitor
                 [[name] | none | default]

          rate_limit
                 [integer]

          ratio  [integer]

          session
                 [user-enabled | user-disabled]

          state  [user-down | user-up ]

          trans_label
                 The label of the transaction  stored  within  the  grain:
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.modify_node bigip admin admin 10.1.1.2 ratio=2 logging=enabled

   salt.modules.bigip.modify_pool(hostname,   username,   password,  name,
   allow_nat=None,           allow_snat=None,            description=None,
   gateway_failsafe_device=None,             ignore_persisted_weight=None,
   ip_tos_to_client=None, ip_tos_to_server=None,  link_qos_to_client=None,
   link_qos_to_server=None,                      load_balancing_mode=None,
   min_active_members=None,                           min_up_members=None,
   min_up_members_action=None, min_up_members_checking=None, monitor=None,
   profiles=None, queue_depth_limit=None,  queue_on_connection_limit=None,
   queue_time_limit=None,  reselect_tries=None,  service_down_action=None,
   slow_ramp_time=None)
          A function to connect to a bigip device and modify  an  existing
          pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify.

          allow_nat
                 [yes | no]

          allow_snat
                 [yes | no]

          description
                 [string]

          gateway_failsafe_device
                 [string]

          ignore_persisted_weight
                 [yes | no]

          ip_tos_to_client
                 [pass-through | [integer]]

          ip_tos_to_server
                 [pass-through | [integer]]

          link_qos_to_client
                 [pass-through | [integer]]

          link_qos_to_server
                 [pass-through | [integer]]

          load_balancing_mode
                 [dynamic-ratio-member      |     dynamic-ratio-node     |
                 fastest-app-response       |        fastest-node        |
                 least-connections-members   |   least-connections-node  |
                 least-sessions  |  observed-member  |   observed-node   |
                 predictive-member        |        predictive-node       |
                 ratio-least-connections-member                          |
                 ratio-least-connections-node  | ratio-member | ratio-node
                 |       ratio-session       |        round-robin        |
                 weighted-least-connections-member                       |
                 weighted-least-connections-node]

          min_active_members
                 [integer]

          min_up_members
                 [integer]

          min_up_members_action
                 [failover | reboot | restart-all]

          min_up_members_checking
                 [enabled | disabled]

          monitor
                 [name]

          profiles
                 [none | profile_name]

          queue_on_connection_limit
                 [enabled | disabled]

          queue_depth_limit
                 [integer]

          queue_time_limit
                 [integer]

          reselect_tries
                 [integer]

          service_down_action
                 [drop | none | reselect | reset]

          slow_ramp_time
                 [integer]

          CLI Example:

             salt '*' bigip.modify_pool bigip admin admin my-pool 10.1.1.1:80,10.1.1.2:80,10.1.1.3:80 min_active_members=1

   salt.modules.bigip.modify_pool_member(hostname,   username,   password,
   name,       member,       connection_limit=None,      description=None,
   dynamic_ratio=None, inherit_profile=None,  logging=None,  monitor=None,
   priority_group=None,    profiles=None,   rate_limit=None,   ratio=None,
   session=None, state=None)
          A function to connect to a bigip device and modify  an  existing
          member of a pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          member The name of the member to modify i.e. 10.1.1.2:80

          connection_limit
                 [integer]

          description
                 [string]

          dynamic_ratio
                 [integer]

          inherit_profile
                 [enabled | disabled]

          logging
                 [enabled | disabled]

          monitor
                 [name]

          priority_group
                 [integer]

          profiles
                 [none | profile_name]

          rate_limit
                 [integer]

          ratio  [integer]

          session
                 [user-enabled | user-disabled]

          state  [ user-up | user-down ]

          CLI Example:

             salt '*' bigip.modify_pool_member bigip admin admin my-pool 10.2.2.1:80 state=use-down session=user-disabled

   salt.modules.bigip.modify_profile(hostname,     username,     password,
   profile_type, name, **kwargs)
          A function to connect to a bigip device and create a profile.

          A function to connect to a bigip device and create a profile.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ... [arg=key1:val1,key2:val2] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

          Creating Complex Args
             Profiles can get pretty complicated in terms of the amount of
             possible config  options.  Use  the  following  shorthand  to
             create  complex  arguments  such  as lists, dictionaries, and
             lists of dictionaries. An option is also provided to pass raw
             json as well.

             lists [i,i,i]:
                    param='item1,item2,item3'

             Dictionary [k:v,k:v,k,v]:
                    param='key-1:val-1,key-2:val2,key-3:va-3'

             List of Dictionaries [k:v,k:v|k:v,k:v|k:v,k:v]:
                    param='key-1:val-1,key-2:val-2|key-1:val-1,key-2:val-2|key-1:val-1,key-2:val-2'

             JSON: 'j{ ... }j':
                    cert-key-chain='j{ "default": { "cert": "default.crt",
                    "chain": "default.crt", "key": "default.key" } }j'

             Escaping Delimiters:
                    Use  \,  or  \:  or  \|  to  escape  characters  which
                    shouldn't    be    treated    as    delimiters    i.e.
                    ciphers='DEFAULT\:!SSLv3'

          CLI Examples:

             salt '*' bigip.modify_profile bigip admin admin http my-http-profile defaultsFrom='/Common/http'

             salt '*' bigip.modify_profile bigip admin admin http my-http-profile defaultsFrom='/Common/http' \
                 enforcement=maxHeaderCount:3200,maxRequests:10

             salt '*' bigip.modify_profile bigip admin admin client-ssl my-client-ssl-1 retainCertificate=false \
                 ciphers='DEFAULT\:!SSLv3'
                 cert_key_chain='j{ "default": { "cert": "default.crt", "chain": "default.crt", "key": "default.key" } }j'

   salt.modules.bigip.modify_virtual(hostname,  username,  password, name,
   destination=None,  pool=None,  address_status=None,  auto_lasthop=None,
   bwc_policy=None,        cmp_enabled=None,        connection_limit=None,
   dhcp_relay=None,      description=None,      fallback_persistence=None,
   flow_eviction_policy=None,       gtm_score=None,       ip_forward=None,
   ip_protocol=None,          internal=None,          twelve_forward=None,
   last_hop_pool=None,  mask=None,  mirror=None, nat64=None, persist=None,
   profiles=None,   policies=None,    rate_class=None,    rate_limit=None,
   rate_limit_mode=None,     rate_limit_dst=None,     rate_limit_src=None,
   rules=None,     related_rules=None,      reject=None,      source=None,
   source_address_translation=None,      source_port=None,     state=None,
   traffic_classes=None,   translate_address=None,    translate_port=None,
   vlans=None)
          A  function  to connect to a bigip device and modify an existing
          virtual server.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to modify

          destination
                 [ [virtual_address_name:port] | [ipv4:port] | [ipv6.port]
                 ]

          pool   [ [pool_name] | none]

          address_status
                 [yes | no]

          auto_lasthop
                 [default | enabled | disabled ]

          bwc_policy
                 [none] | string]

          cmp_enabled
                 [yes | no]

          dhcp_relay
                 [yes | no}

          connection_limit
                 [integer]

          description
                 [string]

          state  [disabled | enabled]

          fallback_persistence
                 [none | [profile name] ]

          flow_eviction_policy
                 [none | [eviction policy name] ]

          gtm_score
                 [integer]

          ip_forward
                 [yes | no]

          ip_protocol
                 [any | protocol]

          internal
                 [yes | no]

          twelve_forward
                 (12-forward) [yes | no]

          last_hop-pool
                 [ [pool_name] | none]

          mask   { [ipv4] | [ipv6] }

          mirror { [disabled | enabled | none] }

          nat64  [enabled | disabled]

          persist
                 [none | profile1,profile2,profile3 ... ]

          profiles
                 [none | default | profile1,profile2,profile3 ... ]

          policies
                 [none | default | policy1,policy2,policy3 ... ]

          rate_class
                 [name]

          rate_limit
                 [integer]

          rate_limitr_mode
                 [destination    |    object    |   object-destination   |
                 object-source  |  object-source-destination  |  source  |
                 source-destination]

          rate_limit_dst
                 [integer]

          rate_limit_src
                 [integer]

          rules  [none | [rule_one,rule_two ...] ]

          related_rules
                 [none | [rule_one,rule_two ...] ]

          reject [yes | no]

          source { [ipv4[/prefixlen]] | [ipv6[/prefixlen]] }

          source_address_translation
                 [none | snat:pool_name | lsn | automap ]

          source_port
                 [change | preserve | preserve-strict]

          state  [enabled | disable]

          traffic_classes
                 [none | default | class_one,class_two ... ]

          translate_address
                 [enabled | disabled]

          translate_port
                 [enabled | disabled]

          vlans  [none  |  default  | [enabled|disabled]:vlan1,vlan2,vlan3
                 ... ]

          CLI Example:

             salt '*' bigip.modify_virtual bigip admin admin my-virtual source_address_translation=none
             salt '*' bigip.modify_virtual bigip admin admin my-virtual rules=my-rule,my-other-rule

   salt.modules.bigip.replace_pool_members(hostname,  username,  password,
   name, members)
          A  function  to connect to a bigip device and replace members of
          an existing pool with new members.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          members
                 List of comma delimited pool members to replace  existing
                 members with.  i.e. 10.1.1.1:80,10.1.1.2:80,10.1.1.3:80

          CLI Example:

             salt '*' bigip.replace_pool_members bigip admin admin my-pool 10.2.2.1:80,10.2.2.2:80,10.2.2.3:80

   salt.modules.bigip.start_transaction(hostname,    username,   password,
   label)
          A function to  connect  to  a  bigip  device  and  start  a  new
          transaction.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          label  The  name  /  alias  for  this  transaction.   The actual
                 transaction id will  be  stored  within  a  grain  called
                 bigip_f5_trans:<label>

          CLI Example:

             salt '*' bigip.start_transaction bigip admin admin my_transaction

   salt.modules.blockdev
   Module for managing block devices

   New in version 2014.7.0.

   Deprecated since version 2016.11.0: Merged to disk module

   salt.modules.blockdev.format(device,  fs_type='ext4',  inode_size=None,
   lazy_itable_init=None, force=False)
          Format a filesystem onto a block device

          New in version 2015.8.2.

          Deprecated since version 2016.11.0.

          device The block device in which to create the new filesystem

          fs_type
                 The type of filesystem to create

          inode_size
                 Size of the inodes

                 This option is only enabled for ext and xfs filesystems

          lazy_itable_init
                 If enabled and the  uninit_bg  feature  is  enabled,  the
                 inode  table  will  not  be  fully initialized by mke2fs.
                 This speeds up filesystem initialization noticeably,  but
                 it   requires  the  kernel  to  finish  initializing  the
                 filesystem  in  the  background  when  the filesystem  is
                 first  mounted.   If  the  option  value  is  omitted, it
                 defaults to 1 to enable lazy inode table zeroing.

                 This option is only enabled for ext filesystems

          force  Force  mke2fs  to  create  a  filesystem,  even  if   the
                 specified  device  is  not a partition on a block special
                 device. This option is  only  enabled  for  ext  and  xfs
                 filesystems

                 This option is dangerous, use it with caution.

                 New in version 2016.11.0.

          CLI Example:

             salt '*' blockdev.format /dev/sdX1

   salt.modules.blockdev.fstype(device)
          Return the filesystem name of a block device

          New in version 2015.8.2.

          Deprecated since version 2016.11.0.

          device The name of the block device

          CLI Example:

             salt '*' blockdev.fstype /dev/sdX1

   salt.modules.bluez
   Support for Bluetooth (using BlueZ in Linux).

   The following packages are required packages for this module:
      bluez >= 5.7 bluez-libs >= 5.7 bluez-utils >= 5.7 pybluez >= 0.18

   salt.modules.bluez.address()
          Get the many addresses of the Bluetooth adapter

          CLI Example:

             salt '*' bluetooth.address

   salt.modules.bluez.block(bdaddr)
          Block a specific bluetooth device by BD Address

          CLI Example:

             salt '*' bluetooth.block DE:AD:BE:EF:CA:FE

   salt.modules.bluez.discoverable(dev)
          Enable this bluetooth device to be discoverable.

          CLI Example:

             salt '*' bluetooth.discoverable hci0

   salt.modules.bluez.noscan(dev)
          Turn off scanning modes on this device.

          CLI Example:

             salt '*' bluetooth.noscan hci0

   salt.modules.bluez.pair(address, key)
          Pair the bluetooth adapter with a device

          CLI Example:

             salt '*' bluetooth.pair DE:AD:BE:EF:CA:FE 1234

          Where  DE:AD:BE:EF:CA:FE  is  the  address of the device to pair
          with, and 1234 is the passphrase.

          TODO:   This   function   is   currently    broken,    as    the
          bluez-simple-agent program no longer ships with BlueZ >= 5.0. It
          needs to be refactored.

   salt.modules.bluez.power(dev, mode)
          Power a bluetooth device on or off

          CLI Examples:

             salt '*' bluetooth.power hci0 on
             salt '*' bluetooth.power hci0 off

   salt.modules.bluez.scan()
          Scan for bluetooth devices in the area

          CLI Example:

             salt '*' bluetooth.scan

   salt.modules.bluez.start()
          Start the bluetooth service.

          CLI Example:

             salt '*' bluetooth.start

   salt.modules.bluez.stop()
          Stop the bluetooth service.

          CLI Example:

             salt '*' bluetooth.stop

   salt.modules.bluez.unblock(bdaddr)
          Unblock a specific bluetooth device by BD Address

          CLI Example:

             salt '*' bluetooth.unblock DE:AD:BE:EF:CA:FE

   salt.modules.bluez.unpair(address)
          Unpair the bluetooth adapter from a device

          CLI Example:

             salt '*' bluetooth.unpair DE:AD:BE:EF:CA:FE

          Where DE:AD:BE:EF:CA:FE is the address of the device to unpair.

          TODO:   This   function   is   currently    broken,    as    the
          bluez-simple-agent program no longer ships with BlueZ >= 5.0. It
          needs to be refactored.

   salt.modules.bluez.version()
          Return Bluez version from bluetoothd -v

          CLI Example:

             salt '*' bluetoothd.version

   salt.modules.boto_apigateway module
   Connection module for Amazon APIGateway

   configuration
          This module accepts explicit Lambda  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the  instance trough Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             apigateway.keyid: GKTADJGHEIQSXMKKRBJ08H
             apigateway.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             apigateway.region: us-west-2

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-west-2

   Changed  in  version  2015.8.0:  All  methods  now return a dictionary.
   Create and delete methods return:

      created: true

   or

      created: false
      error:
        message: error message

   Request methods (e.g., describe_apigateway) return:

      apigateway:
        - {...}
        - {...}

   or

      error:
        message: error message

   depends
          boto3

   salt.modules.boto_apigateway.activate_api_deployment(restApiId,
   stageName,    deploymentId,    region=None,    key=None,    keyid=None,
   profile=None)
          Activates previously deployed deployment for a given stage

          CLI Example:

             salt myminion boto_apigateway.activate_api_deployent restApiId stagename deploymentId

   salt.modules.boto_apigateway.api_exists(name,         description=None,
   region=None, key=None, keyid=None, profile=None)
          Check   to  see  if  the  given  Rest  API  Name  and  optionlly
          description exists.

          CLI Example:

             salt myminion boto_apigateway.exists myapi_name

   salt.modules.boto_apigateway.api_model_exists(restApiId,     modelName,
   region=None, key=None, keyid=None, profile=None)
          Check  to  see  if  the  given  modelName  exists  in  the given
          restApiId

          CLI Example:

             salt myminion boto_apigateway.api_model_exists restApiId modelName

   salt.modules.boto_apigateway.associate_api_key_stagekeys(apiKey,
   stagekeyslist, region=None, key=None, keyid=None, profile=None)
          associate the given stagekeyslist to the given apiKey.

          CLI Example:

             salt myminion boto_apigateway.associate_stagekeys_api_key \
                     api_key '["restapi id/stage name", ...]'

   salt.modules.boto_apigateway.create_api(name,              description,
   cloneFrom=None, region=None, key=None, keyid=None, profile=None)
          Create a new REST API Service with the given name

          Returns {created: True} if the rest api was created and  returns
          {created: False} if the rest api was not created.

          CLI Example:

             salt myminion boto_apigateway.create_api myapi_name api_description

   salt.modules.boto_apigateway.create_api_deployment(restApiId,
   stageName,             stageDescription='',             description='',
   cacheClusterEnabled=False,    cacheClusterSize='0.5',   variables=None,
   region=None, key=None, keyid=None, profile=None)
          Creates a new API deployment.

          CLI Example:

             salt myminion boto_apigateway.create_api_deployent restApiId stagename stageDescription='' \
             description='' cacheClusterEnabled=True|False cacheClusterSize=0.5 variables='{"name": "value"}'

   salt.modules.boto_apigateway.create_api_integration(restApiId,
   resourcePath,  httpMethod, integrationType, integrationHttpMethod, uri,
   credentials,       requestParameters=None,       requestTemplates=None,
   region=None, key=None, keyid=None, profile=None)
          Creates  an  integration  for a given method in a given API.  If
          integrationType is MOCK, uri and credential parameters  will  be
          ignored.

          uri   is  in  the  form  of  (substitute  APIGATEWAY_REGION  and
          LAMBDA_FUNC_ARN)
          "arn:aws:apigateway:APIGATEWAY_REGION:lambda:path/2015-03-31/functions/LAMBDA_FUNC_ARN/invocations"

          credentials is in the form of an iam role name or role arn.

          CLI Example:

             salt myminion boto_apigateway.create_api_integration restApiId resourcePath httpMethod \
                                  integrationType integrationHttpMethod uri credentials ['{}' ['{}']]

   salt.modules.boto_apigateway.create_api_integration_response(restApiId,
   resourcePath,       httpMethod,      statusCode,      selectionPattern,
   responseParameters=None, responseTemplates=None, region=None, key=None,
   keyid=None, profile=None)
          Creates  an  integration  response for a given method in a given
          API

          CLI Example:

             salt myminion boto_apigateway.create_api_integration_response restApiId resourcePath httpMethod \
                                 statusCode selectionPattern ['{}' ['{}']]

   salt.modules.boto_apigateway.create_api_key(name,          description,
   enabled=True,   stageKeys=None,   region=None,   key=None,  keyid=None,
   profile=None)
          Create an API key given name and description.

          An optional enabled argument can be provided.  If provided,  the
          valid values are True|False.  This argument defaults to True.

          An  optional  stageKeys  argument can be provided in the form of
          list of dictionary with 'restApiId' and 'stageName' as keys.

          CLI Example:

             salt myminion boto_apigateway.create_api_key name description

             salt myminion boto_apigateway.create_api_key name description enabled=False

             salt myminion boto_apigateway.create_api_key name description \
                  stageKeys='[{"restApiId": "id", "stageName": "stagename"}]'

   salt.modules.boto_apigateway.create_api_method(restApiId, resourcePath,
   httpMethod,           authorizationType,          apiKeyRequired=False,
   requestParameters=None,  requestModels=None,   region=None,   key=None,
   keyid=None, profile=None)
          Creates API method for a resource in the given API

          CLI Example:

             salt myminion boto_apigateway.create_api_method restApiId resourcePath, httpMethod, authorizationType, \
                 apiKeyRequired=False, requestParameters='{"name", "value"}', requestModels='{"content-type", "value"}'

   salt.modules.boto_apigateway.create_api_method_response(restApiId,
   resourcePath,    httpMethod,    statusCode,    responseParameters=None,
   responseModels=None, region=None, key=None, keyid=None, profile=None)
          Create  API  method response for a method on a given resource in
          the given API

          CLI Example:

             salt myminion boto_apigateway.create_api_method_response restApiId resourcePath httpMethod \
                    statusCode responseParameters='{"name", "True|False"}' responseModels='{"content-type", "model"}'

   salt.modules.boto_apigateway.create_api_model(restApiId,     modelName,
   modelDescription,  schema, contentType='application/json', region=None,
   key=None, keyid=None, profile=None)
          Create a new model in a given API with a given schema, currently
          only contentType supported is 'application/json'

          CLI Example:

             salt myminion boto_apigateway.create_api_model restApiId modelName modelDescription '<schema>' 'content-type'

   salt.modules.boto_apigateway.create_api_resources(restApiId,      path,
   region=None, key=None, keyid=None, profile=None)
          Given rest api id, and an absolute resource path, create all the
          resources  and return all resources in the resourcepath, returns
          False on failure.

          CLI Example:

             salt myminion boto_apigateway.create_api_resources myapi_id resource_path

   salt.modules.boto_apigateway.create_api_stage(restApiId,     stageName,
   deploymentId,         description='',        cacheClusterEnabled=False,
   cacheClusterSize='0.5',    variables=None,    region=None,    key=None,
   keyid=None, profile=None)
          Creates a new API stage for a given restApiId and deploymentId.

          CLI Example:

             salt myminion boto_apigateway.create_api_stage restApiId stagename deploymentId \
                 description='' cacheClusterEnabled=True|False cacheClusterSize='0.5' variables='{"name": "value"}'

   salt.modules.boto_apigateway.delete_api(name,         description=None,
   region=None, key=None, keyid=None, profile=None)
          Delete all REST API Service with the given name and an  optional
          API description

          Returns  {deleted:  True,  count:  deleted_count}  if  apis were
          deleted, and returns {deleted: False} if error or not found.

          CLI Example:

             salt myminion boto_apigateway.delete_api myapi_name

             salt myminion boto_apigateway.delete_api myapi_name description='api description'

   salt.modules.boto_apigateway.delete_api_deployment(restApiId,
   deploymentId, region=None, key=None, keyid=None, profile=None)
          Deletes API deployment for a given restApiId and deploymentID

          CLI Example:

             salt myminion boto_apigateway.delete_api_deployent restApiId deploymentId

   salt.modules.boto_apigateway.delete_api_integration(restApiId,
   resourcePath,   httpMethod,    region=None,    key=None,    keyid=None,
   profile=None)
          Deletes an integration for a given method in a given API

          CLI Example:

             salt myminion boto_apigateway.delete_api_integration restApiId resourcePath httpMethod

   salt.modules.boto_apigateway.delete_api_integration_response(restApiId,
   resourcePath,   httpMethod,    statusCode,    region=None,    key=None,
   keyid=None, profile=None)
          Deletes  an  integration  response for a given method in a given
          API

          CLI Example:

             salt myminion boto_apigateway.delete_api_integration_response restApiId resourcePath httpMethod statusCode

   salt.modules.boto_apigateway.delete_api_key(apiKey,        region=None,
   key=None, keyid=None, profile=None)
          Deletes a given apiKey

          CLI Example:

             salt myminion boto_apigateway.delete_api_key apikeystring

   salt.modules.boto_apigateway.delete_api_method(restApiId, resourcePath,
   httpMethod, region=None, key=None, keyid=None, profile=None)
          Delete API method for a resource in the given API

          CLI Example:

             salt myminion boto_apigateway.delete_api_method restApiId resourcePath httpMethod

   salt.modules.boto_apigateway.delete_api_method_response(restApiId,
   resourcePath,    httpMethod,    statusCode,    region=None,   key=None,
   keyid=None, profile=None)
          Delete API method response for a resource in the given API

          CLI Example:

             salt myminion boto_apigateway.delete_api_method_response restApiId resourcePath httpMethod statusCode

   salt.modules.boto_apigateway.delete_api_model(restApiId,     modelName,
   region=None, key=None, keyid=None, profile=None)
          Delete a model identified by name in a given API

          CLI Example:

             salt myminion boto_apigateway.delete_api_model restApiId modelName

   salt.modules.boto_apigateway.delete_api_resources(restApiId,      path,
   region=None, key=None, keyid=None, profile=None)
          Given restApiId  and  an  absolute  resource  path,  delete  the
          resources   starting  from  the  absoluate  resource  path.   If
          resourcepath is the root resource '/', the function will  return
          False.  Returns False on failure.

          CLI Example:

             salt myminion boto_apigateway.delete_api_resources myapi_id, resource_path

   salt.modules.boto_apigateway.delete_api_stage(restApiId,     stageName,
   region=None, key=None, keyid=None, profile=None)
          Deletes stage identified by stageName  from  API  identified  by
          restApiId

          CLI Example:

             salt myminion boto_apigateway.delete_api_stage restApiId stageName

   salt.modules.boto_apigateway.describe_api_deployment(restApiId,
   deploymentId, region=None, key=None, keyid=None, profile=None)
          Get API deployment for a given restApiId and deploymentId.

          CLI Example:

             salt myminion boto_apigateway.describe_api_deployent restApiId deploymentId

   salt.modules.boto_apigateway.describe_api_deployments(restApiId,
   region=None, key=None, keyid=None, profile=None)
          Gets information about the defined API Deployments.  Return list
          of api deployments.

          CLI Example:

             salt myminion boto_apigateway.describe_api_deployments restApiId

   salt.modules.boto_apigateway.describe_api_integration(restApiId,
   resourcePath,    httpMethod,    region=None,    key=None,   keyid=None,
   profile=None)
          Get an integration for a given method in a given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_integration restApiId resourcePath httpMethod

   salt.modules.boto_apigateway.describe_api_integration_response(restApiId,
   resourcePath,    httpMethod,    statusCode,    region=None,   key=None,
   keyid=None, profile=None)
          Get an integration response for a given method in a given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_integration_response restApiId resourcePath httpMethod statusCode

   salt.modules.boto_apigateway.describe_api_key(apiKey,      region=None,
   key=None, keyid=None, profile=None)
          Gets info about the given api key

          CLI Example:

             salt myminion boto_apigateway.describe_api_key apigw_api_key

   salt.modules.boto_apigateway.describe_api_keys(region=None,   key=None,
   keyid=None, profile=None)
          Gets information about the defined API  Keys.   Return  list  of
          apiKeys.

          CLI Example:

             salt myminion boto_apigateway.describe_api_keys

   salt.modules.boto_apigateway.describe_api_method(restApiId,
   resourcePath,   httpMethod,    region=None,    key=None,    keyid=None,
   profile=None)
          Get API method for a resource in the given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_method restApiId resourcePath httpMethod

   salt.modules.boto_apigateway.describe_api_method_response(restApiId,
   resourcePath,   httpMethod,    statusCode,    region=None,    key=None,
   keyid=None, profile=None)
          Get API method response for a resource in the given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_method_response restApiId resourcePath httpMethod statusCode

   salt.modules.boto_apigateway.describe_api_model(restApiId,   modelName,
   flatten=True, region=None, key=None, keyid=None, profile=None)
          Get a model by name for a given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_model restApiId modelName [True]

   salt.modules.boto_apigateway.describe_api_models(restApiId,
   region=None, key=None, keyid=None, profile=None)
          Get all models for a given API

          CLI Example:

             salt myminion boto_apigateway.describe_api_models restApiId

   salt.modules.boto_apigateway.describe_api_resource(restApiId,     path,
   region=None, key=None, keyid=None, profile=None)
          Given rest api id, and an absolute resource  path,  returns  the
          resource id for the given path.

          CLI Example:

             salt myminion boto_apigateway.describe_api_resource myapi_id resource_path

   salt.modules.boto_apigateway.describe_api_resource_method(restApiId,
   resourcePath,   httpMethod,    region=None,    key=None,    keyid=None,
   profile=None)
          Given  rest  api id, resource path, and http method (must be one
          of DELETE, GET, HEAD, OPTIONS, PATCH,  POST,  PUT),  return  the
          method  for  the  api/resource path if defined.  Return False if
          method is not defined.

          CLI Example:

             salt myminion boto_apigateway.describe_api_resource_method myapi_id resource_path httpmethod

   salt.modules.boto_apigateway.describe_api_resources(restApiId,
   region=None, key=None, keyid=None, profile=None)
          Given rest api id, return all resources for this api.

          CLI Example:

             salt myminion boto_apigateway.describe_api_resources myapi_id

   salt.modules.boto_apigateway.describe_api_stage(restApiId,   stageName,
   region=None, key=None, keyid=None, profile=None)
          Get API stage for a given apiID and stage name

          CLI Example:

             salt myminion boto_apigateway.describe_api_stage restApiId stageName

   salt.modules.boto_apigateway.describe_api_stages(restApiId,
   deploymentId, region=None, key=None, keyid=None, profile=None)
          Get all API stages for a given apiID and deploymentID

          CLI Example:

             salt myminion boto_apigateway.describe_api_stages restApiId deploymentId

   salt.modules.boto_apigateway.describe_apis(name=None, description=None,
   region=None, key=None, keyid=None, profile=None)
          Returns all rest  apis  in  the  defined  region.   If  optional
          parameter  name  is included, returns all rest apis matching the
          name in the defined region.

          CLI Example:

             salt myminion boto_apigateway.describe_apis

             salt myminion boto_apigateway.describe_apis name='api name'

             salt myminion boto_apigateway.describe_apis name='api name' description='desc str'

   salt.modules.boto_apigateway.disable_api_key(apiKey,       region=None,
   key=None, keyid=None, profile=None)
          disable the given apiKey.

          CLI Example:

             salt myminion boto_apigateway.enable_api_key api_key

   salt.modules.boto_apigateway.disassociate_api_key_stagekeys(apiKey,
   stagekeyslist, region=None, key=None, keyid=None, profile=None)
          disassociate the given stagekeyslist to the given apiKey.

          CLI Example:

             salt myminion boto_apigateway.disassociate_stagekeys_api_key \
                     api_key '["restapi id/stage name", ...]'

   salt.modules.boto_apigateway.enable_api_key(apiKey,        region=None,
   key=None, keyid=None, profile=None)
          enable the given apiKey.

          CLI Example:

             salt myminion boto_apigateway.enable_api_key api_key

   salt.modules.boto_apigateway.flush_api_stage_cache(restApiId,
   stageName, region=None, key=None, keyid=None, profile=None)
          Flushes cache for the stage identified  by  stageName  from  API
          identified by restApiId

          CLI Example:

             salt myminion boto_apigateway.flush_api_stage_cache restApiId stageName

   salt.modules.boto_apigateway.overwrite_api_stage_variables(restApiId,
   stageName, variables, region=None, key=None, keyid=None, profile=None)
          Overwrite the stage variables for the given restApiId and  stage
          name  with the given variables, variables must be in the form of
          a dictionary.  Overwrite will always  remove  all  the  existing
          stage  variables  associated  with the given restApiId and stage
          name, follow by the adding of all the variables specified in the
          variables dictionary

          CLI Example:

             salt myminion boto_apigateway.overwrite_api_stage_variables restApiId stageName variables='{"name": "value"}'

   salt.modules.boto_apigateway.update_api_key_description(apiKey,
   description, region=None, key=None, keyid=None, profile=None)
          update the given apiKey with the given description.

          CLI Example:

             salt myminion boto_apigateway.update_api_key_description api_key description

   salt.modules.boto_apigateway.update_api_model_schema(restApiId,
   modelName, schema, region=None, key=None, keyid=None, profile=None)
          update  the  schema  (in python dictionary format) for the given
          model in the given restApiId

          CLI Example:

             salt myminion boto_apigateway.update_api_model_schema restApiId modelName schema

   salt.modules.boto_asg
   Connection module for Amazon Autoscale Groups

   New in version 2014.7.0.

   configuration
          This module accepts explicit autoscale credentials but can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             asg.keyid: GKTADJGHEIQSXMKKRBJ08H
             asg.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             asg.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   depends
          boto3

   salt.modules.boto_asg.create(name,                  launch_config_name,
   availability_zones,    min_size,    max_size,    desired_capacity=None,
   load_balancers=None,   default_cooldown=None,   health_check_type=None,
   health_check_period=None,                         placement_group=None,
   vpc_zone_identifier=None,     tags=None,     termination_policies=None,
   suspended_processes=None,                        scaling_policies=None,
   scheduled_actions=None,       region=None,       notification_arn=None,
   notification_types=None, key=None, keyid=None, profile=None)
          Create an autoscale group.

          CLI example:

             salt myminion boto_asg.create myasg mylc '["us-east-1a", "us-east-1e"]' 1 10 load_balancers='["myelb", "myelb2"]' tags='[{"key": "Name", value="myasg", "propagate_at_launch": True}]'

   salt.modules.boto_asg.create_launch_configuration(name,       image_id,
   key_name=None,           security_groups=None,          user_data=None,
   instance_type='m1.small',       kernel_id=None,        ramdisk_id=None,
   block_device_mappings=None, instance_monitoring=False, spot_price=None,
   instance_profile_name=None,                        ebs_optimized=False,
   associate_public_ip_address=None,                     volume_type=None,
   delete_on_termination=True,  iops=None,   use_block_device_types=False,
   region=None, key=None, keyid=None, profile=None)
          Create a launch configuration.

          CLI example:

             salt myminion boto_asg.create_launch_configuration mylc image_id=ami-0b9c9f62 key_name='mykey' security_groups='["mygroup"]' instance_type='c3.2xlarge'

   salt.modules.boto_asg.delete(name,  force=False, region=None, key=None,
   keyid=None, profile=None)
          Delete an autoscale group.

          CLI example:

             salt myminion boto_asg.delete myasg region=us-east-1

   salt.modules.boto_asg.delete_launch_configuration(name,    region=None,
   key=None, keyid=None, profile=None)
          Delete a launch configuration.

          CLI example:

             salt myminion boto_asg.delete_launch_configuration mylc

   salt.modules.boto_asg.describe_launch_configuration(name,  region=None,
   key=None, keyid=None, profile=None)
          Dump details of a given launch configuration.

          CLI example:

             salt myminion boto_asg.describe_launch_configuration mylc

   salt.modules.boto_asg.enter_standby(name,                 instance_ids,
   should_decrement_desired_capacity=False,     region=None,     key=None,
   keyid=None, profile=None)
          Switch desired instances to StandBy mode

          New in version 2016.11.0.

          CLI example:

             salt-call boto_asg.enter_standby my_autoscale_group_name '["i-xxxxxx"]'

   salt.modules.boto_asg.exists(name, region=None,  key=None,  keyid=None,
   profile=None)
          Check to see if an autoscale group exists.

          CLI example:

             salt myminion boto_asg.exists myasg region=us-east-1

   salt.modules.boto_asg.exit_standby(name,                  instance_ids,
   should_decrement_desired_capacity=False,     region=None,     key=None,
   keyid=None, profile=None)
          Exit desired instances from StandBy mode

          New in version 2016.11.0.

          CLI example:

             salt-call boto_asg.exit_standby my_autoscale_group_name '["i-xxxxxx"]'

   salt.modules.boto_asg.get_all_groups(region=None, key=None, keyid=None,
   profile=None)
          Return all AutoScale Groups visible in the account (as a list of
          boto.ec2.autoscale.group.AutoScalingGroup).

          New in version 2016.11.0.

          CLI example:

             salt-call boto_asg.get_all_groups region=us-east-1 --output yaml

   salt.modules.boto_asg.get_all_launch_configurations(region=None,
   key=None, keyid=None, profile=None)
          Fetch and return all Launch Configuration with details.

          CLI example:

             salt myminion boto_asg.get_all_launch_configurations

   salt.modules.boto_asg.get_cloud_init_mime(cloud_init)
          Get a mime multipart encoded  string  from  a  cloud-init  dict.
          Currently supports scripts and cloud-config.

          CLI Example:

             salt myminion boto.get_cloud_init_mime <cloud init>

   salt.modules.boto_asg.get_config(name,      region=None,      key=None,
   keyid=None, profile=None)
          Get the configuration for an autoscale group.

          CLI example:

             salt myminion boto_asg.get_config myasg region=us-east-1

   salt.modules.boto_asg.get_instances(name,  lifecycle_state='InService',
   health_status='Healthy',                attribute='private_ip_address',
   attributes=None, region=None, key=None, keyid=None, profile=None)
          return attribute of all instances in the named autoscale group.

          CLI example:

             salt-call boto_asg.get_instances my_autoscale_group_name

   salt.modules.boto_asg.get_scaling_policy_arn(as_group,
   scaling_policy_name, region=None, key=None, keyid=None, profile=None)
          Return  the  arn  for  a  scaling policy in a specific autoscale
          group or None if not found. Mainly used as a helper  method  for
          boto_cloudwatch_alarm, for linking alarms to scaling policies.

          CLI Example:

             salt '*' boto_asg.get_scaling_policy_arn mygroup mypolicy

   salt.modules.boto_asg.launch_configuration_exists(name,    region=None,
   key=None, keyid=None, profile=None)
          Check for a launch configuration's existence.

          CLI example:

             salt myminion boto_asg.launch_configuration_exists mylc

   salt.modules.boto_asg.list_groups(region=None,  key=None,   keyid=None,
   profile=None)
          Return all AutoScale Groups visible in the account (as a list of
          names).

          New in version 2016.11.0.

          CLI example:

             salt-call boto_asg.list_groups region=us-east-1

   salt.modules.boto_asg.list_launch_configurations(region=None, key=None,
   keyid=None, profile=None)
          List all Launch Configurations.

          CLI example:

             salt myminion boto_asg.list_launch_configurations

   salt.modules.boto_asg.update(name,                  launch_config_name,
   availability_zones,    min_size,    max_size,    desired_capacity=None,
   load_balancers=None,   default_cooldown=None,   health_check_type=None,
   health_check_period=None,                         placement_group=None,
   vpc_zone_identifier=None,     tags=None,     termination_policies=None,
   suspended_processes=None,                        scaling_policies=None,
   scheduled_actions=None, notification_arn=None, notification_types=None,
   region=None, key=None, keyid=None, profile=None)
          Update an autoscale group.

          CLI example:

             salt myminion boto_asg.update myasg mylc '["us-east-1a", "us-east-1e"]' 1 10 load_balancers='["myelb", "myelb2"]' tags='[{"key": "Name", value="myasg", "propagate_at_launch": True}]'

   salt.modules.boto_cfn
   Connection module for Amazon Cloud Formation

   New in version 2015.5.0.

   configuration
          This module  accepts  explicit  AWS  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles. Dynamic credentials are  then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             cfn.keyid: GKTADJGHEIQSXMKKRBJ08H
             cfn.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             cfn.region: us-east-1

   depends
          boto

   salt.modules.boto_cfn.create(name,                  template_body=None,
   template_url=None,       parameters=None,       notification_arns=None,
   disable_rollback=None,    timeout_in_minutes=None,   capabilities=None,
   tags=None,           on_failure=None,           stack_policy_body=None,
   stack_policy_url=None, region=None, key=None, keyid=None, profile=None)
          Create a CFN stack.

          CLI example to create a stack:

             salt myminion boto_cfn.create mystack template_url='https://s3.amazonaws.com/bucket/template.cft'         region=us-east-1

   salt.modules.boto_cfn.delete(name,  region=None,  key=None, keyid=None,
   profile=None)
          Delete a CFN stack.

          CLI example to delete a stack:

             salt myminion boto_cfn.delete mystack region=us-east-1

   salt.modules.boto_cfn.describe(name, region=None, key=None, keyid=None,
   profile=None)
          Describe a stack.

          New in version 2015.8.0.

          CLI example:

             salt myminion boto_cfn.describe mystack region=us-east-1

   salt.modules.boto_cfn.exists(name,  region=None,  key=None, keyid=None,
   profile=None)
          Check to see if a stack exists.

          CLI example:

             salt myminion boto_cfn.exists mystack region=us-east-1

   salt.modules.boto_cfn.get_template(name,     region=None,     key=None,
   keyid=None, profile=None)
          Check to see if attributes are set on a CFN stack.

          CLI example:

             salt myminion boto_cfn.get_template mystack

   salt.modules.boto_cfn.update_stack(name,            template_body=None,
   template_url=None,       parameters=None,       notification_arns=None,
   disable_rollback=False,   timeout_in_minutes=None,   capabilities=None,
   tags=None,                                  use_previous_template=None,
   stack_policy_during_update_body=None,
   stack_policy_during_update_url=None,            stack_policy_body=None,
   stack_policy_url=None, region=None, key=None, keyid=None, profile=None)
          Update a CFN stack.

          New in version 2015.8.0.

          CLI example to update a stack:

             salt myminion boto_cfn.update_stack mystack template_url='https://s3.amazonaws.com/bucket/template.cft'         region=us-east-1

   salt.modules.boto_cfn.validate_template(template_body=None,
   template_url=None, region=None, key=None, keyid=None, profile=None)
          Validate cloudformation template

          New in version 2015.8.0.

          CLI example:

             salt myminion boto_cfn.validate_template mystack-template

   salt.modules.boto_cloudtrail module
   Connection module for Amazon CloudTrail

   New in version 2016.3.0.

   configuration
          This module accepts explicit Lambda  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             cloudtrail.keyid: GKTADJGHEIQSXMKKRBJ08H
             cloudtrail.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             cloudtrail.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto3

   salt.modules.boto_cloudtrail.add_tags(Name,    region=None,   key=None,
   keyid=None, profile=None, **kwargs)
          Add tags to a trail

          Returns {tagged: true} if  the  trail  was  tagged  and  returns
          {tagged: False} if the trail was not tagged.

          CLI Example:

             salt myminion boto_cloudtrail.add_tags my_trail tag_a=tag_value tag_b=tag_value

   salt.modules.boto_cloudtrail.create(Name,                 S3BucketName,
   S3KeyPrefix=None,  SnsTopicName=None,  IncludeGlobalServiceEvents=None,
   IsMultiRegionTrail=None,                  EnableLogFileValidation=None,
   CloudWatchLogsLogGroupArn=None,             CloudWatchLogsRoleArn=None,
   KmsKeyId=None, region=None, key=None, keyid=None, profile=None)
          Given a valid config, create a trail.

          Returns  {created:  true}  if  the trail was created and returns
          {created: False} if the trail was not created.

          CLI Example:

             salt myminion boto_cloudtrail.create my_trail my_bucket

   salt.modules.boto_cloudtrail.delete(Name,    region=None,     key=None,
   keyid=None, profile=None)
          Given a trail name, delete it.

          Returns  {deleted:  true}  if  the trail was deleted and returns
          {deleted: false} if the trail was not deleted.

          CLI Example:

             salt myminion boto_cloudtrail.delete mytrail

   salt.modules.boto_cloudtrail.describe(Name,   region=None,    key=None,
   keyid=None, profile=None)
          Given a trail name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_cloudtrail.describe mytrail

   salt.modules.boto_cloudtrail.exists(Name,     region=None,    key=None,
   keyid=None, profile=None)
          Given a trail name, check to see if the given trail exists.

          Returns True if the given trail exists and returns False if  the
          given trail does not exist.

          CLI Example:

             salt myminion boto_cloudtrail.exists mytrail

   salt.modules.boto_cloudtrail.list(region=None,   key=None,  keyid=None,
   profile=None)
          List all trails

          Returns list of trails

          CLI Example:

             policies:
               - {...}
               - {...}

   salt.modules.boto_cloudtrail.list_tags(Name,   region=None,   key=None,
   keyid=None, profile=None)
          List tags of a trail

          Returns

                 * {...}

                 * {...}

          Return type
                 tags

          CLI Example:

             salt myminion boto_cloudtrail.list_tags my_trail

   salt.modules.boto_cloudtrail.remove_tags(Name,  region=None,  key=None,
   keyid=None, profile=None, **kwargs)
          Remove tags from a trail

          Returns {tagged: true} if  the  trail  was  tagged  and  returns
          {tagged: False} if the trail was not tagged.

          CLI Example:

             salt myminion boto_cloudtrail.remove_tags my_trail tag_a=tag_value tag_b=tag_value

   salt.modules.boto_cloudtrail.start_logging(Name, region=None, key=None,
   keyid=None, profile=None)
          Start logging for a trail

          Returns {started: true} if the trail  was  started  and  returns
          {started: False} if the trail was not started.

          CLI Example:

             salt myminion boto_cloudtrail.start_logging my_trail

   salt.modules.boto_cloudtrail.status(Name,     region=None,    key=None,
   keyid=None, profile=None)
          Given a trail name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_cloudtrail.describe mytrail

   salt.modules.boto_cloudtrail.stop_logging(Name, region=None,  key=None,
   keyid=None, profile=None)
          Stop logging for a trail

          Returns  {stopped:  true}  if  the trail was stopped and returns
          {stopped: False} if the trail was not stopped.

          CLI Example:

             salt myminion boto_cloudtrail.stop_logging my_trail

   salt.modules.boto_cloudtrail.update(Name,                 S3BucketName,
   S3KeyPrefix=None,  SnsTopicName=None,  IncludeGlobalServiceEvents=None,
   IsMultiRegionTrail=None,                  EnableLogFileValidation=None,
   CloudWatchLogsLogGroupArn=None,             CloudWatchLogsRoleArn=None,
   KmsKeyId=None, region=None, key=None, keyid=None, profile=None)
          Given a valid config, update a trail.

          Returns {created: true} if the trail  was  created  and  returns
          {created: False} if the trail was not created.

          CLI Example:

             salt myminion boto_cloudtrail.update my_trail my_bucket

   salt.modules.boto_cloudwatch
   Connection module for Amazon CloudWatch

   New in version 2014.7.0.

   configuration
          This  module  accepts  explicit credentials but can also utilize
          IAM roles assigned to the instance  through  Instance  Profiles.
          Dynamic credentials are then automatically obtained from AWS API
          and no further  configuration  is  necessary.  More  Information
          available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             cloudwatch.keyid: GKTADJGHEIQSXMKKRBJ08H
             cloudwatch.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             cloudwatch.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_cloudwatch.convert_to_arn(arns,          region=None,
   key=None, keyid=None, profile=None)
          Convert a list of strings into actual arns. Converts convenience
          names such as 'scaling_policy:...'

          CLI Example:

             salt '*' convert_to_arn 'scaling_policy:'

   salt.modules.boto_cloudwatch.create_or_update_alarm(connection=None,
   name=None,       metric=None,      namespace=None,      statistic=None,
   comparison=None, threshold=None, period=None,  evaluation_periods=None,
   unit=None,    description='',    dimensions=None,   alarm_actions=None,
   insufficient_data_actions=None, ok_actions=None, region=None, key=None,
   keyid=None, profile=None)
          Create or update a cloudwatch alarm.

          Params are the same as:
                 https://boto.readthedocs.io/en/latest/ref/cloudwatch.html#boto.ec2.cloudwatch.alarm.MetricAlarm.

          Dimensions must be a dict. If  the  value  of  Dimensions  is  a
          string,   it   will   be   json   decoded  to  produce  a  dict.
          alarm_actions, insufficient_data_actions, and ok_actions must be
          lists of string.  If the passed-in value is a string, it will be
          split on "," to produce  a  list.  The  strings  themselves  for
          alarm_actions, insufficient_data_actions, and ok_actions must be
          Amazon  resource  names  (ARN's);  however,  this  method   also
          supports an arn lookup notation, as follows:
             arn:aws:....                                     ARN  as  per
             http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html
             scaling_policy:<as_name>:<scaling_policy_name>    The   named
             autoscale group scaling policy, for  the  named  group  (e.g.
             scaling_policy:my-asg:ScaleDown)

          This is convenient for setting up autoscaling as follows.  First
          specify   a   boto_asg.present   state   for   an    ASG    with
          scaling_policies,  and then set up boto_cloudwatch_alarm.present
          states   which   have   alarm_actions   that    reference    the
          scaling_policy.

          CLI example:
             salt  myminion  boto_cloudwatch.create_alarm name=myalarm ...
             region=us-east-1

   salt.modules.boto_cloudwatch.delete_alarm(name, region=None,  key=None,
   keyid=None, profile=None)
          Delete a cloudwatch alarm

          CLI example to delete a queue:

             salt myminion boto_cloudwatch.delete_alarm myalarm region=us-east-1

   salt.modules.boto_cloudwatch.get_alarm(name,   region=None,   key=None,
   keyid=None, profile=None)
          Get alarm details. Also can be used to check to see if an  alarm
          exists.

          CLI example:

             salt myminion boto_cloudwatch.get_alarm myalarm region=us-east-1

   salt.modules.boto_cloudwatch.get_all_alarms(region=None,   prefix=None,
   key=None, keyid=None, profile=None)
          Get all alarm details.  Produces results that  can  be  used  to
          create an sls file.

          If  prefix parameter is given, alarm names in the output will be
          prepended with the prefix; alarms that have the prefix  will  be
          skipped.   This  can  be  used  to convert existing alarms to be
          managed by salt, as follows:

             1.

                Make a backup of all existing alarms
                       $     salt-call      boto_cloudwatch.get_all_alarms
                       --out=txt | sed "s/local: //" > legacy_alarms.sls

             2.

                Get all alarms with new prefixed names
                       $      salt-call     boto_cloudwatch.get_all_alarms
                       "prefix=**MANAGED  BY  SALT**  "  --out=txt  |  sed
                       "s/local: //" > managed_alarms.sls

             3.

                Insert the managed alarms into cloudwatch
                       $ salt-call state.template managed_alarms.sls

             4. Manually verify that the new alarms look right

             5. Delete   the   original  alarms  $  sed  s/present/absent/
                legacy_alarms.sls > remove_legacy_alarms.sls  $  salt-call
                state.template remove_legacy_alarms.sls

             6. Get  all  alarms  again,  verify  no  changes  $ salt-call
                boto_cloudwatch.get_all_alarms --out=txt |  sed  "s/local:
                //"    >    final_alarms.sls   $   diff   final_alarms.sls
                managed_alarms.sls

          CLI example:

             salt myminion boto_cloudwatch.get_all_alarms region=us-east-1 --out=txt

   salt.modules.boto_cognitoidentity module
   Connection module for Amazon CognitoIdentity

   New in version 2016.11.0.

   configuration
          This module accepts explicit CognitoIdentity credentials but can
          also  utilize IAM roles assigned to the instance trough Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             cognitoidentity.keyid: GKTADJGHEIQSXMKKRBJ08H
             cognitoidentity.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             cognitoidentity.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   Changed  in  version  2015.8.0:  All  methods  now return a dictionary.
   Create, delete, set, and update methods return:

      created: true

   or

      created: false
      error:
        message: error message

   Request methods (e.g., describe_identity_pools) return:

      identity_pools:
        - {...}
        - {...}

   or

      error:
        message: error message

   depends
          boto3

   salt.modules.boto_cognitoidentity.create_identity_pool(IdentityPoolName,
   AllowUnauthenticatedIdentities=False,     SupportedLoginProviders=None,
   DeveloperProviderName=None,             OpenIdConnectProviderARNs=None,
   region=None, key=None, keyid=None, profile=None)
          Creates   a  new  identity  pool.   All  parameters  except  for
          IdentityPoolName is optional.  SupportedLoginProviders should be
          a  dictionary  mapping  provider  names  to  provider  app  IDs.
          OpenIdConnectProviderARNs should be a  list  of  OpenID  Connect
          provider ARNs.

          Returns the created identity pool if successful

          CLI Example:

             salt myminion boto_cognitoidentity.create_identity_pool my_id_pool_name                              DeveloperProviderName=custom_developer_provider

   salt.modules.boto_cognitoidentity.delete_identity_pools(IdentityPoolName,
   IdentityPoolId=None, region=None, key=None, keyid=None, profile=None)
          Given an identity pool name, (optionally if an identity pool  id
          is given, the given name will be ignored)

          Deletes  all  identity  pools  matching  the  given name, or the
          specific identity pool with the given identity pool id.

          CLI Example:

             salt myminion boto_cognitoidentity.delete_identity_pools my_id_pool_name
             salt myminion boto_cognitoidentity.delete_identity_pools '' IdentityPoolId=my_id_pool_id

   salt.modules.boto_cognitoidentity.describe_identity_pools(IdentityPoolName,
   IdentityPoolId=None, region=None, key=None, keyid=None, profile=None)
          Given  an identity pool name, (optionally if an identity pool id
          is given, the given name will be ignored)

          Returns a list of matched identity pool name's pool properties

          CLI Example:

             salt myminion boto_cognitoidentity.describe_identity_pools my_id_pool_name
             salt myminion boto_cognitoidentity.describe_identity_pools '' IdentityPoolId=my_id_pool_id

   salt.modules.boto_cognitoidentity.get_identity_pool_roles(IdentityPoolName,
   IdentityPoolId=None, region=None, key=None, keyid=None, profile=None)
          Given  an identity pool name, (optionally if an identity pool id
          if given, the given name will be ignored)

          Returns a list of matched identity pool name's associated roles

          CLI Example:

             salt myminion boto_cognitoidentity.get_identity_pool_roles my_id_pool_name
             salt myminion boto_cognitoidentity.get_identity_pool_roles '' IdentityPoolId=my_id_pool_id

   salt.modules.boto_cognitoidentity.set_identity_pool_roles(IdentityPoolId,
   AuthenticatedRole=None,      UnauthenticatedRole=None,     region=None,
   key=None, keyid=None, profile=None)
          Given an identity pool id, set the given  AuthenticatedRole  and
          UnauthenticatedRole (the Role can be an iam arn, or a role name)
          If AuthenticatedRole or UnauthenticatedRole is  not  given,  the
          authenticated   and/or   the   unauthenticated  role  associated
          previously with the pool will be cleared.

          Returns set True if successful, set False if  unsuccessful  with
          the associated errors.

          CLI Example:

             salt myminion boto_cognitoidentity.set_identity_pool_roles my_id_pool_roles  # this clears the roles
             salt myminion boto_cognitoidentity.set_identity_pool_roles my_id_pool_id             AuthenticatedRole=my_auth_role UnauthenticatedRole=my_unauth_role  # this set both roles
             salt myminion boto_cognitoidentity.set_identity_pool_roles my_id_pool_id             AuthenticatedRole=my_auth_role  # this will set the auth role and clear the unauth role
             salt myminion boto_cognitoidentity.set_identity_pool_roles my_id_pool_id             UnauthenticatedRole=my_unauth_role  # this will set the unauth role and clear the auth role

   salt.modules.boto_cognitoidentity.update_identity_pool(IdentityPoolId,
   IdentityPoolName=None,            AllowUnauthenticatedIdentities=False,
   SupportedLoginProviders=None,               DeveloperProviderName=None,
   OpenIdConnectProviderARNs=None,  region=None,   key=None,   keyid=None,
   profile=None)
          Updates  the  given IdentityPoolId's properties.  All parameters
          except for IdentityPoolId, is optional.  SupportedLoginProviders
          should  be  a  dictionary mapping provider names to provider app
          IDs.  OpenIdConnectProviderARNs  should  be  a  list  of  OpenID
          Connect provider ARNs.

          To clear SupportedLoginProviders pass '{}'

          To clear OpenIdConnectProviderARNs pass '[]'

          boto3  api prevents DeveloperProviderName to be updated after it
          has been set for the first time.

          Returns the updated identity pool if successful

          CLI Example:

             salt myminion boto_cognitoidentity.update_identity_pool my_id_pool_id my_id_pool_name                              DeveloperProviderName=custom_developer_provider

   salt.modules.boto_datapipeline module
   Connection module for Amazon Data Pipeline

   New in version 2016.3.0.

   depends
          boto3

   salt.modules.boto_datapipeline.activate_pipeline(pipeline_id,
   region=None, key=None, keyid=None, profile=None)
          Start processing pipeline tasks. This function is idempotent.

          CLI example:

             salt myminion boto_datapipeline.activate_pipeline my_pipeline_id

   salt.modules.boto_datapipeline.create_pipeline(name,         unique_id,
   description='', region=None, key=None, keyid=None, profile=None)
          Create a new, empty pipeline. This function is idempotent.

          CLI example:

             salt myminion boto_datapipeline.create_pipeline my_name my_unique_id

   salt.modules.boto_datapipeline.delete_pipeline(pipeline_id,
   region=None, key=None, keyid=None, profile=None)
          Delete a pipeline, its pipeline definition, and its run history.
          This function is idempotent.

          CLI example:

             salt myminion boto_datapipeline.delete_pipeline my_pipeline_id

   salt.modules.boto_datapipeline.describe_pipelines(pipeline_ids,
   region=None, key=None, keyid=None, profile=None)
          Retrieve metadata about one or more pipelines.

          CLI example:

             salt myminion boto_datapipeline.describe_pipelines ['my_pipeline_id']

   salt.modules.boto_datapipeline.get_pipeline_definition(pipeline_id,
   version='latest', region=None, key=None, keyid=None, profile=None)
          Get the definition of the specified pipeline.

          CLI example:

             salt myminion boto_datapipeline.get_pipeline_definition my_pipeline_id

   salt.modules.boto_datapipeline.list_pipelines(region=None,    key=None,
   keyid=None, profile=None)
          Get a list of pipeline ids and names for all pipelines.

          CLI Example:

             salt myminion boto_datapipeline.list_pipelines profile=myprofile

   salt.modules.boto_datapipeline.pipeline_id_from_name(name, region=None,
   key=None, keyid=None, profile=None)
          Get the pipeline id, if it exists, for the given name.

          CLI example:

             salt myminion boto_datapipeline.pipeline_id_from_name my_pipeline_name

   salt.modules.boto_datapipeline.put_pipeline_definition(pipeline_id,
   pipeline_objects,     parameter_objects=None,    parameter_values=None,
   region=None, key=None, keyid=None, profile=None)
          Add  tasks,  schedules,  and  preconditions  to  the   specified
          pipeline.  This  function  is  idempotent  and  will  replace an
          existing definition.

          CLI example:

             salt myminion boto_datapipeline.put_pipeline_definition my_pipeline_id my_pipeline_objects

   salt.modules.boto_dynamodb
   Connection module for Amazon DynamoDB

   New in version 2015.5.0.

   configuration
          This module accepts explicit DynamoDB credentials but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             keyid: GKTADJGHEIQSXMKKRBJ08H
             key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_dynamodb.create_table(table_name,        region=None,
   key=None,    keyid=None,    profile=None,     read_capacity_units=None,
   write_capacity_units=None,    hash_key=None,   hash_key_data_type=None,
   range_key=None,      range_key_data_type=None,      local_indexes=None,
   global_indexes=None)
          Creates a DynamoDB table.

          CLI Example:

             salt myminion boto_dynamodb.create_table table_name /
             region=us-east-1 /
             hash_key=id /
             hash_key_data_type=N /
             range_key=created_at /
             range_key_data_type=N /
             read_capacity_units=1 /
             write_capacity_units=1

   salt.modules.boto_dynamodb.delete(table_name,   region=None,  key=None,
   keyid=None, profile=None)
          Delete a DynamoDB table.

          CLI Example:

             salt myminion boto_dynamodb.delete table_name region=us-east-1

   salt.modules.boto_dynamodb.describe(table_name, region=None,  key=None,
   keyid=None, profile=None)
          Describe a DynamoDB table.

          CLI example:

             salt myminion boto_dynamodb.describe table_name region=us-east-1

   salt.modules.boto_dynamodb.exists(table_name,   region=None,  key=None,
   keyid=None, profile=None)
          Check to see if a table exists.

          CLI Example:

             salt myminion boto_dynamodb.exists table_name region=us-east-1

   salt.modules.boto_dynamodb.update(table_name,          throughput=None,
   global_indexes=None, region=None, key=None, keyid=None, profile=None)
          Update a DynamoDB table.

          CLI example:

             salt myminion boto_dynamodb.update table_name region=us-east-1

   salt.modules.boto_ec2
   Connection module for Amazon EC2

   New in version 2015.8.0.

   configuration
          This  module  accepts  explicit  EC2  credentials  but  can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.   Dynamic  credentials are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             ec2.keyid: GKTADJGHEIQSXMKKRBJ08H
             ec2.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             ec2.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to specify  key,  keyid,  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
               keyid: GKTADJGHEIQSXMKKRBJ08H
               key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
               region: us-east-1

   depends
          boto

   salt.modules.boto_ec2.allocate_eip_address(domain=None,    region=None,
   key=None, keyid=None, profile=None)
          Allocate  a  new  Elastic  IP address and associate it with your
          account.

          domain (string) Optional param - if set to  exactly  'vpc',  the
                 address will be allocated to the VPC.  The default simply
                 maps the EIP to your account container.

          returns
                 (dict) dict of 'interesting' information about the  newly
                 allocated  EIP,  with  probably the most interesting keys
                 being 'public_ip'; and 'allocation_id'  iff  'domain=vpc'
                 was passed.

          CLI Example:

             salt-call boto_ec2.allocate_eip_address domain=vpc

          New in version 2016.3.0.

   salt.modules.boto_ec2.associate_eip_address(instance_id=None,
   instance_name=None,         public_ip=None,         allocation_id=None,
   network_interface_id=None,                 network_interface_name=None,
   private_ip_address=None,    allow_reassociation=False,     region=None,
   key=None, keyid=None, profile=None)
          Associate  an  Elastic  IP  address  with  a  currently  running
          instance or a network interface.  This requires exactly  one  of
          either  'public_ip'  or  'allocation_id',  depending  on whether
          you're associating a VPC address or a plain EC2 address.

          instance_id
                 (string)  --  ID  of  the  instance  to   associate   with
                 (exclusive with 'instance_name')

          instance_name
                 (string)  --  Name  tag  of the instance to associate with
                 (exclusive with 'instance_id')

          public_ip
                 (string) -- Public IP  address,  for  standard  EC2  based
                 allocations.

          allocation_id
                 (string) -- Allocation ID for a VPC-based EIP.

          network_interface_id
                 (string)  -  ID of the network interface to associate the
                 EIP with

          network_interface_name
                 (string) - Name of the network interface to associate the
                 EIP with

          private_ip_address
                 (string) -- The primary or secondary private IP address to
                 associate with the Elastic IP address.

          allow_reassociation
                 (bool)    --  Allow  a  currently  associated  EIP  to  be
                 re-associated with the new instance or interface.

          returns
                 (bool)   - True on success, False on failure.

          CLI Example:

             salt myminion boto_ec2.associate_eip_address instance_name=bubba.ho.tep allocation_id=eipalloc-ef382c8a

          New in version 2016.3.0.

   salt.modules.boto_ec2.attach_network_interface(device_index, name=None,
   network_interface_id=None,    instance_name=None,     instance_id=None,
   region=None, key=None, keyid=None, profile=None)
          Attach an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.attach_network_interface my_eni instance_name=salt-master device_index=0

   salt.modules.boto_ec2.create_image(ami_name,          instance_id=None,
   instance_name=None,  tags=None,  region=None,   key=None,   keyid=None,
   profile=None,    description=None,    no_reboot=False,   dry_run=False,
   filters=None)
          Given instance properties  that  define  exactly  one  instance,
          create AMI and return AMI-id.

          CLI Examples:

             salt myminion boto_ec2.create_instance ami_name instance_name=myinstance
             salt myminion boto_ec2.create_instance another_ami_name tags='{"mytag": "value"}' description='this is my ami'

   salt.modules.boto_ec2.create_key(key_name,    save_path,   region=None,
   key=None, keyid=None, profile=None)
          Creates a key and saves it to a given path.  Returns the private
          key.

          CLI Example:

             salt myminion boto_ec2.create_key mykey /root/

   salt.modules.boto_ec2.create_network_interface(name,    subnet_id=None,
   subnet_name=None,      private_ip_address=None,       description=None,
   groups=None, region=None, key=None, keyid=None, profile=None)
          Create an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.create_network_interface my_eni subnet-12345 description=my_eni groups=['my_group']

   salt.modules.boto_ec2.create_tags(resource_ids,    tags,   region=None,
   key=None, keyid=None, profile=None)
          Create new metadata tags for the specified resource ids.

          New in version 2016.11.0.

          resource_ids
                 (string) or (list) --  List  of  resource  IDs.   A  plain
                 string will be converted to a list of one element.

          tags   (dict) -- Dictionary of name/value pairs. To create only a
                 tag name, pass '' as the value.

          returns
                 (bool) - True on success, False on failure.

          CLI Example:

             salt-call boto_ec2.create_tags vol-12345678 '{"Name": "myVolume01"}'

   salt.modules.boto_ec2.delete_key(key_name,    region=None,    key=None,
   keyid=None, profile=None)
          Deletes a key. Always returns True

          CLI Example:

             salt myminion boto_ec2.delete_key mykey

   salt.modules.boto_ec2.delete_network_interface(name=None,
   network_interface_id=None,    region=None,    key=None,     keyid=None,
   profile=None)
          Create an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.create_network_interface my_eni subnet-12345 description=my_eni groups=['my_group']

   salt.modules.boto_ec2.delete_tags(resource_ids,    tags,   region=None,
   key=None, keyid=None, profile=None)
          Delete metadata tags for the specified resource ids.

          New in version 2016.11.0.

          resource_ids
                 (string) or (list) --  List  of  resource  IDs.   A  plain
                 string will be converted to a list of one element.

          tags

                 (dict)   or  (list)  --  Either  a  dictionary  containing
                 name/value pairs or a list containing just tag names.
                        If you pass in a dictionary, the values must match
                        the  actual  tag  values  or  the  tag will not be
                        deleted. If you pass in a value of  None  for  the
                        tag  value,  all  tags  with  that  name  will  be
                        deleted.

          returns
                 (bool) - True on success, False on failure.

          CLI Example:

             salt-call boto_ec2.delete_tags vol-12345678 '{"Name": "myVolume01"}'
             salt-call boto_ec2.delete_tags vol-12345678 '["Name","MountPoint"]'

   salt.modules.boto_ec2.delete_volume(volume_id,        instance_id=None,
   device=None,    force=False,    region=None,    key=None,   keyid=None,
   profile=None)
          Detach an EBS volume from an EC2 instance.

          New in version 2016.11.0.

          volume_id
                 (string) -- The ID of the EBS volume to be deleted.

          force  (bool) -- Forces deletion even if the device has  not  yet
                 been detached from its instance.

          returns
                 (bool) - True on success, False on failure.

          CLI Example:

             salt-call boto_ec2.delete_volume vol-12345678

   salt.modules.boto_ec2.detach_network_interface(name=None,
   network_interface_id=None,       attachment_id=None,       force=False,
   region=None, key=None, keyid=None, profile=None)
          Detach an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.detach_network_interface my_eni

   salt.modules.boto_ec2.detach_volume(volume_id,        instance_id=None,
   device=None,   force=False,    region=None,    key=None,    keyid=None,
   profile=None)
          Detach an EBS volume from an EC2 instance.

          New in version 2016.11.0.

          volume_id
                 (string) -- The ID of the EBS volume to be detached.

          instance_id
                 (string)  -- The ID of the EC2 instance from which it will
                 be detached.

          device (string) -- The device on the instance through  which  the
                 volume is exposted (e.g. /dev/sdh)

          force

                 (bool)  --  Forces  detachment  if the previous detachment
                 attempt did not occur cleanly.
                        This option can lead to data loss or  a  corrupted
                        file system. Use this option only as a last resort
                        to detach a volume from  a  failed  instance.  The
                        instance  will  not  have  an opportunity to flush
                        file system caches nor file system meta data.   If
                        you  use this option, you must perform file system
                        check and repair procedures.

          returns
                 (bool) - True on success, False on failure.

          CLI Example:

             salt-call boto_ec2.detach_volume vol-12345678 i-87654321

   salt.modules.boto_ec2.disassociate_eip_address(public_ip=None,
   association_id=None, region=None, key=None, keyid=None, profile=None)
          Disassociate  an  Elastic  IP  address  from a currently running
          instance. This requires exactly one of  either  'association_id'
          or  'public_ip',  depending on whether you're dealing with a VPC
          or EC2 Classic address.

          public_ip
                 (string)  --  Public   IP   address,   for   EC2   Classic
                 allocations.

          association_id
                 (string) -- Association ID for a VPC-bound EIP.

          returns
                 (bool)   - True on success, False on failure.

          CLI Example:

             salt myminion boto_ec2.disassociate_eip_address association_id=eipassoc-e3ba2d16

          New in version 2016.3.0.

   salt.modules.boto_ec2.exists(instance_id=None,   name=None,  tags=None,
   region=None,  key=None,   keyid=None,   profile=None,   in_states=None,
   filters=None)
          Given  a  instance  id,  check  to  see if the given instance id
          exists.

          Returns True if the given an instance with the given  id,  name,
          or tags exists; otherwise, False is returned.

          CLI Example:

             salt myminion boto_ec2.exists myinstance

   salt.modules.boto_ec2.find_images(ami_name=None,    executable_by=None,
   owners=None,   image_ids=None,   tags=None,   region=None,    key=None,
   keyid=None, profile=None, return_objs=False)
          Given image properties, find and return matching AMI ids

          CLI Examples:

             salt myminion boto_ec2.find_images tags='{"mytag": "value"}'

   salt.modules.boto_ec2.find_instances(instance_id=None,       name=None,
   tags=None,    region=None,    key=None,    keyid=None,    profile=None,
   return_objs=False, in_states=None, filters=None)
          Given instance properties, find and return matching instance ids

          CLI Examples:

             salt myminion boto_ec2.find_instances # Lists all instances
             salt myminion boto_ec2.find_instances name=myinstance
             salt myminion boto_ec2.find_instances tags='{"mytag": "value"}'
             salt myminion boto_ec2.find_instances filters='{"vpc-id": "vpc-12345678"}'

   salt.modules.boto_ec2.get_all_eip_addresses(addresses=None,
   allocation_ids=None, region=None, key=None, keyid=None, profile=None)
          Get public addresses of some, or all EIPs  associated  with  the
          current account.

          addresses
                 (list)  -  Optional list of addresses.  If provided, only
                 the addresses associated with those in the list  will  be
                 returned.

          allocation_ids
                 (list)  -  Optional list of allocation IDs.  If provided,
                 only the addresses associated with the  given  allocation
                 IDs will be returned.

          returns
                 (list) - A list of the requested EIP addresses

          CLI Example:

             salt-call boto_ec2.get_all_eip_addresses

          New in version 2016.3.0.

   salt.modules.boto_ec2.get_all_volumes(volume_ids=None,    filters=None,
   return_objs=False, region=None, key=None, keyid=None, profile=None)
          Get a list of all EBS volumes, optionally filtered  by  provided
          'filters' param

          New in version 2016.11.0.

          volume_ids
                 (list)  - Optional list of volume_ids.  If provided, only
                 the volumes associated with those in  the  list  will  be
                 returned.

          filters

                 (dict)  -  Additional  constraints  on  which  volumes to
                 return. Valid filters are:
                        attachment.attach-time - The time stamp  when  the
                        attachment                              initiated.
                        attachment.delete-on-termination  -  Whether   the
                        volume   is   deleted   on  instance  termination.
                        attachment.device  -  The  device  name  that   is
                        exposed  to the instance (for example, /dev/sda1).
                        attachment.instance-id - The ID  of  the  instance
                        the  volume  is  attached to.  attachment.status -
                        The  attachment  state  (attaching  |  attached  |
                        detaching  |  detached).   availability-zone - The
                        Availability Zone in which the volume was created.
                        create-time  -  The time stamp when the volume was
                        created.  encrypted - The encryption status of the
                        volume.   size  -  The size of the volume, in GiB.
                        snapshot-id - The snapshot from which  the  volume
                        was  created.   status  - The status of the volume
                        (creating  |  available  |  in-use  |  deleting  |
                        deleted  |  error).  tag:key=value - The key/value
                        combination of a tag  assigned  to  the  resource.
                        volume-id  -  The  volume  ID.   volume-type - The
                        Amazon EBS  volume  type.  This  can  be  gp2  for
                        General Purpose SSD, io1 for
                           Provisioned   IOPS   SSD,  st1  for  Throughput
                           Optimized HDD, sc1 for Cold  HDD,  or  standard
                           for Magnetic volumes.

          return_objs
                 (bool)  - Changes the return type from list of volume IDs
                 to list of boto.ec2.volume.Volume objects

          returns

                 (list) - A list  of  the  requested  values:  Either  the
                 volume IDs; or, if return_objs is true,
                        boto.ec2.volume.Volume objects.

          CLI Example:

             salt-call boto_ec2.get_all_volumes filters='{"tag:Name": "myVolume01"}'

   salt.modules.boto_ec2.get_attribute(attribute,      instance_name=None,
   instance_id=None,  region=None,  key=None,  keyid=None,   profile=None,
   filters=None)
          Get an EC2 instance attribute.

          CLI Example:

             salt myminion boto_ec2.get_attribute sourceDestCheck instance_name=my_instance

          Available attributes:

                 * instanceType

                 * kernel

                 * ramdisk

                 * userData

                 * disableApiTermination

                 * instanceInitiatedShutdownBehavior

                 * rootDeviceName

                 * blockDeviceMapping

                 * productCodes

                 * sourceDestCheck

                 * groupSet

                 * ebsOptimized

                 * sriovNetSupport

   salt.modules.boto_ec2.get_eip_address_info(addresses=None,
   allocation_ids=None, region=None, key=None, keyid=None, profile=None)
          Get 'interesting' info about some, or all EIPs  associated  with
          the current account.

          addresses
                 (list)  -  Optional list of addresses.  If provided, only
                 the addresses associated with those in the list  will  be
                 returned.

          allocation_ids
                 (list)  -  Optional list of allocation IDs.  If provided,
                 only the addresses associated with the  given  allocation
                 IDs will be returned.

          returns
                 (list  of  dicts)  - A list of dicts, each containing the
                 info for one of the requested EIPs.

          CLI Example:

             salt-call boto_ec2.get_eip_address_info addresses=52.4.2.15

          New in version 2016.3.0.

   salt.modules.boto_ec2.get_id(name=None,     tags=None,     region=None,
   key=None, keyid=None, profile=None, in_states=None, filters=None)
          Given instance properties, return the instance id if it exists.

          CLI Example:

             salt myminion boto_ec2.get_id myinstance

   salt.modules.boto_ec2.get_key(key_name,      region=None,     key=None,
   keyid=None, profile=None)
          Check to see if a key exists. Returns fingerprint and name if it
          does and False if it doesn't CLI Example:

             salt myminion boto_ec2.get_key mykey

   salt.modules.boto_ec2.get_keys(keynames=None,             filters=None,
   region=None, key=None, keyid=None, profile=None)
          Gets all keys or filters  them  by  name  and  returns  a  list.
          keynames  (list)::  A list of the names of keypairs to retrieve.
          If not provided, all key pairs will be returned.  filters (dict)
          ::  Optional  filters  that  can  be  used  to limit the results
          returned. Filters are provided  in  the  form  of  a  dictionary
          consisting  of  filter names as the key and filter values as the
          value. The set of allowable filter names/values is dependent  on
          the  request  being  performed.  Check  the  EC2  API  guide for
          details.

          CLI Example:

             salt myminion boto_ec2.get_keys

   salt.modules.boto_ec2.get_network_interface(name=None,
   network_interface_id=None,     region=None,    key=None,    keyid=None,
   profile=None)
          Get an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.get_network_interface name=my_eni

   salt.modules.boto_ec2.get_network_interface_id(name,       region=None,
   key=None, keyid=None, profile=None)
          Get an Elastic Network Interface id from its name tag.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.get_network_interface_id name=my_eni

   salt.modules.boto_ec2.get_unassociated_eip_address(domain='standard',
   region=None, key=None, keyid=None, profile=None)
          Return the first unassociated EIP

          domain Indicates whether the address is a EC2 address or  a  VPC
                 address (standard|vpc).

          CLI Example:

             salt-call boto_ec2.get_unassociated_eip_address

          New in version 2016.3.0.

   salt.modules.boto_ec2.get_zones(region=None,    key=None,   keyid=None,
   profile=None)
          Get a list of AZs for the configured region.

          CLI Example:

             salt myminion boto_ec2.get_zones

   salt.modules.boto_ec2.import_key(key_name,         public_key_material,
   region=None, key=None, keyid=None, profile=None)
          Imports  the  public  key  from an RSA key pair that you created
          with a third-party tool.  Supported formats:  -  OpenSSH  public
          key format (e.g., the format in ~/.ssh/authorized_keys) - Base64
          encoded DER format - SSH public key file format as specified  in
          RFC4716  -  DSA  keys  are  not  supported.  Make  sure your key
          generator is set up to  create  RSA  keys.   Supported  lengths:
          1024, 2048, and 4096.

          CLI Example:

             salt myminion boto_ec2.import mykey publickey

   salt.modules.boto_ec2.modify_network_interface_attribute(name=None,
   network_interface_id=None,    attr=None,    value=None,    region=None,
   key=None, keyid=None, profile=None)
          Modify an attribute of an Elastic Network Interface.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_ec2.modify_network_interface_attribute my_eni attr=description value='example description'

   salt.modules.boto_ec2.release_eip_address(public_ip=None,
   allocation_id=None, region=None, key=None, keyid=None, profile=None)
          Free an Elastic IP address.  Pass either a public IP address  to
          release  an EC2 Classic EIP, or an AllocationId to release a VPC
          EIP.

          public_ip
                 (string) - The public IP address - for EC2 elastic IPs.

          allocation_id
                 (string) - The Allocation ID - for VPC elastic IPs.

          returns
                 (bool) - True on success, False on failure

          CLI Example:

             salt myminion boto_ec2.release_eip_address allocation_id=eipalloc-ef382c8a

          New in version 2016.3.0.

   salt.modules.boto_ec2.run(image_id,        name=None,        tags=None,
   key_name=None,           security_groups=None,          user_data=None,
   instance_type='m1.small',        placement=None,        kernel_id=None,
   ramdisk_id=None,  monitoring_enabled=None,  vpc_id=None, vpc_name=None,
   subnet_id=None,       subnet_name=None,        private_ip_address=None,
   block_device_map=None,                    disable_api_termination=None,
   instance_initiated_shutdown_behavior=None,        placement_group=None,
   client_token=None,  security_group_ids=None, security_group_names=None,
   additional_info=None,     tenancy=None,      instance_profile_arn=None,
   instance_profile_name=None,                         ebs_optimized=None,
   network_interface_id=None,  network_interface_name=None,   region=None,
   key=None, keyid=None, profile=None, network_interfaces=None)
          Create and start an EC2 instance.

          Returns True if the instance was created; otherwise False.

          CLI Example:

             salt myminion boto_ec2.run ami-b80c2b87 name=myinstance

          image_id
                 (string) -- The ID of the image to run.

          name   (string) - The name of the instance.

          tags   (dict  of  key:  value  pairs)  -  tags  to  apply to the
                 instance.

          key_name
                 (string) -- The name of the key pair with which to  launch
                 instances.

          security_groups
                 (list of strings) -- The names of the EC2 classic security
                 groups with which to associate instances

          user_data
                 (string) -- The Base64-encoded MIME user data to  be  made
                 available to the instance(s) in this reservation.

          instance_type
                 (string)  --  The type of instance to run.  Note that some
                 image types (e.g. hvm) only run on some instance types.

          placement
                 (string) -- The Availability Zone to launch  the  instance
                 into.

          kernel_id
                 (string)  -- The ID of the kernel with which to launch the
                 instances.

          ramdisk_id
                 (string) -- The ID of the RAM disk with  which  to  launch
                 the instances.

          monitoring_enabled
                 (bool)  --  Enable  detailed  CloudWatch monitoring on the
                 instance.

          vpc_id (string)  -  ID  of  a  VPC  to  bind  the  instance  to.
                 Exclusive with vpc_name.

          vpc_name
                 (string)  -  Name  of  a  VPC  to  bind  the instance to.
                 Exclusive with vpc_id.

          subnet_id
                 (string) -- The subnet  ID  within  which  to  launch  the
                 instances for VPC.

          subnet_name
                 (string)  --  The  name of a subnet within which to launch
                 the instances for VPC.

          private_ip_address
                 (string) -- If you're using VPC, you  can  optionally  use
                 this   parameter   to  assign  the  instance  a  specific
                 available IP address from the subnet (e.g. 10.0.0.25).

          block_device_map
                 (boto.ec2.blockdevicemapping.BlockDeviceMapping)   --    A
                 BlockDeviceMapping  data  structure  describing  the  EBS
                 volumes associated with the Image.  (string) -  A  string
                 representation of a BlockDeviceMapping structure (dict) -
                 A dict describing  a  BlockDeviceMapping  structure  YAML
                 example:

                    device-maps:

                           /dev/sdb:
                                  ephemeral_name: ephemeral0

                           /dev/sdc:
                                  ephemeral_name: ephemeral1

                           /dev/sdd:
                                  ephemeral_name: ephemeral2

                           /dev/sde:
                                  ephemeral_name: ephemeral3

                           /dev/sdf:
                                  size: 20 volume_type: gp2

          disable_api_termination
                 (bool)  --  If True, the instances will be locked and will
                 not be able to be terminated via the API.

          instance_initiated_shutdown_behavior
                 (string)  --  Specifies  whether  the  instance  stops  or
                 terminates  on  instance-initiated shutdown. Valid values
                 are: stop, terminate

          placement_group
                 (string)  --  If  specified,  this  is  the  name  of  the
                 placement   group   in  which  the  instance(s)  will  be
                 launched.

          client_token
                 (string) -- Unique, case-sensitive identifier you  provide
                 to  ensure  idempotency  of the request. Maximum 64 ASCII
                 characters.

          security_group_ids
                 (list of strings) -- The ID(s) of the VPC security  groups
                 with which to associate instances.

          security_group_names
                 (list  of  strings)  --  The  name(s)  of the VPC security
                 groups with which to associate instances.

          additional_info
                 (string)  --  Specifies  additional  information  to  make
                 available to the instance(s).

          tenancy
                 (string)  --  The  tenancy  of  the  instance  you want to
                 launch. An instance with a tenancy of 'dedicated' runs on
                 single-tenant  hardware  and  can only be launched into a
                 VPC. Valid values are:"default" or "dedicated".  NOTE: To
                 use dedicated tenancy you MUST specify a VPC subnet-ID as
                 well.

          instance_profile_arn
                 (string) -- The Amazon resource  name  (ARN)  of  the  IAM
                 Instance Profile (IIP) to associate with the instances.

          instance_profile_name
                 (string)  -- The name of the IAM Instance Profile (IIP) to
                 associate with the instances.

          ebs_optimized
                 (bool) -- Whether the instance is optimized for  EBS  I/O.
                 This optimization provides dedicated throughput to Amazon
                 EBS and  an  optimized  configuration  stack  to  provide
                 optimal  EBS  I/O  performance.   This optimization isn't
                 available with all instance types.

          network_interfaces
                 (boto.ec2.networkinterface.NetworkInterfaceCollection)  --
                 A  NetworkInterfaceCollection  data  structure containing
                 the ENI specifications for the instance.

          network_interface_id
                 (string) - ID of the network interface to attach  to  the
                 instance

          network_interface_name
                 (string) - Name of the network interface to attach to the
                 instance

   salt.modules.boto_ec2.set_attribute(attribute,         attribute_value,
   instance_name=None,     instance_id=None,     region=None,    key=None,
   keyid=None, profile=None, filters=None)
          Set an EC2 instance attribute.  Returns  whether  the  operation
          succeeded or not.

          CLI Example:

             salt myminion boto_ec2.set_attribute sourceDestCheck False instance_name=my_instance

          Available attributes:

                 * instanceType

                 * kernel

                 * ramdisk

                 * userData

                 * disableApiTermination

                 * instanceInitiatedShutdownBehavior

                 * rootDeviceName

                 * blockDeviceMapping

                 * productCodes

                 * sourceDestCheck

                 * groupSet

                 * ebsOptimized

                 * sriovNetSupport

   salt.modules.boto_ec2.set_volumes_tags(tag_maps,   authoritative=False,
   dry_run=False, region=None, key=None, keyid=None, profile=None)
          New in version 2016.11.0.

          tag_maps

                 (list) -  List  of  dicts  of  filters  and  tags,  where
                 'filters' is a dict suitable for passing
                        to  the  'filters'  argument  of get_all_volumes()
                        above, and 'tags' is a dict of tags to be  set  on
                        volumes  (via  create_tags/delete_tags) as matched
                        by  the  given  filters.   The  filter  syntax  is
                        extended  to  permit  passing  either  a  list  of
                        volume_ids or an instance_name (with instance_name
                        being  the  Name  tag of the instance to which the
                        desired volumes are mapped).  Each mapping in  the
                        list  is  applied  separately, so multiple sets of
                        volumes can be all  tagged  differently  with  one
                        call to this function.

          YAML example fragment:

          authoritative

                 (bool)  -  If  true,  any  existing  tags  on the matched
                 volumes, and not explicitly requested
                        here, will be removed.

          dry_run

                 (bool) - If true, don't change anything,  just  return  a
                 dictionary describing any changes
                        which would have been applied.

          returns
                 (dict) - A dict dsecribing status and any changes.

   salt.modules.boto_ec2.terminate(instance_id=None,            name=None,
   region=None, key=None, keyid=None, profile=None, filters=None)
          Terminate the instance described by instance_id or name.

          CLI Example:

             salt myminion boto_ec2.terminate name=myinstance
             salt myminion boto_ec2.terminate instance_id=i-a46b9f

   salt.modules.boto_elasticache
   Connection module for Amazon Elasticache

   New in version 2014.7.0.

   configuration
          This module accepts explicit  elasticache  credentials  but  can
          also utilize IAM roles assigned to the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             elasticache.keyid: GKTADJGHEIQSXMKKRBJ08H
             elasticache.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             elasticache.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_elasticache.authorize_cache_security_group_ingress(name,
   ec2_security_group_name,   ec2_security_group_owner_id,    region=None,
   key=None, keyid=None, profile=None)
          Authorize  network ingress from an ec2 security group to a cache
          security group.

          CLI example:

             salt myminion boto_elasticache.authorize_cache_security_group_ingress myelasticachesg myec2sg 879879

   salt.modules.boto_elasticache.create(name,        num_cache_nodes=None,
   engine=None,      cache_node_type=None,      replication_group_id=None,
   engine_version=None,                   cache_parameter_group_name=None,
   cache_subnet_group_name=None,          cache_security_group_names=None,
   security_group_ids=None,                            snapshot_arns=None,
   preferred_availability_zone=None,    preferred_maintenance_window=None,
   port=None,                                 notification_topic_arn=None,
   auto_minor_version_upgrade=None,   wait=None,   region=None,  key=None,
   keyid=None, profile=None)
          Create a cache cluster.

          CLI example:

             salt myminion boto_elasticache.create myelasticache 1 redis cache.t1.micro
             cache_security_group_names='["myelasticachesg"]'

   salt.modules.boto_elasticache.create_cache_security_group(name,
   description, region=None, key=None, keyid=None, profile=None)
          Create a cache security group.

          CLI example:

             salt myminion boto_elasticache.create_cache_security_group myelasticachesg 'My Cache Security Group'

   salt.modules.boto_elasticache.create_replication_group(name,
   primary_cluster_id,      replication_group_description,      wait=None,
   region=None, key=None, keyid=None, profile=None)
          Create replication group.

          CLI example:

             salt myminion boto_elasticache.create_replication_group myelasticache myprimarycluster description

   salt.modules.boto_elasticache.create_subnet_group(name,    description,
   subnet_ids=None, subnet_names=None, tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Create an ElastiCache subnet group

          CLI example to create an ElastiCache subnet group:

             salt myminion boto_elasticache.create_subnet_group my-subnet-group             "group description" subnet_ids='[subnet-12345678, subnet-87654321]'             region=us-east-1

   salt.modules.boto_elasticache.delete(name,   wait=False,   region=None,
   key=None, keyid=None, profile=None)
          Delete a cache cluster.

          CLI example:

             salt myminion boto_elasticache.delete myelasticache

   salt.modules.boto_elasticache.delete_cache_security_group(name,
   region=None, key=None, keyid=None, profile=None)
          Delete a cache security group.

          CLI example:

             salt myminion boto_elasticache.delete_cache_security_group myelasticachesg 'My Cache Security Group'

   salt.modules.boto_elasticache.delete_replication_group(name,
   region=None, key=None, keyid=None, profile=None)
          Delete an ElastiCache replication group.

          CLI example:

             salt myminion boto_elasticache.delete_replication_group my-replication-group                 region=us-east-1

   salt.modules.boto_elasticache.delete_subnet_group(name,    region=None,
   key=None, keyid=None, profile=None)
          Delete an ElastiCache subnet group.

          CLI example:

             salt myminion boto_elasticache.delete_subnet_group my-subnet-group                 region=us-east-1

   salt.modules.boto_elasticache.describe_replication_group(name,
   region=None, key=None, keyid=None, profile=None, parameter=None)
          Get replication group information.

          CLI example:

             salt myminion boto_elasticache.describe_replication_group mygroup

   salt.modules.boto_elasticache.exists(name,    region=None,    key=None,
   keyid=None, profile=None)
          Check to see if a cache cluster exists.

          CLI example:

             salt myminion boto_elasticache.exists myelasticache

   salt.modules.boto_elasticache.get_all_cache_subnet_groups(name=None,
   region=None, key=None, keyid=None, profile=None)
          Return a list of all cache subnet groups with details

          CLI example:

             salt myminion boto_elasticache.get_all_subnet_groups region=us-east-1

   salt.modules.boto_elasticache.get_cache_subnet_group(name, region=None,
   key=None, keyid=None, profile=None)
          Get information about a cache subnet group.

          CLI example:

             salt myminion boto_elasticache.get_cache_subnet_group mycache_subnet_group

   salt.modules.boto_elasticache.get_config(name,  region=None,  key=None,
   keyid=None, profile=None)
          Get the configuration for a cache cluster.

          CLI example:

             salt myminion boto_elasticache.get_config myelasticache

   salt.modules.boto_elasticache.get_group_host(name,         region=None,
   key=None, keyid=None, profile=None)
          Get hostname from replication cache group

          CLI example:

             salt myminion boto_elasticache.get_group_host myelasticachegroup

   salt.modules.boto_elasticache.get_node_host(name,          region=None,
   key=None, keyid=None, profile=None)
          Get hostname from cache node

          CLI example:

             salt myminion boto_elasticache.get_node_host myelasticache

   salt.modules.boto_elasticache.group_exists(name, region=None, key=None,
   keyid=None, profile=None)
          Check to see if a replication group exists.

          CLI example:

             salt myminion boto_elasticache.group_exists myelasticache

   salt.modules.boto_elasticache.list_cache_subnet_groups(name=None,
   region=None, key=None, keyid=None, profile=None)
          Return a list of all cache subnet group names

          CLI example:

             salt myminion boto_elasticache.list_subnet_groups region=us-east-1

   salt.modules.boto_elasticache.revoke_cache_security_group_ingress(name,
   ec2_security_group_name,    ec2_security_group_owner_id,   region=None,
   key=None, keyid=None, profile=None)
          Revoke network ingress from an ec2 security  group  to  a  cache
          security group.

          CLI example:

             salt myminion boto_elasticache.revoke_cache_security_group_ingress myelasticachesg myec2sg 879879

   salt.modules.boto_elasticache.subnet_group_exists(name,      tags=None,
   region=None, key=None, keyid=None, profile=None)
          Check to see if an ElastiCache subnet group exists.

          CLI example:

             salt myminion boto_elasticache.subnet_group_exists my-param-group                 region=us-east-1

   salt.modules.boto_elasticsearch_domain module
   Connection module for Amazon Elasticsearch Service

   New in version 2016.11.0.

   configuration
          This module  accepts  explicit  AWS  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the  instance trough Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             lambda.keyid: GKTADJGHEIQSXMKKRBJ08H
             lambda.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             lambda.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

          Create and delete methods return:

             created: true

          or

             created: false
             error:
               message: error message

          Request methods (e.g., describe_function) return:

             domain:
               - {...}
               - {...}

          or

             error:
               message: error message

   depends
          boto3

   salt.modules.boto_elasticsearch_domain.add_tags(DomainName=None,
   ARN=None, region=None, key=None, keyid=None, profile=None, **kwargs)
          Add tags to a domain

          Returns {tagged: true} if the  domain  was  tagged  and  returns
          {tagged: False} if the domain was not tagged.

          CLI Example:

             salt myminion boto_elasticsearch_domain.add_tags mydomain tag_a=tag_value tag_b=tag_value

   salt.modules.boto_elasticsearch_domain.create(DomainName,
   ElasticsearchClusterConfig=None, EBSOptions=None,  AccessPolicies=None,
   SnapshotOptions=None,   AdvancedOptions=None,   region=None,  key=None,
   keyid=None, profile=None)
          Given a valid config, create a domain.

          Returns {created: true} if the domain was  created  and  returns
          {created: False} if the domain was not created.

          CLI Example:

             salt myminion boto_elasticsearch_domain.create mydomain \
                   {'InstanceType': 't2.micro.elasticsearch', 'InstanceCount': 1, \
                   'DedicatedMasterEnabled': false, 'ZoneAwarenessEnabled': false} \
                   {'EBSEnabled': true, 'VolumeType': 'gp2', 'VolumeSize': 10, \
                   'Iops': 0} \
                   {"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"AWS": "*"}, "Action": "es:*", \
                    "Resource": "arn:aws:es:us-east-1:111111111111:domain/mydomain/*", \
                    "Condition": {"IpAddress": {"aws:SourceIp": ["127.0.0.1"]}}}]} \
                   {"AutomatedSnapshotStartHour": 0} \
                   {"rest.action.multi.allow_explicit_index": "true"}

   salt.modules.boto_elasticsearch_domain.delete(DomainName,  region=None,
   key=None, keyid=None, profile=None)
          Given a domain name, delete it.

          Returns {deleted: true} if the domain was  deleted  and  returns
          {deleted: false} if the domain was not deleted.

          CLI Example:

             salt myminion boto_elasticsearch_domain.delete mydomain

   salt.modules.boto_elasticsearch_domain.describe(DomainName,
   region=None, key=None, keyid=None, profile=None)
          Given a domain name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_elasticsearch_domain.describe mydomain

   salt.modules.boto_elasticsearch_domain.exists(DomainName,  region=None,
   key=None, keyid=None, profile=None)
          Given a domain name, check to see if the given domain exists.

          Returns True if the given domain exists and returns False if the
          given function does not exist.

          CLI Example:

             salt myminion boto_elasticsearch_domain.exists mydomain

   salt.modules.boto_elasticsearch_domain.list_tags(DomainName=None,
   ARN=None, region=None, key=None, keyid=None, profile=None)
          List tags of a trail

          Returns

                 * {...}

                 * {...}

          Return type
                 tags

          CLI Example:

             salt myminion boto_cloudtrail.list_tags my_trail

   salt.modules.boto_elasticsearch_domain.remove_tags(TagKeys,
   DomainName=None,   ARN=None,   region=None,    key=None,    keyid=None,
   profile=None)
          Remove tags from a trail

          Returns  {tagged:  true}  if  the  trail  was tagged and returns
          {tagged: False} if the trail was not tagged.

          CLI Example:

             salt myminion boto_cloudtrail.remove_tags my_trail tag_a=tag_value tag_b=tag_value

   salt.modules.boto_elasticsearch_domain.status(DomainName,  region=None,
   key=None, keyid=None, profile=None)
          Given a domain name describe its status.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_elasticsearch_domain.status mydomain

   salt.modules.boto_elasticsearch_domain.update(DomainName,
   ElasticsearchClusterConfig=None, EBSOptions=None,  AccessPolicies=None,
   SnapshotOptions=None,   AdvancedOptions=None,   region=None,  key=None,
   keyid=None, profile=None)
          Update the named domain to the configuration.

          Returns {updated: true} if the domain was  updated  and  returns
          {updated: False} if the domain was not updated.

          CLI Example:

             salt myminion boto_elasticsearch_domain.update mydomain \
                   {'InstanceType': 't2.micro.elasticsearch', 'InstanceCount': 1, \
                   'DedicatedMasterEnabled': false, 'ZoneAwarenessEnabled': false} \
                   {'EBSEnabled': true, 'VolumeType': 'gp2', 'VolumeSize': 10, \
                   'Iops': 0} \
                   {"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"AWS": "*"}, "Action": "es:*", \
                    "Resource": "arn:aws:es:us-east-1:111111111111:domain/mydomain/*", \
                    "Condition": {"IpAddress": {"aws:SourceIp": ["127.0.0.1"]}}}]} \
                   {"AutomatedSnapshotStartHour": 0} \
                   {"rest.action.multi.allow_explicit_index": "true"}

   salt.modules.boto_elb
   Connection module for Amazon ELB

   New in version 2014.7.0.

   configuration
          This  module  accepts  explicit  elb  credentials  but  can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.  Dynamic  credentials  are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             elb.keyid: GKTADJGHEIQSXMKKRBJ08H
             elb.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             elb.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto >= 2.33.0

   salt.modules.boto_elb.apply_security_groups(name,      security_groups,
   region=None, key=None, keyid=None, profile=None)
          Apply security groups to ELB.

          CLI example:

             salt myminion boto_elb.apply_security_groups myelb '["mysecgroup1"]'

   salt.modules.boto_elb.attach_subnets(name,     subnets,    region=None,
   key=None, keyid=None, profile=None)
          Attach ELB to subnets.

          CLI example:

             salt myminion boto_elb.attach_subnets myelb '["mysubnet"]'

   salt.modules.boto_elb.create(name,    availability_zones,    listeners,
   subnets=None,      security_groups=None,      scheme='internet-facing',
   region=None, key=None, keyid=None, profile=None)
          Create an ELB

          CLI example to create an ELB:

             salt myminion boto_elb.create myelb '["us-east-1a", "us-east-1e"]' '{"elb_port": 443, "elb_protocol": "HTTPS", ...}' region=us-east-1

   salt.modules.boto_elb.create_listeners(name,  listeners,   region=None,
   key=None, keyid=None, profile=None)
          Create listeners on an ELB.

          CLI example:

             salt myminion boto_elb.create_listeners myelb '[["HTTPS", "HTTP", 443, 80, "arn:aws:iam::11  11111:server-certificate/mycert"]]'

   salt.modules.boto_elb.create_policy(name,   policy_name,   policy_type,
   policy, region=None, key=None, keyid=None, profile=None)
          Create an ELB policy.

          New in version 2016.3.0.

          CLI example:

             salt myminion boto_elb.create_policy myelb mypolicy LBCookieStickinessPolicyType '{"CookieExpirationPeriod": 3600}'

   salt.modules.boto_elb.delete(name, region=None,  key=None,  keyid=None,
   profile=None)
          Delete an ELB.

          CLI example to delete an ELB:

             salt myminion boto_elb.delete myelb region=us-east-1

   salt.modules.boto_elb.delete_listeners(name,     ports,    region=None,
   key=None, keyid=None, profile=None)
          Delete listeners on an ELB.

          CLI example:

             salt myminion boto_elb.delete_listeners myelb '[80,443]'

   salt.modules.boto_elb.delete_policy(name,   policy_name,   region=None,
   key=None, keyid=None, profile=None)
          Delete an ELB policy.

          New in version 2016.3.0.

          CLI example:

             salt myminion boto_elb.delete_policy myelb mypolicy

   salt.modules.boto_elb.delete_tags(name,  tags,  region=None,  key=None,
   keyid=None, profile=None)
          Add the tags on an ELB

          name   name of the ELB

          tags   list of tags to remove

          CLI Example:

             salt myminion boto_elb.delete_tags my-elb-name ['TagToRemove1', 'TagToRemove2']

   salt.modules.boto_elb.deregister_instances(name,             instances,
   region=None, key=None, keyid=None, profile=None)
          Deregister  instances with an ELB.  Instances is either a string
          instance id or a list of string instance id's.

          Returns:

          * True: instance(s) deregistered successfully

          * False: instance(s) failed to be deregistered

          * None: instance(s) not valid or not registered, no action taken

          CLI example:

             salt myminion boto_elb.deregister_instances myelb instance_id
             salt myminion boto_elb.deregister_instances myelb "[instance_id, instance_id]"

   salt.modules.boto_elb.detach_subnets(name,    subnets,     region=None,
   key=None, keyid=None, profile=None)
          Detach ELB from subnets.

          CLI example:

             salt myminion boto_elb.detach_subnets myelb '["mysubnet"]'

   salt.modules.boto_elb.disable_availability_zones(name,
   availability_zones, region=None, key=None, keyid=None, profile=None)
          Disable availability zones for ELB.

          CLI example:

             salt myminion boto_elb.disable_availability_zones myelb '["us-east-1a"]'

   salt.modules.boto_elb.enable_availability_zones(name,
   availability_zones, region=None, key=None, keyid=None, profile=None)
          Enable availability zones for ELB.

          CLI example:

             salt myminion boto_elb.enable_availability_zones myelb '["us-east-1a"]'

   salt.modules.boto_elb.exists(name,  region=None,  key=None, keyid=None,
   profile=None)
          Check to see if an ELB exists.

          CLI example:

             salt myminion boto_elb.exists myelb region=us-east-1

   salt.modules.boto_elb.get_all_elbs(region=None,  key=None,  keyid=None,
   profile=None)
          Return all load balancers associated with an account

          CLI example:

             salt myminion boto_elb.get_all_elbs region=us-east-1

   salt.modules.boto_elb.get_attributes(name,    region=None,    key=None,
   keyid=None, profile=None)
          Check to see if attributes are set on an ELB.

          CLI example:

             salt myminion boto_elb.get_attributes myelb

   salt.modules.boto_elb.get_elb_config(name,    region=None,    key=None,
   keyid=None, profile=None)
          Get an ELB configuration.

          CLI example:

             salt myminion boto_elb.exists myelb region=us-east-1

   salt.modules.boto_elb.get_health_check(name,   region=None,   key=None,
   keyid=None, profile=None)
          Get the health check configured for this ELB.

          CLI example:

             salt myminion boto_elb.get_health_check myelb

   salt.modules.boto_elb.get_instance_health(name, region=None,  key=None,
   keyid=None, profile=None, instances=None)
          Get a list of instances and their health state

          CLI example:

             salt myminion boto_elb.get_instance_health myelb
             salt myminion boto_elb.get_instance_health myelb region=us-east-1 instances="[instance_id,instance_id]"

   salt.modules.boto_elb.list_elbs(region=None,    key=None,   keyid=None,
   profile=None)
          Return names of all load balancers associated with an account

          CLI example:

             salt myminion boto_elb.list_elbs region=us-east-1

   salt.modules.boto_elb.listener_dict_to_tuple(listener)
          Convert an ELB listener dict  into  a  listener  tuple  used  by
          certain parts of the AWS ELB API.

          CLI example:

             salt myminion boto_elb.listener_dict_to_tuple '{"elb_port":80,"instance_port":80,"elb_protocol":"HTTP"}'

   salt.modules.boto_elb.register_instances(name,  instances, region=None,
   key=None, keyid=None, profile=None)
          Register instances with an ELB.  Instances is  either  a  string
          instance id or a list of string instance id's.

          Returns:

          * True: instance(s) registered successfully

          * False: instance(s) failed to be registered

          CLI example:

             salt myminion boto_elb.register_instances myelb instance_id
             salt myminion boto_elb.register_instances myelb "[instance_id,instance_id]"

   salt.modules.boto_elb.set_attributes(name,   attributes,   region=None,
   key=None, keyid=None, profile=None)
          Set attributes on an ELB.

          name (string)
                 Name of the ELB instance to set attributes for

          attributes
                 A dict of attributes to set.

                 Valid attributes are:

                 access_log (dict)

                        enabled (bool)
                               Enable storage of access logs.

                        s3_bucket_name (string)
                               The name of the S3 bucket to place logs.

                        s3_bucket_prefix (string)
                               Prefix for the log file name.

                        emit_interval (int)
                               Interval for storing logs in S3 in minutes.
                               Valid values are 5 and 60.

                 connection_draining (dict)

                        enabled (bool)
                               Enable connection draining.

                        timeout (int)
                               Maximum allowed time in seconds for sending
                               existing connections to an instance that is
                               deregistering  or  unhealthy.   Default  is
                               300.

                 cross_zone_load_balancing (dict)

                        enabled (bool)
                               Enable cross-zone load balancing.

          CLI example to set attributes on an ELB:

             salt myminion boto_elb.set_attributes myelb '{"access_log": {"enabled": "true", "s3_bucket_name": "mybucket", "s3_bucket_prefix": "mylogs/", "emit_interval": "5"}}' region=us-east-1

   salt.modules.boto_elb.set_backend_policy(name,   port,   policies=None,
   region=None, key=None, keyid=None, profile=None)
          Set the policies of an ELB backend server.

          CLI example:
             salt    myminion    boto_elb.set_backend_policy   myelb   443
             "[policy1,policy2]"

   salt.modules.boto_elb.set_health_check(name, health_check, region=None,
   key=None, keyid=None, profile=None)
          Set attributes on an ELB.

          CLI example to set attributes on an ELB:

             salt myminion boto_elb.set_health_check myelb '{"target": "HTTP:80/"}'

   salt.modules.boto_elb.set_instances(name,     instances,    test=False,
   region=None, key=None, keyid=None, profile=None)
          Set the instances assigned to an ELB to exactly the list given

          CLI example:

             salt myminion boto_elb.set_instances myelb region=us-east-1 instances="[instance_id,instance_id]"

   salt.modules.boto_elb.set_listener_policy(name,  port,   policies=None,
   region=None, key=None, keyid=None, profile=None)
          Set the policies of an ELB listener.

          New in version 2016.3.0.

          CLI example:

             salt myminion boto_elb.set_listener_policy myelb 443 "[policy1,policy2]"

   salt.modules.boto_elb.set_tags(name,   tags,   region=None,   key=None,
   keyid=None, profile=None)
          Add the tags on an ELB

          New in version 2016.3.0.

          name   name of the ELB

          tags   dict of name/value pair tags

          CLI Example:

             salt myminion boto_elb.set_tags my-elb-name "{'Tag1': 'Value', 'Tag2': 'Another Value'}"

   salt.modules.boto_iam
   Connection module for Amazon IAM

   New in version 2014.7.0.

   configuration
          This module  accepts  explicit  iam  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles. Dynamic credentials are  then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             iam.keyid: GKTADJGHEIQSXMKKRBJ08H
             iam.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
             iam.region: us-east-1

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_iam.add_user_to_group(user_name,          group_name,
   region=None, key=None, keyid=None, profile=None)
          Add user to group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.add_user_to_group myuser mygroup

   salt.modules.boto_iam.associate_profile_to_role(profile_name,
   role_name, region=None, key=None, keyid=None, profile=None)
          Associate an instance profile with an IAM role.

          CLI Example:

             salt myminion boto_iam.associate_profile_to_role myirole myiprofile

   salt.modules.boto_iam.attach_group_policy(policy_name,      group_name,
   region=None, key=None, keyid=None, profile=None)
          Attach a managed policy to a group.

          CLI Example:

             salt myminion boto_iam.attach_group_policy mypolicy mygroup

   salt.modules.boto_iam.attach_role_policy(policy_name,        role_name,
   region=None, key=None, keyid=None, profile=None)
          Attach a managed policy to a role.

          CLI Example:

             salt myminion boto_iam.attach_role_policy mypolicy myrole

   salt.modules.boto_iam.attach_user_policy(policy_name,        user_name,
   region=None, key=None, keyid=None, profile=None)
          Attach a managed policy to a user.

          CLI Example:

             salt myminion boto_iam.attach_user_policy mypolicy myuser

   salt.modules.boto_iam.build_policy(region=None,  key=None,  keyid=None,
   profile=None)
          Build a default assume role policy.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.build_policy

   salt.modules.boto_iam.create_access_key(user_name,         region=None,
   key=None, keyid=None, profile=None)
          Create access key id for a user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.create_access_key myuser

   salt.modules.boto_iam.create_group(group_name, path=None,  region=None,
   key=None, keyid=None, profile=None)
          Create a group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.create_group group

   salt.modules.boto_iam.create_instance_profile(name,        region=None,
   key=None, keyid=None, profile=None)
          Create an instance profile.

          CLI Example:

             salt myminion boto_iam.create_instance_profile myiprofile

   salt.modules.boto_iam.create_login_profile(user_name,         password,
   region=None, key=None, keyid=None, profile=None)
          Creates  a  login  profile for the specified user, give the user
          the ability to  access  AWS  services  and  the  AWS  Management
          Console.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.create_login_profile user_name password

   salt.modules.boto_iam.create_policy(policy_name,       policy_document,
   path=None,   description=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Create a policy.

          CLI Example:

             salt myminios boto_iam.create_policy mypolicy '{"Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:Get*", "s3:List*"], "Resource": ["arn:aws:s3:::my-bucket/shared/*"]},]}'

   salt.modules.boto_iam.create_policy_version(policy_name,
   policy_document,    set_as_default=None,     region=None,     key=None,
   keyid=None, profile=None)
          Create a policy version.

          CLI Example:

             salt myminios boto_iam.create_policy_version mypolicy '{"Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:Get*", "s3:List*"], "Resource": ["arn:aws:s3:::my-bucket/shared/*"]},]}'

   salt.modules.boto_iam.create_role(name,           policy_document=None,
   path=None, region=None, key=None, keyid=None, profile=None)
          Create an instance role.

          CLI Example:

             salt myminion boto_iam.create_role myrole

   salt.modules.boto_iam.create_role_policy(role_name,        policy_name,
   policy, region=None, key=None, keyid=None, profile=None)
          Create or modify a role policy.

          CLI Example:

             salt myminion boto_iam.create_role_policy myirole mypolicy '{"MyPolicy": "Statement": [{"Action": ["sqs:*"], "Effect": "Allow", "Resource": ["arn:aws:sqs:*:*:*"], "Sid": "MyPolicySqs1"}]}'

   salt.modules.boto_iam.create_saml_provider(name,
   saml_metadata_document,     region=None,     key=None,      keyid=None,
   profile=None)
          Create SAML provider

          CLI Example:

             salt myminion boto_iam.create_saml_provider my_saml_provider_name saml_metadata_document

   salt.modules.boto_iam.create_user(user_name,   path=None,  region=None,
   key=None, keyid=None, profile=None)
          Create a user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.create_user myuser

   salt.modules.boto_iam.deactivate_mfa_device(user_name,          serial,
   region=None, key=None, keyid=None, profile=None)
          Deactivates  the  specified  MFA  device  and  removes  it  from
          association with the user.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_iam.deactivate_mfa_device user_name serial_num

   salt.modules.boto_iam.delete_access_key(access_key_id,  user_name=None,
   region=None, key=None, keyid=None, profile=None)
          Delete access key id from a user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.delete_access_key myuser

   salt.modules.boto_iam.delete_group(group_name,  region=None,  key=None,
   keyid=None, profile=None)
          Delete a group policy.

          CLI Example:

             .. code-block:: bash
             salt myminion boto_iam.delete_group mygroup

   salt.modules.boto_iam.delete_group_policy(group_name,      policy_name,
   region=None, key=None, keyid=None, profile=None)
          Delete a group policy.

          CLI Example:

             .. code-block:: bash
             salt myminion boto_iam.delete_group_policy mygroup mypolicy

   salt.modules.boto_iam.delete_instance_profile(name,        region=None,
   key=None, keyid=None, profile=None)
          Delete an instance profile.

          CLI Example:

             salt myminion boto_iam.delete_instance_profile myiprofile

   salt.modules.boto_iam.delete_login_profile(user_name,      region=None,
   key=None, keyid=None, profile=None)
          Deletes a login profile for the specified user.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_iam.delete_login_profile user_name

   salt.modules.boto_iam.delete_policy(policy_name, region=None, key=None,
   keyid=None, profile=None)
          Delete a policy.

          CLI Example:

             salt myminion boto_iam.delete_policy mypolicy

   salt.modules.boto_iam.delete_policy_version(policy_name,    version_id,
   region=None, key=None, keyid=None, profile=None)
          Delete a policy version.

          CLI Example:

             salt myminion boto_iam.delete_policy_version mypolicy v1

   salt.modules.boto_iam.delete_role(name,      region=None,     key=None,
   keyid=None, profile=None)
          Delete an IAM role.

          CLI Example:

             salt myminion boto_iam.delete_role myirole

   salt.modules.boto_iam.delete_role_policy(role_name,        policy_name,
   region=None, key=None, keyid=None, profile=None)
          Delete a role policy.

          CLI Example:

             salt myminion boto_iam.delete_role_policy myirole mypolicy

   salt.modules.boto_iam.delete_saml_provider(name, region=None, key=None,
   keyid=None, profile=None)
          Delete SAML provider

          CLI Example:

             salt myminion boto_iam.delete_saml_provider my_saml_provider_name

   salt.modules.boto_iam.delete_server_cert(cert_name,        region=None,
   key=None, keyid=None, profile=None)
          Deletes a certificate from Amazon.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.delete_server_cert mycert_name

   salt.modules.boto_iam.delete_user(user_name,   region=None,   key=None,
   keyid=None, profile=None)
          Delete a user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.delete_user myuser

   salt.modules.boto_iam.delete_user_policy(user_name,        policy_name,
   region=None, key=None, keyid=None, profile=None)
          Delete a user policy.

          CLI Example:

             salt myminion boto_iam.delete_user_policy myuser mypolicy

   salt.modules.boto_iam.describe_role(name,     region=None,    key=None,
   keyid=None, profile=None)
          Get information for a role.

          CLI Example:

             salt myminion boto_iam.describe_role myirole

   salt.modules.boto_iam.detach_group_policy(policy_name,      group_name,
   region=None, key=None, keyid=None, profile=None)
          Detach a managed policy to a group.

          CLI Example:

             salt myminion boto_iam.detach_group_policy mypolicy mygroup

   salt.modules.boto_iam.detach_role_policy(policy_name,        role_name,
   region=None, key=None, keyid=None, profile=None)
          Detach a managed policy to a role.

          CLI Example:

             salt myminion boto_iam.detach_role_policy mypolicy myrole

   salt.modules.boto_iam.detach_user_policy(policy_name,        user_name,
   region=None, key=None, keyid=None, profile=None)
          Detach a managed policy to a user.

          CLI Example:

             salt myminion boto_iam.detach_user_policy mypolicy myuser

   salt.modules.boto_iam.disassociate_profile_from_role(profile_name,
   role_name, region=None, key=None, keyid=None, profile=None)
          Disassociate an instance profile from an IAM role.

          CLI Example:

             salt myminion boto_iam.disassociate_profile_from_role myirole myiprofile

   salt.modules.boto_iam.export_users(path_prefix='/',        region=None,
   key=None, keyid=None, profile=None)
          Get  all  IAM user details. Produces results that can be used to
          create an sls file.

          New in version 2016.3.0.

          CLI Example:
             salt-call boto_iam.export_users --out=txt | sed "s/local: //"
             > iam_users.sls

   salt.modules.boto_iam.get_account_id(region=None, key=None, keyid=None,
   profile=None)
          Get a the AWS account id associated with the used credentials.

          CLI Example:

             salt myminion boto_iam.get_account_id

   salt.modules.boto_iam.get_account_policy(region=None,         key=None,
   keyid=None, profile=None)
          Get account policy for the AWS account.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_account_policy

   salt.modules.boto_iam.get_all_access_keys(user_name,       marker=None,
   max_items=None, region=None, key=None, keyid=None, profile=None)
          Get all access keys from a user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_all_access_keys myuser

   salt.modules.boto_iam.get_all_group_policies(group_name,   region=None,
   key=None, keyid=None, profile=None)
          Get a list of policy names from a group.

          CLI Example:

             salt myminion boto_iam.get_all_group_policies mygroup

   salt.modules.boto_iam.get_all_groups(path_prefix='/',      region=None,
   key=None, keyid=None, profile=None)
          Get and return all IAM group details, starting at  the  optional
          path.

          New in version 2016.3.0.

          CLI Example:
             salt-call boto_iam.get_all_groups

   salt.modules.boto_iam.get_all_instance_profiles(path_prefix='/',
   region=None, key=None, keyid=None, profile=None)
          Get and return  all  IAM  instance  profiles,  starting  at  the
          optional path.

          New in version 2016.11.0.

          CLI Example:
             salt-call boto_iam.get_all_instance_profiles

   salt.modules.boto_iam.get_all_mfa_devices(user_name,       region=None,
   key=None, keyid=None, profile=None)
          Get all MFA devices associated with an IAM user.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_iam.get_all_mfa_devices user_name

   salt.modules.boto_iam.get_all_roles(path_prefix=None,      region=None,
   key=None, keyid=None, profile=None)
          Get  and  return  all IAM role details, starting at the optional
          path.

          New in version 2016.3.0.

          CLI Example:
             salt-call boto_iam.get_all_roles

   salt.modules.boto_iam.get_all_user_policies(user_name,     marker=None,
   max_items=None, region=None, key=None, keyid=None, profile=None)
          Get all user policies.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_group mygroup

   salt.modules.boto_iam.get_all_users(path_prefix='/',       region=None,
   key=None, keyid=None, profile=None)
          Get and return all IAM user details, starting  at  the  optional
          path.

          New in version 2016.3.0.

          CLI Example:
             salt-call boto_iam.get_all_users

   salt.modules.boto_iam.get_group(group_name,    region=None,   key=None,
   keyid=None, profile=None)
          Get group information.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_group mygroup

   salt.modules.boto_iam.get_group_members(group_name,        region=None,
   key=None, keyid=None, profile=None)
          Get group information.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_iam.get_group mygroup

   salt.modules.boto_iam.get_group_policy(group_name,         policy_name,
   region=None, key=None, keyid=None, profile=None)
          Retrieves the specified policy document for the specified group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_group_policy mygroup policyname

   salt.modules.boto_iam.get_policy(policy_name,  region=None,   key=None,
   keyid=None, profile=None)
          Check to see if policy exists.

          CLI Example:

             salt myminion boto_iam.instance_profile_exists myiprofile

   salt.modules.boto_iam.get_policy_version(policy_name,       version_id,
   region=None, key=None, keyid=None, profile=None)
          Check to see if policy exists.

          CLI Example:

             salt myminion boto_iam.instance_profile_exists myiprofile

   salt.modules.boto_iam.get_role_policy(role_name,           policy_name,
   region=None, key=None, keyid=None, profile=None)
          Get a role policy.

          CLI Example:

             salt myminion boto_iam.get_role_policy myirole mypolicy

   salt.modules.boto_iam.get_saml_provider(name,   region=None,  key=None,
   keyid=None, profile=None)
          Get SAML provider document.

          CLI Example:

             salt myminion boto_iam.get_saml_provider arn

   salt.modules.boto_iam.get_saml_provider_arn(name,          region=None,
   key=None, keyid=None, profile=None)
          Get SAML provider

          CLI Example:

             salt myminion boto_iam.get_saml_provider_arn my_saml_provider_name

   salt.modules.boto_iam.get_server_certificate(cert_name,    region=None,
   key=None, keyid=None, profile=None)
          Returns certificate information from Amazon

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_server_certificate mycert_name

   salt.modules.boto_iam.get_user(user_name=None,  region=None,  key=None,
   keyid=None, profile=None)
          Get user information.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_user myuser

   salt.modules.boto_iam.get_user_policy(user_name,           policy_name,
   region=None, key=None, keyid=None, profile=None)
          Retrieves the specified policy document for the specified user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.get_user_policy myuser mypolicyname

   salt.modules.boto_iam.instance_profile_exists(name,        region=None,
   key=None, keyid=None, profile=None)
          Check to see if an instance profile exists.

          CLI Example:

             salt myminion boto_iam.instance_profile_exists myiprofile

   salt.modules.boto_iam.list_attached_group_policies(group_name,
   path_prefix=None,    entity_filter=None,     region=None,     key=None,
   keyid=None, profile=None)
          List entities attached to the given group.

          CLI Example:

             salt myminion boto_iam.list_entities_for_policy mypolicy

   salt.modules.boto_iam.list_attached_role_policies(role_name,
   path_prefix=None,    entity_filter=None,     region=None,     key=None,
   keyid=None, profile=None)
          List entities attached to the given role.

          CLI Example:

             salt myminion boto_iam.list_entities_for_policy mypolicy

   salt.modules.boto_iam.list_attached_user_policies(user_name,
   path_prefix=None,    entity_filter=None,     region=None,     key=None,
   keyid=None, profile=None)
          List entities attached to the given user.

          CLI Example:

             salt myminion boto_iam.list_entities_for_policy mypolicy

   salt.modules.boto_iam.list_entities_for_policy(policy_name,
   path_prefix=None,    entity_filter=None,     region=None,     key=None,
   keyid=None, profile=None)
          List entities that a policy is attached to.

          CLI Example:

             salt myminion boto_iam.list_entities_for_policy mypolicy

   salt.modules.boto_iam.list_instance_profiles(path_prefix='/',
   region=None, key=None, keyid=None, profile=None)
          List all IAM instance profiles, starting at the optional path.

          New in version 2016.11.0.

          CLI Example:
             salt-call boto_iam.list_instance_profiles

   salt.modules.boto_iam.list_policies(region=None, key=None,  keyid=None,
   profile=None)
          List policies.

          CLI Example:

             salt myminion boto_iam.list_policies

   salt.modules.boto_iam.list_policy_versions(policy_name,    region=None,
   key=None, keyid=None, profile=None)
          List versions of a policy.

          CLI Example:

             salt myminion boto_iam.list_policy_versions mypolicy

   salt.modules.boto_iam.list_role_policies(role_name,        region=None,
   key=None, keyid=None, profile=None)
          Get a list of policy names from a role.

          CLI Example:

             salt myminion boto_iam.list_role_policies myirole

   salt.modules.boto_iam.list_saml_providers(region=None,        key=None,
   keyid=None, profile=None)
          List SAML providers.

          CLI Example:

             salt myminion boto_iam.list_saml_providers

   salt.modules.boto_iam.policy_exists(policy_name, region=None, key=None,
   keyid=None, profile=None)
          Check to see if policy exists.

          CLI Example:

             salt myminion boto_iam.instance_profile_exists myiprofile

   salt.modules.boto_iam.policy_version_exists(policy_name,    version_id,
   region=None, key=None, keyid=None, profile=None)
          Check to see if policy exists.

          CLI Example:

             salt myminion boto_iam.instance_profile_exists myiprofile

   salt.modules.boto_iam.profile_associated(role_name,       profile_name,
   region, key, keyid, profile)
          Check  to  see  if an instance profile is associated with an IAM
          role.

          CLI Example:

             salt myminion boto_iam.profile_associated myirole myiprofile

   salt.modules.boto_iam.put_group_policy(group_name,         policy_name,
   policy_json, region=None, key=None, keyid=None, profile=None)
          Adds  or updates the specified policy document for the specified
          group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.put_group_policy mygroup policyname policyrules

   salt.modules.boto_iam.put_user_policy(user_name,           policy_name,
   policy_json, region=None, key=None, keyid=None, profile=None)
          Adds  or updates the specified policy document for the specified
          user.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.put_user_policy myuser policyname policyrules

   salt.modules.boto_iam.remove_user_from_group(group_name,     user_name,
   region=None, key=None, keyid=None, profile=None)
          Remove user from group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.remove_user_from_group mygroup myuser

   salt.modules.boto_iam.role_exists(name,      region=None,     key=None,
   keyid=None, profile=None)
          Check to see if an IAM role exists.

          CLI Example:

             salt myminion boto_iam.role_exists myirole

   salt.modules.boto_iam.set_default_policy_version(policy_name,
   version_id, region=None, key=None, keyid=None, profile=None)
          Set the default version of  a policy.

          CLI Example:

             salt myminion boto_iam.set_default_policy_version mypolicy v1

   salt.modules.boto_iam.update_account_password_policy(allow_users_to_change_password=None,
   hard_expiry=None, max_password_age=None,  minimum_password_length=None,
   password_reuse_prevention=None,      require_lowercase_characters=None,
   require_numbers=None,                             require_symbols=None,
   require_uppercase_characters=None,  region=None,  key=None, keyid=None,
   profile=None)
          Update the password policy for the AWS account.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.update_account_password_policy True

   salt.modules.boto_iam.update_assume_role_policy(role_name,
   policy_document, region=None, key=None, keyid=None, profile=None)
          Update an assume role policy for a role.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.update_assume_role_policy myrole '{"Statement":"..."}'

   salt.modules.boto_iam.update_saml_provider(name,
   saml_metadata_document,     region=None,     key=None,      keyid=None,
   profile=None)
          Update SAML provider.

          CLI Example:

             salt myminion boto_iam.update_saml_provider my_saml_provider_name saml_metadata_document

   salt.modules.boto_iam.upload_server_cert(cert_name,          cert_body,
   private_key,   cert_chain=None,   path=None,   region=None,   key=None,
   keyid=None, profile=None)
          Upload a certificate to Amazon.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.upload_server_cert mycert_name crt priv_key

          Parameters

                 * cert_name  --  The  name for the server certificate. Do
                   not include the path in this value.

                 * cert_body -- The contents of the public key certificate
                   in PEM-encoded format.

                 * private_key  --  The  contents  of  the  private key in
                   PEM-encoded format.

                 * cert_chain -- The contents of  the  certificate  chain.
                   This  is  typically  a concatenation of the PEM-encoded
                   public key certificates of the chain.

                 * path -- The path for the server certificate.

                 * region -- The name of the region to connect to.

                 * key -- The key to be used in order to connect

                 * keyid -- The keyid to be used in order to connect

                 * profile -- The profile that contains a dict of  region,
                   key, keyid

          Returns
                 True / False

   salt.modules.boto_iam.user_exists_in_group(user_name,       group_name,
   region=None, key=None, keyid=None, profile=None)
          Check if user exists in group.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_iam.user_exists_in_group myuser mygroup

   salt.modules.boto_iot module
   Connection module for Amazon IoT

   New in version 2016.3.0.

   configuration
          This module accepts explicit Lambda  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             iot.keyid: GKTADJGHEIQSXMKKRBJ08H
             iot.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             iot.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
               keyid: GKTADJGHEIQSXMKKRBJ08H
               key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
               region: us-east-1

   depends
          boto3

   salt.modules.boto_iot.attach_principal_policy(policyName,    principal,
   region=None, key=None, keyid=None, profile=None)
          Attach  the  specified  policy  to   the   specified   principal
          (certificate or other credential.)

          Returns  {attached:  true} if the policy was attached {attached:
          False} if the policy was not attached.

          CLI Example:

             salt myminion boto_iot.attach_principal_policy mypolicy mycognitoID

   salt.modules.boto_iot.create_policy(policyName,         policyDocument,
   region=None, key=None, keyid=None, profile=None)
          Given a valid config, create a policy.

          Returns  {created:  true}  if the policy was created and returns
          {created: False} if the policy was not created.

          CLI Example:

             salt myminion boto_iot.create_policy my_policy \
                   '{"Version":"2015-12-12",\
                   "Statement":[{"Effect":"Allow",\
                                 "Action":["iot:Publish"],\
                                 "Resource":["arn:::::topic/foo/bar"]}]}'

   salt.modules.boto_iot.create_policy_version(policyName, policyDocument,
   setAsDefault=False, region=None, key=None, keyid=None, profile=None)
          Given a valid config, create a new version of a policy.

          Returns  {created:  true}  if the policy version was created and
          returns {created: False} if the policy version was not created.

          CLI Example:

             salt myminion boto_iot.create_policy_version my_policy \
                    '{"Statement":[{"Effect":"Allow","Action":["iot:Publish"],"Resource":["arn:::::topic/foo/bar"]}]}'

   salt.modules.boto_iot.create_thing_type(thingTypeName,
   thingTypeDescription,  searchableAttributesList, region=None, key=None,
   keyid=None, profile=None)
          Given a valid config, create a thing type.

          Returns {created: true}  if  the  thing  type  was  created  and
          returns {created: False} if the thing type was not created.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_iot.create_thing_type mythingtype \
                   thingtype_description_string '["searchable_attr_1", "searchable_attr_2"]'

   salt.modules.boto_iot.create_topic_rule(ruleName,     sql,     actions,
   description,  ruleDisabled=False,  region=None,  key=None,  keyid=None,
   profile=None)
          Given a valid config, create a topic rule.

          Returns  {created:  true}  if  the  rule was created and returns
          {created: False} if the rule was not created.

          CLI Example:

             salt myminion boto_iot.create_topic_rule my_rule "SELECT * FROM 'some/thing'" \
                 '[{"lambda":{"functionArn":"arn:::::something"}},{"sns":{\
                 "targetArn":"arn:::::something","roleArn":"arn:::::something"}}]'

   salt.modules.boto_iot.delete_policy(policyName, region=None,  key=None,
   keyid=None, profile=None)
          Given a policy name, delete it.

          Returns  {deleted:  true}  if the policy was deleted and returns
          {deleted: false} if the policy was not deleted.

          CLI Example:

             salt myminion boto_iot.delete_policy mypolicy

   salt.modules.boto_iot.delete_policy_version(policyName,
   policyVersionId, region=None, key=None, keyid=None, profile=None)
          Given a policy name and version, delete it.

          Returns  {deleted:  true}  if the policy version was deleted and
          returns {deleted: false} if the policy version was not deleted.

          CLI Example:

             salt myminion boto_iot.delete_policy_version mypolicy version

   salt.modules.boto_iot.delete_thing_type(thingTypeName,     region=None,
   key=None, keyid=None, profile=None)
          Given a thing type name, delete it.

          Returns  {deleted:  true}  if  the  thing  type  was deleted and
          returns {deleted: false} if the thing type was not deleted.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_iot.delete_thing_type mythingtype

   salt.modules.boto_iot.delete_topic_rule(ruleName,          region=None,
   key=None, keyid=None, profile=None)
          Given a rule name, delete it.

          Returns  {deleted:  true}  if  the  rule was deleted and returns
          {deleted: false} if the rule was not deleted.

          CLI Example:

             salt myminion boto_iot.delete_rule myrule

   salt.modules.boto_iot.deprecate_thing_type(thingTypeName,
   undoDeprecate=False, region=None, key=None, keyid=None, profile=None)
          Given  a  thing  type  name,  deprecate it when undoDeprecate is
          False and undeprecate it when undoDeprecate is True.

          Returns {deprecated: true} if the thing type was deprecated  and
          returns   {deprecated:   false}   if  the  thing  type  was  not
          deprecated.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_iot.deprecate_thing_type mythingtype

   salt.modules.boto_iot.describe_policy(policyName,          region=None,
   key=None, keyid=None, profile=None)
          Given a policy name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_iot.describe_policy mypolicy

   salt.modules.boto_iot.describe_policy_version(policyName,
   policyVersionId, region=None, key=None, keyid=None, profile=None)
          Given a policy name and version describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_iot.describe_policy_version mypolicy version

   salt.modules.boto_iot.describe_thing_type(thingTypeName,   region=None,
   key=None, keyid=None, profile=None)
          Given a thing type name describe its properties.

          Returns a dictionary of interesting properties.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_iot.describe_thing_type mythingtype

   salt.modules.boto_iot.describe_topic_rule(ruleName,        region=None,
   key=None, keyid=None, profile=None)
          Given a topic rule name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_iot.describe_topic_rule myrule

   salt.modules.boto_iot.detach_principal_policy(policyName,    principal,
   region=None, key=None, keyid=None, profile=None)
          Detach   the  specified  policy  from  the  specified  principal
          (certificate or other credential.)

          Returns {detached: true} if the policy was  detached  {detached:
          False} if the policy was not detached.

          CLI Example:

             salt myminion boto_iot.detach_principal_policy mypolicy mycognitoID

   salt.modules.boto_iot.list_policies(region=None,  key=None, keyid=None,
   profile=None)
          List all policies

          Returns list of policies

          CLI Example:

             salt myminion boto_iot.list_policies

          Example Return:

             policies:
               - {...}
               - {...}

   salt.modules.boto_iot.list_policy_versions(policyName,     region=None,
   key=None, keyid=None, profile=None)
          List the versions available for the given policy.

          CLI Example:

             salt myminion boto_iot.list_policy_versions mypolicy

          Example Return:

             policyVersions:
               - {...}
               - {...}

   salt.modules.boto_iot.list_principal_policies(principal,   region=None,
   key=None, keyid=None, profile=None)
          List the policies attached to the given principal.

          CLI Example:

             salt myminion boto_iot.list_principal_policies myprincipal

          Example Return:

             policies:
               - {...}
               - {...}

   salt.modules.boto_iot.list_topic_rules(topic=None,   ruleDisabled=None,
   region=None, key=None, keyid=None, profile=None)
          List all rules (for a given topic, if specified)

          Returns list of rules

          CLI Example:

             salt myminion boto_iot.list_topic_rules

          Example Return:

             rules:
               - {...}
               - {...}

   salt.modules.boto_iot.policy_exists(policyName,  region=None, key=None,
   keyid=None, profile=None)
          Given a policy name, check to see if the given policy exists.

          Returns True if the given policy exists and returns False if the
          given policy does not exist.

          CLI Example:

             salt myminion boto_iot.policy_exists mypolicy

   salt.modules.boto_iot.policy_version_exists(policyName,
   policyVersionId, region=None, key=None, keyid=None, profile=None)
          Given a policy name and version ID, check to see  if  the  given
          policy version exists.

          Returns  True  if  the  given  policy version exists and returns
          False if the given policy version does not exist.

          CLI Example:

             salt myminion boto_iot.policy_version_exists mypolicy versionid

   salt.modules.boto_iot.replace_topic_rule(ruleName,    sql,     actions,
   description,  ruleDisabled=False,  region=None,  key=None,  keyid=None,
   profile=None)
          Given a valid config, replace a topic rule with the new values.

          Returns {created: true} if the  rule  was  created  and  returns
          {created: False} if the rule was not created.

          CLI Example:

             salt myminion boto_iot.replace_topic_rule my_rule 'SELECT * FROM some.thing' \
                 '[{"lambda":{"functionArn":"arn:::::something"}},{"sns":{\
                 "targetArn":"arn:::::something","roleArn":"arn:::::something"}}]'

   salt.modules.boto_iot.set_default_policy_version(policyName,
   policyVersionId, region=None, key=None, keyid=None, profile=None)
          Sets the specified  version  of  the  specified  policy  as  the
          policy's  default  (operative)  version. This action affects all
          certificates that the policy is attached to.

          Returns {changed: true} if the policy version was set  {changed:
          False} if the policy version was not set.

          CLI Example:

             salt myminion boto_iot.set_default_policy_version mypolicy versionid

   salt.modules.boto_iot.thing_type_exists(thingTypeName,     region=None,
   key=None, keyid=None, profile=None)
          Given a thing type name, check to see if the  given  thing  type
          exists

          Returns True if the given thing type exists and returns False if
          the given thing type does not exist.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_iot.thing_type_exists mythingtype

   salt.modules.boto_iot.topic_rule_exists(ruleName,          region=None,
   key=None, keyid=None, profile=None)
          Given a rule name, check to see if the given rule exists.

          Returns  True  if the given rule exists and returns False if the
          given rule does not exist.

          CLI Example:

             salt myminion boto_iot.topic_rule_exists myrule

   salt.modules.boto_kms
   Connection module for Amazon KMS

   New in version 2015.8.0.

   configuration
          This module  accepts  explicit  kms  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles. Dynamic credentials are  then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             kms.keyid: GKTADJGHEIQSXMKKRBJ08H
             kms.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             kms.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                    keyid:           GKTADJGHEIQSXMKKRBJ08H           key:
                    askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs      region:
                    us-east-1

   depends
          boto

   salt.modules.boto_kms.create_alias(alias_name,           target_key_id,
   region=None, key=None, keyid=None, profile=None)
          Create a display name for a key.

          CLI example:

             salt myminion boto_kms.create_alias 'alias/mykey' key_id

   salt.modules.boto_kms.create_grant(key_id,           grantee_principal,
   retiring_principal=None,       operations=None,       constraints=None,
   grant_tokens=None, region=None, key=None, keyid=None, profile=None)
          Adds a grant to a key to specify who  can  access  the  key  and
          under what conditions.

          CLI example:

             salt myminion boto_kms.create_grant 'alias/mykey' 'arn:aws:iam::1111111:/role/myrole' operations='["Encrypt","Decrypt"]'

   salt.modules.boto_kms.create_key(policy=None,         description=None,
   key_usage=None, region=None, key=None, keyid=None, profile=None)
          Creates a master key.

          CLI example:

             salt myminion boto_kms.create_key '{"Statement":...}' "My master key"

   salt.modules.boto_kms.decrypt(ciphertext_blob, encryption_context=None,
   grant_tokens=None, region=None, key=None, keyid=None, profile=None)
          Decrypt ciphertext.

          CLI example:

             salt myminion boto_kms.decrypt encrypted_ciphertext

   salt.modules.boto_kms.describe_key(key_id,    region=None,    key=None,
   keyid=None, profile=None)
          Get detailed information about a key.

          CLI example:

             salt myminion boto_kms.describe_key 'alias/mykey'

   salt.modules.boto_kms.disable_key(key_id,    region=None,     key=None,
   keyid=None, profile=None)
          Mark key as disabled.

          CLI example:

             salt myminion boto_kms.disable_key 'alias/mykey'

   salt.modules.boto_kms.disable_key_rotation(key_id,         region=None,
   key=None, keyid=None, profile=None)
          Disable key rotation for specified key.

          CLI example:

             salt myminion boto_kms.disable_key_rotation 'alias/mykey'

   salt.modules.boto_kms.enable_key(key_id,     region=None,     key=None,
   keyid=None, profile=None)
          Mark key as enabled.

          CLI example:

             salt myminion boto_kms.enable_key 'alias/mykey'

   salt.modules.boto_kms.enable_key_rotation(key_id,          region=None,
   key=None, keyid=None, profile=None)
          Disable key rotation for specified key.

          CLI example:

             salt myminion boto_kms.enable_key_rotation 'alias/mykey'

   salt.modules.boto_kms.encrypt(key_id,                        plaintext,
   encryption_context=None,   grant_tokens=None,   region=None,  key=None,
   keyid=None, profile=None)
          Encrypt plaintext into cipher text using specified key.

          CLI example:

             salt myminion boto_kms.encrypt 'alias/mykey' 'myplaindata' '{"aws:username":"myuser"}'

   salt.modules.boto_kms.generate_data_key(key_id,
   encryption_context=None,      number_of_bytes=None,      key_spec=None,
   grant_tokens=None, region=None, key=None, keyid=None, profile=None)
          Generate a secure data key.

          CLI example:

             salt myminion boto_kms.generate_data_key 'alias/mykey' number_of_bytes=1024 key_spec=AES_128

   salt.modules.boto_kms.generate_data_key_without_plaintext(key_id,
   encryption_context=None,      number_of_bytes=None,      key_spec=None,
   grant_tokens=None, region=None, key=None, keyid=None, profile=None)
          Generate a secure data key without a plaintext copy of the key.

          CLI example:

             salt myminion boto_kms.generate_data_key_without_plaintext 'alias/mykey' number_of_bytes=1024 key_spec=AES_128

   salt.modules.boto_kms.generate_random(number_of_bytes=None,
   region=None, key=None, keyid=None, profile=None)
          Generate a random string.

          CLI example:

             salt myminion boto_kms.generate_random number_of_bytes=1024

   salt.modules.boto_kms.get_key_policy(key_id,  policy_name, region=None,
   key=None, keyid=None, profile=None)
          Get the policy for the specified key.

          CLI example:

             salt myminion boto_kms.get_key_policy 'alias/mykey' mypolicy

   salt.modules.boto_kms.get_key_rotation_status(key_id,      region=None,
   key=None, keyid=None, profile=None)
          Get status of whether or not key rotation is enabled for a key.

          CLI example:

             salt myminion boto_kms.get_key_rotation_status 'alias/mykey'

   salt.modules.boto_kms.key_exists(key_id,     region=None,     key=None,
   keyid=None, profile=None)
          Check for the existence of a key.

          CLI example:

             salt myminion boto_kms.key_exists 'alias/mykey'

   salt.modules.boto_kms.list_grants(key_id,   limit=None,    marker=None,
   region=None, key=None, keyid=None, profile=None)
          List grants for the specified key.

          CLI example:

             salt myminion boto_kms.list_grants 'alias/mykey'

   salt.modules.boto_kms.list_key_policies(key_id,             limit=None,
   marker=None, region=None, key=None, keyid=None, profile=None)
          List key_policies for the specified key.

          CLI example:

             salt myminion boto_kms.list_key_policies 'alias/mykey'

   salt.modules.boto_kms.put_key_policy(key_id,    policy_name,    policy,
   region=None, key=None, keyid=None, profile=None)
          Attach a key policy to the specified key.

          CLI example:

             salt myminion boto_kms.put_key_policy 'alias/mykey' default '{"Statement":...}'

   salt.modules.boto_kms.re_encrypt(ciphertext_blob,   destination_key_id,
   source_encryption_context=None,    destination_encryption_context=None,
   grant_tokens=None, region=None, key=None, keyid=None, profile=None)
          Reencrypt encrypted data with a new master key.

          CLI example:

             salt myminion boto_kms.re_encrypt 'encrypted_data' 'alias/mynewkey' default '{"Statement":...}'

   salt.modules.boto_kms.revoke_grant(key_id,    grant_id,    region=None,
   key=None, keyid=None, profile=None)
          Revoke a grant from a key.

          CLI example:

             salt myminion boto_kms.revoke_grant 'alias/mykey' 8u89hf-j09j...

   salt.modules.boto_kms.update_key_description(key_id,       description,
   region=None, key=None, keyid=None, profile=None)
          Update a key's description.

          CLI example:

             salt myminion boto_kms.update_key_description 'alias/mykey' 'My key'

   salt.modules.boto_lambda module
   Connection module for Amazon Lambda

   New in version 2016.3.0.

   configuration
          This  module  accepts  explicit  Lambda credentials but can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.   Dynamic  credentials are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             lambda.keyid: GKTADJGHEIQSXMKKRBJ08H
             lambda.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             lambda.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   Changed in version 2015.8.0:  All  methods  now  return  a  dictionary.
   Create and delete methods return:

      created: true

   or

      created: false
      error:
        message: error message

   Request methods (e.g., describe_function) return:

      function:
        - {...}
        - {...}

   or

      error:
        message: error message

   depends
          boto3

   salt.modules.boto_lambda.add_permission(FunctionName,      StatementId,
   Action, Principal, SourceArn=None, SourceAccount=None,  Qualifier=None,
   region=None, key=None, keyid=None, profile=None)
          Add a permission to a lambda function.

          Returns  {added:  true}  if the permission was added and returns
          {added: False} if the permission was not added.

          CLI Example:

             salt myminion boto_lamba.add_permission my_function my_id "lambda:*" \
                                s3.amazonaws.com aws:arn::::bucket-name \
                                aws-account-id

   salt.modules.boto_lambda.alias_exists(FunctionName, Name,  region=None,
   key=None, keyid=None, profile=None)
          Given  a function name and alias name, check to see if the given
          alias exists.

          Returns True if the given alias exists and returns False if  the
          given alias does not exist.

          CLI Example:

             salt myminion boto_lambda.alias_exists myfunction myalias

   salt.modules.boto_lambda.create_alias(FunctionName,               Name,
   FunctionVersion,  Description='',  region=None,  key=None,  keyid=None,
   profile=None)
          Given a valid config, create an alias to a function.

          Returns  {created:  true}  if  the alias was created and returns
          {created: False} if the alias was not created.

          CLI Example:

             salt myminion boto_lamba.create_alias my_function my_alias $LATEST "An alias"

   salt.modules.boto_lambda.create_event_source_mapping(EventSourceArn,
   FunctionName,     StartingPosition,     Enabled=True,    BatchSize=100,
   region=None, key=None, keyid=None, profile=None)
          Identifies a stream as an event source for a Lambda function. It
          can  be  either  an  Amazon Kinesis stream or an Amazon DynamoDB
          stream. AWS Lambda invokes the specified function  when  records
          are posted to the stream.

          Returns  {created: true} if the event source mapping was created
          and returns {created: False} if the event source mapping was not
          created.

          CLI Example:

             salt myminion boto_lamba.create_event_source_mapping arn::::eventsource myfunction LATEST

   salt.modules.boto_lambda.create_function(FunctionName,  Runtime,  Role,
   Handler, ZipFile=None, S3Bucket=None, S3Key=None, S3ObjectVersion=None,
   Description='',      Timeout=3,      MemorySize=128,     Publish=False,
   WaitForRole=False, RoleRetries=5,  region=None,  key=None,  keyid=None,
   profile=None, VpcConfig=None)
          Given a valid config, create a function.

          Returns  {created: true} if the function was created and returns
          {created: False} if the function was not created.

          CLI Example:

             salt myminion boto_lamba.create_function my_function python2.7 my_role my_file.my_function my_function.zip

   salt.modules.boto_lambda.delete_alias(FunctionName, Name,  region=None,
   key=None, keyid=None, profile=None)
          Given a function name and alias name, delete the alias.

          Returns  {deleted:  true}  if  the alias was deleted and returns
          {deleted: false} if the alias was not deleted.

          CLI Example:

             salt myminion boto_lambda.delete_alias myfunction myalias

   salt.modules.boto_lambda.delete_event_source_mapping(UUID=None,
   EventSourceArn=None,    FunctionName=None,    region=None,    key=None,
   keyid=None, profile=None)
          Given an event source mapping ID or  an  event  source  ARN  and
          FunctionName, delete the event source mapping

          Returns  {deleted:  true} if the mapping was deleted and returns
          {deleted: false} if the mapping was not deleted.

          CLI Example:

             salt myminion boto_lambda.delete_event_source_mapping 260c423d-e8b5-4443-8d6a-5e91b9ecd0fa

   salt.modules.boto_lambda.delete_function(FunctionName,  Qualifier=None,
   region=None, key=None, keyid=None, profile=None)
          Given a function name and optional version qualifier, delete it.

          Returns  {deleted: true} if the function was deleted and returns
          {deleted: false} if the function was not deleted.

          CLI Example:

             salt myminion boto_lambda.delete_function myfunction

   salt.modules.boto_lambda.describe_alias(FunctionName,             Name,
   region=None, key=None, keyid=None, profile=None)
          Given  a function name and alias name describe the properties of
          the alias.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_lambda.describe_alias myalias

   salt.modules.boto_lambda.describe_event_source_mapping(UUID=None,
   EventSourceArn=None,    FunctionName=None,    region=None,    key=None,
   keyid=None, profile=None)
          Given an event source mapping ID or  an  event  source  ARN  and
          FunctionName, obtain the current settings of that mapping.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_lambda.describe_event_source_mapping uuid

   salt.modules.boto_lambda.describe_function(FunctionName,   region=None,
   key=None, keyid=None, profile=None)
          Given a function name describe its properties.

          Returns a dictionary of interesting properties.

          CLI Example:

             salt myminion boto_lambda.describe_function myfunction

   salt.modules.boto_lambda.event_source_mapping_exists(UUID=None,
   EventSourceArn=None,    FunctionName=None,    region=None,    key=None,
   keyid=None, profile=None)
          Given an event source mapping ID or  an  event  source  ARN  and
          FunctionName, check whether the mapping exists.

          Returns  True if the given alias exists and returns False if the
          given alias does not exist.

          CLI Example:

             salt myminion boto_lambda.alias_exists myfunction myalias

   salt.modules.boto_lambda.function_exists(FunctionName,     region=None,
   key=None, keyid=None, profile=None)
          Given  a  function name, check to see if the given function name
          exists.

          Returns True if the given function exists and returns  False  if
          the given function does not exist.

          CLI Example:

             salt myminion boto_lambda.function_exists myfunction

   salt.modules.boto_lambda.get_event_source_mapping_ids(EventSourceArn,
   FunctionName, region=None, key=None, keyid=None, profile=None)
          Given an event source  and  function  name,  return  a  list  of
          mapping IDs

          CLI Example:

             salt myminion boto_lambda.get_event_source_mapping_ids arn:::: myfunction

   salt.modules.boto_lambda.get_permissions(FunctionName,  Qualifier=None,
   region=None, key=None, keyid=None, profile=None)
          Get resource permissions for the given lambda function

          Returns dictionary of permissions, by statement ID

          CLI Example:

             salt myminion boto_lamba.get_permissions my_function

             permissions: {...}

   salt.modules.boto_lambda.list_function_versions(FunctionName,
   region=None, key=None, keyid=None, profile=None)
          List the versions available for the given function.

          Returns list of function versions

          CLI Example:

             versions:
               - {...}
               - {...}

   salt.modules.boto_lambda.remove_permission(FunctionName,   StatementId,
   Qualifier=None, region=None, key=None, keyid=None, profile=None)
          Remove a permission from a lambda function.

          Returns {removed:  true}  if  the  permission  was  removed  and
          returns {removed: False} if the permission was not removed.

          CLI Example:

             salt myminion boto_lamba.remove_permission my_function my_id

   salt.modules.boto_lambda.update_alias(FunctionName,               Name,
   FunctionVersion=None,    Description=None,    region=None,    key=None,
   keyid=None, profile=None)
          Update the named alias to the configuration.

          Returns  {updated:  true}  if  the alias was updated and returns
          {updated: False} if the alias was not updated.

          CLI Example:

             salt myminion boto_lamba.update_alias my_lambda my_alias $LATEST

   salt.modules.boto_lambda.update_event_source_mapping(UUID,
   FunctionName=None, Enabled=None, BatchSize=None, region=None, key=None,
   keyid=None, profile=None)
          Update the event source mapping identified by the UUID.

          Returns {updated: true} if the alias  was  updated  and  returns
          {updated: False} if the alias was not updated.

          CLI Example:

             salt myminion boto_lamba.update_event_source_mapping uuid FunctionName=new_function

   salt.modules.boto_lambda.update_function_code(FunctionName,
   ZipFile=None,    S3Bucket=None,    S3Key=None,    S3ObjectVersion=None,
   Publish=False, region=None, key=None, keyid=None, profile=None)
          Upload the given code to the named lambda function.

          Returns  {updated: true} if the function was updated and returns
          {updated: False} if the function was not updated.

          CLI Example:

             salt myminion boto_lamba.update_function_code my_function ZipFile=function.zip

   salt.modules.boto_lambda.update_function_config(FunctionName,
   Role=None,      Handler=None,      Description=None,      Timeout=None,
   MemorySize=None,  region=None,  key=None,   keyid=None,   profile=None,
   VpcConfig=None, WaitForRole=False, RoleRetries=5)
          Update the named lambda function to the configuration.

          Returns  {updated: true} if the function was updated and returns
          {updated: False} if the function was not updated.

          CLI Example:

             salt myminion boto_lamba.update_function_config my_function my_role my_file.my_function "my lambda function"

   salt.modules.boto_rds
   Connection module for Amazon RDS

   New in version 2015.8.0.

   configuration
          This module  accepts  explicit  rds  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             rds.keyid: GKTADJGHEIQSXMKKRBJ08H
             rds.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             rds.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto3

   salt.modules.boto_rds.create(name,                   allocated_storage,
   db_instance_class,   engine,   master_username,   master_user_password,
   db_name=None,   db_security_groups=None,   vpc_security_group_ids=None,
   availability_zone=None,                      db_subnet_group_name=None,
   preferred_maintenance_window=None,        db_parameter_group_name=None,
   backup_retention_period=None, preferred_backup_window=None,  port=None,
   multi_az=None,   engine_version=None,  auto_minor_version_upgrade=None,
   license_model=None,         iops=None,          option_group_name=None,
   character_set_name=None,   publicly_accessible=None,  wait_status=None,
   tags=None,        db_cluster_identifier=None,        storage_type=None,
   tde_credential_arn=None,                  tde_credential_password=None,
   storage_encrypted=None,          kms_key_id=None,          domain=None,
   copy_tags_to_snapshot=None,                   monitoring_interval=None,
   monitoring_role_arn=None,    domain_iam_role_name=None,    region=None,
   promotion_tier=None, key=None, keyid=None, profile=None)
          Create an RDS

          CLI example to create an RDS:

             salt myminion boto_rds.create myrds 10 db.t2.micro MySQL sqlusr sqlpassw

   salt.modules.boto_rds.create_option_group(name,            engine_name,
   major_engine_version, option_group_description, tags=None, region=None,
   key=None, keyid=None, profile=None)
          Create an RDS option group

          CLI example to create an RDS option group:

             salt myminion boto_rds.create_option_group my-opt-group mysql 5.6                 "group description"

   salt.modules.boto_rds.create_parameter_group(name,
   db_parameter_group_family,   description,    tags=None,    region=None,
   key=None, keyid=None, profile=None)
          Create an RDS parameter group

          CLI example to create an RDS parameter group:

             salt myminion boto_rds.create_parameter_group my-param-group mysql5.6                 "group description"

   salt.modules.boto_rds.create_read_replica(name,            source_name,
   db_instance_class=None,       availability_zone=None,        port=None,
   auto_minor_version_upgrade=None,   iops=None,   option_group_name=None,
   publicly_accessible=None,     tags=None,     db_subnet_group_name=None,
   storage_type=None,                          copy_tags_to_snapshot=None,
   monitoring_interval=None,    monitoring_role_arn=None,     region=None,
   key=None, keyid=None, profile=None)
          Create an RDS read replica

          CLI example to create an RDS  read replica:

             salt myminion boto_rds.create_read_replica replicaname source_name

   salt.modules.boto_rds.create_subnet_group(name,            description,
   subnet_ids, tags=None, region=None, key=None, keyid=None, profile=None)
          Create an RDS subnet group

          CLI example to create an RDS subnet group:

             salt myminion boto_rds.create_subnet_group my-subnet-group             "group description" '[subnet-12345678, subnet-87654321]'             region=us-east-1

   salt.modules.boto_rds.delete(name,            skip_final_snapshot=None,
   final_db_snapshot_identifier=None,  region=None,  key=None, keyid=None,
   profile=None, wait_for_deletion=True, timeout=180)
          Delete an RDS instance.

          CLI example:

             salt myminion boto_rds.delete myrds skip_final_snapshot=True                 region=us-east-1

   salt.modules.boto_rds.delete_option_group(name, region=None,  key=None,
   keyid=None, profile=None)
          Delete an RDS option group.

          CLI example:

             salt myminion boto_rds.delete_option_group my-opt-group                 region=us-east-1

   salt.modules.boto_rds.delete_parameter_group(name,         region=None,
   key=None, keyid=None, profile=None)
          Delete an RDS parameter group.

          CLI example:

             salt myminion boto_rds.delete_parameter_group my-param-group                 region=us-east-1

   salt.modules.boto_rds.delete_subnet_group(name, region=None,  key=None,
   keyid=None, profile=None)
          Delete an RDS subnet group.

          CLI example:

             salt myminion boto_rds.delete_subnet_group my-subnet-group                 region=us-east-1

   salt.modules.boto_rds.describe(name,  tags=None, region=None, key=None,
   keyid=None, profile=None)
          Return RDS instance details.

          CLI example:

             salt myminion boto_rds.describe myrds

   salt.modules.boto_rds.describe_parameter_group(name,      Filters=None,
   MaxRecords=None,   Marker=None,   region=None,   key=None,  keyid=None,
   profile=None)
          Returns a list of DBParameterGroup descriptions.  CLI example to
          description of parameter group:

             salt myminion boto_rds.describe_parameter_group parametergroupname            region=us-east-1

   salt.modules.boto_rds.describe_parameters(name,            Source=None,
   MaxRecords=None,  Marker=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Returns  a  list of DBParameterGroup parameters.  CLI example to
          description of parameters

             salt myminion boto_rds.describe_parameters parametergroupname            region=us-east-1

   salt.modules.boto_rds.exists(name,  tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Check to see if an RDS exists.

          CLI example:

             salt myminion boto_rds.exists myrds region=us-east-1

   salt.modules.boto_rds.get_endpoint(name,     tags=None,    region=None,
   key=None, keyid=None, profile=None)
          Return the endpoint of an RDS instance.

          CLI example:

             salt myminion boto_rds.get_endpoint myrds

   salt.modules.boto_rds.modify_db_instance(name,  allocated_storage=None,
   allow_major_version_upgrade=None,               apply_immediately=None,
   auto_minor_version_upgrade=None,          backup_retention_period=None,
   ca_certificate_identifier=None,                character_set_name=None,
   copy_tags_to_snapshot=None,                 db_cluster_identifier=None,
   db_instance_class=None,   db_name=None,   db_parameter_group_name=None,
   db_port_number=None,                           db_security_groups=None,
   db_subnet_group_name=None,    domain=None,   domain_iam_role_name=None,
   engine_version=None,  iops=None,  kms_key_id=None,  license_model=None,
   master_user_password=None,                    monitoring_interval=None,
   monitoring_role_arn=None,                                multi_az=None,
   new_db_instance_identifier=None,                option_group_name=None,
   preferred_backup_window=None,        preferred_maintenance_window=None,
   promotion_tier=None,  publicly_accessible=None, storage_encrypted=None,
   storage_type=None,                             tde_credential_arn=None,
   tde_credential_password=None, vpc_security_group_ids=None, region=None,
   key=None, keyid=None, profile=None)
          Modify settings for a DB instance.  CLI example  to  description
          of parameters

             salt myminion boto_rds.modify_db_instance db_instance_identifier region=us-east-1

   salt.modules.boto_rds.option_group_exists(name, tags=None, region=None,
   key=None, keyid=None, profile=None)
          Check to see if an RDS option group exists.

          CLI example:

             salt myminion boto_rds.option_group_exists myoptiongr region=us-east-1

   salt.modules.boto_rds.parameter_group_exists(name,           tags=None,
   region=None, key=None, keyid=None, profile=None)
          Check to see if an RDS parameter group exists.

          CLI example:

             salt myminion boto_rds.parameter_group_exists myparametergroup                 region=us-east-1

   salt.modules.boto_rds.subnet_group_exists(name, tags=None, region=None,
   key=None, keyid=None, profile=None)
          Check to see if an RDS subnet group exists.

          CLI example:

             salt myminion boto_rds.subnet_group_exists my-param-group                 region=us-east-1

   salt.modules.boto_rds.update_parameter_group(name,          parameters,
   apply_method='pending-reboot',    tags=None,   region=None,   key=None,
   keyid=None, profile=None)
          Update an RDS parameter group.

          CLI example:

             salt myminion boto_rds.update_parameter_group my-param-group                 parameters='{"back_log":1, "binlog_cache_size":4096}'                 region=us-east-1

   salt.modules.boto_route53
   Connection module for Amazon Route53

   New in version 2014.7.0.

   configuration
          This module accepts explicit route53 credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles.  Dynamic credentials are then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             route53.keyid: GKTADJGHEIQSXMKKRBJ08H
             route53.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             route53.region: us-east-1

          If  a region is not specified, the default is 'universal', which
          is what the boto_route53 library expects, rather than None.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
               keyid: GKTADJGHEIQSXMKKRBJ08H
               key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
               region: us-east-1

   depends
          boto

   salt.modules.boto_route53.add_record(name,  value,  zone,  record_type,
   identifier=None,    ttl=None,    region=None,   key=None,   keyid=None,
   profile=None, wait_for_sync=True, split_dns=False,  private_zone=False,
   retry_on_rate_limit=True, rate_limit_retries=5)
          Add a record to a zone.

          CLI example:

             salt myminion boto_route53.add_record test.example.org 1.1.1.1 example.org A

   salt.modules.boto_route53.create_hosted_zone(domain_name,
   caller_ref=None,    comment='',    private_zone=False,     vpc_id=None,
   vpc_name=None,   vpc_region=None,  region=None,  key=None,  keyid=None,
   profile=None)
          Create  a  new  Route53  Hosted  Zone.  Returns  a  Python  data
          structure with information about the newly created Hosted Zone.

          domain_name
                 The  name of the domain. This should be a fully-specified
                 domain, and should terminate with a period. This  is  the
                 name  you  have registered with your DNS registrar. It is
                 also the name you will delegate from  your  registrar  to
                 the  Amazon  Route  53  delegation  servers  returned  in
                 response to this request.

          caller_ref
                 A unique string that  identifies  the  request  and  that
                 allows  create_hosted_zone()  calls to be retried without
                 the risk of executing the operation twice.  You  want  to
                 provide this where possible, since additional calls while
                 the first is in PENDING status will be accepted  and  can
                 lead  to  multiple  copies  of  the zone being created in
                 Route53.

          comment
                 Any comments you want to include about the hosted zone.

          private_zone
                 Set True if creating a private hosted zone.

          vpc_id When creating a private hosted zone, either the VPC ID or
                 VPC  Name  to associate with is required.  Exclusive with
                 vpe_name.  Ignored if passed for a non-private zone.

          vpc_name
                 When creating a private hosted zone, either the VPC ID or
                 VPC  Name  to associate with is required.  Exclusive with
                 vpe_id.  Ignored if passed for a non-private zone.

          vpc_region
                 When creating a private hosted zone, the  region  of  the
                 associated  VPC  is required.  If not provided, an effort
                 will be made to determine it from vpc_id or vpc_name,  if
                 possible.   If  this  fails,  you'll  need  to provide an
                 explicit value for this option.  Ignored if passed for  a
                 non-private zone.

          region Region endpoint to connect to

          key    AWS key to bind with

          keyid  AWS keyid to bind with

          profile
                 Dict,  or  pillar  key pointing to a dict, containing AWS
                 region/key/keyid

          CLI Example:

             salt myminion boto_route53.create_hosted_zone example.org

   salt.modules.boto_route53.create_zone(zone, private=False, vpc_id=None,
   vpc_region=None, region=None, key=None, keyid=None, profile=None)
          Create a Route53 hosted zone.

          New in version 2015.8.0.

          zone   DNS zone to create

          private
                 True/False if the zone will be a private zone

          vpc_id VPC  ID  to associate the zone to (required if private is
                 True)

          vpc_region
                 VPC Region (required if private is True)

          region region endpoint to connect to

          key    AWS key

          keyid  AWS keyid

          profile
                 AWS pillar profile

          CLI Example:

             salt myminion boto_route53.create_zone example.org

   salt.modules.boto_route53.delete_record(name,    zone,     record_type,
   identifier=None,  all_records=False, region=None, key=None, keyid=None,
   profile=None, wait_for_sync=True, split_dns=False,  private_zone=False,
   retry_on_rate_limit=True, rate_limit_retries=5)
          Modify a record in a zone.

          CLI example:

             salt myminion boto_route53.delete_record test.example.org example.org A

   salt.modules.boto_route53.delete_zone(zone,    region=None,   key=None,
   keyid=None, profile=None)
          Delete a Route53 hosted zone.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_route53.delete_zone example.org

   salt.modules.boto_route53.describe_hosted_zones(zone_id=None,
   domain_name=None, region=None, key=None, keyid=None, profile=None)
          Return  detailed  info  about  one,  or  all, zones in the bound
          account.  If neither zone_id nor domain_name is provided, return
          all  zones.   Note  that the return format is slightly different
          between the 'all' and 'single' description types.

          zone_id
                 The unique identifier for the Hosted Zone

          domain_name
                 The FQDN of the Hosted Zone (including final period)

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          CLI Example:

             salt myminion boto_route53.describe_hosted_zones domain_name=foo.bar.com.                 profile='{"region": "us-east-1", "keyd": "A12345678AB", "key": "xblahblahblah"}'

   salt.modules.boto_route53.get_record(name,      zone,      record_type,
   fetch_all=False,  region=None,  key=None,   keyid=None,   profile=None,
   split_dns=False,          private_zone=False,          identifier=None,
   retry_on_rate_limit=True, rate_limit_retries=5)
          Get a record from a zone.

          CLI example:

             salt myminion boto_route53.get_record test.example.org example.org A

   salt.modules.boto_route53.list_all_zones_by_id(region=None,   key=None,
   keyid=None, profile=None)
          List, by their IDs, all hosted zones in the bound account.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          CLI Example:

             salt myminion boto_route53.list_all_zones_by_id

   salt.modules.boto_route53.list_all_zones_by_name(region=None, key=None,
   keyid=None, profile=None)
          List, by their FQDNs, all hosted zones in the bound account.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          CLI Example:

             salt myminion boto_route53.list_all_zones_by_name

   salt.modules.boto_route53.update_record(name, value, zone, record_type,
   identifier=None,    ttl=None,    region=None,   key=None,   keyid=None,
   profile=None, wait_for_sync=True, split_dns=False,  private_zone=False,
   retry_on_rate_limit=True, rate_limit_retries=5)
          Modify a record in a zone.

          CLI example:

             salt myminion boto_route53.modify_record test.example.org 1.1.1.1 example.org A

   salt.modules.boto_route53.zone_exists(zone,    region=None,   key=None,
   keyid=None,           profile=None,           retry_on_rate_limit=True,
   rate_limit_retries=5)
          Check for the existence of a Route53 hosted zone.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_route53.zone_exists example.org

   salt.modules.boto_secgroup
   Connection module for Amazon Security Groups

   New in version 2014.7.0.

   configuration
          This  module  accepts  explicit  ec2  credentials  but  can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.   Dynamic  credentials are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             secgroup.keyid: GKTADJGHEIQSXMKKRBJ08H
             secgroup.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             secgroup.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_secgroup.authorize(name=None, source_group_name=None,
   source_group_owner_id=None,      ip_protocol=None,      from_port=None,
   to_port=None, cidr_ip=None, group_id=None,  source_group_group_id=None,
   region=None,    key=None,    keyid=None,   profile=None,   vpc_id=None,
   vpc_name=None, egress=False)
          Add a new rule to an existing security group.

          CLI example:

             salt myminion boto_secgroup.authorize mysecgroup ip_protocol=tcp from_port=80 to_port=80 cidr_ip='['10.0.0.0/8', '192.168.0.0/24']'

   salt.modules.boto_secgroup.convert_to_group_ids(groups,    vpc_id=None,
   vpc_name=None, region=None, key=None, keyid=None, profile=None)
          Given    a    list    of   security   groups   and   a   vpc_id,
          convert_to_group_ids will convert all list items  in  the  given
          list to security group ids.

          CLI example:

             salt myminion boto_secgroup.convert_to_group_ids mysecgroup vpc-89yhh7h

   salt.modules.boto_secgroup.create(name,    description,    vpc_id=None,
   vpc_name=None, region=None, key=None, keyid=None, profile=None)
          Create a security group.

          CLI example:

             salt myminion boto_secgroup.create mysecgroup 'My Security Group'

   salt.modules.boto_secgroup.delete(name=None,             group_id=None,
   region=None,    key=None,    keyid=None,   profile=None,   vpc_id=None,
   vpc_name=None)
          Delete a security group.

          CLI example:

             salt myminion boto_secgroup.delete mysecgroup

   salt.modules.boto_secgroup.delete_tags(tags, name=None,  group_id=None,
   vpc_name=None,    vpc_id=None,   region=None,   key=None,   keyid=None,
   profile=None)
          deletes tags from a security group

          New in version 2016.3.0.

          tags   a list of tags to remove

          name   the name of the security group

          group_id
                 the group id of the security group (in lie of a  name/vpc
                 combo)

          vpc_name
                 the name of the vpc to search the named group for

          vpc_id the id of the vpc, in lieu of the vpc_name

          region the amazon region

          key    amazon key

          keyid  amazon keyid

          profile
                 amazon profile

          CLI example:

             salt myminion boto_secgroup.delete_tags ['TAG_TO_DELETE1','TAG_TO_DELETE2'] security_group_name vpc_id=vpc-13435 profile=my_aws_profile

   salt.modules.boto_secgroup.exists(name=None,   region=None,   key=None,
   keyid=None, profile=None, vpc_id=None, vpc_name=None, group_id=None)
          Check to see if a security group exists.

          CLI example:

             salt myminion boto_secgroup.exists mysecgroup

   salt.modules.boto_secgroup.get_all_security_groups(groupnames=None,
   group_ids=None,   filters=None,   region=None,   key=None,  keyid=None,
   profile=None)
          Return a list of all Security Groups matching the given criteria
          and filters.

          Note that the 'groupnames' argument only functions correctly for
          EC2 Classic and default VPC Security Groups.  To find groups  by
          name  in  other  VPCs you'll want to use the 'group-name' filter
          instead.

          Valid keys for the filters argument are:
                 description - The  description  of  the  security  group.
                 egress.ip-permission.prefix-list-id  - The ID (prefix) of
                 the AWS  service  to  which  the  security  group  allows
                 access.   group-id  -  The  ID  of  the  security  group.
                 group-name  -   The   name   of   the   security   group.
                 ip-permission.cidr  -  A CIDR range that has been granted
                 permission.  ip-permission.from-port - The start of  port
                 range  for  the  TCP  and  UDP protocols, or an ICMP type
                 number.  ip-permission.group-id - The ID  of  a  security
                 group     that     has     been    granted    permission.
                 ip-permission.group-name - The name of a  security  group
                 that has been granted permission.  ip-permission.protocol
                 - The IP protocol for the permission (tcp | udp | icmp or
                 a  protocol  number).  ip-permission.to-port - The end of
                 port range for the TCP and  UDP  protocols,  or  an  ICMP
                 code.   ip-permission.user-id  - The ID of an AWS account
                 that has been granted permission.   owner-id  -  The  AWS
                 account ID of the owner of the security group.  tag-key -
                 The  key  of  a  tag  assigned  to  the  security  group.
                 tag-value  -  The value of a tag assigned to the security
                 group.  vpc-id - The ID of the  VPC  specified  when  the
                 security group was created.

          CLI example:

             salt myminion boto_secgroup.get_all_security_groups filters='{group-name: mygroup}'

   salt.modules.boto_secgroup.get_config(name=None,         group_id=None,
   region=None,   key=None,   keyid=None,    profile=None,    vpc_id=None,
   vpc_name=None)
          Get the configuration for a security group.

          CLI example:

             salt myminion boto_secgroup.get_config mysecgroup

   salt.modules.boto_secgroup.get_group_id(name,              vpc_id=None,
   vpc_name=None, region=None, key=None, keyid=None, profile=None)
          Get a Group ID given a Group Name or Group Name and VPC ID

          CLI example:

             salt myminion boto_secgroup.get_group_id mysecgroup

   salt.modules.boto_secgroup.revoke(name=None,    source_group_name=None,
   source_group_owner_id=None,      ip_protocol=None,      from_port=None,
   to_port=None, cidr_ip=None, group_id=None,  source_group_group_id=None,
   region=None,    key=None,    keyid=None,   profile=None,   vpc_id=None,
   vpc_name=None, egress=False)
          Remove a rule from an existing security group.

          CLI example:

             salt myminion boto_secgroup.revoke mysecgroup ip_protocol=tcp from_port=80 to_port=80 cidr_ip='10.0.0.0/8'

   salt.modules.boto_secgroup.set_tags(tags,   name=None,   group_id=None,
   vpc_name=None,    vpc_id=None,   region=None,   key=None,   keyid=None,
   profile=None)
          sets tags on a security group

          New in version 2016.3.0.

          tags   a dict of key:value pair of tags to set on  the  security
                 group

          name   the name of the security gruop

          group_id
                 the  group id of the security group (in lie of a name/vpc
                 combo)

          vpc_name
                 the name of the vpc to search the named group for

          vpc_id the id of the vpc, in lieu of the vpc_name

          region the amazon region

          key    amazon key

          keyid  amazon keyid

          profile
                 amazon profile

          CLI example:

             salt myminion boto_secgroup.set_tags "{'TAG1': 'Value1', 'TAG2': 'Value2'}" security_group_name vpc_id=vpc-13435 profile=my_aws_profile

   salt.modules.boto_sns
   Connection module for Amazon SNS

   configuration
          This module  accepts  explicit  sns  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles. Dynamic credentials are  then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             sns.keyid: GKTADJGHEIQSXMKKRBJ08H
             sns.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             sns.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's  also  possible  to  specify  key,  keyid  and region via a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_sns.create(name,  region=None,  key=None, keyid=None,
   profile=None)
          Create an SNS topic.

          CLI example to create a topic:

             salt myminion boto_sns.create mytopic region=us-east-1

   salt.modules.boto_sns.delete(name, region=None,  key=None,  keyid=None,
   profile=None)
          Delete an SNS topic.

          CLI example to delete a topic:

             salt myminion boto_sns.delete mytopic region=us-east-1

   salt.modules.boto_sns.exists(name,  region=None,  key=None, keyid=None,
   profile=None)
          Check to see if an SNS topic exists.

          CLI example:

             salt myminion boto_sns.exists mytopic region=us-east-1

   salt.modules.boto_sns.get_all_subscriptions_by_topic(name, region=None,
   key=None, keyid=None, profile=None)
          Get list of all subscriptions to a specific topic.

          CLI example to delete a topic:

             salt myminion boto_sns.get_all_subscriptions_by_topic mytopic region=us-east-1

   salt.modules.boto_sns.get_all_topics(region=None, key=None, keyid=None,
   profile=None)
          Returns a list of the all topics..

          CLI example:

             salt myminion boto_sns.get_all_topics

   salt.modules.boto_sns.get_arn(name, region=None, key=None,  keyid=None,
   profile=None)
          Returns the full ARN for a given topic name.

          CLI example:

             salt myminion boto_sns.get_arn mytopic

   salt.modules.boto_sns.subscribe(topic, protocol, endpoint, region=None,
   key=None, keyid=None, profile=None)
          Subscribe to a Topic.

          CLI example to delete a topic:

             salt myminion boto_sns.subscribe mytopic https https://www.example.com/sns-endpoint region=us-east-1

   salt.modules.boto_sns.unsubscribe(topic, subscription_arn, region=None,
   key=None, keyid=None, profile=None)
          Unsubscribe a specific SubscriptionArn of a topic.

          CLI Example:

             salt myminion boto_sns.unsubscribe my_topic my_subscription_arn region=us-east-1

          New in version 2016.11.0.

   salt.modules.boto_sqs
   Connection module for Amazon SQS

   New in version 2014.7.0.

   configuration
          This  module  accepts  explicit  sqs  credentials  but  can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.  Dynamic  credentials  are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             sqs.keyid: GKTADJGHEIQSXMKKRBJ08H
             sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             sqs.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   depends
          boto

   salt.modules.boto_sqs.create(name, region=None,  key=None,  keyid=None,
   profile=None)
          Create an SQS queue.

          CLI Example:

             salt myminion boto_sqs.create myqueue region=us-east-1

   salt.modules.boto_sqs.delete(name,  region=None,  key=None, keyid=None,
   profile=None)
          Delete an SQS queue.

          CLI Example:

             salt myminion boto_sqs.delete myqueue region=us-east-1

   salt.modules.boto_sqs.exists(name, region=None,  key=None,  keyid=None,
   profile=None)
          Check to see if a queue exists.

          CLI Example:

             salt myminion boto_sqs.exists myqueue region=us-east-1

   salt.modules.boto_sqs.get_all_queues(prefix=None,          region=None,
   key=None, keyid=None, profile=None)
          Return a list of Queue() objects describing all visible queues.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_sqs.get_all_queues region=us-east-1 --output yaml

   salt.modules.boto_sqs.get_attributes(name,    region=None,    key=None,
   keyid=None, profile=None)
          Return attributes currently set on an SQS queue.

          CLI Example:

             salt myminion boto_sqs.get_attributes myqueue

   salt.modules.boto_sqs.list(prefix=None,      region=None,     key=None,
   keyid=None, profile=None)
          Return a list of the names of all visible queues.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_sqs.list region=us-east-1

   salt.modules.boto_sqs.set_attributes(name,   attributes,   region=None,
   key=None, keyid=None, profile=None)
          Set attributes on an SQS queue.

          CLI Example:

             salt myminion boto_sqs.set_attributes myqueue '{ReceiveMessageWaitTimeSeconds: 20}' region=us-east-1

   salt.modules.boto_vpc
   Connection module for Amazon VPC

   New in version 2014.7.0.

   configuration
          This  module  accepts  explicit  VPC  credentials  but  can also
          utilize IAM roles assigned  to  the  instance  through  Instance
          Profiles.   Dynamic  credentials are then automatically obtained
          from AWS API and no further  configuration  is  necessary.  More
          Information available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
             vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A region may also be specified in the configuration:

             vpc.region: us-east-1

          If a region is not specified, the default is us-east-1.

          It's also possible to  specify  key,  keyid  and  region  via  a
          profile, either as a passed in dict, or as a string to pull from
          pillars or minion config:

             myprofile:
                 keyid: GKTADJGHEIQSXMKKRBJ08H
                 key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                 region: us-east-1

   Changed in version 2015.8.0:  All  methods  now  return  a  dictionary.
   Create and delete methods return:

      created: true

   or

      created: false
      error:
        message: error message

   Request methods (e.g., describe_vpc) return:

      vpcs:
        - {...}
        - {...}

   or

      error:
        message: error message

   depends
          boto

   New in version 2016.11.0.

   Functions   to   request,  accept,  delete  and  describe  VPC  peering
   connections.  Named VPC peering  connections  can  be  requested  using
   these  modules.   VPC owner accounts can accept VPC peering connections
   (named or otherwise).

   Examples showing creation of VPC peering connection

      # Create a named VPC peering connection
      salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da name=my_vpc_connection
      # Without a name
      salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da
      # Specify a region
      salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da region=us-west-2

   Check to see if VPC peering connection is pending

      salt myminion boto_vpc.is_peering_connection_pending name=salt-vpc
      # Specify a region
      salt myminion boto_vpc.is_peering_connection_pending name=salt-vpc region=us-west-2
      # specify an id
      salt myminion boto_vpc.is_peering_connection_pending conn_id=pcx-8a8939e3

   Accept VPC peering connection

      salt myminion boto_vpc.accept_vpc_peering_connection name=salt-vpc
      # Specify a region
      salt myminion boto_vpc.accept_vpc_peering_connection name=salt-vpc region=us-west-2
      # specify an id
      salt myminion boto_vpc.accept_vpc_peering_connection conn_id=pcx-8a8939e3

   Deleting VPC peering connection via this module

      # Delete a named VPC peering connection
      salt myminion boto_vpc.delete_vpc_peering_connection name=salt-vpc
      # Specify a region
      salt myminion boto_vpc.delete_vpc_peering_connection name=salt-vpc region=us-west-2
      # specify an id
      salt myminion boto_vpc.delete_vpc_peering_connection conn_id=pcx-8a8939e3

   salt.modules.boto_vpc.accept_vpc_peering_connection(conn_id='',
   name='',     region=None,     key=None,    keyid=None,    profile=None,
   dry_run=False)
          Request a VPC peering connection between two VPCs.

          New in version 2016.11.0.

          Parameters

                 * conn_id -- The ID to use. String type.

                 * name -- The name of this VPC peering connection. String
                   type.

                 * region -- The AWS region to use. Type string.

          :param  key.  The  key  to use for this connection. Type string.
          :param keyid. The key id to use.  :param profile. The profile to
          use.  :param dry_run. The dry_run flag to set.  :return: dict

          Warning:  Please specify either the vpc_peering_connection_id or
          name but not both. Specifying both will result in an error!

          CLI Example:

             salt myminion boto_vpc.accept_vpc_peering_connection name=salt-vpc
             # Specify a region
             salt myminion boto_vpc.accept_vpc_peering_connection name=salt-vpc region=us-west-2
             # specify an id
             salt myminion boto_vpc.accept_vpc_peering_connection conn_id=pcx-8a8939e3

   salt.modules.boto_vpc.associate_dhcp_options_to_vpc(dhcp_options_id,
   vpc_id=None,    vpc_name=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Given valid DHCP options id and a valid VPC  id,  associate  the
          DHCP options record with the VPC.

          Returns  True  if  the  DHCP  options record were associated and
          returns False if the DHCP options record was not associated.

          CLI Example:

             salt myminion boto_vpc.associate_dhcp_options_to_vpc 'dhcp-a0bl34pp' 'vpc-6b1fe402'

   salt.modules.boto_vpc.associate_network_acl_to_subnet(network_acl_id=None,
   subnet_id=None,  network_acl_name=None,  subnet_name=None, region=None,
   key=None, keyid=None, profile=None)
          Given a network acl and subnet ids or names, associate a network
          acl to a subnet.

          CLI Example:

             salt myminion boto_vpc.associate_network_acl_to_subnet \
                     network_acl_id='acl-5fb85d36' subnet_id='subnet-6a1fe403'

             salt myminion boto_vpc.associate_network_acl_to_subnet \
                     network_acl_id='myacl' subnet_id='mysubnet'

   salt.modules.boto_vpc.associate_route_table(route_table_id=None,
   subnet_id=None, route_table_name=None,  subnet_name=None,  region=None,
   key=None, keyid=None, profile=None)
          Given  a route table and subnet name or id, associates the route
          table with the subnet.

          CLI Example:

             salt myminion boto_vpc.associate_route_table 'rtb-1f382e7d' 'subnet-6a1fe403'

             salt myminion boto_vpc.associate_route_table route_table_name='myrtb' \
                     subnet_name='mysubnet'

   salt.modules.boto_vpc.check_vpc(vpc_id=None,             vpc_name=None,
   region=None, key=None, keyid=None, profile=None)
          Check  whether  a VPC with the given name or id exists.  Returns
          the vpc_id or None. Raises SaltInvocationError  if  both  vpc_id
          and  vpc_name are None. Optionally raise a CommandExecutionError
          if the VPC does not exist.

          New in version 2016.3.0.

          CLI Example:

             salt myminion boto_vpc.check_vpc vpc_name=myvpc profile=awsprofile

   salt.modules.boto_vpc.create(cidr_block,         instance_tenancy=None,
   vpc_name=None,    enable_dns_support=None,   enable_dns_hostnames=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Given a valid CIDR block, create a VPC.

          An  optional  instance_tenancy  argument  can  be  provided.  If
          provided, the valid values are 'default' or 'dedicated'

          An optional vpc_name argument can be provided.

          Returns  {created:  true}  if  the  VPC  was created and returns
          {created: False} if the VPC was not created.

          CLI Example:

             salt myminion boto_vpc.create '10.0.0.0/24'

   salt.modules.boto_vpc.create_customer_gateway(vpn_connection_type,
   ip_address,     bgp_asn,     customer_gateway_name=None,     tags=None,
   region=None, key=None, keyid=None, profile=None)
          Given a valid VPN connection type, a static  IP  address  and  a
          customer  gateway's  Border  Gateway  Protocol  (BGP) Autonomous
          System Number, create a customer gateway.

          Returns the customer gateway id  if  the  customer  gateway  was
          created  and  returns  False  if  the  customer  gateway was not
          created.

          CLI Example:

             salt myminion boto_vpc.create_customer_gateway 'ipsec.1', '12.1.2.3', 65534

   salt.modules.boto_vpc.create_dhcp_options(domain_name=None,
   domain_name_servers=None,  ntp_servers=None, netbios_name_servers=None,
   netbios_node_type=None, dhcp_options_name=None, tags=None, vpc_id=None,
   vpc_name=None, region=None, key=None, keyid=None, profile=None)
          Given   valid  DHCP  options,  create  a  DHCP  options  record,
          optionally associating it with an existing VPC.

          Returns True if the DHCP options record was created and  returns
          False if the DHCP options record was not deleted.

          Changed in version 2015.8.0: Added vpc_name and vpc_id arguments

          CLI Example:

             salt myminion boto_vpc.create_dhcp_options domain_name='example.com' \
                     domain_name_servers='[1.2.3.4]' ntp_servers='[5.6.7.8]' \
                     netbios_name_servers='[10.0.0.1]' netbios_node_type=1 \
                     vpc_name='myvpc'

   salt.modules.boto_vpc.create_internet_gateway(internet_gateway_name=None,
   vpc_id=None,   vpc_name=None,   tags=None,    region=None,    key=None,
   keyid=None, profile=None)
          Create  an  Internet  Gateway,  optionally  attaching  it  to an
          existing VPC.

          Returns the internet gateway id  if  the  internet  gateway  was
          created  and  returns  False  if  the  internet gateways was not
          created.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.create_internet_gateway \
                     internet_gateway_name=myigw vpc_name=myvpc

   salt.modules.boto_vpc.create_nat_gateway(subnet_id=None,
   subnet_name=None,     allocation_id=None,     region=None,    key=None,
   keyid=None, profile=None)
          Create a NAT Gateway within an existing subnet. If allocation_id
          is specified, the elastic IP address it references is associated
          with the gateway. Otherwise, a new allocation_id is created  and
          used.

          This function requires boto3 to be installed.

          Returns  the  nat  gateway id if the nat gateway was created and
          returns False if the nat gateway was not created.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_vpc.create_nat_gateway subnet_name=mysubnet

   salt.modules.boto_vpc.create_network_acl(vpc_id=None,    vpc_name=None,
   network_acl_name=None,   subnet_id=None,  subnet_name=None,  tags=None,
   region=None, key=None, keyid=None, profile=None)
          Given a vpc_id, creates a network acl.

          Returns the network acl  id  if  successful,  otherwise  returns
          False.

          Changed  in  version  2015.8.0:  Added  vpc_name, subnet_id, and
          subnet_name arguments

          CLI Example:

             salt myminion boto_vpc.create_network_acl 'vpc-6b1fe402'

   salt.modules.boto_vpc.create_network_acl_entry(network_acl_id=None,
   rule_number=None,   protocol=None,  rule_action=None,  cidr_block=None,
   egress=None,  network_acl_name=None,  icmp_code=None,   icmp_type=None,
   port_range_from=None,    port_range_to=None,   region=None,   key=None,
   keyid=None, profile=None)
          Creates a network acl entry.

          CLI Example:

             salt myminion boto_vpc.create_network_acl_entry 'acl-5fb85d36' '32767' \
                     'all' 'deny' '0.0.0.0/0' egress=true

   salt.modules.boto_vpc.create_route(route_table_id=None,
   destination_cidr_block=None,   route_table_name=None,  gateway_id=None,
   internet_gateway_name=None,    instance_id=None,     interface_id=None,
   vpc_peering_connection_id=None,       vpc_peering_connection_name=None,
   region=None, key=None, keyid=None,  profile=None,  nat_gateway_id=None,
   nat_gateway_subnet_name=None, nat_gateway_subnet_id=None)
          Creates a route.

          If a nat gateway is specified, boto3 must be installed

          CLI Example:

             salt myminion boto_vpc.create_route 'rtb-1f382e7d' '10.0.0.0/16' gateway_id='vgw-a1b2c3'

   salt.modules.boto_vpc.create_route_table(vpc_id=None,    vpc_name=None,
   route_table_name=None, tags=None,  region=None,  key=None,  keyid=None,
   profile=None)
          Creates a route table.

          Changed in version 2015.8.0: Added vpc_name argument

          CLI Examples:

             salt myminion boto_vpc.create_route_table vpc_id='vpc-6b1fe402' \
                     route_table_name='myroutetable'
             salt myminion boto_vpc.create_route_table vpc_name='myvpc' \
                     route_table_name='myroutetable'

   salt.modules.boto_vpc.create_subnet(vpc_id=None,       cidr_block=None,
   vpc_name=None,  availability_zone=None,  subnet_name=None,   tags=None,
   region=None, key=None, keyid=None, profile=None)
          Given  a  valid VPC ID or Name and a CIDR block, create a subnet
          for the VPC.

          An optional availability zone argument can be provided.

          Returns True if the VPC subnet was created and returns False  if
          the VPC subnet was not created.

          Changed in version 2015.8.0: Added vpc_name argument

          CLI Examples:

             salt myminion boto_vpc.create_subnet vpc_id='vpc-6b1fe402' \
                     subnet_name='mysubnet' cidr_block='10.0.0.0/25'
             salt myminion boto_vpc.create_subnet vpc_name='myvpc' \
                     subnet_name='mysubnet', cidr_block='10.0.0.0/25'

   salt.modules.boto_vpc.customer_gateway_exists(customer_gateway_id=None,
   customer_gateway_name=None,    region=None,    key=None,    keyid=None,
   profile=None)
          Given  a  customer  gateway ID, check if the customer gateway ID
          exists.

          Returns True if the customer gateway ID  exists;  Returns  False
          otherwise.

          CLI Example:

             salt myminion boto_vpc.customer_gateway_exists cgw-b6a247df
             salt myminion boto_vpc.customer_gateway_exists customer_gatway_name=mycgw

   salt.modules.boto_vpc.delete(vpc_id=None,   name=None,   vpc_name=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Given a VPC ID or VPC name, delete the VPC.

          Returns {deleted: true} if  the  VPC  was  deleted  and  returns
          {deleted: false} if the VPC was not deleted.

          CLI Example:

             salt myminion boto_vpc.delete vpc_id='vpc-6b1fe402'
             salt myminion boto_vpc.delete name='myvpc'

   salt.modules.boto_vpc.delete_customer_gateway(customer_gateway_id=None,
   customer_gateway_name=None,    region=None,    key=None,    keyid=None,
   profile=None)
          Given  a  customer  gateway  ID  or  name,  delete  the customer
          gateway.

          Returns True if the customer gateway  was  deleted  and  returns
          False if the customer gateway was not deleted.

          Changed   in   version   2015.8.0:  Added  customer_gateway_name
          argument

          CLI Example:

             salt myminion boto_vpc.delete_customer_gateway 'cgw-b6a247df'

   salt.modules.boto_vpc.delete_dhcp_options(dhcp_options_id=None,
   dhcp_options_name=None,      region=None,     key=None,     keyid=None,
   profile=None)
          Delete dhcp options by id or name.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.delete_dhcp_options 'dopt-b6a247df'

   salt.modules.boto_vpc.delete_internet_gateway(internet_gateway_id=None,
   internet_gateway_name=None,    detach=False,   region=None,   key=None,
   keyid=None, profile=None)
          Delete an internet gateway (by name or id).

          Returns True if the internet gateway was deleted  and  otherwise
          False.

          New in version 2015.8.0.

          CLI Examples:

             salt myminion boto_vpc.delete_internet_gateway internet_gateway_id=igw-1a2b3c
             salt myminion boto_vpc.delete_internet_gateway internet_gateway_name=myigw

   salt.modules.boto_vpc.delete_nat_gateway(nat_gateway_id,
   release_eips=False, region=None,  key=None,  keyid=None,  profile=None,
   wait_for_delete=False, wait_for_delete_retries=5)
          Delete a nat gateway (by id).

          Returns  True  if the internet gateway was deleted and otherwise
          False.

          This function requires boto3 to be installed.

          New in version 2016.11.0.

          nat_gateway_id
                 Id of the NAT Gateway

          releaes_eips
                 whether to release the elastic IPs  associated  with  the
                 given NAT Gateway Id

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          wait_for_delete
                 whether to wait for delete of the NAT gateway  to  be  in
                 failed or deleted state after issuing the delete call.

          wait_for_delete_retries
                 NAT  gateway  may take some time to be go into deleted or
                 failed state.  During the  deletion  process,  subsequent
                 release   of  elastic  IPs  may  fail;  this  state  will
                 automatically retry this number of times  to  ensure  the
                 NAT   gateway  is  in  deleted  or  failed  state  before
                 proceeding.

          CLI Examples:

             salt myminion boto_vpc.delete_nat_gateway nat_gateway_id=igw-1a2b3c

   salt.modules.boto_vpc.delete_network_acl(network_acl_id=None,
   network_acl_name=None,   disassociate=False,   region=None,   key=None,
   keyid=None, profile=None)
          Delete  a  network  acl   based   on   the   network_acl_id   or
          network_acl_name provided.

          CLI Examples:

             salt myminion boto_vpc.delete_network_acl network_acl_id='acl-5fb85d36' \
                     disassociate=false

             salt myminion boto_vpc.delete_network_acl network_acl_name='myacl' \
                     disassociate=true

   salt.modules.boto_vpc.delete_network_acl_entry(network_acl_id=None,
   rule_number=None,  egress=None,   network_acl_name=None,   region=None,
   key=None, keyid=None, profile=None)
          Deletes a network acl entry.

          CLI Example:

             salt myminion boto_vpc.delete_network_acl_entry 'acl-5fb85d36' '32767'

   salt.modules.boto_vpc.delete_route(route_table_id=None,
   destination_cidr_block=None,    route_table_name=None,     region=None,
   key=None, keyid=None, profile=None)
          Deletes a route.

          CLI Example:

             salt myminion boto_vpc.delete_route 'rtb-1f382e7d' '10.0.0.0/16'

   salt.modules.boto_vpc.delete_route_table(route_table_id=None,
   route_table_name=None, region=None, key=None, keyid=None, profile=None)
          Deletes a route table.

          CLI Examples:

             salt myminion boto_vpc.delete_route_table route_table_id='rtb-1f382e7d'
             salt myminion boto_vpc.delete_route_table route_table_name='myroutetable'

   salt.modules.boto_vpc.delete_subnet(subnet_id=None,   subnet_name=None,
   region=None, key=None, keyid=None, profile=None)
          Given a subnet ID or name, delete the subnet.

          Returns  True if the subnet was deleted and returns False if the
          subnet was not deleted.

          Changed in version 2015.8.0: Added subnet_name argument

          CLI Example:

             salt myminion boto_vpc.delete_subnet 'subnet-6a1fe403'

   salt.modules.boto_vpc.delete_vpc_peering_connection(conn_id=None,
   conn_name=None,   region=None,   key=None,   keyid=None,  profile=None,
   dry_run=False)
          Delete a VPC peering connection.

          New in version 2016.11.0.

          conn_id
                 The connection ID to check.  Exclusive with conn_name.

          conn_name
                 The connection name to check.  Exclusive with conn_id.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          dry_run
                 If  True,  skip  application  and simply return projected
                 status.

          CLI Example:

             # Create a named VPC peering connection
             salt myminion boto_vpc.delete_vpc_peering_connection conn_name=salt-vpc
             # Specify a region
             salt myminion boto_vpc.delete_vpc_peering_connection conn_name=salt-vpc region=us-west-2
             # specify an id
             salt myminion boto_vpc.delete_vpc_peering_connection conn_id=pcx-8a8939e3

   salt.modules.boto_vpc.describe(vpc_id=None, vpc_name=None, region=None,
   key=None, keyid=None, profile=None)
          Given a VPC ID describe its properties.

          Returns a dictionary of interesting properties.

          Changed in version 2015.8.0: Added vpc_name argument

          CLI Example:

             salt myminion boto_vpc.describe vpc_id=vpc-123456
             salt myminion boto_vpc.describe vpc_name=myvpc

   salt.modules.boto_vpc.describe_nat_gateways(nat_gateway_id=None,
   subnet_id=None,    subnet_name=None,    vpc_id=None,     vpc_name=None,
   states=('pending',  'available'),  region=None,  key=None,  keyid=None,
   profile=None)
          Return a description of  nat  gateways  matching  the  selection
          criteria

          This function requires boto3 to be installed.

          CLI Example:

             salt myminion boto_vpc.describe_nat_gateways nat_gateway_id='nat-03b02643b43216fe7'
             salt myminion boto_vpc.describe_nat_gateways subnet_id='subnet-5b05942d'

   salt.modules.boto_vpc.describe_route_table(route_table_id=None,
   route_table_name=None, tags=None,  region=None,  key=None,  keyid=None,
   profile=None)
          Given  route  table  properties,  return  route table details if
          matching table(s) exist.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.describe_route_table route_table_id='rtb-1f382e7d'

   salt.modules.boto_vpc.describe_route_tables(route_table_id=None,
   route_table_name=None,  vpc_id=None,  tags=None, region=None, key=None,
   keyid=None, profile=None)
          Given route table properties, return  details  of  all  matching
          route tables.

          This function requires boto3 to be installed.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_vpc.describe_route_tables vpc_id='vpc-a6a9efc3'

   salt.modules.boto_vpc.describe_subnet(subnet_id=None, subnet_name=None,
   region=None, key=None, keyid=None, profile=None)
          Given a subnet id or name, describe its properties.

          Returns a dictionary of interesting properties.

          New in version 2015.8.0.

          CLI Examples:

             salt myminion boto_vpc.describe_subnet subnet_id=subnet-123456
             salt myminion boto_vpc.describe_subnet subnet_name=mysubnet

   salt.modules.boto_vpc.describe_subnets(subnet_ids=None,
   subnet_names=None,   vpc_id=None,   cidr=None,  region=None,  key=None,
   keyid=None, profile=None)
          Given a VPC ID or subnet CIDR,  returns  a  list  of  associated
          subnets  and their details. Return all subnets if VPC ID or CIDR
          are not provided.  If a subnet id or CIDR is provided, only  its
          associated subnet details will be returned.

          New in version 2015.8.0.

          CLI Examples:

             salt myminion boto_vpc.describe_subnets

             salt myminion boto_vpc.describe_subnets subnet_ids=['subnet-ba1987ab', 'subnet-ba1987cd']

             salt myminion boto_vpc.describe_subnets vpc_id=vpc-123456

             salt myminion boto_vpc.describe_subnets cidr=10.0.0.0/21

   salt.modules.boto_vpc.describe_vpc_peering_connection(name,
   region=None, key=None, keyid=None, profile=None)
          Returns any VPC peering  connection  id(s)  for  the  given  VPC
          peering connection name.

          VPC  peering  connection  ids  are only returned for connections
          that are  in  the  active,  pending-acceptance  or  provisioning
          state.

          New in version 2016.11.0.

          Parameters

                 * name -- The string name for this VPC peering connection

                 * region -- The aws region to use

                 * key -- Your aws key

                 * keyid -- The key id associated with this aws account

                 * profile -- The profile to use

          Returns
                 dict

          CLI Example:

             salt myminion boto_vpc.describe_vpc_peering_connection salt-vpc
             # Specify a region
             salt myminion boto_vpc.describe_vpc_peering_connection salt-vpc region=us-west-2

   salt.modules.boto_vpc.describe_vpcs(vpc_id=None,  name=None, cidr=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Describe all VPCs, matching the filter criteria if provided.

          Returns a a list of dictionaries with interesting properties.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.describe_vpcs

   salt.modules.boto_vpc.dhcp_options_exists(dhcp_options_id=None,
   name=None,  dhcp_options_name=None,  tags=None,  region=None, key=None,
   keyid=None, profile=None)
          Check if a dhcp option exists.

          Returns True if the dhcp option exists; Returns False otherwise.

          CLI Example:

             salt myminion boto_vpc.dhcp_options_exists dhcp_options_id='dhcp-a0bl34pp'

   salt.modules.boto_vpc.disassociate_network_acl(subnet_id=None,
   vpc_id=None,  subnet_name=None,  vpc_name=None,  region=None, key=None,
   keyid=None, profile=None)
          Given a subnet ID, disassociates a network acl.

          CLI Example:

             salt myminion boto_vpc.disassociate_network_acl 'subnet-6a1fe403'

   salt.modules.boto_vpc.disassociate_route_table(association_id,
   region=None, key=None, keyid=None, profile=None)
          Dissassociates a route table.

          association_id
                 The Route Table Association ID to disassociate

          CLI Example:

             salt myminion boto_vpc.disassociate_route_table 'rtbassoc-d8ccddba'

   salt.modules.boto_vpc.exists(vpc_id=None,     name=None,     cidr=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Given a VPC ID, check to see if the given VPC ID exists.

          Returns True if the given VPC ID exists and returns False if the
          given VPC ID does not exist.

          CLI Example:

             salt myminion boto_vpc.exists myvpc

   salt.modules.boto_vpc.get_dhcp_options(dhcp_options_name=None,
   dhcp_options_id=None, region=None, key=None, keyid=None, profile=None)
          Return a dict with the current  values  of  the  requested  DHCP
          options set

          CLI Example:

             salt myminion boto_vpc.get_dhcp_options 'myfunnydhcpoptionsname'

          New in version 2016.3.0.

   salt.modules.boto_vpc.get_id(name=None,      cidr=None,      tags=None,
   region=None, key=None, keyid=None, profile=None)
          Given VPC properties, return the VPC id if a match is found.

          CLI Example:

             salt myminion boto_vpc.get_id myvpc

   salt.modules.boto_vpc.get_resource_id(resource,              name=None,
   resource_id=None, region=None, key=None, keyid=None, profile=None)
          Get an AWS id for a VPC resource by type and name.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.get_resource_id internet_gateway myigw

   salt.modules.boto_vpc.get_subnet_association(subnets,      region=None,
   key=None, keyid=None, profile=None)
          Given a subnet (aka: a vpc zone identifier) or list of  subnets,
          returns vpc association.

          Returns  a  VPC  ID if the given subnets are associated with the
          same VPC ID.  Returns False on an error or if the given  subnets
          are associated with different VPC IDs.

          CLI Examples:

             salt myminion boto_vpc.get_subnet_association subnet-61b47516

             salt myminion boto_vpc.get_subnet_association ['subnet-61b47516','subnet-2cb9785b']

   salt.modules.boto_vpc.is_peering_connection_pending(conn_id=None,
   conn_name=None, region=None, key=None, keyid=None, profile=None)
          Check if a VPC peering connection is in the pending state.

          New in version 2016.11.0.

          conn_id
                 The connection ID to check.  Exclusive with conn_name.

          conn_name
                 The connection name to check.  Exclusive with conn_id.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          CLI Example:

             salt myminion boto_vpc.is_peering_connection_pending conn_name=salt-vpc
             # Specify a region
             salt myminion boto_vpc.is_peering_connection_pending conn_name=salt-vpc region=us-west-2
             # specify an id
             salt myminion boto_vpc.is_peering_connection_pending conn_id=pcx-8a8939e3

   salt.modules.boto_vpc.nat_gateway_exists(nat_gateway_id=None,
   subnet_id=None,    subnet_name=None,    vpc_id=None,     vpc_name=None,
   states=('pending',  'available'),  region=None,  key=None,  keyid=None,
   profile=None)
          Checks if a nat gateway exists.

          This function requires boto3 to be installed.

          New in version 2016.11.0.

          CLI Example:

             salt myminion boto_vpc.nat_gateway_exists nat_gateway_id='nat-03b02643b43216fe7'
             salt myminion boto_vpc.nat_gateway_exists subnet_id='subnet-5b05942d'

   salt.modules.boto_vpc.network_acl_exists(network_acl_id=None,
   name=None,  network_acl_name=None,  tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Checks if a network acl exists.

          Returns True if the network acl exists or returns  False  if  it
          doesn't exist.

          CLI Example:

             salt myminion boto_vpc.network_acl_exists network_acl_id='acl-5fb85d36'

   salt.modules.boto_vpc.peering_connection_pending_from_vpc(conn_id=None,
   conn_name=None,  vpc_id=None,  vpc_name=None,  region=None,   key=None,
   keyid=None, profile=None)
          Check  if  a VPC peering connection is in the pending state, and
          requested from the given VPC.

          New in version 2016.11.0.

          conn_id
                 The connection ID to check.  Exclusive with conn_name.

          conn_name
                 The connection name to check.  Exclusive with conn_id.

          vpc_id Is this the ID of the requesting  VPC  for  this  peering
                 connection.  Exclusive with vpc_name.

          vpc_name
                 Is  this  the Name of the requesting VPC for this peering
                 connection.  Exclusive with vpc_id.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          CLI Example:

             salt myminion boto_vpc.is_peering_connection_pending name=salt-vpc

   salt.modules.boto_vpc.replace_network_acl_entry(network_acl_id=None,
   rule_number=None,  protocol=None,  rule_action=None,   cidr_block=None,
   egress=None,   network_acl_name=None,  icmp_code=None,  icmp_type=None,
   port_range_from=None,   port_range_to=None,   region=None,    key=None,
   keyid=None, profile=None)
          Replaces a network acl entry.

          CLI Example:

             salt myminion boto_vpc.replace_network_acl_entry 'acl-5fb85d36' '32767' \
                     'all' 'deny' '0.0.0.0/0' egress=true

   salt.modules.boto_vpc.replace_route(route_table_id=None,
   destination_cidr_block=None,  route_table_name=None,   gateway_id=None,
   instance_id=None, interface_id=None, region=None, key=None, keyid=None,
   profile=None, vpc_peering_connection_id=None)
          Replaces a route.

          CLI Example:

             salt myminion boto_vpc.replace_route 'rtb-1f382e7d' '10.0.0.0/16' gateway_id='vgw-a1b2c3'

   salt.modules.boto_vpc.replace_route_table_association(association_id,
   route_table_id, region=None, key=None, keyid=None, profile=None)
          Replaces a route table association.

          CLI Example:

             salt myminion boto_vpc.replace_route_table_association 'rtbassoc-d8ccddba' 'rtb-1f382e7d'

   salt.modules.boto_vpc.request_vpc_peering_connection(requester_vpc_id=None,
   requester_vpc_name=None,     peer_vpc_id=None,      peer_vpc_name=None,
   name=None,   peer_owner_id=None,   region=None,  key=None,  keyid=None,
   profile=None, dry_run=False)
          Request a VPC peering connection between two VPCs.

          New in version 2016.11.0.

          requester_vpc_id
                 ID   of    the    requesting    VPC.    Exclusive    with
                 requester_vpc_name.

          requester_vpc_name
                 Name   tag   of   the  requesting  VPC.   Exclusive  with
                 requester_vpc_id.

          peer_vpc_id
                 ID of the VPC tp crete VPC peering connection with.  This
                 can   be   a  VPC  in  another  account.  Exclusive  with
                 peer_vpc_name.

          peer_vpc_name
                 Name tag of the VPC tp crete VPC peering connection with.
                 This  can  only  be  a  VPC  in  the  same  account, else
                 resolving it into a vpc ID will  almost  certainly  fail.
                 Exclusive with peer_vpc_id.

          name   The name to use for this VPC peering connection.

          peer_owner_id
                 ID of the owner of the peer VPC. Defaults to your account
                 ID, so a value is required if peering with  a  VPC  in  a
                 different account.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          dry_run
                 If True, skip application and return status.

          CLI Example:

             # Create a named VPC peering connection
             salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da name=my_vpc_connection
             # Without a name
             salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da
             # Specify a region
             salt myminion boto_vpc.request_vpc_peering_connection vpc-4a3e622e vpc-be82e9da region=us-west-2

   salt.modules.boto_vpc.resource_exists(resource,              name=None,
   resource_id=None,   tags=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Given a resource type and name,  return  {exists:  true}  if  it
          exists,  {exists:  false}  if  it  does  not  exist,  or {error:
          {message: error text} on error.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.resource_exists internet_gateway myigw

   salt.modules.boto_vpc.route_exists(destination_cidr_block,
   route_table_name=None,       route_table_id=None,      gateway_id=None,
   instance_id=None, interface_id=None, tags=None, region=None,  key=None,
   keyid=None, profile=None, vpc_peering_connection_id=None)
          Checks if a route exists.

          New in version 2015.8.0.

          CLI Example:

             salt myminion boto_vpc.route_exists destination_cidr_block='10.0.0.0/20' gateway_id='local' route_table_name='test'

   salt.modules.boto_vpc.route_table_exists(route_table_id=None,
   name=None,  route_table_name=None,  tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Checks if a route table exists.

          CLI Example:

             salt myminion boto_vpc.route_table_exists route_table_id='rtb-1f382e7d'

   salt.modules.boto_vpc.subnet_exists(subnet_id=None,          name=None,
   subnet_name=None,  cidr=None,   tags=None,   zones=None,   region=None,
   key=None, keyid=None, profile=None)
          Check if a subnet exists.

          Returns True if the subnet exists, otherwise returns False.

          Changed   in   version   2015.8.0:  Added  subnet_name  argument
          Deprecated name argument

          CLI Example:

             salt myminion boto_vpc.subnet_exists subnet_id='subnet-6a1fe403'

   salt.modules.bower
   Manage and query Bower packages
   This module manages the installed packages using Bower.  Note that npm,
   git and bower must be installed for this module to be available.

   salt.modules.bower.install(pkg, dir, pkgs=None, runas=None, env=None)
          Install a Bower package.

          If  no  package is specified, the dependencies (from bower.json)
          of the package in the given directory will be installed.

          pkg    A package name in any format accepted by Bower, including
                 a version identifier

          dir    The target directory in which to install the package

          pkgs   A  list  of  package  names in the same format as the pkg
                 parameter

          runas  The user to run Bower with

          env    Environment variables to set when  invoking  Bower.  Uses
                 the same env format as the cmd.run execution function.

          CLI Example:

             salt '*' bower.install underscore /path/to/project

             salt '*' bower.install jquery#2.0 /path/to/project

   salt.modules.bower.list(dir, runas=None, env=None)
          List installed Bower packages.

          dir    The directory whose packages will be listed

          runas  The user to run Bower with

          env    Environment  variables  to  set when invoking Bower. Uses
                 the same env format as the cmd.run execution function.

          CLI Example:

             salt '*' bower.list /path/to/project

   salt.modules.bower.uninstall(pkg, dir, runas=None, env=None)
          Uninstall a Bower package.

          pkg    A package name in any format accepted by Bower

          dir    The target directory from which to uninstall the package

          runas  The user to run Bower with

          env    Environment variables to set when  invoking  Bower.  Uses
                 the same env format as the cmd.run execution function.

          CLI Example:

             salt '*' bower.uninstall underscore /path/to/project

   salt.modules.bridge
   Module for gathering and managing bridging information

   salt.modules.bridge.add(br=None)
          Creates a bridge

          CLI Example:

             salt '*' bridge.add br0

   salt.modules.bridge.addif(br=None, iface=None)
          Adds an interface to a bridge

          CLI Example:

             salt '*' bridge.addif br0 eth0

   salt.modules.bridge.delete(br=None)
          Deletes a bridge

          CLI Example:

             salt '*' bridge.delete br0

   salt.modules.bridge.delif(br=None, iface=None)
          Removes an interface from a bridge

          CLI Example:

             salt '*' bridge.delif br0 eth0

   salt.modules.bridge.find_interfaces(*args)
          Returns the bridge to which the interfaces are bond to

          CLI Example:

             salt '*' bridge.find_interfaces eth0 [eth1...]

   salt.modules.bridge.interfaces(br=None)
          Returns interfaces attached to a bridge

          CLI Example:

             salt '*' bridge.interfaces br0

   salt.modules.bridge.list()
          Returns the machine's bridges list

          CLI Example:

             salt '*' bridge.list

   salt.modules.bridge.show(br=None)
          Returns   bridges   interfaces   along  with  enslaved  physical
          interfaces. If no interface is given,  all  bridges  are  shown,
          else only the specified bridge values are returned.

          CLI Example:

             salt '*' bridge.show
             salt '*' bridge.show br0

   salt.modules.bridge.stp(br=None, state='disable', iface=None)
          Sets Spanning Tree Protocol state for a bridge

          CLI Example:

             salt '*' bridge.stp br0 enable
             salt '*' bridge.stp br0 disable

          For  BSD-like  operating  systems,  it  is  required  to add the
          interface on which to enable the STP.

          CLI Example:

             salt '*' bridge.stp bridge0 enable fxp0
             salt '*' bridge.stp bridge0 disable fxp0

   salt.modules.bsd_shadow
   Manage the password database on BSD systems

   IMPORTANT:
      If you feel  that  Salt  should  be  using  this  module  to  manage
      passwords  on a minion, and it is using a different module (or gives
      an error similar to 'shadow.info' is not available), see here.

   salt.modules.bsd_shadow.default_hash()
          Returns the default hash used for unset passwords

          CLI Example:

             salt '*' shadow.default_hash

   salt.modules.bsd_shadow.del_password(name)
          New in version 2015.8.2.

          Delete the password from name user

          CLI Example:

             salt '*' shadow.del_password username

   salt.modules.bsd_shadow.info(name)
          Return information for the specified user

          CLI Example:

             salt '*' shadow.info someuser

   salt.modules.bsd_shadow.set_change(name, change)
          Sets the time at which the password expires  (in  seconds  since
          the  UNIX epoch). See man 8 usermod on NetBSD and OpenBSD or man
          8 pw on FreeBSD.

          A value of 0 sets the password to never expire.

          CLI Example:

             salt '*' shadow.set_change username 1419980400

   salt.modules.bsd_shadow.set_expire(name, expire)
          Sets the time at which the account expires (in seconds since the
          UNIX epoch). See man 8 usermod on NetBSD and OpenBSD or man 8 pw
          on FreeBSD.

          A value of 0 sets the account to never expire.

          CLI Example:

             salt '*' shadow.set_expire username 1419980400

   salt.modules.bsd_shadow.set_password(name, password)
          Set the password for a  named  user.  The  password  must  be  a
          properly  defined  hash. The password hash can be generated with
          this command:

          python   -c   "import   crypt;   print   crypt.crypt('password',
          ciphersalt)"

          NOTE:
             When  constructing the ciphersalt string, you must escape any
             dollar signs, to avoid them being interpolated by the shell.

          'password' is, of course, the password for  which  you  want  to
          generate a hash.

          ciphersalt  is a combination of a cipher identifier, an optional
          number of rounds, and the cryptographic  salt.  The  arrangement
          and  format  of  these  fields  depends  on the cipher and which
          flavor of BSD you are using. For more information on  this,  see
          the  manpage  for crpyt(3). On NetBSD, additional information is
          available in passwd.conf(5).

          It is important to make sure that a supported cipher is used.

          CLI Example:

             salt '*' shadow.set_password someuser '$1$UYCIxa628.9qXjpQCjM4a..'

   salt.modules.btrfs
   Module for managing BTRFS file systems.

   salt.modules.btrfs.add(mountpoint, *devices, **kwargs)
          Add a devices to a BTRFS filesystem.

          General options:

          * nodiscard: Do not perform whole device TRIM

          * force: Force overwrite existing filesystem on the disk

          CLI Example:

             salt '*' btrfs.add /mountpoint /dev/sda1 /dev/sda2

   salt.modules.btrfs.convert(device, permanent=False, keeplf=False)
          Convert ext2/3/4 to BTRFS. Device should be mounted.

          Filesystem  can  be  converted  temporarily   so   the   further
          processing  and  rollback  is  possible,  or  permanently, where
          previous extended filesystem image gets  deleted.  Please  note,
          permanent  conversion takes a while as BTRFS filesystem needs to
          be properly rebalanced afterwards.

          General options:

          * permanent: Specify if the migration should be permanent (false
            by default)

          *

            keeplf: Keep lost+found of the partition (removed by default,
                   but still in the image, if not permanent migration)

          CLI Example:

             salt '*' btrfs.convert /dev/sda1
             salt '*' btrfs.convert /dev/sda1 permanent=True

   salt.modules.btrfs.defragment(path)
          Defragment  mounted  BTRFS filesystem.  In order to defragment a
          filesystem, device should be properly mounted and writable.

          If passed a device name,  then  defragmented  whole  filesystem,
          mounted  on in.  If passed a moun tpoint of the filesystem, then
          only this mount point is defragmented.

          CLI Example:

             salt '*' btrfs.defragment /dev/sda1
             salt '*' btrfs.defragment /path/on/filesystem

   salt.modules.btrfs.delete(mountpoint, *devices, **kwargs)
          Remove devices from a BTRFS filesystem.

          CLI Example:

             salt '*' btrfs.delete /mountpoint /dev/sda1 /dev/sda2

   salt.modules.btrfs.devices()
          Get known BTRFS formatted devices on the system.

          CLI Example:

             salt '*' btrfs.devices

   salt.modules.btrfs.features()
          List currently available BTRFS features.

          CLI Example:

             salt '*' btrfs.mkfs_features

   salt.modules.btrfs.info(device)
          Get BTRFS filesystem information.

          CLI Example:

             salt '*' btrfs.info /dev/sda1

   salt.modules.btrfs.mkfs(*devices, **kwargs)
          Create a file system on the specified device. By  default  wipes
          out with force.

          General options:

          * allocsize:  Specify  the  BTRFS  offset  from the start of the
            device.

          * bytecount: Specify the size of the resultant filesystem.

          * nodesize: Node size.

          * leafsize: Specify the nodesize, the tree block size  in  which
            btrfs stores data.

          * noforce:  Prevent  force overwrite when an existing filesystem
            is detected on the device.

          * sectorsize: Specify the sectorsize,  the  minimum  data  block
            allocation unit.

          * nodiscard:  Do  not  perform  whole  device  TRIM operation by
            default.

          * uuid: Pass UUID or pass True to generate one.

          Options:

          *

            dto: (raid0|raid1|raid5|raid6|raid10|single|dup)
                   Specify how the data must be spanned across the devices
                   specified.

          *

            mto: (raid0|raid1|raid5|raid6|raid10|single|dup)
                   Specify how metadata must be spanned across the devices
                   specified.

          * fts: Features (call salt <host> btrfs.features for  full  list
            of available features)

          See the mkfs.btrfs(8) manpage for a more complete description of
          corresponding options description.

          CLI Example:

             salt '*' btrfs.mkfs /dev/sda1
             salt '*' btrfs.mkfs /dev/sda1 noforce=True

   salt.modules.btrfs.properties(obj, type=None, set=None)
          List properties for given btrfs object. The object can  be  path
          of  BTRFS  device,  mount point, or any directories/files inside
          the BTRFS filesystem.

          General options:

          * type: Possible types are s[ubvol], f[ilesystem],  i[node]  and
            d[evice].

          * force: Force overwrite existing filesystem on the disk

          * set:   <key=value,key1=value1...>  Options  for  a  filesystem
            properties.

          CLI Example:

             salt '*' btrfs.properties /mountpoint
             salt '*' btrfs.properties /dev/sda1 type=subvol set='ro=false,label="My Storage"'

   salt.modules.btrfs.resize(mountpoint, size)
          Resize filesystem.

          General options:

          * mountpoint: Specify the BTRFS mountpoint to resize.

          * size: ([+/-]<newsize>[kKmMgGtTpPeE]|max) Specify the new  size
            of the target.

          CLI Example:

             salt '*' btrfs.resize /mountpoint size=+1g
             salt '*' btrfs.resize /dev/sda1 size=max

   salt.modules.btrfs.usage(path)
          Show in which disk the chunks are allocated.

          CLI Example:

             salt '*' btrfs.usage /your/mountpoint

   salt.modules.btrfs.version()
          Return BTRFS version.

          CLI Example:

             salt '*' btrfs.version

   salt.modules.cabal
   Manage and query Cabal packages
   New in version 2015.8.0.

   salt.modules.cabal.install(pkg=None,        pkgs=None,       user=None,
   install_global=False, env=None)
          Install a cabal package.

          pkg    A package name in format accepted by cabal-install.  See:
                 https://wiki.haskell.org/Cabal-Install

          pkgs   A list of packages names in same format as pkg

          user   The user to run cabal install with

          install_global
                 Install package globally instead of locally

          env    Environment  variables  to  set when invoking cabal. Uses
                 the same env format as the cmd.run execution function

          CLI Example:

             salt '*' cabal.install shellcheck
             salt '*' cabal.install shellcheck-0.3.5

   salt.modules.cabal.list(pkg=None, user=None, installed=False, env=None)
          List packages matching a search string.

          pkg    Search string for matching package names

          user   The user to run cabal list with

          installed
                 If True, only return installed packages.

          env    Environment variables to set when  invoking  cabal.  Uses
                 the same env format as the cmd.run execution function

          CLI example:

             salt '*' cabal.list
             salt '*' cabal.list ShellCheck

   salt.modules.cabal.uninstall(pkg, user=None, env=None)
          Uninstall a cabal package.

          pkg    The package to uninstall

          user   The user to run ghc-pkg unregister with

          env    Environment  variables  to  set when invoking cabal. Uses
                 the same env format as the cmd.run execution function

          CLI Example:

             salt '*' cabal.uninstall ShellCheck

   salt.modules.cabal.update(user=None, env=None)
          Updates list of known packages.

          user   The user to run cabal update with

          env    Environment variables to set when  invoking  cabal.  Uses
                 the same env format as the cmd.run execution function.

          CLI Example:

             salt '*' cabal.update

   salt.modules.cassandra
   Cassandra NoSQL Database Module

   depends

          * pycassa Cassandra Python adapter

   configuration
          The  location  of  the 'nodetool' command, host, and thrift port
          needs to be specified via pillar:

             cassandra.nodetool: /usr/local/bin/nodetool
             cassandra.host: localhost
             cassandra.thrift_port: 9160

   salt.modules.cassandra.column_families(keyspace=None)
          Return existing column families for all keyspaces  or  just  the
          provided one.

          CLI Example:

             salt '*' cassandra.column_families
             salt '*' cassandra.column_families <keyspace>

   salt.modules.cassandra.column_family_definition(keyspace,
   column_family)
          Return a dictionary of column family definitions for  the  given
          keyspace/column_family

          CLI Example:

             salt '*' cassandra.column_family_definition <keyspace> <column_family>

   salt.modules.cassandra.compactionstats()
          Return compactionstats info

          CLI Example:

             salt '*' cassandra.compactionstats

   salt.modules.cassandra.info()
          Return cassandra node info

          CLI Example:

             salt '*' cassandra.info

   salt.modules.cassandra.keyspaces()
          Return existing keyspaces

          CLI Example:

             salt '*' cassandra.keyspaces

   salt.modules.cassandra.netstats()
          Return netstats info

          CLI Example:

             salt '*' cassandra.netstats

   salt.modules.cassandra.ring()
          Return cassandra ring info

          CLI Example:

             salt '*' cassandra.ring

   salt.modules.cassandra.tpstats()
          Return tpstats info

          CLI Example:

             salt '*' cassandra.tpstats

   salt.modules.cassandra.version()
          Return the cassandra version

          CLI Example:

             salt '*' cassandra.version

   salt.modules.cassandra_cql
   Cassandra Database Module

   New in version 2015.5.0.

   depends
          DataStax      Python     Driver     for     Apache     Cassandra
          https://github.com/datastax/python-driver      pip       install
          cassandra-driver

   referenced by
          Salt's cassandra_cql returner

   configuration
          The  Cassandra cluster members and connection port can either be
          specified in the master or minion config, the minion's pillar or
          be passed to the module.

          Example configuration in the config for a single node:

             cassandra:
               cluster: 192.168.50.10
               port: 9000

          Example configuration in the config for a cluster:

             cassandra:
               cluster:
                 - 192.168.50.10
                 - 192.168.50.11
                 - 192.168.50.12
               port: 9000
               username: cas_admin

          Changed in version 2016.11.0.

          Added support for ssl_options and protocol_version.

          Example configuration with ssl options:

          If ssl_options are present in cassandra config the cassandra_cql
          returner will use SSL.  SSL  isn't  used  if  ssl_options  isn't
          specified.

             cassandra:
               cluster:
                 - 192.168.50.10
                 - 192.168.50.11
                 - 192.168.50.12
               port: 9000
               username: cas_admin

               ssl_options:
                 ca_certs: /etc/ssl/certs/ca-bundle.trust.crt

                 # SSL version should be one from the ssl module
                 # This is an optional parameter
                 ssl_version: PROTOCOL_TLSv1

          Additionally you can also specify the protocol_version to use.

             cassandra:
               cluster:
                 - 192.168.50.10
                 - 192.168.50.11
                 - 192.168.50.12
               port: 9000
               username: cas_admin

               # defaults to 4, if not set
               protocol_version: 3

   salt.modules.cassandra_cql.cql_query(query,        contact_points=None,
   port=None, cql_user=None, cql_pass=None)
          Run a query on a Cassandra cluster and return a dictionary.

          Parameters

                 * query (str) -- The query to execute.

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

                 * params (str) -- The parameters for the query, optional.

          Returns
                 A dictionary from the return values of the query

          Return type
                 list[dict]

   salt.modules.cassandra_cql.cql_query_with_prepare(query,
   statement_name, statement_arguments, async=False, callback_errors=None,
   contact_points=None, port=None, cql_user=None, cql_pass=None)
          Run a query on a Cassandra cluster and return a dictionary.

          This  function  should not be used asynchronously for SELECTs --
          it will not return  anything  and  we  don't  currently  have  a
          mechanism for handling a future that will return results.

          Parameters

                 * query (str) -- The query to execute.

                 * statement_name  (str)  --  Name  to assign the prepared
                   statement in the __context__ dictionary

                 * statement_arguments (list[str]) -- Bind parameters  for
                   the SQL statement

                 * async (bool) -- Run this query in asynchronous mode

                 * callback_errors (Function callable) -- Function to call
                   after query runs if there is an error

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

                 * params (str) -- The parameters for the query, optional.

          Returns
                 A dictionary from the return values of the query

          Return type
                 list[dict]

   salt.modules.cassandra_cql.create_keyspace(keyspace,
   replication_strategy='SimpleStrategy',            replication_factor=1,
   replication_datacenters=None,      contact_points=None,      port=None,
   cql_user=None, cql_pass=None)
          Create a new keyspace in Cassandra.

          Parameters

                 * keyspace (str) -- The keyspace name

                 * replication_strategy (str) -- either SimpleStrategy  or
                   NetworkTopologyStrategy

                 * replication_factor  (int) -- number of replicas of data
                   on    multiple    nodes.    not    used    if     using
                   NetworkTopologyStrategy

                 * replication_datacenters   (str  |  dict[str,  int])  --
                   string or  dict  of  datacenter  names  to  replication
                   factors,   required  if  using  NetworkTopologyStrategy
                   (will be a dict if coming from state file).

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

          Returns
                 The info for the keyspace or False if it does not exist.

          Return type
                 dict

             salt 'minion1' cassandra_cql.create_keyspace keyspace=newkeyspace

             salt 'minion1' cassandra_cql.create_keyspace keyspace=newkeyspace replication_strategy=NetworkTopologyStrategy         replication_datacenters='{"datacenter_1": 3, "datacenter_2": 2}'

   salt.modules.cassandra_cql.create_user(username,              password,
   superuser=False,   contact_points=None,    port=None,    cql_user=None,
   cql_pass=None)
          Create  a  new  cassandra  user  with  credentials and superuser
          status.

          Parameters

                 * username (str) -- The name of the new user.

                 * password (str) -- The password of the new user.

                 * superuser (bool) -- Is the  new  user  going  to  be  a
                   superuser? default: False

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster addresses, can either be a string or a list  of
                   IPs.

                 * cql_user  (str) -- The Cassandra user if authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port  (int)  -- The Cassandra cluster port, defaults to
                   None.

          Returns

          Return type

             salt 'minion1' cassandra_cql.create_user username=joe password=secret

             salt 'minion1' cassandra_cql.create_user username=joe password=secret superuser=True

             salt 'minion1' cassandra_cql.create_user username=joe password=secret superuser=True contact_points=minion1

   salt.modules.cassandra_cql.drop_keyspace(keyspace, contact_points=None,
   port=None, cql_user=None, cql_pass=None)
          Drop a keyspace if it exists in a Cassandra cluster.

          Parameters

                 * keyspace (str) -- The keyspace to drop.

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster addresses, can either be a string or a list  of
                   IPs.

                 * cql_user  (str) -- The Cassandra user if authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port  (int)  -- The Cassandra cluster port, defaults to
                   None.

          Returns
                 The info for the keyspace or False if it does not exist.

          Return type
                 dict

          CLI Example:

             salt 'minion1' cassandra_cql.drop_keyspace keyspace=test

             salt 'minion1' cassandra_cql.drop_keyspace keyspace=test contact_points=minion1

   salt.modules.cassandra_cql.grant_permission(username,    resource=None,
   resource_type='keyspace',     permission=None,     contact_points=None,
   port=None, cql_user=None, cql_pass=None)
          Grant permissions to a user.

          Parameters

                 * username (str)  --  The  name  of  the  user  to  grant
                   permissions to.

                 * resource  (str) -- The resource (keyspace or table), if
                   None, permissions for all resources are granted.

                 * resource_type (str) -- The resource_type  (keyspace  or
                   table), defaults to 'keyspace'.

                 * permission (str) -- A permission name (e.g. select), if
                   None, all permissions are granted.

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

          Returns

          Return type

             salt 'minion1' cassandra_cql.grant_permission

             salt 'minion1' cassandra_cql.grant_permission username=joe resource=test_keyspace permission=select

             salt 'minion1' cassandra_cql.grant_permission username=joe resource=test_table resource_type=table         permission=select contact_points=minion1

   salt.modules.cassandra_cql.info(contact_points=None,         port=None,
   cql_user=None, cql_pass=None)
          Show the Cassandra information for this cluster.

          Parameters

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

          Returns
                 The information for this Cassandra cluster.

          Return type
                 dict

          CLI Example:

             salt 'minion1' cassandra_cql.info

             salt 'minion1' cassandra_cql.info contact_points=minion1

   salt.modules.cassandra_cql.keyspace_exists(keyspace,
   contact_points=None, port=None, cql_user=None, cql_pass=None)
          Check if a keyspace exists in a Cassandra cluster.

          :param keyspace        The keyspace name to  check  for.   :type
          keyspace:       str :param contact_points: The Cassandra cluster
          addresses, can either be a string  or  a  list  of  IPs.   :type
          contact_points:  str  |  list[str]  :param  cql_user:        The
          Cassandra user if authentication is turned on.  :type  cql_user:
          str  :param  cql_pass:        The  Cassandra  user  password  if
          authentication is turned on.  :type  cql_pass:       str  :param
          port:            The  Cassandra  cluster port, defaults to None.
          :type  port:           int :return:               The  info  for
          the   keyspace   or   False  if  it  does  not  exist.   :rtype:
          dict

          CLI Example:

             salt 'minion1' cassandra_cql.keyspace_exists keyspace=system

             salt 'minion1' cassandra_cql.list_keyspaces keyspace=system contact_points=minion1

   salt.modules.cassandra_cql.list_column_families(keyspace=None,
   contact_points=None, port=None, cql_user=None, cql_pass=None)
          List column families in a Cassandra cluster for all keyspaces or
          just the provided one.

          Parameters

                 * keyspace (str) -- The keyspace to  provide  the  column
                   families for, optional.

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster addresses, can either be a string or a list  of
                   IPs.

                 * cql_user  (str) -- The Cassandra user if authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port  (int)  -- The Cassandra cluster port, defaults to
                   None.

          Returns
                 The column families in this Cassandra cluster.

          Return type
                 list[dict]

          CLI Example:

             salt 'minion1' cassandra_cql.list_column_families

             salt 'minion1' cassandra_cql.list_column_families contact_points=minion1

             salt 'minion1' cassandra_cql.list_column_families keyspace=system

   salt.modules.cassandra_cql.list_keyspaces(contact_points=None,
   port=None, cql_user=None, cql_pass=None)
          List keyspaces in a Cassandra cluster.

          Parameters

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster addresses, can either be a string or a list  of
                   IPs.

                 * cql_user  (str) -- The Cassandra user if authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port  (int)  -- The Cassandra cluster port, defaults to
                   None.

          Returns
                 The keyspaces in this Cassandra cluster.

          Return type
                 list[dict]

          CLI Example:

             salt 'minion1' cassandra_cql.list_keyspaces

             salt 'minion1' cassandra_cql.list_keyspaces contact_points=minion1 port=9000

   salt.modules.cassandra_cql.list_permissions(username=None,
   resource=None,        resource_type='keyspace',        permission=None,
   contact_points=None, port=None, cql_user=None, cql_pass=None)
          List permissions.

          Parameters

                 * username  (str)  --  The  name  of  the  user  to  list
                   permissions for.

                 * resource  (str) -- The resource (keyspace or table), if
                   None, permissions for all resources are listed.

                 * resource_type (str) -- The resource_type  (keyspace  or
                   table), defaults to 'keyspace'.

                 * permission (str) -- A permission name (e.g. select), if
                   None, all permissions are listed.

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

          Returns
                 Dictionary of permissions.

          Return type
                 dict

             salt 'minion1' cassandra_cql.list_permissions

             salt 'minion1' cassandra_cql.list_permissions username=joe resource=test_keyspace permission=select

             salt 'minion1' cassandra_cql.list_permissions username=joe resource=test_table resource_type=table         permission=select contact_points=minion1

   salt.modules.cassandra_cql.list_users(contact_points=None,   port=None,
   cql_user=None, cql_pass=None)
          List existing users in this Cassandra cluster.

          Parameters

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

                 * cql_user  (str) -- The Cassandra user if authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

          Returns
                 The list of existing users.

          Return type
                 dict

             salt 'minion1' cassandra_cql.list_users

             salt 'minion1' cassandra_cql.list_users contact_points=minion1

   salt.modules.cassandra_cql.version(contact_points=None,      port=None,
   cql_user=None, cql_pass=None)
          Show the Cassandra version.

          Parameters

                 * contact_points  (str  |  list[str])  --  The  Cassandra
                   cluster  addresses, can either be a string or a list of
                   IPs.

                 * cql_user (str) -- The Cassandra user if  authentication
                   is turned on.

                 * cql_pass  (str)  --  The  Cassandra  user  password  if
                   authentication is turned on.

                 * port (int) -- The Cassandra cluster port,  defaults  to
                   None.

          Returns
                 The version for this Cassandra cluster.

          Return type
                 str

          CLI Example:

             salt 'minion1' cassandra_cql.version

             salt 'minion1' cassandra_cql.version contact_points=minion1

   salt.modules.chassis
   Glue execution module to link to the fx2 proxymodule.

   Depends: iDRAC Remote execution module (salt.modules.dracr)

   For documentation on commands that you can direct to a Dell chassis via
   proxy, look in the documentation for salt.modules.dracr.

   This execution module calls through to a  function  in  the  fx2  proxy
   module  called chconfig.  That function looks up the function passed in
   the cmd parameter in salt.modules.dracr and calls it.

   New in version 2015.8.2.

   salt.modules.chef
   Execute chef in server or solo mode

   salt.modules.chef.client(whyrun=False,  localmode=False,  logfile=None,
   **kwargs)
          Execute  a  chef  client  run and return a dict with the stderr,
          stdout, return code, and pid.

          CLI Example:

             salt '*' chef.client server=https://localhost

          server The chef server URL

          client_key
                 Set the client key file location

          config The configuration file to use

          config-file-jail
                 Directory under which config  files  are  allowed  to  be
                 loaded  (no  client.rb or knife.rb outside this path will
                 be loaded).

          environment
                 Set the Chef Environment on the node

          group  Group to set privilege to

          json-attributes
                 Load attributes from a JSON file or URL

          localmode
                 Point chef-client at local repository if True

          log_level
                 Set the log level (debug, info, warn, error, fatal)

          logfile
                 Set the log file location

          node-name
                 The node name for this client

          override-runlist
                 Replace current run  list  with  specified  items  for  a
                 single run

          pid    Set     the    PID    file    location,    defaults    to
                 /tmp/chef-client.pid

          run-lock-timeout
                 Set maximum duration to wait for another  client  run  to
                 finish, default is indefinitely.

          runlist
                 Permanently replace current run list with specified items

          user   User to set privilege to

          validation_key
                 Set   the   validation   key   file  location,  used  for
                 registering new clients

          whyrun Enable whyrun mode when set to True

   salt.modules.chef.solo(whyrun=False, logfile=None, **kwargs)
          Execute a chef solo run and  return  a  dict  with  the  stderr,
          stdout, return code, and pid.

          CLI Example:

             salt '*' chef.solo override-runlist=test

          config The configuration file to use

          environment
                 Set the Chef Environment on the node

          group  Group to set privilege to

          json-attributes
                 Load attributes from a JSON file or URL

          log_level
                 Set the log level (debug, info, warn, error, fatal)

          logfile
                 Set the log file location

          node-name
                 The node name for this client

          override-runlist
                 Replace  current  run  list  with  specified  items for a
                 single run

          recipe-url
                 Pull down a remote gzipped tarball of recipes  and  untar
                 it to the cookbook cache

          run-lock-timeout
                 Set  maximum  duration  to wait for another client run to
                 finish, default is indefinitely.

          user   User to set privilege to

          whyrun Enable whyrun mode when set to True

   salt.modules.chocolatey
   A dead simple module wrapping calls to the Chocolatey  package  manager
   (http://chocolatey.org)

   New in version 2014.1.0.

   salt.modules.chocolatey.add_source(name,               source_location,
   username=None, password=None)
          Instructs Chocolatey to add a source.

          name   The name of the  source  to  be  added  as  a  chocolatey
                 repository.

          source Location of the source you want to work with.

          username
                 Provide   username   for  chocolatey  sources  that  need
                 authentication credentials.

          password
                 Provide  password  for  chocolatey  sources   that   need
                 authentication credentials.

          CLI Example:

             salt '*' chocolatey.add_source <source name> <source_location>
             salt '*' chocolatey.add_source <source name> <source_location> user=<user> password=<password>

   salt.modules.chocolatey.bootstrap(force=False)
          Download  and  install  the  latest  version  of  the Chocolatey
          package manager via the official bootstrap.

          Chocolatey  requires  Windows  PowerShell  and  the  .NET   v4.0
          runtime.   Depending   on   the   host's   version  of  Windows,
          chocolatey.bootstrap will attempt to ensure these  prerequisites
          are  met by downloading and executing the appropriate installers
          from Microsoft.

          Note that if PowerShell is installed, you may  have  to  restart
          the host machine for Chocolatey to work.

          force  Run  the bootstrap process even if Chocolatey is found in
                 the path.

          CLI Example:

             salt '*' chocolatey.bootstrap
             salt '*' chocolatey.bootstrap force=True

   salt.modules.chocolatey.chocolatey_version()
          Returns the version of Chocolatey installed on the minion.

          CLI Example:

             salt '*' chocolatey.chocolatey_version

   salt.modules.chocolatey.disable_source(name)
          Instructs Chocolatey to disable a source.

          name   Name of the source repository to disable.

          CLI Example:

             salt '*' chocolatey.disable_source <name>

   salt.modules.chocolatey.enable_source(name)
          Instructs Chocolatey to enable a source.

          name   Name of the source repository to enable.

          CLI Example:

             salt '*' chocolatey.enable_source <name>

   salt.modules.chocolatey.install(name,    version=None,     source=None,
   force=False,           pre_versions=False,           install_args=None,
   override_args=False, force_x86=False, package_args=None)
          Instructs Chocolatey to install a package.

          Parameters

                 * name (str) -- The name of the package to be  installed.
                   Only accepts a single argument.

                 * version  (str)  --  Install  a  specific version of the
                   package. Defaults to latest version.

                 * source (str) --

                   Chocolatey repository (directory, share or  remote  URL
                   feed)  the package comes from. Defaults to the official
                   Chocolatey feed.

                   Alternative Sources:

                   * cygwin

                   * python

                   * ruby

                   * webpi

                   * windowsfeatures

                 * force (bool) -- Reinstall the  current  version  of  an
                   existing package.

                 * pre_versions  (bool)  --  Include pre-release packages.
                   Defaults to False.

                 * install_args (str) -- A list of install  arguments  you
                   want  to  pass  to the installation process i.e product
                   key or feature list

                 * override_args (bool) -- Set to  true  if  you  want  to
                   override the original install arguments (for the native
                   installer) in the package and use your own.  When  this
                   is  set  to  False install_args will be appended to the
                   end of the default arguments

                 * force_x86 (str) -- Force x86 (32bit) installation on 64
                   bit systems. Defaults to false.

                 * package_args  (str)  -- A list of arguments you want to
                   pass to the package

          Returns
                 The output of the chocolatey command

          Return type
                 str

          CLI Example:

             salt '*' chocolatey.install <package name>
             salt '*' chocolatey.install <package name> version=<package version>
             salt '*' chocolatey.install <package name> install_args=<args> override_args=True

   salt.modules.chocolatey.install_cygwin(name,         install_args=None,
   override_args=False)
          Instructs Chocolatey to install a package via Cygwin.

          name   The  name  of the package to be installed. Only accepts a
                 single argument.

          install_args
                 A list of install arguments  you  want  to  pass  to  the
                 installation process i.e product key or feature list

          override_args

                 Set  to true if you want to override the original install
                 arguments (for the native installer)
                        in the package and use your own. When this is  set
                        to  False install_args will be appended to the end
                        of the default arguments

          CLI Example:

             salt '*' chocolatey.install_cygwin <package name>
             salt '*' chocolatey.install_cygwin <package name> install_args=<args> override_args=True

   salt.modules.chocolatey.install_gem(name,                 version=None,
   install_args=None, override_args=False)
          Instructs Chocolatey to install a package via Ruby's Gems.

          name   The  name  of the package to be installed. Only accepts a
                 single argument.

          version
                 Install a specific version of the  package.  Defaults  to
                 latest version available.

          install_args
                 A  list  of  install  arguments  you  want to pass to the
                 installation process i.e product key or feature list

          override_args

                 Set to true if you want to override the original  install
                 arguments (for the native installer)
                        in  the package and use your own. When this is set
                        to False install_args will be appended to the  end
                        of the default arguments

          CLI Example:

             salt '*' chocolatey.install_gem <package name>
             salt '*' chocolatey.install_gem <package name> version=<package version>
             salt '*' chocolatey.install_gem <package name> install_args=<args> override_args=True

   salt.modules.chocolatey.install_missing(name,             version=None,
   source=None)
          Instructs Chocolatey to install a package if it doesn't  already
          exist.

          Changed  in  version  2014.7.0:  If the minion has Chocolatey >=
          0.9.8.24  installed,  this  function  calls   chocolatey.install
          instead,  as installmissing is deprecated as of that version and
          will be removed in Chocolatey 1.0.

          name   The name of the package to be installed. Only  accepts  a
                 single argument.

          version
                 Install  a  specific  version of the package. Defaults to
                 latest version available.

          source Chocolatey repository (directory,  share  or  remote  URL
                 feed)  the  package  comes from. Defaults to the official
                 Chocolatey feed.

          CLI Example:

             salt '*' chocolatey.install_missing <package name>
             salt '*' chocolatey.install_missing <package name> version=<package version>

   salt.modules.chocolatey.install_python(name,              version=None,
   install_args=None, override_args=False)
          Instructs   Chocolatey   to   install  a  package  via  Python's
          easy_install.

          name   The name of the package to be installed. Only  accepts  a
                 single argument.

          version
                 Install  a  specific  version of the package. Defaults to
                 latest version available.

          install_args
                 A list of install arguments  you  want  to  pass  to  the
                 installation process i.e product key or feature list

          override_args

                 Set  to true if you want to override the original install
                 arguments (for the native installer)
                        in the package and use your own. When this is  set
                        to  False install_args will be appended to the end
                        of the default arguments

          CLI Example:

             salt '*' chocolatey.install_python <package name>
             salt '*' chocolatey.install_python <package name> version=<package version>
             salt '*' chocolatey.install_python <package name> install_args=<args> override_args=True

   salt.modules.chocolatey.install_webpi(name,          install_args=None,
   override_args=False)
          Instructs  Chocolatey to install a package via the Microsoft Web
          PI service.

          name   The name of the package to be installed. Only  accepts  a
                 single argument.

          install_args
                 A  list  of  install  arguments  you  want to pass to the
                 installation process i.e product key or feature list

          override_args

                 Set to true if you want to override the original  install
                 arguments (for the native installer)
                        in  the package and use your own. When this is set
                        to False install_args will be appended to the  end
                        of the default arguments

          CLI Example:

             salt '*' chocolatey.install_webpi <package name>
             salt '*' chocolatey.install_webpi <package name> install_args=<args> override_args=True

   salt.modules.chocolatey.install_windowsfeatures(name)
          Instructs  Chocolatey  to  install  a  Windows  Feature  via the
          Deployment Image Servicing and Management tool.

          name   The name of the feature to be installed. Only  accepts  a
                 single argument.

          CLI Example:

             salt '*' chocolatey.install_windowsfeatures <package name>

   salt.modules.chocolatey.list(narrow=None,           all_versions=False,
   pre_versions=False, source=None, local_only=False)
          Instructs Chocolatey to pull  a  vague  package  list  from  the
          repository.

          narrow Term  used  to  narrow  down  results.  Searches  against
                 name/description/tag.

          all_versions
                 Display  all  available  package  versions  in   results.
                 Defaults to False.

          pre_versions
                 Display  pre-release  packages  in  results.  Defaults to
                 False.

          source Chocolatey repository (directory,  share  or  remote  URL
                 feed)  the  package  comes from. Defaults to the official
                 Chocolatey feed.

          local_only
                 Display packages only installed locally

          CLI Example:

             salt '*' chocolatey.list <narrow>
             salt '*' chocolatey.list <narrow> all_versions=True

   salt.modules.chocolatey.list_webpi()
          Instructs Chocolatey to  pull  a  full  package  list  from  the
          Microsoft Web PI repository.

          Returns
                 List of webpi packages

          Return type
                 str

          CLI Example:

             salt '*' chocolatey.list_webpi

   salt.modules.chocolatey.list_windowsfeatures()
          Instructs  Chocolatey  to  pull  a  full  package  list from the
          Windows Features list, via the Deployment  Image  Servicing  and
          Management tool.

          Returns
                 List of Windows Features

          Return type
                 str

          CLI Example:

             salt '*' chocolatey.list_windowsfeatures

   salt.modules.chocolatey.uninstall(name,                   version=None,
   uninstall_args=None, override_args=False)
          Instructs Chocolatey to uninstall a package.

          name   The name of the package to be uninstalled. Only accepts a
                 single argument.

          version
                 Uninstalls a specific version of the package. Defaults to
                 latest version installed.

          uninstall_args
                 A list of uninstall arguments you want  to  pass  to  the
                 uninstallation process i.e product key or feature list

          override_args

                 Set  to  true  if  you  want  to  override  the  original
                 uninstall arguments (for the native uninstaller)
                        in the package and use your own. When this is  set
                        to  False  uninstall_args  will be appended to the
                        end of the default arguments

          CLI Example:

             salt '*' chocolatey.uninstall <package name>
             salt '*' chocolatey.uninstall <package name> version=<package version>
             salt '*' chocolatey.uninstall <package name> version=<package version> uninstall_args=<args> override_args=True

   salt.modules.chocolatey.update(name, source=None, pre_versions=False)
          Instructs Chocolatey to update packages on the system.

          name   The name of the package to update,  or  "all"  to  update
                 everything installed on the system.

          source Chocolatey  repository  (directory,  share  or remote URL
                 feed) the package comes from. Defaults  to  the  official
                 Chocolatey feed.

          pre_versions
                 Include  pre-release  packages in comparison. Defaults to
                 False.

          CLI Example:

             salt "*" chocolatey.update all
             salt "*" chocolatey.update <package name> pre_versions=True

   salt.modules.chocolatey.upgrade(name,    version=None,     source=None,
   force=False,           pre_versions=False,           install_args=None,
   override_args=False, force_x86=False, package_args=None)
          New in version 2016.3.4.

          Instructs Chocolatey to upgrade packages on the system.  (update
          is being deprecated)

          Parameters

                 * name  (str)  --  The  name of the package to update, or
                   "all" to update everything installed on the system.

                 * version (str) -- Install  a  specific  version  of  the
                   package. Defaults to latest version.

                 * source (str) -- Chocolatey repository (directory, share
                   or remote URL feed) the package comes from. Defaults to
                   the official Chocolatey feed.

                 * force  (bool)  --  Reinstall  the  same version already
                   installed

                 * pre_versions (bool) -- Include pre-release packages  in
                   comparison. Defaults to False.

                 * install_args  (str)  -- A list of install arguments you
                   want to pass to the installation  process  i.e  product
                   key or feature list

                 * override_args  (str)  --  Set  to  true  if you want to
                   override the original install arguments (for the native
                   installer)  in  the package and use your own. When this
                   is set to False install_args will be  appended  to  the
                   end of the default arguments

                 * force_x86  --  Force x86 (32bit) installation on 64 bit
                   systems. Defaults to false.

                 * package_args -- A list of arguments you want to pass to
                   the package

          Returns
                 Results of the chocolatey command

          Return type
                 str

          CLI Example:

             salt "*" chocolatey.upgrade all
             salt "*" chocolatey.upgrade <package name> pre_versions=True

   salt.modules.chocolatey.version(name,  check_remote=False, source=None,
   pre_versions=False)
          Instructs Chocolatey to check an installed package version,  and
          optionally compare it to one available from a remote feed.

          name   The name of the package to check.

          check_remote
                 Get  the  version  number  of the latest package from the
                 remote feed.  Defaults to False.

          source Chocolatey repository (directory,  share  or  remote  URL
                 feed)  the  package  comes from. Defaults to the official
                 Chocolatey feed.

          pre_versions
                 Include pre-release packages in comparison.  Defaults  to
                 False.

          CLI Example:

             salt "*" chocolatey.version <package name>
             salt "*" chocolatey.version <package name> check_remote=True

   salt.modules.chronos module
   Module providing a simple management interface to a chronos cluster.

   Currently this only works when run through a proxy minion.

   New in version 2015.8.2.

   salt.modules.chronos.has_job(name)
          Return whether the given job is currently configured.

          CLI Example:

             salt chronos-minion-id chronos.has_job my-job

   salt.modules.chronos.job(name)
          Return the current server configuration for the specified job.

          CLI Example:

             salt chronos-minion-id chronos.job my-job

   salt.modules.chronos.jobs()
          Return a list of the currently installed job names.

          CLI Example:

             salt chronos-minion-id chronos.jobs

   salt.modules.chronos.rm_job(name)
          Remove the specified job from the server.

          CLI Example:

             salt chronos-minion-id chronos.rm_job my-job

   salt.modules.chronos.update_job(name, config)
          Update the specified job with the given configuration.

          CLI Example:

             salt chronos-minion-id chronos.update_job my-job '<config yaml>'

   salt.modules.cloud
   Salt-specific interface for calling Salt Cloud directly

   salt.modules.cloud.action(fun=None,      cloudmap=None,     names=None,
   provider=None, instance=None, **kwargs)
          Execute a single action on the given provider/instance

          CLI Example:

             salt '*' cloud.action start instance=myinstance
             salt '*' cloud.action stop instance=myinstance
             salt '*' cloud.action show_image provider=my-ec2-config image=ami-1624987f

   salt.modules.cloud.create(provider, names, opts=None, **kwargs)
          Create an instance using Salt Cloud

          CLI Example:

             salt minionname cloud.create my-ec2-config myinstance image=ami-1624987f size='t1.micro' ssh_username=ec2-user securitygroup=default delvol_on_destroy=True

   salt.modules.cloud.destroy(names)
          Destroy the named VM(s)

          CLI Example:

             salt '*' cloud.destroy myinstance

   salt.modules.cloud.full_query(query_type='list_nodes_full')
          List all available cloud provider data

          CLI Example:

             salt '*' cloud.full_query

   salt.modules.cloud.get_instance(name, provider=None)
          Return details on an instance.

          Similar to the cloud action show_instance but returns  only  the
          instance details.

          CLI Example:

             salt '*' cloud.get_instance myinstance

          SLS Example:

             {{ salt['cloud.get_instance']('myinstance')['mac_address'] }}

   salt.modules.cloud.has_instance(name, provider=None)
          Return true if the instance is found on a provider

          CLI Example:

             salt '*' cloud.has_instance myinstance

   salt.modules.cloud.list_images(provider='all')
          List cloud provider images for the given providers

          CLI Example:

             salt '*' cloud.list_images my-gce-config

   salt.modules.cloud.list_locations(provider='all')
          List cloud provider locations for the given providers

          CLI Example:

             salt '*' cloud.list_locations my-gce-config

   salt.modules.cloud.list_sizes(provider='all')
          List cloud provider sizes for the given providers

          CLI Example:

             salt '*' cloud.list_sizes my-gce-config

   salt.modules.cloud.network_create(provider, names, **kwargs)
          Create private network

          CLI Example:

             salt minionname cloud.network_create my-nova names=['salt'] cidr='192.168.100.0/24'

   salt.modules.cloud.network_list(provider)
          List private networks

          CLI Example:

             salt minionname cloud.network_list my-nova

   salt.modules.cloud.profile(profile,      names,      vm_overrides=None,
   opts=None, **kwargs)
          Spin up an instance using Salt Cloud

          CLI Example:

             salt '*' cloud.profile my-gce-config myinstance

   salt.modules.cloud.query(query_type='list_nodes')
          List cloud provider data for all providers

          CLI Examples:

             salt '*' cloud.query
             salt '*' cloud.query list_nodes_full
             salt '*' cloud.query list_nodes_select

   salt.modules.cloud.select_query(query_type='list_nodes_select')
          List selected nodes

          CLI Example:

             salt '*' cloud.select_query

   salt.modules.cloud.virtual_interface_create(provider, names, **kwargs)
          Attach private interfaces to a server

          CLI Example:

             salt minionname cloud.virtual_interface_create my-nova names=['salt-master'] net_name='salt'

   salt.modules.cloud.virtual_interface_list(provider, names, **kwargs)
          List virtual interfaces on a server

          CLI Example:

             salt minionname cloud.virtual_interface_list my-nova names=['salt-master']

   salt.modules.cloud.volume_attach(provider, names, **kwargs)
          Attach volume to a server

          CLI Example:

             salt minionname cloud.volume_attach my-nova myblock server_name=myserver device='/dev/xvdf'

   salt.modules.cloud.volume_create(provider, names, **kwargs)
          Create volume

          CLI Example:

             salt minionname cloud.volume_create my-nova myblock size=100 voltype=SSD

   salt.modules.cloud.volume_delete(provider, names, **kwargs)
          Delete volume

          CLI Example:

             salt minionname cloud.volume_delete my-nova myblock

   salt.modules.cloud.volume_detach(provider, names, **kwargs)
          Detach volume from a server

          CLI Example:

             salt minionname cloud.volume_detach my-nova myblock server_name=myserver

   salt.modules.cloud.volume_list(provider)
          List block storage volumes

          CLI Example:

             salt minionname cloud.volume_list my-nova

   salt.modules.cmdmod
   A module for shelling out.

   Keep in mind that this module is insecure, in that it can give whomever
   has access to the master root execution access to all salt minions.

   salt.modules.cmdmod.exec_code(lang, code, cwd=None)
          Pass  in  two strings, the first naming the executable language,
          aka - python2, python3, ruby, perl, lua, etc. the second  string
          containing  the  code  you  wish  to execute. The stdout will be
          returned.

          CLI Example:

             salt '*' cmd.exec_code ruby 'puts "cheese"'

   salt.modules.cmdmod.exec_code_all(lang, code, cwd=None)
          Pass in two strings, the first naming the  executable  language,
          aka  - python2, python3, ruby, perl, lua, etc. the second string
          containing the code you  wish  to  execute.  All  cmd  artifacts
          (stdout, stderr, retcode, pid) will be returned.

          CLI Example:

             salt '*' cmd.exec_code_all ruby 'puts "cheese"'

   salt.modules.cmdmod.has_exec(cmd)
          Returns true if the executable is available on the minion, false
          otherwise

          CLI Example:

             salt '*' cmd.has_exec cat

   salt.modules.cmdmod.powershell(cmd, cwd=None,  stdin=None,  runas=None,
   shell='/bin/sh', env=None, clean_env=False, template=None, rstrip=True,
   umask=None,   output_loglevel='debug',    quiet=False,    timeout=None,
   reset_system_locale=True,     ignore_retcode=False,     saltenv='base',
   use_vt=False, password=None, depth=None, encode_cmd=False, **kwargs)
          Execute the passed PowerShell command and return the output as a
          dictionary.

          Other cmd.* functions return the raw text output of the command.
          This function appends | ConvertTo-JSON to the command  and  then
          parses  the  JSON  into a Python dictionary. If you want the raw
          textual result of your PowerShell command you should use cmd.run
          with the shell=powershell option.

          For example:

             salt '*' cmd.run '$PSVersionTable.CLRVersion' shell=powershell
             salt '*' cmd.run 'Get-NetTCPConnection' shell=powershell

          New in version 2016.3.0.

          WARNING:
             This  passes  the cmd argument directly to PowerShell without
             any further processing! Be  absolutely  sure  that  you  have
             properly sanitized the command passed to this function and do
             not use untrusted inputs.

          Note that env  represents  the  environment  variables  for  the
          command,  and  should  be  formatted as a dict, or a YAML string
          which resolves to a dict.

          In addition to  the  normal  cmd.run  parameters,  this  command
          offers  the  depth parameter to change the Windows default depth
          for the ConvertTo-JSON powershell command. The  Windows  default
          is 2. If you need more depth, set that here.

          NOTE:
             For  some commands, setting the depth to a value greater than
             4 greatly increases the time it  takes  for  the  command  to
             return and in many cases returns useless data.

          Parameters

                 * cmd (str) -- The powershell command to run.

                 * cwd  (str)  -- The current working directory to execute
                   the command in

                 * stdin (str) --  A  string  of  standard  input  can  be
                   specified  for  the  command  to be run using the stdin
                   parameter. This can be useful in cases where  sensitive
                   information must be read from standard input.:

                 * runas  (str)  -- User to run script as. If running on a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows only.  Required  when  specifying  runas.  This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell  (str) -- Shell to execute under. Defaults to the
                   system default shell.

                 * python_shell (bool) -- If False, let python handle  the
                   positional   arguments.   Set  to  True  to  use  shell
                   features, such as pipes or redirection

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * rstrip  (bool)  --  Strip all whitespace off the end of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command output more interactively to  the  console  and
                   the logs. This is experimental.

                 * reset_system_locale (bool) -- Resets the system locale

                 * ignore_retcode (bool) -- Ignore the return code

                 * saltenv  (str)  -- The salt environment to use. Default
                   is 'base'

                 * depth (int) --

                   The  number  of  levels  of  contained  objects  to  be
                   included.   Default is 2. Values greater than 4 seem to
                   greatly increase the time it takes for the  command  to
                   complete for some commands. eg: dir

                   New in version 2016.3.4.

                 * encode_cmd   (bool)   --   Encode  the  command  before
                   executing. Use in cases where characters may be dropped
                   or  incorrectly  converted  when  executed.  Default is
                   False.

          Returns

                 dict   A dictionary of data returned  by  the  powershell
                        command.

          CLI Example:

             salt '*' cmd.powershell "$PSVersionTable.CLRVersion"

   salt.modules.cmdmod.retcode(cmd,   cwd=None,   stdin=None,  runas=None,
   shell='/bin/sh',    python_shell=None,    env=None,    clean_env=False,
   template=None,  umask=None, output_loglevel='debug', log_callback=None,
   timeout=None,      reset_system_locale=True,      ignore_retcode=False,
   saltenv='base', use_vt=False, password=None, **kwargs)
          Execute a shell command and return the command's return code.

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd  (str)  -- The current working directory to execute
                   the command in, defaults to /root

                 * stdin (str) --  A  string  of  standard  input  can  be
                   specified  for  the  command  to be run using the stdin
                   parameter. This can be useful in cases where  sensitive
                   information must be read from standard input.:

                 * runas  (str)  -- User to run script as. If running on a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows only.  Required  when  specifying  runas.  This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell  (str) -- Shell to execute under. Defaults to the
                   system default shell.

                 * python_shell (bool) -- If False, let python handle  the
                   positional   arguments.   Set  to  True  to  use  shell
                   features, such as pipes or redirection

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * rstrip  (bool)  --  Strip all whitespace off the end of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command output more interactively to  the  console  and
                   the logs. This is experimental.

          NOTE:
             env represents the environment variables for the command, and
             should be formatted  as  a  dict,  or  a  YAML  string  which
             resolves to a dict.

          Return type
                 int

          Return type
                 None

          Returns
                 Return Code as an int or None if there was an exception.

          CLI Example:

             salt '*' cmd.retcode "file /bin/bash"

          The  template  arg  can  be  set to 'jinja' or another supported
          template  engine  to  render  the   command   arguments   before
          execution.  For example:

             salt '*' cmd.retcode template=jinja "file {{grains.pythonpath[0]}}/python"

          A  string  of standard input can be specified for the command to
          be run using the stdin parameter. This can be  useful  in  cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.retcode "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.run(cmd,    cwd=None,    stdin=None,    runas=None,
   shell='/bin/sh',    python_shell=None,    env=None,    clean_env=False,
   template=None,    rstrip=True,   umask=None,   output_loglevel='debug',
   log_callback=None,       timeout=None,        reset_system_locale=True,
   ignore_retcode=False,     saltenv='base',    use_vt=False,    bg=False,
   password=None, encoded_cmd=False, **kwargs)
          Execute the passed command and return the output as a string

          Note that env  represents  the  environment  variables  for  the
          command,  and  should  be  formatted as a dict, or a YAML string
          which resolves to a dict.

          Parameters

                 * cmd (str) -- The command to run. ex: ls -lart /home

                 * cwd (str) -- The current working directory  to  execute
                   the command in, defaults to /root (C:\ in windows)

                 * stdin  (str)  --  A  string  of  standard  input can be
                   specified for the command to be  run  using  the  stdin
                   parameter.  This can be useful in cases where sensitive
                   information must be read from standard input.:

                 * runas (str) -- User to run script as. If running  on  a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows  only.  Required  when  specifying  runas. This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell (str) -- Shell to execute under. Defaults to  the
                   system default shell.

                 * python_shell  (bool) -- If False, let python handle the
                   positional  arguments.  Set  to  True  to   use   shell
                   features, such as pipes or redirection

                 * bg  (bool) -- If True, run command in background and do
                   not await or deliver it's results

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * rstrip  (bool)  --  Strip all whitespace off the end of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command output more interactively to  the  console  and
                   the logs. This is experimental.

                 * encoded_cmd  (bool)  -- Specify if the supplied command
                   is encoded.  Only applies to shell 'powershell'.

          WARNING:
             This function does  not  process  commands  through  a  shell
             unless  the python_shell flag is set to True. This means that
             any shell-specific functionality such as 'echo' or the use of
             pipes,  redirection  or  &&,  should  either  be  migrated to
             cmd.shell or have the python_shell=True flag set here.

             The use of python_shell=True means that the shell will accept
             _any_  input including potentially malicious commands such as
             'good_command;rm -rf /'.  Be absolutely certain that you have
             sanitized your input prior to using python_shell=True

          CLI Example:

             salt '*' cmd.run "ls -l | awk '/foo/{print \\$2}'"

          The  template  arg  can  be  set to 'jinja' or another supported
          template  engine  to  render  the   command   arguments   before
          execution.  For example:

             salt '*' cmd.run template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \\$2}'"

          Specify an alternate shell with the shell parameter:

             salt '*' cmd.run "Get-ChildItem C:\\ " shell='powershell'

          A  string  of standard input can be specified for the command to
          be run using the stdin parameter. This can be  useful  in  cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.run "grep f" stdin='one\\ntwo\\nthree\\nfour\\nfive\\n'

          If an equal sign (=) appears in an argument to a Salt command it
          is interpreted as a keyword argument in the format key=val. That
          processing  can  be  bypassed  in  order  to  pass an equal sign
          through to the remote shell command by manually  specifying  the
          kwarg:

             salt '*' cmd.run cmd='sed -e s/=/:/g'

   salt.modules.cmdmod.run_all(cmd,   cwd=None,   stdin=None,  runas=None,
   shell='/bin/sh',    python_shell=None,    env=None,    clean_env=False,
   template=None,    rstrip=True,   umask=None,   output_loglevel='debug',
   log_callback=None,       timeout=None,        reset_system_locale=True,
   ignore_retcode=False,           saltenv='base',           use_vt=False,
   redirect_stderr=False, password=None, **kwargs)
          Execute the passed command and return a dict of return data

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd (str) -- The current working directory  to  execute
                   the command in, defaults to /root

                 * stdin  (str)  --  A  string  of  standard  input can be
                   specified for the command to be  run  using  the  stdin
                   parameter.  This can be useful in cases where sensitive
                   information must be read from standard input.:

                 * runas (str) -- User to run script as. If running  on  a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows  only.  Required  when  specifying  runas. This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell (str) -- Shell to execute under. Defaults to  the
                   system default shell.

                 * python_shell  (bool) -- If False, let python handle the
                   positional  arguments.  Set  to  True  to   use   shell
                   features, such as pipes or redirection

                 * env (list) --

                   A  list  of  environment  variables  to be set prior to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The above illustrates a common  PyYAML  pitfall,
                          that  yes,  no, on, off, true, and false are all
                          loaded as boolean True  and  False  values,  and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings. More info on this  (and  other)  PyYAML
                          idiosyncrasies can be found here.

                      Variables  as  values are not evaluated. So $PATH in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One can still use the existing $PATH by using a  bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env  (bool)  --  Attempt  to  clean out all other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template  (str)  -- If this setting is applied then the
                   named templating engine will  be  used  to  render  the
                   downloaded  file.  Currently jinja, mako, and wempy are
                   supported

                 * rstrip (bool) -- Strip all whitespace off  the  end  of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel (str) -- Control the loglevel at  which
                   the  output  from  the command is logged. Note that the
                   command being  run  will  still  be  logged  (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout  (int) -- A timeout in seconds for the executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command  output  more  interactively to the console and
                   the logs. This is experimental.

          NOTE:
             env represents the environment variables for the command, and
             should  be  formatted  as  a  dict,  or  a  YAML string which
             resolves to a dict.

          redirect_stderr
                 False If set to True, then stderr will be  redirected  to
                 stdout.  This  is  helpful for cases where obtaining both
                 the retcode and output is desired, but it is not  desired
                 to have the output separated into both stdout and stderr.

                 New in version 2015.8.2.

          CLI Example:

             salt '*' cmd.run_all "ls -l | awk '/foo/{print \$2}'"

          The  template  arg  can  be  set to 'jinja' or another supported
          template  engine  to  render  the   command   arguments   before
          execution.  For example:

             salt '*' cmd.run_all template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \$2}'"

          A  string  of standard input can be specified for the command to
          be run using the stdin parameter. This can be  useful  in  cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.run_all "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.run_bg(cmd,  cwd=None, runas=None, shell='/bin/sh',
   python_shell=None,    env=None,     clean_env=False,     template=None,
   umask=None,  timeout=None,  output_loglevel='debug', log_callback=None,
   reset_system_locale=True,     ignore_retcode=False,     saltenv='base',
   password=None, **kwargs)
          Execute the passed command in the background and return it's PID

          Note  that  env  represents  the  environment  variables for the
          command, and should be formatted as a dict,  or  a  YAML  string
          which resolves to a dict.

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd  (str)  -- The current working directory to execute
                   the command in, defaults to /root (
                   `
                   C:` in windows)

                 * output_loglevel (str) -- Control the loglevel at  which
                   the  output  from  the command is logged. Note that the
                   command being  run  will  still  be  logged  (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * runas  (str)  -- User to run script as. If running on a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows only.  Required  when  specifying  runas.  This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell  (str) -- Shell to execute under. Defaults to the
                   system default shell.

                 * python_shell (bool) -- If False, let python handle  the
                   positional   arguments.   Set  to  True  to  use  shell
                   features, such as pipes or redirection

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

          WARNING:
             This  function  does  not  process  commands  through a shell
             unless the python_shell flag is set to True. This means  that
             any shell-specific functionality such as 'echo' or the use of
             pipes, redirection  or  &&,  should  either  be  migrated  to
             cmd.shell or have the python_shell=True flag set here.

             The use of python_shell=True means that the shell will accept
             _any_ input including potentially malicious commands such  as
             'good_command;rm -rf /'.  Be absolutely certain that you have
             sanitized your input prior to using python_shell=True

          CLI Example:

             salt '*' cmd.run_bg "fstrim-all"

          The template arg can be set  to  'jinja'  or  another  supported
          template   engine   to   render  the  command  arguments  before
          execution.  For example:

             salt '*' cmd.run_bg template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \\$2}'"

          Specify an alternate shell with the shell parameter:

             salt '*' cmd.run_bg "Get-ChildItem C:\\ " shell='powershell'

          If an equal sign (=) appears in an argument to a Salt command it
          is interpreted as a keyword argument in the format key=val. That
          processing can be bypassed  in  order  to  pass  an  equal  sign
          through  to  the remote shell command by manually specifying the
          kwarg:

             salt '*' cmd.run_bg cmd='ls -lR / | sed -e s/=/:/g > /tmp/dontwait'

   salt.modules.cmdmod.run_chroot(root,   cmd,    cwd=None,    stdin=None,
   runas=None,      shell='/bin/sh',      python_shell=True,     env=None,
   clean_env=False,      template=None,      rstrip=True,      umask=None,
   output_loglevel='quiet',  log_callback=None, quiet=False, timeout=None,
   reset_system_locale=True,     ignore_retcode=False,     saltenv='base',
   use_vt=False, bg=False, **kwargs)
          New in version 2014.7.0.

          This function runs cmd.run_all wrapped within a chroot, with dev
          and proc mounted in the chroot

          root   Path to the root of the jail to use.

          cmd    The command to run. ex: 'ls -lart /home'

          cwd    The current working directory to execute the command  in,
                 defaults to /root

          stdin  A  string  of  standard  input  can  be specified for the
                 command to be run using the stdin parameter. This can  be
                 useful  in cases where sensitive information must be read
                 from standard input.:

          runas  User to run script as.

          shell  Shell to execute under. Defaults to  the  system  default
                 shell.

          python_shell
                 If False, let python handle the positional arguments. Set
                 to  True  to  use  shell  features,  such  as  pipes   or
                 redirection

          env
                    A  list  of  environment  variables to be set prior to
                    execution.  Example:

                        salt://scripts/foo.sh:
                          cmd.script:
                            - env:
                              - BATCH: 'yes'

                    WARNING:
                        The above illustrates  a  common  PyYAML  pitfall,
                        that  yes,  no,  on,  off, true, and false are all
                        loaded as boolean True and False values, and  must
                        be  enclosed in quotes to be used as strings. More
                        info on this (and other) PyYAML idiosyncrasies can
                        be found here.

                    Variables as values are not evaluated. So $PATH in the
                    following example is a literal '$PATH':

                        salt://scripts/bar.sh:
                          cmd.script:
                            - env: "PATH=/some/path:$PATH"

                    One can still use the existing $PATH by using a bit of
                    Jinja:

                        {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                        mycommand:
                          cmd.run:
                            - name: ls -l /
                            - env:
                              - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 clean_env:
                        Attempt  to  clean out all other shell environment
                        variables and set only those provided in the 'env'
                        argument to this function.

          template
                 If  this  setting  is  applied  then the named templating
                 engine will  be  used  to  render  the  downloaded  file.
                 Currently jinja, mako, and wempy are supported

          rstrip Strip  all  whitespace off the end of output before it is
                 returned.

          umask  The umask (in octal) to use when running the command.

          output_loglevel
                 Control the loglevel at which the output from the command
                 is logged.  Note that the command being run will still be
                 logged (loglevel: DEBUG) regardless, unless quiet is used
                 for this value.

          timeout
                 A timeout in seconds for the executed process to return.

          use_vt Use  VT  utils  (saltstack)  to stream the command output
                 more interactively to the console and the logs.  This  is
                 experimental.

          CLI Example:

             salt '*' cmd.run_chroot /var/lib/lxc/container_name/rootfs 'sh /tmp/bootstrap.sh'

   salt.modules.cmdmod.run_stderr(cmd,  cwd=None,  stdin=None, runas=None,
   shell='/bin/sh',    python_shell=None,    env=None,    clean_env=False,
   template=None,    rstrip=True,   umask=None,   output_loglevel='debug',
   log_callback=None,       timeout=None,        reset_system_locale=True,
   ignore_retcode=False,   saltenv='base',   use_vt=False,  password=None,
   **kwargs)
          Execute a command and only return the standard error

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd (str) -- The current working directory  to  execute
                   the command in, defaults to /root

                 * stdin  (str)  --  A  string  of  standard  input can be
                   specified for the command to be  run  using  the  stdin
                   parameter.  This can be useful in cases where sensitive
                   information must be read from standard input.:

                 * runas (str) -- User to run script as. If running  on  a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows  only.  Required  when  specifying  runas. This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell (str) -- Shell to execute under. Defaults to  the
                   system default shell.

                 * python_shell  (bool) -- If False, let python handle the
                   positional  arguments.  Set  to  True  to   use   shell
                   features, such as pipes or redirection

                 * env (list) --

                   A  list  of  environment  variables  to be set prior to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The above illustrates a common  PyYAML  pitfall,
                          that  yes,  no, on, off, true, and false are all
                          loaded as boolean True  and  False  values,  and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings. More info on this  (and  other)  PyYAML
                          idiosyncrasies can be found here.

                      Variables  as  values are not evaluated. So $PATH in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One can still use the existing $PATH by using a  bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env  (bool)  --  Attempt  to  clean out all other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template  (str)  -- If this setting is applied then the
                   named templating engine will  be  used  to  render  the
                   downloaded  file.  Currently jinja, mako, and wempy are
                   supported

                 * rstrip (bool) -- Strip all whitespace off  the  end  of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel (str) -- Control the loglevel at  which
                   the  output  from  the command is logged. Note that the
                   command being  run  will  still  be  logged  (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout  (int) -- A timeout in seconds for the executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command  output  more  interactively to the console and
                   the logs. This is experimental.

          NOTE:
             env represents the environment variables for the command, and
             should  be  formatted  as  a  dict,  or  a  YAML string which
             resolves to a dict.

          CLI Example:

             salt '*' cmd.run_stderr "ls -l | awk '/foo/{print \$2}'"

          The template arg can be set  to  'jinja'  or  another  supported
          template   engine   to   render  the  command  arguments  before
          execution.  For example:

             salt '*' cmd.run_stderr template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \$2}'"

          A string of standard input can be specified for the  command  to
          be  run  using  the stdin parameter. This can be useful in cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.run_stderr "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.run_stdout(cmd, cwd=None,  stdin=None,  runas=None,
   shell='/bin/sh',    python_shell=None,    env=None,    clean_env=False,
   template=None,   rstrip=True,   umask=None,    output_loglevel='debug',
   log_callback=None,        timeout=None,       reset_system_locale=True,
   ignore_retcode=False,  saltenv='base',   use_vt=False,   password=None,
   **kwargs)
          Execute a command, and only return the standard out

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd  (str)  -- The current working directory to execute
                   the command in, defaults to /root

                 * stdin (str) --  A  string  of  standard  input  can  be
                   specified  for  the  command  to be run using the stdin
                   parameter. This can be useful in cases where  sensitive
                   information must be read from standard input.:

                 * runas  (str)  -- User to run script as. If running on a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows only.  Required  when  specifying  runas.  This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell  (str) -- Shell to execute under. Defaults to the
                   system default shell.

                 * python_shell (bool) -- If False, let python handle  the
                   positional   arguments.   Set  to  True  to  use  shell
                   features, such as pipes or redirection

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * rstrip  (bool)  --  Strip all whitespace off the end of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command output more interactively to  the  console  and
                   the logs. This is experimental.

          NOTE:
             env represents the environment variables for the command, and
             should be formatted  as  a  dict,  or  a  YAML  string  which
             resolves to a dict.

          CLI Example:

             salt '*' cmd.run_stdout "ls -l | awk '/foo/{print \$2}'"

          The  template  arg  can  be  set to 'jinja' or another supported
          template  engine  to  render  the   command   arguments   before
          execution.  For example:

             salt '*' cmd.run_stdout template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \$2}'"

          A  string  of standard input can be specified for the command to
          be run using the stdin parameter. This can be  useful  in  cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.run_stdout "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.script(source,   args=None,  cwd=None,  stdin=None,
   runas=None,     shell='/bin/sh',      python_shell=None,      env=None,
   template=None,  umask=None, output_loglevel='debug', log_callback=None,
   quiet=False,  timeout=None,  reset_system_locale=True,  saltenv='base',
   use_vt=False, bg=False, password=None, **kwargs)
          Download  a script from a remote location and execute the script
          locally.  The script can be located  on  the  salt  master  file
          server or on an HTTP/FTP server.

          The  script  will  be executed directly, so it can be written in
          any available programming language.

          Parameters

                 * source (str) -- The location of the script to download.
                   If  the  file is located on the master in the directory
                   named spam, and is called eggs, the  source  string  is
                   salt://spam/eggs

                 * args  (str)  --  String of command line args to pass to
                   the script.  Only used if no args are specified as part
                   of  the  name  argument.  To  pass  a string containing
                   spaces in YAML, you will need to doubly-quote it: "arg1
                   'arg two' arg3"

                 * cwd  (str)  -- The current working directory to execute
                   the command in, defaults to /root

                 * stdin (str) --  A  string  of  standard  input  can  be
                   specified  for  the  command  to be run using the stdin
                   parameter. This can be useful in cases where  sensitive
                   information must be read from standard input.:

                 * runas  (str)  -- User to run script as. If running on a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows only.  Required  when  specifying  runas.  This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell  (str) -- Shell to execute under. Defaults to the
                   system default shell.

                 * python_shell (bool) -- If False, let python handle  the
                   positional   arguments.   Set  to  True  to  use  shell
                   features, such as pipes or redirection

                 * bg (bool) -- If True, run script in background  and  do
                   not await or deliver it's results

                 * env (list) --

                   A  list  of  environment  variables  to be set prior to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The above illustrates a common  PyYAML  pitfall,
                          that  yes,  no, on, off, true, and false are all
                          loaded as boolean True  and  False  values,  and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings. More info on this  (and  other)  PyYAML
                          idiosyncrasies can be found here.

                      Variables  as  values are not evaluated. So $PATH in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One can still use the existing $PATH by using a  bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * template  (str)  -- If this setting is applied then the
                   named templating engine will  be  used  to  render  the
                   downloaded  file.  Currently jinja, mako, and wempy are
                   supported

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG)regardless, unless quiet is used for this value.

                 * quiet (bool) -- The command will be  executed  quietly,
                   meaning  no  log  entries  of the actual command or its
                   return data. This is  deprecated  as  of  the  2014.1.0
                   release,  and  is  being replaced with output_loglevel:
                   quiet.

                 * timeout (int) -- If  the  command  has  not  terminated
                   after timeout seconds, send the subprocess sigterm, and
                   if sigterm is ignored, follow up with sigkill

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command  output  more  interactively to the console and
                   the logs. This is experimental.

          CLI Example:

             salt '*' cmd.script salt://scripts/runme.sh
             salt '*' cmd.script salt://scripts/runme.sh 'arg1 arg2 "arg 3"'
             salt '*' cmd.script salt://scripts/windows_task.ps1 args=' -Input c:\tmp\infile.txt' shell='powershell'

             salt '*' cmd.script salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.script_retcode(source,     args=None,     cwd=None,
   stdin=None,  runas=None,  shell='/bin/sh', python_shell=None, env=None,
   template='jinja', umask=None,  timeout=None,  reset_system_locale=True,
   saltenv='base',       output_loglevel='debug',       log_callback=None,
   use_vt=False, password=None, **kwargs)
          Download a script from a remote location and execute the  script
          locally.   The  script  can  be  located on the salt master file
          server or on an HTTP/FTP server.

          The script will be executed directly, so it can  be  written  in
          any available programming language.

          The  script  can also be formatted as a template, the default is
          jinja.

          Only evaluate the script  return  code  and  do  not  block  for
          terminal output

          Parameters

                 * source (str) -- The location of the script to download.
                   If the file is located on the master in  the  directory
                   named  spam,  and  is called eggs, the source string is
                   salt://spam/eggs

                 * args (str) -- String of command line args  to  pass  to
                   the  script. Only used if no args are specified as part
                   of the name  argument.  To  pass  a  string  containing
                   spaces  in  YAML,  you  will  need  to doubly-quote it:
                   "arg1 'arg two' arg3"

                 * cwd (str) -- The current working directory  to  execute
                   the command in, defaults to /root

                 * stdin  (str)  --  A  string  of  standard  input can be
                   specified for the command to be  run  using  the  stdin
                   parameter.  This can be useful in cases where sensitive
                   information must be read from standard input.:

                 * runas (str) -- User to run script as. If running  on  a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows  only.  Required  when  specifying  runas. This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell (str) -- Shell to execute under. Defaults to  the
                   system default shell.

                 * python_shell  (bool) -- If False, let python handle the
                   positional  arguments.  Set  to  True  to   use   shell
                   features, such as pipes or redirection

                 * env (list) --

                   A  list  of  environment  variables  to be set prior to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The above illustrates a common  PyYAML  pitfall,
                          that  yes,  no, on, off, true, and false are all
                          loaded as boolean True  and  False  values,  and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings. More info on this  (and  other)  PyYAML
                          idiosyncrasies can be found here.

                      Variables  as  values are not evaluated. So $PATH in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One can still use the existing $PATH by using a  bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * template  (str)  -- If this setting is applied then the
                   named templating engine will  be  used  to  render  the
                   downloaded  file.  Currently jinja, mako, and wempy are
                   supported

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * quiet (bool) -- The command will be  executed  quietly,
                   meaning  no  log  entries  of the actual command or its
                   return data. This is  deprecated  as  of  the  2014.1.0
                   release,  and  is  being replaced with output_loglevel:
                   quiet.

                 * timeout (int) -- If  the  command  has  not  terminated
                   after timeout seconds, send the subprocess sigterm, and
                   if sigterm is ignored, follow up with sigkill

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command  output  more  interactively to the console and
                   the logs. This is experimental.

          CLI Example:

             salt '*' cmd.script_retcode salt://scripts/runme.sh
             salt '*' cmd.script_retcode salt://scripts/runme.sh 'arg1 arg2 "arg 3"'
             salt '*' cmd.script_retcode salt://scripts/windows_task.ps1 args=' -Input c:\tmp\infile.txt' shell='powershell'

          A string of standard input can be specified for the  command  to
          be  run  using  the stdin parameter. This can be useful in cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.script_retcode salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.cmdmod.shell(cmd,   cwd=None,   stdin=None,    runas=None,
   shell='/bin/sh', env=None, clean_env=False, template=None, rstrip=True,
   umask=None,  output_loglevel='debug',  log_callback=None,  quiet=False,
   timeout=None,      reset_system_locale=True,      ignore_retcode=False,
   saltenv='base', use_vt=False, bg=False, password=None, **kwargs)
          Execute the passed command and return the output as a string.

          New in version 2015.5.0.

          Parameters

                 * cmd (str) -- The command to run. ex: 'ls -lart /home'

                 * cwd (str) -- The current working directory  to  execute
                   the command in, defaults to /root

                 * stdin  (str)  --  A  string  of  standard  input can be
                   specified for the command to be  run  using  the  stdin
                   parameter.  This can be useful in cases where sensitive
                   information must be read from standard input.

                 * runas (str) -- User to run script as. If running  on  a
                   Windows minion you must also pass a password

                 * password (str) --

                   Windows  only.  Required  when  specifying  runas. This
                   parameter will be ignored on non-Windows platforms.

                   New in version 2016.3.0.

                 * shell (int) -- Shell to execute under. Defaults to  the
                   system default shell.

                 * bg  (bool) -- If True, run command in background and do
                   not await or deliver its results

                 * env (list) --

                   A list of environment variables  to  be  set  prior  to
                   execution.
                      Example:

                          salt://scripts/foo.sh:
                            cmd.script:
                              - env:
                                - BATCH: 'yes'

                      WARNING:
                          The  above  illustrates a common PyYAML pitfall,
                          that yes, no, on, off, true, and false  are  all
                          loaded  as  boolean  True  and False values, and
                          must  be  enclosed  in  quotes  to  be  used  as
                          strings.  More  info  on this (and other) PyYAML
                          idiosyncrasies can be found here.

                      Variables as values are not evaluated. So  $PATH  in
                      the following example is a literal '$PATH':

                          salt://scripts/bar.sh:
                            cmd.script:
                              - env: "PATH=/some/path:$PATH"

                      One  can still use the existing $PATH by using a bit
                      of Jinja:

                          {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                          mycommand:
                            cmd.run:
                              - name: ls -l /
                              - env:
                                - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

                 * clean_env (bool) -- Attempt  to  clean  out  all  other
                   shell environment variables and set only those provided
                   in the 'env' argument to this function.

                 * template (str) -- If this setting is applied  then  the
                   named  templating  engine  will  be  used to render the
                   downloaded file. Currently jinja, mako, and  wempy  are
                   supported

                 * rstrip  (bool)  --  Strip all whitespace off the end of
                   output before it is returned.

                 * umask (str) -- The umask (in octal) to use when running
                   the command.

                 * output_loglevel  (str) -- Control the loglevel at which
                   the output from the command is logged.  Note  that  the
                   command  being  run  will  still  be  logged (loglevel:
                   DEBUG) regardless, unless quiet is used for this value.

                 * timeout (int) -- A timeout in seconds for the  executed
                   process to return.

                 * use_vt (bool) -- Use VT utils (saltstack) to stream the
                   command output more interactively to  the  console  and
                   the logs. This is experimental.

          WARNING:
             This  passes  the  cmd argument directly to the shell without
             any further processing! Be  absolutely  sure  that  you  have
             properly sanitized the command passed to this function and do
             not use untrusted inputs.

          NOTE:
             env represents the environment variables for the command, and
             should  be  formatted  as  a  dict,  or  a  YAML string which
             resolves to a dict.

          CLI Example:

             salt '*' cmd.shell "ls -l | awk '/foo/{print \$2}'"

          The template arg can be set  to  'jinja'  or  another  supported
          template   engine   to   render  the  command  arguments  before
          execution.  For example:

             salt '*' cmd.shell template=jinja "ls -l /tmp/{{grains.id}} | awk '/foo/{print \$2}'"

          Specify an alternate shell with the shell parameter:

             salt '*' cmd.shell "Get-ChildItem C:\ " shell='powershell'

          A string of standard input can be specified for the  command  to
          be  run  using  the stdin parameter. This can be useful in cases
          where sensitive information must be read from standard input.:

             salt '*' cmd.shell "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'

          If an equal sign (=) appears in an argument to a Salt command it
          is interpreted as a keyword argument in the format key=val. That
          processing can be bypassed  in  order  to  pass  an  equal  sign
          through  to  the remote shell command by manually specifying the
          kwarg:

             salt '*' cmd.shell cmd='sed -e s/=/:/g'

   salt.modules.cmdmod.shell_info(shell, list_modules=False)
          New in version 2016.11.0.

          Provides information about a shell  or  script  languages  which
          often  use #!. The values returned are dependant on the shell or
          scripting languages all return  the  installed,  path,  version,
          version_raw

          Parameters

                 * shell (str) -- Name of the shell. Support shells/script
                   languages include

                 * cmd,  perl,  php,  powershell,  python,  ruby  and  zsh
                   (bash,) --

                 * list_modules  (bool)  -- True to list modules available
                   to the shell.

                 * only lists powershell modules. (Currently) --

          Returns
                 A dictionary of information about the shell

          Return type
                 dict

             {'version': '<2 or 3 numeric components dot-separated>',
              'version_raw': '<full version string>',
              'path': '<full path to binary>',
              'installed': <True, False or None>,
              '<attribute>': '<attribute value>'}

          NOTE:

             * installed is always returned, if None or False also returns
               error and may also return stdout for diagnostics.

             * version  is for use in determine if a shell/script language
               has a particular feature set, not for package management.

             * The shell must be within the executable search path.

          CLI Example:

             salt '*' cmd.shell_info bash
             salt '*' cmd.shell_info powershell

          Codeauthor
                 Damon Atkins <https://github.com/damon-atkins>

   salt.modules.cmdmod.shells()
          Lists the valid shells on this system via the /etc/shells file

          New in version 2015.5.0.

          CLI Example:

             salt '*' cmd.shells

   salt.modules.cmdmod.tty(device, echo=None)
          Echo a string to a specific tty

          CLI Example:

             salt '*' cmd.tty tty0 'This is a test'
             salt '*' cmd.tty pts3 'This is a test'

   salt.modules.cmdmod.which(cmd)
          Returns the path of an executable available on the minion,  None
          otherwise

          CLI Example:

             salt '*' cmd.which cat

   salt.modules.cmdmod.which_bin(cmds)
          Returns the first command found in a list of commands

          CLI Example:

             salt '*' cmd.which_bin '[pip2, pip, pip-python]'

   salt.modules.composer
   Use composer to install PHP dependencies for a directory

   salt.modules.composer.did_composer_install(dir)
          Test to see if the vendor directory exists in this directory

          dir    Directory location of the composer.json file

          CLI Example:

             salt '*' composer.did_composer_install /var/www/application

   salt.modules.composer.install(directory,    composer=None,    php=None,
   runas=None,  prefer_source=None,   prefer_dist=None,   no_scripts=None,
   no_plugins=None,      optimize=None,      no_dev=None,     quiet=False,
   composer_home='/root')
          Install composer dependencies for a directory.

          If composer has not been installed globally making it  available
          in  the system PATH & making it executable, the composer and php
          parameters  will  need  to  be  set  to  the  location  of   the
          executables.

          directory
                 Directory location of the composer.json file.

          composer
                 Location  of  the composer.phar file. If not set composer
                 will just  execute  "composer"  as  if  it  is  installed
                 globally.  (i.e. /path/to/composer.phar)

          php    Location  of  the  php  executable  to use with composer.
                 (i.e. /usr/bin/php)

          runas  Which system user to run composer as.

          prefer_source
                 --prefer-source option of composer.

          prefer_dist
                 --prefer-dist option of composer.

          no_scripts
                 --no-scripts option of composer.

          no_plugins
                 --no-plugins option of composer.

          optimize
                 --optimize-autoloader option of composer. Recommended for
                 production.

          no_dev --no-dev option for composer. Recommended for production.

          quiet  --quiet  option  for  composer.  Whether or not to return
                 output from composer.

          composer_home
                 $COMPOSER_HOME environment variable

          CLI Example:

             salt '*' composer.install /var/www/application

             salt '*' composer.install /var/www/application             no_dev=True optimize=True

   salt.modules.composer.selfupdate(composer=None,  php=None,  runas=None,
   quiet=False, composer_home='/root')
          Update composer itself.

          If  composer has not been installed globally making it available
          in the system PATH & making it executable, the composer and  php
          parameters   will  need  to  be  set  to  the  location  of  the
          executables.

          composer
                 Location of the composer.phar file. If not  set  composer
                 will  just  execute  "composer"  as  if  it  is installed
                 globally.  (i.e. /path/to/composer.phar)

          php    Location of the php  executable  to  use  with  composer.
                 (i.e. /usr/bin/php)

          runas  Which system user to run composer as.

          quiet  --quiet  option  for  composer.  Whether or not to return
                 output from composer.

          composer_home
                 $COMPOSER_HOME environment variable

          CLI Example:

             salt '*' composer.selfupdate

   salt.modules.composer.update(directory,    composer=None,     php=None,
   runas=None,   prefer_source=None,   prefer_dist=None,  no_scripts=None,
   no_plugins=None,     optimize=None,      no_dev=None,      quiet=False,
   composer_home='/root')
          Update composer dependencies for a directory.

          If  composer  install  has  not yet been run, this runs composer
          install instead.

          If composer has not been installed globally making it  available
          in  the system PATH & making it executable, the composer and php
          parameters  will  need  to  be  set  to  the  location  of   the
          executables.

          directory
                 Directory location of the composer.json file.

          composer
                 Location  of  the composer.phar file. If not set composer
                 will just  execute  "composer"  as  if  it  is  installed
                 globally.  (i.e. /path/to/composer.phar)

          php    Location  of  the  php  executable  to use with composer.
                 (i.e. /usr/bin/php)

          runas  Which system user to run composer as.

          prefer_source
                 --prefer-source option of composer.

          prefer_dist
                 --prefer-dist option of composer.

          no_scripts
                 --no-scripts option of composer.

          no_plugins
                 --no-plugins option of composer.

          optimize
                 --optimize-autoloader option of composer. Recommended for
                 production.

          no_dev --no-dev option for composer. Recommended for production.

          quiet  --quiet  option  for  composer.  Whether or not to return
                 output from composer.

          composer_home
                 $COMPOSER_HOME environment variable

          CLI Example:

             salt '*' composer.update /var/www/application

             salt '*' composer.update /var/www/application             no_dev=True optimize=True

   salt.modules.config
   Return config information

   salt.modules.config.backup_mode(backup='')
          Return the backup mode

          CLI Example:

             salt '*' config.backup_mode

   salt.modules.config.dot_vals(value)
          Pass in a configuration value that should  be  preceded  by  the
          module  name  and  a  dot,  this  will return a list of all read
          key/value pairs

          CLI Example:

             salt '*' config.dot_vals host

   salt.modules.config.gather_bootstrap_script(bootstrap=None)
          Download the salt-bootstrap script, and return its location

          bootstrap
                 URL of alternate bootstrap script

          CLI Example:

             salt '*' config.gather_bootstrap_script

   salt.modules.config.get(key, default='', delimiter=':', merge=None)
          Attempt to retrieve the named value from the minion config file,
          pillar,  grains  or the master config. If the named value is not
          available,  return  the  value  specified  by  default.  If  not
          specified, the default is an empty string.

          Values  can  also  be retrieved from nested dictionaries. Assume
          the below data structure:

             {'pkg': {'apache': 'httpd'}}

          To retrieve the value associated with the  apache  key,  in  the
          sub-dictionary  corresponding  to  the  pkg  key,  the following
          command can be used:

             salt myminion config.get pkg:apache

          The : (colon) is used to represent a nested dictionary level.

          Changed in version 2015.5.0: The delimiter argument  was  added,
          to allow delimiters other than : to be used.

          This  function  traverses  these  data  stores  in  this  order,
          returning the first match found:

          * Minion configuration

          * Minion's grains

          * Minion's pillar data

          * Master configuration (requires pillar_opts to be set  to  True
            in Minion config file in order to work)

          This means that if there is a value that is going to be the same
          for the majority of minions, it can be configured in the  Master
          config  file,  and  then overridden using the grains, pillar, or
          Minion config file.

          Adding config options to the Master or Minion configuration file
          is easy:

             my-config-option: value
             cafe-menu:
               - egg and bacon
               - egg sausage and bacon
               - egg and spam
               - egg bacon and spam
               - egg bacon sausage and spam
               - spam bacon sausage and spam
               - spam egg spam spam bacon and spam
               - spam sausage spam spam bacon spam tomato and spam

          NOTE:
             Minion  configuration  options  built  into  Salt (like those
             defined  here)  will  always  be  defined   in   the   Minion
             configuration  and  thus  cannot  be  overridden by grains or
             pillar data. However, additional (user-defined) configuration
             options  (as  in the above example) will not be in the Minion
             configuration by default and thus  can  be  overridden  using
             grains/pillar  data  by  leaving the option out of the minion
             config file.

          Arguments

          delimiter
                 New in version 2015.5.0.

                 Override the delimiter used to separate nested levels  of
                 a data structure.

          merge  New in version 2015.5.0.

                 If passed, this parameter will change the behavior of the
                 function so that, instead of traversing each  data  store
                 above  in  order  and returning the first match, the data
                 stores are first merged together and then  searched.  The
                 pillar  data  is merged into the master config data, then
                 the grains are merged,  followed  by  the  Minion  config
                 data.   The resulting data structure is then searched for
                 a match.  This  allows  for  configurations  to  be  more
                 flexible.

                 NOTE:
                    The  merging  described above does not mean that grain
                    data will end up  in  the  Minion's  pillar  data,  or
                    pillar  data  will  end  up in the master config data,
                    etc. The data is just combined  for  the  purposes  of
                    searching an amalgam of the different data stores.

                 The supported merge strategies are as follows:

                 * recurse - If a key exists in both dictionaries, and the
                   new  value  is  not  a  dictionary,  it  is   replaced.
                   Otherwise,  the  sub-dictionaries  are  merged together
                   into  a  single  dictionary,   recursively   on   down,
                   following the same criteria. For example:

                      >>> dict1 = {'foo': {'bar': 1, 'qux': True},
                                   'hosts': ['a', 'b', 'c'],
                                   'only_x': None}
                      >>> dict2 = {'foo': {'baz': 2, 'qux': False},
                                   'hosts': ['d', 'e', 'f'],
                                   'only_y': None}
                      >>> merged
                      {'foo': {'bar': 1, 'baz': 2, 'qux': False},
                       'hosts': ['d', 'e', 'f'],
                       'only_dict1': None,
                       'only_dict2': None}

                 * overwrite  -  If  a key exists in the top level of both
                   dictionaries, the new value completely  overwrites  the
                   old. For example:

                      >>> dict1 = {'foo': {'bar': 1, 'qux': True},
                                   'hosts': ['a', 'b', 'c'],
                                   'only_x': None}
                      >>> dict2 = {'foo': {'baz': 2, 'qux': False},
                                   'hosts': ['d', 'e', 'f'],
                                   'only_y': None}
                      >>> merged
                      {'foo': {'baz': 2, 'qux': False},
                       'hosts': ['d', 'e', 'f'],
                       'only_dict1': None,
                       'only_dict2': None}

          CLI Example:

             salt '*' config.get pkg:apache
             salt '*' config.get lxc.container_profile:centos merge=recurse

   salt.modules.config.manage_mode(mode)
          Return a mode value, normalized to a string

          CLI Example:

             salt '*' config.manage_mode

   salt.modules.config.merge(value,      default='',      omit_opts=False,
   omit_master=False, omit_pillar=False)
          Retrieves an option based on key, merging all matches.

          Same as option() except that it merges all matches, rather  than
          taking the first match.

          CLI Example:

             salt '*' config.merge schedule

   salt.modules.config.option(value,      default='',     omit_opts=False,
   omit_master=False, omit_pillar=False)
          Pass in a generic option and receive  the  value  that  will  be
          assigned

          CLI Example:

             salt '*' config.option redis.host

   salt.modules.config.valid_fileproto(uri)
          Returns  a  boolean value based on whether or not the URI passed
          has a valid remote file protocol designation

          CLI Example:

             salt '*' config.valid_fileproto salt://path/to/file

   salt.modules.consul
   Interact with Consul

   https://www.consul.io

   salt.modules.consul.acl_clone(consul_url=None, **kwargs)
          Information about an ACL token.

          Parameters

                 * consul_url -- The Consul server URL.

                 * id -- Unique identifier for the ACL to update.

          Returns
                 Boolean, message of success or failure,  and  new  ID  of
                 cloned ACL.

          CLI Example:

             salt '*' consul.acl_info id='c1c4d223-91cb-3d1f-1ee8-f2af9e7b6716'

   salt.modules.consul.acl_create(consul_url=None, **kwargs)
          Create a new ACL token.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- Meaningful indicator of the ACL's purpose.

                 * type   --  Type  is  either  client  or  management.  A
                   management token is comparable to a root user  and  has
                   the  ability  to perform any action including creating,
                   modifying, and deleting ACLs.

                 * rules -- The Consul server URL.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.acl_create

   salt.modules.consul.acl_delete(consul_url=None, **kwargs)
          Delete an ACL token.

          Parameters

                 * consul_url -- The Consul server URL.

                 * id -- Unique identifier for the ACL to update.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.acl_delete id='c1c4d223-91cb-3d1f-1ee8-f2af9e7b6716'

   salt.modules.consul.acl_info(consul_url=None, **kwargs)
          Information about an ACL token.

          Parameters

                 * consul_url -- The Consul server URL.

                 * id -- Unique identifier for the ACL to update.

          Returns
                 Information about the ACL requested.

          CLI Example:

             salt '*' consul.acl_info id='c1c4d223-91cb-3d1f-1ee8-f2af9e7b6716'

   salt.modules.consul.acl_list(consul_url=None, **kwargs)
          List the ACL tokens.

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 List of ACLs

          CLI Example:

             salt '*' consul.acl_list

   salt.modules.consul.acl_update(consul_url=None, **kwargs)
          Update an ACL token.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- Meaningful indicator of the ACL's purpose.

                 * id -- Unique identifier for the ACL to update.

                 * type  --  Type  is  either  client  or  management.   A
                   management  token  is comparable to a root user and has
                   the ability to perform any action  including  creating,
                   modifying, and deleting ACLs.

                 * rules -- The Consul server URL.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.acl_update

   salt.modules.consul.agent_check_deregister(consul_url=None,
   checkid=None)
          The agent will take care of deregistering  the  check  from  the
          Catalog.

          Parameters

                 * consul_url -- The Consul server URL.

                 * checkid  --  The  ID  of  the  check to deregister from
                   Consul.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_check_deregister checkid='Memory Utilization'

   salt.modules.consul.agent_check_fail(consul_url=None,     checkid=None,
   **kwargs)
          This endpoint is used with a check that is of the TTL type. When
          this is called, the status of the check is set to  critical  and
          the TTL clock is reset.

          Parameters

                 * consul_url -- The Consul server URL.

                 * checkid  --  The  ID  of  the  check to deregister from
                   Consul.

                 * note -- A human-readable message with the status of the
                   check.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_check_fail checkid='redis_check1'
                     note='Forcing check into critical state.'

   salt.modules.consul.agent_check_pass(consul_url=None,     checkid=None,
   **kwargs)
          This endpoint is used with a check that is of the TTL type. When
          this  is  called,  the status of the check is set to passing and
          the TTL clock is reset.

          Parameters

                 * consul_url -- The Consul server URL.

                 * checkid -- The ID of the check to mark as passing.

                 * note -- A human-readable message with the status of the
                   check.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_check_pass checkid='redis_check1'
                     note='Forcing check into passing state.'

   salt.modules.consul.agent_check_register(consul_url=None, **kwargs)
          The  register  endpoint  is used to add a new check to the local
          agent.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- The description of what the check is for.

                 * id -- The unique name to use  for  the  check,  if  not
                   provided 'name' is used.

                 * notes -- Human readable description of the check.

                 * script  --  If  script is provided, the check type is a
                   script, and Consul will evaluate that script  based  on
                   the interval parameter.

                 * http  -- Check will perform an HTTP GET request against
                   the value of HTTP (expected to be a URL) based  on  the
                   interval parameter.

                 * ttl  --  If  a  TTL  type  is used, then the TTL update
                   endpoint must be used periodically to update the  state
                   of the check.

                 * interval -- Interval at which the check should run.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_check_register name='Memory Utilization'
                     script='/usr/local/bin/check_mem.py' interval='15s'

   salt.modules.consul.agent_check_warn(consul_url=None,     checkid=None,
   **kwargs)
          This endpoint is used with a check that is of the TTL type. When
          this  is  called,  the status of the check is set to warning and
          the TTL clock is reset.

          Parameters

                 * consul_url -- The Consul server URL.

                 * checkid -- The ID  of  the  check  to  deregister  from
                   Consul.

                 * note -- A human-readable message with the status of the
                   check.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_check_warn checkid='redis_check1'
                     note='Forcing check into warning state.'

   salt.modules.consul.agent_checks(consul_url=None)
          Returns the checks the local agent is managing

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 Returns the checks the local agent is managing

          CLI Example:

             salt '*' consul.agent_checks

   salt.modules.consul.agent_join(consul_url=None, address=None, **kwargs)
          Triggers the local agent to join a node

          Parameters

                 * consul_url -- The Consul server URL.

                 * address -- The address for the agent to connect to.

                 * wan -- Causes the agent to attempt to  join  using  the
                   WAN pool.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_join address='192.168.1.1'

   salt.modules.consul.agent_leave(consul_url=None, node=None)
          Used to instruct the agent to force a node into the left state.

          Parameters

                 * consul_url -- The Consul server URL.

                 * node -- The node the agent will force into left state

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_leave node='web1.example.com'

   salt.modules.consul.agent_maintenance(consul_url=None, **kwargs)
          Manages node maintenance mode

          Parameters

                 * consul_url -- The Consul server URL.

                 * enable  --  The  enable  flag  is required.  Acceptable
                   values are either true (to enter maintenance  mode)  or
                   false (to resume normal operation).

                 * reason  --  If  provided,  its  value  should be a text
                   string explaining the reason for placing the node  into
                   maintenance mode.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_maintenance enable='False' reason='Upgrade in progress'

   salt.modules.consul.agent_members(consul_url=None, **kwargs)
          Returns the members as seen by the local serf agent

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 Returns the members as seen by the local serf agent

          CLI Example:

             salt '*' consul.agent_members

   salt.modules.consul.agent_self(consul_url=None)
          Returns the local node configuration

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 Returns the local node configuration

          CLI Example:

             salt '*' consul.agent_self

   salt.modules.consul.agent_service_deregister(consul_url=None,
   serviceid=None)
          Used to remove a service.

          Parameters

                 * consul_url -- The Consul server URL.

                 * serviceid -- A serviceid describing the service.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_service_deregister serviceid='redis'

   salt.modules.consul.agent_service_maintenance(consul_url=None,
   serviceid=None, **kwargs)
          Used to place a service into maintenance mode.

          Parameters

                 * consul_url -- The Consul server URL.

                 * serviceid -- A name of the service.

                 * enable  --  Whether  the  service  should be enabled or
                   disabled.

                 * reason -- A human readable message of why  the  service
                   was enabled or disabled.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_service_deregister serviceid='redis'
                     enable='True' reason='Down for upgrade'

   salt.modules.consul.agent_service_register(consul_url=None, **kwargs)
          The used to add a new service, with an optional health check, to
          the local agent.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- A name describing the service.

                 * address -- The address used by the service, defaults to
                   the address of the agent.

                 * port -- The port used by the service.

                 * id  --  Unique  ID  to  identify  the  service,  if not
                   provided the value of the name parameter is used.

                 * tags -- Identifying tags for service, string or list.

                 * script -- If script is provided, the check  type  is  a
                   script,  and  Consul will evaluate that script based on
                   the interval parameter.

                 * http -- Check will perform an HTTP GET request  against
                   the  value  of HTTP (expected to be a URL) based on the
                   interval parameter.

                 * check_ttl -- If a TTL type is used, then the TTL update
                   endpoint  must be used periodically to update the state
                   of the check.

                 * check_interval -- Interval at which  the  check  should
                   run.

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.agent_service_register name='redis'
                 tags='["master", "v1"]' address="127.0.0.1" port="8080"
                 check_script="/usr/local/bin/check_redis.py" interval="10s"

   salt.modules.consul.agent_services(consul_url=None)
          Returns the services the local agent is managing

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 Returns the services the local agent is managing

          CLI Example:

             salt '*' consul.agent_services

   salt.modules.consul.catalog_datacenters(consul_url=None)
          Return list of available datacenters from catalog.

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 The list of available datacenters.

          CLI Example:

             salt '*' consul.catalog_datacenters

   salt.modules.consul.catalog_deregister(consul_url=None, **kwargs)
          Deregisters a node, service, or check

          Parameters

                 * consul_url -- The Consul server URL.

                 * node -- The node to deregister.

                 * datacenter  --  By default, the datacenter of the agent
                   is queried; however, the dc can be provided  using  the
                   "dc" parameter.

                 * checkid -- The ID of the health check to deregister.

                 * serviceid -- The ID of the service to deregister.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.catalog_register node='node1'
                 serviceid='redis_server1' checkid='redis_check1'

   salt.modules.consul.catalog_node(consul_url=None, node=None, **kwargs)
          Information about the registered node.

          Parameters

                 * consul_url -- The Consul server URL.

                 * node -- The node to request information about.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 Information about the requested node.

          CLI Example:

             salt '*' consul.catalog_service service='redis'

   salt.modules.consul.catalog_nodes(consul_url=None, **kwargs)
          Return list of available nodes from catalog.

          Parameters

                 * consul_url -- The Consul server URL.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 The list of available nodes.

          CLI Example:

             salt '*' consul.catalog_nodes

   salt.modules.consul.catalog_register(consul_url=None, **kwargs)
          Registers a new node, service, or check

          Parameters

                 * consul_url -- The Consul server URL.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

                 * node -- The node to register.

                 * address -- The address of the node.

                 * service -- The service that will be registered.

                 * service_address -- The address that the service listens
                   on.

                 * service_port -- The port for the service.

                 * service_id -- A unique identifier for the  service,  if
                   this is not provided "name" will be used.

                 * service_tags -- Any tags associated with the service.

                 * check -- The name of the health check to register

                 * check_status  --  The initial status of the check, must
                   be one of unknown, passing, warning, or critical.

                 * check_service  --  The  service  that  the   check   is
                   performed against.

                 * check_id -- Unique identifier for the service.

                 * check_notes  --  An  opaque field that is meant to hold
                   human-readable text.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.catalog_register node='node1' address='192.168.1.1'
                 service='redis' service_address='127.0.0.1' service_port='8080'
                 service_id='redis_server1'

   salt.modules.consul.catalog_service(consul_url=None,      service=None,
   **kwargs)
          Information about the registered service.

          Parameters

                 * consul_url -- The Consul server URL.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

                 * tag -- Filter returned services with tag parameter.

          Returns
                 Information about the requested service.

          CLI Example:

             salt '*' consul.catalog_service service='redis'

   salt.modules.consul.catalog_services(consul_url=None, **kwargs)
          Return list of available services rom catalog.

          Parameters

                 * consul_url -- The Consul server URL.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 The list of available services.

          CLI Example:

             salt '*' consul.catalog_services

   salt.modules.consul.delete(consul_url=None, key=None, **kwargs)
          Delete values from Consul

          Parameters

                 * consul_url -- The Consul server URL.

                 * key  --  The  key  to use as the starting point for the
                   list.

                 * recurse -- Delete values recursively beginning  at  the
                   value of key.

                 * cas  --  This  flag  is  used to turn the DELETE into a
                   Check-And-Set operation.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.delete key='web'

             salt '*' consul.delete key='web' recurse='True'

   salt.modules.consul.event_fire(consul_url=None, name=None, **kwargs)
          List the ACL tokens.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- The name of the event to fire.

                 * dc -- By  default,  the  datacenter  of  the  agent  is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

                 * node -- Filter by node name.

                 * service -- Filter by service name.

                 * tag -- Filter by tag name.

          Returns
                 List of ACLs

          CLI Example:

             salt '*' consul.event_fire name='deploy'

   salt.modules.consul.event_list(consul_url=None, **kwargs)
          List the recent events.

          Parameters

                 * consul_url -- The Consul server URL.

                 * name -- The name of the event to fire.

          Returns
                 List of ACLs

          CLI Example:

             salt '*' consul.event_list

   salt.modules.consul.get(consul_url=None,    key=None,    recurse=False,
   decode=False, raw=False)
          Get key from Consul

          Parameters

                 * consul_url -- The Consul server URL.

                 * key  --  The  key  to use as the starting point for the
                   list.

                 * recurse -- Return values recursively beginning  at  the
                   value of key.

                 * decode  --  By  default  values  are  stored  as Base64
                   encoded values, decode will return the whole  key  with
                   the value decoded.

                 * raw -- Simply return the decoded value of the key.

          Returns
                 The keys in Consul.

          CLI Example:

             salt '*' consul.get key='web/key1'

             salt '*' consul.list key='web' recurse='True

             salt '*' consul.list key='web' recurse='True' decode='True'

          By  default  values stored in Consul are base64 encoded, passing
          the decode option will show them as the decoded values.

             salt '*' consul.list key='web' recurse='True' decode='True' raw='True'

          By default Consult will return other information about the  key,
          the raw option will return only the raw value.

   salt.modules.consul.health_checks(consul_url=None,        service=None,
   **kwargs)
          Health information about the registered service.

          Parameters

                 * consul_url -- The Consul server URL.

                 * service -- The service to  request  health  information
                   about.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 Health information about the requested node.

          CLI Example:

             salt '*' consul.health_checks service='redis1'

   salt.modules.consul.health_node(consul_url=None, node=None, **kwargs)
          Health information about the registered node.

          Parameters

                 * consul_url -- The Consul server URL.

                 * node -- The node to request health information about.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 Health information about the requested node.

          CLI Example:

             salt '*' consul.health_node node='node1'

   salt.modules.consul.health_service(consul_url=None,       service=None,
   **kwargs)
          Health information about the registered service.

          Parameters

                 * consul_url -- The Consul server URL.

                 * service -- The service to  request  health  information
                   about.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

                 * tag -- Filter returned services with tag parameter.

                 * passing -- Filter results to only nodes with all checks
                   in the passing state.

          Returns
                 Health information about the requested node.

          CLI Example:

             salt '*' consul.health_service service='redis1'

             salt '*' consul.health_service service='redis1' passing='True'

   salt.modules.consul.health_state(consul_url=None, state=None, **kwargs)
          Returns the checks in the state provided on the path.

          Parameters

                 * consul_url -- The Consul server URL.

                 * state -- The state to show checks  for.  The  supported
                   states are any, unknown, passing, warning, or critical.
                   The any state is a wildcard that can be used to  return
                   all checks.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 The checks in the provided state.

          CLI Example:

             salt '*' consul.health_state state='redis1'

             salt '*' consul.health_state service='redis1' passing='True'

   salt.modules.consul.list(consul_url=None, key=None, **kwargs)
          List keys in Consul

          Parameters

                 * consul_url -- The Consul server URL.

                 * key  --  The  key  to use as the starting point for the
                   list.

          Returns
                 The list of keys.

          CLI Example:

             salt '*' consul.list

             salt '*' consul.list key='web'

   salt.modules.consul.put(consul_url=None,     key=None,      value=None,
   **kwargs)
          Put values into Consul

          Parameters

                 * consul_url -- The Consul server URL.

                 * key  --  The  key  to use as the starting point for the
                   list.

                 * value -- The value to set the key to.

                 * flags -- This can be used to specify an unsigned  value
                   between  0  and  2^64-1. Clients can choose to use this
                   however makes sense for their application.

                 * cas -- This flag  is  used  to  turn  the  PUT  into  a
                   Check-And-Set operation.

                 * acquire  --  This  flag  is used to turn the PUT into a
                   lock acquisition operation.

                 * release -- This flag is used to turn  the  PUT  into  a
                   lock release operation.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.put key='web/key1' value="Hello there"

             salt '*' consul.put key='web/key1' value="Hello there"
                                     acquire='d5d371f4-c380-5280-12fd-8810be175592'

             salt '*' consul.put key='web/key1' value="Hello there"
                                     release='d5d371f4-c380-5280-12fd-8810be175592'

   salt.modules.consul.session_create(consul_url=None, **kwargs)
          Used to create a session.

          Parameters

                 * consul_url -- The Consul server URL.

                 * lockdelay  --  Duration  string  using a "s" suffix for
                   seconds.  The default is 15s.

                 * node  --  Must  refer  to  a  node  that   is   already
                   registered,  if  specified. By default, the agent's own
                   node name is used.

                 * name -- A human-readable name for the session

                 * checks -- A list of associated  health  checks.  It  is
                   highly recommended that, if you override this list, you
                   include the default "serfHealth".

                 * behavior -- Can be set to  either  release  or  delete.
                   This   controls   the   behavior   when  a  session  is
                   invalidated. By default, this is release,  causing  any
                   locks  that  are  held to be released. Changing this to
                   delete causes any locks that are held  to  be  deleted.
                   delete  is  useful  for  creating  ephemeral  key/value
                   entries.

                 * ttl -- Session is invalidated  if  it  is  not  renewed
                   before the TTL expires

          Returns
                 Boolean and message indicating success or failure.

          CLI Example:

             salt '*' consul.session_create node='node1' name='my-session'
                     behavior='delete' ttl='3600s'

   salt.modules.consul.session_destroy(consul_url=None,      session=None,
   **kwargs)
          Destroy session

          Parameters

                 * consul_url -- The Consul server URL.

                 * session -- The ID of the session to destroy.

                 * dc -- By  default,  the  datacenter  of  the  agent  is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.session_destroy session='c1c4d223-91cb-3d1f-1ee8-f2af9e7b6716'

   salt.modules.consul.session_info(consul_url=None,         session=None,
   **kwargs)
          Information about a session

          Parameters

                 * consul_url -- The Consul server URL.

                 * session  -- The ID of the session to return information
                   about.

                 * dc -- By  default,  the  datacenter  of  the  agent  is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

          Returns
                 Boolean & message of success or failure.

          CLI Example:

             salt '*' consul.session_info session='c1c4d223-91cb-3d1f-1ee8-f2af9e7b6716'

   salt.modules.consul.session_list(consul_url=None,    return_list=False,
   **kwargs)
          Used to list sessions.

          Parameters

                 * consul_url -- The Consul server URL.

                 * dc  --  By  default,  the  datacenter  of  the agent is
                   queried; however, the dc can be provided using the "dc"
                   parameter.

                 * return_list  --  By  default, all information about the
                   sessions is returned, using the  return_list  parameter
                   will return a list of session IDs.

          Returns
                 A list of all available sessions.

          CLI Example:

             salt '*' consul.session_list

   salt.modules.consul.status_leader(consul_url=None)
          Returns the current Raft leader

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 The address of the Raft leader.

          CLI Example:

             salt '*' consul.status_leader

   salt.modules.consul.status_peers(consul_url)
          Returns the current Raft peer set

          Parameters
                 consul_url -- The Consul server URL.

          Returns
                 Retrieves  the Raft peers for the datacenter in which the
                 the agent is running.

          CLI Example:

             salt '*' consul.status_peers

   salt.modules.container_resource
   Common resources for LXC and systemd-nspawn containers

   New in version 2015.8.0.

   These functions are not designed to be  called  directly,  but  instead
   from  the lxc, nspawn, and dockerng execution modules. They provide for
   common logic to be re-used for common actions.

   salt.modules.container_resource.cache_file(source)
          Wrapper for cp.cache_file which raises an error if the file  was
          unable to be cached.

          CLI Example:

             salt myminion container_resource.cache_file salt://foo/bar/baz.txt

   salt.modules.container_resource.copy_to(*args, **kwargs)
          Common logic for copying files to containers

          path   path  to  the  container  parent  (for LXC only) default:
                 /var/lib/lxc (system default)

          CLI Example:

             salt myminion container_resource.copy_to mycontainer /local/file/path /container/file/path container_type=docker exec_driver=nsenter

   salt.modules.container_resource.run(*args, **kwargs)
          Common logic for running shell commands in containers

          path   path to the container  parent  (for  LXC  only)  default:
                 /var/lib/lxc (system default)

          CLI Example:

             salt myminion container_resource.run mycontainer 'ps aux' container_type=docker exec_driver=nsenter output=stdout

   salt.modules.cp
   Minion side functions for salt-cp

   salt.modules.cp.cache_dir(path,   saltenv='base',  include_empty=False,
   include_pat=None, exclude_pat=None)
          Download and cache everything under a directory from the master

          include_pat
                 None Glob or regex to narrow down the files  cached  from
                 the  given path. If matching with a regex, the regex must
                 be prefixed with E@, otherwise  the  expression  will  be
                 interpreted as a glob.

                 New in version 2014.7.0.

          exclude_pat
                 None  Glob  or  regex to exclude certain files from being
                 cached from the given path. If matching with a regex, the
                 regex  must be prefixed with E@, otherwise the expression
                 will be interpreted as a glob.

                 NOTE:
                    If used with include_pat, files matching this  pattern
                    will  be  excluded from the subset of files defined by
                    include_pat.

                 New in version 2014.7.0.

          CLI Examples:

             salt '*' cp.cache_dir salt://path/to/dir
             salt '*' cp.cache_dir salt://path/to/dir include_pat='E@*.py$'

   salt.modules.cp.cache_file(path, saltenv='base')
          Used to cache a single file on the Minion

          Returns the location of the new cached file on the Minion.

          CLI Example:

             salt '*' cp.cache_file salt://path/to/file

          There are  two  ways  of  defining  the  fileserver  environment
          (a.k.a.   saltenv)  from  which to cache the file. One is to use
          the saltenv parameter, and the other is  to  use  a  querystring
          syntax   in   the  salt://  URL.  The  below  two  examples  are
          equivalent:

             salt '*' cp.cache_file salt://foo/bar.conf saltenv=config
             salt '*' cp.cache_file salt://foo/bar.conf?saltenv=config

          NOTE:
             It  may  be  necessary  to  quote  the  URL  when  using  the
             querystring  method, depending on the shell being used to run
             the command.

   salt.modules.cp.cache_files(paths, saltenv='base')
          Used to gather many files from the Master,  the  gathered  files
          will  be  saved  in  the minion cachedir reflective to the paths
          retrieved from the Master

          CLI Example:

             salt '*' cp.cache_files salt://pathto/file1,salt://pathto/file1

          There are  two  ways  of  defining  the  fileserver  environment
          (a.k.a.   saltenv)  from which to cache the files. One is to use
          the saltenv parameter, and the other is  to  use  a  querystring
          syntax   in   the  salt://  URL.  The  below  two  examples  are
          equivalent:

             salt '*' cp.cache_files salt://foo/bar.conf,salt://foo/baz.conf saltenv=config
             salt '*' cp.cache_files salt://foo/bar.conf?saltenv=config,salt://foo/baz.conf?saltenv=config

          The querystring method is less useful when all files  are  being
          cached  from  the same environment, but is a good way of caching
          files from multiple different environments in the same  command.
          For  example,  the  below command will cache the first file from
          the config1 environment, and the second  one  from  the  config2
          environment.

             salt '*' cp.cache_files salt://foo/bar.conf?saltenv=config1,salt://foo/bar.conf?saltenv=config2

          NOTE:
             It  may  be  necessary  to  quote  the  URL  when  using  the
             querystring method, depending on the shell being used to  run
             the command.

   salt.modules.cp.cache_local_file(path)
          Cache a local file on the minion in the localfiles cache

          CLI Example:

             salt '*' cp.cache_local_file /etc/hosts

   salt.modules.cp.cache_master(saltenv='base')
          Retrieve all of the files on the master and cache them locally

          CLI Example:

             salt '*' cp.cache_master

   salt.modules.cp.get_dir(path,   dest,   saltenv='base',  template=None,
   gzip=None, **kwargs)
          Used to recursively copy a directory from the salt master

          CLI Example:

             salt '*' cp.get_dir salt://path/to/dir/ /minion/dest

          get_dir  supports  the  same  template  and  gzip  arguments  as
          get_file.

   salt.modules.cp.get_file(path,  dest,  saltenv='base',  makedirs=False,
   template=None, gzip=None, **kwargs)
          Used to get a single file from the salt master

          CLI Example:

             salt '*' cp.get_file salt://path/to/file /minion/dest

          Template rendering  can  be  enabled  on  both  the  source  and
          destination file names like so:

             salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja

          This  example  would  instruct  all Salt minions to download the
          vimrc from a directory with the same name as their os grain  and
          copy it to /etc/vimrc

          For  larger  files,  the  cp.get_file  module also supports gzip
          compression.  Because gzip is CPU-intensive, this should only be
          used in scenarios where the compression ratio is very high (e.g.
          pretty-printed JSON or YAML files).

          Use the gzip named argument to  enable  it.   Valid  values  are
          1..9, where 1 is the lightest compression and 9 the heaviest.  1
          uses the least CPU on the master (and minion), 9 uses the most.

          There are  two  ways  of  defining  the  fileserver  environment
          (a.k.a.  saltenv) from which to retrieve the file. One is to use
          the saltenv parameter, and the other is  to  use  a  querystring
          syntax   in   the  salt://  URL.  The  below  two  examples  are
          equivalent:

             salt '*' cp.get_file salt://foo/bar.conf /etc/foo/bar.conf saltenv=config
             salt '*' cp.get_file salt://foo/bar.conf?saltenv=config /etc/foo/bar.conf

          NOTE:
             It  may  be  necessary  to  quote  the  URL  when  using  the
             querystring  method, depending on the shell being used to run
             the command.

   salt.modules.cp.get_file_str(path, saltenv='base')
          Download a file from a URL to the  Minion  cache  directory  and
          return the contents of that file

          Returns False if Salt was unable to cache a file from a URL.

          CLI Example:

             salt '*' cp.get_file_str salt://my/file

   salt.modules.cp.get_template(path,        dest,       template='jinja',
   saltenv='base', makedirs=False, **kwargs)
          Render a file as a template before setting  it  down.   Warning,
          order  is  not the same as in fileclient.cp for non breaking old
          API.

          CLI Example:

             salt '*' cp.get_template salt://path/to/template /minion/dest

   salt.modules.cp.get_url(path, dest='', saltenv='base', makedirs=False)
          Used to get a single file from a URL.

          path   A URL to download a file from. Supported URL schemes are:
                 salt://,  http://,  https://, ftp://, s3://, swift:// and
                 file:// (local filesystem). If no scheme  was  specified,
                 this is equivalent of using file://.  If a file:// URL is
                 given, the function just returns absolute  path  to  that
                 file  on  a local filesystem.  The function returns False
                 if Salt was unable to fetch a file from a salt:// URL.

          dest   The default behaviour is to write the fetched file to the
                 given  destination  path. If this parameter is omitted or
                 set as empty string (''), the function places the  remote
                 file  on  the  local  filesystem  inside the Minion cache
                 directory and returns the path to that file.

                 NOTE:
                    To  simply  return  the  file  contents  instead,  set
                    destination to None. This works with salt://, http://,
                    https://  and  file://  URLs.  The  files  fetched  by
                    http:// and https:// will not be cached.

          saltenv
                 base  Salt  fileserver envrionment from which to retrieve
                 the file. Ignored if path is not a salt:// URL.

          CLI Example:

             salt '*' cp.get_url salt://my/file /tmp/this_file_is_mine
             salt '*' cp.get_url http://www.slashdot.org /tmp/index.html

   salt.modules.cp.hash_file(path, saltenv='base')
          Return the hash of a file, to get the hash of a file on the salt
          master file server prepend the path with salt://<file on server>
          otherwise, prepend the file with / for a local file.

          CLI Example:

             salt '*' cp.hash_file salt://path/to/file

   salt.modules.cp.is_cached(path, saltenv='base')
          Return a boolean if the given path on the master has been cached
          on the minion

          CLI Example:

             salt '*' cp.is_cached salt://path/to/file

   salt.modules.cp.list_master(saltenv='base', prefix='')
          List all of the files stored on the master

          CLI Example:

             salt '*' cp.list_master

   salt.modules.cp.list_master_dirs(saltenv='base', prefix='')
          List all of the directories stored on the master

          CLI Example:

             salt '*' cp.list_master_dirs

   salt.modules.cp.list_master_symlinks(saltenv='base', prefix='')
          List all of the symlinks stored on the master

          CLI Example:

             salt '*' cp.list_master_symlinks

   salt.modules.cp.list_minion(saltenv='base')
          List all of the files cached on the minion

          CLI Example:

             salt '*' cp.list_minion

   salt.modules.cp.list_states(saltenv='base')
          List all of the available state modules in an environment

          CLI Example:

             salt '*' cp.list_states

   salt.modules.cp.push(path,    keep_symlinks=False,    upload_path=None,
   remove_source=False)
          WARNING Files  pushed  to  the  master  will  have  global  read
          permissions..

          Push  a  file from the minion up to the master, the file will be
          saved to the salt master in the master's minion  files  cachedir
          (defaults to /var/cache/salt/master/minions/minion-id/files)

          Since  this  feature  allows  a  minion to push a file up to the
          master server it is disabled by default for  security  purposes.
          To  enable,  set  file_recv  to True in the master configuration
          file, and restart the master.

          keep_symlinks
                 Keep the path value without resolving its canonical form

          upload_path
                 Provide a different path inside the master's minion files
                 cachedir

          remove_source
                 Remove the source file on the minion

                 New in version 2016.3.0.

          CLI Example:

             salt '*' cp.push /etc/fstab
             salt '*' cp.push /etc/system-release keep_symlinks=True
             salt '*' cp.push /etc/fstab upload_path='/new/path/fstab'
             salt '*' cp.push /tmp/filename remove_source=True

   salt.modules.cp.push_dir(path, glob=None, upload_path=None)
          Push  a  directory  from  the minion up to the master, the files
          will be saved to the salt master in the  master's  minion  files
          cachedir                       (defaults                      to
          /var/cache/salt/master/minions/minion-id/files).  It also has  a
          glob for matching specific files using globbing.

          New in version 2014.7.0.

          Since  this  feature  allows  a  minion  to push files up to the
          master server it is disabled by default for  security  purposes.
          To  enable,  set  file_recv  to True in the master configuration
          file, and restart the master.

          upload_path
                 Provide a different path and directory  name  inside  the
                 master's minion files cachedir

          CLI Example:

             salt '*' cp.push /usr/lib/mysql
             salt '*' cp.push /usr/lib/mysql upload_path='/newmysql/path'
             salt '*' cp.push_dir /etc/modprobe.d/ glob='*.conf'

   salt.modules.cp.recv(files, dest)
          Used with salt-cp, pass the files dict, and the destination.

          This function receives small fast copy files from the master via
          salt-cp.  It does not work via the CLI.

   salt.modules.cpan
   Manage Perl modules using CPAN

   New in version 2015.5.0.

   salt.modules.cpan.install(module)
          Install a Perl module from CPAN

          CLI Example:

             salt '*' cpan.install Template::Alloy

   salt.modules.cpan.list()
          List installed Perl modules, and the version installed

          CLI Example:

             salt '*' cpan.list

   salt.modules.cpan.remove(module, details=False)
          Attempt to remove a Perl module that was  installed  from  CPAN.
          Because    the    cpan    command   doesn't   actually   support
          "uninstall"-like functionality, this function will attempt to do
          what it can, with what it has from CPAN.

          Until this function is declared stable, USE AT YOUR OWN RISK!

          CLI Example:

             salt '*' cpan.remove Old::Package

   salt.modules.cpan.show(module)
          Show information about a specific Perl module

          CLI Example:

             salt '*' cpan.show Template::Alloy

   salt.modules.cpan.show_config()
          Return a dict of CPAN configuration values

          CLI Example:

             salt '*' cpan.show_config

   salt.modules.cron
   Work with cron

   NOTE:
      Salt  does  not escape cron metacharacters automatically. You should
      backslash-escape percent characters  and  any  other  metacharacters
      that might be interpreted incorrectly by the shell.

   salt.modules.cron.list_tab(user)
          Return the contents of the specified user's crontab

          CLI Example:

             salt '*' cron.list_tab root

   salt.modules.cron.ls(user)
          This function is an alias of list_tab.
             Return the contents of the specified user's crontab

             CLI Example:

                 salt '*' cron.list_tab root

   salt.modules.cron.raw_cron(user)
          Return the contents of the user's crontab

          CLI Example:

             salt '*' cron.raw_cron root

   salt.modules.cron.rm(user,  cmd, minute=None, hour=None, daymonth=None,
   month=None, dayweek=None, identifier=None)
          This function is an alias of rm_job.
             Remove a cron job  for  a  specified  user.  If  any  of  the
             day/time  params  are specified, the job will only be removed
             if the specified params match.

             CLI Example:

                 salt '*' cron.rm_job root /usr/local/weekly
                 salt '*' cron.rm_job root /usr/bin/foo dayweek=1

   salt.modules.cron.rm_env(user, name)
          Remove cron environment variable for a specified user.

          CLI Example:

             salt '*' cron.rm_env root MAILTO

   salt.modules.cron.rm_job(user,     cmd,     minute=None,     hour=None,
   daymonth=None, month=None, dayweek=None, identifier=None)
          Remove  a  cron job for a specified user. If any of the day/time
          params are specified, the  job  will  only  be  removed  if  the
          specified params match.

          CLI Example:

             salt '*' cron.rm_job root /usr/local/weekly
             salt '*' cron.rm_job root /usr/bin/foo dayweek=1

   salt.modules.cron.rm_special(user, special, cmd)
          Remove a special cron job for a specified user.

          CLI Example:

             salt '*' cron.rm_job root @hourly /usr/bin/foo

   salt.modules.cron.set_env(user, name, value=None)
          Set up an environment variable in the crontab.

          CLI Example:

             salt '*' cron.set_env root MAILTO [email protected]

   salt.modules.cron.set_job(user, minute, hour, daymonth, month, dayweek,
   cmd, commented=False, comment=None, identifier=None)
          Sets a cron job up for a specified user.

          CLI Example:

             salt '*' cron.set_job root '*' '*' '*' '*' 1 /usr/local/weekly

   salt.modules.cron.set_special(user, special, cmd)
          Set up a special command in the crontab.

          CLI Example:

             salt '*' cron.set_special root @hourly 'echo foobar'

   salt.modules.cron.write_cron_file(user, path)
          Writes the contents of a file to a user's crontab

          CLI Example:

             salt '*' cron.write_cron_file root /tmp/new_cron

          Changed in version 2015.8.9.

          NOTE:
             Solaris and AIX require that path is readable by user

   salt.modules.cron.write_cron_file_verbose(user, path)
          Writes the contents of a file to a  user's  crontab  and  return
          error message on error

          CLI Example:

             salt '*' cron.write_cron_file_verbose root /tmp/new_cron

          Changed in version 2015.8.9.

          NOTE:
             Solaris and AIX require that path is readable by user

   salt.modules.csf
   Support for Config Server Firewall (CSF)
   maintainer
          Mostafa Hussein <[email protected]>

   maturity
          new

   platform
          Linux

   salt.modules.csf.allow(ip,   port=None,   proto='tcp',  direction='in',
   port_origin='d', ip_origin='s', ttl=None, comment='')
          Add an rule to csf allowed hosts See _access_rule().  1- Add  an
          IP: CLI Example:

             salt '*' csf.allow 127.0.0.1
             salt '*' csf.allow 127.0.0.1 comment="Allow localhost"

   salt.modules.csf.allow_port(port, proto='tcp', direction='both')
          Like  allow_ports,  but  it  will  append  to the existing entry
          instead of replacing it.  Takes a single port instead of a  list
          of ports.

          CLI Example:

             salt '*' csf.allow_port 22 proto='tcp' direction='in'

   salt.modules.csf.allow_ports(ports, proto='tcp', direction='in')
          Fully  replace  the  incoming  or  outgoing  ports  line  in the
          csf.conf file - e.g. TCP_IN, TCP_OUT, UDP_IN, UDP_OUT, etc.

          CLI Example:

             salt '*' csf.allow_ports ports="[22,80,443,4505,4506]" proto='tcp' direction='in'

   salt.modules.csf.deny(ip,   port=None,   proto='tcp',   direction='in',
   port_origin='d', ip_origin='d', ttl=None, comment='')
          Add  an rule to csf denied hosts See _access_rule().  1- Deny an
          IP: CLI Example:

             salt '*' csf.deny 127.0.0.1
             salt '*' csf.deny 127.0.0.1 comment="Too localhosty"

   salt.modules.csf.disable()
          Disable csf permanently CLI Example:

             salt '*' csf.disable

   salt.modules.csf.enable()
          Activate csf if not running CLI Example:

             salt '*' csf.enable

   salt.modules.csf.exists(method,     ip,     port=None,     proto='tcp',
   direction='in', port_origin='d', ip_origin='d', ttl=None, comment='')
          Returns  true  a  rule  for  the  ip already exists based on the
          method supplied. Returns false if not found.  CLI Example:

             salt '*' csf.exists allow 1.2.3.4
             salt '*' csf.exists tempdeny 1.2.3.4

   salt.modules.csf.get_ports(proto='tcp', direction='in')
          Lists ports from csf.conf based on direction and protocol.  e.g.
          - TCP_IN, TCP_OUT, UDP_IN, UDP_OUT, etc..

          CLI Example:

             salt '*' csf.allow_port 22 proto='tcp' direction='in'

   salt.modules.csf.reload()
          Restart csf CLI Example:

             salt '*' csf.reload

   salt.modules.csf.running()
          Check csf status CLI Example:

             salt '*' csf.running

   salt.modules.csf.tempallow(ip=None,         ttl=None,        port=None,
   direction=None, comment='')
          Add an rule to the temporary ip allow list.  See _access_rule().
          1- Add an IP: CLI Example:

             salt '*' csf.tempallow 127.0.0.1 3600 port=22 direction='in' comment='# Temp dev ssh access'

   salt.modules.csf.tempdeny(ip=None, ttl=None, port=None, direction=None,
   comment='')
          Add a rule to the temporary ip deny list.   See  _access_rule().
          1- Add an IP: CLI Example:

             salt '*' csf.tempdeny 127.0.0.1 300 port=22 direction='in' comment='# Brute force attempt'

   salt.modules.csf.unallow(ip)
          Remove  a rule from the csf denied hosts See _access_rule().  1-
          Deny an IP: CLI Example:

             salt '*' csf.unallow 127.0.0.1

   salt.modules.csf.undeny(ip)
          Remove a rule from the csf denied hosts See _access_rule().   1-
          Deny an IP: CLI Example:

             salt '*' csf.undeny 127.0.0.1

   salt.modules.cyg
   Manage cygwin packages.

   Module file to accompany the cyg state.

   salt.modules.cyg.check_valid_package(package,        cyg_arch='x86_64',
   mirrors=None)
          Check if the package is valid on the given mirrors.

          Parameters

                 * package -- The name of the package

                 * cyg_arch -- The cygwin architecture

                 * mirrors -- any mirrors to check

          Returns (bool): True if Valid, otherwise False

          CLI Example:

             salt '*' cyg.check_valid_package <package name>

   salt.modules.cyg.install(packages=None,              cyg_arch='x86_64',
   mirrors=None)
          Install one or several packages.

          packages
                 None The packages to install

          cyg_arch
                 x86_64  Specify  the  architecture to install the package
                 under Current options are x86 and x86_64

          CLI Example:

             salt '*' cyg.install dos2unix
             salt '*' cyg.install dos2unix mirrors=[{'http://mirror': 'http://url/to/public/key}]

   salt.modules.cyg.list(package='', cyg_arch='x86_64')
          List locally installed packages.

          package
                 '' package name to check. else all

          cyg_arch :
                 Cygwin architecture to use Options are x86 and x86_64

          CLI Example:

             salt '*' cyg.list

   salt.modules.cyg.uninstall(packages, cyg_arch='x86_64', mirrors=None)
          Uninstall one or several packages.

          packages
                 The packages to uninstall.

          cyg_arch
                 x86_64 Specify the architecture  to  remove  the  package
                 from Current options are x86 and x86_64

          CLI Example:

             salt '*' cyg.uninstall dos2unix
             salt '*' cyg.uninstall dos2unix mirrors=[{'http://mirror': 'http://url/to/public/key}]

   salt.modules.cyg.update(cyg_arch='x86_64', mirrors=None)
          Update all packages.

          cyg_arch
                 x86_64  Specify  the  cygwin  architecture update Current
                 options are x86 and x86_64

          CLI Example:

             salt '*' cyg.update
             salt '*' cyg.update dos2unix mirrors=[{'http://mirror': 'http://url/to/public/key}]

   salt.modules.daemontools
   daemontools service module. This module will  create  daemontools  type
   service watcher.

   This module is compatible with the service states, so it can be used to
   maintain services using the provider argument:

      myservice:
        service.running:
          - provider: daemontools

   salt.modules.daemontools.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' daemontools.available foo

   salt.modules.daemontools.disabled(name)
          Return True if the named service is enabled, false otherwise

          New in version 2015.5.6.

          CLI Example:

             salt '*' daemontools.disabled <service name>

   salt.modules.daemontools.enabled(name, **kwargs)
          Return  True  if the named service is enabled, false otherwise A
          service is considered enabled if in your service directory: - an
          executable ./run file exist - a file named "down" does not exist

          New in version 2015.5.7.

          name   Service name

          CLI Example:

             salt '*' daemontools.enabled <service name>

   salt.modules.daemontools.full_restart(name)
          Calls daemontools.restart() function

          CLI Example:

             salt '*' daemontools.full_restart <service name>

   salt.modules.daemontools.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' daemontools.get_all

   salt.modules.daemontools.missing(name)
          The  inverse  of  daemontools.available.   Returns  True  if the
          specified service is not available, otherwise returns False.

          CLI Example:

             salt '*' daemontools.missing foo

   salt.modules.daemontools.reload(name)
          Wrapper for term()

          CLI Example:

             salt '*' daemontools.reload <service name>

   salt.modules.daemontools.restart(name)
          Restart service via daemontools. This will stop/start service

          CLI Example:

             salt '*' daemontools.restart <service name>

   salt.modules.daemontools.start(name)
          Starts service via daemontools

          CLI Example:

             salt '*' daemontools.start <service name>

   salt.modules.daemontools.status(name, sig=None)
          Return the status for a service via daemontools, return  pid  if
          running

          CLI Example:

             salt '*' daemontools.status <service name>

   salt.modules.daemontools.stop(name)
          Stops service via daemontools

          CLI Example:

             salt '*' daemontools.stop <service name>

   salt.modules.daemontools.term(name)
          Send a TERM to service via daemontools

          CLI Example:

             salt '*' daemontools.term <service name>

   salt.modules.data
   Manage  a  local  persistent data structure that can hold any arbitrary
   data specific to the minion

   salt.modules.data.cas(key, value, old_value)
          Check and set a value in the minion datastore

          CLI Example:

             salt '*' data.cas <key> <value> <old_value>

   salt.modules.data.clear()
          Clear out all of the data in the minion datastore, this function
          is destructive!

          CLI Example:

             salt '*' data.clear

   salt.modules.data.dump(new_data)
          Replace the entire datastore with a passed data structure

          CLI Example:

             salt '*' data.dump '{'eggs': 'spam'}'

   salt.modules.data.get(key, default=None)
          Get a (list of) value(s) from the minion datastore

          New in version 2015.8.0.

          CLI Example:

             salt '*' data.get key
             salt '*' data.get '["key1", "key2"]'

   salt.modules.data.has_key(key)
          Check if key is in the minion datastore

          New in version 2015.8.0.

          CLI Example:

             salt '*' data.has_key <mykey>

   salt.modules.data.items()
          Get items from the minion datastore

          New in version 2015.8.0.

          CLI Example:

             salt '*' data.items

   salt.modules.data.keys()
          Get all keys from the minion datastore

          New in version 2015.8.0.

          CLI Example:

             salt '*' data.keys

   salt.modules.data.load()
          Return all of the data in the minion datastore

          CLI Example:

             salt '*' data.load

   salt.modules.data.pop(key, default=None)
          Pop (return & delete) a value from the minion datastore

          New in version 2015.5.2.

          CLI Example:

             salt '*' data.pop <key> "there was no val"

   salt.modules.data.update(key, value)
          Update a key with a value in the minion datastore

          CLI Example:

             salt '*' data.update <key> <value>

   salt.modules.data.values()
          Get values from the minion datastore

          New in version 2015.8.0.

          CLI Example:

             salt '*' data.values

   salt.modules.ddns
   Support for RFC 2136 dynamic DNS updates.

   depends

          * dnspython Python module

   configuration
          If you want to use TSIG authentication for the server, there are
          a couple of optional configuration parameters made available  to
          support this (the keyname is only needed if the keyring contains
          more than one key):

             keyfile: keyring file (default=None)
             keyname: key name in file (default=None)
             keyalgorithm: algorithm used to create the key
                           (default='HMAC-MD5.SIG-ALG.REG.INT').
                 Other possible values: hmac-sha1, hmac-sha224, hmac-sha256,
                     hmac-sha384, hmac-sha512

          The keyring file needs to be in json format  and  the  key  name
          needs to end with an extra period in the file, similar to this:

             {"keyname.": "keycontent"}

   salt.modules.ddns.add_host(zone, name, ttl, ip, nameserver='127.0.0.1',
   replace=True, timeout=5, port=53, **kwargs)
          Add, replace, or update the A and PTR (reverse)  records  for  a
          host.

          CLI Example:

             salt ns1 ddns.add_host example.com host1 60 10.1.1.1

   salt.modules.ddns.delete(zone,     name,     rdtype=None,    data=None,
   nameserver='127.0.0.1', timeout=5, port=53, **kwargs)
          Delete a DNS record.

          CLI Example:

             salt ns1 ddns.delete example.com host1 A

   salt.modules.ddns.delete_host(zone,    name,    nameserver='127.0.0.1',
   timeout=5, port=53, **kwargs)
          Delete the forward and reverse records for a host.

          Returns true if any records are deleted.

          CLI Example:

             salt ns1 ddns.delete_host example.com host1

   salt.modules.ddns.update(zone,     name,     ttl,     rdtype,     data,
   nameserver='127.0.0.1', timeout=5, replace=False, port=53, **kwargs)
          Add, replace, or update a DNS record.  nameserver must be an  IP
          address  and  the  minion  running  this module must have update
          privileges on that server.  If replace is  true,  first  deletes
          all records for this name and type.

          CLI Example:

             salt ns1 ddns.update example.com host1 60 A 10.0.0.1

   salt.modules.deb_apache
   Support for Apache

   Please note: The functions in here are Debian-specific. Placing them in
   this separate file  will  allow  them  to  load  only  on  Debian-based
   systems, while still loading under the apache namespace.

   salt.modules.deb_apache.a2disconf(conf)
          New in version 2016.3.0.

          Runs a2disconf for the given conf.

          This  will  only be functional on Debian-based operating systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2disconf security

   salt.modules.deb_apache.a2dismod(mod)
          Runs a2dismod for the given mod.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2dismod vhost_alias

   salt.modules.deb_apache.a2dissite(site)
          Runs a2dissite for the given site.

          This  will  only be functional on Debian-based operating systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2dissite example.com

   salt.modules.deb_apache.a2enconf(conf)
          New in version 2016.3.0.

          Runs a2enconf for the given conf.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2enconf security

   salt.modules.deb_apache.a2enmod(mod)
          Runs a2enmod for the given mod.

          This  will  only be functional on Debian-based operating systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2enmod vhost_alias

   salt.modules.deb_apache.a2ensite(site)
          Runs a2ensite for the given site.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.a2ensite example.com

   salt.modules.deb_apache.check_conf_enabled(conf)
          New in version 2016.3.0.

          Checks   to   see   if   the   specific   conf   symlink  is  in
          /etc/apache2/conf-enabled.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.check_conf_enabled security
             salt '*' apache.check_conf_enabled security.conf

   salt.modules.deb_apache.check_mod_enabled(mod)
          Checks   to   see   if   the   specific   mod   symlink   is  in
          /etc/apache2/mods-enabled.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.check_mod_enabled status
             salt '*' apache.check_mod_enabled status.load
             salt '*' apache.check_mod_enabled status.conf

   salt.modules.deb_apache.check_site_enabled(site)
          Checks   to   see   if   the   specific   site   symlink  is  in
          /etc/apache2/sites-enabled.

          This will only be functional on Debian-based  operating  systems
          (Ubuntu, Mint, etc).

          CLI Examples:

             salt '*' apache.check_site_enabled example.com
             salt '*' apache.check_site_enabled example.com.conf

   salt.modules.deb_postgres
   Module  to  provide  Postgres  compatibility  to salt for debian family
   specific tools.

   salt.modules.deb_postgres.cluster_create(version,          name='main',
   port=None, locale=None, encoding=None, datadir=None)
          Adds a cluster to the Postgres server.

          CLI Example:

             salt '*' postgres.cluster_create '9.3'

             salt '*' postgres.cluster_create '9.3' 'main'

             salt '*' postgres.cluster_create '9.3' locale='fr_FR'

   salt.modules.deb_postgres.cluster_exists(version, name='main')
          Checks if a given version and name of a cluster exists.

          CLI Example:

             salt '*' postgres.cluster_exists '9.3'

             salt '*' postgres.cluster_exists '9.3' 'main'

   salt.modules.deb_postgres.cluster_list(verbose=False)
          Return  a  list of cluster of Postgres server (tuples of version
          and name).

          CLI Example:

             salt '*' postgres.cluster_list

             salt '*' postgres.cluster_list verbose=True

   salt.modules.deb_postgres.cluster_remove(version,          name='main',
   stop=False)
          Remove a cluster on a Postgres server. By default it doesn't try
          to stop the cluster.

          CLI Example:

             salt '*' postgres.cluster_remove '9.3'

             salt '*' postgres.cluster_remove '9.3' 'main'

             salt '*' postgres.cluster_remove '9.3' 'main' stop=True

   salt.modules.debbuild
   Debian Package builder system

   New in version 2015.8.0.

   This system allows for all of the components to build  debs  safely  in
   chrooted environments. This also provides a function to generate debian
   repositories

   This module implements the pkgbuild interface

   salt.modules.debbuild.build(runas, tgt, dest_dir, spec, sources,  deps,
   env, template, saltenv='base', log_dir='/var/log/salt/pkgbuild')
          Given  the package destination directory, the tarball containing
          debian files (e.g. control) and package sources, use pbuilder to
          safely build the platform package

          CLI Example:

          Debian

             salt '*' pkgbuild.make_src_pkg deb-8-x86_64 /var/www/html https://raw.githubusercontent.com/saltstack/libnacl/master/pkg/deb/python-libnacl.control https://pypi.python.org/packages/source/l/libnacl/libnacl-1.3.5.tar.gz

          This example command should build the libnacl package for Debian
          using pbuilder and place it in /var/www/html/ on the minion

   salt.modules.debbuild.make_repo(repodir,     keyid=None,      env=None,
   use_passphrase=False,    gnupghome='/etc/salt/gpgkeys',   runas='root',
   timeout=15.0)
          Make a package repository and optionally sign  it  and  packages
          present

          Given  the repodir (directory to create repository in), create a
          Debian repository and optionally sign it and  packages  present.
          This  state  is  best used with onchanges linked to your package
          building states.

          repodir
                 The directory to  find  packages  that  will  be  in  the
                 repository.

          keyid  Changed in version 2016.3.0.

                 Optional   Key   ID   to  use  in  signing  packages  and
                 repository.  Utilizes Public and Private keys  associated
                 with  keyid  which  have  been  loaded  into the minion's
                 Pillar      data.      Leverages      gpg-agent       and
                 gpg-preset-passphrase for caching keys, etc.

                 For  example, contents from a Pillar data file with named
                 Public and Private keys as follows:

                    gpg_pkg_priv_key: |
                      -----BEGIN PGP PRIVATE KEY BLOCK-----
                      Version: GnuPG v1

                      lQO+BFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      Ebe+8JCQTwqSXPRTzXmy/b5WXDeM79CkLWvuGpXFor76D+ECMRPv/rawukEcNptn
                      R5OmgHqvydEnO4pWbn8JzQO9YX/Us0SMHBVzLC8eIi5ZIopzalvX
                      =JvW8

                      -----END PGP PRIVATE KEY BLOCK-----
                    gpg_pkg_priv_keyname: gpg_pkg_key.pem

                    gpg_pkg_pub_key: |
                      -----BEGIN PGP PUBLIC KEY BLOCK-----
                      Version: GnuPG v1

                      mQENBFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      bYP7t5iwJmQzRMyFInYRt77wkJBPCpJc9FPNebL9vlZcN4zv0KQta+4alcWivvoP
                      4QIxE+/+trC6QRw2m2dHk6aAeq/J0Sc7ilZufwnNA71hf9SzRIwcFXMsLx4iLlki
                      inNqW9c=
                      =s1CX

                      -----END PGP PUBLIC KEY BLOCK-----
                    gpg_pkg_pub_keyname: gpg_pkg_key.pub

          env    Changed in version 2016.3.0.

                 A dictionary of environment variables to be  utilized  in
                 creating the repository.

          use_passphrase
                 False New in version 2016.3.0.

                 Use a passphrase with the signing key presented in keyid.
                 Passphrase is received from Pillar data  which  could  be
                 passed  on  the  command  line with pillar parameter. For
                 example:

                    pillar='{ "gpg_passphrase" : "my_passphrase" }'

          gnupghome
                 /etc/salt/gpgkeys New in version 2016.3.0.

                 Location where GPG related files are  stored,  used  with
                 keyid.

          runas  root New in version 2016.3.0.

                 User  to  create  the  repository as, and optionally sign
                 packages.

                 NOTE:
                    Ensure the user has correct permissions to  any  files
                    and directories which are to be utilized.

          timeout
                 15.0 New in version 2016.3.4.

                 Timeout  in  seconds to wait for the prompt for inputting
                 the passphrase.

          CLI Example:

             salt '*' pkgbuild.make_repo /var/www/html

   salt.modules.debbuild.make_src_pkg(dest_dir, spec,  sources,  env=None,
   template=None, saltenv='base')
          Create  a  platform  specific  source  package  from  the  given
          platform spec/control file and sources

          CLI Example:

          Debian

             salt '*' pkgbuild.make_src_pkg /var/www/html/ https://raw.githubusercontent.com/saltstack/libnacl/master/pkg/deb/python-libnacl.control.tar.xz https://pypi.python.org/packages/source/l/libnacl/libnacl-1.3.5.tar.gz

          This example command should build the libnacl SOURCE package and
          place it in /var/www/html/ on the minion

   salt.modules.debconfmod
   Support for Debconf

   salt.modules.debconfmod.get_selections(fetchempty=True)
          Answers  to  debconf questions for all packages in the following
          format:

             {'package': [['question', 'type', 'value'], ...]}

          CLI Example:

             salt '*' debconf.get_selections

   salt.modules.debconfmod.set(package, question, type, value, *extra)
          Set answers to debconf questions for a package.

          CLI Example:

             salt '*' debconf.set <package> <question> <type> <value> [<value> ...]

   salt.modules.debconfmod.set_file(path, saltenv='base', **kwargs)
          Set answers to debconf questions from a file.

          CLI Example:

             salt '*' debconf.set_file salt://pathto/pkg.selections

   salt.modules.debconfmod.set_template(path, template, context, defaults,
   saltenv='base', **kwargs)
          Set answers to debconf questions from a template.

          path   location of the file containing the package selections

          template
                 template format

          context
                 variables to add to the template environment

          default
                 default values for the template environment

          CLI Example:

             salt '*' debconf.set_template salt://pathto/pkg.selections.jinja jinja None None

   salt.modules.debconfmod.show(name)
          Answers  to  debconf  questions  for  a package in the following
          format:

             [['question', 'type', 'value'], ...]

          If debconf doesn't know about a package, we return None.

          CLI Example:

             salt '*' debconf.show <package name>

   salt.modules.debian_ip
   The networking module for Debian based distros

   References:

   * http://www.debian.org/doc/manuals/debian-reference/ch05.en.html

   salt.modules.debian_ip.apply_network_settings(**settings)
          Apply global network configuration.

          CLI Example:

             salt '*' ip.apply_network_settings

   salt.modules.debian_ip.build_bond(iface, **settings)
          Create a bond script in /etc/modprobe.d with the passed settings
          and load the bonding kernel module.

          CLI Example:

             salt '*' ip.build_bond bond0 mode=balance-alb

   salt.modules.debian_ip.build_interface(iface,    iface_type,   enabled,
   **settings)
          Build an interface script for a network interface.

          CLI Example:

             salt '*' ip.build_interface eth0 eth <settings>

   salt.modules.debian_ip.build_network_settings(**settings)
          Build the global network script.

          CLI Example:

             salt '*' ip.build_network_settings <settings>

   salt.modules.debian_ip.build_routes(iface, **settings)
          Add route scripts for a network interface using up commands.

          CLI Example:

             salt '*' ip.build_routes eth0 <settings>

   salt.modules.debian_ip.down(iface, iface_type)
          Shutdown a network interface

          CLI Example:

             salt '*' ip.down eth0 eth

   salt.modules.debian_ip.get_bond(iface)
          Return the content of a bond script

          CLI Example:

             salt '*' ip.get_bond bond0

   salt.modules.debian_ip.get_interface(iface)
          Return the contents of an interface script

          CLI Example:

             salt '*' ip.get_interface eth0

   salt.modules.debian_ip.get_network_settings()
          Return the contents of the global network script.

          CLI Example:

             salt '*' ip.get_network_settings

   salt.modules.debian_ip.get_routes(iface)
          Return the routes for the interface

          CLI Example:

             salt '*' ip.get_routes eth0

   salt.modules.debian_ip.up(iface, iface_type)
          Start up a network interface

          CLI Example:

             salt '*' ip.up eth0 eth

   salt.modules.debian_service
   Service support for Debian systems (uses update-rc.d and /sbin/service)

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   salt.modules.debian_service.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.debian_service.disable(name, **kwargs)
          Disable the named service to start at boot

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.debian_service.disabled(name)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.debian_service.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.debian_service.enabled(name, **kwargs)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.debian_service.force_reload(name)
          Force-reload the named service

          CLI Example:

             salt '*' service.force_reload <service name>

   salt.modules.debian_service.get_all()
          Return all available boot services

          CLI Example:

             salt '*' service.get_all

   salt.modules.debian_service.get_disabled()
          Return a set of services that are installed but disabled

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.debian_service.get_enabled()
          Return a list of service that are enabled on boot

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.debian_service.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.debian_service.reload(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.debian_service.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.debian_service.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.debian_service.status(name, sig=None)
          Return the status for a service, pass a signature to use to find
          the service via ps

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.debian_service.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.defaults
   salt.modules.defaults.get(key, default='')
          defaults.get  is  used  much like pillar.get except that it will
          read  a  default  value  for  a  pillar  from  defaults.json  or
          defaults.yaml  files  that  are  stored  in  the  root of a salt
          formula.

          CLI Example:

             salt '*' defaults.get core:users:root

          The defaults is computed from pillar key.  The  first  entry  is
          considered as the formula namespace.

          For   example,   querying   core:users:root  will  try  to  load
          salt://core/defaults.yaml and salt://core/defaults.json.

   salt.modules.defaults.merge(dest, upd)
          Allows deep merging of dicts in formulas.
             CLI Example:

             salt '*' default.merge a=b d=e

          It is more typical to use  this  in  a  templating  language  in
          formulas, instead of directly on the command-line.

   salt.modules.devmap
   Device-Mapper module

   salt.modules.devmap.multipath_flush(device)
          Device-Mapper Multipath flush

          CLI Example:

             salt '*' devmap.multipath_flush mpath1

   salt.modules.devmap.multipath_list()
          Device-Mapper Multipath list

          CLI Example:

             salt '*' devmap.multipath_list

   salt.modules.dig
   Compendium  of generic DNS utilities.  The 'dig' command line tool must
   be installed in order to use this module.

   salt.modules.dig.A(host, nameserver=None)
          Return the A record for host.

          Always returns a list.

          CLI Example:

             salt ns1 dig.A www.google.com

   salt.modules.dig.AAAA(host, nameserver=None)
          Return the AAAA record for host.

          Always returns a list.

          CLI Example:

             salt ns1 dig.AAAA www.google.com

   salt.modules.dig.MX(domain, resolve=False, nameserver=None)
          Return a list of lists for the MX of domain.

          If the resolve argument is True, resolve IPs for the servers.

          It's limited to one IP, because although in practice  it's  very
          rarely  a  round  robin,  it  is an acceptable configuration and
          pulling just one IP lets the data be similar to the non-resolved
          version.  If  you  think  an  MX has multiple IPs, don't use the
          resolver here, resolve them in a separate step.

          CLI Example:

             salt ns1 dig.MX google.com

   salt.modules.dig.NS(domain, resolve=True, nameserver=None)
          Return a list of IPs of the nameservers for domain

          If resolve is False, don't resolve names.

          CLI Example:

             salt ns1 dig.NS google.com

   salt.modules.dig.SPF(domain, record='SPF', nameserver=None)
          Return the allowed IPv4 ranges in the SPF record for domain.

          If record is SPF and the SPF record is  empty,  the  TXT  record
          will  be searched automatically. If you know the domain uses TXT
          and not SPF, specifying that will save a lookup.

          CLI Example:

             salt ns1 dig.SPF google.com

   salt.modules.dig.TXT(host, nameserver=None)
          Return the TXT record for host.

          Always returns a list.

          CLI Example:

             salt ns1 dig.TXT google.com

   salt.modules.dig.check_ip(addr)
          Check if address is a valid IP. returns True if valid, otherwise
          False.

          CLI Example:

             salt ns1 dig.check_ip 127.0.0.1
             salt ns1 dig.check_ip 1111:2222:3333:4444:5555:6666:7777:8888

   salt.modules.disk
   Module for managing disks and blockdevices

   salt.modules.disk.blkid(device=None)
          Return  block device attributes: UUID, LABEL, etc. This function
          only works on systems where blkid is available.

          CLI Example:

             salt '*' disk.blkid
             salt '*' disk.blkid /dev/sda

   salt.modules.disk.dump(device, args=None)
          Return all contents of dumpe2fs for a specified device

          CLI Example:
             salt '*' disk.dump /dev/sda1

   salt.modules.disk.format_(device,   fs_type='ext4',    inode_size=None,
   lazy_itable_init=None, force=False)
          Format a filesystem onto a device

          New in version 2016.11.0.

          device The device in which to create the new filesystem

          fs_type
                 The type of filesystem to create

          inode_size
                 Size of the inodes

                 This option is only enabled for ext and xfs filesystems

          lazy_itable_init
                 If  enabled  and  the  uninit_bg  feature is enabled, the
                 inode table will not  be  fully  initialized  by  mke2fs.
                 This  speeds up filesystem initialization noticeably, but
                 it  requires  the  kernel  to  finish  initializing   the
                 filesystem   in  the  background  when  the filesystem is
                 first mounted.   If  the  option  value  is  omitted,  it
                 defaults to 1 to enable lazy inode table zeroing.

                 This option is only enabled for ext filesystems

          force  Force   mke2fs  to  create  a  filesystem,  even  if  the
                 specified device is not a partition on  a  block  special
                 device.  This  option  is  only  enabled  for ext and xfs
                 filesystems

                 This option is dangerous, use it with caution.

          CLI Example:

             salt '*' disk.format /dev/sdX1

   salt.modules.disk.fstype(device)
          Return the filesystem name of the specified device

          New in version 2016.11.0.

          device The name of the device

          CLI Example:

             salt '*' disk.fstype /dev/sdX1

   salt.modules.disk.hdparms(disks, args=None)
          Retrieve all info's for all disks parse 'em  into  a  nice  dict
          (which, considering hdparms output, is quite a hassle)

          New in version 2016.3.0.

          CLI Example:
             salt '*' disk.hdparms /dev/sda

   salt.modules.disk.hpa(disks, size=None)
          Get/set Host Protected Area settings

          T13  INCITS  346-2001 (1367D) defines the BEER (Boot Engineering
          Extension Record) and PARTIES (Protected Area Run Time Interface
          Extension  Services),  allowing  for  a Host Protected Area on a
          disk.

          It's often used by OEMS  to  hide  parts  of  a  disk,  and  for
          overprovisioning SSD's

          WARNING:
             Setting the HPA might clobber your data, be very careful with
             this on active disks!

          New in version 2016.3.0.

          CLI Example:

             salt '*' disk.hpa /dev/sda
             salt '*' disk.hpa /dev/sda 5%
             salt '*' disk.hpa /dev/sda 10543256

   salt.modules.disk.inodeusage(args=None)
          Return inode usage  information  for  volumes  mounted  on  this
          minion

          CLI Example:

             salt '*' disk.inodeusage

   salt.modules.disk.iostat(interval=1, count=5, disks=None)
          Gather and return (averaged) IO stats.

          New in version 2016.3.0.

          CLI Example:

             salt '*' disk.iostat 1 5 disks=sda

   salt.modules.disk.percent(args=None)
          Return partition information for volumes mounted on this minion

          CLI Example:

             salt '*' disk.percent /var

   salt.modules.disk.resize2fs(device)
          Resizes the filesystem.

          CLI Example:
             salt '*' disk.resize2fs /dev/sda1

   salt.modules.disk.smart_attributes(dev, attributes=None, values=None)
          Fetch  SMART  attributes  Providing attributes will deliver only
          requested  attributes  Providing  values   will   deliver   only
          requested values for attributes

          Default     is     the     Backblaze    recommended    set    (
          https://www.backblaze.com/blog/hard-drive-smart-stats/):
          (5,187,188,197,198)

          New in version 2016.3.0.

          CLI Example:

             salt '*' disk.smart_attributes /dev/sda
             salt '*' disk.smart_attributes /dev/sda attributes=(5,187,188,197,198)

   salt.modules.disk.tune(device, **kwargs)
          Set attributes for the specified device

          CLI Example:

             salt '*' disk.tune /dev/sda1 read-ahead=1024 read-write=True

          Valid options are: read-ahead, filesystem-read-ahead, read-only,
          read-write.

          See the blockdev(8) manpage for a more complete  description  of
          these options.

   salt.modules.disk.usage(args=None)
          Return usage information for volumes mounted on this minion

          CLI Example:

             salt '*' disk.usage

   salt.modules.disk.wipe(device)
          Remove the filesystem information

          CLI Example:

             salt '*' disk.wipe /dev/sda1

   salt.modules.djangomod
   Manage Django sites

   salt.modules.djangomod.collectstatic(settings_module,     bin_env=None,
   no_post_process=False,   ignore=None,    dry_run=False,    clear=False,
   link=False, no_default_ignore=False, pythonpath=None, env=None)
          Collect  static  files  from  each  of  your applications into a
          single location that can easily be served in production.

          CLI Example:

             salt '*' django.collectstatic <settings_module>

   salt.modules.djangomod.command(settings_module, command,  bin_env=None,
   pythonpath=None, env=None, *args, **kwargs)
          Run arbitrary django management command

          CLI Example:

             salt '*' django.command <settings_module> <command>

   salt.modules.djangomod.createsuperuser(settings_module,       username,
   email, bin_env=None, database=None, pythonpath=None, env=None)
          Create a super user for the database.  This function defaults to
          use the --noinput flag which prevents the creation of a password
          for the superuser.

          CLI Example:

             salt '*' django.createsuperuser <settings_module> user [email protected]

   salt.modules.djangomod.loaddata(settings_module,              fixtures,
   bin_env=None, database=None, pythonpath=None, env=None)
          Load fixture data

          Fixtures:
                 comma separated list of fixtures to load

          CLI Example:

             salt '*' django.loaddata <settings_module> <comma delimited list of fixtures>

   salt.modules.djangomod.syncdb(settings_module,            bin_env=None,
   migrate=False, database=None, pythonpath=None, env=None, noinput=True)
          Run syncdb

          Execute the Django-Admin syncdb command, if South  is  available
          on  the  minion the migrate option can be passed as True calling
          the migrations to run after the syncdb completes

          CLI Example:

             salt '*' django.syncdb <settings_module>

   salt.modules.dnsmasq
   Module for managing dnsmasq

   salt.modules.dnsmasq.fullversion()
          Shows installed version of dnsmasq and compile options.

          CLI Example:

             salt '*' dnsmasq.fullversion

   salt.modules.dnsmasq.get_config(config_file='/etc/dnsmasq.conf')
          Dumps all options from the config file.

          config_file
                 The location of the config  file  from  which  to  obtain
                 contents.  Defaults to /etc/dnsmasq.conf.

          CLI Examples:

             salt '*' dnsmasq.get_config
             salt '*' dnsmasq.get_config config_file=/etc/dnsmasq.conf

   salt.modules.dnsmasq.set_config(config_file='/etc/dnsmasq.conf',
   follow=True, **kwargs)
          Sets a value or a set  of  values  in  the  specified  file.  By
          default,  if  conf-dir  is  configured  in  this file, salt will
          attempt to set the option in any file inside the conf-dir  where
          it  has  already been enabled. If it does not find it inside any
          files, it will append it to the main config file. Setting follow
          to False will turn off this behavior.

          If  a  config  option  currently appears multiple times (such as
          dhcp-host, which is specified at least once per host),  the  new
          option will be added to the end of the main config file (and not
          to any includes). If you need an  option  added  to  a  specific
          include file, specify it as the config_file.

          Parameters

                 * config_file  (string)  --  config  file  where settings
                   should be updated / added.

                 * follow (bool) --  attempt  to  set  the  config  option
                   inside  any  file  within  the  conf-dir  where  it has
                   already been enabled.

                 * kwargs  --   key   value   pairs   that   contain   the
                   configuration settings that you want set.

          CLI Examples:

             salt '*' dnsmasq.set_config domain=mydomain.com
             salt '*' dnsmasq.set_config follow=False domain=mydomain.com
             salt '*' dnsmasq.set_config config_file=/etc/dnsmasq.conf domain=mydomain.com

   salt.modules.dnsmasq.version()
          Shows installed version of dnsmasq.

          CLI Example:

             salt '*' dnsmasq.version

   salt.modules.dnsutil
   Compendium of generic DNS utilities

   salt.modules.dnsutil.A(host, nameserver=None)
          Return the A record(s) for host.

          Always returns a list.

          CLI Example:

             salt ns1 dnsutil.A www.google.com

   salt.modules.dnsutil.AAAA(host, nameserver=None)
          Return the AAAA record(s) for host.

          Always returns a list.

          New in version 2014.7.5.

          CLI Example:

             salt ns1 dnsutil.AAAA www.google.com

   salt.modules.dnsutil.MX(domain, resolve=False, nameserver=None)
          Return a list of lists for the MX of domain.

          If the 'resolve' argument is True, resolve IPs for the servers.

          It's  limited  to one IP, because although in practice it's very
          rarely a round robin, it  is  an  acceptable  configuration  and
          pulling just one IP lets the data be similar to the non-resolved
          version. If you think an MX has  multiple  IPs,  don't  use  the
          resolver here, resolve them in a separate step.

          CLI Example:

             salt ns1 dig.MX google.com

   salt.modules.dnsutil.NS(domain, resolve=True, nameserver=None)
          Return a list of IPs of the nameservers for domain

          If 'resolve' is False, don't resolve names.

          CLI Example:

             salt ns1 dig.NS google.com

   salt.modules.dnsutil.SPF(domain, record='SPF', nameserver=None)
          Return the allowed IPv4 ranges in the SPF record for domain.

          If  record  is  SPF  and the SPF record is empty, the TXT record
          will be searched automatically. If you know the domain uses  TXT
          and not SPF, specifying that will save a lookup.

          CLI Example:

             salt ns1 dig.SPF google.com

   salt.modules.dnsutil.check_ip(ip_addr)
          Check that string ip_addr is a valid IP

          CLI Example:

             salt ns1 dig.check_ip 127.0.0.1

   salt.modules.dnsutil.hosts_append(hostsfile='/etc/hosts', ip_addr=None,
   entries=None)
          Append a single line to the /etc/hosts file.

          CLI Example:

             salt '*' dnsutil.hosts_append /etc/hosts 127.0.0.1 ad1.yuk.co,ad2.yuk.co

   salt.modules.dnsutil.hosts_remove(hostsfile='/etc/hosts', entries=None)
          Remove a host from the /etc/hosts file. If doing so will leave a
          line  containing  only  an  IP  address,  then  the line will be
          deleted. This function  will  leave  comments  and  blank  lines
          intact.

          CLI Examples:

             salt '*' dnsutil.hosts_remove /etc/hosts ad1.yuk.co
             salt '*' dnsutil.hosts_remove /etc/hosts ad2.yuk.co,ad1.yuk.co

   salt.modules.dnsutil.parse_hosts(hostsfile='/etc/hosts', hosts=None)
          Parse /etc/hosts file.

          CLI Example:

             salt '*' dnsutil.parse_hosts

   salt.modules.dnsutil.parse_zone(zonefile=None, zone=None)
          Parses  a  zone  file.  Can  be  passed raw zone data on the API
          level.

          CLI Example:

             salt ns1 dnsutil.parse_zone /var/lib/named/example.com.zone

   salt.modules.dnsutil.serial(zone='', update=False)
          Return, store and update a dns serial for your zone files.

          zone: a keyword for a specific zone

          update: store an updated version of the serial in a grain

          If update is False,  the  function  will  retrieve  an  existing
          serial  or  return  the  current  date  if  no serial is stored.
          Nothing will be stored

          If update is True, the function  will  set  the  serial  to  the
          current  date  if  none exist or if the existing serial is for a
          previous date. If a serial for greater than the current date  is
          already stored, the function will increment it.

          This module stores the serial in a grain, you can explicitly set
          the stored value as a grain named dnsserial_<zone_name>.

          CLI Example:

             salt ns1 dnsutil.serial example.com

   salt.modules.dockercompose module
   Module to import docker-compose via saltstack

   New in version 2016.3.0.

   maintainer
          Jean Praloran <[email protected]>

   maturity
          new

   depends
          docker-compose>=1.5

   platform
          all

   Introduction
   This module allows one to deal with docker-compose file in a directory.

   This is  a first version only, the following commands  are  missing  at
   the moment but will be built later on if the community is interested in
   this module:

   * run

   * logs

   * port

   * scale

   Installation Prerequisites
   This  execution  module  requires  at  least  version  1.4.0  of   both
   docker-compose and Docker. docker-compose can easily be installed using
   pip.install:

      salt myminion pip.install docker-compose>=1.5.0

   How to use this module?
   In order to use the module if you have no docker-compose  file  on  the
   server  you  can  issue  the command create, it takes two arguments the
   path where the docker-compose.yml will be stored  and  the  content  of
   this latter:

      # salt-call -l debug dockercompose.create /tmp/toto '
       database:
       image: mongo:3.0
       command: mongod --smallfiles --quiet --logpath=/dev/null
       '

   Then  you  can  execute  a list of method defined at the bottom with at
   least one argument (the path where the docker-compose.yml will be read)
   and an optional python list which corresponds to the services names:

      # salt-call -l debug dockercompose.up /tmp/toto
      # salt-call -l debug dockercompose.restart /tmp/toto '[database]'
      # salt-call -l debug dockercompose.stop /tmp/toto
      # salt-call -l debug dockercompose.rm /tmp/toto

   Docker-compose method supported
   * up

   * restart

   * stop

   * start

   * pause

   * unpause

   * kill

   * rm

   * ps

   * pull

   * build

   Functions
   *

     docker-compose.yml management

            * dockercompose.create

            * dockercompose.get

   *

     Manage containers

            * dockercompose.restart

            * dockercompose.stop

            * dockercompose.pause

            * dockercompose.unpause

            * dockercompose.start

            * dockercompose.kill

            * dockercompose.rm

            * dockercompose.up

   *

     Manage containers image:

            * dockercompose.pull

            * dockercompose.build

   *

     Gather information about containers:

            * dockercompose.ps

   Detailed Function Documentation
   salt.modules.dockercompose.build(path, service_names=None)
          Build   image   for   containers  in  the  docker-compose  file,
          service_names is a python list, if omitted build images for  all
          containers.  Please  note that at the moment the module does not
          allow you to upload your Dockerfile,  nor  any  other  file  you
          could  need  with your docker-compose.yml, you will have to make
          sure the files you need are actually in the directory  specified
          in the build keyword

          path   Path  where  the  docker-compose  file  is  stored on the
                 server

          service_names
                 If specified will pull only the image for  the  specified
                 services

          CLI Example:

             salt myminion dockercompose.build /path/where/docker-compose/stored
             salt myminion dockercompose.build /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.create(path, docker_compose)
          Create and validate a docker-compose file into a directory

          path   Path  where the docker-compose file will be stored on the
                 server

          docker_compose
                 docker_compose file

          CLI Example:

             salt myminion dockercompose.create /path/where/docker-compose/stored content

   salt.modules.dockercompose.get(path)
          Get the content of the docker-compose file into a directory

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          CLI Example:

             salt myminion dockercompose.get /path/where/docker-compose/stored

   salt.modules.dockercompose.kill(path, service_names=None)
          Kill  containers  in the docker-compose file, service_names is a
          python list, if omitted kill all containers

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          service_names
                 If specified will kill only the specified services

          CLI Example:

             salt myminion dockercompose.kill /path/where/docker-compose/stored
             salt myminion dockercompose.kill /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.pause(path, service_names=None)
          Pause   running   containers   in   the   docker-compose   file,
          service_names is a python list, if omitted pause all containers

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          service_names
                 If specified will pause only the specified services

          CLI Example:

             salt myminion dockercompose.pause /path/where/docker-compose/stored
             salt myminion dockercompose.pause /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.ps(path)
          List  all  running  containers and report some information about
          them

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          CLI Example:

             salt myminion dockercompose.ps /path/where/docker-compose/stored

   salt.modules.dockercompose.pull(path, service_names=None)
          Pull   image   for   containers   in  the  docker-compose  file,
          service_names is a python list, if omitted pull all images

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          service_names
                 If  specified  will pull only the image for the specified
                 services

          CLI Example:

             salt myminion dockercompose.pull /path/where/docker-compose/stored
             salt myminion dockercompose.pull /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.restart(path, service_names=None)
          Restart container(s) in the docker-compose  file,  service_names
          is a python list, if omitted restart all containers

          path   Path  where  the  docker-compose  file  is  stored on the
                 server

          service_names
                 If specified will restart only the specified services

          CLI Example:

             salt myminion dockercompose.restart /path/where/docker-compose/stored
             salt myminion dockercompose.restart /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.rm(path, service_names=None)
          Remove  stopped   containers   in   the   docker-compose   file,
          service_names  is  a  python list, if omitted remove all stopped
          containers

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          service_names
                 If  specified  will  remove  only  the  specified stopped
                 services

          CLI Example:

             salt myminion dockercompose.rm /path/where/docker-compose/stored
             salt myminion dockercompose.rm /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.start(path, service_names=None)
          Start containers in the docker-compose file, service_names is  a
          python list, if omitted start all containers

          path   Path  where  the  docker-compose  file  is  stored on the
                 server

          service_names
                 If specified will start only the specified services

          CLI Example:

             salt myminion dockercompose.start /path/where/docker-compose/stored
             salt myminion dockercompose.start /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.stop(path, service_names=None)
          Stop   running   containers   in   the   docker-compose    file,
          service_names is a python list, if omitted stop all containers

          path   Path  where  the  docker-compose  file  is  stored on the
                 server

          service_names
                 If specified will stop only the specified services

          CLI Example:

             salt myminion dockercompose.stop /path/where/docker-compose/stored
             salt myminion dockercompose.stop  /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.unpause(path, service_names=None)
          Un-Pause containers in the docker-compose file, service_names is
          a python list, if omitted unpause all containers

          path   Path  where  the  docker-compose  file  is  stored on the
                 server

          service_names
                 If specified will un-pause only the specified services

          CLI Example:

             salt myminion dockercompose.pause /path/where/docker-compose/stored
             salt myminion dockercompose.pause /path/where/docker-compose/stored '[janus]'

   salt.modules.dockercompose.up(path, service_names=None)
          Create   and   start   containers    defined    in    the    the
          docker-compose.yml  file  located  in  path,  service_names is a
          python list, if omitted create and start all containers

          path   Path where the  docker-compose  file  is  stored  on  the
                 server

          service_names
                 If  specified  will  create  and start only the specified
                 services

          CLI Example:

             salt myminion dockercompose.up /path/where/docker-compose/stored
             salt myminion dockercompose.up /path/where/docker-compose/stored '[janus]'

   salt.modules.dockerio
   Management of Docker Containers

   New in version 2014.1.0.

   Deprecated since version 2015.8.0: Future feature development  will  be
   done  only  in  dockerng.  See  the  documentation  for this module for
   information on the deprecation path.

   NOTE:
      The DockerIO integration is still in beta; the  API  is  subject  to
      change

   General Notes
   As  we use states, we don't want to be continuously popping dockers, so
   we will map each container id (or image) with a grain  whenever  it  is
   relevant.

   As  a  corollary, we will resolve a container id either directly by the
   id or try to find a container id matching something stocked in grain.

   Installation Prerequisites
   * You  will  need  the  docker-py  python  package   in   your   python
     installation  path  that  is running salt. Its version should support
     Docker Remote API v1.12.

     Currently, docker-py 0.6.0 is known  to  support  Docker  Remote  API
     v1.12

        pip install docker-py==0.6.0

   Prerequisite Pillar Configuration for Authentication
   * To  push  or  pull you will need to be authenticated as the docker-py
     bindings require it

   * For this to happen, you will need  to  configure  a  mapping  in  the
     pillar representing your per URL authentication bits:

        docker-registries:
            registry_url:
                email: [email protected]
                password: s3cr3t
                username: foo

   * You need at least an entry to the default docker index:

        docker-registries:
            https://index.docker.io/v1/:
                email: [email protected]
                password: s3cr3t
                username: foo

   * You  can  define  multiple registry blocks for them to be aggregated.
     The only thing to keep in mind is that  their  ID  must  finish  with
     -docker-registries:

        ac-docker-registries:
            https://index.bar.io/v1/:
                email: [email protected]
                password: s3cr3t
                username: foo

        ab-docker-registries:
            https://index.foo.io/v1/:
                email: [email protected]
                password: s3cr3t
                username: foo

     This could be also written as:

        docker-registries:
            https://index.bar.io/v1/:
                email: [email protected]
                password: s3cr3t
                username: foo
            https://index.foo.io/v1/:
                email: [email protected]
                password: s3cr3t
                username: foo

   - Registry Dialog

          * login

          * push

          * pull

   - Docker Management

          * version

          * info

   - Image Management

          * search

          * inspect_image

          * get_images

          * remove_image

          * import_image

          * build

          * tag

          * save

          * load

   - Container Management

          * start

          * stop

          * restart

          * kill

          * wait

          * get_containers

          * inspect_container

          * remove_container

          * is_running

          * top

          * port

          * logs

          * diff

          * commit

          * create_container

          * export

          * get_container_root

   Runtime Execution within a specific, already existing/running container

   --------------------------------------------------------------------------

   Idea is to use `lxc-attach <http://linux.die.net/man/1/lxc-attach>`_ to
   execute

   inside the container context.

   We  do  not  want  to  use ``docker run`` but want to execute something
   inside a

   running container.

   These are the available methods:

   - :py:func:`retcode<salt.modules.dockerio.retcode>`

   - :py:func:`run<salt.modules.dockerio.run>`

   - :py:func:`run_all<salt.modules.dockerio.run_all>`

   - :py:func:`run_stderr<salt.modules.dockerio.run_stderr>`

   - :py:func:`run_stdout<salt.modules.dockerio.run_stdout>`

   - :py:func:`script<salt.modules.dockerio.script>`

   - :py:func:`script_retcode<salt.modules.dockerio.script_retcode>`

   salt.modules.dockerio.build(path=None,      tag=None,      quiet=False,
   fileobj=None, nocache=False, rm=True, timeout=None)
          Build a docker image from a dockerfile or an URL

          path   url/branch/docker_dir  or  path  on the filesystem to the
                 dockerfile

          tag    tag of the image

          quiet  quiet mode, Default is False

          nocache
                 do not use docker image cache, Default is False

          rm     remove intermediate commits, Default is True

          timeout
                 timeout value before aborting (in seconds)

          CLI Example:

             salt '*' docker.build vieux/apache
             salt '*' docker.build github.com/creack/docker-firefox

   salt.modules.dockerio.commit(container,   repository=None,    tag=None,
   message=None, author=None, conf=None)
          Commit a container (promotes it to an image)

          container
                 container id

          repository
                 repository/image to commit to

          tag    tag of the image (Optional)

          message
                 commit message (Optional)

          author author name (Optional)

          conf   conf (Optional)

          CLI Example:

             salt '*' docker.commit <container id>

   salt.modules.dockerio.create_container(image,             command=None,
   hostname=None,  user=None,  detach=True,  stdin_open=False,  tty=False,
   mem_limit=None,  ports=None,  environment=None, dns=None, volumes=None,
   volumes_from=None, name=None, cpu_shares=None, cpuset=None, binds=None)
          Create a new container

          image  image to create the container from

          command
                 command to execute while starting

          hostname
                 hostname of the container

          user   user to run docker as

          detach daemon mode, Default is True

          environment
                 environment variable mapping ({'foo':'BAR'})

          ports  port redirections ({'222': {}})

          volumes
                 list of volume mappings in  either  local  volume,  bound
                 volume, or read-only bound volume form:

                    (['/var/lib/mysql/', '/usr/local/etc/ssl:/etc/ssl', '/etc/passwd:/etc/passwd:ro'])

          binds  complete dictionary of bound volume mappings:

                    { '/usr/local/etc/ssl/certs/internal.crt': {
                        'bind': '/etc/ssl/certs/com.example.internal.crt',
                        'ro': True
                        },
                      '/var/lib/mysql': {
                        'bind': '/var/lib/mysql/',
                        'ro': False
                        }
                    }

                 This dictionary is suitable for feeding directly into the
                 Docker  API,   and   all   keys   are   required.    (see
                 https://docker-py.readthedocs.io/en/latest/volumes/)

          tty    attach ttys, Default is False

          stdin_open
                 let stdin open, Default is False

          name   name given to container

          cpu_shares
                 CPU shares (relative weight)

          cpuset CPUs in which to allow execution ('0-3' or '0,1')

          CLI Example:

             salt '*' docker.create_container o/ubuntu volumes="['/s','/m:/f']"

   salt.modules.dockerio.diff(container)
          Get container diffs

          container
                 container id

          CLI Example:

             salt '*' docker.diff <container id>

   salt.modules.dockerio.exists(container)
          Check if a given container exists

          container
                 container id

          Returns True if container exists otherwise returns False

          CLI Example:

             salt '*' docker.exists <container id>

   salt.modules.dockerio.export(container, path)
          Export a container to a file

          container
                 container id

          path   path to which file is to be exported

          CLI Example:

             salt '*' docker.export <container id>

   salt.modules.dockerio.get_container_root(container)
          Get the container rootfs path

          container
                 container id or grain

          CLI Example:

             salt '*' docker.get_container_root <container id>

   salt.modules.dockerio.get_containers(all=True, trunc=False, since=None,
   before=None, limit=-1, host=False, inspect=False)
          Get a list of mappings representing all containers

          all    return all containers, Default is True

          trunc  set it to True to have the short ID, Default is False

          host   include the  Docker  host's  ipv4  and  ipv6  address  in
                 return, Default is False

          inspect
                 Get  more  granular  information  about each container by
                 running a docker inspect

          CLI Example:

             salt '*' docker.get_containers
             salt '*' docker.get_containers host=True
             salt '*' docker.get_containers host=True inspect=True

   salt.modules.dockerio.get_images(name=None, quiet=False, all=True)
          List docker images

          name   repository name

          quiet  only show image id, Default is False

          all    show all images, Default is True

          CLI Example:

             salt '*' docker.get_images <name> [quiet=True|False] [all=True|False]

   salt.modules.dockerio.import_image(src, repo, tag=None)
          Import content from a local tarball or a URL to a docker image

          src    content to import (URL or absolute path to a tarball)

          repo   repository to import to

          tag    set tag of the image (Optional)

          CLI Example:

             salt '*' docker.import_image <src> <repo> [tag]

   salt.modules.dockerio.info()
          Get the version information about docker.  This  is  similar  to
          docker info command

          CLI Example:

             salt '*' docker.info

   salt.modules.dockerio.inspect_container(container)
          Get  container  information.  This  is similar to docker inspect
          command but only for containers

          container
                 container id

          CLI Example:

             salt '*' docker.inspect_container <container id>

   salt.modules.dockerio.inspect_image(image)
          Inspect the status of an image and return relative data. This is
          similar to docker inspect command but only for images.

          image  name of the image

          CLI Example:

             salt '*' docker.inspect_image <image>

   salt.modules.dockerio.is_running(container)
          Check if the specified container is running

          container
                 container id

          Returns True if container is running otherwise returns False

          CLI Example:

             salt '*' docker.is_running <container id>

   salt.modules.dockerio.kill(container, signal=None)
          Kill a running container

          container
                 container id

          signal signal to send

                 New in version 2015.8.0.

          CLI Example:

             salt '*' docker.kill <container id>

   salt.modules.dockerio.load(imagepath)
          Load  the  specified  file  at  imagepath  into  docker that was
          generated  from  a  docker  save  command  e.g.  docker  load  <
          imagepath

          imagepath
                 imagepath to docker tar file

          CLI Example:

             salt '*' docker.load /path/to/image

   salt.modules.dockerio.login(url=None,   username=None,   password=None,
   email=None)
          Wrapper to the docker.py login method (does not do much yet)

          url    registry url to authenticate to

          username
                 username to authenticate

          password
                 password to authenticate

          email  email to authenticate

          CLI Example:

             salt '*' docker.login <url> <username> <password> <email>

   salt.modules.dockerio.logs(container)
          Return logs for a specified container

          container
                 container id

          CLI Example:

             salt '*' docker.logs <container id>

   salt.modules.dockerio.port(container, private_port)
          Private port mapping  allocation  information.  This  method  is
          broken  on  docker-py  side.  Just  use the result of inspect to
          mangle port allocation

          container
                 container id

          private_port
                 private port on the container to query for

          CLI Example:

             salt '*' docker.port <container id> <private port>

   salt.modules.dockerio.pull(repo, tag=None, insecure_registry=False)
          Pulls an image from any registry. See documentation  at  top  of
          this page to configure authenticated access

          repo   name of repository

          tag    specific tag to pull (Optional)

          insecure_registry
                 set as True to use insecure (non HTTPS) registry. Default
                 is False (only available if using docker-py >= 0.5.0)

          CLI Example:

             salt '*' docker.pull <repository> [tag]

   salt.modules.dockerio.push(repo,         tag=None,         quiet=False,
   insecure_registry=False)
          Pushes  an  image  to  any registry. See documentation at top of
          this page to configure authenticated access

          repo   name of repository

          tag    specific tag to push (Optional)

          quiet  set as True to quiet output, Default is False

          insecure_registry
                 set as True to use insecure (non HTTPS) registry. Default
                 is False (only available if using docker-py >= 0.5.0)

          CLI Example:

             salt '*' docker.push <repository> [tag] [quiet=True|False]

   salt.modules.dockerio.remove_container(container, force=False, v=False)
          Remove a container from a docker installation

          container
                 container id

          force  remove a running container, Default is False

          v      remove  the  volumes associated to the container, Default
                 is False

          CLI Example:

             salt '*' docker.remove_container <container id> [force=True|False] [v=True|False]

   salt.modules.dockerio.remove_image(image)
          Remove an image from a system.

          image  name of image

          CLI Example:

             salt '*' docker.remove_image <image>

   salt.modules.dockerio.restart(container, timeout=10)
          Restart a running container

          container
                 container id

          timeout
                 timeout for container to exit gracefully  before  killing
                 it, Default is 10 seconds

          CLI Example:

             salt '*' docker.restart <container id> [timeout=20]

   salt.modules.dockerio.retcode(container, cmd)
          Wrapper for cmdmod.retcode inside a container context

          container
                 container id (or grain)

          cmd    command to execute

          NOTE:
             The  return  is  True  or  False  depending  on  the commands
             success.

          WARNING:
             Be advised that this function allows for raw shell access  to
             the  named  container!  If  allowing  users  to  execute this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.retcode <container id> 'ls -l /etc'

   salt.modules.dockerio.run(container, cmd)
          Wrapper for cmdmod.run inside a container context

          container
                 container id (or grain)

          cmd    command to execute

          NOTE:
             The return is a bit different as we use  the  docker  struct.
             Output of the command is in 'out' and result is always True.

          WARNING:
             Be  advised that this function allows for raw shell access to
             the named  container!  If  allowing  users  to  execute  this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.run <container id> 'ls -l /etc'

   salt.modules.dockerio.run_all(container, cmd)
          Wrapper for cmdmod.run_all inside a container context

          container
                 container id (or grain)

          cmd    command to execute

          NOTE:
             The  return  is  a bit different as we use the docker struct.
             Output of the command is in 'out'  and  result  is  False  if
             command failed to execute.

          WARNING:
             Be  advised that this function allows for raw shell access to
             the named  container!  If  allowing  users  to  execute  this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.run_all <container id> 'ls -l /etc'

   salt.modules.dockerio.run_stderr(container, cmd)
          Wrapper for cmdmod.run_stderr inside a container context

          container
                 container id (or grain)

          cmd    command to execute

          NOTE:
             The  return  is  a bit different as we use the docker struct.
             Output of the command is in 'out' and result is always True.

          WARNING:
             Be advised that this function allows for raw shell access  to
             the  named  container!  If  allowing  users  to  execute this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.run_stderr <container id> 'ls -l /etc'

   salt.modules.dockerio.run_stdout(container, cmd)
          Wrapper for cmdmod.run_stdout inside a container context

          container
                 container id (or grain)

          cmd    command to execute

          NOTE:
             The return is a bit different as we use  the  docker  struct.
             Output of the command is in 'out' and result is always True.

          WARNING:
             Be  advised that this function allows for raw shell access to
             the named  container!  If  allowing  users  to  execute  this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.run_stdout <container id> 'ls -l /etc'

   salt.modules.dockerio.save(image, filename)
          New in version 2015.5.0.

          Save  the  specified  image  to filename from docker e.g. docker
          save image > filename

          image  name of image

          filename
                 The filename of the saved docker image

          CLI Example:

             salt '*' docker.save arch_image /path/to/save/image

   salt.modules.dockerio.script(container,  source,  args=None,  cwd=None,
   stdin=None,  runas=None, shell='/bin/sh', template='jinja', umask=None,
   timeout=None, reset_system_locale=True, no_clean=False, saltenv='base')
          Wrapper for cmdmod.script inside a container context

          container
                 container id (or grain)

          additional parameters
                 See cmd.script

          WARNING:
             Be advised that this function allows for raw shell access  to
             the  named  container!  If  allowing  users  to  execute this
             directly it may allow more rights than intended!

          Download a script from a remote location and execute the  script
          in  the container.  The script can be located on the salt master
          file server or on an HTTP/FTP server.

          The script will be executed directly, so it can  be  written  in
          any available programming language.

          The  script  can also be formatted as a template, the default is
          jinja. Arguments for the script can be specified as well.

          CLI Example:

             salt '*' docker.script <container id> salt://docker_script.py
             salt '*' docker.script <container id> salt://scripts/runme.sh 'arg1 arg2 "arg 3"'
             salt '*' docker.script <container id> salt://scripts/windows_task.ps1 args=' -Input c:\tmp\infile.txt' shell='powershell'

          A string of standard input can be specified for the  command  to
          be  run  using  the stdin parameter. This can be useful in cases
          where sensitive information must be read from standard input:

          CLI Example:

             salt '*' docker.script <container id> salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n'

   salt.modules.dockerio.script_retcode(container,    source,    cwd=None,
   stdin=None,  runas=None, shell='/bin/sh', template='jinja', umask=None,
   timeout=None, reset_system_locale=True, no_clean=False, saltenv='base')
          Wrapper for cmdmod.script_retcode inside a container context

          container
                 container id (or grain)

          additional parameters
                 See cmd.script_retcode

          WARNING:
             Be advised that this function allows for raw shell access  to
             the  named  container!  If  allowing  users  to  execute this
             directly it may allow more rights than intended!

          CLI Example:

             salt '*' docker.script_retcode <container id> salt://docker_script.py

   salt.modules.dockerio.search(term)
          Search for an image on the registry

          term   search keyword

          CLI Example:

             salt '*' docker.search <term>

   salt.modules.dockerio.start(container, binds=None,  port_bindings=None,
   lxc_conf=None,  publish_all_ports=None,  links=None,  privileged=False,
   dns=None,  volumes_from=None,  network_mode=None,  restart_policy=None,
   cap_add=None, cap_drop=None)
          Start the specified container

          container
                 container id

          CLI Example:

             salt '*' docker.start <container id>

   salt.modules.dockerio.stop(container, timeout=10)
          Stop a running container

          container
                 container id

          timeout
                 timeout  for  container to exit gracefully before killing
                 it, Default is 10 seconds

          CLI Example:

             salt '*' docker.stop <container id> [timeout=20]

   salt.modules.dockerio.tag(image, repository, tag=None, force=False)
          Tag an image into a repository

          image  name of image

          repository
                 name of repository

          tag    tag to apply (Optional)

          force  force apply tag, Default is False

          CLI Example:

             salt '*' docker.tag <image> <repository> [tag] [force=True|False]

   salt.modules.dockerio.top(container)
          Run the docker top command on a specific container

          container
                 container id

          CLI Example:

             salt '*' docker.top <container id>

   salt.modules.dockerio.version()
          Get docker version

          CLI Example:

             salt '*' docker.version

   salt.modules.dockerio.wait(container)
          Wait for a container to exit gracefully

          container
                 container id

          CLI Example:

             salt '*' docker.wait <container id>

   salt.modules.dockerng
   Management of Docker Containers

   New in version 2015.8.0.

   Why Make a Second Docker Execution Module?
   We have received a lot of  feedback  on  our  Docker  support.  In  the
   process  of  implementing  recommended  improvements, it became obvious
   that major changes needed to be made to the functions and return  data.
   In the end, a complete rewrite was done.

   The  changes  being  too  significant,  it  was  decided  that making a
   separate execution module and state module (called dockerng)  would  be
   the best option. This will give users a couple release cycles to modify
   their scripts, SLS files, etc. to use  the  new  functionality,  rather
   than forcing users to change everything immediately.

   In  the  Nitrogen  release of Salt (due in 2017), this execution module
   will take the  place  of  the  default  Docker  execution  module,  and
   backwards-compatible  naming  will  be maintained for a couple releases
   after that to allow users time to replace references to  dockerng  with
   docker.

   Installation Prerequisites
   This execution module requires at least version 1.4.0 of both docker-py
   and Docker. docker-py can easily be installed using pip.install:

      salt myminion pip.install docker-py>=1.4.0

   Authentication
   To push or pull images, credentials  must  be  configured.  By  default
   dockerng  will  try to get the credentials from the default docker auth
   file, located  under  the  home  directory  of  the  user  running  the
   salt-minion  (HOME/.docker/config.json).   Because  a  password must be
   used, it is recommended to place this configuration in Pillar data.  If
   pillar  data specifies a registry already present in the default docker
   auth file, it will override.

   The configuration schema is as follows:

      docker-registries:
        <registry_url>:
          email: <email_address>
          password: <password>
          username: <username>
          reauth: <boolean>

   For example:

      docker-registries:
        https://index.docker.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo

   Reauth is an  optional  parameter  that  forces  the  docker  login  to
   reauthorize  using  the credentials passed in the pillar data. Defaults
   to false.

   New in version 2016.3.5,2016.11.1.

   For example:

      docker-registries:
        https://index.docker.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo
          reauth: True

   Mulitiple registries can be configured. This can be done in one of  two
   ways.    The  first  way  is  to  configure  each  registry  under  the
   docker-registries pillar key.

      docker-registries:
        https://index.foo.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo
        https://index.bar.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo

   The  second  way  is  to  use  separate  pillar  variables  ending   in
   -docker-registries:

      foo-docker-registries:
        https://index.foo.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo

      bar-docker-registries:
        https://index.bar.io/v1/:
          email: [email protected]
          password: s3cr3t
          username: foo

   Both   methods   can   be   combined;  any  registry  configured  under
   docker-registries or *-docker-registries will be detected.

   Configuration Options
   The following configuration options can be set to  fine-tune  how  Salt
   uses Docker:

   * docker.url: URL to the docker service (default: local socket).

   * docker.version: API version to use

   * docker.exec_driver:   Execution   driver  to  use,  one  of  nsenter,
     lxc-attach, or docker-exec.  See  the  Executing  Commands  Within  a
     Running  Container  section  for  more  details  on  how  this config
     parameter is used.

   These configuration options are retrieved using config.get  (click  the
   link for further information).

   Functions
   *

     Information Gathering

            * dockerng.depends

            * dockerng.diff

            * dockerng.exists

            * dockerng.history

            * dockerng.images

            * dockerng.info

            * dockerng.inspect

            * dockerng.inspect_container

            * dockerng.inspect_image

            * dockerng.list_containers

            * dockerng.list_tags

            * dockerng.logs

            * dockerng.pid

            * dockerng.port

            * dockerng.ps

            * dockerng.state

            * dockerng.search

            * dockerng.top

            * dockerng.version

   *

     Container Management

            * dockerng.create

            * dockerng.copy_from

            * dockerng.copy_to

            * dockerng.export

            * dockerng.rm

   *

     Management of Container State

            * dockerng.kill

            * dockerng.pause

            * dockerng.restart

            * dockerng.start

            * dockerng.stop

            * dockerng.unpause

            * dockerng.wait

   *

     Image Management

            * dockerng.build

            * dockerng.commit

            * dockerng.dangling

            * dockerng.import

            * dockerng.load

            * dockerng.pull

            * dockerng.push

            * dockerng.rmi

            * dockerng.save

            * dockerng.tag

   *

     Network Management

            * dockerng.networks

            * dockerng.create_network

            * dockerng.remove_network

            * dockerng.inspect_network

            * dockerng.connect_container_to_network

            * dockerng.disconnect_container_from_network

   Executing Commands Within a Running Container
   Multiple methods exist for executing commands within Docker containers:

   * lxc-attach: Default for older versions of docker

   * nsenter: Enters container namespace to run command

   * docker-exec:   Native   support  for  executing  commands  in  Docker
     containers (added in Docker 1.3)

   Adding    a    configuration    option    (see    config.get)    called
   docker.exec_driver will tell Salt which execution driver to use:

      docker.exec_driver: docker-exec

   If   this  configuration  option  is  not  found,  Salt  will  use  the
   appropriate interface (either  nsenter  or  lxc-attach)  based  on  the
   Execution  Driver value returned from docker info. docker-exec will not
   be used by default, as it is presently (as of version 1.6.2) only  able
   to  execute commands as the effective user of the container. Thus, if a
   USER directive was used to run as a  non-privileged  user,  docker-exec
   would  be  unable  to  perform  the  action as root. Salt can still use
   docker-exec as an execution driver, but must be  explicitly  configured
   (as in the example above) to do so at this time.

   If  possible,  try to manually specify the execution driver, as it will
   save Salt a little work.

   This execution module provides functions that shadow those from the cmd
   module. They are as follows:

   * dockerng.retcode

   * dockerng.run

   * dockerng.run_all

   * dockerng.run_stderr

   * dockerng.run_stdout

   * dockerng.script

   * dockerng.script_retcode

   Detailed Function Documentation
   salt.modules.dockerng.build(path=None, image=None, cache=True, rm=True,
   api_response=False, fileobj=None, dockerfile=None)
          Builds a docker image from a Dockerfile or a URL

          path   Path to directory on the Minion containing a Dockerfile

          image  Image to be built, in  repo:tag  notation.  If  just  the
                 repository  name  is passed, a tag name of latest will be
                 assumed. If building from a URL, this  parameted  can  be
                 omitted.

          cache  True  Set  to False to force the build process not to use
                 the  Docker  image   cache,   and   pull   all   required
                 intermediate image layers

          rm     True Remove intermediate containers created during build

          api_response
                 False If True: an API_Response key will be present in the
                 return data, containing the raw output  from  the  Docker
                 API.

          fileobj
                 Allows  for a file-like object containing the contents of
                 the Dockerfile to be passed  in  place  of  a  file  path
                 argument.  This argument should not be used from the CLI,
                 only from other Salt code.

          dockerfile
                 Allows for an alternative  Dockerfile  to  be  specified.
                 Path  to  alternative  Dockefile is relative to the build
                 path for the Docker container.

                 New in version develop.

          RETURN DATA

          A dictionary containing one or more of the following keys:

          * Id - ID of the newly-built image

          * Time_Elapsed - Time in seconds taken to perform the build

          * Intermediate_Containers - IDs of containers created during the
            course of the build process

            (Only present if rm=False)

          *

            Images  - A dictionary containing one or more of the following
            keys:

                   * Already_Pulled  -  Layers  that  that  were   already
                     present on the Minion

                   * Pulled - Layers that that were pulled

            (Only  present  if the image specified by the "image" argument
            was not present on the Minion, or if cache=False)

          * Status - A string containing a  summary  of  the  pull  action
            (usually  a  message  saying  that an image was downloaded, or
            that it was up to date).

            (Only present if the image specified by the  "image"  argument
            was not present on the Minion, or if cache=False)

          CLI Example:

             salt myminion dockerng.build /path/to/docker/build/dir image=myimage:dev
             salt myminion dockerng.build https://github.com/myuser/myrepo.git image=myimage:latest

             .. versionadded:: develop

             salt myminion dockerng.build /path/to/docker/build/dir dockerfile=Dockefile.different image=myimage:dev

   salt.modules.dockerng.call(name, function, *args, **kwargs)
          Executes a salt function inside a container

          CLI Example:

             salt myminion dockerng.call test.ping

             salt myminion test.arg arg1 arg2 key1=val1

          The  container  does not need to have Salt installed, but Python
          is required.

          New in version 2016.11.0.

   salt.modules.dockerng.commit(name, image, message=None, author=None)
          Commits  a  container,  thereby  promoting  it  to   an   image.
          Equivalent to running the docker commit Docker CLI command.

          name   Container name or ID to commit

          image  Image  to be committed, in repo:tag notation. If just the
                 repository name is passed, a tag name of latest  will  be
                 assumed.

          message
                 Commit message (Optional)

          author Author name (Optional)

          RETURN DATA

          A dictionary containing the following keys:

          * Id - ID of the newly-created image

          * Image - Name of the newly-created image

          * Time_Elapsed - Time in seconds taken to perform the commit

          CLI Example:

             salt myminion dockerng.commit mycontainer myuser/myimage
             salt myminion dockerng.commit mycontainer myuser/myimage:mytag

   salt.modules.dockerng.connect_container_to_network(container,
   network_id)
          Connect container to network.

          container
                 Container name or ID

          network_id
                 ID of network

          CLI Example:

             salt myminion dockerng.connect_container_from_network web-1 1f9d2454d0872b68dd9e8744c6e7a4c66b86f10abaccc21e14f7f014f729b2bc

   salt.modules.dockerng.copy_from(name, *args, **kwargs)
          Copy a file from inside a container to the Minion

          name   Container name

          source Path of the file on the container's filesystem

          dest   Destination on the Minion. Must be an absolute  path.  If
                 the  destination  is a directory, the file will be copied
                 into that directory.

          overwrite
                 False Unless this option is set to True, then if  a  file
                 exists at the location specified by the dest argument, an
                 error will be raised.

          makedirs
                 False Create the parent directory on the container if  it
                 does not already exist.

          RETURN DATA

          A boolean (True if successful, otherwise False)

          CLI Example:

             salt myminion dockerng.copy_from mycontainer /var/log/nginx/access.log /home/myuser

   salt.modules.dockerng.copy_to(name, *args, **kwargs)
          Copy a file from the host into a container

          name   Container name

          source File  to  be copied to the container. Can be a local path
                 on the Minion or a remote file from the Salt fileserver.

          dest   Destination on the container. Must be an  absolute  path.
                 If  the  destination  is  a  directory,  the file will be
                 copied into that directory.

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          overwrite
                 False  Unless  this option is set to True, then if a file
                 exists at the location specified by the dest argument, an
                 error will be raised.

          makedirs
                 False  Create the parent directory on the container if it
                 does not already exist.

          RETURN DATA

          A boolean (True if successful, otherwise False)

          CLI Example:

             salt myminion dockerng.copy_to mycontainer /tmp/foo /root/foo

   salt.modules.dockerng.create(*args, **kwargs)
          Create a new container

          name   Name for the new container. If not provided, Docker  will
                 randomly generate one for you.

          image  Image from which to create the container

          command or cmd
                 Command to run in the container

                 Example: command=bash or cmd=bash

                 Changed in version 2015.8.1: cmd is now also accepted

          hostname
                 Hostname of the container. If not provided, and if a name
                 has been provided, the hostname will default to the  name
                 that was passed.

                 Example: hostname=web1

                 WARNING:
                    If  the  container  is started with network_mode=host,
                    the hostname will be overridden by the hostname of the
                    Minion.

          domainname
                 Domain name of the container

                 Example: domainname=domain.tld

          interactive
                 False Leave stdin open

                 Example: interactive=True

          tty    False Attach TTYs

                 Example: tty=True

          detach True If True, run command in the background (daemon mode)

                 Example: detach=False

          user   User under which to run docker

                 Example: user=foo

          memory 0  Memory  limit.  Can  be  specified  in  bytes or using
                 single-letter units (i.e. 512M, 2G, etc.). A value  of  0
                 (the default) means no memory limit.

                 Example: memory=512M, memory=1073741824

          memory_swap
                 -1  Total  memory  limit (memory plus swap). Set to -1 to
                 disable swap. A value of 0 means no swap limit.

                 Example: memory_swap=1G, memory_swap=2147483648

          mac_address
                 MAC address to use for the container. If not specified, a
                 random MAC address will be used.

                 Example: mac_address=01:23:45:67:89:0a

          network_disabled
                 False  If  True,  networking  will be disabled within the
                 container

                 Example: network_disabled=True

          working_dir
                 Working directory inside the container

                 Example: working_dir=/var/log/nginx

          entrypoint
                 Entrypoint for  the  container.  Either  a  string  (e.g.
                 "mycmd --arg1 --arg2") or a Python list (e.g.  "['mycmd',
                 '--arg1', '--arg2']")

                 Example: entrypoint="cat access.log"

          environment
                 Either a dictionary of  environment  variable  names  and
                 their  values,  or a Python list of strings in the format
                 VARNAME=value.

                 Example:   "{'VAR1':    'value',    'VAR2':    'value'}",
                 "['VAR1=value', 'VAR2=value']"

          ports  A list of ports to expose on the container. Can be passed
                 as comma-separated list or a Python list. If the protocol
                 is omitted, the port will be assumed to be a TCP port.

                 Example: 1111,2222/udp, "['1111/tcp', '2222/udp']"

          volumes
                 None  List  of  directories  to expose as volumes. Can be
                 passed as a comma-separated list or a Python list.

                 Example:                     volumes=/mnt/vol1,/mnt/vol2,
                 volumes="[/mnt/vol1, /mnt/vol2]"

          cpu_shares
                 CPU shares (relative weight)

                 Example: cpu_shares=0.5, cpu_shares=1

          cpuset CPUs  on  which  which to allow execution, specified as a
                 string containing a range (e.g. 0-3) or a comma-separated
                 list of CPUs (e.g. 0,1).

                 Example: cpuset="0-3", cpuset="0,1"

          client_timeout
                 Timeout  in  seconds for the Docker client. This is not a
                 timeout for this function, but for receiving  a  response
                 from the API.

                 NOTE:
                    This  is only used if Salt needs to pull the requested
                    image.

          labels Add  Metadata  to  the  container.  Can  be  a  list   of
                 strings/dictionaries or a dictionary of strings (keys and
                 values).

                 Example:     labels=LABEL1,LABEL2,     labels="{'LABEL1':
                 'value1', 'LABEL2': 'value2'}"

          validate_ip_addrs
                 True  For  parameters which accept IP addresses as input,
                 IP address validation will be performed. To disable,  set
                 this to False

          binds  Files/directories  to  bind mount. Each bind mount should
                 be         passed         in          the          format
                 <host_path>:<container_path>:<read_only>,           where
                 <read_only> is one of rw (for read-write  access)  or  ro
                 (for   read-only   access).   Optionally,  the  read-only
                 information can be left off the end and  the  bind  mount
                 will be assumed to be read-write.  Examples 2 and 3 below
                 are equivalent.

                 Example 1: binds=/srv/www:/var/www:ro

                 Example 2: binds=/srv/www:/var/www:rw

                 Example 3: binds=/srv/www:/var/www

          port_bindings
                 Bind exposed ports which were  exposed  using  the  ports
                 argument  to  dockerng.create.  These should be passed in
                 the same way as the --publish argument to the docker  run
                 CLI command:

                 * ip:hostPort:containerPort - Bind a specific IP and port
                   on the host to a specific port within the container.

                 * ip::containerPort - Bind a specific IP and an ephemeral
                   port to a specific port within the container.

                 * hostPort:containerPort - Bind a specific port on all of
                   the host's interfaces to a  specific  port  within  the
                   container.

                 * containerPort  -  Bind  an ephemeral port on all of the
                   host's  interfaces  to  a  specific  port  within   the
                   container.

                 Multiple  bindings  can be separated by commas, or passed
                 as a Python list. The below two examples are equivalent:

                 Example 1: port_bindings="5000:5000,2123:2123/udp,8080"

                 Example 2: port_bindings="['5000:5000',  '2123:2123/udp',
                 '8080']"

                 NOTE:
                    When  configuring bindings for UDP ports, the protocol
                    must be passed in the containerPort value, as seen  in
                    the examples above.

          lxc_conf
                 Additional  LXC  configuration  parameters  to set before
                 starting the container.

                 Example: lxc_conf="{lxc.utsname: docker}"

                 NOTE:
                    These LXC configuration parameters will only have  the
                    desired  effect  if  the  container  is  using the LXC
                    execution driver, which has not been the  default  for
                    some time.

          security_opt
                 Security  configuration  for  MLS systems such as SELinux
                 and AppArmor.

                 Example 1: security_opt="apparmor:unconfined"

                 Example      2:      security_opt=["apparmor:unconfined"]
                 security_opt=["apparmor:unconfined", "param2:value2"]

          publish_all_ports
                 False  Allocates a random host port for each port exposed
                 using the ports argument to dockerng.create.

                 Example: publish_all_ports=True

          links  Link this container to another. Links should be specified
                 in    the   format   <container_name_or_id>:<link_alias>.
                 Multiple links can be passed, ether as a comma  separated
                 list or a Python list.

                 Example           1:           links=mycontainer:myalias,
                 links=web1:link1,web2:link2

                 Example        2:         links="['mycontainer:myalias']"
                 links="['web1:link1', 'web2:link2']"

          dns    List   of   DNS   nameservers.   Can   be   passed  as  a
                 comma-separated list or a Python list.

                 Example: dns=8.8.8.8,8.8.4.4 or dns="[8.8.8.8, 8.8.4.4]"

                 NOTE:
                    To     skip     IP     address     validation,     use
                    validate_ip_addrs=False

          dns_search
                 List   of   DNS  search  domains.  Can  be  passed  as  a
                 comma-separated list or a Python list.

                 Example:  dns_search=foo1.domain.tld,foo2.domain.tld   or
                 dns_search="[foo1.domain.tld, foo2.domain.tld]"

          volumes_from
                 Container  names or IDs from which the container will get
                 volumes. Can be passed as a  comma-separated  list  or  a
                 Python list.

                 Example:      volumes_from=foo,     volumes_from=foo,bar,
                 volumes_from="[foo, bar]"

          network_mode
                 bridge One of the following:

                 * bridge - Creates a new network stack for the  container
                   on the docker bridge

                 * null  -  No  networking  (equivalent  of the Docker CLI
                   argument --net=none)

                 * container:<name_or_id>  -  Reuses  another  container's
                   network stack

                 * host   -  Use  the  host's  network  stack  inside  the
                   container

                   WARNING:
                      Using host mode gives the container full  access  to
                      the  hosts system's services (such as D-bus), and is
                      therefore considered insecure.

                 Example: network_mode=null, network_mode=container:web1

          restart_policy
                 Set a restart policy for the container. Must be passed as
                 a  string in the format policy[:retry_count] where policy
                 is one of always or on-failure,  and  retry_count  is  an
                 optional  limit to the number of retries. The retry count
                 is ignored when using the always restart policy.

                 Example 1: restart_policy=on-failure:5

                 Example 2: restart_policy=always

          cap_add
                 List of capabilities to add within the container. Can  be
                 passed  as  a  comma-separated  list  or  a  Python list.
                 Requires Docker 1.2.0 or newer.

                 Example:  cap_add=SYS_ADMIN,MKNOD,   cap_add="[SYS_ADMIN,
                 MKNOD]"

          cap_drop
                 List of capabilities to drop within the container. Can be
                 passed as a comma-separated  string  or  a  Python  list.
                 Requires Docker 1.2.0 or newer.

                 Example:  cap_drop=SYS_ADMIN,MKNOD, cap_drop="[SYS_ADMIN,
                 MKNOD]"

          extra_hosts
                 Additional hosts to add  to  the  container's  /etc/hosts
                 file. Can be passed as a comma-separated list or a Python
                 list. Requires Docker 1.3.0 or newer.

                 Example: extra_hosts=web1:10.9.8.7,web2:10.9.8.8

                 NOTE:
                    To     skip     IP     address     validation,     use
                    validate_ip_addrs=False

          pid_mode
                 Set  to  host  to  use the host container's PID namespace
                 within the container. Requires Docker 1.5.0 or newer.

                 Example: pid_mode=host

          log_config
                 Set container's log driver and options

                 Example:
                        ``
                        log_conf: Type: json-file Config:
                           max-file: '10'``

          RETURN DATA

          A dictionary containing the following keys:

          * Id - ID of the newly-created container

          * Name - Name of the newly-created container

          CLI Example:

             # Create a data-only container
             salt myminion dockerng.create myuser/mycontainer volumes="/mnt/vol1,/mnt/vol2"
             # Create a CentOS 7 container that will stay running once started
             salt myminion dockerng.create centos:7 name=mycent7 interactive=True tty=True command=bash

   salt.modules.dockerng.create_network(name, driver=None)
          Create a new network

          network_id
                 ID of network

          driver Driver of the network

          CLI Example:

             salt myminion dockerng.create_network web_network driver=bridge

   salt.modules.dockerng.create_volume(name,                  driver=None,
   driver_opts=None)
          Create a new volume

          New in version 2015.8.4.

          name   name of volume

          driver Driver of the volume

          driver_opts
                 Options for the driver volume

          CLI Example:

             salt myminion dockerng.create_volume my_volume driver=local

   salt.modules.dockerng.dangling(prune=False, force=False)
          Return  top-level images (those on which no other images depend)
          which do not have a tag assigned to them. These include:

          * Images which were once tagged but were later untagged, such as
            those  which  were  superseded  by committing a new copy of an
            existing tagged image.

          * Images which were loaded using docker.load (or the docker load
            Docker CLI command), but not tagged.

          prune  False Remove these images

          force  False  If  True,  and if prune=True, then forcibly remove
                 these images.

          RETURN DATA

          If prune=False, the return data will be a list of dangling image
          IDs.

          If  prune=True,  the  return data will be a dictionary with each
          key being the ID  of  the  dangling  image,  and  the  following
          information for each image:

          * Comment  -  Any  error  encountered  when  trying  to  prune a
            dangling image

            (Only present if prune failed)

          * Removed - A boolean (True if prune was  successful,  False  if
            not)

          CLI Example:

             salt myminion dockerng.dangling
             salt myminion dockerng.dangling prune=True

   salt.modules.dockerng.depends(name)
          Returns  the  containers and images, if any, which depend on the
          given image

          name   Name or ID of image

          RETURN DATA

          A dictionary containing the following keys:

          * Containers  -  A  list  of  containers  which  depend  on  the
            specified image

          * Images - A list of IDs of images which depend on the specified
            image

          CLI Example:

             salt myminion dockerng.depends myimage
             salt myminion dockerng.depends 0123456789ab

   salt.modules.dockerng.diff(name, *args, **kwargs)
          Get information on changes made to container's filesystem  since
          it was created. Equivalent to running the docker diff Docker CLI
          command.

          name   Container name or ID

          RETURN DATA

          A dictionary containing any of the following keys:

          * Added - A list of paths that were added.

          * Changed - A list of paths that were changed.

          * Deleted - A list of paths that were deleted.

          These keys will only be present if there were changes, so if the
          container has no differences the return dict will be empty.

          CLI Example:

             salt myminion dockerng.diff mycontainer

   salt.modules.dockerng.disconnect_container_from_network(container,
   network_id)
          Disconnect container from network.

          container
                 Container name or ID

          network_id
                 ID of network

          CLI Example:

             salt myminion dockerng.disconnect_container_from_network web-1 1f9d2454d0872b68dd9e8744c6e7a4c66b86f10abaccc21e14f7f014f729b2bc

   salt.modules.dockerng.exists(name)
          Check if a given container exists

          name   Container name or ID

          RETURN DATA

          A boolean (True if the container exists, otherwise False)

          CLI Example:

             salt myminion dockerng.exists mycontainer

   salt.modules.dockerng.export(name, *args, **kwargs)
          Exports a container to a tar archive.  It  can  also  optionally
          compress that tar archive, and push it up to the Master.

          name   Container name or ID

          path   Absolute  path  on the Minion where the container will be
                 exported

          overwrite
                 False Unless this option is set to True, then if  a  file
                 exists at the location specified by the path argument, an
                 error will be raised.

          makedirs
                 False If True, then if the parent directory of  the  file
                 specified  by the path argument does not exist, Salt will
                 attempt to create it.

          compression
                 None Can be set to any of the following:

                 * gzip or gz for gzip compression

                 * bzip2 or bz2 for bzip2 compression

                 * xz or lzma for XZ compression  (requires  xz-utils,  as
                   well  as  the lzma module from Python 3.3, available in
                   Python 2 and Python 3.0-3.2 as backports.lzma)

                 This parameter can be omitted and Salt  will  attempt  to
                 determine  the compression type by examining the filename
                 passed in the path parameter.

          push   False If True, the container will be pushed to the master
                 using cp.push.

                 NOTE:
                    This  requires  file_recv  to  be  set  to True on the
                    Master.

          RETURN DATA

          A dictionary will containing the following keys:

          * Path - Path of the file that was exported

          * Push - Reports whether or not the file was successfully pushed
            to the Master

            (Only present if push=True)

          * Size - Size of the file, in bytes

          * Size_Human - Size of the file, in human-readable units

          * Time_Elapsed - Time in seconds taken to perform the export

          CLI Examples:

             salt myminion dockerng.export mycontainer /tmp/mycontainer.tar
             salt myminion dockerng.export mycontainer /tmp/mycontainer.tar.xz push=True

   salt.modules.dockerng.history(name, quiet=False)
          Return  the  history  for  an  image.  Equivalent to running the
          docker history Docker CLI command.

          name   Container name or ID

          quiet  False If True, the return data will simply be a  list  of
                 the commands run to build the container.

                    $ salt myminion dockerng.history nginx:latest quiet=True
                    myminion:
                        - FROM scratch
                        - ADD file:ef063ed0ae9579362871b9f23d2bc0781ef7cd4de6ac822052cf6c9c5a12b1e2 in /
                        - CMD [/bin/bash]
                        - MAINTAINER NGINX Docker Maintainers "[email protected]"
                        - apt-key adv --keyserver pgp.mit.edu --recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
                        - echo "deb http://nginx.org/packages/mainline/debian/ wheezy nginx" >> /etc/apt/sources.list
                        - ENV NGINX_VERSION=1.7.10-1~wheezy
                        - apt-get update &&     apt-get install -y ca-certificates nginx=${NGINX_VERSION} &&     rm -rf /var/lib/apt/lists/*
                        - ln -sf /dev/stdout /var/log/nginx/access.log
                        - ln -sf /dev/stderr /var/log/nginx/error.log
                        - VOLUME [/var/cache/nginx]
                        - EXPOSE map[80/tcp:{} 443/tcp:{}]
                        - CMD [nginx -g daemon off;]
                                https://github.com/saltstack/salt/pull/22421

          RETURN DATA

          If  quiet=False, the return value will be a list of dictionaries
          containing information about each step taken to build the image.
          The keys in each step include the following:

          * Command - The command executed in this build step

          * Id - Layer ID

          * Size - Cumulative image size, in bytes

          * Size_Human - Cumulative image size, in human-readable units

          * Tags - Tag(s) assigned to this layer

          * Time_Created_Epoch - Time this build step was completed (Epoch
            time)

          * Time_Created_Local  -  Time  this  build  step  was  completed
            (Minion's local timezone)

          CLI Example:

             salt myminion dockerng.exists mycontainer

   salt.modules.dockerng.images(verbose=False, **kwargs)
          Returns  information  about  the  Docker  images  on the Minion.
          Equivalent to running the docker images Docker CLI command.

          all    False If True, untagged images will also be returned

          verbose
                 False If True, a docker inspect will be run on each image
                 returned.

          RETURN DATA

          A  dictionary  with  each  key being an image ID, and each value
          some general info about that image  (time  created,  size,  tags
          associated with the image, etc.)

          CLI Example:

             salt myminion dockerng.images
             salt myminion dockerng.images all=True

   salt.modules.dockerng.import(source, image, api_response=False)
          Imports  content  from  a local tarball or a URL as a new docker
          image

          source Content to import (URL or absolute path  to  a  tarball).
                 URL   can   be  a  file  on  the  Salt  fileserver  (i.e.
                 salt://path/to/rootfs/tarball.tar.xz. To  import  a  file
                 from a saltenv other than base (e.g. dev), pass it at the
                 end          of          the           URL           (ex.
                 salt://path/to/rootfs/tarball.tar.xz?saltenv=dev).

          image  Image  to be created by the import, in repo:tag notation.
                 If just the repository name is  passed,  a  tag  name  of
                 latest will be assumed.

          api_response
                 False  If True an api_response key will be present in the
                 return data, containing the raw output  from  the  Docker
                 API.

          RETURN DATA

          A dictionary containing the following keys:

          * Id - ID of the newly-created image

          * Image - Name of the newly-created image

          * Time_Elapsed - Time in seconds taken to perform the commit

          CLI Example:

             salt myminion dockerng.import /tmp/cent7-minimal.tar.xz myuser/centos
             salt myminion dockerng.import /tmp/cent7-minimal.tar.xz myuser/centos:7
             salt myminion dockerng.import salt://dockerimages/cent7-minimal.tar.xz myuser/centos:7

   salt.modules.dockerng.info(*args, **kwargs)
          Returns  a  dictionary of system-wide information. Equivalent to
          running the docker info Docker CLI command.

          CLI Example:

             salt myminion dockerng.info

   salt.modules.dockerng.inspect(name)
          This is a generic container/image inspecton  function.  It  will
          first  attempt  to  get  container  information  for  the passed
          name/ID using docker.inspect_container, and then will try to get
          image    information    for    the    passed    name/ID    using
          docker.inspect_image. If it is already known that the name/ID is
          an    image,    it   is   slightly   more   efficient   to   use
          docker.inspect_image.

          name   Container/image name or ID

          RETURN DATA

          A dictionary of container/image information

          CLI Example:

             salt myminion dockerng.inspect mycontainer
             salt myminion dockerng.inspect busybox

   salt.modules.dockerng.inspect_container(name, *args, **kwargs)
          Retrieves  container  information.  Equivalent  to  running  the
          docker  inspect  Docker  CLI  command,  but  will  only look for
          container information.

          name   Container name or ID

          RETURN DATA

          A dictionary of container information

          CLI Example:

             salt myminion dockerng.inspect_container mycontainer
             salt myminion dockerng.inspect_container 0123456789ab

   salt.modules.dockerng.inspect_image(name)
          Retrieves image information. Equivalent to  running  the  docker
          inspect  Docker  CLI  command,  but  will  only  look  for image
          information.

          NOTE:
             To inspect an image, it must have been pulled from a registry
             or  built locally. Images on a Docker registry which have not
             been pulled cannot be inspected.

          name   Image name or ID

          RETURN DATA

          A dictionary of image information

          CLI Examples:

             salt myminion dockerng.inspect_image busybox
             salt myminion dockerng.inspect_image centos:6
             salt myminion dockerng.inspect_image 0123456789ab

   salt.modules.dockerng.inspect_network(network_id)
          Inspect Network

          network_id
                 ID of network

          CLI Example:

             salt myminion dockerng.inspect_network 1f9d2454d0872b68dd9e8744c6e7a4c66b86f10abaccc21e14f7f014f729b2bc

   salt.modules.dockerng.inspect_volume(name)
          Inspect Volume

          New in version 2015.8.4.

          name   Name of volume

          CLI Example:

             salt myminion dockerng.inspect_volume my_volume

   salt.modules.dockerng.kill(*args, **kwargs)
          Kill all processes in a running container instead of  performing
          a graceful shutdown

          name   Container name or ID

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result - A boolean  noting  whether  or  not  the  action  was
            successful

          * comment - Only present if the container cannot be killed

          CLI Example:

             salt myminion dockerng.kill mycontainer

   salt.modules.dockerng.layers(name)
          Returns  a  list of the IDs of layers belonging to the specified
          image, with the top-most layer  (the  one  correspnding  to  the
          passed name) appearing last.

          name   Image name or ID

          CLI Example:

             salt myminion dockerng.layers centos:7

   salt.modules.dockerng.list_containers(**kwargs)
          Returns  a  list  of  containers by name. This is different from
          dockerng.ps in that dockerng.ps returns its results organized by
          container ID.

          all    False  If  True,  stopped  containers will be included in
                 return data

          CLI Example:

             salt myminion dockerng.inspect_image <image>

   salt.modules.dockerng.list_tags()
          Returns a list of tagged images

          CLI Example:

             salt myminion dockerng.list_tags

   salt.modules.dockerng.load(path, image=None)
          Load a tar archive that was created using dockerng.save (or  via
          the Docker CLI using docker save).

          path   Path  to  docker  tar  archive. Path can be a file on the
                 Minion, or the URL of a file on the Salt fileserver (i.e.
                 salt://path/to/docker/saved/image.tar).  To  load  a file
                 from a saltenv other than base (e.g. dev), pass it at the
                 end           of           the          URL          (ex.
                 salt://path/to/rootfs/tarball.tar.xz?saltenv=dev).

          image  None If specified, the topmost layer of the  newly-loaded
                 image  will  be  tagged  with  the specified repo and tag
                 using dockerng.tag. The image name should be specified in
                 repo:tag notation. If just the repository name is passed,
                 a tag name of latest will be assumed.

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * Path - Path of the file that was saved

          * Layers - A list containing the IDs of the  layers  which  were
            loaded.   Any  layers  in the file that was loaded, which were
            already present on the Minion, will not be included.

          * Image - Name of tag applied to topmost layer

            (Only present if tag was specified and tagging was successful)

          * Time_Elapsed - Time in seconds taken to load the file

          * Warning -  Message  describing  any  problems  encountered  in
            attemp to tag the topmost layer

            (Only present if tag was specified and tagging failed)

          CLI Example:

             salt myminion dockerng.load /path/to/image.tar
             salt myminion dockerng.load salt://path/to/docker/saved/image.tar image=myuser/myimage:mytag

   salt.modules.dockerng.logs(name)
          Returns  the  logs  for the container. Equivalent to running the
          docker logs Docker CLI command.

          name   Container name or ID

          CLI Example:

             salt myminion dockerng.logs mycontainer

   salt.modules.dockerng.networks(names=None, ids=None)
          List existing networks

          names  Filter by name

          ids    Filter by id

          CLI Example:

             salt myminion dockerng.networks names="['network-web']"
             salt myminion dockerng.networks ids="['1f9d2454d0872b68dd9e8744c6e7a4c66b86f10abaccc21e14f7f014f729b2bc']"

   salt.modules.dockerng.pause(*args, **kwargs)
          Pauses a container

          name   Container name or ID

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result  -  A  boolean  noting  whether  or  not the action was
            successful

          * comment - Only present if the container cannot be paused

          CLI Example:

             salt myminion dockerng.pause mycontainer

   salt.modules.dockerng.pid(name, *args, **kwargs)
          Returns the PID of a container

          name   Container name or ID

          CLI Example:

             salt myminion dockerng.pid mycontainer
             salt myminion dockerng.pid 0123456789ab

   salt.modules.dockerng.port(name, *args, **kwargs)
          Returns  port  mapping  information  for  a   given   container.
          Equivalent to running the docker port Docker CLI command.

          name   Container name or ID

          private_port
                 None  If  specified,  get  information  for that specific
                 port. Can be specified either  as  a  port  number  (i.e.
                 5000),  or  as  a  port  number  plus  the protocol (i.e.
                 5000/udp).

                 If this argument is omitted, all port  mappings  will  be
                 returned.

          RETURN DATA

          A  dictionary of port mappings, with the keys being the port and
          the values being the mapping(s) for that port.

          CLI Examples:

             salt myminion dockerng.port mycontainer
             salt myminion dockerng.port mycontainer 5000
             salt myminion dockerng.port mycontainer 5000/udp

   salt.modules.dockerng.ps(filters=None, **kwargs)
          Returns information about the Docker containers on  the  Minion.
          Equivalent to running the docker ps Docker CLI command.

          all    False If True, stopped containers will also be returned

          host: False
                 If True, local host's network topology will be included

          verbose
                 False  If  True,  a  docker  inspect  will be run on each
                 container returned.

          filters: None
                 A dictionary of filters to be processed on the  container
                 list.  Available filters:

                    * exited  (int):  Only  containers with specified exit
                      code

                    * status (str): One of  restarting,  running,  paused,
                      exited

                    * label (str): format either "key" or "key=value"

          RETURN DATA

          A dictionary with each key being an container ID, and each value
          some general info about  that  container  (time  created,  name,
          command, etc.)

          CLI Example:

             salt myminion dockerng.ps
             salt myminion dockerng.ps all=True
             salt myminion dockerng.ps filters="{'label': 'role=web'}"

   salt.modules.dockerng.pull(image,              insecure_registry=False,
   api_response=False, client_timeout=60)
          Pulls an image from a Docker registry. See the documentation  at
          the top of this page to configure authenticated access.

          image  Image  to  be  pulled,  in repo:tag notation. If just the
                 repository name is passed, a tag name of latest  will  be
                 assumed.

          insecure_registry
                 False  If  True, the Docker client will permit the use of
                 insecure (non-HTTPS) registries.

          api_response
                 False If True, an API_Response key will be present in the
                 return  data,  containing  the raw output from the Docker
                 API.

                 NOTE:
                    This may result in a lot of  additional  return  data,
                    especially for larger images.

          client_timeout
                 Timeout  in  seconds for the Docker client. This is not a
                 timeout for this function, but for receiving  a  response
                 from the API.

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          *

            Layers  - A dictionary containing one or more of the following
            keys:

                   * Already_Pulled  -  Layers  that  that  were   already
                     present on the Minion

                   * Pulled - Layers that that were pulled

          * Status  -  A  string  containing  a summary of the pull action
            (usually a message saying that an  image  was  downloaded,  or
            that it was up to date).

          * Time_Elapsed - Time in seconds taken to perform the pull

          CLI Example:

             salt myminion dockerng.pull centos
             salt myminion dockerng.pull centos:6

   salt.modules.dockerng.push(image,              insecure_registry=False,
   api_response=False, client_timeout=60)
          Changed in version 2015.8.4: The Id and Image keys are no longer
          present  in  the  return  data.   This  is due to changes in the
          Docker Remote API.

          Pushes an image to a Docker registry. See the  documentation  at
          top of this page to configure authenticated access.

          image  Image to be pushed, in repo:tag notation.

                 Changed  in version 2015.8.4: If just the repository name
                 is passed, then all tagged images for the specified  repo
                 will  be  pushed.  In prior releases, a tag of latest was
                 assumed if the tag was omitted.

          insecure_registry
                 False If True, the Docker client will permit the  use  of
                 insecure (non-HTTPS) registries.

          api_response
                 False If True, an API_Response key will be present in the
                 return data, containing the raw output  from  the  Docker
                 API.

          client_timeout
                 Timeout  in  seconds for the Docker client. This is not a
                 timeout for this function, but for receiving  a  response
                 from the API.

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          *

            Layers  - A dictionary containing one or more of the following
            keys:

                   * Already_Pushed  -  Layers  that  that  were   already
                     present on the Minion

                   * Pushed - Layers that that were pushed

          * Time_Elapsed - Time in seconds taken to perform the push

          CLI Example:

             salt myminion dockerng.push myuser/mycontainer
             salt myminion dockerng.push myuser/mycontainer:mytag

   salt.modules.dockerng.remove_network(network_id)
          Remove a network

          network_id
                 ID of network

          CLI Example:

             salt myminion dockerng.remove_network 1f9d2454d0872b68dd9e8744c6e7a4c66b86f10abaccc21e14f7f014f729b2bc

   salt.modules.dockerng.remove_volume(name)
          Remove a volume

          New in version 2015.8.4.

          name   Name of volume

          CLI Example:

             salt myminion dockerng.remove_volume my_volume

   salt.modules.dockerng.restart(name, *args, **kwargs)
          Restarts a container

          name   Container name or ID

          timeout
                 10  Timeout  in seconds after which the container will be
                 killed (if it has not yet gracefully shut down)

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result  -  A  boolean  noting  whether  or  not the action was
            successful

          * restarted - If  restart  was  successful,  this  key  will  be
            present and will be set to True.

          CLI Examples:

             salt myminion dockerng.restart mycontainer
             salt myminion dockerng.restart mycontainer timeout=20

   salt.modules.dockerng.retcode(name,  cmd, exec_driver=None, stdin=None,
   python_shell=True,        output_loglevel='debug',        use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.retcode within a container

          name   Container name or ID in which to run the command

          cmd    Command to run

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None If not passed, only a sane default PATH  environment
                 variable  will be set. If True, all environment variables
                 from the container's host  will  be  kept.  Otherwise,  a
                 comma-separated  list  (or  Python  list)  of environment
                 variable names  can  be  passed,  and  those  environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.retcode mycontainer 'ls -l /etc'

   salt.modules.dockerng.rm(*args, **kwargs)
          Removes a container

          name   Container name or ID

          force  False  If True, the container will be killed first before
                 removal, as the Docker API  will  not  permit  a  running
                 container  to  be removed. This option is set to False by
                 default  to  prevent  accidental  removal  of  a  running
                 container.

          volumes
                 False Also remove volumes associated with container

          RETURN DATA

          A list of the IDs of containers which were removed

          CLI Example:

             salt myminion dockerng.rm mycontainer
             salt myminion dockerng.rm mycontainer force=True

   salt.modules.dockerng.rmi(*names, **kwargs)
          Removes an image

          name   Name (in repo:tag notation) or ID of image.

          force  False  If  True,  the  image  will be removed even if the
                 Minion has containers created from that image

          prune  True If  True,  untagged  parent  image  layers  will  be
                 removed as well, set this to False to keep them.

          RETURN DATA

          A  dictionary  will  be  returned,  containing the following two
          keys:

          * Layers - A list of the IDs of image layers that were removed

          * Tags - A list of the tags that were removed

          * Errors - A list of any errors that were encountered

          CLI Examples:

             salt myminion dockerng.rmi busybox
             salt myminion dockerng.rmi busybox force=True
             salt myminion dockerng.rmi foo bar baz

   salt.modules.dockerng.run(name,  cmd,   exec_driver=None,   stdin=None,
   python_shell=True,        output_loglevel='debug',        use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.run within a container

          name   Container name or ID in which to run the command

          cmd    Command to run

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.run mycontainer 'ls -l /etc'

   salt.modules.dockerng.run_all(name, cmd, exec_driver=None,  stdin=None,
   python_shell=True,        output_loglevel='debug',        use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.run_all within a container

          NOTE:
             While  the  command  is  run  within  the  container,  it  is
             initiated  from  the  host.  Therefore, the PID in the return
             dict is from the host, not from the container.

          name   Container name or ID in which to run the command

          cmd    Command to run

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.run_all mycontainer 'ls -l /etc'

   salt.modules.dockerng.run_stderr(name,      cmd,      exec_driver=None,
   stdin=None,  python_shell=True,  output_loglevel='debug', use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.run_stderr within a container

          name   Container name or ID in which to run the command

          cmd    Command to run

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.run_stderr mycontainer 'ls -l /etc'

   salt.modules.dockerng.run_stdout(name,      cmd,      exec_driver=None,
   stdin=None,  python_shell=True,  output_loglevel='debug', use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.run_stdout within a container

          name   Container name or ID in which to run the command

          cmd    Command to run

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.run_stdout mycontainer 'ls -l /etc'

   salt.modules.dockerng.save(name, path, overwrite=False, makedirs=False,
   compression=None, **kwargs)
          Saves  an  image  and  to  a  file  on the minion. Equivalent to
          running the docker save Docker CLI command,  but  unlike  docker
          save  this will also work on named images instead of just images
          IDs.

          name   Name or ID of image. Specify a specific tag by using  the
                 repo:tag notation.

          path   Absolute  path  on  the  Minion  where  the image will be
                 exported

          overwrite
                 False Unless this option is set  to  True,  then  if  the
                 destination file exists an error will be raised.

          makedirs
                 False  If  True, then if the parent directory of the file
                 specified by the path argument does not exist, Salt  will
                 attempt to create it.

          compression
                 None Can be set to any of the following:

                 * gzip or gz for gzip compression

                 * bzip2 or bz2 for bzip2 compression

                 * xz  or  lzma  for XZ compression (requires xz-utils, as
                   well as the lzma module from Python 3.3,  available  in
                   Python 2 and Python 3.0-3.2 as backports.lzma)

                 This  parameter  can  be omitted and Salt will attempt to
                 determine the compression type by examining the  filename
                 passed in the path parameter.

                 NOTE:
                    Since  the  Docker  API  does not support docker save,
                    compression will be a bit slower  with  this  function
                    than  with docker.export since the image(s) will first
                    be saved and then the compression done afterwards.

          push   False If True, the container will be pushed to the master
                 using cp.push.

                 NOTE:
                    This  requires  file_recv  to  be  set  to True on the
                    Master.

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * Path - Path of the file that was saved

          * Push - Reports whether or not the file was successfully pushed
            to the Master

            (Only present if push=True)

          * Size - Size of the file, in bytes

          * Size_Human - Size of the file, in human-readable units

          * Time_Elapsed - Time in seconds taken to perform the save

          CLI Examples:

             salt myminion dockerng.save centos:7 /tmp/cent7.tar
             salt myminion dockerng.save 0123456789ab cdef01234567 /tmp/saved.tar

   salt.modules.dockerng.script(name,  source,  saltenv='base', args=None,
   template=None,   exec_driver=None,    stdin=None,    python_shell=True,
   output_loglevel='debug',       ignore_retcode=False,      use_vt=False,
   keep_env=None)
          Run cmd.script within a container

          NOTE:
             While  the  command  is  run  within  the  container,  it  is
             initiated  from  the  host.  Therefore, the PID in the return
             dict is from the host, not from the container.

          name   Container name or ID

          source Path to the script. Can be a local path on the Minion  or
                 a remote file from the Salt fileserver.

          args   A  string  containing  additional command-line options to
                 pass to the script.

          template
                 None Templating  engine  to  use  on  the  script  before
                 running.

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the script

          output_loglevel
                 debug Level at which to log the output from  the  script.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None If not passed, only a sane default PATH  environment
                 variable  will be set. If True, all environment variables
                 from the container's host  will  be  kept.  Otherwise,  a
                 comma-separated  list  (or  Python  list)  of environment
                 variable names  can  be  passed,  and  those  environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.script mycontainer salt://docker_script.py
             salt myminion dockerng.script mycontainer salt://scripts/runme.sh 'arg1 arg2 "arg 3"'
             salt myminion dockerng.script mycontainer salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n' output_loglevel=quiet

   salt.modules.dockerng.script_retcode(name,    source,   saltenv='base',
   args=None,      template=None,      exec_driver=None,       stdin=None,
   python_shell=True,    output_loglevel='debug',    ignore_retcode=False,
   use_vt=False, keep_env=None)
          Run cmd.script_retcode within a container

          name   Container name or ID

          source Path to the script. Can be a local path on the Minion  or
                 a remote file from the Salt fileserver.

          args   A  string  containing  additional command-line options to
                 pass to the script.

          template
                 None Templating  engine  to  use  on  the  script  before
                 running.

          exec_driver
                 None If not passed, the execution driver will be detected
                 as described above.

          stdin  None Standard input to be used for the script

          output_loglevel
                 debug Level at which to log the output from  the  script.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None If not passed, only a sane default PATH  environment
                 variable  will be set. If True, all environment variables
                 from the container's host  will  be  kept.  Otherwise,  a
                 comma-separated  list  (or  Python  list)  of environment
                 variable names  can  be  passed,  and  those  environment
                 variables will be kept.

          CLI Example:

             salt myminion dockerng.script_retcode mycontainer salt://docker_script.py
             salt myminion dockerng.script_retcode mycontainer salt://scripts/runme.sh 'arg1 arg2 "arg 3"'
             salt myminion dockerng.script_retcode mycontainer salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n' output_loglevel=quiet

   salt.modules.dockerng.search(name, official=False, trusted=False)
          Searches the registry for an image

          name   Search keyword

          official
                 False Limit results to official builds

          trusted
                 False Limit results to trusted builds

          RETURN DATA

          A  dictionary  with each key being the name of an image, and the
          following information for each image:

          * Description - Image description

          * Official - A boolean (True if an official build, False if not)

          * Stars - Number of stars the image has on the registry

          * Trusted - A boolean (True if a trusted build, False if not)

          CLI Example:

             salt myminion dockerng.search centos
             salt myminion dockerng.search centos official=True

   salt.modules.dockerng.signal(*args, **kwargs)
          Send a signal to a container. Signals can be either  strings  or
          numbers,  and are defined in the Standard Signals section of the
          signal(7) manpage. Run man 7 signal on a Linux  host  to  browse
          this manpage.

          name   Container name or ID

          signal Signal to send to container

          RETURN DATA

          If  the  signal  was  successfully  sent, True will be returned.
          Otherwise, an error will be raised.

          CLI Example:

             salt myminion dockerng.signal mycontainer SIGHUP

   salt.modules.dockerng.sls(name, mods=None, saltenv='base', **kwargs)
          Apply the highstate defined by the specified modules.

          For example, if your master defines the states  web  and  rails,
          you can apply them to a container: states by doing:

          CLI Example:

             salt myminion dockerng.sls compassionate_mirzakhani mods=rails,web

          The  container  does not need to have Salt installed, but Python
          is required.

          New in version 2016.11.0.

   salt.modules.dockerng.sls_build(name,           base='opensuse/python',
   mods=None, saltenv='base', **kwargs)
          Build  a  docker  image using the specified sls modules and base
          image.

          For example, if your master defines the states  web  and  rails,
          you  can  build  a  docker image inside myminion that results of
          applying those states by doing:

          CLI Example:

             salt myminion dockerng.sls_build imgname base=mybase mods=rails,web

          The base image does not need to have Salt installed, but  Python
          is required.

          New in version 2016.11.0.

   salt.modules.dockerng.start(*args, **kwargs)
          Start a container

          name   Container name or ID

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result - A boolean  noting  whether  or  not  the  action  was
            successful

          * comment - Only present if the container cannot be started

          CLI Example:

             salt myminion dockerng.start mycontainer

   salt.modules.dockerng.state(name, *args, **kwargs)
          Returns the state of the container

          name   Container name or ID

          RETURN DATA

          A string representing the current state of the container (either
          running, paused, or stopped)

          CLI Example:

             salt myminion dockerng.state mycontainer

   salt.modules.dockerng.stop(*args, **kwargs)
          Stops a running container

          name   Container name or ID

          unpause
                 False If True and the container is  paused,  it  will  be
                 unpaused before attempting to stop the container.

          timeout
                 10  Timeout  in seconds after which the container will be
                 killed (if it has not yet gracefully shut down)

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result  -  A  boolean  noting  whether  or  not the action was
            successful

          * comment - Only present if the container can not be stopped

          CLI Examples:

             salt myminion dockerng.stop mycontainer
             salt myminion dockerng.stop mycontainer unpause=True
             salt myminion dockerng.stop mycontainer timeout=20

   salt.modules.dockerng.tag(name, image, force=False)
          Tag an image into a repository and return True. If the  tag  was
          unsuccessful, an error will be raised.

          name   ID of image

          image  Tag  to apply to the image, in repo:tag notation. If just
                 the repository name is passed, a tag name of latest  will
                 be assumed.

          force  False Force apply tag

          CLI Example:

             salt myminion dockerng.tag 0123456789ab myrepo/mycontainer
             salt myminion dockerng.tag 0123456789ab myrepo/mycontainer:mytag

   salt.modules.dockerng.top(name, *args, **kwargs)
          Runs the docker top command on a specific container

          name   Container name or ID

          CLI Example:

          RETURN DATA

          A list of dictionaries containing information about each process

             salt myminion dockerng.top mycontainer
             salt myminion dockerng.top 0123456789ab

   salt.modules.dockerng.unpause(*args, **kwargs)
          Unpauses a container

          name   Container name or ID

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result - A boolean  noting  whether  or  not  the  action  was
            successful

          * comment - Only present if the container can not be unpaused

          CLI Example:

             salt myminion dockerng.pause mycontainer

   salt.modules.dockerng.version()
          Returns  a  dictionary of Docker version information. Equivalent
          to running the docker version Docker CLI command.

          CLI Example:

             salt myminion dockerng.version

   salt.modules.dockerng.volumes(filters=None)
          List existing volumes

          New in version 2015.8.4.

          filters
                 There is one available filter: dangling=true

          CLI Example:

             salt myminion dockerng.volumes filters="{'dangling': True}"

   salt.modules.dockerng.wait(name,          ignore_already_stopped=False,
   fail_on_exit_status=False)
          Wait  for  the container to exit gracefully, and return its exit
          code

          NOTE:
             This function will block until the container is stopped.

          name   Container name or ID

          ignore_already_stopped
                 Boolean  flag  that  prevent  execution  to  fail,  if  a
                 container is already stopped.

          fail_on_exit_status
                 Boolean   flag   to   report   execution  as  failure  if
                 exit_status is different than 0.

          RETURN DATA

          A dictionary will be returned, containing the following keys:

          * status - A dictionary showing the prior state of the container
            as well as the new state

          * result  -  A  boolean  noting  whether  or  not the action was
            successful

          * exit_status - Exit status for the container

          * comment - Only present if the container is already stopped

          CLI Example:

             salt myminion dockerng.wait mycontainer

   salt.modules.dpkg
   Support for DEB packages

   salt.modules.dpkg.bin_pkg_info(path, saltenv='base')
          New in version 2015.8.0.

          Parses RPM metadata and  returns  a  dictionary  of  information
          about the package (name, version, etc.).

          path   Path  to  the  file.  Can either be an absolute path to a
                 file on the  minion,  or  a  salt  fileserver  URL  (e.g.
                 salt://path/to/file.rpm).   If  a  salt fileserver URL is
                 passed, the file will be cached to the minion so that  it
                 can be examined.

          saltenv
                 base  Salt  fileserver envrionment from which to retrieve
                 the package. Ignored if path is a local file path on  the
                 minion.

          CLI Example:

             salt '*' lowpkg.bin_pkg_info /root/foo-1.2.3-1ubuntu1_all.deb
             salt '*' lowpkg.bin_pkg_info salt://foo-1.2.3-1ubuntu1_all.deb

   salt.modules.dpkg.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying any packages will return a list of  _every_  file  on
          the system's package database (not generally recommended).

          CLI Examples:

             salt '*' lowpkg.file_list httpd
             salt '*' lowpkg.file_list httpd postfix
             salt '*' lowpkg.file_list

   salt.modules.dpkg.file_list(*packages)
          List  the  files  that  belong  to a package. Not specifying any
          packages will return a list of  _every_  file  on  the  system's
          package database (not generally recommended).

          CLI Examples:

             salt '*' lowpkg.file_list httpd
             salt '*' lowpkg.file_list httpd postfix
             salt '*' lowpkg.file_list

   salt.modules.dpkg.info(*packages)
          Returns  a  detailed summary of package information for provided
          package names.  If no packages are specified, all packages  will
          be returned.

          New in version 2015.8.1.

          packages
                 The   names   of   the   packages  for  which  to  return
                 information.

          CLI example:

             salt '*' lowpkg.info
             salt '*' lowpkg.info apache2 bash

   salt.modules.dpkg.list_pkgs(*packages)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          External dependencies:

             Virtual package resolution requires aptitude. Because this function
             uses dpkg, virtual packages will be reported as not installed.

          CLI Example:

             salt '*' lowpkg.list_pkgs
             salt '*' lowpkg.list_pkgs httpd

   salt.modules.dpkg.unpurge(*packages)
          Change package selection for each package specified to 'install'

          CLI Example:

             salt '*' lowpkg.unpurge curl

   salt.modules.drac
   Manage Dell DRAC

   salt.modules.drac.change_password(username, password, uid=None)
          Change users password

          CLI Example:

             salt dell drac.change_password [USERNAME] [PASSWORD] [UID - optional]
             salt dell drac.change_password diana secret

   salt.modules.drac.create_user(username,     password,      permissions,
   users=None)
          Create user accounts

          CLI Example:

             salt dell drac.create_user [USERNAME] [PASSWORD] [PRIVILEGES]
             salt dell drac.create_user diana secret login,test_alerts,clear_logs

          DRAC Privileges

                 * login                   : Login to iDRAC

                 * drac                    : Configure iDRAC

                 * user_management         : Configure Users

                 * clear_logs              : Clear Logs

                 * server_control_commands   :   Execute   Server  Control
                   Commands

                 * console_redirection     : Access Console Redirection

                 * virtual_media           : Access Virtual Media

                 * test_alerts             : Test Alerts

                 * debug_commands          : Execute Debug Commands

   salt.modules.drac.delete_user(username, uid=None)
          Delete a user

          CLI Example:

             salt dell drac.delete_user [USERNAME] [UID - optional]
             salt dell drac.delete_user diana 4

   salt.modules.drac.email_alerts(action)
          Enable/Disable email alerts

          CLI Example:

             salt dell drac.email_alerts True
             salt dell drac.email_alerts False

   salt.modules.drac.list_users()
          List all DRAC users

          CLI Example:

             salt dell drac.list_users

   salt.modules.drac.nameservers(*ns)
          Configure the nameservers on the DRAC

          CLI Example:

             salt dell drac.nameservers [NAMESERVERS]
             salt dell drac.nameservers ns1.example.com ns2.example.com

   salt.modules.drac.network_info()
          Return Network Configuration

          CLI Example:

             salt dell drac.network_info

   salt.modules.drac.server_hardreset()
          Performs a reset (reboot) operation on the managed server.

          CLI Example:

             salt dell drac.server_hardreset

   salt.modules.drac.server_poweroff()
          Powers down the managed server.

          CLI Example:

             salt dell drac.server_poweroff

   salt.modules.drac.server_poweron()
          Powers up the managed server.

          CLI Example:

             salt dell drac.server_poweron

   salt.modules.drac.server_pxe()
          Configure server to PXE perform a one off PXE boot

          CLI Example:

             salt dell drac.server_pxe

   salt.modules.drac.server_reboot()
          Issues a power-cycle  operation  on  the  managed  server.  This
          action  is  similar to pressing the power button on the system's
          front panel to power down and then power up the system.

          CLI Example:

             salt dell drac.server_reboot

   salt.modules.drac.set_network(ip, netmask, gateway)
          Configure Network

          CLI Example:

             salt dell drac.set_network [DRAC IP] [NETMASK] [GATEWAY]
             salt dell drac.set_network 192.168.0.2 255.255.255.0 192.168.0.1

   salt.modules.drac.set_permissions(username, permissions, uid=None)
          Configure users permissions

          CLI Example:

             salt dell drac.set_permissions [USERNAME] [PRIVILEGES] [USER INDEX - optional]
             salt dell drac.set_permissions diana login,test_alerts,clear_logs 4

          DRAC Privileges

                 * login                   : Login to iDRAC

                 * drac                    : Configure iDRAC

                 * user_management         : Configure Users

                 * clear_logs              : Clear Logs

                 * server_control_commands  :   Execute   Server   Control
                   Commands

                 * console_redirection     : Access Console Redirection

                 * virtual_media           : Access Virtual Media

                 * test_alerts             : Test Alerts

                 * debug_commands          : Execute Debug Commands

   salt.modules.drac.set_snmp(community)
          Configure SNMP community string

          CLI Example:

             salt dell drac.set_snmp [COMMUNITY]
             salt dell drac.set_snmp public

   salt.modules.drac.syslog(server, enable=True)
          Configure   syslog   remote  logging,  by  default  syslog  will
          automatically be enabled if a server is specified.  However,  if
          you  want  to  disable  syslog you will need to specify a server
          followed by False

          CLI Example:

             salt dell drac.syslog [SYSLOG IP] [ENABLE/DISABLE]
             salt dell drac.syslog 0.0.0.0 False

   salt.modules.drac.system_info()
          Return System information

          CLI Example:

             salt dell drac.system_info

   salt.modules.dracr
   Manage Dell DRAC.

   New in version 2015.8.2.

   salt.modules.dracr.change_password(username,    password,     uid=None,
   host=None, admin_username=None, admin_password=None, module=None)
          Change user's password

          CLI Example:

             salt dell dracr.change_password [USERNAME] [PASSWORD] uid=[OPTIONAL]
                 host=<remote DRAC> admin_username=<DRAC user>
                 admin_password=<DRAC PW>
             salt dell dracr.change_password diana secret

          Note  that if only a username is specified then this module will
          look up details for all 16 possible DRAC users.   This  is  time
          consuming,  but might be necessary if one is not sure which user
          slot contains the one you want.  Many  late-model  Dell  chassis
          have  'root' as UID 1, so if you can depend on that then setting
          the password is much quicker.  Raises an error if  the  supplied
          password is greater than 20 chars.

   salt.modules.dracr.create_user(username,     password,     permissions,
   users=None, host=None, admin_username=None, admin_password=None)
          Create user accounts

          CLI Example:

             salt dell dracr.create_user [USERNAME] [PASSWORD] [PRIVILEGES]
             salt dell dracr.create_user diana secret login,test_alerts,clear_logs

          DRAC Privileges

                 * login                   : Login to iDRAC

                 * drac                    : Configure iDRAC

                 * user_management         : Configure Users

                 * clear_logs              : Clear Logs

                 * server_control_commands  :   Execute   Server   Control
                   Commands

                 * console_redirection     : Access Console Redirection

                 * virtual_media           : Access Virtual Media

                 * test_alerts             : Test Alerts

                 * debug_commands          : Execute Debug Commands

   salt.modules.dracr.delete_user(username,      uid=None,      host=None,
   admin_username=None, admin_password=None)
          Delete a user

          CLI Example:

             salt dell dracr.delete_user [USERNAME] [UID - optional]
             salt dell dracr.delete_user diana 4

   salt.modules.dracr.deploy_password(username,    password,    host=None,
   admin_username=None, admin_password=None, module=None)
          Change the QuickDeploy password, used for switches as well

          CLI Example:

             salt dell dracr.deploy_password [USERNAME] [PASSWORD]
                 host=<remote DRAC> admin_username=<DRAC user>
                 admin_password=<DRAC PW>
             salt dell dracr.change_password diana secret

          Note  that if only a username is specified then this module will
          look up details for all 16 possible DRAC users.   This  is  time
          consuming,  but might be necessary if one is not sure which user
          slot contains the one you want.  Many  late-model  Dell  chassis
          have  'root' as UID 1, so if you can depend on that then setting
          the password is much quicker.

   salt.modules.dracr.deploy_snmp(snmp,  host=None,   admin_username=None,
   admin_password=None, module=None)
          Change  the QuickDeploy SNMP community string, used for switches
          as well

          CLI Example:

             salt dell dracr.deploy_snmp SNMP_STRING
                 host=<remote DRAC or CMC> admin_username=<DRAC user>
                 admin_password=<DRAC PW>
             salt dell dracr.deploy_password diana secret

   salt.modules.dracr.email_alerts(action, host=None, admin_username=None,
   admin_password=None)
          Enable/Disable email alerts

          CLI Example:

             salt dell dracr.email_alerts True
             salt dell dracr.email_alerts False

   salt.modules.dracr.get_chassis_datacenter(host=None,
   admin_username=None, admin_password=None)
          Get the datacenter of the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_chassis_location host=111.222.333.444
                admin_username=root admin_password=secret

   salt.modules.dracr.get_chassis_location(host=None, admin_username=None,
   admin_password=None)
          Get the location of the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_chassis_location host=111.222.333.444
                admin_username=root admin_password=secret

   salt.modules.dracr.get_chassis_name(host=None,     admin_username=None,
   admin_password=None)
          Get the name of a chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.get_chassis_name host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.get_slotname(slot,  host=None,  admin_username=None,
   admin_password=None)
          Get the name of a slot number in the chassis.

          slot   The number of the slot for which to obtain the name.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt-call --local dracr.get_slotname 0 host=111.222.333.444
                admin_username=root admin_password=secret

   salt.modules.dracr.idrac_general(blade_name,                   command,
   idrac_password=None,          host=None,           admin_username=None,
   admin_password=None)
          Run  a  generic  racadm  command against a particular blade in a
          chassis.  Blades  are  usually  named  things  like  'server-1',
          'server-2', etc.  If the iDRAC has a different password than the
          CMC, then you can pass it with the idrac_password kwarg.

          Parameters

                 * blade_name -- Name of the blade to run the command on

                 * command -- Command like to pass to racadm

                 * idrac_password -- Password for the iDRAC  if  different
                   from the CMC

                 * host -- Chassis hostname

                 * admin_username -- CMC username

                 * admin_password -- CMC password

          Returns
                 stdout   if  the  retcode  is  0,  otherwise  a  standard
                 cmd.run_all dictionary

          CLI Example:

             salt fx2 chassis.cmd idrac_general server-1 'get BIOS.SysProfileSettings'

   salt.modules.dracr.list_slotnames(host=None,       admin_username=None,
   admin_password=None)
          List the names of all slots in the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt-call --local dracr.list_slotnames host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.list_users(host=None,           admin_username=None,
   admin_password=None, module=None)
          List all DRAC users

          CLI Example:

             salt dell dracr.list_users

   salt.modules.dracr.nameservers(ns,   host=None,    admin_username=None,
   admin_password=None, module=None)
          Configure the nameservers on the DRAC

          CLI Example:

             salt dell dracr.nameservers [NAMESERVERS]
             salt dell dracr.nameservers ns1.example.com ns2.example.com
                 admin_username=root admin_password=calvin module=server-1
                 host=192.168.1.1

   salt.modules.dracr.network_info(host=None,         admin_username=None,
   admin_password=None, module=None)
          Return Network Configuration

          CLI Example:

             salt dell dracr.network_info

   salt.modules.dracr.server_hardreset(host=None,     admin_username=None,
   admin_password=None, module=None)
          Performs a reset (reboot) operation on the managed server.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          module The element to hard reset on the chassis such as a blade.
                 If not provided, the chassis will be reset.

          CLI Example:

             salt dell dracr.server_hardreset
             salt dell dracr.server_hardreset module=server-1

   salt.modules.dracr.server_power(status, host=None, admin_username=None,
   admin_password=None, module=None)

          status One of 'powerup', 'powerdown', 'powercycle', 'hardreset',
                 'graceshutdown'

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          module The element to reboot on the chassis such as a blade.  If
                 not provided, the chassis will be rebooted.

          CLI Example:

             salt dell dracr.server_reboot
             salt dell dracr.server_reboot module=server-1

   salt.modules.dracr.server_poweroff(host=None,      admin_username=None,
   admin_password=None, module=None)
          Powers down the managed server.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          module The element to power off on the chassis such as a  blade.
                 If not provided, the chassis will be powered off.

          CLI Example:

             salt dell dracr.server_poweroff
             salt dell dracr.server_poweroff module=server-1

   salt.modules.dracr.server_poweron(host=None,       admin_username=None,
   admin_password=None, module=None)
          Powers up the managed server.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          module The element to power on located on the chassis such as  a
                 blade. If not provided, the chassis will be powered on.

          CLI Example:

             salt dell dracr.server_poweron
             salt dell dracr.server_poweron module=server-1

   salt.modules.dracr.server_powerstatus(host=None,   admin_username=None,
   admin_password=None, module=None)
          return the power status for the passed module

          CLI Example:

             salt dell drac.server_powerstatus

   salt.modules.dracr.server_pxe(host=None,           admin_username=None,
   admin_password=None)
          Configure server to PXE perform a one off PXE boot

          CLI Example:

             salt dell dracr.server_pxe

   salt.modules.dracr.server_reboot(host=None,        admin_username=None,
   admin_password=None, module=None)
          Issues a power-cycle  operation  on  the  managed  server.  This
          action  is  similar to pressing the power button on the system's
          front panel to power down and then power up the system.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          module The element to reboot on the chassis such as a blade.  If
                 not provided, the chassis will be rebooted.

          CLI Example:

             salt dell dracr.server_reboot
             salt dell dracr.server_reboot module=server-1

   salt.modules.dracr.set_chassis_datacenter(location,          host=None,
   admin_username=None, admin_password=None)
          Set the location of the chassis.

          location
                 The name of the datacenter to be set on the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_chassis_datacenter datacenter-name host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.set_chassis_location(location,            host=None,
   admin_username=None, admin_password=None)
          Set the location of the chassis.

          location
                 The name of the location to be set on the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_chassis_location location-name host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.set_chassis_name(name,                    host=None,
   admin_username=None, admin_password=None)
          Set the name of the chassis.

          name   The name to be set on the chassis.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_chassis_name my-chassis host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.set_network(ip,   netmask,    gateway,    host=None,
   admin_username=None, admin_password=None)
          Configure   Network   on  the  CMC  or  individual  iDRAC.   Use
          set_niccfg for blade and switch addresses.

          CLI Example:

             salt dell dracr.set_network [DRAC IP] [NETMASK] [GATEWAY]
             salt dell dracr.set_network 192.168.0.2 255.255.255.0 192.168.0.1
                 admin_username=root admin_password=calvin host=192.168.1.1

   salt.modules.dracr.set_permissions(username,   permissions,   uid=None,
   host=None, admin_username=None, admin_password=None)
          Configure users permissions

          CLI Example:

             salt dell dracr.set_permissions [USERNAME] [PRIVILEGES]
                  [USER INDEX - optional]
             salt dell dracr.set_permissions diana login,test_alerts,clear_logs 4

          DRAC Privileges

                 * login                   : Login to iDRAC

                 * drac                    : Configure iDRAC

                 * user_management         : Configure Users

                 * clear_logs              : Clear Logs

                 * server_control_commands   :   Execute   Server  Control
                   Commands

                 * console_redirection     : Access Console Redirection

                 * virtual_media           : Access Virtual Media

                 * test_alerts             : Test Alerts

                 * debug_commands          : Execute Debug Commands

   salt.modules.dracr.set_slotname(slot,         name,          host=None,
   admin_username=None, admin_password=None)
          Set the name of a slot in a chassis.

          slot   The slot number to change.

          name   The name to set. Can only be 15 characters long.

          host   The chassis host.

          admin_username
                 The username used to access the chassis.

          admin_password
                 The password used to access the chassis.

          CLI Example:

             salt '*' dracr.set_slotname 2 my-slotname host=111.222.333.444
                 admin_username=root admin_password=secret

   salt.modules.dracr.set_snmp(community,  host=None, admin_username=None,
   admin_password=None)
          Configure CMC or individual iDRAC SNMP  community  string.   Use
          deploy_snmp for configuring chassis switch SNMP.

          CLI Example:

             salt dell dracr.set_snmp [COMMUNITY]
             salt dell dracr.set_snmp public

   salt.modules.dracr.syslog(server,        enable=True,        host=None,
   admin_username=None, admin_password=None, module=None)
          Configure  syslog  remote  logging,  by  default   syslog   will
          automatically  be  enabled if a server is specified. However, if
          you want to disable syslog you will need  to  specify  a  server
          followed by False

          CLI Example:

             salt dell dracr.syslog [SYSLOG IP] [ENABLE/DISABLE]
             salt dell dracr.syslog 0.0.0.0 False

   salt.modules.dracr.system_info(host=None,          admin_username=None,
   admin_password=None, module=None)
          Return System information

          CLI Example:

             salt dell dracr.system_info

   salt.modules.dracr.update_firmware(filename,                 host=None,
   admin_username=None, admin_password=None)
          Updates firmware using local firmware file

             salt dell dracr.update_firmware firmware.exe

          This  executes the following command on your FX2 (using username
          and password stored in the pillar data)

             racadm update --f firmware.exe -u user --p pass

   salt.modules.dracr.update_firmware_nfs_or_cifs(filename,         share,
   host=None, admin_username=None, admin_password=None)
          Executes  the  following  for  CIFS (using username and password
          stored in the pillar data)

             racadm update -f <updatefile> -u user --p pass -l //IP-Address/share

          Or for NFS (using username and password  stored  in  the  pillar
          data)

             racadm update -f <updatefile> -u user --p pass -l IP-address:/share

          Salt command for CIFS:

             salt dell dracr.update_firmware_nfs_or_cifs          firmware.exe //IP-Address/share

          Salt command for NFS:

             salt dell dracr.update_firmware_nfs_or_cifs          firmware.exe IP-address:/share

   salt.modules.drbd
   DRBD administration module

   salt.modules.drbd.overview()
          Show status of the DRBD devices

          CLI Example:

             salt '*' drbd.overview

   salt.modules.ebuild
   Support for Portage

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   optdepends

          * portage Python adapter

   For now all package names MUST include the package category, i.e. 'vim'
   will not work, 'app-editors/vim' will.

   salt.modules.ebuild.check_db(*names, **kwargs)
          New in version 0.17.0.

          Returns a dict containing the  following  information  for  each
          specified package:

          1. A  key  found,  which  will  be a boolean value denoting if a
             match was found in the package database.

          2. If found is False, then a second key called suggestions  will
             be  present,  which  will contain a list of possible matches.
             This list will be empty if the package name was specified  in
             category/pkgname  format,  since  the  suggestions  are  only
             intended  to  disambiguate  ambiguous  package  names   (ones
             submitted without a category).

          CLI Examples:

             salt '*' pkg.check_db <package1> <package2> <package3>

   salt.modules.ebuild.check_extra_requirements(pkgname, pkgver)
          Check   if   the   installed   package  already  has  the  given
          requirements.

          CLI Example:

             salt '*' pkg.check_extra_requirements 'sys-devel/gcc' '~>4.1.2:4.1::gentoo[nls,fortran]'

   salt.modules.ebuild.depclean(name=None,    slot=None,    fromrepo=None,
   pkgs=None)
          Portage  has  a  function  to  remove  unused dependencies. If a
          package is provided, it will only  removed  the  package  if  no
          other package depends on it.

          name   The name of the package to be cleaned.

          slot   Restrict  the  remove to a specific slot. Ignored if name
                 is None.

          fromrepo
                 Restrict the remove to a specific slot. Ignored  if  name
                 is None.

          pkgs   Clean  multiple packages. slot and fromrepo arguments are
                 ignored if this argument is present. Must be passed as  a
                 python list.

          Return a list containing the removed packages:

          CLI Example:

             salt '*' pkg.depclean <package name>

   salt.modules.ebuild.ex_mod_init(low)
          If  the config option ebuild.enforce_nice_config is set to True,
          this  module  will   enforce   a   nice   tree   structure   for
          /etc/portage/package.*  configuration files.

          New  in version 0.17.0: Initial automatic enforcement added when
          pkg is used on a Gentoo system.

          Changed in version 2014.1.0-Hydrogen: Configure option added  to
          make this behaviour optional, defaulting to off.

          SEE ALSO:
             ebuild.ex_mod_init  is  called  automatically  when  a  state
             invokes    a    pkg    state    on    a    Gentoo     system.
             salt.states.pkg.mod_init()

             ebuild.ex_mod_init uses portage_config.enforce_nice_config to
             do                        the                        lifting.
             salt.modules.portage_config.enforce_nice_config()

          CLI Example:

             salt '*' pkg.ex_mod_init

   salt.modules.ebuild.install(name=None,     refresh=False,    pkgs=None,
   sources=None,  slot=None,   fromrepo=None,   uses=None,   binhost=None,
   **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any emerge commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Install  the  passed  package(s),  add  refresh=True to sync the
          portage tree before package is installed.

          name   The name of the package to be installed. Note  that  this
                 parameter  is  ignored  if  either "pkgs" or "sources" is
                 passed. Additionally, please note that  this  option  can
                 only  be  used to emerge a package from the portage tree.
                 To install a tbz2 package  manually,  use  the  "sources"
                 option described below.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 Whether   or   not   to  sync  the  portage  tree  before
                 installing.

          version
                 Install a specific version of the package, e.g. 1.0.9-r1.
                 Ignored if "pkgs" or "sources" is passed.

          slot   Similar  to  version,  but  specifies  a valid slot to be
                 installed. It will install the latest  available  version
                 in the specified slot.  Ignored if "pkgs" or "sources" or
                 "version" is passed.

                 CLI Example:

                    salt '*' pkg.install sys-devel/gcc slot='4.4'

          fromrepo
                 Similar to slot, but specifies the  repository  from  the
                 package  will  be  installed.  It will install the latest
                 available version in the specified  repository.   Ignored
                 if "pkgs" or "sources" or "version" is passed.

                 CLI Example:

                    salt '*' pkg.install salt fromrepo='gentoo'

          uses   Similar  to  slot,  but  specifies  a  list  of use flag.
                 Ignored if "pkgs" or "sources" or "version" is passed.

                 CLI Example:

                    salt '*' pkg.install sys-devel/gcc uses='["nptl","-nossp"]'

          Multiple Package Installation Options:

          pkgs   A list of packages to install from the portage tree. Must
                 be passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo","bar","~category/package:slot::repository[use]"]'

          sources
                 A  list  of tbz2 packages to install. Must be passed as a
                 list of dicts, with the keys being package names, and the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.tbz2"},{"bar": "salt://bar.tbz2"}]'

          binhost
                 has two options try and force.  try - tells emerge to try
                 and install the package from a configured binhost.  force
                 -  forces  emerge  to  install the package from a binhost
                 otherwise it fails out.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.ebuild.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.ebuild.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.ebuild.list_upgrades(refresh=True, backtrack=3, **kwargs)
          List all available package upgrades.

          refresh
                 Whether or not to sync the portage tree  before  checking
                 for upgrades.

          backtrack
                 Specifies  an  integer  number  of  times to backtrack if
                 dependency calculation fails due  to  a  conflict  or  an
                 unsatisfied dependency (default: 3).

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.ebuild.porttree_matches(name)
          Returns  a  list containing the matches for a given package name
          from the portage tree. Note that the  specific  version  of  the
          package  will  not  be  provided  for packages that have several
          versions in the portage tree, but rather the name of the package
          (i.e. "dev-python/paramiko").

   salt.modules.ebuild.purge(name=None,      slot=None,     fromrepo=None,
   pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any emerge commands spawned by Salt when the salt-minion
          service  is  restarted.  (see  KillMode  in  the systemd.kill(5)
          manpage  for   more   information).   If   desired,   usage   of
          systemd-run(1)  can  be  suppressed  by  setting a config option
          called systemd.scope, with a value of False (no quotes).

          Portage does not  have  a  purge,  this  function  calls  remove
          followed by depclean to emulate a purge process

          name   The name of the package to be deleted.

          slot   Restrict  the  remove to a specific slot. Ignored if name
                 is None.

          fromrepo
                 Restrict the remove to a specific slot. Ignored  if  name
                 is None.

          Multiple Package Options:

          pkgs   Uninstall  multiple packages. slot and fromrepo arguments
                 are ignored if this argument is present. Must  be  passed
                 as a python list.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package name> slot=4.4
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.ebuild.refresh_db()
          Updates  the  portage  tree  (emerge  --sync).  Uses eix-sync if
          available.

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.ebuild.remove(name=None,     slot=None,     fromrepo=None,
   pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any emerge commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Remove packages via emerge --unmerge.

          name   The name of the package to be deleted.

          slot   Restrict  the  remove to a specific slot. Ignored if name
                 is None.

          fromrepo
                 Restrict the remove to a specific slot. Ignored  if  name
                 is None.

          Multiple Package Options:

          pkgs   Uninstall  multiple packages. slot and fromrepo arguments
                 are ignored if this argument is present. Must  be  passed
                 as a python list.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package name> slot=4.4 fromrepo=gentoo
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.ebuild.update(pkg,        slot=None,        fromrepo=None,
   refresh=False, binhost=None)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any emerge commands spawned by Salt when the salt-minion
          service  is  restarted.  (see  KillMode  in  the systemd.kill(5)
          manpage  for   more   information).   If   desired,   usage   of
          systemd-run(1)  can  be  suppressed  by  setting a config option
          called systemd.scope, with a value of False (no quotes).

          Updates the passed package (emerge --update package)

          slot   Restrict the update to a particular slot. It will  update
                 to the latest version within the slot.

          fromrepo
                 Restrict  the  update to a particular repository. It will
                 update to the latest version within the repository.

          binhost
                 has two options try and force.  try - tells emerge to try
                 and install the package from a configured binhost.  force
                 - forces emerge to install the  package  from  a  binhost
                 otherwise it fails out.

          Return a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.update <package name>

   salt.modules.ebuild.upgrade(refresh=True, binhost=None, backtrack=3)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any emerge commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Run a full system upgrade (emerge -uDN @world)

          binhost
                 has two options try and force.  try - tells emerge to try
                 and install the package from a configured binhost.  force
                 -  forces  emerge  to  install the package from a binhost
                 otherwise it fails out.

          backtrack
                 Specifies an integer number  of  times  to  backtrack  if
                 dependency  calculation  fails  due  to  a conflict or an
                 unsatisfied dependency (default: 3).

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.ebuild.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.ebuild.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.ebuild.version_clean(version)
          Clean the version string removing extra data.

          CLI Example:

             salt '*' pkg.version_clean <version_string>

   salt.modules.ebuild.version_cmp(pkg1, pkg2, **kwargs)
          Do a cmp-style comparison on two packages. Return -1 if  pkg1  <
          pkg2,  0  if  pkg1 == pkg2, and 1 if pkg1 > pkg2. Return None if
          there was a problem making the comparison.

          CLI Example:

             salt '*' pkg.version_cmp '0.2.4-0' '0.2.4.1-0'

   salt.modules.eix
   Support for Eix

   salt.modules.eix.sync()
          Sync portage/overlay trees and update the eix database

          CLI Example:

             salt '*' eix.sync

   salt.modules.eix.update()
          Update the eix database

          CLI Example:

             salt '*' eix.update

   salt.modules.elasticsearch
   Elasticsearch - A distributed RESTful search and analytics server

   Module to provide Elasticsearch compatibility to Salt (compatible  with
   Elasticsearch version 1.5.2+)

   New in version 2015.8.0.

   depends
          elasticsearch-py

   configuration
          This  module  accepts connection configuration details either as
          parameters or as configuration settings in  /etc/salt/minion  on
          the relevant minions:

             elasticsearch:
               host: '10.10.10.100:9200'

             elasticsearch:
               hosts:
                 - '10.10.10.100:9200'
                 - '10.10.10.101:9200'
                 - '10.10.10.102:9200'

             elasticsearch:
               hosts:
                 - '10.10.10.100:9200'
               number_of_shards: 1
               number_of_replicas: 0
               functions_blacklist:
                 - 'saltutil.find_job'
                 - 'pillar.items'
                 - 'grains.items'

          This  data  can  also be passed into pillar. Options passed into
          opts will overwrite options passed into pillar.

   salt.modules.elasticsearch.alias_create(indices,   alias,   hosts=None,
   body=None, profile=None)
          Create an alias for a specific index/indices

          CLI example:

             salt myminion elasticsearch.alias_create testindex_v1 testindex

   salt.modules.elasticsearch.alias_delete(indices,  aliases,  hosts=None,
   body=None, profile=None)
          Delete an alias of an index

          CLI example:

             salt myminion elasticsearch.alias_delete testindex_v1 testindex

   salt.modules.elasticsearch.alias_exists(aliases,          indices=None,
   hosts=None, profile=None)
          Return a boolean indicating whether given alias exists

          CLI example:

             salt myminion elasticsearch.alias_exists testindex

   salt.modules.elasticsearch.alias_get(indices=None,        aliases=None,
   hosts=None, profile=None)
          Check for the existence of an alias and if it exists, return it

          CLI example:

             salt myminion elasticsearch.alias_get testindex

   salt.modules.elasticsearch.document_create(index, doc_type,  body=None,
   id=None, hosts=None, profile=None)
          Create a document in a specified index

          CLI example:

             salt myminion elasticsearch.document_create testindex doctype1 '{}'

   salt.modules.elasticsearch.document_delete(index,     doc_type,     id,
   hosts=None, profile=None)
          Delete a document from an index

          CLI example:

             salt myminion elasticsearch.document_delete testindex doctype1 AUx-384m0Bug_8U80wQZ

   salt.modules.elasticsearch.document_exists(index, id,  doc_type='_all',
   hosts=None, profile=None)
          Return a boolean indicating whether given document exists

          CLI example:

             salt myminion elasticsearch.document_exists testindex AUx-384m0Bug_8U80wQZ

   salt.modules.elasticsearch.document_get(index,   id,   doc_type='_all',
   hosts=None, profile=None)
          Check for the existence of a document and if it  exists,  return
          it

          CLI example:

             salt myminion elasticsearch.document_get testindex AUx-384m0Bug_8U80wQZ

   salt.modules.elasticsearch.index_create(index,  body=None,  hosts=None,
   profile=None)
          Create an index

          CLI example:

             salt myminion elasticsearch.index_create testindex

   salt.modules.elasticsearch.index_delete(index,              hosts=None,
   profile=None)
          Delete an index

          CLI example:

             salt myminion elasticsearch.index_delete testindex

   salt.modules.elasticsearch.index_exists(index,              hosts=None,
   profile=None)
          Return a boolean indicating whether given index exists

          CLI example:

             salt myminion elasticsearch.index_exists testindex

   salt.modules.elasticsearch.index_get(index, hosts=None, profile=None)
          Check for the existence of an index and if it exists, return it

          CLI example:

             salt myminion elasticsearch.index_get testindex

   salt.modules.elasticsearch.index_template_create(name,            body,
   hosts=None, profile=None)
          Create an index template

          CLI example:

             salt myminion elasticsearch.index_template_create testindex_templ '{ "template": "logstash-*", "order": 1, "settings": { "number_of_shards": 1 } }'

   salt.modules.elasticsearch.index_template_delete(name,      hosts=None,
   profile=None)
          Delete an index template (type) along with its data

          CLI example:

             salt myminion elasticsearch.index_template_delete testindex_templ user

   salt.modules.elasticsearch.index_template_exists(name,      hosts=None,
   profile=None)
          Return a boolean indicating whether given index template exists

          CLI example:

             salt myminion elasticsearch.index_template_exists testindex_templ

   salt.modules.elasticsearch.index_template_get(name,         hosts=None,
   profile=None)
          Retrieve template definition of index or index/type

          CLI example:

             salt myminion elasticsearch.index_template_get testindex_templ user

   salt.modules.elasticsearch.mapping_create(index,    doc_type,     body,
   hosts=None, profile=None)
          Create a mapping in a given index

          CLI example:

             salt myminion elasticsearch.mapping_create testindex user '{ "user" : { "properties" : { "message" : {"type" : "string", "store" : true } } } }'

   salt.modules.elasticsearch.mapping_delete(index,  doc_type, hosts=None,
   profile=None)
          Delete a mapping (type) along with its data

          CLI example:

             salt myminion elasticsearch.mapping_delete testindex user

   salt.modules.elasticsearch.mapping_get(index,   doc_type,   hosts=None,
   profile=None)
          Retrieve mapping definition of index or index/type

          CLI example:

             salt myminion elasticsearch.mapping_get testindex user

   salt.modules.environ
   Support  for  getting  and  setting  the  environment  variables of the
   current salt process.

   salt.modules.environ.get(key, default='')
          Get a single salt process environment variable.

          key    String used as the key for environment lookup.

          default
                 If the key is not found in the environment,  return  this
                 value.  Default: ''

          CLI Example:

             salt '*' environ.get foo
             salt '*' environ.get baz default=False

   salt.modules.environ.has_value(key, value=None)
          Determine  whether  the  key  exists in the current salt process
          environment dictionary. Optionally compare the current value  of
          the environment against the supplied value string.

          key    Must be a string. Used as key for environment lookup.

          value: Optional.  If  key exists in the environment, compare the
                 current value with this value. Return True  if  they  are
                 equal.

          CLI Example:

             salt '*' environ.has_value foo

   salt.modules.environ.item(keys, default='')
          Get  one  or more salt process environment variables.  Returns a
          dict.

          keys   Either a string or a list of strings that will be used as
                 the keys for environment lookup.

          default
                 If  the  key is not found in the environment, return this
                 value.  Default: ''

          CLI Example:

             salt '*' environ.item foo
             salt '*' environ.item '[foo, baz]' default=None

   salt.modules.environ.items()
          Return a dict of the entire environment set for the salt process

          CLI Example:

             salt '*' environ.items

   salt.modules.environ.setenv(environ,                false_unsets=False,
   clear_all=False, update_minion=False, permanent=False)
          Set  multiple  salt  process  environment variables from a dict.
          Returns a dict.

          environ
                 Must be a dict. The top-level keys of the  dict  are  the
                 names  of  the  environment  variables to set. Each key's
                 value  must  be  a  string  or  False.   Refer   to   the
                 'false_unsets' parameter for behavior when a value set to
                 False.

          false_unsets
                 If a key's value is False and false_unsets is True,  then
                 the   key   will  be  removed  from  the  salt  processes
                 environment dict entirely. If a key's value is False  and
                 false_unsets  is  not  True, then the key's value will be
                 set to an empty string.  Default: False

          clear_all
                 USE WITH  CAUTION!  This  option  can  unset  environment
                 variables  needed  for  salt  to  function  properly.  If
                 clear_all is True, then  any  environment  variables  not
                 defined  in  the  environ dict will be deleted.  Default:
                 False

          update_minion
                 If  True,  apply  these  environ  changes  to  the   main
                 salt-minion  process.  If False, the environ changes will
                 only affect the current salt subprocess.  Default: False

          permanent
                 On Windows minions this will set the environment variable
                 in  the  registry  so  that  it  is  always  added  as  a
                 environment variable when applications open. If you  want
                 to  set the variable to HKLM instead of HKCU just pass in
                 "HKLM" for this parameter. On all other minion types this
                 will  be  ignored.  Note:  This  will only take affect on
                 applications opened after this has been set.

          CLI Example:

             salt '*' environ.setenv '{"foo": "bar", "baz": "quux"}'
             salt '*' environ.setenv '{"a": "b", "c": False}' false_unsets=True

   salt.modules.environ.setval(key,        val,        false_unsets=False,
   permanent=False)
          Set  a single salt process environment variable. Returns True on
          success.

          key    The environment key to set. Must be a string.

          val    The value to set. Must be a string or False. Refer to the
                 'false_unsets' parameter for behavior when set to False.

          false_unsets
                 If  val  is  False and false_unsets is True, then the key
                 will be removed from the salt processes environment  dict
                 entirely.   If val is False and false_unsets is not True,
                 then the key's value will be  set  to  an  empty  string.
                 Default: False.

          permanent
                 On Windows minions this will set the environment variable
                 in  the  registry  so  that  it  is  always  added  as  a
                 environment  variable when applications open. If you want
                 to set the variable to HKLM instead of HKCU just pass  in
                 "HKLM" for this parameter. On all other minion types this
                 will be ignored. Note: This  will  only  take  affect  on
                 applications opened after this has been set.

          CLI Example:

             salt '*' environ.setval foo bar
             salt '*' environ.setval baz val=False false_unsets=True
             salt '*' environ.setval baz bar permanent=True
             salt '*' environ.setval baz bar permanent=HKLM

   salt.modules.eselect
   Support for eselect, Gentoo's configuration and management tool.

   salt.modules.eselect.exec_action(module, action, module_parameter=None,
   action_parameter=None, state_only=False)
          Execute an arbitrary action on a module.

          module name of the module to be executed

          action name of the module's action to be run

          module_parameter
                 additional params passed to the defined module

          action_parameter
                 additional params passed to the defined action

          state_only
                 don't return any output but only the  success/failure  of
                 the operation

          CLI Example (updating the php implementation used for apache2):

             salt '*' eselect.exec_action php update action_parameter='apache2'

   salt.modules.eselect.get_current_target(module,  module_parameter=None,
   action_parameter=None)
          Get the currently selected target for the given module.

          module name of the module to be queried for its current target

          module_parameter
                 additional params passed to the defined module

          action_parameter
                 additional params passed to the 'show' action

          CLI Example (current target of system-wide java-vm):

             salt '*' eselect.get_current_target java-vm action_parameter='system'

          CLI Example (current target of kernel symlink):

             salt '*' eselect.get_current_target kernel

   salt.modules.eselect.get_modules()
          List available eselect modules.

          CLI Example:

             salt '*' eselect.get_modules

   salt.modules.eselect.get_target_list(module, action_parameter=None)
          List available targets for the given module.

          module name of the module to be queried for its targets

          action_parameter
                 additional params passed to the defined action

                 New in version 2016.11.0.

          CLI Example:

             salt '*' eselect.get_target_list kernel

   salt.modules.eselect.set_target(module, target,  module_parameter=None,
   action_parameter=None)
          Set the target for the given module.  Target can be specified by
          index or name.

          module name of the module for which a target should be set

          target name of the target to be set for this module

          module_parameter
                 additional params passed to the defined module

          action_parameter
                 additional params passed to the defined action

          CLI Example (setting target of system-wide java-vm):

             salt '*' eselect.set_target java-vm icedtea-bin-7 action_parameter='system'

          CLI Example (setting target of kernel symlink):

             salt '*' eselect.set_target kernel linux-3.17.5-gentoo

   salt.modules.esxi
   Glues the VMware vSphere Execution Module  to  the  VMware  ESXi  Proxy
   Minions to the esxi proxymodule.

   New in version 2015.8.4.

   Depends: vSphere Remote Execution Module (salt.modules.vsphere)

   For  documentation  on commands that you can direct to an ESXi host via
   proxy, look in the documentation for salt.modules.vsphere.

   This execution module calls through to a function  in  the  ESXi  proxy
   module  called  ch_config,  which  looks  up the function passed in the
   command parameter in salt.modules.vsphere and calls it.

   To execute commands  with  an  ESXi  Proxy  Minion  using  the  vSphere
   Execution Module, use the esxi.cmd <vsphere-function-name> syntax. Both
   args and kwargs needed for various vsphere execution  module  functions
   must be passed through in a kwarg- type manor.

      salt 'esxi-proxy' esxi.cmd system_info
      salt 'exsi-proxy' esxi.cmd get_service_policy service_name='ssh'

   salt.modules.etcd_mod
   Execution module to work with etcd

   depends

          * python-etcd

   Configuration
   To  work  with  an  etcd server you must configure an etcd profile. The
   etcd config can be set in either the Salt Minion configuration file  or
   in pillar:

      my_etd_config:
        etcd.host: 127.0.0.1
        etcd.port: 4001

   It  is  technically possible to configure etcd without using a profile,
   but this is not considered to  be  a  best  practice,  especially  when
   multiple etcd servers or clusters are available.

      etcd.host: 127.0.0.1
      etcd.port: 4001

   NOTE:
      The  etcd  configuration  can  also be set in the Salt Master config
      file, but in order to use any etcd  configurations  defined  in  the
      Salt Master config, the pillar_opts must be set to True.

      Be  aware that setting pillar_opts to True has security implications
      as this makes all master configuration  settings  available  in  all
      minion's pillars.

   salt.modules.etcd_mod.get(key, recurse=False, profile=None)
          New in version 2014.7.0.

          Get a value from etcd, by direct path.  Returns None on failure.

          CLI Examples:

             salt myminion etcd.get /path/to/key
             salt myminion etcd.get /path/to/key profile=my_etcd_config
             salt myminion etcd.get /path/to/key recurse=True profile=my_etcd_config

   salt.modules.etcd_mod.ls(path='/', profile=None)
          New in version 2014.7.0.

          Return  all  keys  and  dirs  inside a specific path. Returns an
          empty dict on failure.

          CLI Example:

             salt myminion etcd.ls /path/to/dir/
             salt myminion etcd.ls /path/to/dir/ profile=my_etcd_config

   salt.modules.etcd_mod.rm(key, recurse=False, profile=None)
          New in version 2014.7.0.

          Delete a key from etcd.  Returns True if the  key  was  deleted,
          False if it wasn not and None if there was a failure.

          CLI Example:

             salt myminion etcd.rm /path/to/key
             salt myminion etcd.rm /path/to/key profile=my_etcd_config
             salt myminion etcd.rm /path/to/dir recurse=True profile=my_etcd_config

   salt.modules.etcd_mod.set(key,     value,    profile=None,    ttl=None,
   directory=False)
          New in version 2014.7.0.

          Set a key in etcd by direct path. Optionally, create a directory
          or set a TTL on the key.  Returns None on failure.

          CLI Example:

             salt myminion etcd.set /path/to/key value
             salt myminion etcd.set /path/to/key value profile=my_etcd_config
             salt myminion etcd.set /path/to/dir '' directory=True
             salt myminion etcd.set /path/to/key value ttl=5

   salt.modules.etcd_mod.tree(path='/', profile=None)
          New in version 2014.7.0.

          Recurse  through  etcd  and  return all values.  Returns None on
          failure.

          CLI Example:

             salt myminion etcd.tree
             salt myminion etcd.tree profile=my_etcd_config
             salt myminion etcd.tree /path/to/keys profile=my_etcd_config

   salt.modules.etcd_mod.update(fields, path='', profile=None)
          New in version 2016.3.0.

          Sets a dictionary of values  in  one  call.   Useful  for  large
          updates  in  syndic  environments.  The dictionary can contain a
          mix of formats such as:

             {
               '/some/example/key': 'bar',
               '/another/example/key': 'baz'
             }

          Or it may be a straight dictionary, which will be  flattened  to
          look like the above format:

             {
                 'some': {
                     'example': {
                         'key': 'bar'
                     }
                 },
                 'another': {
                     'example': {
                         'key': 'baz'
                     }
                 }
             }

          You can even mix the two formats and it will be flattened to the
          first format.  Leading and trailing '/' will be removed.

          Empty directories can be created by setting the value of the key
          to an empty dictionary.

          The 'path' parameter will optionally set the root of the path to
          use.

          CLI Example:

             salt myminion etcd.update "{'/path/to/key': 'baz', '/another/key': 'bar'}"
             salt myminion etcd.update "{'/path/to/key': 'baz', '/another/key': 'bar'}" profile=my_etcd_config
             salt myminion etcd.update "{'/path/to/key': 'baz', '/another/key': 'bar'}" path='/some/root'

   salt.modules.etcd_mod.watch(key,      recurse=False,      profile=None,
   timeout=0, index=None)
          New in version 2016.3.0.

          Makes  a  best effort to watch for a key or tree change in etcd.
          Returns a dict containing the new key value ( or None if the key
          was  deleted  ),  the  modifiedIndex of the key, whether the key
          changed or not, the path to the key that changed and whether  it
          is a directory or not.

          If something catastrophic happens, returns {}

          CLI Example:

             salt myminion etcd.watch /path/to/key
             salt myminion etcd.watch /path/to/key timeout=10
             salt myminion etcd.watch /patch/to/key profile=my_etcd_config index=10

   salt.modules.ethtool module
   Module for running ethtool command

   New in version 2016.3.0.

   codeauthor
          Krzysztof Pawlowski <[email protected]>

   maturity
          new

   depends
          python-ethtool

   platform
          linux

   salt.modules.ethtool.set_coalesce(devname, **kwargs)
          Changes the coalescing settings of the specified network device

          CLI Example:

             salt '*' ethtool.set_coalesce <devname> [adaptive_rx=on|off] [adaptive_tx=on|off] [rx_usecs=N] [rx_frames=N]
                 [rx_usecs_irq=N] [rx_frames_irq=N] [tx_usecs=N] [tx_frames=N] [tx_usecs_irq=N] [tx_frames_irq=N]
                 [stats_block_usecs=N] [pkt_rate_low=N] [rx_usecs_low=N] [rx_frames_low=N] [tx_usecs_low=N] [tx_frames_low=N]
                 [pkt_rate_high=N] [rx_usecs_high=N] [rx_frames_high=N] [tx_usecs_high=N] [tx_frames_high=N]
                 [sample_interval=N]

   salt.modules.ethtool.set_offload(devname, **kwargs)
          Changes  the  offload  parameters  and  other  features  of  the
          specified network device

          CLI Example:

             salt '*' ethtool.set_offload <devname> tcp_segmentation_offload=on

   salt.modules.ethtool.set_ring(devname, **kwargs)
          Changes the rx/tx  ring  parameters  of  the  specified  network
          device

          CLI Example:

             salt '*' ethtool.set_ring <devname> [rx=N] [rx_mini=N] [rx_jumbo=N] [tx=N]

   salt.modules.ethtool.show_coalesce(devname)
          Queries the specified network device for coalescing information

          CLI Example:

             salt '*' ethtool.show_coalesce <devname>

   salt.modules.ethtool.show_driver(devname)
          Queries  the  specified  network  device  for  associated driver
          information

          CLI Example:

             salt '*' ethtool.show_driver <devname>

   salt.modules.ethtool.show_offload(devname)
          Queries the specified network device for the state  of  protocol
          offload and other features

          CLI Example:

             salt '*' ethtool.show_offload <devname>

   salt.modules.ethtool.show_ring(devname)
          Queries  the  specified  network device for rx/tx ring parameter
          information

          CLI Example:

             salt '*' ethtool.show_ring <devname>

   salt.modules.event
   Use the Salt Event System to fire events from the master to the  minion
   and vice-versa.

   salt.modules.event.fire(data, tag)
          Fire an event on the local minion event bus. Data must be formed
          as a dict.

          CLI Example:

             salt '*' event.fire '{"data":"my event data"}' 'tag'

   salt.modules.event.fire_master(data, tag, preload=None)
          Fire an event off up to the master server

          CLI Example:

             salt '*' event.fire_master '{"data":"my event data"}' 'tag'

   salt.modules.event.send(tag, data=None,  preload=None,  with_env=False,
   with_grains=False, with_pillar=False, with_env_opts=False, **kwargs)
          Send an event to the Salt Master

          New in version 2014.7.0.

          Parameters

                 * tag  -- A tag to give the event.  Use slashes to create
                   a    namespace    for     related     events.     E.g.,
                   myco/build/buildserver1/start,
                   myco/build/buildserver1/success,
                   myco/build/buildserver1/failure.

                 * data  --  A  dictionary  of  data to send in the event.
                   This is free-form. Send any data points that are needed
                   for  whoever  is  consuming the event. Arguments on the
                   CLI are interpreted as YAML so complex data  structures
                   are possible.

                 * with_env  (Specify  True  to  include  all  environment
                   variables, or specify a list  of  strings  of  variable
                   names  to  include.)  --  Include environment variables
                   from the current shell environment in the event data as
                   environ.. This is a short-hand for working with systems
                   that seed the environment with relevant  data  such  as
                   Jenkins.

                 * with_grains  (Specify  True  to  include all grains, or
                   specify a list of strings of grain names  to  include.)
                   --  Include grains from the current minion in the event
                   data as grains.

                 * with_pillar (Specify True to include all Pillar values,
                   or specify a list of strings of Pillar keys to include.
                   It is a best-practice to only specify a relevant subset
                   of  Pillar  data.)  --  Include  Pillar values from the
                   current minion in the event data  as  pillar.  Remember
                   Pillar data is often sensitive data so be careful. This
                   is useful for passing ephemeral Pillar  values  through
                   an  event.  Such  as  passing  the  pillar={}  kwarg in
                   state.sls from the Master,  through  an  event  on  the
                   Minion, then back to the Master.

                 * with_env_opts  (Specify  True  to  include  saltenv and
                   pillarenv values or False to  omit  them.)  --  Include
                   saltenv  and pillarenv set on minion at the moment when
                   event is send into event data.

                 * kwargs -- Any additional keyword  arguments  passed  to
                   this  function  will  be interpreted as key-value pairs
                   and included  in  the  event  data.   This  provides  a
                   convenient alternative to YAML for simple values.

          CLI Example:

             salt-call event.send myco/mytag foo=Foo bar=Bar
             salt-call event.send 'myco/mytag' '{foo: Foo, bar: Bar}'

          A  convenient  way  to allow Jenkins to execute salt-call is via
          sudo. The following rule in sudoers will allow the jenkins  user
          to run only the following command.

          /etc/sudoers (allow preserving the environment):

             jenkins ALL=(ALL) NOPASSWD:SETENV: /usr/bin/salt-call event.send*

          Call Jenkins via sudo (preserve the environment):

             sudo -E salt-call event.send myco/jenkins/build/success with_env=[BUILD_ID, BUILD_URL, GIT_BRANCH, GIT_COMMIT]

   salt.modules.extfs
   Module for managing ext2/3/4 file systems

   salt.modules.extfs.attributes(device, args=None)
          Return attributes from dumpe2fs for a specified device

          CLI Example:

             salt '*' extfs.attributes /dev/sda1

   salt.modules.extfs.blocks(device, args=None)
          Return block and inode info from dumpe2fs for a specified device

          CLI Example:

             salt '*' extfs.blocks /dev/sda1

   salt.modules.extfs.dump(device, args=None)
          Return all contents of dumpe2fs for a specified device

          CLI Example:

             salt '*' extfs.dump /dev/sda1

   salt.modules.extfs.mkfs(device, fs_type, **kwargs)
          Create a file system on the specified device

          CLI Example:

             salt '*' extfs.mkfs /dev/sda1 fs_type=ext4 opts='acl,noexec'

          Valid options are:

          * block_size: 1024, 2048 or 4096

          * check: check for bad blocks

          * direct: use direct IO

          * ext_opts: extended file system options (comma-separated)

          * fragment_size: size of fragments

          * force:  setting force to True will cause mke2fs to specify the
            -F option twice (it  is  already  set  once);  this  is  truly
            dangerous

          * blocks_per_group: number of blocks in a block group

          * number_of_groups: ext4 option for a virtual block group

          * bytes_per_inode: set the bytes/inode ratio

          * inode_size: size of the inode

          * journal: set to True to create a journal (default on ext3/4)

          * journal_opts: options for the fs journal (comma separated)

          * blocks_file: read bad blocks from file

          * label: label to apply to the file system

          * reserved: percentage of blocks reserved for super-user

          * last_dir: last mounted directory

          * test:  set  to  True  to  not  actually create the file system
            (mke2fs -n)

          * number_of_inodes: override default number of inodes

          * creator_os: override "creator operating system" field

          * opts: mount options (comma separated)

          * revision: set the filesystem revision (default 1)

          * super: write superblock and group descriptors only

          * fs_type: set the filesystem type (REQUIRED)

          * usage_type: how the filesystem is going to be used

          * uuid: set the UUID for the file system

          See the mke2fs(8) manpage for a  more  complete  description  of
          these options.

   salt.modules.extfs.tune(device, **kwargs)
          Set attributes for the specified device (using tune2fs)

          CLI Example:

             salt '*' extfs.tune /dev/sda1 force=True label=wildstallyns opts='acl,noexec'

          Valid options are:

          * max: max mount count

          * count: mount count

          * error: error behavior

          * extended_opts: extended options (comma separated)

          * force: force, even if there are errors (set to True)

          * group: group name or gid that can use the reserved blocks

          * interval: interval between checks

          * journal: set to True to create a journal (default on ext3/4)

          * journal_opts: options for the fs journal (comma separated)

          * label: label to apply to the file system

          * reserved: percentage of blocks reserved for super-user

          * last_dir: last mounted directory

          * opts: mount options (comma separated)

          * feature: set or clear a feature (comma separated)

          * mmp_check: mmp check interval

          * reserved: reserved blocks count

          * quota_opts: quota options (comma separated)

          * time: time last checked

          * user: user or uid who can use the reserved blocks

          * uuid: set the UUID for the file system

          See  the  mke2fs(8)  manpage  for a more complete description of
          these options.

   salt.modules.file
   Manage information about regular files, directories, and special  files
   on the minion, set/read user, group, mode, and data

   salt.modules.file.access(path, mode)
          New in version 2014.1.0.

          Test  whether  the  Salt process has the specified access to the
          file. One of the following modes must be specified:

          CLI Example:

             salt '*' file.access /path/to/file f
             salt '*' file.access /path/to/file x

   salt.modules.file.append(path, *args, **kwargs)
          New in version 0.9.5.

          Append text to the end of a file

          path   path to file

          *args  strings to append to file

          CLI Example:

             salt '*' file.append /etc/motd \
                     "With all thine offerings thou shalt offer salt." \
                     "Salt is what makes things taste bad when it isn't in them."

             Attention

                    If you need to pass a string to append and that string
                    contains  an equal sign, you must include the argument
                    name, args.  For example:

                 salt '*' file.append /etc/motd args='cheese=spam'

                 salt '*' file.append /etc/motd args="['cheese=spam','spam=cheese']"

   salt.modules.file.apply_template_on_contents(contents,        template,
   context, defaults, saltenv)
          Return the contents after applying the templating engine

          contents
                 template string

          template
                 template format

          context
                 Overrides   default   context  variables  passed  to  the
                 template.

          defaults
                 Default context passed to the template.

          CLI Example:

             salt '*' file.apply_template_on_contents \
                 contents='This is a {{ template }} string.' \
                 template=jinja \
                 "context={}" "defaults={'template': 'cool'}" \
                 saltenv=base

   salt.modules.file.basename(path)
          Returns the final component of a pathname

          New in version 2015.5.0.

          This can be useful at the CLI  but  is  frequently  useful  when
          scripting.

             {%- set filename = salt['file.basename'](source_file) %}

          CLI Example:

             salt '*' file.basename 'test/test.config'

   salt.modules.file.blockreplace(path,  marker_start='#--  start  managed
   zone  --',  marker_end='#--   end   managed   zone   --',   content='',
   append_if_not_found=False,  prepend_if_not_found=False,  backup='.bak',
   dry_run=False, show_changes=True, append_newline=False)
          New in version 2014.1.0.

          Replace content of a text block in a  file,  delimited  by  line
          markers

          A  block  of  content  delimited by comments can help you manage
          several  lines  entries  without  worrying  about  old   entries
          removal.

          NOTE:
             This  function  will  store  two copies of the file in-memory
             (the original version and the edited  version)  in  order  to
             detect changes and only edit the targeted file if necessary.

          path   Filesystem path to the file to be edited

          marker_start
                 The  line  content identifying a line as the start of the
                 content block.  Note that the whole line containing  this
                 marker will be considered, so whitespace or extra content
                 before or after the marker is included in final output

          marker_end
                 The line content identifying a line as  the  end  of  the
                 content  block.  Note that the whole line containing this
                 marker will be considered, so whitespace or extra content
                 before or after the marker is included in final output

          content
                 The  content  to be used between the two lines identified
                 by marker_start and marker_stop.

          append_if_not_found
                 False If markers are not found and set to True then,  the
                 markers and content will be appended to the file.

          prepend_if_not_found
                 False  If markers are not found and set to True then, the
                 markers and content will be prepended to the file.

          backup The file extension to use for a backup of the file if any
                 edit is made.  Set to False to skip making a backup.

          dry_run
                 Don't make any edits to the file.

          show_changes
                 Output  a  unified diff of the old file and the new file.
                 If False, return a boolean if any changes were made.

          append_newline:
                 Append  a  newline  to  the  content  block.   For   more
                 information                                          see:
                 https://github.com/saltstack/salt/issues/33686

                 New in version 2016.3.4.

          CLI Example:

             salt '*' file.blockreplace /etc/hosts '#-- start managed zone foobar : DO NOT EDIT --' \
             '#-- end managed zone foobar --' $'10.0.1.1 foo.foobar\n10.0.1.2 bar.foobar' True

   salt.modules.file.check_file_meta(name, sfn, source, source_sum,  user,
   group, mode, saltenv, contents=None)
          Check for the changes in the file metadata.

          CLI Example:

             salt '*' file.check_file_meta /etc/httpd/conf.d/httpd.conf salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' root, root, '755' base

          NOTE:
             Supported  hash types include sha512, sha384, sha256, sha224,
             sha1, and md5.

          name   Path to file destination

          sfn    Template-processed source file contents

          source URL to file source

          source_sum
                 File checksum information as a dictionary

                    {hash_type: md5, hsum: <md5sum>}

          user   Destination file user owner

          group  Destination file group owner

          mode   Destination file permissions mode

          saltenv
                 Salt environment used to resolve source files

          contents
                 File contents

   salt.modules.file.check_hash(path, file_hash)
          Check if a file matches the given hash string

          Returns true  if  the  hash  matched,  otherwise  false.  Raises
          ValueError if the hash was not formatted correctly.

          path   A file path

          hash   A   string  in  the  form  <hash_type>:<hash_value>.  For
                 example: md5:e138491e9d5b97023cea823fe17bac22

          CLI Example:

             salt '*' file.check_hash /etc/fstab md5:<md5sum>

   salt.modules.file.check_managed(name,       source,        source_hash,
   source_hash_name,  user,  group,  mode,  template,  context,  defaults,
   saltenv, contents=None, skip_verify=False, **kwargs)
          Check to see what changes need to be made for a file

          CLI Example:

             salt '*' file.check_managed /etc/httpd/conf.d/httpd.conf salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' root, root, '755' jinja True None None base

   salt.modules.file.check_managed_changes(name,   source,    source_hash,
   source_hash_name,  user,  group,  mode,  template,  context,  defaults,
   saltenv, contents=None, skip_verify=False, keep_mode=False, **kwargs)
          Return a dictionary of what changes need to be made for a file

          CLI Example:

             salt '*' file.check_managed_changes /etc/httpd/conf.d/httpd.conf salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' root, root, '755' jinja True None None base

   salt.modules.file.check_perms(name,    ret,    user,    group,    mode,
   follow_symlinks=False)
          Check the permissions on files and chown if needed

          CLI Example:

             salt '*' file.check_perms /etc/sudoers '{}' root root 400

          Changed in version 2014.1.3: follow_symlinks option added

   salt.modules.file.chgrp(path, group)
          Change the group of a file

          path   path to the file or directory

          group  group owner

          CLI Example:

             salt '*' file.chgrp /etc/passwd root

   salt.modules.file.chown(path, user, group)
          Chown a file, pass the file the desired user and group

          path   path to the file or directory

          user   user owner

          group  group owner

          CLI Example:

             salt '*' file.chown /etc/passwd root root

   salt.modules.file.comment(path, regex, char='#', backup='.bak')
          Deprecated since version 0.17.0: Use replace() instead.

          Comment out specified lines in a file

          path   The full path to the file to be edited

          regex  A  regular  expression used to find the lines that are to
                 be commented; this pattern will be wrapped in parenthesis
                 and  will  move  any preceding/trailing ^ or $ characters
                 outside the parenthesis (e.g., the pattern ^foo$ will  be
                 rewritten as ^(foo)$)

          char   # The character to be inserted at the beginning of a line
                 in order to comment it out

          backup .bak The file will be backed up  before  edit  with  this
                 file extension

                 WARNING:
                    This  backup  will  be  overwritten  each  time  sed /
                    comment / uncomment is called. Meaning the backup will
                    only be useful after the first invocation.

          CLI Example:

             salt '*' file.comment /etc/modules pcspkr

   salt.modules.file.comment_line(path,    regex,   char='#',   cmnt=True,
   backup='.bak')
          Comment or Uncomment a line in a text file.

          Parameters

                 * path -- string The full path to the text file.

                 * regex -- string A regex expression that begins  with  ^
                   that  will find the line you wish to comment. Can be as
                   simple as ^color =

                 * char -- string The character used to comment a line  in
                   the type of file you're referencing.  Default is #

                 * cmnt  --  boolean  True  to  comment the line. False to
                   uncomment the line. Default is True.

                 * backup -- string The file extension to give the  backup
                   file.  Default  is .bak Set to False/None to not keep a
                   backup.

          Returns
                 boolean Returns True if successful, False if not

          CLI Example:

          The following example will comment out the pcspkr  line  in  the
          /etc/modules  file  using  the  default # character and create a
          backup file named modules.bak

             salt '*' file.comment_line '/etc/modules' '^pcspkr'

          CLI Example:

          The following example will uncomment the  log_level  setting  in
          minion  config  file  if  it  is set to either warning, info, or
          debug using the # character  and  create  a  backup  file  named
          minion.bk

             salt '*' file.comment_line 'C:\salt\conf\minion' '^log_level: (warning|info|debug)' '#' False '.bk'

   salt.modules.file.contains(path, text)
          Deprecated since version 0.17.0: Use search() instead.

          Return True if the file at path contains text

          CLI Example:

             salt '*' file.contains /etc/crontab 'mymaintenance.sh'

   salt.modules.file.contains_glob(path, glob_expr)
          Deprecated since version 0.17.0: Use search() instead.

          Return True if the given glob matches a string in the named file

          CLI Example:

             salt '*' file.contains_glob /etc/foobar '*cheese*'

   salt.modules.file.contains_regex(path, regex, lchar='')
          Deprecated since version 0.17.0: Use search() instead.

          Return  True if the given regular expression matches on any line
          in the text of a given file.

          If the lchar argument (leading char) is specified, it will strip
          lchar from the left side of each line before trying to match

          CLI Example:

             salt '*' file.contains_regex /etc/crontab

   salt.modules.file.copy(src, dst, recurse=False, remove_existing=False)
          Copy a file or directory from source to dst

          In  order to copy a directory, the recurse flag is required, and
          will by default overwrite files in the destination with the same
          path,  and retain all other existing files. (similar to cp -r on
          unix)

          remove_existing will remove all files in the  target  directory,
          and then copy files from the source.

          NOTE:
             The  copy  function  accepts paths that are local to the Salt
             minion.  This function does not support salt://, http://,  or
             the  other  additional  file  paths  that  are  supported  by
             states.file.managed and states.file.recurse.

          CLI Example:

             salt '*' file.copy /path/to/src /path/to/dst
             salt '*' file.copy /path/to/src_dir /path/to/dst_dir recurse=True
             salt '*' file.copy /path/to/src_dir /path/to/dst_dir recurse=True remove_existing=True

   salt.modules.file.delete_backup(path, backup_id)
          New in version 0.17.0.

          Delete a previous version of a file that  was  backed  up  using
          Salt's file state backup system.

          path   The path on the minion to check for backups

          backup_id
                 The  numeric  id  for  the  backup you wish to delete, as
                 found using file.list_backups

          CLI Example:

             salt '*' file.delete_backup /var/cache/salt/minion/file_backup/home/foo/bar/baz.txt 0

   salt.modules.file.directory_exists(path)
          Tests to see if path is a valid directory.  Returns True/False.

          CLI Example:

             salt '*' file.directory_exists /etc

   salt.modules.file.dirname(path)
          Returns the directory component of a pathname

          New in version 2015.5.0.

          This can be useful at the CLI  but  is  frequently  useful  when
          scripting.

             {%- from salt['file.dirname'](tpldir) + '/vars.jinja' import parent_vars %}

          CLI Example:

             salt '*' file.dirname 'test/path/filename.config'

   salt.modules.file.diskusage(path)
          Recursively calculate disk usage of path and return it in bytes

          CLI Example:

             salt '*' file.diskusage /path/to/check

   salt.modules.file.extract_hash(hash_fn,             hash_type='sha256',
   file_name='', source='', source_hash_name=None)
          Changed in version 2016.3.5: Prior to  this  version,  only  the
          file_name  argument  was  considered for filename matches in the
          hash file. This would be problematic for cases in which the user
          was  relying on a remote checksum file that they do not control,
          and they wished to use a different name for  that  file  on  the
          minion  from  the  filename  on  the  remote  server (and in the
          checksum file). For example,  managing  /tmp/myfile.tar.gz  when
          the            remote            file           was           at
          https://mydomain.tld/different_name.tar.gz.   The   file.managed
          state  now  also  passes this function the source URI as well as
          the   source_hash_name   (if   specified).   In   cases    where
          source_hash_name is specified, it takes precedence over both the
          file_name and source. When it is not specified, file_name  takes
          precedence  over  source.  This allows for better capability for
          matching hashes.

          Changed in version 2016.11.0: File name and source  URI  matches
          are  no  longer  disregarded when source_hash_name is specified.
          They will be used as fallback matches if there is  no  match  to
          the source_hash_name value.

          This  routine  is  called  from the file.managed state to pull a
          hash from a remote file.  Regular expressions are used  line  by
          line  on  the source_hash file, to find a potential candidate of
          the indicated hash type. This avoids many problems of  arbitrary
          file  layout  rules.  It specifically permits pulling hash codes
          from debian *.dsc files.

          If no exact match of a hash and filename  are  found,  then  the
          first  hash found (if any) will be returned. If no hashes at all
          are found, then None will be returned.

          For example:

             openerp_7.0-latest-1.tar.gz:
               file.managed:
                 - name: /tmp/openerp_7.0-20121227-075624-1_all.deb
                 - source: http://nightly.openerp.com/7.0/nightly/deb/openerp_7.0-20121227-075624-1.tar.gz
                 - source_hash: http://nightly.openerp.com/7.0/nightly/deb/openerp_7.0-20121227-075624-1.dsc

          CLI Example:

             salt '*' file.extract_hash /path/to/hash/file sha512 /etc/foo

   salt.modules.file.file_exists(path)
          Tests to see if path is a valid file.  Returns True/False.

          CLI Example:

             salt '*' file.file_exists /etc/passwd

   salt.modules.file.find(path, *args, **kwargs)
          Approximate the Unix find(1) command and return a list of  paths
          that meet the specified criteria.

          The options include match criteria:

             name    = path-glob                 # case sensitive
             iname   = path-glob                 # case insensitive
             regex   = path-regex                # case sensitive
             iregex  = path-regex                # case insensitive
             type    = file-types                # match any listed type
             user    = users                     # match any listed user
             group   = groups                    # match any listed group
             size    = [+-]number[size-unit]     # default unit = byte
             mtime   = interval                  # modified since date
             grep    = regex                     # search file contents

          and/or actions:

             delete [= file-types]               # default type = 'f'
             exec    = command [arg ...]         # where {} is replaced by pathname
             print  [= print-opts]

          and/or depth criteria:

             maxdepth = maximum depth to transverse in path
             mindepth = minimum depth to transverse before checking files or directories

          The default action is print=path

          path-glob:

             *                = match zero or more chars
             ?                = match any char
             [abc]            = match a, b, or c
             [!abc] or [^abc] = match anything except a, b, and c
             [x-y]            = match chars x through y
             [!x-y] or [^x-y] = match anything except chars x through y
             {a,b,c}          = match a or b or c

          path-regex: a Python Regex (regular expression) pattern to match
          pathnames

          file-types: a string of one or more of the following:

             a: all file types
             b: block device
             c: character device
             d: directory
             p: FIFO (named pipe)
             f: plain file
             l: symlink
             s: socket

          users: a space and/or comma separated list of user names  and/or
          uids

          groups:  a  space  and/or  comma  separated  list of group names
          and/or gids

          size-unit:

             b: bytes
             k: kilobytes
             m: megabytes
             g: gigabytes
             t: terabytes

          interval:

             [<num>w] [<num>d] [<num>h] [<num>m] [<num>s]

             where:
                 w: week
                 d: day
                 h: hour
                 m: minute
                 s: second

          print-opts: a comma and/or space separated list of one  or  more
          of the following:

             group: group name
             md5:   MD5 digest of file contents
             mode:  file permissions (as integer)
             mtime: last modification time (as time_t)
             name:  file basename
             path:  file absolute path
             size:  file size in bytes
             type:  file type
             user:  user name

          CLI Examples:

             salt '*' file.find / type=f name=\*.bak size=+10m
             salt '*' file.find /var mtime=+30d size=+10m print=path,size,mtime
             salt '*' file.find /var/log name=\*.[0-9] mtime=+30d size=+10m delete

   salt.modules.file.get_devmm(name)
          Get major/minor info from a device

          CLI Example:

             salt '*' file.get_devmm /dev/chr

   salt.modules.file.get_diff(minionfile, masterfile, saltenv='base')
          Return unified diff of file compared to file on master

          CLI Example:

             salt '*' file.get_diff /home/fred/.vimrc salt://users/fred/.vimrc

   salt.modules.file.get_gid(path, follow_symlinks=True)
          Return the id of the group that owns a given file

          path   file or directory of which to get the gid

          follow_symlinks
                 indicated if symlinks should be followed

          CLI Example:

             salt '*' file.get_gid /etc/passwd

          Changed in version 0.16.4: follow_symlinks option added

   salt.modules.file.get_group(path, follow_symlinks=True)
          Return the group that owns a given file

          path   file or directory of which to get the group

          follow_symlinks
                 indicated if symlinks should be followed

          CLI Example:

             salt '*' file.get_group /etc/passwd

          Changed in version 0.16.4: follow_symlinks option added

   salt.modules.file.get_hash(path, form='sha256', chunk_size=65536)
          Get the hash sum of a file

          This is better than get_sum for the following reasons:

                 * It does not read the entire file into memory.

                 *

                   It  does  not  return  a  string on error. The returned
                   value of
                          get_sum cannot really be  trusted  since  it  is
                          vulnerable to collisions: get_sum(..., 'xyz') ==
                          'Hash xyz not supported'

          path   path to the file or directory

          form   desired sum format

          chunk_size
                 amount to sum at once

          CLI Example:

             salt '*' file.get_hash /etc/shadow

   salt.modules.file.get_managed(name,  template,   source,   source_hash,
   source_hash_name,   user,  group,  mode,  saltenv,  context,  defaults,
   skip_verify=False, **kwargs)
          Return the managed file data for file.managed

          name   location where the file lives on the server

          template
                 template format

          source managed source file

          source_hash
                 hash of the source file

          source_hash_name
                 When source_hash refers to a remote file, this  specifies
                 the filename to look for in that file.

                 New in version 2016.3.5.

          user   Owner of file

          group  Group owner of file

          mode   Permissions of file

          context
                 Variables to add to the template context

          defaults
                 Default values of for context_dict

          skip_verify
                 If   True,  hash  verification  of  remote  file  sources
                 (http://, https://, ftp://)  will  be  skipped,  and  the
                 source_hash argument will be ignored.

                 New in version 2016.3.0.

          CLI Example:

             salt '*' file.get_managed /etc/httpd/conf.d/httpd.conf jinja salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' None root root '755' base None None

   salt.modules.file.get_mode(path, follow_symlinks=True)
          Return the mode of a file

          path   file or directory of which to get the mode

          follow_symlinks
                 indicated if symlinks should be followed

          CLI Example:

             salt '*' file.get_mode /etc/passwd

          Changed in version 2014.1.0: follow_symlinks option added

   salt.modules.file.get_selinux_context(path)
          Get an SELinux context from a given path

          CLI Example:

             salt '*' file.get_selinux_context /etc/hosts

   salt.modules.file.get_source_sum(file_name='',               source='',
   source_hash=None, source_hash_name=None, saltenv='base')
          New in version 2016.11.0.

          Used by file.get_managed to obtain the hash and hash  type  from
          the parameters specified below.

          file_name
                 Optional  file  name  being  managed,  for  matching with
                 file.extract_hash.

                 New in version 2016.11.0.

          source Source file,  as  used  in  file  and  other  states.  If
                 source_hash refers to a file containing hashes, then this
                 filename will be used to match a filename in  that  file.
                 If  the  source_hash  is  a  hash  expression,  then this
                 argument will be ignored.

          source_hash
                 Hash file/expression, as used in file and  other  states.
                 If  this value refers to a remote URL or absolute path to
                 a local file, it will  be  cached  and  file.extract_hash
                 will be used to obtain a hash from it.

          source_hash_name
                 Specific file name to look for when source_hash refers to
                 a remote file, used to disambiguate ambiguous matches.

                 New in version 2016.11.0.

          saltenv
                 base Salt fileserver environment from  which  to  retrive
                 the  source_hash.  This  value  will  only  be  used when
                 source_hash refers to a file on the Salt fileserver (i.e.
                 one beginning with salt://).

          CLI Example:

             salt '*' file.get_source_sum /tmp/foo.tar.gz source=http://mydomain.tld/foo.tar.gz source_hash=499ae16dcae71eeb7c3a30c75ea7a1a6
             salt '*' file.get_source_sum /tmp/foo.tar.gz source=http://mydomain.tld/foo.tar.gz source_hash=https://mydomain.tld/hashes.md5
             salt '*' file.get_source_sum /tmp/foo.tar.gz source=http://mydomain.tld/foo.tar.gz source_hash=https://mydomain.tld/hashes.md5 source_hash_name=./dir2/foo.tar.gz

   salt.modules.file.get_sum(path, form='sha256')
          Return  the  checksum for the given file. The following checksum
          algorithms are supported:

          * md5

          * sha1

          * sha224

          * sha256 (default)

          * sha384

          * sha512

          path   path to the file or directory

          form   desired sum format

          CLI Example:

             salt '*' file.get_sum /etc/passwd sha512

   salt.modules.file.get_uid(path, follow_symlinks=True)
          Return the id of the user that owns a given file

          path   file or directory of which to get the uid

          follow_symlinks
                 indicated if symlinks should be followed

          CLI Example:

             salt '*' file.get_uid /etc/passwd

          Changed in version 0.16.4: follow_symlinks option added

   salt.modules.file.get_user(path, follow_symlinks=True)
          Return the user that owns a given file

          path   file or directory of which to get the user

          follow_symlinks
                 indicated if symlinks should be followed

          CLI Example:

             salt '*' file.get_user /etc/passwd

          Changed in version 0.16.4: follow_symlinks option added

   salt.modules.file.gid_to_group(gid)
          Convert the group id to the group name on this system

          gid    gid to convert to a group name

          CLI Example:

             salt '*' file.gid_to_group 0

   salt.modules.file.grep(path, pattern, *opts)
          Grep for a string in the specified file

          NOTE:
             This function's return value  is  slated  for  refinement  in
             future versions of Salt

          path   Path to the file to be searched

                 NOTE:
                    Globbing is supported (i.e. /var/log/foo/*.log, but if
                    globbing is being used then the path should be  quoted
                    to  keep  the shell from attempting to expand the glob
                    expression.

          pattern
                 Pattern to match. For example: test, or a[0-5]

          opts   Additional  command-line  flags  to  pass  to  the   grep
                 command. For example: -v, or -i -B2

                 NOTE:
                    The  options should come after a double-dash (as shown
                    in the examples below) to  keep  Salt's  own  argument
                    parser from interpreting them.

          CLI Example:

             salt '*' file.grep /etc/passwd nobody
             salt '*' file.grep /etc/sysconfig/network-scripts/ifcfg-eth0 ipaddr -- -i
             salt '*' file.grep /etc/sysconfig/network-scripts/ifcfg-eth0 ipaddr -- -i -B2
             salt '*' file.grep "/etc/sysconfig/network-scripts/*" ipaddr -- -i -l

   salt.modules.file.group_to_gid(group)
          Convert the group to the gid on this system

          group  group to convert to its gid

          CLI Example:

             salt '*' file.group_to_gid root

   salt.modules.file.is_blkdev(name)
          Check if a file exists and is a block device.

          CLI Example:

             salt '*' file.is_blkdev /dev/blk

   salt.modules.file.is_chrdev(name)
          Check if a file exists and is a character device.

          CLI Example:

             salt '*' file.is_chrdev /dev/chr

   salt.modules.file.is_fifo(name)
          Check if a file exists and is a FIFO.

          CLI Example:

             salt '*' file.is_fifo /dev/fifo

   salt.modules.file.is_link(path)
          Check if the path is a symbolic link

          CLI Example:

             salt '*' file.is_link /path/to/link

   salt.modules.file.join(*args)
          Return a normalized file system path for the underlying OS

          New in version 2014.7.0.

          This  can  be  useful  at  the CLI but is frequently useful when
          scripting combining path variables:

             {% set www_root = '/var' %}
             {% set app_dir = 'myapp' %}

             myapp_config:
               file:
                 - managed
                 - name: {{ salt['file.join'](www_root, app_dir, 'config.yaml') }}

          CLI Example:

             salt '*' file.join '/' 'usr' 'local' 'bin'

   salt.modules.file.lchown(path, user, group)
          Chown a file, pass the file the desired user and  group  without
          following symlinks.

          path   path to the file or directory

          user   user owner

          group  group owner

          CLI Example:

             salt '*' file.chown /etc/passwd root root

   salt.modules.file.line(path,     content,     match=None,    mode=None,
   location=None,     before=None,     after=None,      show_changes=True,
   backup=False, quiet=False, indent=True)
          New in version 2015.8.0.

          Edit  a  line  in  the  configuration file. The path and content
          arguments are required, as well as passing in one  of  the  mode
          options.

          path   Filesystem path to the file to be edited.

          content
                 Content of the line.

          match  Match  the  target  line for an action by a fragment of a
                 string or regular expression.

                 If neither before nor after are provided,  and  match  is
                 also None, match becomes the content value.

          mode   Defines  how to edit a line. One of the following options
                 is required:

                 *

                   ensure If line does not exist, it will be  added.  This
                          is based on the content argument.

                 *

                   replace
                          If line already exists, it will be replaced.

                 *

                   delete Delete the line, once found.

                 *

                   insert Insert a line.

                 NOTE:
                    If  mode=insert is used, at least one of the following
                    options must also be  defined:  location,  before,  or
                    after.  If  location is used, it takes precedence over
                    the other two options.

          location
                 Defines where to place content in  the  line.  Note  this
                 option  is  only used when mode=insert is specified. If a
                 location is passed in, it takes precedence over both  the
                 before and after kwargs. Valid locations are:

                 *

                   start  Place the content at the beginning of the file.

                 *

                   end    Place the content at the end of the file.

          before Regular expression or an exact case-sensitive fragment of
                 the string.  This option is only  used  when  either  the
                 ensure or insert mode is defined.

          after  Regular expression or an exact case-sensitive fragment of
                 the string.  This option is only  used  when  either  the
                 ensure or insert mode is defined.

          show_changes
                 Output  a  unified diff of the old file and the new file.
                 If False return a  boolean  if  any  changes  were  made.
                 Default is True

                 NOTE:
                    Using  this  option  will store two copies of the file
                    in-memory  (the  original  version  and   the   edited
                    version) in order to generate the diff.

          backup Create  a backup of the original file with the extension:
                 "Year-Month-Day-Hour-Minutes-Seconds".

          quiet  Do not raise any exceptions. E.g. ignore  the  fact  that
                 the  file  that  is tried to be edited does not exist and
                 nothing really happened.

          indent Keep indentation with the previous line. This  option  is
                 not considered when the delete mode is specified.

          CLI Example:

             salt '*' file.line /etc/nsswitch.conf "networks:        files dns" after="hosts:.*?" mode='ensure'

          NOTE:
             If  an  equal  sign  (=)  appears  in  an  argument to a Salt
             command, it is interpreted  as  a  keyword  argument  in  the
             format  of  key=val. That processing can be bypassed in order
             to pass an equal sign through to the remote shell command  by
             manually specifying the kwarg:

                 salt '*' file.line /path/to/file content="CREATEMAIL_SPOOL=no" match="CREATE_MAIL_SPOOL=yes" mode="replace"

   salt.modules.file.link(src, path)
          New in version 2014.1.0.

          Create a hard link to a file

          CLI Example:

             salt '*' file.link /path/to/file /path/to/link

   salt.modules.file.list_backups(path, limit=None)
          New in version 0.17.0.

          Lists  the  previous  versions  of a file backed up using Salt's
          file state backup system.

          path   The path on the minion to check for backups

          limit  Limit the number of results to the most recent N backups

          CLI Example:

             salt '*' file.list_backups /foo/bar/baz.txt

   salt.modules.file.list_backups_dir(path, limit=None)
          Lists the previous versions  of  a  directory  backed  up  using
          Salt's file state backup system.

          path   The directory on the minion to check for backups

          limit  Limit the number of results to the most recent N backups

          CLI Example:

             salt '*' file.list_backups_dir /foo/bar/baz/

   salt.modules.file.lstat(path)
          New in version 2014.1.0.

          Returns the lstat attributes for the given file or dir. Does not
          support symbolic links.

          CLI Example:

             salt '*' file.lstat /path/to/file

   salt.modules.file.makedirs(path, user=None, group=None, mode=None)
          Ensure that the directory containing this path is available.

          NOTE:
             The path  must  end  with  a  trailing  slash  otherwise  the
             directory/directories  will  be  created  up  to  the  parent
             directory. For example if path is /opt/code, then it would be
             treated  as  /opt/ but if the path ends with a trailing slash
             like /opt/code/, then it would be treated as /opt/code/.

          CLI Example:

             salt '*' file.makedirs /opt/code/

   salt.modules.file.makedirs_perms(name,      user=None,      group=None,
   mode='0755')
          Taken  and modified from os.makedirs to set user, group and mode
          for each directory created.

          CLI Example:

             salt '*' file.makedirs_perms /opt/code

   salt.modules.file.manage_file(name, sfn, ret, source, source_sum, user,
   group,    mode,   saltenv,   backup,   makedirs=False,   template=None,
   show_changes=True, contents=None, dir_mode=None,  follow_symlinks=True,
   skip_verify=False, keep_mode=False, **kwargs)
          Checks   the   destination   against  what  was  retrieved  with
          get_managed  and  makes  the   appropriate   modifications   (if
          necessary).

          name   location to place the file

          sfn    location of cached file on the minion

                 This  is  the path to the file stored on the minion. This
                 file is placed on the minion using cp.cache_file.  If the
                 hash  sum  of that file matches the source_sum, we do not
                 transfer the file to the minion again.

                 This file is then grabbed and if it has template set,  it
                 renders  the  file to be placed into the correct place on
                 the system using salt.files.utils.copyfile()

          ret    The initial state return data structure. Pass in None  to
                 use the default structure.

          source file reference on the master

          source_hash
                 sum hash for source

          user   user owner

          group  group owner

          backup backup_mode

          makedirs
                 make directories if they do not exist

          template
                 format of templating

          show_changes
                 Include diff in state return

          contents:
                 contents to be placed in the file

          dir_mode
                 mode for directories created with makedirs

          skip_verify
                 False  If  True, hash verification of remote file sources
                 (http://, https://, ftp://)  will  be  skipped,  and  the
                 source_hash argument will be ignored.

                 New in version 2016.3.0.

          keep_mode
                 False  If  True,  and  the source is a file from the Salt
                 fileserver (or a local file on the minion), the  mode  of
                 the  destination  file  will  be  set  to the mode of the
                 source file.

          CLI Example:

             salt '*' file.manage_file /etc/httpd/conf.d/httpd.conf '' '{}' salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' root root '755' base ''

          Changed in version 2014.7.0: follow_symlinks option added

   salt.modules.file.mkdir(dir_path, user=None, group=None, mode=None)
          Ensure that a directory is available.

          CLI Example:

             salt '*' file.mkdir /opt/jetty/context

   salt.modules.file.mknod(name,  ntype,  major=0,   minor=0,   user=None,
   group=None, mode='0600')
          New in version 0.17.0.

          Create   a   block  device,  character  device,  or  fifo  pipe.
          Identical to the gnu mknod.

          CLI Examples:

             salt '*' file.mknod /dev/chr c 180 31
             salt '*' file.mknod /dev/blk b 8 999
             salt '*' file.nknod /dev/fifo p

   salt.modules.file.mknod_blkdev(name,    major,    minor,     user=None,
   group=None, mode='0660')
          New in version 0.17.0.

          Create a block device.

          CLI Example:

             salt '*' file.mknod_blkdev /dev/blk 8 999

   salt.modules.file.mknod_chrdev(name,     major,    minor,    user=None,
   group=None, mode='0660')
          New in version 0.17.0.

          Create a character device.

          CLI Example:

             salt '*' file.mknod_chrdev /dev/chr 180 31

   salt.modules.file.mknod_fifo(name, user=None, group=None, mode='0660')
          New in version 0.17.0.

          Create a FIFO pipe.

          CLI Example:

             salt '*' file.mknod_fifo /dev/fifo

   salt.modules.file.move(src, dst)
          Move a file or directory

          CLI Example:

             salt '*' file.move /path/to/src /path/to/dst

   salt.modules.file.normpath(path)
          Returns Normalize path, eliminating double slashes, etc.

          New in version 2015.5.0.

          This can be useful at the CLI  but  is  frequently  useful  when
          scripting.

             {%- from salt['file.normpath'](tpldir + '/../vars.jinja') import parent_vars %}

          CLI Example:

             salt '*' file.normpath 'a/b/c/..'

   salt.modules.file.open_files(by_pid=False)
          Return a list of all physical open files on the system.

          CLI Examples:

             salt '*' file.open_files
             salt '*' file.open_files by_pid=True

   salt.modules.file.pardir()
          Return  the relative parent directory path symbol for underlying
          OS

          New in version 2014.7.0.

          This can be useful when constructing Salt Formulas.

             {% set pardir = salt['file.pardir']() %}
             {% set final_path = salt['file.join']('subdir', pardir, 'confdir') %}

          CLI Example:

             salt '*' file.pardir

   salt.modules.file.patch(originalfile,      patchfile,       options='',
   dry_run=False)
          New in version 0.10.4.

          Apply a patch to a file or directory.

          Equivalent to:

             patch <options> -i <patchfile> <originalfile>

          Or, when a directory is patched:

             patch <options> -i <patchfile> -d <originalfile> -p0

          originalfile
                 The full path to the file or directory to be patched

          patchfile
                 A patch file to apply to originalfile

          options
                 Options to pass to patch.

          CLI Example:

             salt '*' file.patch /opt/file.txt /tmp/file.txt.patch

   salt.modules.file.path_exists_glob(path)
          Tests  to  see  if path after expansion is a valid path (file or
          directory).  Expansion allows usage of ? * and character  ranges
          []. Tilde expansion is not supported. Returns True/False.

          New in version Hellium.

          CLI Example:

             salt '*' file.path_exists_glob /etc/pam*/pass*

   salt.modules.file.prepend(path, *args, **kwargs)
          New in version 2014.7.0.

          Prepend text to the beginning of a file

          path   path to file

          *args  strings to prepend to the file

          CLI Example:

             salt '*' file.prepend /etc/motd \
                     "With all thine offerings thou shalt offer salt." \
                     "Salt is what makes things taste bad when it isn't in them."

             Attention

                    If you need to pass a string to append and that string
                    contains an equal sign, you must include the  argument
                    name, args.  For example:

                 salt '*' file.prepend /etc/motd args='cheese=spam'

                 salt '*' file.prepend /etc/motd args="['cheese=spam','spam=cheese']"

   salt.modules.file.psed(path,  before,  after,  limit='', backup='.bak',
   flags='gMS', escape_all=False, multi=False)
          Deprecated since version 0.17.0: Use replace() instead.

          Make a simple edit to a file (pure Python version)

          Equivalent to:

             sed <backup> <options> "/<limit>/ s/<before>/<after>/<flags> <file>"

          path   The full path to the file to be edited

          before A pattern to find in order to replace with after

          after  Text that will replace before

          limit  '' An initial pattern to search for before searching  for
                 before

          backup .bak  The  file  will  be backed up before edit with this
                 file extension; WARNING: each time  sed/comment/uncomment
                 is called will overwrite this backup

          flags  gMS.INDENT 7.0

          Flags to modify the search. Valid values are:

                 * g: Replace all occurrences of the pattern, not just the
                   first.

                 * I: Ignore case.

                 * L: Make \w, \W, 	, \B, \s  and  \S  dependent  on  the
                   locale.

                 * M: Treat multiple lines as a single line.

                 * S: Make . match all characters, including newlines.

                 * U:  Make \w, \W, 	, \B, \d, \D, \s and \S dependent on
                   Unicode.

                 * X: Verbose (whitespace is ignored).

   multi: False
          If True, treat the entire file as a single line

   Forward slashes and single quotes will be escaped automatically in  the
   before and after patterns.

   CLI Example:

             salt '*' file.sed /etc/httpd/httpd.conf 'LogLevel warn' 'LogLevel info'

   salt.modules.file.readdir(path)
          New in version 2014.1.0.

          Return a list containing the contents of a directory

          CLI Example:

             salt '*' file.readdir /path/to/dir/

   salt.modules.file.readlink(path, canonicalize=False)
          New in version 2014.1.0.

          Return  the path that a symlink points to If canonicalize is set
          to True, then it return the final target

          CLI Example:

             salt '*' file.readlink /path/to/link

   salt.modules.file.remove(path)
          Remove the named file. If a directory is supplied,  it  will  be
          recursively deleted.

          CLI Example:

             salt '*' file.remove /tmp/foo

   salt.modules.file.rename(src, dst)
          Rename a file or directory

          CLI Example:

             salt '*' file.rename /path/to/src /path/to/dst

   salt.modules.file.replace(path,   pattern,   repl,   count=0,  flags=8,
   bufsize=1,    append_if_not_found=False,    prepend_if_not_found=False,
   not_found_content=None,          backup='.bak',          dry_run=False,
   search_only=False,     show_changes=True,      ignore_if_missing=False,
   preserve_inode=True)
          New in version 0.17.0.

          Replace  occurrences  of a pattern in a file. If show_changes is
          True, then a diff of what changed will be returned, otherwise  a
          True  will  be returned when changes are made, and False when no
          changes are made.

          This is a pure Python implementation that wraps Python's sub().

          path   Filesystem path to the file to be edited. If a symlink is
                 specified, it will be resolved to its target.

          pattern
                 A  regular  expression,  to  be  matched  using  Python's
                 search().

          repl   The replacement text

          count  0 Maximum number of pattern occurrences to  be  replaced.
                 If count is a positive integer n, only n occurrences will
                 be replaced, otherwise all occurrences will be replaced.

          flags (list or int)
                 A list of flags defined in the re  module  documentation.
                 Each  list item should be a string that will correlate to
                 the  human-friendly  flag  name.   E.g.,   ['IGNORECASE',
                 'MULTILINE'].  Optionally,  flags  may  be an int, with a
                 value corresponding to the XOR (|)  of  all  the  desired
                 flags. Defaults to 8 (which supports 'MULTILINE').

          bufsize (int or str)
                 How  much  of the file to buffer into memory at once. The
                 default value 1 processes one line at a time. The special
                 value  file  may  be specified which will read the entire
                 file into memory before processing.

          append_if_not_found
                 False New in version 2014.7.0.

                 If set to True,  and  pattern  is  not  found,  then  the
                 content will be appended to the file.

          prepend_if_not_found
                 False New in version 2014.7.0.

                 If set to True and pattern is not found, then the content
                 will be prepended to the file.

          not_found_content
                 New in version 2014.7.0.

                 Content to use for append/prepend if not found.  If  None
                 (default), uses repl. Useful when repl uses references to
                 group in pattern.

          backup .bak The file extension to use for a backup of  the  file
                 before editing. Set to False to skip making a backup.

          dry_run
                 False  If  set  to  True,  no changes will be made to the
                 file, the function will  just  return  the  changes  that
                 would   have   been   made  (or  a  True/False  value  if
                 show_changes is set to False).

          search_only
                 False If set to true, this no changes will  be  performed
                 on the file, and this function will simply return True if
                 the pattern was matched, and False if not.

          show_changes
                 True If True, return a diff of changes  made.  Otherwise,
                 return True if changes were made, and False if not.

                 NOTE:
                    Using this option will store two copies of the file in
                    memory (the original version and the  edited  version)
                    in  order  to generate the diff. This may not normally
                    be a concern, but could  impact  performance  if  used
                    with large files.

          ignore_if_missing
                 False New in version 2015.8.0.

                 If set to True, this function will simply return False if
                 the file doesn't  exist.  Otherwise,  an  error  will  be
                 thrown.

          preserve_inode
                 True New in version 2015.8.0.

                 Preserve  the  inode  of the file, so that any hard links
                 continue to share the inode with the  original  filename.
                 This  works  by  copying the file, reading from the copy,
                 and writing to the file at the original inode. If  False,
                 the file will be moved rather than copied, and a new file
                 will be written to a new inode, but  using  the  original
                 filename.  Hard  links  will then share an inode with the
                 backup, instead (if  using  backup  to  create  a  backup
                 copy).

          If an equal sign (=) appears in an argument to a Salt command it
          is interpreted as a keyword argument in the format key=val. That
          processing  can  be  bypassed  in  order  to  pass an equal sign
          through to the remote shell command by manually  specifying  the
          kwarg:

             salt '*' file.replace /path/to/file pattern='=' repl=':'
             salt '*' file.replace /path/to/file pattern="bind-address\s*=" repl='bind-address:'

          CLI Examples:

             salt '*' file.replace /etc/httpd/httpd.conf pattern='LogLevel warn' repl='LogLevel info'
             salt '*' file.replace /some/file pattern='before' repl='after' flags='[MULTILINE, IGNORECASE]'

   salt.modules.file.restore_backup(path, backup_id)
          New in version 0.17.0.

          Restore  a  previous  version of a file that was backed up using
          Salt's file state backup system.

          path   The path on the minion to check for backups

          backup_id
                 The numeric id for the backup you  wish  to  restore,  as
                 found using file.list_backups

          CLI Example:

             salt '*' file.restore_backup /foo/bar/baz.txt 0

   salt.modules.file.restorecon(path, recursive=False)
          Reset the SELinux context on a given path

          CLI Example:

             salt '*' file.restorecon /home/user/.ssh/authorized_keys

   salt.modules.file.rmdir(path)
          New in version 2014.1.0.

          Remove  the  specified  directory.  Fails  if a directory is not
          empty.

          CLI Example:

             salt '*' file.rmdir /tmp/foo/

   salt.modules.file.search(path,     pattern,     flags=8,     bufsize=1,
   ignore_if_missing=False, multiline=False)
          New in version 0.17.0.

          Search for occurrences of a pattern in a file

          Except for multiline, params are identical to replace().

          multiline
                 If  true, inserts 'MULTILINE' into flags and sets bufsize
                 to 'file'.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' file.search /etc/crontab 'mymaintenance.sh'

   salt.modules.file.sed(path,  before,  after,  limit='',  backup='.bak',
   options='-r -e', flags='g', escape_all=False, negate_match=False)
          Deprecated since version 0.17.0: Use replace() instead.

          Make a simple edit to a file

          Equivalent to:

             sed <backup> <options> "/<limit>/ s/<before>/<after>/<flags> <file>"

          path   The full path to the file to be edited

          before A pattern to find in order to replace with after

          after  Text that will replace before

          limit  ''  An initial pattern to search for before searching for
                 before

          backup .bak The file will be backed up  before  edit  with  this
                 file  extension; WARNING: each time sed/comment/uncomment
                 is called will overwrite this backup

          options
                 -r -e Options to pass to sed

          flags  g  Flags  to  modify  the  sed  search;   e.g.,   i   for
                 case-insensitive pattern matching

          negate_match
                 False Negate the search command (!)

                 New in version 0.17.0.

          Forward  slashes and single quotes will be escaped automatically
          in the before and after patterns.

          CLI Example:

             salt '*' file.sed /etc/httpd/httpd.conf 'LogLevel warn' 'LogLevel info'

   salt.modules.file.sed_contains(path, text, limit='', flags='g')
          Deprecated since version 0.17.0: Use search() instead.

          Return True if the file at path contains text. Utilizes  sed  to
          perform the search (line-wise search).

          Note: the p flag will be added to any flags you pass in.

          CLI Example:

             salt '*' file.contains /etc/crontab 'mymaintenance.sh'

   salt.modules.file.seek_read(path, size, offset)
          New in version 2014.1.0.

          Seek to a position on a file and read it

          path   path to file

          seek   amount to read at once

          offset offset to start into the file

          CLI Example:

             salt '*' file.seek_read /path/to/file 4096 0

   salt.modules.file.seek_write(path, data, offset)
          New in version 2014.1.0.

          Seek to a position on a file and write to it

          path   path to file

          data   data to write to file

          offset position in file to start writing

          CLI Example:

             salt '*' file.seek_write /path/to/file 'some data' 4096

   salt.modules.file.set_mode(path, mode)
          Set the mode of a file

          path   file or directory of which to set the mode

          mode   mode to set the path to

          CLI Example:

             salt '*' file.set_mode /etc/passwd 0644

   salt.modules.file.set_selinux_context(path,    user=None,    role=None,
   type=None, range=None)
          Set a specific SELinux label on a given path

          CLI Example:

             salt '*' file.set_selinux_context path <role> <type> <range>

   salt.modules.file.source_list(source, source_hash, saltenv)
          Check the source list and return the source to use

          CLI Example:

             salt '*' file.source_list salt://http/httpd.conf '{hash_type: 'md5', 'hsum': <md5sum>}' base

   salt.modules.file.stats(path, hash_type=None, follow_symlinks=True)
          Return a dict containing the stats for a given file

          CLI Example:

             salt '*' file.stats /etc/passwd

   salt.modules.file.statvfs(path)
          New in version 2014.1.0.

          Perform a statvfs call against  the  filesystem  that  the  file
          resides on

          CLI Example:

             salt '*' file.statvfs /path/to/file

   salt.modules.file.symlink(src, path)
          Create a symbolic link (symlink, soft link) to a file

          CLI Example:

             salt '*' file.symlink /path/to/file /path/to/link

   salt.modules.file.touch(name, atime=None, mtime=None)
          New in version 0.9.5.

          Just  like  the touch command, create a file if it doesn't exist
          or simply update the atime and mtime if it already does.

          atime: Access time in Unix epoch time

          mtime: Last modification in Unix epoch time

          CLI Example:

             salt '*' file.touch /var/log/emptyfile

   salt.modules.file.truncate(path, length)
          New in version 2014.1.0.

          Seek to a position on a file and delete  everything  after  that
          point

          path   path to file

          length offset into file to truncate

          CLI Example:

             salt '*' file.truncate /path/to/file 512

   salt.modules.file.uid_to_user(uid)
          Convert a uid to a user name

          uid    uid to convert to a username

          CLI Example:

             salt '*' file.uid_to_user 0

   salt.modules.file.uncomment(path, regex, char='#', backup='.bak')
          Deprecated since version 0.17.0: Use replace() instead.

          Uncomment specified commented lines in a file

          path   The full path to the file to be edited

          regex  A  regular  expression used to find the lines that are to
                 be  uncommented.   This  regex  should  not  include  the
                 comment character. A leading ^ character will be stripped
                 for convenience (for easily switching  between  comment()
                 and uncomment()).

          char   # The character to remove in order to uncomment a line

          backup .bak  The  file  will  be backed up before edit with this
                 file extension; WARNING: each time  sed/comment/uncomment
                 is called will overwrite this backup

          CLI Example:

             salt '*' file.uncomment /etc/hosts.deny 'ALL: PARANOID'

   salt.modules.file.user_to_uid(user)
          Convert user name to a uid

          user   user name to convert to its uid

          CLI Example:

             salt '*' file.user_to_uid root

   salt.modules.file.write(path, *args, **kwargs)
          New in version 2014.7.0.

          Write text to a file, overwriting any existing contents.

          path   path to file

          *args  strings to write to the file

          CLI Example:

             salt '*' file.write /etc/motd \
                     "With all thine offerings thou shalt offer salt."

             Attention

                    If you need to pass a string to append and that string
                    contains an equal sign, you must include the  argument
                    name, args.  For example:

                 salt '*' file.write /etc/motd args='cheese=spam'

                 salt '*' file.write /etc/motd args="['cheese=spam','spam=cheese']"

   salt.modules.firewalld
   Support for firewalld.

   New in version 2015.2.0.

   salt.modules.firewalld.add_interface(zone, interface, permanent=True)
          Bind an interface to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.add_interface zone eth0

   salt.modules.firewalld.add_masquerade(zone=None, permanent=True)
          Enable  masquerade  on a zone.  If zone is omitted, default zone
          will be used.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.add_masquerade

          To enable masquerade on a specific zone

             salt '*' firewalld.add_masquerade dmz

   salt.modules.firewalld.add_port(zone, port, permanent=True)
          Allow specific ports in a zone.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.add_port internal 443/tcp

   salt.modules.firewalld.add_port_fwd(zone,   src,   dest,   proto='tcp',
   dstaddr='', permanent=True)
          Add port forwarding.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.add_port_fwd public 80 443 tcp

   salt.modules.firewalld.add_rich_rule(zone, rule, permanent=True)
          Add a rich rule to a zone

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.add_rich_rule zone 'rule'

   salt.modules.firewalld.add_service(service, zone=None, permanent=True)
          Add a service for zone. If zone is omitted, default zone will be
          used.

          CLI Example:

             salt '*' firewalld.add_service ssh

          To assign a service to a specific zone:

             salt '*' firewalld.add_service ssh my_zone

   salt.modules.firewalld.add_service_port(service, port)
          Add a new port to the specified service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.add_service_port zone 80

   salt.modules.firewalld.add_service_protocol(service, protocol)
          Add a new protocol to the specified service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.add_service_protocol zone ssh

   salt.modules.firewalld.add_source(zone, source, permanent=True)
          Bind a source to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.add_source zone 192.168.1.0/24

   salt.modules.firewalld.allow_icmp(zone, icmp, permanent=True)
          Allow a specific ICMP type on a zone

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.allow_icmp zone echo-reply

   salt.modules.firewalld.block_icmp(zone, icmp, permanent=True)
          Block a specific ICMP type on a zone

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.block_icmp zone echo-reply

   salt.modules.firewalld.default_zone()
          Print default zone for connections and interfaces

          CLI Example:

             salt '*' firewalld.default_zone

   salt.modules.firewalld.delete_service(name, restart=True)
          Delete an existing service

          CLI Example:

             salt '*' firewalld.delete_service my_service

          By  default  firewalld  will  be  reloaded.  However,  to  avoid
          reloading you need to specify the restart as False

             salt '*' firewalld.delete_service my_service False

   salt.modules.firewalld.delete_zone(zone, restart=True)
          Delete an existing zone

          CLI Example:

             salt '*' firewalld.delete_zone my_zone

          By  default  firewalld  will  be  reloaded.  However,  to  avoid
          reloading you need to specify the restart as False

             salt '*' firewalld.delete_zone my_zone False

   salt.modules.firewalld.get_icmp_types(permanent=True)
          Print predefined icmptypes

          CLI Example:

             salt '*' firewalld.get_icmp_types

   salt.modules.firewalld.get_interfaces(zone, permanent=True)
          List interfaces bound to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.get_interfaces zone

   salt.modules.firewalld.get_masquerade(zone=None, permanent=True)
          Show if masquerading is enabled on a zone.  If zone is  omitted,
          default zone will be used.

          CLI Example:

             salt '*' firewalld.get_masquerade zone

   salt.modules.firewalld.get_rich_rules(zone, permanent=True)
          List rich rules bound to a zone

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.get_rich_rules zone

   salt.modules.firewalld.get_service_ports(service)
          List ports of a service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.get_service_ports zone

   salt.modules.firewalld.get_service_protocols(service)
          List protocols of a service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.get_service_protocols zone

   salt.modules.firewalld.get_services(permanent=True)
          Print predefined services

          CLI Example:

             salt '*' firewalld.get_services

   salt.modules.firewalld.get_sources(zone, permanent=True)
          List sources bound to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.get_sources zone

   salt.modules.firewalld.get_zones(permanent=True)
          Print predefined zones

          CLI Example:

             salt '*' firewalld.get_zones

   salt.modules.firewalld.list_all(zone=None, permanent=True)
          List everything added for or enabled in a zone

          CLI Example:

             salt '*' firewalld.list_all

          List a specific zone

             salt '*' firewalld.list_all my_zone

   salt.modules.firewalld.list_icmp_block(zone, permanent=True)
          List ICMP blocks on a zone

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewlld.list_icmp_block zone

   salt.modules.firewalld.list_port_fwd(zone, permanent=True)
          List port forwarding

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.list_port_fwd public

   salt.modules.firewalld.list_ports(zone, permanent=True)
          List all ports in a zone.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.list_ports

   salt.modules.firewalld.list_services(zone=None, permanent=True)
          List services added for zone as a space separated list.  If zone
          is omitted, default zone will be used.

          CLI Example:

             salt '*' firewalld.list_services

          List a specific zone

             salt '*' firewalld.list_services my_zone

   salt.modules.firewalld.list_zones(permanent=True)
          List everything added for or enabled in all zones

          CLI Example:

             salt '*' firewalld.list_zones

   salt.modules.firewalld.make_permanent()
          Make current runtime configuration permanent.

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.make_permanent

   salt.modules.firewalld.new_service(name, restart=True)
          Add a new service

          CLI Example:

             salt '*' firewalld.new_service my_service

          By  default  firewalld  will  be  reloaded.  However,  to  avoid
          reloading you need to specify the restart as False

             salt '*' firewalld.new_service my_service False

   salt.modules.firewalld.new_zone(zone, restart=True)
          Add a new zone

          CLI Example:

             salt '*' firewalld.new_zone my_zone

          By  default  firewalld  will  be  reloaded.  However,  to  avoid
          reloading you need to specify the restart as False

             salt '*' firewalld.new_zone my_zone False

   salt.modules.firewalld.reload_rules()
          Reload  the  firewall   rules,   which   makes   the   permanent
          configuration the new runtime configuration without losing state
          information.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.reload

   salt.modules.firewalld.remove_interface(zone,                interface,
   permanent=True)
          Remove an interface bound to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.remove_interface zone eth0

   salt.modules.firewalld.remove_masquerade(zone=None, permanent=True)
          Remove  masquerade  on a zone.  If zone is omitted, default zone
          will be used.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.remove_masquerade

          To remove masquerade on a specific zone

             salt '*' firewalld.remove_masquerade dmz

   salt.modules.firewalld.remove_port(zone, port, permanent=True)
          Remove a specific port from a zone.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.remove_port internal 443/tcp

   salt.modules.firewalld.remove_port_fwd(zone,  src,  dest,  proto='tcp',
   dstaddr='', permanent=True)
          Remove Port Forwarding.

          New in version 2015.8.0.

          CLI Example:

             salt '*' firewalld.remove_port_fwd public 80 443 tcp

   salt.modules.firewalld.remove_rich_rule(zone, rule, permanent=True)
          Add a rich rule to a zone

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.remove_rich_rule zone 'rule'

   salt.modules.firewalld.remove_service(service,               zone=None,
   permanent=True)
          Remove a  service  from  zone.  This  option  can  be  specified
          multiple times.  If zone is omitted, default zone will be used.

          CLI Example:

             salt '*' firewalld.remove_service ssh

          To remove a service from a specific zone

             salt '*' firewalld.remove_service ssh dmz

   salt.modules.firewalld.remove_service_port(service, port)
          Remove a port from the specified service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.remove_service_port zone 80

   salt.modules.firewalld.remove_service_protocol(service, protocol)
          Remove a protocol from the specified service.

          New in version 2016.11.0.

          CLI Example:

             salt '*' firewalld.remove_service_protocol zone ssh

   salt.modules.firewalld.remove_source(zone, source, permanent=True)
          Remove a source bound to a zone

          New in version 2016.3.0.

          CLI Example:

             salt '*' firewalld.remove_source zone 192.168.1.0/24

   salt.modules.firewalld.set_default_zone(zone)
          Set default zone

          CLI Example:

             salt '*' firewalld.set_default_zone damian

   salt.modules.firewalld.version()
          Return version from firewall-cmd

          CLI Example:

             salt '*' firewalld.version

   salt.modules.freebsd_sysctl
   Module for viewing and modifying sysctl parameters

   salt.modules.freebsd_sysctl.assign(name, value)
          Assign a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.assign net.inet.icmp.icmplim 50

   salt.modules.freebsd_sysctl.get(name)
          Return a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.get hw.physmem

   salt.modules.freebsd_sysctl.persist(name,                        value,
   config='/etc/sysctl.conf')
          Assign and persist a simple sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.persist net.inet.icmp.icmplim 50
             salt '*' sysctl.persist coretemp_load NO config=/boot/loader.conf

   salt.modules.freebsd_sysctl.show(config_file=False)
          Return a list of sysctl parameters for this minion

          CLI Example:

             salt '*' sysctl.show

   salt.modules.freebsdjail
   The jail module for FreeBSD

   salt.modules.freebsdjail.fstab(jail)
          Display contents of a fstab(5) file defined in specified  jail's
          configuration. If no file is defined, return False.

          CLI Example:

             salt '*' jail.fstab <jail name>

   salt.modules.freebsdjail.get_enabled()
          Return which jails are set to be run

          CLI Example:

             salt '*' jail.get_enabled

   salt.modules.freebsdjail.is_enabled()
          See if jail service is actually enabled on boot

          CLI Example:

             salt '*' jail.is_enabled <jail name>

   salt.modules.freebsdjail.restart(jail='')
          Restart the specified jail or all, if none specified

          CLI Example:

             salt '*' jail.restart [<jail name>]

   salt.modules.freebsdjail.show_config(jail)
          Display specified jail's configuration

          CLI Example:

             salt '*' jail.show_config <jail name>

   salt.modules.freebsdjail.start(jail='')
          Start the specified jail or all, if none specified

          CLI Example:

             salt '*' jail.start [<jail name>]

   salt.modules.freebsdjail.status(jail)
          See if specified jail is currently running

          CLI Example:

             salt '*' jail.status <jail name>

   salt.modules.freebsdjail.stop(jail='')
          Stop the specified jail or all, if none specified

          CLI Example:

             salt '*' jail.stop [<jail name>]

   salt.modules.freebsdjail.sysctl()
          Dump all jail related kernel states (sysctl)

          CLI Example:

             salt '*' jail.sysctl

   salt.modules.freebsdkmod
   Module to manage FreeBSD kernel modules

   salt.modules.freebsdkmod.available()
          Return a list of all available kernel modules

          CLI Example:

             salt '*' kmod.available

   salt.modules.freebsdkmod.check_available(mod)
          Check to see if the specified kernel module is available

          CLI Example:

             salt '*' kmod.check_available vmm

   salt.modules.freebsdkmod.is_loaded(mod)
          Check to see if the specified kernel module is loaded

          CLI Example:

             salt '*' kmod.is_loaded vmm

   salt.modules.freebsdkmod.load(mod, persist=False)
          Load the specified kernel module

          mod    Name of the module to add

          persist
                 Write  the module to sysrc kld_modules to make it load on
                 system reboot

          CLI Example:

             salt '*' kmod.load bhyve

   salt.modules.freebsdkmod.lsmod()
          Return a dict  containing  information  about  currently  loaded
          modules

          CLI Example:

             salt '*' kmod.lsmod

   salt.modules.freebsdkmod.mod_list(only_persist=False)
          Return a list of the loaded module names

          CLI Example:

             salt '*' kmod.mod_list

   salt.modules.freebsdkmod.remove(mod, persist=False)
          Remove the specified kernel module

          CLI Example:

             salt '*' kmod.remove vmm

   salt.modules.freebsdpkg
   Remote package support using pkg_add(1)

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   WARNING:
      This  module  has  been  completely  rewritten.  Up to and including
      version  0.17.0,  it  supported  pkg_add(1),  but  checked  for  the
      existence  of  a  pkgng local database and, if found,  would provide
      some of pkgng's  functionality.  The  rewrite  of  this  module  has
      removed  all  pkgng  support,  and  moved  it to the pkgng execution
      module. For versions <= 0.17.0, the documentation here should not be
      considered  accurate.  If  your  Minion  is  running  one  of  these
      versions, then the documentation for this module can be viewed using
      the sys.doc function:

          salt bsdminion sys.doc pkg

   This  module  acts  as  the  default package provider for FreeBSD 9 and
   older. If you need to use pkgng on a FreeBSD 9 system, you will need to
   override  the  pkg  provider by setting the providers parameter in your
   Minion config file, in order to use pkgng.

      providers:
        pkg: pkgng

   More information on pkgng support can be found in the documentation for
   the pkgng module.

   This  module  will  respect the PACKAGEROOT and PACKAGESITE environment
   variables, if set, but these values can also be overridden  in  several
   ways:

   1. Salt   configuration   parameters.   The   configuration  parameters
      freebsdpkg.PACKAGEROOT and  freebsdpkg.PACKAGESITE  are  recognized.
      These  config parameters are looked up using config.get and can thus
      be specified in the Master config file, Grains, Pillar,  or  in  the
      Minion config file. Example:

         freebsdpkg.PACKAGEROOT: ftp://ftp.freebsd.org/
         freebsdpkg.PACKAGESITE: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ia64/packages-9-stable/Latest/

   2. CLI  arguments.  Both  the  packageroot  (used  interchangeably with
      fromrepo for API compatibility) and packagesite  CLI  arguments  are
      recognized,  and  override  their config counterparts from section 1
      above.

             salt -G 'os:FreeBSD' pkg.install zsh fromrepo=ftp://ftp2.freebsd.org/
             salt -G 'os:FreeBSD' pkg.install zsh packageroot=ftp://ftp2.freebsd.org/
             salt -G 'os:FreeBSD' pkg.install zsh packagesite=ftp://ftp2.freebsd.org/pub/FreeBSD/ports/ia64/packages-9-stable/Latest/

         .. note::

             These arguments can also be passed through in states:

             .. code-block:: yaml

                 zsh:
                   pkg.installed:
                     - fromrepo: ftp://ftp2.freebsd.org/

   salt.modules.freebsdpkg.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying  any  packages  will return a list of _every_ file on
          the system's package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.freebsdpkg.file_list(*packages)
          List the files that belong to  a  package.  Not  specifying  any
          packages  will  return  a  list  of _every_ file on the system's
          package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.freebsdpkg.install(name=None,               refresh=False,
   fromrepo=None, pkgs=None, sources=None, **kwargs)
          Install package(s) using pkg_add(1)

          name   The name of the package to be installed.

          refresh
                 Whether  or  not  to  refresh the package database before
                 installing.

          fromrepo or packageroot
                 Specify a  package  repository  from  which  to  install.
                 Overrides  the system default, as well as the PACKAGEROOT
                 environment variable.

          packagesite
                 Specify the exact directory from  which  to  install  the
                 remote  package.   Overrides  the PACKAGESITE environment
                 variable, if present.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must be passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo", "bar"]'

          sources
                 A  list  of packages to install. Must be passed as a list
                 of dicts, with the keys  being  package  names,  and  the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.deb"}, {"bar": "salt://bar.deb"}]'

          Return a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.install <package name>

   salt.modules.freebsdpkg.latest_version(*names, **kwargs)
          pkg_add(1)  is  not  capable of querying for remote packages, so
          this function will always return  results  as  if  there  is  no
          package available for install or upgrade.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.freebsdpkg.list_pkgs(versions_as_list=False,
   with_origin=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          with_origin
                 False Return a  nested  dictionary  containing  both  the
                 origin name and version for each installed package.

                 New in version 2014.1.0.

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.freebsdpkg.refresh_db()
          pkg_add(1)  does not use a local database of available packages,
          so this function simply returns True. it exists merely  for  API
          compatibility.

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.freebsdpkg.remove(name=None, pkgs=None, **kwargs)
          Remove packages using pkg_delete(1)

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.freebsdpkg.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          string if not installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          with_origin
                 False  Return  a  nested  dictionary  containing both the
                 origin name and version for each specified package.

                 New in version 2014.1.0.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.freebsdports
   Install software from the FreeBSD ports(7) system

   New in version 2014.1.0.

   This module allows you to  install  ports  using  BATCH=yes  to  bypass
   configuration  prompts.  It  is  recommended  to use the ports state to
   install ports, but it it also possible to use this  module  exclusively
   from the command line.

      salt minion-id ports.config security/nmap IPV6=off
      salt minion-id ports.install security/nmap

   salt.modules.freebsdports.config(name, reset=False, **kwargs)
          Modify  configuration options for a given port. Multiple options
          can be specified. To see the available options for a  port,  use
          ports.showconfig.

          name   The port name, in category/name format

          reset  False  If  True,  runs  a  make  rmconfig  for  the port,
                 clearing its configuration  before  setting  the  desired
                 options

          CLI Examples:

             salt '*' ports.config security/nmap IPV6=off

   salt.modules.freebsdports.deinstall(name)
          De-install a port.

          CLI Example:

             salt '*' ports.deinstall security/nmap

   salt.modules.freebsdports.install(name, clean=True)
          Install a port from the ports tree. Installs using BATCH=yes for
          non-interactive building. To set  config  options  for  a  given
          port, use ports.config.

          clean  True  If  True,  cleans after installation. Equivalent to
                 running make install clean BATCH=yes.

          NOTE:
             It may be helpful to run this function using the -t option to
             set  a  higher  timeout, since compiling a port may cause the
             Salt command to exceed the default timeout.

          CLI Example:

             salt -t 1200 '*' ports.install security/nmap

   salt.modules.freebsdports.list_all()
          Lists all ports available.

          CLI Example:

             salt '*' ports.list_all

          WARNING:
             Takes a while to run, and returns a LOT of output

   salt.modules.freebsdports.rmconfig(name)
          Clear the cached options for the  specified  port;  run  a  make
          rmconfig

          name   The name of the port to clear

          CLI Example:

             salt '*' ports.rmconfig security/nmap

   salt.modules.freebsdports.search(name)
          Search  for  matches in the ports tree. Globs are supported, and
          the category is optional

          CLI Examples:

             salt '*' ports.search 'security/*'
             salt '*' ports.search 'security/n*'
             salt '*' ports.search nmap

          WARNING:
             Takes a while to run

   salt.modules.freebsdports.showconfig(name,               default=False,
   dict_return=False)
          Show the configuration options for a given port.

          default
                 False   Show   the   default  options  for  a  port  (not
                 necessarily the same as the current configuration)

          dict_return
                 False Instead of returning the output of make showconfig,
                 return the data in an dictionary

          CLI Example:

             salt '*' ports.showconfig security/nmap
             salt '*' ports.showconfig security/nmap default=True

   salt.modules.freebsdports.update(extract=False)
          Update the ports tree

          extract
                 False  If  True,  runs a portsnap extract after fetching,
                 should be used for first-time installation of  the  ports
                 tree.

          CLI Example:

             salt '*' ports.update

   salt.modules.freebsdservice
   The service module for FreeBSD

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on a minion, and it is using a different module (or gives  an  error
      similar to 'service.start' is not available), see here.

   salt.modules.freebsdservice.available(name)
          Check that the given service is available.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.freebsdservice.disable(name, **kwargs)
          Disable the named service to start at boot

          Arguments the same as for enable()

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.freebsdservice.disabled(name)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.freebsdservice.enable(name, **kwargs)
          Enable the named service to start at boot

          name   service name

          config /etc/rc.conf  Config file for managing service. If config
                 value  is  empty  string,  then  /etc/rc.conf.d/<service>
                 used.  See man rc.conf(5) for details.

                 Also  service.config  variable  can  be  used  to  change
                 default.

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.freebsdservice.enabled(name, **kwargs)
          Return True if the named service is enabled, false otherwise

          name   Service name

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.freebsdservice.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' service.get_all

   salt.modules.freebsdservice.get_disabled()
          Return what services are available but not enabled to  start  at
          boot

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.freebsdservice.get_enabled()
          Return what services are set to run on boot

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.freebsdservice.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.freebsdservice.reload(name)
          Restart the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.freebsdservice.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.freebsdservice.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.freebsdservice.status(name, sig=None)
          Return the status for a service (True or False).

          name   Name of service

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.freebsdservice.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.gem
   Manage ruby gems.

   salt.modules.gem.install(gems,  ruby=None,  gem_bin=None,   runas=None,
   version=None,  rdoc=False,  ri=False,  pre_releases=False,  proxy=None,
   source=None)
          Installs one or several gems.

          Parameters

                 * gems -- string The gems to install

                 * gem_bin -- string : None Full path  to  gem  binary  to
                   use.

                 * ruby  --  string  : None If RVM or rbenv are installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

                 * version -- string : None Specify the version to install
                   for the gem.  Doesn't play nice with multiple  gems  at
                   once

                 * rdoc -- boolean : False Generate RDoc documentation for
                   the gem(s).

                 * ri -- boolean : False Generate RI documentation for the
                   gem(s).

                 * pre_releases -- boolean : False Include pre-releases in
                   the available versions

                 * proxy -- string : None Use  the  specified  HTTP  proxy
                   server    for    all    outgoing    traffic.    Format:
                   http://hostname[:port]

          source None Use the specified HTTP gem source server to download
                 gem.  Format: http://hostname[:port]

          CLI Example:

             salt '*' gem.install vagrant

             salt '*' gem.install redphone gem_bin=/opt/sensu/embedded/bin/gem

   salt.modules.gem.list(prefix='', ruby=None, runas=None, gem_bin=None)
          List locally installed gems.

          Parameters

                 * prefix -- string : Only list gems when the name matches
                   this prefix.

                 * gem_bin -- string : None Full path  to  gem  binary  to
                   use.

                 * ruby  --  string  : None If RVM or rbenv are installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.list

   salt.modules.gem.list_upgrades(ruby=None, runas=None, gem_bin=None)
          New in version 2015.8.0.

          Check if an upgrade is available for installed gems

          gem_bin
                 None Full path to gem binary to use.

          ruby   None  If RVM or rbenv are installed, the ruby version and
                 gemset to use.  Ignored if gem_bin is specified.

          runas  None The user to run gem as.

          CLI Example:

             salt '*' gem.list_upgrades

   salt.modules.gem.sources_add(source_uri,     ruby=None,     runas=None,
   gem_bin=None)
          Add a gem source.

          Parameters

                 * source_uri -- string The source URI to add.

                 * gem_bin  --  string  :  None Full path to gem binary to
                   use.

                 * ruby -- string : None If RVM or  rbenv  are  installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.sources_add http://rubygems.org/

   salt.modules.gem.sources_list(ruby=None, runas=None, gem_bin=None)
          List the configured gem sources.

          Parameters

                 * gem_bin -- string : None Full path  to  gem  binary  to
                   use.

                 * ruby  --  string  : None If RVM or rbenv are installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.sources_list

   salt.modules.gem.sources_remove(source_uri,    ruby=None,   runas=None,
   gem_bin=None)
          Remove a gem source.

          Parameters

                 * source_uri -- string The source URI to remove.

                 * gem_bin -- string : None Full path  to  gem  binary  to
                   use.

                 * ruby  --  string  : None If RVM or rbenv are installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.sources_remove http://rubygems.org/

   salt.modules.gem.uninstall(gems, ruby=None, runas=None, gem_bin=None)
          Uninstall one or several gems.

          Parameters

                 * gems -- string The gems to uninstall.

                 * gem_bin  --  string  :  None Full path to gem binary to
                   use.

                 * ruby -- string : None If RVM or  rbenv  are  installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.uninstall vagrant

   salt.modules.gem.update(gems, ruby=None, runas=None, gem_bin=None)
          Update one or several gems.

          Parameters

                 * gems -- string The gems to update.

                 * gem_bin -- string : None Full path  to  gem  binary  to
                   use.

                 * ruby  --  string  : None If RVM or rbenv are installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.update vagrant

   salt.modules.gem.update_system(version='',    ruby=None,    runas=None,
   gem_bin=None)
          Update rubygems.

          Parameters

                 * version -- string : (newest) The version of rubygems to
                   install.

                 * gem_bin  --  string  :  None Full path to gem binary to
                   use.

                 * ruby -- string : None If RVM or  rbenv  are  installed,
                   the ruby version and gemset to use.  Ignored if gem_bin
                   is specified.

                 * runas -- string : None The user to run gem as.

          CLI Example:

             salt '*' gem.update_system

   salt.modules.genesis
   Module for managing container and VM images

   New in version 2014.7.0.

   salt.modules.genesis.avail_platforms()
          Return which platforms are available

          CLI Example:

             salt myminion genesis.avail_platforms

   salt.modules.genesis.bootstrap(platform,    root,     img_format='dir',
   fs_format='ext2',  fs_opts=None, arch=None, flavor=None, repo_url=None,
   static_qemu=None,   img_size=None,   mount_dir=None,    pkg_cache=None,
   pkgs=None,                                           exclude_pkgs=None,
   epel_url='http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm')
          Create an image for a specific platform.

          Please  note  that  this function MUST be run as root, as images
          that are created make files belonging to root.

          platform
                 Which platform to use  to  create  the  image.  Currently
                 supported platforms are rpm, deb and pacman.

          root   Local path to create the root of the image filesystem.

          img_format
                 Which  format  to  create  the image in. By default, just
                 copies files into a directory  on  the  local  filesystem
                 (dir). Future support will exist for sparse.

          fs_format
                 When  using  a  non-dir  img_format,  which filesystem to
                 format the image to. By default, ext2.

          fs_opts
                 When using a non-dir img_format, a dict of  opts  may  be
                 specified.

          arch   Architecture to install packages for, if supported by the
                 underlying bootstrap tool. Currently only used for deb.

          flavor Which  flavor  of  operating  system  to  install.   This
                 correlates  to  a  specific directory on the distribution
                 repositories. For instance, wheezy on Debian.

          repo_url
                 Mainly important for Debian-based repos. Base URL for the
                 mirror        to        install        from.       (e.x.:
                 http://ftp.debian.org/debian/)

          static_qemu
                 Local path to the static qemu binary  required  for  this
                 arch.  (e.x.: /usr/bin/qemu-amd64-static)

          pkg_confs
                 The location of the conf files to copy into the image, to
                 point the installer to the right repos and configuration.

          img_size
                 If img_format is not dir, then the size of the image must
                 be specified.

          mount_dir
                 If  img_format is not dir, then the image must be mounted
                 somewhere.  If the mount_dir is not  specified,  then  it
                 will  be created at /opt/salt-genesis.<random_uuid>. This
                 directory will be unmounted and removed when the  process
                 is finished.

          pkg_cache
                 This  points to a directory containing a cache of package
                 files to be copied to the image. It does not need  to  be
                 specified.

          pkgs   A  list  of  packages  to be installed on this image. For
                 RedHat, this will include yum, centos-release and iputils
                 by default.

          exclude_pkgs
                 A  list of packages to be excluded. If you do not want to
                 install the defaults, you need to include  them  in  this
                 list.

          epel_url
                 The URL to download the EPEL release package from.

          CLI Examples:

             salt myminion genesis.bootstrap pacman /root/arch
             salt myminion genesis.bootstrap rpm /root/redhat
             salt myminion genesis.bootstrap deb /root/wheezy arch=amd64             flavor=wheezy static_qemu=/usr/bin/qemu-x86_64-static

   salt.modules.genesis.ldd_deps(filename, ret=None)
          Recurse  through  a set of dependencies reported by ldd, to find
          associated dependencies.

          Please  note  that  this  does  not  necessarily   resolve   all
          (non-package) dependencies for a file; but it does help.

          CLI Example:
             salt    myminion    genesis.ldd_deps   bash   salt   myminion
             genesis.ldd_deps /bin/bash

   salt.modules.genesis.mksls(fmt, src, dst=None)
          Convert an installation file/script to an  SLS  file.  Currently
          supports kickstart, preseed, and autoyast.

          CLI Examples:
             salt  <minion> genesis.mksls kickstart /path/to/kickstart.cfg
             salt <minion> genesis.mksls kickstart  /path/to/kickstart.cfg
             /path/to/dest.sls

          New in version Beryllium.

   salt.modules.genesis.pack(name,   root,  path=None,  pack_format='tar',
   compress='bzip2')
          Pack up a directory structure, into a specific format

          CLI Examples:

             salt myminion genesis.pack centos /root/centos
             salt myminion genesis.pack centos /root/centos pack_format='tar'

   salt.modules.genesis.unpack(name,         dest=None,         path=None,
   pack_format='tar', compress='bz2')
          Unpack an image into a directory structure

          CLI Example:

             salt myminion genesis.unpack centos /root/centos

   salt.modules.gentoo_service
   Top level package command wrapper, used to translate the os detected by
   grains to the correct service manager

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   salt.modules.gentoo_service.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.gentoo_service.disable(name, **kwargs)
          Disable the named service to start at boot

          CLI Example:

             salt '*' service.disable <service name> <runlevels=single-runlevel>
             salt '*' service.disable <service name> <runlevels=[runlevel1,runlevel2]>

   salt.modules.gentoo_service.disabled(name)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service name> <runlevels=[runlevel]>

   salt.modules.gentoo_service.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name> <runlevels=single-runlevel>
             salt '*' service.enable <service name> <runlevels=[runlevel1,runlevel2]>

   salt.modules.gentoo_service.enabled(name, **kwargs)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.enabled <service name> <runlevels=single-runlevel>
             salt '*' service.enabled <service name> <runlevels=[runlevel1,runlevel2]>

   salt.modules.gentoo_service.get_all()
          Return all available boot services

          CLI Example:

             salt '*' service.get_all

   salt.modules.gentoo_service.get_disabled()
          Return a set of services that are installed but disabled

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.gentoo_service.get_enabled()
          Return a list of service that are enabled on boot

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.gentoo_service.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.gentoo_service.reload_(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.gentoo_service.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.gentoo_service.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.gentoo_service.status(name, sig=None)
          Return the status for a service, returns the  PID  or  an  empty
          string if the service is running or not, pass a signature to use
          to find the service via ps

          CLI Example:

             salt '*' service.status <service name> [service signature]

   salt.modules.gentoo_service.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.gentoo_service.zap(name)
          Resets service state

          CLI Example:

             salt '*' service.zap <service name>

   salt.modules.gentoolkitmod
   Support for Gentoolkit

   salt.modules.gentoolkitmod.eclean_dist(destructive=False,
   package_names=False,             size_limit=0,            time_limit=0,
   fetch_restricted=False, exclude_file='/etc/eclean/distfiles.exclude')
          Clean obsolete portage sources

          destructive
                 Only keep minimum for reinstallation

          package_names
                 Protect  all  versions  of   installed   packages.   Only
                 meaningful if used with destructive=True

          size_limit <size>
                 Don't  delete  distfiles bigger than <size>.  <size> is a
                 size specification: "10M" is "ten megabytes",  "200K"  is
                 "two hundreds kilobytes", etc. Units are: G, M, K and B.

          time_limit <time>
                 Don't delete distfiles files modified since <time> <time>
                 is an amount of time: "1y" is "one year",  "2w"  is  "two
                 weeks", etc. Units are: y (years), m (months), w (weeks),
                 d (days) and h (hours).

          fetch_restricted
                 Protect fetch-restricted files. Only meaningful  if  used
                 with destructive=True

          exclude_file
                 Path      to      exclusion      file.     Default     is
                 /etc/eclean/distfiles.exclude This is  the  same  default
                 eclean-dist  uses.  Use  None if this file exists and you
                 want to ignore.

          Returns a dict containing the  cleaned,  saved,  and  deprecated
          dists:

             {'cleaned': {<dist file>: <size>},
              'deprecated': {<package>: <dist file>},
              'saved': {<package>: <dist file>},
              'total_cleaned': <size>}

          CLI Example:

             salt '*' gentoolkit.eclean_dist destructive=True

   salt.modules.gentoolkitmod.eclean_pkg(destructive=False,
   package_names=False,                                      time_limit=0,
   exclude_file='/etc/eclean/packages.exclude')
          Clean obsolete binary packages

          destructive
                 Only keep minimum for reinstallation

          package_names
                 Protect   all   versions   of  installed  packages.  Only
                 meaningful if used with destructive=True

          time_limit <time>
                 Don't delete distfiles files modified since <time> <time>
                 is  an  amount  of time: "1y" is "one year", "2w" is "two
                 weeks", etc. Units are: y (years), m (months), w (weeks),
                 d (days) and h (hours).

          exclude_file
                 Path      to      exclusion      file.     Default     is
                 /etc/eclean/packages.exclude This  is  the  same  default
                 eclean-pkg  uses.  Use  None  if this file exists and you
                 want to ignore.

          Returns a dict containing the cleaned binary packages:

             {'cleaned': {<dist file>: <size>},
              'total_cleaned': <size>}

          CLI Example:

             salt '*' gentoolkit.eclean_pkg destructive=True

   salt.modules.gentoolkitmod.glsa_check_list(glsa_list)
          List the status of Gentoo Linux Security Advisories

          glsa_list
                 can contain an arbitrary number of  GLSA  ids,  filenames
                 containing  GLSAs  or  the  special identifiers 'all' and
                 'affected'

          Returns a dict containing glsa ids with a  description,  status,
          and CVEs:

             {<glsa_id>: {'description': <glsa_description>,
              'status': <glsa status>,
              'CVEs': [<list of CVEs>]}}

          CLI Example:

             salt '*' gentoolkit.glsa_check_list 'affected'

   salt.modules.gentoolkitmod.revdep_rebuild(lib=None)
          Fix up broken reverse dependencies

          lib    Search  for reverse dependencies for a particular library
                 rather than every library on the system. It can be a full
                 path to a library or basic regular expression.

          CLI Example:

             salt '*' gentoolkit.revdep_rebuild

   salt.modules.git
   Support for the Git SCM

   salt.modules.git.add(cwd,  filename, opts='', user=None, password=None,
   ignore_retcode=False)
          Changed in version 2015.8.0: The --verbose command line argument
          is now implied

          Interface to git-add(1)

          cwd    The path to the git checkout

          filename
                 The  location  of  the file/directory to add, relative to
                 cwd

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.add /path/to/repo foo/bar.py
             salt myminion git.add /path/to/repo foo/bar.py opts='--dry-run'

   salt.modules.git.archive(cwd,     output,     rev='HEAD',     fmt=None,
   prefix=None, user=None, password=None, ignore_retcode=False, **kwargs)
          Changed  in version 2015.8.0: Returns True if successful, raises
          an error if not.

          Interface to git-archive(1), exports a tarball/zip file  of  the
          repository

          cwd    The path to be archived

                 NOTE:
                    git  archive  permits a partial archive to be created.
                    Thus, this path does not need to be the  root  of  the
                    git  repository.  Only  the files within the directory
                    specified by cwd (and its subdirectories) will  be  in
                    the  resulting archive. For example, if there is a git
                    checkout at /tmp/foo, then passing /tmp/foo/bar as the
                    cwd   will   result   in  just  the  files  underneath
                    /tmp/foo/bar to be exported as an archive.

          output The path of the archive to be created

          overwrite
                 False Unless set to True, Salt  will  over  overwrite  an
                 existing  archive  at  the  path  specified by the output
                 argument.

                 New in version 2015.8.0.

          rev    HEAD The revision from which to create the archive

          format Manually  specify  the  file  format  of  the   resulting
                 archive.  This  argument  can be omitted, and git archive
                 will attempt to guess the archive type (and  compression)
                 from   the  filename.  zip,  tar,  tar.gz,  and  tgz  are
                 extensions that are recognized automatically, and git can
                 be  configured  to  support  other archive types with the
                 addition of git configuration keys.

                 See  the  git-archive(1)  manpage  explanation   of   the
                 --format  argument  (as well as the CONFIGURATION section
                 of the manpage) for further information.

                 New in version 2015.8.0.

          fmt    Replaced by format in version 2015.8.0

                 Deprecated since version 2015.8.0.

          prefix Prepend <prefix> to every filename  in  the  archive.  If
                 unspecified,  the  name of the directory at the top level
                 of the repository will be used as the prefix (e.g. if cwd
                 is  set  to /foo/bar/baz, the prefix will be baz, and the
                 resulting archive will contain a top-level  directory  by
                 that name).

                 NOTE:
                    The  default  behavior  if the --prefix option for git
                    archive is not specified is to not prepend  a  prefix,
                    so  Salt's  behavior differs slightly from git archive
                    in this respect. Use prefix='' to  create  an  archive
                    with no prefix.

                 Changed   in  version  2015.8.0:  The  behavior  of  this
                 argument has been changed slightly. As of  this  version,
                 it  is  necessary  to  include  the  trailing  slash when
                 specifying a prefix, if the prefix is intended to  create
                 a top-level directory.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.archive /path/to/repo /path/to/archive.tar

   salt.modules.git.branch(cwd,     name=None,     opts='',     user=None,
   password=None, ignore_retcode=False)
          Interface to git-branch(1)

          cwd    The path to the git checkout

          name   Name of the branch on which to operate. If not specified,
                 the current branch will be assumed.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    To create a branch based on something other than HEAD,
                    pass the name of the revision as opts. If the revision
                    is in the format  remotename/branch,  then  this  will
                    also set the remote tracking branch.

                    Additionally,  on  the  Salt  CLI,  if  the  opts  are
                    preceded with a dash, it is necessary to precede  them
                    with  opts=  (as  in  the CLI examples below) to avoid
                    causing errors with Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             # Set remote tracking branch
             salt myminion git.branch /path/to/repo mybranch opts='--set-upstream-to origin/mybranch'
             # Create new branch
             salt myminion git.branch /path/to/repo mybranch upstream/somebranch
             # Delete branch
             salt myminion git.branch /path/to/repo mybranch opts='-d'
             # Rename branch (2015.8.0 and later)
             salt myminion git.branch /path/to/repo newbranch opts='-m oldbranch'

   salt.modules.git.checkout(cwd,    rev=None,    force=False,    opts='',
   user=None, password=None, ignore_retcode=False)
          Interface to git-checkout(1)

          cwd    The path to the git checkout

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

          rev    The remote branch or revision to checkout.

                 Changed in version 2015.8.0: Optional when using -b or -B
                 in opts.

          force  False Force a checkout even if there might be overwritten
                 changes

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             # Checking out local local revisions
             salt myminion git.checkout /path/to/repo somebranch user=jeff
             salt myminion git.checkout /path/to/repo opts='testbranch -- conf/file1 file2'
             salt myminion git.checkout /path/to/repo rev=origin/mybranch opts='--track'
             # Checking out remote revision into new branch
             salt myminion git.checkout /path/to/repo upstream/master opts='-b newbranch'
             # Checking out current revision into new branch (2015.8.0 and later)
             salt myminion git.checkout /path/to/repo opts='-b newbranch'

   salt.modules.git.clone(cwd,  url=None,  name=None,  opts='', user=None,
   password=None,   identity=None,    https_user=None,    https_pass=None,
   ignore_retcode=False, repository=None, saltenv='base')
          Interface to git-clone(1)

          cwd    Location of git clone

                 Changed  in version 2015.8.0: If name is passed, then the
                 clone will be made within this directory.

          url    The URL of the repository to be cloned

                 Changed  in  version  2015.8.0:  Argument  renamed   from
                 repository to url

          name   Optional alternate name for the top-level directory to be
                 created by the clone

                 New in version 2015.8.0.

          opts   Any additional options to add to the command line,  in  a
                 single string

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless  Salt  is  invoked  from   the   minion   using
                    salt-call,  the  key(s)  must  be  passphraseless. For
                    greater security with passphraseless private keys, see
                    the  sshd(8)  manpage  for information on securing the
                    keypair from the remote side  in  the  authorized_keys
                    file.

                 Changed  in version 2015.8.7: Salt will no longer attempt
                 to use passphrase-protected keys unless invoked from  the
                 minion  using  salt-call, to prevent blocking waiting for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          https_user
                 Set  HTTP  Basic  Auth  username. Only accepted for HTTPS
                 URLs.

                 New in version 20515.5.0.

          https_pass
                 Set HTTP Basic Auth password.  Only  accepted  for  HTTPS
                 URLs.

                 New in version 2015.5.0.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             salt myminion git.clone /path/to/repo_parent_dir git://github.com/saltstack/salt.git

   salt.modules.git.commit(cwd,     message,      opts='',      user=None,
   password=None, filename=None, ignore_retcode=False)
          Interface to git-commit(1)

          cwd    The path to the git checkout

          message
                 Commit message

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

                    The -m option should not be passed here, as the commit
                    message will be defined by the message argument.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          filename
                 The location of the file/directory to commit, relative to
                 cwd.  This argument is  optional,  and  can  be  used  to
                 commit a file without first staging it.

                 NOTE:
                    This  argument  only  works on files which are already
                    tracked by the git repository.

                 New in version 2015.8.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.commit /path/to/repo 'The commit message'
             salt myminion git.commit /path/to/repo 'The commit message' filename=foo/bar.py

   salt.modules.git.config_get(key,  cwd=None,  user=None,  password=None,
   ignore_retcode=False, **kwargs)
          Get the value of a key in the git configuration file

          key    The name of the configuration key to get

                 Changed  in  version  2015.8.0:  Argument  renamed   from
                 setting_name to key

          cwd    The path to the git checkout

                 Changed  in  version  2015.8.0: Now optional if global is
                 set to True

          global False  If  True,  query  the  global  git  configuration.
                 Otherwise,  only  the  local  git  configuration  will be
                 queried.

                 New in version 2015.8.0.

          all    False If True, return a list of all values set  for  key.
                 If the key does not exist, None will be returned.

                 New in version 2015.8.0.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.config_get user.name cwd=/path/to/repo
             salt myminion git.config_get user.email global=True
             salt myminion git.config_get core.gitproxy cwd=/path/to/repo all=True

   salt.modules.git.config_get_regexp(key,   value_regex=None,   cwd=None,
   user=None, password=None, ignore_retcode=False, **kwargs)
          New in version 2015.8.0.

          Get the value of a key or keys in  the  git  configuration  file
          using  regexes  for more flexible matching. The return data is a
          dictionary  mapping  keys  to  lists  of  values  matching   the
          value_regex.  If  no  values  match, an empty dictionary will be
          returned.

          key    Regex on which key names will be matched

          value_regex
                 If specified, return all values matching this regex.  The
                 return data will be a dictionary mapping keys to lists of
                 values matching the regex.

                 IMPORTANT:
                    Only values matching the value_regex will be  part  of
                    the  return  data. So, if key matches a multivar, then
                    it is possible that not all  of  the  values  will  be
                    returned. To get all values set for a multivar, simply
                    omit the value_regex argument.

          cwd    The path to the git checkout

          global False  If  True,  query  the  global  git  configuration.
                 Otherwise,  only  the  local  git  configuration  will be
                 queried.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

          CLI Examples:

             # Matches any values for key 'foo.bar'
             salt myminion git.config_get_regexp /path/to/repo foo.bar
             # Matches any value starting with 'baz' set for key 'foo.bar'
             salt myminion git.config_get_regexp /path/to/repo foo.bar 'baz.*'
             # Matches any key starting with 'user.'
             salt myminion git.config_get_regexp '^user\.' global=True

   salt.modules.git.config_set(key, value=None,  multivar=None,  cwd=None,
   user=None, password=None, ignore_retcode=False, **kwargs)
          Changed  in  version  2015.8.0:  Return  the value(s) of the key
          being set

          Set a key in the git configuration file

          cwd    The path to the git checkout. Must be an  absolute  path,
                 or  the  word global to indicate that a global key should
                 be set.

                 Changed in version 2014.7.0: Made cwd  argument  optional
                 if is_global=True

          key    The name of the configuration key to set

                 Changed   in  version  2015.8.0:  Argument  renamed  from
                 setting_name to key

          value  The value to set for the specified key. Incompatible with
                 the multivar argument.

                 Changed   in  version  2015.8.0:  Argument  renamed  from
                 setting_value to value

          add    False Add a value to a key, creating/updating a multivar

                 New in version 2015.8.0.

          multivar
                 Set a multivar all at once. Values can be comma-separated
                 or  passed  as a Python list. Incompatible with the value
                 argument.

                 New in version 2015.8.0.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          global False If True, set a global variable

          is_global
                 False If True, set a global variable

                 Deprecated since version 2015.8.0: Use global instead

          CLI Example:

             salt myminion git.config_set user.email [email protected] cwd=/path/to/repo
             salt myminion git.config_set user.email [email protected] global=True

   salt.modules.git.config_unset(key,     value_regex=None,      cwd=None,
   user=None, password=None, ignore_retcode=False, **kwargs)
          New in version 2015.8.0.

          Unset a key in the git configuration file

          cwd    The  path  to the git checkout. Must be an absolute path,
                 or the word global to indicate that a global  key  should
                 be unset.

          key    The name of the configuration key to unset

          value_regex
                 Regular  expression that matches exactly one key, used to
                 delete a single value from a multivar. Ignored if all  is
                 set to True.

          all    False  If True unset all values for a multivar. If False,
                 and key is a multivar, an error will be raised.

          global False If True, unset set a global variable. Otherwise,  a
                 local variable will be unset.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

          CLI Example:

             salt myminion git.config_unset /path/to/repo foo.bar
             salt myminion git.config_unset /path/to/repo foo.bar all=True

   salt.modules.git.current_branch(cwd,      user=None,     password=None,
   ignore_retcode=False)
          Returns the current branch name of a local checkout. If HEAD  is
          detached,  return  the  SHA1  of the revision which is currently
          checked out.

          cwd    The path to the git checkout

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.current_branch /path/to/repo

   salt.modules.git.describe(cwd,  rev='HEAD',  user=None,  password=None,
   ignore_retcode=False)
          Returns  the  git-describe(1)  string (or the SHA1 hash if there
          are no tags) for the given revision.

          cwd    The path to the git checkout

          rev    HEAD The revision to describe

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.describe /path/to/repo
             salt myminion git.describe /path/to/repo develop

   salt.modules.git.diff(cwd, item1=None, item2=None, opts='',  user=None,
   password=None, no_index=False, cached=False, paths=None)
          New in version 2015.8.12,2016.3.3,2016.11.0.

          Interface to git-diff(1)

          cwd    The path to the git checkout

          item1 and item2
                 Revision(s)  to pass to the git diff command. One or both
                 of these arguments may be ignored if some of the  options
                 below  are  set  to  True.  When  cached is False, and no
                 revisions are passed to this function, then  the  current
                 working  tree  will  be  compared against the index (i.e.
                 unstaged changes). When two revisions  are  passed,  they
                 will be compared to each other.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          no_index
                 False When it is necessary to diff two files in the  same
                 repo  against  each  other,  and  not  diff two different
                 revisions, set this option to True. If this is left False
                 in  these  instances,  then  a  normal  git  diff will be
                 performed against the index (i.e. unstaged changes),  and
                 files in the paths option will be used to narrow down the
                 diff output.

                 NOTE:
                    Requires Git 1.5.1 or newer. Additionally, when set to
                    True, item1 and item2 will be ignored.

          cached False  If  True,  compare  staged  changes  to  item1 (if
                 specified), otherwise compare them  to  the  most  recent
                 commit.

                 NOTE:
                    item2 is ignored if this option is is set to True.

          paths  File paths to pass to the git diff command. Can be passed
                 as a comma-separated list or a Python list.

          CLI Example:

             # Perform diff against the index (staging area for next commit)
             salt myminion git.diff /path/to/repo
             # Compare staged changes to the most recent commit
             salt myminion git.diff /path/to/repo cached=True
             # Compare staged changes to a specific revision
             salt myminion git.diff /path/to/repo mybranch cached=True
             # Perform diff against the most recent commit (includes staged changes)
             salt myminion git.diff /path/to/repo HEAD
             # Diff two commits
             salt myminion git.diff /path/to/repo abcdef1 aabbccd
             # Diff two commits, only showing differences in the specified paths
             salt myminion git.diff /path/to/repo abcdef1 aabbccd paths=path/to/file1,path/to/file2
             # Diff two files with one being outside the working tree
             salt myminion git.diff /path/to/repo no_index=True paths=path/to/file1,/absolute/path/to/file2

   salt.modules.git.fetch(cwd,  remote=None,  force=False,  refspecs=None,
   opts='', user=None, password=None, identity=None, ignore_retcode=False,
   saltenv='base')
          Changed in version 2015.8.2: Return data  is  now  a  dictionary
          containing   information   on   branches   and  tags  that  were
          added/updated

          Interface to git-fetch(1)

          cwd    The path to the git checkout

          remote Optional remote name to fetch. If not  passed,  then  git
                 will   use   its   default   behavior   (as  detailed  in
                 git-fetch(1)).

                 New in version 2015.8.0.

          force  Force the fetch even when it is not a fast-forward.

                 New in version 2015.8.0.

          refspecs
                 Override the refspec(s) configured for  the  remote  with
                 this   argument.    Multiple   refspecs  can  be  passed,
                 comma-separated.

                 New in version 2015.8.0.

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             salt myminion git.fetch /path/to/repo upstream
             salt myminion git.fetch /path/to/repo identity=/root/.ssh/id_rsa

   salt.modules.git.init(cwd,          bare=False,          template=None,
   separate_git_dir=None, shared=None, opts='', user=None,  password=None,
   ignore_retcode=False)
          Interface to git-init(1)

          cwd    The path to the directory to be initialized

          bare   False If True, init a bare repository

                 New in version 2015.8.0.

          template
                 Set  this  argument  to  specify  an  alternate  template
                 directory

                 New in version 2015.8.0.

          separate_git_dir
                 Set this argument to specify an alternate $GIT_DIR

                 New in version 2015.8.0.

          shared Set sharing permissions on git repo. See git-init(1)  for
                 more details.

                 New in version 2015.8.0.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.init /path/to/repo
             # Init a bare repo (before 2015.8.0)
             salt myminion git.init /path/to/bare/repo.git opts='--bare'
             # Init a bare repo (2015.8.0 and later)
             salt myminion git.init /path/to/bare/repo.git bare=True

   salt.modules.git.is_worktree(cwd, user=None, password=None)
          New in version 2015.8.0.

          This  function  will  attempt  to  determine if cwd is part of a
          worktree by checking its .git to see if it is a file  containing
          a reference to another gitdir.

          cwd    path to the worktree to be removed

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          CLI Example:

             salt myminion git.is_worktree /path/to/repo

   salt.modules.git.list_branches(cwd,      remote=False,       user=None,
   password=None, ignore_retcode=False)
          New in version 2015.8.0.

          Return a list of branches

          cwd    The path to the git checkout

          remote False  If  True,  list  remote branches. Otherwise, local
                 branches will be listed.

                 WARNING:
                    This option will only return remote branches of  which
                    the  local  checkout is aware, use git.fetch to update
                    remotes.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.list_branches /path/to/repo
             salt myminion git.list_branches /path/to/repo remote=True

   salt.modules.git.list_tags(cwd,        user=None,        password=None,
   ignore_retcode=False)
          New in version 2015.8.0.

          Return a list of tags

          cwd    The path to the git checkout

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.list_tags /path/to/repo

   salt.modules.git.list_worktrees(cwd,       stale=False,      user=None,
   password=None, **kwargs)
          New in version 2015.8.0.

          Returns information on worktrees

          Changed in  version  2015.8.4:  Version  2.7.0  added  the  list
          subcommand to git-worktree(1) which provides a lot of additional
          information. The return data has been changed  to  include  this
          information, even for pre-2.7.0 versions of git. In addition, if
          a worktree has a detached head, then any tags which point to the
          worktree's HEAD will be included in the return data.

          NOTE:
             By  default,  only worktrees for which the worktree directory
             is still present are returned, but this can be changed  using
             the all and stale arguments (described below).

          cwd    The path to the git checkout

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          all    False If True, then return all  worktrees  tracked  under
                 $GIT_DIR/worktrees,  including  ones for which the gitdir
                 is no longer present.

          stale  False If True, return only worktrees whose gitdir  is  no
                 longer present.

          NOTE:
             Only one of all and stale can be set to True.

          CLI Examples:

             salt myminion git.list_worktrees /path/to/repo
             salt myminion git.list_worktrees /path/to/repo all=True
             salt myminion git.list_worktrees /path/to/repo stale=True

   salt.modules.git.ls_remote(cwd=None,     remote='origin',     ref=None,
   opts='',  user=None,  password=None,  identity=None,   https_user=None,
   https_pass=None, ignore_retcode=False, saltenv='base')
          Interface  to  git-ls-remote(1). Returns the upstream hash for a
          remote reference.

          cwd    The path to the git checkout. Optional  (and  ignored  if
                 present)  when remote is set to a URL instead of a remote
                 name.

          remote origin The name of the remote to query. Can be  the  name
                 of a git remote (which exists in the git checkout defined
                 by the cwd parameter), or the URL of a remote repository.

                 Changed  in  version  2015.8.0:  Argument  renamed   from
                 repository to remote

          ref    The name of the ref to query. Optional, if not specified,
                 all refs are returned. Can be a branch or  tag  name,  or
                 the  full  name of the reference (for example, to get the
                 hash for a Github pull request number 1234,  ref  can  be
                 set to refs/pull/1234/head

                 Changed in version 2015.8.0: Argument renamed from branch
                 to ref

                 Changed in version 2015.8.4: Defaults  to  returning  all
                 refs instead of master.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 New in version 2015.8.0.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          https_user
                 Set HTTP Basic Auth username.  Only  accepted  for  HTTPS
                 URLs.

                 New in version 2015.5.0.

          https_pass
                 Set  HTTP  Basic  Auth  password. Only accepted for HTTPS
                 URLs.

                 New in version 2015.5.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             salt myminion git.ls_remote /path/to/repo origin master
             salt myminion git.ls_remote remote=https://mydomain.tld/repo.git ref=mytag opts='--tags'

   salt.modules.git.merge(cwd,      rev=None,      opts='',     user=None,
   password=None, ignore_retcode=False, **kwargs)
          Interface to git-merge(1)

          cwd    The path to the git checkout

          rev    Revision  to  merge  into  the  current  branch.  If  not
                 specified, the remote tracking branch will be merged.

                 New in version 2015.8.0.

          branch The  remote  branch or revision to merge into the current
                 branch Revision to merge into the current branch

                 Deprecated since version 2015.8.0: Use rev instead.

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             # Fetch first...
             salt myminion git.fetch /path/to/repo
             # ... then merge the remote tracking branch
             salt myminion git.merge /path/to/repo
             # .. or merge another rev
             salt myminion git.merge /path/to/repo rev=upstream/foo

   salt.modules.git.merge_base(cwd,       refs=None,        octopus=False,
   is_ancestor=False,    independent=False,    fork_point=None,   opts='',
   user=None, password=None, ignore_retcode=False, **kwargs)
          New in version 2015.8.0.

          Interface to git-merge-base(1).

          cwd    The path to the git checkout

          refs   Any refs/commits to check for a merge base. Can be passed
                 as a comma-separated list or a Python list.

          all    False  Return  a  list  of  all matching merge bases. Not
                 compatible with any  of  the  below  options  except  for
                 octopus.

          octopus
                 False If True, then this function will determine the best
                 common ancestors of all specified commits, in preparation
                 for  an  n-way  merge.  See here for a description of how
                 these bases are determined.

                 Set all to True with this option to return  all  computed
                 merge bases, otherwise only the "best" will be returned.

          is_ancestor
                 False  If True, then instead of returning the merge base,
                 return a boolean telling whether or not the first  commit
                 is an ancestor of the second commit.

                 NOTE:
                    This option requires two commits to be passed.

                 Changed  in  version  2015.8.2:  Works  properly  in  git
                 versions older than 1.8.0, where  the  --is-ancestor  CLI
                 option is not present.

          independent
                 False  If  True, this function will return the IDs of the
                 refs/commits passed which cannot be  reached  by  another
                 commit.

          fork_point
                 If  passed,  then  this  function  will return the commit
                 where the commit  diverged  from  the  ref  specified  by
                 fork_point. If no fork point is found, None is returned.

                 NOTE:
                    At  most  one  commit  is  permitted to be passed if a
                    fork_point is specified. If  no  commits  are  passed,
                    then HEAD is assumed.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

                    This  option  should  not  be necessary unless new CLI
                    arguments are added to git-merge-base(1) and  are  not
                    yet supported in Salt.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False if True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

          CLI Examples:

             salt myminion git.merge_base /path/to/repo HEAD upstream/mybranch
             salt myminion git.merge_base /path/to/repo 8f2e542,4ad8cab,cdc9886 octopus=True
             salt myminion git.merge_base /path/to/repo refs=8f2e542,4ad8cab,cdc9886 independent=True
             salt myminion git.merge_base /path/to/repo refs=8f2e542,4ad8cab is_ancestor=True
             salt myminion git.merge_base /path/to/repo fork_point=upstream/master
             salt myminion git.merge_base /path/to/repo refs=mybranch fork_point=upstream/master

   salt.modules.git.merge_tree(cwd,   ref1,  ref2,  base=None,  user=None,
   password=None, ignore_retcode=False)
          New in version 2015.8.0.

          Interface to git-merge-tree(1),  shows  the  merge  results  and
          conflicts from a 3-way merge without touching the index.

          cwd    The path to the git checkout

          ref1   First ref/commit to compare

          ref2   Second ref/commit to compare

          base   The  base  tree  to  use  for  the  3-way-merge.  If  not
                 provided, then git.merge_base will be invoked on ref1 and
                 ref2 to determine the merge base to use.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False if True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

          CLI Examples:

             salt myminion git.merge_tree /path/to/repo HEAD upstream/dev
             salt myminion git.merge_tree /path/to/repo HEAD upstream/dev base=aaf3c3d

   salt.modules.git.pull(cwd,     opts='',    user=None,    password=None,
   identity=None, ignore_retcode=False, saltenv='base')
          Interface to git-pull(1)

          cwd    The path to the git checkout

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             salt myminion git.pull /path/to/repo opts='--rebase origin master'

   salt.modules.git.push(cwd,  remote=None,  ref=None, opts='', user=None,
   password=None,  identity=None,  ignore_retcode=False,   saltenv='base',
   **kwargs)
          Interface to git-push(1)

          cwd    The path to the git checkout

          remote Name of the remote to which the ref should being pushed

                 New in version 2015.8.0.

          ref    master Name of the ref to push

                 NOTE:
                    Being  a refspec, this argument can include a colon to
                    define local and remote ref names.

          branch Name of the ref to push

                 Deprecated since version 2015.8.0: Use ref instead

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             # Push master as origin/master
             salt myminion git.push /path/to/repo origin master
             # Push issue21 as upstream/develop
             salt myminion git.push /path/to/repo upstream issue21:develop
             # Delete remote branch 'upstream/temp'
             salt myminion git.push /path/to/repo upstream :temp

   salt.modules.git.rebase(cwd,    rev='master',    opts='',    user=None,
   password=None, ignore_retcode=False)
          Interface to git-rebase(1)

          cwd    The path to the git checkout

          rev    master The revision to rebase onto the current branch

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.rebase /path/to/repo master
             salt myminion git.rebase /path/to/repo 'origin master'
             salt myminion git.rebase /path/to/repo origin/master opts='--onto newbranch'

   salt.modules.git.remote_get(cwd,      remote='origin',       user=None,
   password=None, redact_auth=True, ignore_retcode=False)
          Get the fetch and push URL for a specific remote

          cwd    The path to the git checkout

          remote origin Name of the remote to query

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          redact_auth
                 True Set to False to include the username/password if the
                 remote uses HTTPS Basic Auth. Otherwise, this information
                 will be redacted.

                 WARNING:
                    Setting this to False will not only reveal  any  HTTPS
                    Basic  Auth  that  is  configured, but the return data
                    will also be written to the job cache. When  possible,
                    it is recommended to use SSH for authentication.

                 New in version 2015.5.6.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.remote_get /path/to/repo
             salt myminion git.remote_get /path/to/repo upstream

   salt.modules.git.remote_refs(url, heads=False,  tags=False,  user=None,
   password=None,    identity=None,    https_user=None,   https_pass=None,
   ignore_retcode=False, saltenv='base')
          New in version 2015.8.0.

          Return the remote refs for the specified URL

          url    URL of the remote repository

          heads  False Restrict output to  heads.  Can  be  combined  with
                 tags.

          tags   False  Restrict  output  to  tags.  Can  be combined with
                 heads.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          https_user
                 Set HTTP Basic Auth username.  Only  accepted  for  HTTPS
                 URLs.

          https_pass
                 Set  HTTP  Basic  Auth  password. Only accepted for HTTPS
                 URLs.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             salt myminion git.remote_refs https://github.com/saltstack/salt.git

   salt.modules.git.remote_set(cwd,   url,   remote='origin',   user=None,
   password=None,   https_user=None,    https_pass=None,    push_url=None,
   push_https_user=None, push_https_pass=None, ignore_retcode=False)

          cwd    The path to the git checkout

          url    Remote URL to set

          remote origin Name of the remote to set

          push_url
                 If  unset,  the  push  URL will be identical to the fetch
                 URL.

                 New in version 2015.8.0.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          https_user
                 Set  HTTP  Basic  Auth  username. Only accepted for HTTPS
                 URLs.

                 New in version 2015.5.0.

          https_pass
                 Set HTTP Basic Auth password.  Only  accepted  for  HTTPS
                 URLs.

                 New in version 2015.5.0.

          push_https_user
                 Set  HTTP  Basic  Auth  user  for  push_url.  Ignored  if
                 push_url is unset. Only accepted for HTTPS URLs.

                 New in version 2015.8.0.

          push_https_pass
                 Set HTTP Basic Auth password  for  push_url.  Ignored  if
                 push_url is unset. Only accepted for HTTPS URLs.

                 New in version 2015.8.0.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.remote_set /path/to/repo [email protected]:user/repo.git
             salt myminion git.remote_set /path/to/repo [email protected]:user/repo.git remote=upstream
             salt myminion git.remote_set /path/to/repo https://github.com/user/repo.git remote=upstream push_url=[email protected]:user/repo.git

   salt.modules.git.remotes(cwd,         user=None,         password=None,
   redact_auth=True, ignore_retcode=False)
          Get fetch and push URLs for each remote in a git checkout

          cwd    The path to the git checkout

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          redact_auth
                 True Set to False to include  the  username/password  for
                 authenticated remotes in the return data. Otherwise, this
                 information will be redacted.

                 WARNING:
                    Setting this to False will not only reveal  any  HTTPS
                    Basic  Auth  that  is  configured, but the return data
                    will also be written to the job cache. When  possible,
                    it is recommended to use SSH for authentication.

                 New in version 2015.5.6.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.remotes /path/to/repo

   salt.modules.git.reset(cwd,    opts='',    user=None,    password=None,
   ignore_retcode=False)
          Interface  to  git-reset(1),  returns  the  stdout  from the git
          command

          cwd    The path to the git checkout

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with opts= (as in  the
                    CLI  examples  below)  to  avoid  causing  errors with
                    Salt's own argument parsing.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             # Soft reset to a specific commit ID
             salt myminion git.reset /path/to/repo ac3ee5c
             # Hard reset
             salt myminion git.reset /path/to/repo opts='--hard origin/master'

   salt.modules.git.rev_parse(cwd,    rev=None,    opts='',     user=None,
   password=None, ignore_retcode=False)
          New in version 2015.8.0.

          Interface to git-rev-parse(1)

          cwd    The path to the git checkout

          rev    Revision  to  parse. See the SPECIFYING REVISIONS section
                 of the git-rev-parse(1) manpage for  details  on  how  to
                 format this argument.

                 This  argument  is optional when using the options in the
                 Options  for  Files  section  of   the   git-rev-parse(1)
                 manpage.

          opts   Any  additional  options to add to the command line, in a
                 single string

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

          CLI Examples:

             # Get the full SHA1 for HEAD
             salt myminion git.rev_parse /path/to/repo HEAD
             # Get the short SHA1 for HEAD
             salt myminion git.rev_parse /path/to/repo HEAD opts='--short'
             # Get the develop branch's upstream tracking branch
             salt myminion git.rev_parse /path/to/repo 'develop@{upstream}' opts='--abbrev-ref'
             # Get the SHA1 for the commit corresponding to tag v1.2.3
             salt myminion git.rev_parse /path/to/repo 'v1.2.3^{commit}'
             # Find out whether or not the repo at /path/to/repo is a bare repository
             salt myminion git.rev_parse /path/to/repo opts='--is-bare-repository'

   salt.modules.git.revision(cwd,  rev='HEAD',   short=False,   user=None,
   password=None, ignore_retcode=False)
          Returns  the SHA1 hash of a given identifier (hash, branch, tag,
          HEAD, etc.)

          cwd    The path to the git checkout

          rev    HEAD The revision

          short  False If True, return an abbreviated SHA1 git hash

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.revision /path/to/repo mybranch

   salt.modules.git.rm(cwd, filename, opts='',  user=None,  password=None,
   ignore_retcode=False)
          Interface to git-rm(1)

          cwd    The path to the git checkout

          filename
                 The location of the file/directory to remove, relative to
                 cwd

                 NOTE:
                    To remove a directory, -r must be  part  of  the  opts
                    parameter.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.rm /path/to/repo foo/bar.py
             salt myminion git.rm /path/to/repo foo/bar.py opts='--dry-run'
             salt myminion git.rm /path/to/repo foo/baz opts='-r'

   salt.modules.git.stash(cwd,    action='save',    opts='',    user=None,
   password=None, ignore_retcode=False)
          Interface to git-stash(1),  returns  the  stdout  from  the  git
          command

          cwd    The path to the git checkout

          opts   Any  additional  options to add to the command line, in a
                 single string.   Use  this  to  complete  the  git  stash
                 command  by  adding  the remaining arguments (i.e.  'save
                 <stash  comment>',  'apply  stash@{2}',  'show',   etc.).
                 Omitting this argument will simply run git stash.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.stash /path/to/repo save opts='work in progress'
             salt myminion git.stash /path/to/repo apply opts='stash@{1}'
             salt myminion git.stash /path/to/repo drop opts='stash@{1}'
             salt myminion git.stash /path/to/repo list

   salt.modules.git.status(cwd,          user=None,         password=None,
   ignore_retcode=False)
          Changed in version 2015.8.0: Return data has changed from a list
          of lists to a dictionary

          Returns the changes to the repository

          cwd    The path to the git checkout

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Example:

             salt myminion git.status /path/to/repo

   salt.modules.git.submodule(cwd,     command,     opts='',    user=None,
   password=None,  identity=None,  ignore_retcode=False,   saltenv='base',
   **kwargs)
          Changed in version 2015.8.0: Added the command argument to allow
          for operations other than update to be run  on  submodules,  and
          deprecated  the  init  argument.  To  do a submodule update with
          init=True moving forward, use command=update opts='--init'

          Interface to git-submodule(1)

          cwd    The path to the submodule

          command
                 Submodule  command  to  run,  see  git-submodule(1)  <git
                 submodule> for more information. Any additional arguments
                 after  the  command  (such  as  the  URL  when  adding  a
                 submodule) must be passed in the opts parameter.

                 New in version 2015.8.0.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is necessary to precede them with opts= (as in the
                    CLI examples  below)  to  avoid  causing  errors  with
                    Salt's own argument parsing.

          init   False   If   True,   ensures   that  new  submodules  are
                 initialized

                 Deprecated since  version  2015.8.0:  Pass  init  as  the
                 command  parameter,  or  include --init in the opts param
                 with command set to update.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          identity
                 Path to a private key to use for ssh URLs

                 WARNING:
                    Unless   Salt   is   invoked  from  the  minion  using
                    salt-call, the  key(s)  must  be  passphraseless.  For
                    greater security with passphraseless private keys, see
                    the sshd(8) manpage for information  on  securing  the
                    keypair  from  the  remote side in the authorized_keys
                    file.

                 Changed in version 2015.8.7: Salt will no longer  attempt
                 to  use passphrase-protected keys unless invoked from the
                 minion using salt-call, to prevent blocking  waiting  for
                 user input.

                 Key can also be specified as a SaltStack file server URL,
                 eg. salt://location/identity_file

                 Changed in version 2016.3.0.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          saltenv
                 The default salt environment to pull sls files from

                 New in version 2016.3.1.

          CLI Example:

             # Update submodule and ensure it is initialized (before 2015.8.0)
             salt myminion git.submodule /path/to/repo/sub/repo init=True
             # Update submodule and ensure it is initialized (2015.8.0 and later)
             salt myminion git.submodule /path/to/repo/sub/repo update opts='--init'

             # Rebase submodule (2015.8.0 and later)
             salt myminion git.submodule /path/to/repo/sub/repo update opts='--rebase'

             # Add submodule (2015.8.0 and later)
             salt myminion git.submodule /path/to/repo/sub/repo add opts='https://mydomain.tld/repo.git'

             # Unregister submodule (2015.8.0 and later)
             salt myminion git.submodule /path/to/repo/sub/repo deinit

   salt.modules.git.symbolic_ref(cwd, ref, value=None, opts='', user=None,
   password=None, ignore_retcode=False)
          New in version 2015.8.0.

          Interface to git-symbolic-ref(1)

          cwd    The path to the git checkout

          ref    Symbolic ref to read/modify

          value  If passed, then the symbolic ref  will  be  set  to  this
                 value and an empty string will be returned.

                 If  not  passed, then the ref to which ref points will be
                 returned, unless --delete is included in opts  (in  which
                 case the symbolic ref will be deleted).

          opts   Any  additional  options to add to the command line, in a
                 single string

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             # Get ref to which HEAD is pointing
             salt myminion git.symbolic_ref /path/to/repo HEAD
             # Set/overwrite symbolic ref 'FOO' to local branch 'foo'
             salt myminion git.symbolic_ref /path/to/repo FOO refs/heads/foo
             # Delete symbolic ref 'FOO'
             salt myminion git.symbolic_ref /path/to/repo FOO opts='--delete'

   salt.modules.git.version(versioninfo=False)
          New in version 2015.8.0.

          Returns the version of Git installed on the minion

          versioninfo
                 False If True, return the version in a  versioninfo  list
                 (e.g. [2, 5, 0])

          CLI Example:

             salt myminion git.version

   salt.modules.git.worktree_add(cwd,       worktree_path,       ref=None,
   reset_branch=None,  force=None,   detach=False,   opts='',   user=None,
   password=None, ignore_retcode=False, **kwargs)
          New in version 2015.8.0.

          Interface to git-worktree(1), adds a worktree

          cwd    The path to the git checkout

          worktree_path
                 Path  to  the  new  worktree.  Can be either absolute, or
                 relative to cwd.

          branch Name of new branch to create. If omitted, will be set  to
                 the  basename  of  the worktree_path. For example, if the
                 worktree_path is /foo/bar/baz, then branch will be baz.

          ref    Name of the ref on which to base  the  new  worktree.  If
                 omitted,  then  HEAD  is  use,  and  a new branch will be
                 created, named for the basename of the worktree_path. For
                 example,  if the worktree_path is /foo/bar/baz then a new
                 branch baz will be created, and pointed at HEAD.

          reset_branch
                 False If False, then git-worktree(1) will fail to  create
                 the  worktree  if the targeted branch already exists. Set
                 this argument to True to reset  the  targeted  branch  to
                 point  at  ref,  and checkout the newly-reset branch into
                 the new worktree.

          force  False By default, git-worktree(1)  will  not  permit  the
                 same  branch to be checked out in more than one worktree.
                 Set this argument to True to override this.

          opts   Any additional options to add to the command line,  in  a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it is necessary to precede them with  opts=  to  avoid
                    causing errors with Salt's own argument parsing.

                    All  CLI  options for adding worktrees as of Git 2.5.0
                    are already supported by  this  function  as  of  Salt
                    2015.8.0, so using this argument is unnecessary unless
                    new CLI arguments are added to git-worktree(1) and are
                    not yet supported in Salt.

          user   User  under which to run the git command. By default, the
                 command is run by the user  under  which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False If True, do not log an error to the minion  log  if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.worktree_add /path/to/repo/main ../hotfix ref=origin/master
             salt myminion git.worktree_add /path/to/repo/main ../hotfix branch=hotfix21 ref=v2.1.9.3

   salt.modules.git.worktree_prune(cwd,    dry_run=False,    verbose=True,
   expire=None, opts='', user=None, password=None, ignore_retcode=False)
          New in version 2015.8.0.

          Interface   to   git-worktree(1),    prunes    stale    worktree
          administrative data from the gitdir

          cwd    The path to the main git checkout or a linked worktree

          dry_run
                 False  If True, then this function will report what would
                 have been pruned, but no changes will be made.

          verbose
                 True Report all changes made. Set to  False  to  suppress
                 this output.

          expire Only  prune  unused  worktree  data older than a specific
                 period of time.  The date format for  this  parameter  is
                 described     in     the     documentation     for    the
                 gc.pruneWorktreesExpire config param in the git-config(1)
                 manpage.

          opts   Any  additional  options to add to the command line, in a
                 single string

                 NOTE:
                    On the Salt CLI, if the opts are preceded with a dash,
                    it  is  necessary  to precede them with opts= to avoid
                    causing errors with Salt's own argument parsing.

                    All CLI options for pruning worktrees as of Git  2.5.0
                    are  already  supported  by  this  function as of Salt
                    2015.8.0, so using this argument is unnecessary unless
                    new CLI arguments are added to git-worktree(1) and are
                    not yet supported in Salt.

          user   User under which to run the git command. By default,  the
                 command  is  run  by  the  user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          ignore_retcode
                 False  If  True, do not log an error to the minion log if
                 the git command returns a nonzero exit status.

                 New in version 2015.8.0.

          CLI Examples:

             salt myminion git.worktree_prune /path/to/repo
             salt myminion git.worktree_prune /path/to/repo dry_run=True
             salt myminion git.worktree_prune /path/to/repo expire=1.day.ago

   salt.modules.git.worktree_rm(cwd, user=None)
          New in version 2015.8.0.

          Recursively removes the worktree located at cwd, returning  True
          if successful. This function will attempt to determine if cwd is
          actually a worktree by invoking  git.is_worktree.  If  the  path
          does  not correspond to a worktree, then an error will be raised
          and no action will be taken.

          WARNING:
             There is no undoing  this  action.  Be  VERY  careful  before
             running this function.

          cwd    Path to the worktree to be removed

          user   Used for path expansion when cwd is not an absolute path.
                 By default, when cwd is not absolute, the  path  will  be
                 assumed  to be relative to the home directory of the user
                 under which the minion is running.  Setting  this  option
                 will  change the home directory from which path expansion
                 is performed.

          CLI Examples:

             salt myminion git.worktree_rm /path/to/worktree

   salt.modules.github module
   Module for interacting with the GitHub v3 API.

   New in version 2016.3.0.

   depends
          PyGithub python module

   Configuration
   Configure this module by specifying the name of a configuration profile
   in  the minion config, minion pillar, or master config. The module will
   use the 'github' key by default, if defined.

   For example:

      github:
        token: abc1234
        org_name: my_organization

        # optional: some functions require a repo_name, which
        # can be set in the config file, or passed in at the CLI.
        repo_name: my_repo

   salt.modules.github.add_repo(name,   description=None,   homepage=None,
   private=None,   has_issues=None,   has_wiki=None,   has_downloads=None,
   auto_init=None,     gitignore_template=None,     license_template=None,
   profile='github')
          Create a new github repository.

          name   The name of the team to be created.

          description
                 The description of the repository.

          homepage
                 The URL with more information about the repository.

          private
                 The  visiblity  of  the  repository.  Note  that  private
                 repositories require a paid GitHub account.

          has_issues
                 Whether to enable issues for this repository.

          has_wiki
                 Whether to enable the wiki for this repository.

          has_downloads
                 Whether to enable downloads for this repository.

          auto_init
                 Whether to create an initial commit with an empty README.

          gitignore_template
                 The desired language or platform for  a  .gitignore,  e.g
                 "Haskell".

          license_template
                 The  desired  LICENSE  template  to  apply,  e.g "mit" or
                 "mozilla".

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_repo 'repo_name'

          New in version 2016.11.0.

   salt.modules.github.add_team(name,  description=None,  repo_names=None,
   privacy=None, permission=None, profile='github')
          Create a new Github team within an organization.

          name   The name of the team to be created.

          description
                 The description of the team.

          repo_names
                 The names of repositories to add the team to.

          privacy
                 The level of privacy for the team,  can  be  'secret'  or
                 'closed'.

          permission
                 The  default permission for new repositories added to the
                 team, can be 'pull', 'push' or 'admin'.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_team 'team_name'

          New in version 2016.11.0.

   salt.modules.github.add_team_member(name, team_name, profile='github')
          Adds a team member to a team with team_name.

          name   The name of the team member to add.

          team_name
                 The name of the team of which to add the user.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_team_member 'user_name' 'team_name'

          New in version 2016.11.0.

   salt.modules.github.add_team_repo(repo_name,                 team_name,
   profile='github')
          Adds a repository to a team with team_name.

          repo_name
                 The name of the repository to add.

          team_name
                 The name of the team of which to add the repository.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_team_repo 'my_repo' 'team_name'

          New in version 2016.11.0.

   salt.modules.github.add_user(name, profile='github')
          Add a GitHub user.

          name   The user for which to obtain information.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_user github-handle

   salt.modules.github.edit_repo(name,   description=None,  homepage=None,
   private=None,   has_issues=None,   has_wiki=None,   has_downloads=None,
   profile='github')
          Updates an existing Github repository.

          name   The name of the team to be created.

          description
                 The description of the repository.

          homepage
                 The URL with more information about the repository.

          private
                 The  visiblity  of  the  repository.  Note  that  private
                 repositories require a paid GitHub account.

          has_issues
                 Whether to enable issues for this repository.

          has_wiki
                 Whether to enable the wiki for this repository.

          has_downloads
                 Whether to enable downloads for this repository.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.add_repo 'repo_name'

          New in version 2016.11.0.

   salt.modules.github.edit_team(name,   description=None,   privacy=None,
   permission=None, profile='github')
          Updates an existing Github team.

          name   The name of the team to be edited.

          description
                 The description of the team.

          privacy
                 The level of privacy for the team,  can  be  'secret'  or
                 'closed'.

          permission
                 The  default permission for new repositories added to the
                 team, can be 'pull', 'push' or 'admin'.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.edit_team 'team_name' description='Team description'

          New in version 2016.11.0.

   salt.modules.github.get_issue(issue_number,             repo_name=None,
   profile='github', output='min')
          Return information about a single issue in a named repository.

          New in version 2016.11.0.

          issue_number
                 The number of the issue to retrieve.

          repo_name
                 The name of the repository from which to get  the  issue.
                 This  argument is required, either passed via the CLI, or
                 defined in the configured profile. A repo_name passed  as
                 a CLI argument will override the repo_name defined in the
                 configured profile, if provided.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          output The  amount  of  data returned by each issue. Defaults to
                 min. Change to full to see all issue output.

          CLI Example:

             salt myminion github.get_issue 514
             salt myminion github.get_issue 514 repo_name=salt

   salt.modules.github.get_issue_comments(issue_number,    repo_name=None,
   profile='github', since=None, output='min')
          Return  information  about  the  comments for a given issue in a
          named repository.

          New in version 2016.11.0.

          issue_number
                 The number of the issue for which to retrieve comments.

          repo_name
                 The name of the repository to which  the  issue  belongs.
                 This  argument is required, either passed via the CLI, or
                 defined in the configured profile. A repo_name passed  as
                 a CLI argument will override the repo_name defined in the
                 configured profile, if provided.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          since  Only comments updated at or after this time are returned.
                 This   is   a   timestamp    in    ISO    8601    format:
                 YYYY-MM-DDTHH:MM:SSZ.

          output The  amount  of  data returned by each issue. Defaults to
                 min. Change to full to see all issue output.

          CLI Example:

             salt myminion github.get_issue_comments 514
             salt myminion github.get_issue 514 repo_name=salt

   salt.modules.github.get_issues(repo_name=None,        profile='github',
   milestone=None,      state='open',     assignee=None,     creator=None,
   mentioned=None,    labels=None,    sort='created',    direction='desc',
   since=None, output='min', per_page=None)
          Returns  information for all issues in a given repository, based
          on the search options.

          New in version 2016.11.0.

          repo_name
                 The name of the repository for which to list issues. This
                 argument  is  required,  either  passed  via  the CLI, or
                 defined in the configured profile. A repo_name passed  as
                 a CLI argument will override the repo_name defined in the
                 configured profile, if provided.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          milestone
                 The number of a GitHub milestone, or a string of either *
                 or none.

                 If a number is passed, it should refer to a milestone  by
                 its  number  field. Use the github.get_milestone function
                 to obtain a milestone's number.

                 If the string * is passed, issues with any milestone  are
                 accepted.  If  the  string none is passed, issues without
                 milestones are returned.

          state  Indicates the state of  the  issues  to  return.  Can  be
                 either open, closed, or all. Default is open.

          assignee
                 Can be the name of a user. Pass in none (as a string) for
                 issues with no assigned user or * for issues assigned  to
                 any user.

          creator
                 The user that created the issue.

          mentioned
                 A user that's mentioned in the issue.

          labels A  string  of  comma  separated label names. For example,
                 bug,ui,@high.

          sort   What to sort results by. Can be either created,  updated,
                 or comments. Default is created.

          direction
                 The  direction  of  the  sort. Can be either asc or desc.
                 Default is desc.

          since  Only issues updated at or after this time  are  returned.
                 This    is    a    timestamp    in   ISO   8601   format:
                 YYYY-MM-DDTHH:MM:SSZ.

          output The amount of data returned by each  issue.  Defaults  to
                 min. Change to full to see all issue output.

          per_page
                 GitHub  paginates data in their API calls. Use this value
                 to increase or decrease the  number  of  issues  gathered
                 from  GitHub,  per  page. If not set, GitHub defaults are
                 used. Maximum is 100.

          CLI Example:

             salt myminion github.get_issues my-github-repo

   salt.modules.github.get_milestone(number=None,               name=None,
   repo_name=None, profile='github', output='min')
          Return   information   about  a  single  milestone  in  a  named
          repository.

          New in version 2016.11.0.

          number The number of the milestone  to  retrieve.  If  provided,
                 this option will be favored over name.

          name   The name of the milestone to retrieve.

          repo_name
                 The name of the repository for which to list issues. This
                 argument is required,  either  passed  via  the  CLI,  or
                 defined  in the configured profile. A repo_name passed as
                 a CLI argument will override the repo_name defined in the
                 configured profile, if provided.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          output The amount of data returned by each  issue.  Defaults  to
                 min. Change to full to see all issue output.

          CLI Example:

             salt myminion github.get_milestone 72
             salt myminion github.get_milestone name=my_milestone

   salt.modules.github.get_milestones(repo_name=None,    profile='github',
   state='open',     sort='due_on',     direction='asc',     output='min',
   per_page=None)
          Return information about milestones for a given repository.

          New in version 2016.11.0.

          repo_name
                 The name of the repository for which to list issues. This
                 argument is required,  either  passed  via  the  CLI,  or
                 defined  in the configured profile. A repo_name passed as
                 a CLI argument will override the repo_name defined in the
                 configured profile, if provided.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          state  The state of the milestone. Either open, closed, or  all.
                 Default is open.

          sort   What  to  sort results by. Either due_on or completeness.
                 Default is due_on.

          direction
                 The direction of the sort. Either asc or desc. Default is
                 asc.

          output The  amount  of  data returned by each issue. Defaults to
                 min. Change to full to see all issue output.

          per_page
                 GitHub paginates data in their API calls. Use this  value
                 to  increase  or  decrease  the number of issues gathered
                 from GitHub, per page. If not set,  GitHub  defaults  are
                 used.

          CLI Example:

             salt myminion github.get_milestones

   salt.modules.github.get_repo_info(repo_name, profile='github')
          Return information for a given repo.

          New in version 2016.11.0.

          repo_name
                 The name of the repository.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.get_repo_info salt
             salt myminion github.get_repo_info salt profile='my-github-profile'

   salt.modules.github.get_team(name, profile='github')
          Returns the team details if a team with the given  name  exists,
          or None otherwise.

          name   The team name for which to obtain information.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.get_team 'team_name'

   salt.modules.github.get_user(name,                    profile='github',
   user_details=False)
          Get a GitHub user by name.

          name   The user for which to obtain information.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          user_details
                 Prints user information details. Defaults  to  False.  If
                 the  user is already in the organization and user_details
                 is set to False, the get_user function returns  True.  If
                 the user is not already present in the organization, user
                 details will be printed by default.

          CLI Example:

             salt myminion github.get_user github-handle
             salt myminion github.get_user github-handle user_details=true

   salt.modules.github.is_team_member(name, team_name, profile='github')
          Returns True if the github user is in the team  with  team_name,
          or False otherwise.

          name   The name of the user whose membership to check.

          team_name
                 The name of the team to check membership in.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.is_team_member 'user_name' 'team_name'

          New in version 2016.11.0.

   salt.modules.github.list_members_without_mfa(profile='github',
   ignore_cache=False)
          List all members (in lower case) without MFA turned on.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          ignore_cache
                 Bypasses the use of cached team repos.

          CLI Example:

             salt myminion github.list_members_without_mfa

          New in version 2016.11.0.

   salt.modules.github.list_private_repos(profile='github')
          List private repositories  within  the  organization.  Dependent
          upon the access rights of the profile token.

          New in version 2016.11.0.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.list_private_repos
             salt myminion github.list_private_repos profile='my-github-profile'

   salt.modules.github.list_public_repos(profile='github')
          List public repositories within the organization.

          New in version 2016.11.0.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.list_public_repos
             salt myminion github.list_public_repos profile='my-github-profile'

   salt.modules.github.list_repos(profile='github')
          List  all  repositories within the organization. Includes public
          and private repositories within the organization Dependent  upon
          the access rights of the profile token.

          New in version 2016.11.0.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.list_repos
             salt myminion github.list_repos profile='my-github-profile'

   salt.modules.github.list_team_members(team_name,      profile='github',
   ignore_cache=False)
          Gets the names of team members in lower case.

          team_name
                 The name of the team from which to list members.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          ignore_cache
                 Bypasses the use of cached team members.

          CLI Example:

             salt myminion github.list_team_members 'team_name'

          New in version 2016.11.0.

   salt.modules.github.list_team_repos(team_name,        profile='github',
   ignore_cache=False)
          Gets the names of team repos in lower case.

          team_name
                 The name of the team from which to list repos.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          ignore_cache
                 Bypasses the use of cached team repos.

          CLI Example:

             salt myminion github.list_team_repos 'team_name'

          New in version 2016.11.0.

   salt.modules.github.list_teams(profile='github', ignore_cache=False)
          Lists all teams with the organization.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          ignore_cache
                 Bypasses the use of cached teams.

          CLI Example:

             salt myminion github.list_teams

          New in version 2016.11.0.

   salt.modules.github.list_users(profile='github', ignore_cache=False)
          List all users within the organization.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          ignore_cache
                 Bypasses the use of cached users.

                 New in version 2016.11.0.

          CLI Example:

             salt myminion github.list_users
             salt myminion github.list_users profile='my-github-profile'

   salt.modules.github.remove_repo(name, profile='github')
          Remove a Github repository.

          name   The name of the repository to be removed.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.remove_repo 'my-repo'

          New in version 2016.11.0.

   salt.modules.github.remove_team(name, profile='github')
          Remove a github team.

          name   The name of the team to be removed.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.remove_team 'team_name'

          New in version 2016.11.0.

   salt.modules.github.remove_team_member(name,                 team_name,
   profile='github')
          Removes a team member from a team with team_name.

          name   The name of the team member to remove.

          team_name
                 The name of the team from which to remove the user.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.remove_team_member 'user_name' 'team_name'

          New in version 2016.11.0.

   salt.modules.github.remove_team_repo(repo_name,              team_name,
   profile='github')
          Removes a repository from a team with team_name.

          repo_name
                 The name of the repository to remove.

          team_name
                 The name of the team of which to remove the repository.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.remove_team_repo 'my_repo' 'team_name'

          New in version 2016.11.0.

   salt.modules.github.remove_user(name, profile='github')
          Remove a Github user by name.

          name   The user for which to obtain information.

          profile
                 The name of the profile configuration to use. Defaults to
                 github.

          CLI Example:

             salt myminion github.remove_user github-handle

   salt.modules.glance
   Module for handling openstack glance calls.

   optdepends

          * glanceclient Python adapter

   configuration
          This  module  is  not  usable  until the following are specified
          either in a pillar or in the minion's config file:

             keystone.user: admin
             keystone.password: verybadpass
             keystone.tenant: admin
             keystone.insecure: False   #(optional)
             keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'

          If configuration for multiple openstack  accounts  is  required,
          they  can  be  set  up  as different configuration profiles: For
          example:

             openstack1:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'

             openstack2:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.2:5000/v2.0/'

          With this configuration in place, any of  the  glance  functions
          can  make  use  of  a  configuration  profile  by  declaring  it
          explicitly.  For example:

             salt '*' glance.image_list profile=openstack1

   salt.modules.glance.image_create(name,   location=None,   profile=None,
   visibility=None,       container_format='bare',      disk_format='raw',
   protected=None, copy_from=None, is_public=None)
          Create an image (glance image-create)

          CLI Example, old format:

             salt '*' glance.image_create name=f16-jeos is_public=true \
                      disk_format=qcow2 container_format=ovf \
                      copy_from=http://berrange.fedorapeople.org/                    images/2012-02-29/f16-x86_64-openstack-sda.qcow2

          CLI Example, new format resembling Glance API v2:

             salt '*' glance.image_create name=f16-jeos visibility=public \
                      disk_format=qcow2 container_format=ovf \
                      copy_from=http://berrange.fedorapeople.org/                    images/2012-02-29/f16-x86_64-openstack-sda.qcow2

          The parameter  'visibility'  defaults  to  'public'  if  neither
          'visibility' nor 'is_public' is specified.

   salt.modules.glance.image_delete(id=None, name=None, profile=None)
          Delete an image (glance image-delete)

          CLI Examples:

             salt '*' glance.image_delete c2eb2eb0-53e1-4a80-b990-8ec887eae7df
             salt '*' glance.image_delete id=c2eb2eb0-53e1-4a80-b990-8ec887eae7df
             salt '*' glance.image_delete name=f16-jeos

   salt.modules.glance.image_list(id=None, profile=None, name=None)
          Return a list of available images (glance image-list)

          CLI Example:

             salt '*' glance.image_list

   salt.modules.glance.image_schema(profile=None)
          Returns   names   and   descriptions  of  the  schema  "image"'s
          properties for this profile's instance of glance

          CLI Example:

             salt '*' glance.image_schema

   salt.modules.glance.image_show(id=None, name=None, profile=None)
          Return details about a specific image (glance image-show)

          CLI Example:

             salt '*' glance.image_show

   salt.modules.glance.image_update(id=None,   name=None,    profile=None,
   **kwargs)
          Update  properties of given image.  Known to work for: - min_ram
          (in MB) - protected (bool) - visibility ('public' or 'private')

          CLI Example:

             salt '*' glance.image_update id=c2eb2eb0-53e1-4a80-b990-8ec887eae7df
             salt '*' glance.image_update name=f16-jeos

   salt.modules.glance.schema_get(name, profile=None)

          Known valid names of schemas are:

                 * image

                 * images

                 * member

                 * members

          CLI Example:

             salt '*' glance.schema_get name=f16-jeos

   salt.modules.glusterfs
   Manage a glusterfs pool

   salt.modules.glusterfs.add_volume_bricks(name, bricks)
          Add brick(s) to an existing volume

          name   Volume name

          bricks List of bricks to add to the volume

   salt.modules.glusterfs.create(*args, **kwargs)
          Deprecated version of more consistently named create_volume

   salt.modules.glusterfs.create_volume(name,    bricks,     stripe=False,
   replica=False,     device_vg=False,    transport='tcp',    start=False,
   force=False)
          Create a glusterfs volume.

          name   Name of the gluster volume

          bricks Bricks to create  volume  from,  in  <peer>:<brick  path>
                 format.  For          multiple  bricks  use  list format:
                 '["<peer1>:<brick1>",         "<peer2>:<brick2>"]'

          stripe Stripe count, the number of bricks should be  a  multiple
                 of  the  stripe          count  for a distributed striped
                 volume

          replica
                 Replica count, the number of bricks should be a  multiple
                 of the         replica count for a distributed replicated
                 volume

          device_vg
                 If  true,  specifies  volume  should  use  block  backend
                 instead  of  regular          posix backend. Block device
                 backend volume does not support multiple         bricks

          transport
                 Transport protocol  to  use,  can  be  'tcp',  'rdma'  or
                 'tcp,rdma'

          start  Start the volume after creation

          force  Force  volume  creation,  this  works even if creating in
                 root FS

          CLI Example:

             salt host1 glusterfs.create newvolume host1:/brick

             salt gluster1 glusterfs.create vol2 '["gluster1:/export/vol2/brick",         "gluster2:/export/vol2/brick"]' replica=2 start=True

   salt.modules.glusterfs.delete(*args, **kwargs)
          Deprecated version of more consistently named delete_volume

   salt.modules.glusterfs.delete_volume(target, stop=True)
          Deletes a gluster volume

          target Volume to delete

          stop   Stop volume before delete  if  it  is  started,  True  by
                 default

   salt.modules.glusterfs.info(name=None)
          New in version 2015.8.4.

          Return gluster volume info.

          name   Optional name to retrieve only information of one volume

          CLI Example:

             salt '*' glusterfs.info

   salt.modules.glusterfs.list_peers()
          Deprecated  version  of  peer_status(), which returns the peered
          hostnames and some additional information.

          CLI Example:

             salt '*' glusterfs.list_peers

   salt.modules.glusterfs.list_volumes()
          List configured volumes

          CLI Example:

             salt '*' glusterfs.list_volumes

   salt.modules.glusterfs.peer(name)
          Add another node into the peer list.

          name   The remote host to probe.

          CLI Example:

             salt 'one.gluster.*' glusterfs.peer two

          GLUSTER direct CLI example (to show  what  salt  is  sending  to
          gluster):
             $ gluster peer probe ftp2

          GLUSTER  CLI  3.4.4  return  example  (so  we  know  what we are
          parsing):
                 #if the "peer" is the local host: peer probe: success: on
                 localhost not needed

                 #if the peer was just added: peer probe: success

                 #if the peer was already part of the cluster: peer probe:
                 success: host ftp2 port 24007 already in peer list

   salt.modules.glusterfs.peer_status()
          Return peer status information

          The return value is a dictionary with peer  UUIDs  as  keys  and
          dicts of peer information as values. Hostnames are listed in one
          list. GlusterFS separates one of  the  hostnames  but  the  only
          reason  for  this  seems to be which hostname happens to be used
          firts in peering.

          CLI Example:

             salt '*' glusterfs.peer_status

          GLUSTER direct CLI example (to show  what  salt  is  sending  to
          gluster):
             $ gluster peer status

          GLUSTER  CLI  3.4.4  return  example  (so  we  know  what we are
          parsing):
             Number of Peers: 2

             Hostname:        ftp2        Port:        24007         Uuid:
             cbcb256b-e66e-4ec7-a718-21082d396c24  State:  Peer in Cluster
             (Connected)

             Hostname:  ftp3  Uuid:   5ea10457-6cb2-427b-a770-7897509625e9
             State: Peer in Cluster (Connected)

   salt.modules.glusterfs.start_volume(name, force=False)
          Start a gluster volume.

          name   Volume name

          force  Force the volume start even if the volume is started

          CLI Example:

             salt '*' glusterfs.start mycluster

   salt.modules.glusterfs.status(name)
          Check the status of a gluster volume.

          name   Volume name

          CLI Example:

             salt '*' glusterfs.status myvolume

   salt.modules.glusterfs.stop_volume(name, force=False)
          Stop a gluster volume.

          name   Volume name

          force  Force stop the volume

          CLI Example:

             salt '*' glusterfs.stop_volume mycluster

   salt.modules.gnomedesktop
   GNOME implementations

   salt.modules.gnomedesktop.get(schema=None,     key=None,     user=None,
   **kwargs)
          Get key in a particular GNOME schema

          CLI Example:

             salt '*' gnome.get user=<username> schema=org.gnome.desktop.screensaver key=idle-activation-enabled

   salt.modules.gnomedesktop.getClockFormat(**kwargs)
          Return the current clock format, either 12h or 24h format.

          CLI Example:

             salt '*' gnome.getClockFormat user=<username>

   salt.modules.gnomedesktop.getClockShowDate(**kwargs)
          Return the current setting, if the date is shown in the clock

          CLI Example:

             salt '*' gnome.getClockShowDate user=<username>

   salt.modules.gnomedesktop.getIdleActivation(**kwargs)
          Get whether the idle activation is enabled

          CLI Example:

             salt '*' gnome.getIdleActivation user=<username>

   salt.modules.gnomedesktop.getIdleDelay(**kwargs)
          Return the current idle delay setting in seconds

          CLI Example:

             salt '*' gnome.getIdleDelay user=<username>

   salt.modules.gnomedesktop.ping(**kwargs)
          A test to ensure the GNOME module is loaded

          CLI Example:

             salt '*' gnome.ping user=<username>

   salt.modules.gnomedesktop.setClockFormat(clockFormat, **kwargs)
          Set the clock format, either 12h or 24h format.

          CLI Example:

             salt '*' gnome.setClockFormat <12h|24h> user=<username>

   salt.modules.gnomedesktop.setClockShowDate(kvalue, **kwargs)
          Set whether the date is visible in the clock

          CLI Example:

             salt '*' gnome.setClockShowDate <True|False> user=<username>

   salt.modules.gnomedesktop.setIdleActivation(kvalue, **kwargs)
          Set whether the idle activation is enabled

          CLI Example:

             salt '*' gnome.setIdleActivation <True|False> user=<username>

   salt.modules.gnomedesktop.setIdleDelay(delaySeconds, **kwargs)
          Set the current idle delay setting in seconds

          CLI Example:

             salt '*' gnome.setIdleDelay <seconds> user=<username>

   salt.modules.gnomedesktop.set(schema=None,     key=None,     user=None,
   value=None, **kwargs)
          Set key in a particular GNOME schema

          CLI Example:

             salt '*' gnome.set user=<username> schema=org.gnome.desktop.screensaver key=idle-activation-enabled value=False

   salt.modules.gpg
   Manage  a  GPG  keychains,  add  keys,  create keys, retrieve keys from
   keyservers.  Sign, encrypt and sign plus encrypt text and files.

   New in version 2015.5.0.

   NOTE:
      The  python-gnupg  library  and  gpg  binary  are  required  to   be
      installed.

   salt.modules.gpg.create_key(*args, **kwargs)
          Create a key in the GPG keychain

          NOTE:
             GPG  key generation requires a lot of entropy and randomness.
             Difficult to do over a  remote  connection,  consider  having
             another  process available which is generating randomness for
             the machine.  Also especially difficult on virtual  machines,
             consider the rng-tools package.

             The create_key process takes awhile so increasing the timeout
             may be necessary, e.g. -t 15.

          key_type
                 The type of the primary  key  to  generate.  It  must  be
                 capable of signing.  'RSA' or 'DSA'.

          key_length
                 The length of the primary key in bits.

          name_real
                 The  real  name of the user identity which is represented
                 by the key.

          name_comment
                 A comment to attach to the user id.

          name_email
                 An email address for the user.

          subkey_type
                 The type of the secondary key to generate.

          subkey_length
                 The length of the secondary key in bits.

          expire_date
                 The expiration date for the  primary  and  any  secondary
                 key.    You   can  specify  an  ISO  date,  A  number  of
                 days/weeks/months/years, an  epoch  value,  or  0  for  a
                 non-expiring key.

          use_passphrase
                 Whether  to  use  a  passphrase  with  the  signing  key.
                 Passphrase is received from Pillar.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt -t 15 '*' gpg.create_key

   salt.modules.gpg.decrypt(user=None,      text=None,      filename=None,
   output=None, use_passphrase=False, gnupghome=None, bare=False)
          Decrypt a message or file

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          text   The encrypted text to decrypt.

          filename
                 The encrypted filename to decrypt.

          output The filename where the decrypted data  will  be  written,
                 default is standard out.

          use_passphrase
                 Whether  to  use  a  passphrase  with  the  signing  key.
                 Passphrase is received from Pillar.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          bare   If True, return the (armored) decrypted block as a string
                 without the standard comment/res dict.

          CLI Example:

             salt '*' gpg.decrypt filename='/path/to/important.file.gpg'

             salt '*' gpg.decrypt filename='/path/to/important.file.gpg' use_passphrase=True

   salt.modules.gpg.delete_key(keyid=None,               fingerprint=None,
   delete_secret=False, user=None, gnupghome=None)
          Get a key from the GPG keychain

          keyid  The keyid of the key to be deleted.

          fingerprint
                 The fingerprint of the key to be deleted.

          delete_secret
                 Whether  to  delete  a  corresponding secret key prior to
                 deleting the public key.  Secret  keys  must  be  deleted
                 before deleting any corresponding public keys.

          user   Which user's keychain to access, defaults to user Salt is
                 running as.  Passing the user as salt will set the  GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify  the location where GPG keyring and related files
                 are stored.

          CLI Example:

             salt '*' gpg.delete_key keyid=3FAD9F1E

             salt '*' gpg.delete_key fingerprint=53C96788253E58416D20BCD352952C84C3252192

             salt '*' gpg.delete_key keyid=3FAD9F1E user=username

             salt '*' gpg.delete_key keyid=3FAD9F1E user=username delete_secret=True

   salt.modules.gpg.encrypt(user=None,     recipients=None,     text=None,
   filename=None,     output=None,     sign=None,    use_passphrase=False,
   gnupghome=None, bare=False)
          Encrypt a message or file

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          recipients
                 The fingerprints for those recipient  whom  the  data  is
                 being encrypted for.

          text   The text to encrypt.

          filename
                 The filename to encrypt.

          output The  filename  where  the  signed  file  will be written,
                 default is standard out.

          sign   Whether to sign, in addition to encrypt, the  data.  True
                 to  use default key or fingerprint to specify a different
                 key to sign with.

          use_passphrase
                 Whether  to  use  a  passphrase  with  the  signing  key.
                 Passphrase is received from Pillar.

          gnupghome
                 Specify  the location where GPG keyring and related files
                 are stored.

          bare   If True, return the (armored) encrypted block as a string
                 without the standard comment/res dict.

          CLI Example:

             salt '*' gpg.encrypt text='Hello there.  How are you?'

             salt '*' gpg.encrypt filename='/path/to/important.file'

             salt '*' gpg.encrypt filename='/path/to/important.file' use_passphrase=True

   salt.modules.gpg.export_key(keyids=None,    secret=False,    user=None,
   gnupghome=None)
          Export a key from the GPG keychain

          keyids The key ID(s) of  the  key(s)  to  be  exported.  Can  be
                 specified as a comma separated string or a list. Anything
                 which GnuPG itself  accepts  to  identify  a  key  -  for
                 example, the key ID or the fingerprint could be used.

          secret Export   the   secret   key   identified  by  the  keyids
                 information passed.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.export_key keyids=3FAD9F1E

             salt '*' gpg.export_key keyids=3FAD9F1E secret=True

             salt '*' gpg.export_key keyids="['3FAD9F1E','3FBD8F1E']" user=username

   salt.modules.gpg.get_key(keyid=None,    fingerprint=None,    user=None,
   gnupghome=None)
          Get a key from the GPG keychain

          keyid  The key ID (short or long) of the key to be retrieved.

          fingerprint
                 The fingerprint of the key to be retrieved.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.get_key keyid=3FAD9F1E

             salt '*' gpg.get_key fingerprint=53C96788253E58416D20BCD352952C84C3252192

             salt '*' gpg.get_key keyid=3FAD9F1E user=username

   salt.modules.gpg.get_secret_key(keyid=None,           fingerprint=None,
   user=None, gnupghome=None)
          Get a key from the GPG keychain

          keyid  The key ID (short or long) of the key to be retrieved.

          fingerprint
                 The fingerprint of the key to be retrieved.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.get_secret_key keyid=3FAD9F1E

             salt '*' gpg.get_secret_key fingerprint=53C96788253E58416D20BCD352952C84C3252192

             salt '*' gpg.get_secret_key keyid=3FAD9F1E user=username

   salt.modules.gpg.import_key(*args, **kwargs)
          Import a key from text or file

          text   The text containing to import.

          filename
                 The filename containing the key to import.

          user   Which user's keychain to access, defaults to user Salt is
                 running as.  Passing the user as salt will set the  GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify  the location where GPG keyring and related files
                 are stored.

          CLI Example:

             salt '*' gpg.import_key text='-----BEGIN PGP PUBLIC KEY BLOCK-----\n ... -----END PGP PUBLIC KEY BLOCK-----'
             salt '*' gpg.import_key filename='/path/to/public-key-file'

   salt.modules.gpg.list_keys(user=None, gnupghome=None)
          List keys in GPG keychain

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.list_keys

   salt.modules.gpg.list_secret_keys(user=None, gnupghome=None)
          List secret keys in GPG keychain

          user   Which user's keychain to access, defaults to user Salt is
                 running as.  Passing the user as salt will set the  GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify  the location where GPG keyring and related files
                 are stored.

          CLI Example:

             salt '*' gpg.list_secret_keys

   salt.modules.gpg.receive_keys(*args, **kwargs)
          Receive key(s) from keyserver and add them to keychain

          keyserver
                 Keyserver to use for searching for GPG keys, defaults  to
                 pgp.mit.edu

          keys   The  keyID(s)  to  retrieve  from  the keyserver.  Can be
                 specified as a comma separated string or a list.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.receive_keys keys='3FAD9F1E'

             salt '*' gpg.receive_keys keys="['3FAD9F1E','3FBD9F2E']"

             salt '*' gpg.receive_keys keys=3FAD9F1E user=username

   salt.modules.gpg.search_keys(text, keyserver=None, user=None)
          Search keys from keyserver

          text   Text  to  search  the  keyserver for, e.g. email address,
                 keyID or fingerprint.

          keyserver
                 Keyserver to use for searching for GPG keys, defaults  to
                 pgp.mit.edu.

          user   Which user's keychain to access, defaults to user Salt is
                 running as.  Passing the user as salt will set the  GnuPG
                 home directory to the /etc/salt/gpgkeys.

          CLI Example:

             salt '*' gpg.search_keys [email protected]

             salt '*' gpg.search_keys [email protected] keyserver=keyserver.ubuntu.com

             salt '*' gpg.search_keys [email protected] keyserver=keyserver.ubuntu.com user=username

   salt.modules.gpg.sign(user=None,  keyid=None, text=None, filename=None,
   output=None, use_passphrase=False, gnupghome=None)
          Sign message or file

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          keyid  The keyid of the key to set the trust level for, defaults
                 to first key in the secret keyring.

          text   The text to sign.

          filename
                 The filename to sign.

          output The  filename  where  the  signed  file  will be written,
                 default is standard out.

          use_passphrase
                 Whether  to  use  a  passphrase  with  the  signing  key.
                 Passphrase is received from Pillar.

          gnupghome
                 Specify  the location where GPG keyring and related files
                 are stored.

          CLI Example:

             salt '*' gpg.sign text='Hello there.  How are you?'

             salt '*' gpg.sign filename='/path/to/important.file'

             salt '*' gpg.sign filename='/path/to/important.file' use_passphrase=True

   salt.modules.gpg.trust_key(keyid=None,                fingerprint=None,
   trust_level=None, user=None)
          Set the trust level for a key in GPG keychain

          keyid  The keyid of the key to set the trust level for.

          fingerprint
                 The fingerprint of the key to set the trust level for.

          trust_level
                 The trust level to set for the specified key, must be one
                 of  the   following:   expired,   unknown,   not_trusted,
                 marginally, fully, ultimately

          user   Which user's keychain to access, defaults to user Salt is
                 running as.  Passing the user as salt will set the  GnuPG
                 home directory to the /etc/salt/gpgkeys.

          CLI Example:

             salt '*' gpg.trust_key keyid='3FAD9F1E' trust_level='marginally'
             salt '*' gpg.trust_key fingerprint='53C96788253E58416D20BCD352952C84C3252192' trust_level='not_trusted'
             salt '*' gpg.trust_key keys=3FAD9F1E trust_level='ultimately' user='username'

   salt.modules.gpg.verify(text=None,       user=None,      filename=None,
   gnupghome=None)
          Verify a message or file

          text   The text to verify.

          filename
                 The filename to verify.

          user   Which user's keychain to access, defaults to user Salt is
                 running  as.  Passing the user as salt will set the GnuPG
                 home directory to the /etc/salt/gpgkeys.

          gnupghome
                 Specify the location where GPG keyring and related  files
                 are stored.

          CLI Example:

             salt '*' gpg.verify text='Hello there.  How are you?'

             salt '*' gpg.verify filename='/path/to/important.file'

             salt '*' gpg.verify filename='/path/to/important.file' use_passphrase=True

   salt.modules.grains
   Return/control aspects of the grains data

   salt.modules.grains.append(key, val, convert=False, delimiter=':')
          New in version 0.17.0.

          Append a value to a list in the grains config file. If the grain
          doesn't exist, the grain key is added and the value is  appended
          to the new grain as a list item.

          key    The grain key to be appended to

          val    The value to append to the grain key

          convert
                 If  convert  is  True,  convert  non-list contents into a
                 list.   If  convert  is  False  and  the  grain  contains
                 non-list contents, an error is given. Defaults to False.

          delimiter
                 The  key  can be a nested dict key. Use this parameter to
                 specify the delimiter you use, instead of the default  :.
                 You  can now append values to a list in nested dictionary
                 grains. If the list doesn't exist at this level, it  will
                 be created.

                 New in version 2014.7.6.

          CLI Example:

             salt '*' grains.append key val

   salt.modules.grains.delval(key, destructive=False)
          New in version 0.17.0.

          Delete a grain from the grains config file

          key    The grain key from which to delete the value.

          destructive
                 Delete the key, too. Defaults to False.

          CLI Example:

             salt '*' grains.delval key

   salt.modules.grains.fetch(key, default='', delimiter=':', ordered=True)
          Attempt  to  retrieve  the named value from grains, if the named
          value is not available return the passed  default.  The  default
          return is an empty string.

          The  value  can  also represent a value in a nested dict using a
          ":" delimiter for the dict. This means that if a dict in  grains
          looks like this:

             {'pkg': {'apache': 'httpd'}}

          To  retrieve the value associated with the apache key in the pkg
          dict this key can be passed:

             pkg:apache

          Parameters

                 * delimiter --

                   Specify an alternate delimiter to use when traversing a
                   nested dict

                   New in version 2014.7.0.

                 * ordered --

                   Outputs an ordered dict if applicable (default: True)

                   New in version 2016.11.0.

          CLI Example:

             salt '*' grains.get pkg:apache

   salt.modules.grains.filter_by(lookup_dict,           grain='os_family',
   merge=None, default='default', base=None)
          New in version 0.17.0.

          Look up the given grain in a given dictionary for the current OS
          and return the result

          Although this may occasionally be useful at the CLI, the primary
          intent of this function is for use in Jinja to make  short  work
          of creating lookup tables for OS-specific data. For example:

             {% set apache = salt['grains.filter_by']({
                 'Debian': {'pkg': 'apache2', 'srv': 'apache2'},
                 'RedHat': {'pkg': 'httpd', 'srv': 'httpd'},
             }, default='Debian') %}

             myapache:
               pkg.installed:
                 - name: {{ apache.pkg }}
               service.running:
                 - name: {{ apache.srv }}

          Values  in  the  lookup  table  may  be  overridden by values in
          Pillar. An example Pillar to  override  values  in  the  example
          above could be as follows:

             apache:
               lookup:
                 pkg: apache_13
                 srv: apache

          The  call  to  filter_by()  would  be  modified  as  follows  to
          reference those Pillar values:

             {% set apache = salt['grains.filter_by']({
                 ...
             }, merge=salt['pillar.get']('apache:lookup')) %}

          Parameters

                 * lookup_dict --

                   A dictionary, keyed by a grain, containing a  value  or
                   values  relevant  to  systems  matching that grain. For
                   example, a key could be the grain for  an  OS  and  the
                   value  could  the  name of a package on that particular
                   OS.

                   Changed in version 2016.11.0: The dictionary key  could
                   be  a  globbing  pattern.  The function will return the
                   corresponding  lookup_dict  value  where  grain   value
                   matches the pattern. For example:

                      # this will render 'got some salt' if Minion ID begins from 'salt'
                      salt '*' grains.filter_by '{salt*: got some salt, default: salt is not here}' id

                 * grain --

                   The  name of a grain to match with the current system's
                   grains. For example, the value of the "os_family" grain
                   for  the  current  system  could be used to pull values
                   from the lookup_dict dictionary.

                   Changed in version 2016.11.0: The grain value could  be
                   a  list. The function will return the lookup_dict value
                   for a first found item in the list matching one of  the
                   lookup_dict keys.

                 * merge  -- A dictionary to merge with the results of the
                   grain selection from lookup_dict. This allows Pillar to
                   override  the  values in the lookup_dict. This could be
                   useful,  for  example,  to  override  the  values   for
                   non-standard   package  names  such  as  when  using  a
                   different  Python  version  from  the  default   Python
                   version   provided  by  the  OS  (e.g.,  python26-mysql
                   instead of python-mysql).

                 * default --

                   default lookup_dict's key used if the  grain  does  not
                   exists   or   if  the  grain  value  has  no  match  on
                   lookup_dict.  If unspecified the value is "default".

                   New in version 2014.1.0.

                 * base --

                   A lookup_dict key to use for a  base  dictionary.   The
                   grain-selected lookup_dict is merged over this and then
                   finally the merge dictionary is  merged.   This  allows
                   common values for each case to be collected in the base
                   and overridden by the grain  selection  dictionary  and
                   the merge dictionary.  Default is unset.

                   New in version 2015.5.0.

          CLI Example:

             salt '*' grains.filter_by '{Debian: Debheads rule, RedHat: I love my hat}'
             # this one will render {D: {E: I, G: H}, J: K}
             salt '*' grains.filter_by '{A: B, C: {D: {E: F, G: H}}}' 'xxx' '{D: {E: I}, J: K}' 'C'
             # next one renders {A: {B: G}, D: J}
             salt '*' grains.filter_by '{default: {A: {B: C}, D: E}, F: {A: {B: G}}, H: {D: I}}' 'xxx' '{D: J}' 'F' 'default'
             # next same as above when default='H' instead of 'F' renders {A: {B: C}, D: J}

   salt.modules.grains.get(key, default='', delimiter=':', ordered=True)
          Attempt  to  retrieve  the named value from grains, if the named
          value is not available return the passed  default.  The  default
          return is an empty string.

          The  value  can  also represent a value in a nested dict using a
          ":" delimiter for the dict. This means that if a dict in  grains
          looks like this:

             {'pkg': {'apache': 'httpd'}}

          To  retrieve the value associated with the apache key in the pkg
          dict this key can be passed:

             pkg:apache

          Parameters

                 * delimiter --

                   Specify an alternate delimiter to use when traversing a
                   nested dict

                   New in version 2014.7.0.

                 * ordered --

                   Outputs an ordered dict if applicable (default: True)

                   New in version 2016.11.0.

          CLI Example:

             salt '*' grains.get pkg:apache

   salt.modules.grains.get_or_set_hash(name,                     length=8,
   chars='abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)')
          Perform a one-time generation of a hash  and  write  it  to  the
          local  grains.   If  that  grain has already been set return the
          value instead.

          This is  useful  for  generating  passwords  or  keys  that  are
          specific  to  a  single  minion  that  don't  need  to be stored
          somewhere centrally.

          State Example:

             some_mysql_user:
               mysql_user:
                 - present
                 - host: localhost
                 - password: {{ salt['grains.get_or_set_hash']('mysql:some_mysql_user') }}

          CLI Example:

             salt '*' grains.get_or_set_hash 'django:SECRET_KEY' 50

          WARNING:
             This  function  could  return  strings  which   may   contain
             characters  which  are  reserved  as  directives  by the YAML
             parser, such as strings beginning with  %.  To  avoid  issues
             when  using  the  output  of  this  function  in  an SLS file
             containing YAML+Jinja, surround the call with single quotes.

   salt.modules.grains.has_value(key)
          Determine whether a named value exists in the grains dictionary.

          Given a grains dictionary that contains the following structure:

             {'pkg': {'apache': 'httpd'}}

          One would determine if the apache key in the pkg dict exists by:

             pkg:apache

          CLI Example:

             salt '*' grains.has_value pkg:apache

   salt.modules.grains.item(*args, **kwargs)
          Return one or more grains

          CLI Example:

             salt '*' grains.item os
             salt '*' grains.item os osrelease oscodename

          Sanitized CLI Example:

             salt '*' grains.item host sanitize=True

   salt.modules.grains.items(sanitize=False)
          Return all of the minion's grains

          CLI Example:

             salt '*' grains.items

          Sanitized CLI Example:

             salt '*' grains.items sanitize=True

   salt.modules.grains.ls()
          Return a list of all available grains

          CLI Example:

             salt '*' grains.ls

   salt.modules.grains.remove(key, val, delimiter=':')
          New in version 0.17.0.

          Remove a value from a list in the grains config file

          key    The grain key to remove.

          val    The value to remove.

          delimiter
                 The key can be a nested dict key. Use this  parameter  to
                 specify  the delimiter you use, instead of the default :.
                 You can now append values to a list in nested  dictionary
                 grains.  If the list doesn't exist at this level, it will
                 be created.

                 New in version 2015.8.2.

          CLI Example:

             salt '*' grains.remove key val

   salt.modules.grains.set(key,  val='',  force=False,  destructive=False,
   delimiter=':')
          Set  a  key  to  an  arbitrary value. It is used like setval but
          works with nested keys.

          This function is conservative. It will only overwrite  an  entry
          if  its  value  and  the given one are not a list or a dict. The
          force parameter is used to allow overwriting in all cases.

          New in version 2015.8.0.

          Parameters

                 * force -- Force writing over existing entry if given  or
                   existing values are list or dict. Defaults to False.

                 * destructive  --  If an operation results in a key being
                   removed, delete the key, too. Defaults to False.

                 * delimiter -- Specify an alternate delimiter to use when
                   traversing a nested dict, the default being :

          CLI Example:

             salt '*' grains.set 'apps:myApp:port' 2209
             salt '*' grains.set 'apps:myApp' '{port: 2209}'

   salt.modules.grains.setval(key, val, destructive=False)
          Set a grains value in the grains config file

          key    The grain key to be set.

          val    The value to set the grain key to.

          destructive
                 If  an  operation  results in a key being removed, delete
                 the key, too.  Defaults to False.

          CLI Example:

             salt '*' grains.setval key val
             salt '*' grains.setval key "{'sub-key': 'val', 'sub-key2': 'val2'}"

   salt.modules.grains.setvals(grains, destructive=False)
          Set new grains values in the grains config file

          destructive
                 If an operation results in a key  being  removed,  delete
                 the key, too.  Defaults to False.

          CLI Example:

             salt '*' grains.setvals "{'key1': 'val1', 'key2': 'val2'}"

   salt.modules.groupadd
   Manage groups on Linux, OpenBSD and NetBSD

   IMPORTANT:
      If  you  feel that Salt should be using this module to manage groups
      on a minion, and it is using a different module (or gives  an  error
      similar to 'group.info' is not available), see here.

   salt.modules.groupadd.add(name, gid=None, system=False, root=None)
          Add the specified group

          CLI Example:

             salt '*' group.add foo 3456

   salt.modules.groupadd.adduser(name, username, root=None)
          Add a user in the group.

          CLI Example:

             salt '*' group.adduser foo bar

          Verifies  if  a  valid username 'bar' as a member of an existing
          group 'foo', if not then adds it.

   salt.modules.groupadd.chgid(name, gid, root=None)
          Change the gid for a named group

          CLI Example:

             salt '*' group.chgid foo 4376

   salt.modules.groupadd.delete(name, root=None)
          Remove the named group

          CLI Example:

             salt '*' group.delete foo

   salt.modules.groupadd.deluser(name, username, root=None)
          Remove a user from the group.

          CLI Example:

             salt '*' group.deluser foo bar

          Removes a member user 'bar' from a group 'foo'. If group is  not
          present then returns True.

   salt.modules.groupadd.getent(refresh=False)
          Return info on all groups

          CLI Example:

             salt '*' group.getent

   salt.modules.groupadd.info(name)
          Return information about a group

          CLI Example:

             salt '*' group.info foo

   salt.modules.groupadd.members(name, members_list, root=None)
          Replaces members of the group with a provided list.

          CLI Example:
             salt '*' group.members foo 'user1,user2,user3,...'

          Replaces a membership list for a local group 'foo'.
                 foo:x:1234:user1,user2,user3,...

   salt.modules.grub_legacy
   Support for GRUB Legacy

   salt.modules.grub_legacy.conf()
          Parse GRUB conf file

          CLI Example:

             salt '*' grub.conf

   salt.modules.grub_legacy.version()
          Return server version from grub --version

          CLI Example:

             salt '*' grub.version

   salt.modules.guestfs
   Interact with virtual machine images via libguestfs

   depends

          * libguestfs

   salt.modules.guestfs.mount(location, access='rw', root=None)
          Mount an image

          CLI Example:

             salt '*' guest.mount /srv/images/fedora.qcow

   salt.modules.hadoop
   Support for hadoop

   maintainer
          Yann Jouanin <[email protected]>

   maturity
          new

   depends

   platform
          linux

   salt.modules.hadoop.dfs(command=None, *args)
          Execute a command on DFS

          CLI Example:

             salt '*' hadoop.dfs ls /

   salt.modules.hadoop.dfs_absent(path)
          Check if a file or directory is absent on the distributed FS.

          CLI Example:

             salt '*' hadoop.dfs_absent /some_random_file

          Returns True if the file is absent

   salt.modules.hadoop.dfs_present(path)
          Check if a file or directory is present on the distributed FS.

          CLI Example:

             salt '*' hadoop.dfs_present /some_random_file

          Returns True if the file is present

   salt.modules.hadoop.namenode_format(force=None)
          Format a name node

             salt '*' hadoop.namenode_format force=True

   salt.modules.hadoop.version()
          Return version from hadoop version

          CLI Example:

             salt '*' hadoop.version

   salt.modules.haproxyconn
   Support for haproxy

   New in version 2014.7.0.

   salt.modules.haproxyconn.disable_server(name,                  backend,
   socket='/var/run/haproxy.sock')
          Disable server in haproxy.

          name   Server to disable

          backend
                 haproxy backend, or all backends if "*" is supplied

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.disable_server db1.example.com mysql

   salt.modules.haproxyconn.enable_server(name,                   backend,
   socket='/var/run/haproxy.sock')
          Enable Server in haproxy

          name   Server to enable

          backend
                 haproxy backend, or all backends if "*" is supplied

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.enable_server web1.example.com www

   salt.modules.haproxyconn.get_sessions(name,                    backend,
   socket='/var/run/haproxy.sock')
          New in version 2016.11.0.

          Get number of current sessions on server in backend (scur)

          name   Server name

          backend
                 haproxy backend

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.get_sessions web1.example.com www

   salt.modules.haproxyconn.get_weight(name,                      backend,
   socket='/var/run/haproxy.sock')
          Get server weight

          name   Server name

          backend
                 haproxy backend

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.get_weight web1.example.com www

   salt.modules.haproxyconn.list_servers(backend,
   socket='/var/run/haproxy.sock', objectify=False)
          List servers in haproxy backend.

          backend
                 haproxy backend

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.list_servers mysql

   salt.modules.haproxyconn.set_state(name,        backend,         state,
   socket='/var/run/haproxy.sock')
          Force  a  server's administrative state to a new state. This can
          be useful to disable load balancing  and/or  any  traffic  to  a
          server.  Setting  the state to "ready" puts the server in normal
          mode, and the command is the equivalent of the  "enable  server"
          command.  Setting  the  state to "maint" disables any traffic to
          the server as well as any health checks. This is the  equivalent
          of  the  "disable  server"  command. Setting the mode to "drain"
          only removes the server from load balancing but still allows  it
          to  be checked and to accept new persistent connections. Changes
          are propagated to tracking servers if any.

          name   Server name

          backend
                 haproxy backend

          state  A string of the state to set. Must be  'ready',  'drain',
                 or 'maint'

          CLI Example:

             salt '*' haproxy.set_state my_proxy_server my_backend ready

   salt.modules.haproxyconn.set_weight(name,       backend,      weight=0,
   socket='/var/run/haproxy.sock')
          Set server weight

          name   Server name

          backend
                 haproxy backend

          weight Server Weight

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.set_weight web1.example.com www 13

   salt.modules.haproxyconn.show_backends(socket='/var/run/haproxy.sock')
          Show HaProxy Backends

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.show_backends

   salt.modules.haproxyconn.show_frontends(socket='/var/run/haproxy.sock')
          Show HaProxy frontends

          socket haproxy stats socket

          CLI Example:

             salt '*' haproxy.show_frontends

   salt.modules.hashutil
   A collection of hashing and encoding functions

   salt.modules.hashutil.base64_b64decode(instr)
          Decode  a  base64-encoded  string  using  the  "modern"   Python
          interface

          New in version 2016.3.0.

          CLI Example:

             salt '*' hashutil.base64_b64decode 'Z2V0IHNhbHRlZA=='

   salt.modules.hashutil.base64_b64encode(instr)
          Encode a string as base64 using the "modern" Python interface.

          Among  other possible differences, the "modern" encoder does not
          include newline ('n') characters in the encoded output.

          New in version 2016.3.0.

          CLI Example:

             salt '*' hashutil.base64_b64encode 'get salted'

   salt.modules.hashutil.base64_decodefile(instr, outfile)
          Decode a base64-encoded string and write the result to a file

          New in version 2015.2.0.

          CLI Example:

             salt '*' hashutil.base64_decodefile instr='Z2V0IHNhbHRlZAo=' outfile='/path/to/binary_file'

   salt.modules.hashutil.base64_decodestring(instr)
          Decode  a  base64-encoded  string  using  the  "legacy"   Python
          interface

          New in version 2014.7.0.

          CLI Example:

             salt '*' hashutil.base64_decodestring instr='Z2V0IHNhbHRlZAo='

   salt.modules.hashutil.base64_encodefile(fname)
          Read  a file from the file system and return as a base64 encoded
          string

          New in version 2016.3.0.

          Pillar example:

             path:
               to:
                 data: |
                   {{ salt.hashutil.base64_encodefile('/path/to/binary_file') | indent(6) }}

          The file.decode state function can be used to decode  this  data
          and write it to disk.

          CLI Example:

             salt '*' hashutil.base64_encodefile /path/to/binary_file

   salt.modules.hashutil.base64_encodestring(instr)
          Encode a string as base64 using the "legacy" Python interface.

          Among  other possible differences, the "legacy" encoder includes
          a newline ('n') character after every 76 characters  and  always
          at the end of the encoded string.

          New in version 2014.7.0.

          CLI Example:

             salt '*' hashutil.base64_encodestring 'get salted'

   salt.modules.hashutil.digest(instr, checksum='md5')
          Return a checksum digest for a string

          instr  A string

          checksum
                 md5  The  hashing algorithm to use to generate checksums.
                 Valid options: md5, sha256, sha512.

          CLI Example:

             salt '*' hashutil.digest 'get salted'

   salt.modules.hashutil.digest_file(infile, checksum='md5')
          Return a checksum digest for a file

          infile A file path

          checksum
                 md5 The hashing algorithm to use to  generate  checksums.
                 Wraps the hashutil.digest execution function.

          CLI Example:

             salt '*' hashutil.digest_file /path/to/file

   salt.modules.hashutil.hmac_signature(string,             shared_secret,
   challenge_hmac)
          Verify  a  challenging  hmac  signature  against  a   string   /
          shared-secret

          New in version 2014.7.0.

          Returns a boolean if the verification succeeded or failed.

          CLI Example:

             salt '*' hashutil.hmac_signature 'get salted' 'shared secret' 'eBWf9bstXg+NiP5AOwppB5HMvZiYMPzEM9W5YMm/AmQ='

   salt.modules.hashutil.md5_digest(instr)
          Generate an md5 hash of a given string

          New in version 2014.7.0.

          CLI Example:

             salt '*' hashutil.md5_digest 'get salted'

   salt.modules.hashutil.sha256_digest(instr)
          Generate an sha256 hash of a given string

          New in version 2014.7.0.

          CLI Example:

             salt '*' hashutil.sha256_digest 'get salted'

   salt.modules.hashutil.sha512_digest(instr)
          Generate an sha512 hash of a given string

          New in version 2014.7.0.

          CLI Example:

             salt '*' hashutil.sha512_digest 'get salted'

   salt.modules.hg
   Support for the Mercurial SCM

   salt.modules.hg.archive(cwd,  output, rev='tip', fmt=None, prefix=None,
   user=None)
          Export a tarball from the repository

          cwd    The path to the Mercurial repository

          output The path to the archive tarball

          rev: tip
                 The revision to create an archive from

          fmt: None
                 Format of the resulting archive. Mercurial supports: tar,
                 tbz2, tgz, zip, uzip, and files formats.

          prefix None Prepend <prefix>/ to every filename in the archive

          user   None Run hg as a user other than what the minion runs as

          If  prefix  is  not specified it defaults to the basename of the
          repo directory.

          CLI Example:

             salt '*' hg.archive /path/to/repo output=/tmp/archive.tgz fmt=tgz

   salt.modules.hg.clone(cwd,    repository,     opts=None,     user=None,
   identity=None)
          Clone a new repository

          cwd    The path to the Mercurial repository

          repository
                 The hg URI of the repository

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          identity
                 None   Private   SSH   key   on  the  minion  server  for
                 authentication (ssh://)

                 New in version 2015.5.0.

          CLI Example:

             salt '*' hg.clone /path/to/repo https://bitbucket.org/birkenfeld/sphinx

   salt.modules.hg.describe(cwd, rev='tip', user=None)
          Mimic git describe  and  return  an  identifier  for  the  given
          revision

          cwd    The path to the Mercurial repository

          rev: tip
                 The path to the archive tarball

          user   None Run hg as a user other than what the minion runs as

          CLI Example:

             salt '*' hg.describe /path/to/repo

   salt.modules.hg.pull(cwd,    opts=None,    user=None,    identity=None,
   repository=None)
          Perform a pull on the given repository

          cwd    The path to the Mercurial repository

          repository
                 None Perform pull  from  the  repository  different  from
                 .hg/hgrc:[paths]:default

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          identity
                 None   Private   SSH   key   on  the  minion  server  for
                 authentication (ssh://)

                 New in version 2015.5.0.

          CLI Example:

             salt '*' hg.pull /path/to/repo opts=-u

   salt.modules.hg.revision(cwd, rev='tip', short=False, user=None)
          Returns the long hash of a given identifier (hash, branch,  tag,
          HEAD, etc)

          cwd    The path to the Mercurial repository

          rev: tip
                 The revision

          short: False
                 Return an abbreviated commit hash

          user   None Run hg as a user other than what the minion runs as

          CLI Example:

             salt '*' hg.revision /path/to/repo mybranch

   salt.modules.hg.status(cwd, opts=None, user=None)
          Show changed files of the given repository

          cwd    The path to the Mercurial repository

          opts   None Any additional options to add to the command line

          user   None Run hg as a user other than what the minion runs as

          CLI Example:

             salt '*' hg.status /path/to/repo

   salt.modules.hg.update(cwd, rev, force=False, user=None)
          Update to a given revision

          cwd    The path to the Mercurial repository

          rev    The revision to update to

          force  False Force an update

          user   None Run hg as a user other than what the minion runs as

          CLI Example:

             salt devserver1 hg.update /path/to/repo somebranch

   salt.modules.hipchat
   Module for sending messages to hipchat.

   New in version 2015.5.0.

   configuration
          This module can be used by either passing an api key and version
          directly or by specifying both in a configuration profile in the
          salt master/minion config.

          It    is    possible    to    use    a    different   API   than
          http://api.hipchat.com, by specifying the API URL in  config  as
          api_url, or by passing the value directly.

          For example:

             hipchat:
               api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15
               api_version: v1

          Custom API Example:

             hipchat:
               api_url: http://api.hipchat.myteam.com
               api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15
               api_version: v2

   salt.modules.hipchat.find_room(name,     api_url=None,    api_key=None,
   api_version=None)
          Find a room by name and return it.

          Parameters

                 * name -- The room name.

                 * api_url -- The HipChat API URL, if not specified in the
                   configuration.

                 * api_key -- The HipChat admin api key.

                 * api_version   --   The  HipChat  api  version,  if  not
                   specified in the configuration.

          Returns
                 The room object.

          CLI Example:

             salt '*' hipchat.find_room name="Development Room"

             salt '*' hipchat.find_room name="Development Room" api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15 api_version=v1

   salt.modules.hipchat.find_user(name,    api_url=None,     api_key=None,
   api_version=None)
          Find a user by name and return it.

          Parameters

                 * name -- The user name.

                 * api_url -- The HipChat API URL, if not specified in the
                   configuration.

                 * api_key -- The HipChat admin api key.

                 * api_version  --  The  HipChat  api  version,   if   not
                   specified in the configuration.

          Returns
                 The user object.

          CLI Example:

             salt '*' hipchat.find_user name="Thomas Hatch"

             salt '*' hipchat.find_user name="Thomas Hatch" api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15 api_version=v1

   salt.modules.hipchat.list_rooms(api_url=None,             api_key=None,
   api_version=None)
          List all HipChat rooms.

          Parameters

                 * api_url -- The HipChat API URL, if not specified in the
                   configuration.

                 * api_key -- The HipChat admin api key.

                 * api_version   --   The  HipChat  api  version,  if  not
                   specified in the configuration.

          Returns
                 The room list.

          CLI Example:

             salt '*' hipchat.list_rooms

             salt '*' hipchat.list_rooms api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15 api_version=v1

   salt.modules.hipchat.list_users(api_url=None,             api_key=None,
   api_version=None)
          List all HipChat users.

          Parameters

                 * api_url -- The HipChat API URL, if not specified in the
                   configuration.

                 * api_key -- The HipChat admin api key.

                 * api_version  --  The  HipChat  api  version,   if   not
                   specified in the configuration.

          Returns
                 The user list.

          CLI Example:

             salt '*' hipchat.list_users

             salt '*' hipchat.list_users api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15 api_version=v1

   salt.modules.hipchat.send_message(room_id,      message,     from_name,
   api_url=None,    api_key=None,    api_version=None,     color='yellow',
   notify=False)
          Send a message to a HipChat room.

          Parameters

                 * room_id -- The room id or room name, either will work.

                 * message -- The message to send to the HipChat room.

                 * from_name -- Specify who the message is from.

                 * api_url -- The HipChat api URL, if not specified in the
                   configuration.

                 * api_key -- The HipChat api key, if not specified in the
                   configuration.

                 * api_version   --   The  HipChat  api  version,  if  not
                   specified in the configuration.

                 * color -- The color for the message, default: yellow.

                 * notify -- Whether to notify the room, default: False.

          Returns
                 Boolean if message was sent successfully.

          CLI Example:

             salt '*' hipchat.send_message room_id="Development Room" message="Build is done" from_name="Build Server"

             salt '*' hipchat.send_message room_id="Development Room" message="Build failed" from_name="Build Server" color="red" notify=True

   salt.modules.hosts
   Manage the information in the hosts file

   salt.modules.hosts.add_host(ip, alias)
          Add a host to an existing entry, if the entry is  not  in  place
          then create it with the given host

          CLI Example:

             salt '*' hosts.add_host <ip> <alias>

   salt.modules.hosts.get_alias(ip)
          Return the list of aliases associated with an ip

          Aliases  (host  names)  are  returned in the order in which they
          appear in the hosts file.  If there are  no  aliases  associated
          with the IP, an empty list is returned.

          CLI Example:

             salt '*' hosts.get_alias <ip addr>

   salt.modules.hosts.get_ip(host)
          Return the ip associated with the named host

          CLI Example:

             salt '*' hosts.get_ip <hostname>

   salt.modules.hosts.has_pair(ip, alias)
          Return true if the alias is set

          CLI Example:

             salt '*' hosts.has_pair <ip> <alias>

   salt.modules.hosts.list_hosts()
          Return the hosts found in the hosts file in this format:

             {'<ip addr>': ['alias1', 'alias2', ...]}

          CLI Example:

             salt '*' hosts.list_hosts

   salt.modules.hosts.rm_host(ip, alias)
          Remove a host entry from the hosts file

          CLI Example:

             salt '*' hosts.rm_host <ip> <alias>

   salt.modules.hosts.set_host(ip, alias)
          Set the host entry in the hosts file for the given ip, this will
          overwrite any previous entry for the given ip

          Changed in version 2016.3.0: If alias does not include any  host
          names  (it is the empty string or contains only whitespace), all
          entries for the given IP address are removed.

          CLI Example:

             salt '*' hosts.set_host <ip> <alias>

   salt.modules.htpasswd
   Support for htpasswd command. Requires the  apache2-utils  package  for
   Debian-based distros.

   New in version 2014.1.0.

   The  functions  here  will  load inside the webutil module. This allows
   other functions that don't use htpasswd to use the webutil module name.

   salt.modules.htpasswd.useradd(pwfile,    user,    password,    opts='',
   runas=None)
          Add  a  user to htpasswd file using the htpasswd command. If the
          htpasswd file does not exist, it will be created.

          pwfile Path to htpasswd file

          user   User name

          password
                 User password

          opts   Valid options that can be passed are:

                    * n  Don't update file; display results on stdout.

                    * m  Force MD5 encryption of the password (default).

                    * d  Force CRYPT encryption of the password.

                    * p  Do not encrypt the password (plaintext).

                    * s  Force SHA encryption of the password.

          runas  The system user to run htpasswd command with

          CLI Examples:

             salt '*' webutil.useradd /etc/httpd/htpasswd larry badpassword
             salt '*' webutil.useradd /etc/httpd/htpasswd larry badpass opts=ns

   salt.modules.htpasswd.useradd_all(pwfile,  user,   password,   opts='',
   runas=None)
          Add  a  user to htpasswd file using the htpasswd command. If the
          htpasswd file does not exist, it will be created.

          Deprecated since version Nitrogen.

          pwfile Path to htpasswd file

          user   User name

          password
                 User password

          opts   Valid options that can be passed are:

                    * n  Don't update file; display results on stdout.

                    * m  Force MD5 encryption of the password (default).

                    * d  Force CRYPT encryption of the password.

                    * p  Do not encrypt the password (plaintext).

                    * s  Force SHA encryption of the password.

          runas  The system user to run htpasswd command with

          CLI Examples:

             salt '*' webutil.useradd /etc/httpd/htpasswd larry badpassword
             salt '*' webutil.useradd /etc/httpd/htpasswd larry badpass opts=ns

   salt.modules.htpasswd.userdel(pwfile, user, runas=None)
          Delete a user from the specified htpasswd file.

          pwfile Path to htpasswd file

          user   User name

          runas  The system user to run htpasswd command with

          CLI Examples:

             salt '*' webutil.userdel /etc/httpd/htpasswd larry

   salt.modules.http
   Module for making various web calls. Primarily  designed  for  webhooks
   and the like, but also useful for basic http testing.

   New in version 2015.5.0.

   salt.modules.http.query(url, **kwargs)
          Query a resource, and decode the return data

          New in version 2015.5.0.

          CLI Example:

             salt '*' http.query http://somelink.com/
             salt '*' http.query http://somelink.com/ method=POST             params='key1=val1&key2=val2'
             salt '*' http.query http://somelink.com/ method=POST             data='<xml>somecontent</xml>'

   salt.modules.http.update_ca_bundle(target=None,            source=None,
   merge_files=None)
          Update the local CA bundle file from a URL

          New in version 2015.5.0.

          CLI Example:

             salt '*' http.update_ca_bundle
             salt '*' http.update_ca_bundle target=/path/to/cacerts.pem
             salt '*' http.update_ca_bundle source=https://example.com/cacerts.pem

          If the target is not specified,  it  will  be  pulled  from  the
          ca_cert  configuration  variable  available to the minion. If it
          cannot   be   found   there,    it    will    be    placed    at
          <<FILE_ROOTS>>/cacerts.pem.

          If  the  source  is  not  specified,  it will be pulled from the
          ca_cert_url configuration variable available to the  minion.  If
          it cannot be found, it will be downloaded from the cURL website,
          using an http (not https) URL. USING THE DEFAULT URL  SHOULD  BE
          AVOIDED!

          merge_files  may  also  be specified, which includes a string or
          list of strings representing a file or files to be  appended  to
          the end of the CA bundle, once it is downloaded.

          CLI Example:

             salt '*' http.update_ca_bundle merge_files=/path/to/mycert.pem

   salt.modules.http.wait_for_successful_query(url,          wait_for=300,
   **kwargs)
          Query a resource until a successful  response,  and  decode  the
          return data

          CLI Example:

             salt '*' http.wait_for_successful_query http://somelink.com/ wait_for=160

   salt.modules.ifttt
   Support for IFTTT

   New in version 2015.8.0.

   Requires an api_key in /etc/salt/minion:

   salt.modules.ifttt.trigger_event(event=None, **kwargs)
          Trigger a configured event in IFTTT.

          Parameters
                 event -- The name of the event to trigger.

          Returns
                 A  dictionary  with status, text, and error if result was
                 failure.

   salt.modules.ilo
   Manage HP ILO

   depends
          hponcfg (SmartStart Scripting Toolkit Linux Edition)

   salt.modules.ilo.change_password(username, password)
          Reset a users password

          CLI Example:

             salt '*' ilo.change_password damianMyerscough

   salt.modules.ilo.change_username(old_username, new_username)
          Change a username

          CLI Example:

             salt '*' ilo.change_username damian diana

   salt.modules.ilo.configure_network(ip, netmask, gateway)
          Configure Network Interface

          CLI Example:

             salt '*' ilo.configure_network [IP ADDRESS] [NETMASK] [GATEWAY]

   salt.modules.ilo.configure_snmp(community,               snmp_port=161,
   snmp_trapport=161)
          Configure SNMP

          CLI Example:

             salt '*' ilo.configure_snmp [COMMUNITY STRING] [SNMP PORT] [SNMP TRAP PORT]

   salt.modules.ilo.create_user(name, password, *privileges)
          Create user

          CLI Example:

             salt '*' ilo.create_user damian secretagent VIRTUAL_MEDIA_PRIV

          If  no  permissions  are  specify  the  user  will  only  have a
          read-only account.

          Supported privelges:

          * ADMIN_PRIV Enables the user to administer user accounts.

          * REMOTE_CONS_PRIV Enables the user to access the Remote Console
            functionality.

          * RESET_SERVER_PRIV  Enables the user to remotely manipulate the
            server power setting.

          * VIRTUAL_MEDIA_PRIV Enables the user permission to  access  the
            virtual media functionality.

          * CONFIG_ILO_PRIV Enables the user to configure iLO settings.

   salt.modules.ilo.delete_ssh_key(username)
          Delete a users SSH key from the ILO

          CLI Example:

             salt '*' ilo.delete_user_sshkey damian

   salt.modules.ilo.delete_user(username)
          Delete a user

          CLI Example:

             salt '*' ilo.delete_user damian

   salt.modules.ilo.disable_dhcp()
          Disable DHCP

          CLI Example:

             salt '*' ilo.disable_dhcp

   salt.modules.ilo.disable_ssh()
          Disable the SSH daemon

          CLI Example:

             salt '*' ilo.disable_ssh

   salt.modules.ilo.enable_dhcp()
          Enable DHCP

          CLI Example:

             salt '*' ilo.enable_dhcp

   salt.modules.ilo.enable_ssh()
          Enable the SSH daemon

          CLI Example:

             salt '*' ilo.enable_ssh

   salt.modules.ilo.get_user(username)
          Returns local user information, excluding the password

          CLI Example:

             salt '*' ilo.get_user damian

   salt.modules.ilo.global_settings()
          Show global settings

          CLI Example:

             salt '*' ilo.global_settings

   salt.modules.ilo.list_users()
          List all users

          CLI Example:

             salt '*' ilo.list_users

   salt.modules.ilo.list_users_info()
          List all users in detail

          CLI Example:

             salt '*' ilo.list_users_info

   salt.modules.ilo.network()
          Grab the current network settings

          CLI Example:

             salt '*' ilo.network

   salt.modules.ilo.set_http_port(port=80)
          Configure the port HTTP should listen on

          CLI Example:

             salt '*' ilo.set_http_port 8080

   salt.modules.ilo.set_https_port(port=443)
          Configure the port HTTPS should listen on

          CLI Example:

             salt '*' ilo.set_https_port 4334

   salt.modules.ilo.set_ssh_key(public_key)
          Configure SSH public keys for specific users

          CLI Example:

             salt '*' ilo.set_ssh_key "ssh-dss AAAAB3NzaC1kc3MAAACBA... damian"

          The  SSH public key needs to be DSA and the last argument in the
          key  needs  to  be  the  username  (case-senstive)  of  the  ILO
          username.

   salt.modules.ilo.set_ssh_port(port=22)
          Enable SSH on a user defined port

          CLI Example:

             salt '*' ilo.set_ssh_port 2222

   salt.modules.img
   Virtual machine image management tools

   salt.modules.img.bootstrap(location, size, fmt)
          HIGHLY EXPERIMENTAL Bootstrap a virtual machine image

          location:
                 The location to create the image

          size:  The size of the image to create in megabytes

          fmt:   The image format, raw or qcow2

          CLI Example:

             salt '*' img.bootstrap /srv/salt-images/host.qcow 4096 qcow2

   salt.modules.img.mount_image(location)
          Mount the named image and return the mount point

          CLI Example:

             salt '*' img.mount_image /tmp/foo

   salt.modules.img.umount_image(mnt)
          Unmount an image mountpoint

          CLI Example:

             salt '*' img.umount_image /mnt/foo

   salt.modules.incron
   Work with incron

   salt.modules.incron.list_tab(user)
          Return the contents of the specified user's incrontab

          CLI Example:

             salt '*' incron.list_tab root

   salt.modules.incron.ls(user)
          This function is an alias of list_tab.
             Return the contents of the specified user's incrontab

             CLI Example:

                 salt '*' incron.list_tab root

   salt.modules.incron.raw_incron(user)
          Return the contents of the user's incrontab

          CLI Example:

             salt '*' incron.raw_incron root

   salt.modules.incron.raw_system_incron()
          Return the contents of the system wide incrontab

          CLI Example:

             salt '*' incron.raw_system_incron

   salt.modules.incron.rm(user, path, mask, cmd)
          This function is an alias of rm_job.
             Remove  a  incron  job  for  a  specified user. If any of the
             day/time params are specified, the job will only  be  removed
             if the specified params match.

             CLI Example:

                 salt '*' incron.rm_job root /path

   salt.modules.incron.rm_job(user, path, mask, cmd)
          Remove a incron job for a specified user. If any of the day/time
          params are specified, the  job  will  only  be  removed  if  the
          specified params match.

          CLI Example:

             salt '*' incron.rm_job root /path

   salt.modules.incron.set_job(user, path, mask, cmd)
          Sets an incron job up for a specified user.

          CLI Example:

             salt '*' incron.set_job root '/root' 'IN_MODIFY' 'echo "$$ $@ $# $% $&"'

   salt.modules.incron.write_incron_file(user, path)
          Writes the contents of a file to a user's incrontab

          CLI Example:

             salt '*' incron.write_incron_file root /tmp/new_incron

   salt.modules.incron.write_incron_file_verbose(user, path)
          Writes  the  contents of a file to a user's incrontab and return
          error message on error

          CLI Example:

             salt '*' incron.write_incron_file_verbose root /tmp/new_incron

   salt.modules.influx
   InfluxDB - A distributed time series database

   Module to provide  InfluxDB  compatibility  to  Salt  (compatible  with
   InfluxDB version 0.9+)

   depends

          * influxdb Python module (>= 3.0.0)

   configuration
          This  module  accepts connection configuration details either as
          parameters or as configuration settings in  /etc/salt/minion  on
          the relevant minions:

             influxdb.host: 'localhost'
             influxdb.port: 8086
             influxdb.user: 'root'
             influxdb.password: 'root'

          This  data  can  also be passed into pillar. Options passed into
          opts will overwrite options passed into pillar.

          Most functions in this module allow you to override  or  provide
          some or all of these settings via keyword arguments:

             salt '*' influxdb.foo_function user='influxadmin' password='s3cr1t'

          would  override user and password while still using the defaults
          for host and port.

   salt.modules.influx.alter_retention_policy(database,  name,   duration,
   replication, default=False, **client_args)
          Modify an existing retention policy.

          name   Name of the retention policy to modify.

          database
                 Name  of  the database for which the retention policy was
                 defined.

          duration
                 New duration of given retention policy.

                 Durations such as 1h, 90m,  12h,  7d,  and  4w,  are  all
                 supported  and  mean 1 hour, 90 minutes, 12 hours, 7 day,
                 and 4  weeks,  respectively.  For  infinite  retention  --
                 meaning  the  data  will never be deleted -- use 'INF' for
                 duration.  The minimum retention period is 1 hour.

          replication
                 New replication of given retention policy.

                 This determines how many independent copies of each  data
                 point are stored in a cluster.

          default
                 False  Whether  or  not  to  set  the  modified policy as
                 default.

          CLI Example:

             salt '*' influxdb.alter_retention_policy metrics default 1d 1

   salt.modules.influx.create_db(name, **client_args)
          Create a database.

          name   Name of the database to create.

          CLI Example:

             salt '*' influxdb.create_db <name>

   salt.modules.influx.create_retention_policy(database,  name,  duration,
   replication, default=False, **client_args)
          Create a retention policy.

          database
                 Name  of the database for which the retention policy will
                 be created.

          name   Name of the new retention policy.

          duration
                 Duration of the new retention policy.

                 Durations such as 1h, 90m,  12h,  7d,  and  4w,  are  all
                 supported  and  mean 1 hour, 90 minutes, 12 hours, 7 day,
                 and 4  weeks,  respectively.  For  infinite  retention  --
                 meaning  the  data  will never be deleted -- use 'INF' for
                 duration. The minimum retention period is 1 hour.

          replication
                 Replication factor of the retention policy.

                 This determines how many independent copies of each  data
                 point are stored in a cluster.

          default
                 False Whether or not the policy as default will be set as
                 default.

          CLI Example:

             salt '*' influxdb.create_retention_policy metrics default 1d 1

   salt.modules.influx.create_user(name,      password,       admin=False,
   **client_args)
          Create a user.

          name   Name of the user to create.

          password
                 Password of the new user.

          admin  False Whether the user should have cluster administration
                 privileges or not.

          CLI Example:

             salt '*' influxdb.create_user <name> <password>
             salt '*' influxdb.create_user <name> <password> admin=True

   salt.modules.influx.db_exists(name, **client_args)
          Checks if a database exists in InfluxDB.

          name   Name of the database to check.

          CLI Example:

             salt '*' influxdb.db_exists <name>

   salt.modules.influx.drop_db(name, **client_args)
          Drop a database.

          name   Name of the database to drop.

          CLI Example:

             salt '*' influxdb.drop_db <name>

   salt.modules.influx.get_retention_policy(database, name, **client_args)
          Get an existing retention policy.

          database
                 Name of the database for which the retention  policy  was
                 defined.

          name   Name of the retention policy.

          CLI Example:

             salt '*' influxdb.get_retention_policy metrics default

   salt.modules.influx.grant_admin_privileges(name, **client_args)
          Grant cluster administration privileges to a user.

          name   Name  of  the  user  to  whom  admin  privileges  will be
                 granted.

          CLI Example:

             salt '*' influxdb.grant_admin_privileges <name>

   salt.modules.influx.grant_privilege(database,   privilege,    username,
   **client_args)
          Grant a privilege on a database to a user.

          database
                 Name of the database to grant the privilege on.

          privilege
                 Privilege  to  grant.  Can  be  one of 'read', 'write' or
                 'all'.

          username
                 Name of the user to grant the privilege to.

   salt.modules.influx.list_dbs(**client_args)
          List all InfluxDB databases.

          CLI Example:

             salt '*' influxdb.list_dbs

   salt.modules.influx.list_users(**client_args)
          List all users.

          CLI Example:

             salt '*' influxdb.list_users

   salt.modules.influx.remove_user(name, **client_args)
          Remove a user.

          name   Name of the user to remove

          CLI Example:

             salt '*' influxdb.remove_user <name>

   salt.modules.influx.retention_policy_exists(database,             name,
   **client_args)
          Check if retention policy with given name exists.

          database
                 Name  of  the database for which the retention policy was
                 defined.

          name   Name of the retention policy to check.

          CLI Example:

             salt '*' influxdb.retention_policy_exists metrics default

   salt.modules.influx.revoke_admin_privileges(name, **client_args)
          Revoke cluster administration privileges from a user.

          name   Name of the user  from  whom  admin  privileges  will  be
                 revoked.

          CLI Example:

             salt '*' influxdb.revoke_admin_privileges <name>

   salt.modules.influx.revoke_privilege(database,   privilege,   username,
   **client_args)
          Revoke a privilege on a database from a user.

          database
                 Name of the database to grant the privilege on.

          privilege
                 Privilege to grant. Can be  one  of  'read',  'write'  or
                 'all'.

          username
                 Name of the user to grant the privilege to.

   salt.modules.influx.set_user_password(name, password, **client_args)
          Change password of a user.

          name   Name of the user for whom to set the password.

          password
                 New password of the user.

          CLI Example:

             salt '*' influxdb.set_user_password <name> <password>

   salt.modules.influx.user_exists(name, **client_args)
          Check if a user exists.

          name   Name of the user to check.

          CLI Example:

             salt '*' influxdb.user_exists <name>

   salt.modules.influx.user_info(name, **client_args)
          Get information about given user.

          name   Name of the user for which to get information.

          CLI Example:

             salt '*' influxdb.user_info <name>

   salt.modules.infoblox
   Module for managing Infoblox

   Will    look    for   pillar   data   infoblox:server,   infoblox:user,
   infoblox:password if not passed to functions

   New in version 2016.3.0.

   depends

          * requests

   salt.modules.infoblox.add_record(name,  value,  record_type,  dns_view,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          add a record to an infoblox dns view

          name   the record name

          value

                 the value for the entry
                        can  make  use  of  infoblox  functions  for  next
                        available                 IP,                 like
                        'func:nextavailableip:10.1.0.0/24'

          record_type
                 the record type (cname, a, host, etc)

          dns_view
                 the DNS view to add the record to

          infoblox_server
                 the  infoblox  server  hostname   (can   also   use   the
                 infoblox:server pillar)

          infoblox_user
                 the  infoblox  user  to  connect  with  (can also use the
                 infoblox:user pillar)

          infoblox_password
                 the  infoblox  user's  password   (can   also   use   the
                 infolblox:password pillar)

          infoblox_api_version
                 the infoblox api version to use

          sslVerify
                 should  ssl verification be done on the connection to the
                 Infoblox REST API

          CLI Example:

             salt 'myminion' infoblox.add_record alias.network.name canonical.network.name MyView

   salt.modules.infoblox.delete_record(name,    dns_view,     record_type,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          delete a record

          name   name of the record

          dns_view
                 the DNS view to remove the record from

          record_type
                 the record type (a, cname, host, etc)

          infoblox_server
                 the  infoblox  server  hostname   (can   also   use   the
                 infoblox:server pillar)

          infoblox_user
                 the  infoblox  user  to  connect  with  (can also use the
                 infoblox:user pillar)

          infoblox_password
                 the  infoblox  user's  password   (can   also   use   the
                 infolblox:password pillar)

          infoblox_api_version
                 the infoblox api version to use

          sslVerify
                 should  ssl verification be done on the connection to the
                 Infoblox REST API

          CLI Example:

             salt my-minion infoblox.delete_record some.dns.record MyInfobloxView A sslVerify=False

   salt.modules.infoblox.get_network(network_name,      network_view=None,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          get a network from infoblox

          network_name
                 The name of the network in IPAM

          network_view
                 The name of the network view the network belongs to

          infoblox_server
                 the  infoblox  server  hostname   (can   also   use   the
                 infoblox:server pillar)

          infoblox_user
                 the  infoblox  user  to  connect  with  (can also use the
                 infoblox:user pillar)

          infoblox_password
                 the  infoblox  user's  password   (can   also   use   the
                 infolblox:password pillar)

          infoblox_api_version
                 the infoblox api version to use

          sslVerify
                 should  ssl verification be done on the connection to the
                 Infoblox REST API

          CLI Example:

             salt myminion infoblox.get_network '10.0.0.0/8'

   salt.modules.infoblox.get_record(record_name,       record_type='host',
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   dns_view=None, infoblox_api_version='v1.4.2', sslVerify=True)
          get a record from infoblox

          record_name
                 name of the record to search for

          record_type
                 type  of  reacord  to  search  for   (host,   cname,   a,
                 etc...defaults to host)

          infoblox_server
                 the   infoblox   server   hostname   (can  also  use  the
                 infoblox:server pillar)

          infoblox_user
                 the infoblox user to  connect  with  (can  also  use  the
                 infoblox:user pillar)

          infoblox_password
                 the   infoblox   user's   password   (can  also  use  the
                 infolblox:password pillar)

          dns_view
                 the infoblox DNS view to search,  if  not  specified  all
                 views are searched

          infoblox_api_version
                 the infoblox api version to use

          sslVerify
                 should  ssl verification be done on the connection to the
                 Infoblox REST API

          CLI Example:

             salt myminion infoblox.get_record some.host.com A sslVerify=False

   salt.modules.infoblox.update_record(name, value, dns_view, record_type,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          update an entry to an infoblox dns view

          name   the dns name

          value  the value for the record

          record_type
                 the record type (a, cname, etc)

          dns_view
                 the DNS view to add the record to

          infoblox_server
                 the  infoblox  server  hostname   (can   also   use   the
                 infoblox:server pillar)

          infoblox_user
                 the  infoblox  user  to  connect  with  (can also use the
                 infoblox:user pillar)

          infoblox_password
                 the  infoblox  user's  password   (can   also   use   the
                 infolblox:password pillar)

          infoblox_api_version
                 the infoblox api version to use

          sslVerify
                 should  ssl verification be done on the connection to the
                 Infoblox REST API

          CLI Example:

             salt '*' infoblox.update_record alias.network.name canonical.network.name MyInfobloxView cname sslVerify=False

   salt.modules.ini_manage
   Edit ini files

   maintainer
          <[email protected]>

   maturity
          new

   depends
          re

   platform
          all

   (for example /etc/sysctl.conf)

   salt.modules.ini_manage.get_option(file_name,     section,      option,
   separator='=')
          Get  value  of a key from a section in an ini file. Returns None
          if no matching key was found.

          API Example:

             import salt
             sc = salt.client.get_local_client()
             sc.cmd('target', 'ini.get_option',
                    [path_to_ini_file, section_name, option])

          CLI Example:

             salt '*' ini.get_option /path/to/ini section_name option_name

   salt.modules.ini_manage.get_section(file_name, section, separator='=')
          Retrieve a section from an ini  file.  Returns  the  section  as
          dictionary.  If the section is not found, an empty dictionary is
          returned.

          API Example:

             import salt
             sc = salt.client.get_local_client()
             sc.cmd('target', 'ini.get_section',
                    [path_to_ini_file, section_name])

          CLI Example:

             salt '*' ini.get_section /path/to/ini section_name

   salt.modules.ini_manage.remove_option(file_name,    section,    option,
   separator='=')
          Remove  a  key/value pair from a section in an ini file. Returns
          the value of the removed key, or None if nothing was removed.

          API Example:

             import salt
             sc = salt.client.get_local_client()
             sc.cmd('target', 'ini.remove_option',
                    [path_to_ini_file, section_name, option])

          CLI Example:

             salt '*' ini.remove_option /path/to/ini section_name option_name

   salt.modules.ini_manage.remove_section(file_name,              section,
   separator='=')
          Remove  a section in an ini file. Returns the removed section as
          dictionary, or None if nothing was removed.

          API Example:

             import salt
             sc = salt.client.get_local_client()
             sc.cmd('target', 'ini.remove_section',
                    [path_to_ini_file, section_name])

          CLI Example:

             salt '*' ini.remove_section /path/to/ini section_name

   salt.modules.ini_manage.set_option(file_name,            sections=None,
   separator='=')
          Edit  an  ini  file,  replacing  one or more sections. Returns a
          dictionary containing the changes made.

          file_name
                 path of ini_file

          sections
                 None A dictionary representing the sections to be  edited
                 ini  file  The  keys are the section names and the values
                 are the dictionary containing the options If the ini file
                 does  not  contain sections the keys and values represent
                 the options

          separator
                 = A character used to separate keys and values.  Standard
                 ini files use the "=" character.

                 New in version 2016.11.0.

          API Example:

             import salt
             sc = salt.client.get_local_client()
             sc.cmd('target', 'ini.set_option',
                    ['path_to_ini_file', '{"section_to_change": {"key": "value"}}'])

          CLI Example:

             salt '*' ini.set_option /path/to/ini '{section_foo: {key: value}}'

   salt.modules.inspectlib package
   Submodules
   salt.modules.inspectlib.collector module
   salt.modules.inspectlib.collector.is_alive(pidfile)
          Check if PID is still alive.

   salt.modules.inspectlib.collector.main(dbfile, pidfile, mode)
          Main analyzer routine.

   salt.modules.inspectlib.dbhandle module
   class salt.modules.inspectlib.dbhandle.DBHandleBase(path)
          Handle  for  the  volatile database, which serves the purpose of
          caching the inspected data. This database can  be  destroyed  or
          corrupted, so it should be simply re-created from scratch.

          close()
                 Close the database connection.

          flush(table)
                 Flush the table.

          open(new=False)
                 Init the database, if required.

          purge()
                 Purge whole database.

   salt.modules.inspectlib.exceptions module
   exception
   salt.modules.inspectlib.exceptions.InspectorKiwiProcessorException
          Kiwi builder/exporter exception.

   exception salt.modules.inspectlib.exceptions.InspectorQueryException
          Exception that is only for the inspector query.

   exception salt.modules.inspectlib.exceptions.InspectorSnapshotException
          Snapshot exception.

   exception salt.modules.inspectlib.exceptions.SIException
          System information exception.

   salt.modules.inspectlib.query module
   class salt.modules.inspectlib.query.Query(scope, cachedir=None)
          Query the system.  This class is actually puts all Salt features
          together,  so  there  would  be  no need to pick it from various
          places.

   class salt.modules.inspectlib.query.SysInfo(systype)
          System information.

   Module contents
   class   salt.modules.inspectlib.EnvLoader(cachedir=None,   piddir=None,
   pidfilename=None)
          Load environment.

   salt.modules.introspect
   Functions  to  perform  introspection on a minion, and return data in a
   format usable by Salt States

   salt.modules.introspect.enabled_service_owners()
          Return  which  packages  own  each  of  the  services  that  are
          currently enabled.

          CLI Example:
             salt myminion introspect.enabled_service_owners

   salt.modules.introspect.running_service_owners(exclude=('/dev',
   '/home', '/media', '/proc', '/run', '/sys/', '/tmp', '/var'))
          Determine which packages own the currently running services.  By
          default, excludes files whose full path starts with /dev, /home,
          /media, /proc, /run, /sys, /tmp and /var. This can be overridden
          by passing in a new list to exclude.

          CLI Example:
             salt myminion introspect.running_service_owners

   salt.modules.introspect.service_highstate(requires=True)
          Return running and enabled services in a highstate structure. By
          default also returns package dependencies  for  those  services,
          which  means  that  package  definitions must be created outside
          this function. To drop the package dependencies, set requires to
          False.

          CLI Example:
             salt   myminion  introspect.service_highstate  salt  myminion
             introspect.service_highstate requires=False

   salt.modules.ipmi
   Support IPMI commands over LAN. This module does not talk to the  local
   systems hardware through IPMI drivers. It uses a python module pyghmi.

   depends
          Python module pyghmi.  You can install pyghmi using pip:

             pip install pyghmi

   configuration
          The  following  configuration  defaults can be define (pillar or
          config files):

             ipmi.config:
                 api_host: 127.0.0.1
                 api_user: admin
                 api_pass: apassword
                 api_port: 623
                 api_kg: None

          Usage can override the config defaults:

             salt-call ipmi.get_user api_host=myipmienabled.system
                                     api_user=admin api_pass=pass
                                     uid=1

   salt.modules.ipmi.create_user(uid,    name,    password,    channel=14,
   callback=False,              link_auth=True,             ipmi_msg=True,
   privilege_level='administrator', **kwargs)
          create/ensure a user is created with provided settings.

          Parameters

                 * privilege_level -- User  Privilege  Limit.  (Determines
                   the maximum privilege level that the user is allowed to
                   switch to on the specified channel.)  * callback * user
                   * operator * administrator * proprietary * no_access

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   CLI Examples:

             salt-call ipmi.create_user uid=2 name=steverweber api_host=172.168.0.7 api_pass=nevertell

   salt.modules.ipmi.fast_connect_test(**kwargs)
          Returns  True  if  connection  success.  This uses an aggressive
          timeout value!

          Parameters
                 kwargs -- .INDENT 7.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   CLI Examples:

             salt-call ipmi.fast_connect_test api_host=172.168.0.9

   salt.modules.ipmi.get_bootdev(**kwargs)
          Get current boot device override information.

          Provides the current requested boot device.  Be aware  that  not
          all  IPMI  devices  support  this.   Even in BMCs that claim to,
          occasionally the BIOS or UEFI fail to honor it. This is  usually
          only applicable to the next reboot.

          Parameters
                 kwargs -- .INDENT 7.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   CLI Example:

             salt-call ipmi.get_bootdev api_host=127.0.0.1 api_user=admin api_pass=pass

   salt.modules.ipmi.get_channel_access(channel=14,
   read_mode='non_volatile', **kwargs)
          :param       kwargs:api_host='127.0.0.1'        api_user='admin'
          api_pass='example' api_port=623

          Parameters

                 * channel -- number [1:7]

                 * read_mode -- .INDENT 2.0

                 * non_volatile  = get non-volatile Channel Access

                 * volatile       =  get present volatile (active) setting
                   of Channel Access

          * kwargs -- .INDENT 2.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

          return A Python dict with the following keys/values:

                    {
                        alerting:
                        per_msg_auth:
                        user_level_auth:
                        access_mode:{ (ONE OF)
                            0: 'disabled',
                            1: 'pre_boot',
                            2: 'always',
                            3: 'shared'
                        }
                        privilege_level: { (ONE OF)
                            1: 'callback',
                            2: 'user',
                            3: 'operator',
                            4: 'administrator',
                            5: 'proprietary',
                        }
                    }

          CLI Examples:

             salt-call ipmi.get_channel_access channel=1

   salt.modules.ipmi.get_channel_info(channel=14, **kwargs)
          Get channel info

          Parameters

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

          return channel session supports:

                    - no_session: channel is session-less
                    - single: channel is single-session
                    - multi: channel is multi-session
                    - auto: channel is session-based (channel could alternate between
                        single- and multi-session operation, as can occur with a
                        serial/modem channel that supports connection mode auto-detect)

          CLI Examples:

             salt-call ipmi.get_channel_info

   salt.modules.ipmi.get_channel_max_user_count(channel=14, **kwargs)
          Get max users in channel

          Parameters

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   Returns
          int -- often 16

   CLI Examples:

             salt-call ipmi.get_channel_max_user_count

   salt.modules.ipmi.get_health(**kwargs)
          Get Summarize health

          This provides a summary of the health of the managed system.  It
          additionally  provides  an iterable list of reasons for warning,
          critical, or failed assessments.

          good health: {'badreadings': [], 'health': 0}

          Parameters
                 kwargs -- .INDENT 7.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   CLI Example:

             salt-call ipmi.get_health api_host=127.0.0.1 api_user=admin api_pass=pass

   salt.modules.ipmi.get_power(**kwargs)
          Get current power state

          The response, if successful, should contain 'powerstate' key and
          either 'on' or 'off' to indicate current state.

          Parameters
                 kwargs -- .INDENT 7.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   CLI Example:

             salt-call ipmi.get_power api_host=127.0.0.1 api_user=admin api_pass=pass

   salt.modules.ipmi.get_sensor_data(**kwargs)
          Get sensor readings

          Iterates sensor reading objects

          Parameters
                 kwargs -- .INDENT 7.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   CLI Example:

             salt-call ipmi.get_sensor_data api_host=127.0.0.1 api_user=admin api_pass=pass

   salt.modules.ipmi.get_user(uid, channel=14, **kwargs)
          Get user from uid and access on channel

          Parameters

                 * uid -- user number [1:16]

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   return

                 name: (str)
                 uid: (int)
                 channel: (int)
                 access:
                     - callback (bool)
                     - link_auth (bool)
                     - ipmi_msg (bool)
                     - privilege_level: (str)[callback, user, operatorm administrator,
                                             proprietary, no_access]

          CLI Examples:

             salt-call ipmi.get_user uid=2

   salt.modules.ipmi.get_user_access(uid, channel=14, **kwargs)
          Get user access

          Parameters

                 * uid -- user number [1:16]

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   return

                 channel_info:
                     - max_user_count = maximum number of user IDs on this channel
                     - enabled_users = count of User ID slots presently in use
                     - users_with_fixed_names = count of user IDs with fixed names
                 access:
                     - callback
                     - link_auth
                     - ipmi_msg
                     - privilege_level: [reserved, callback, user, operator
                                        administrator, proprietary, no_access]

          CLI Examples:

             salt-call ipmi.get_user_access uid=2

   salt.modules.ipmi.get_user_name(uid,         return_none_on_error=True,
   **kwargs)
          Get user name

          Parameters

                 * uid -- user number [1:16]

                 * return_none_on_error -- return None on error

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   CLI Examples:

             salt-call ipmi.get_user_name uid=2

   salt.modules.ipmi.get_users(channel=14, **kwargs)
          get list of users and access information

          Parameters

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   Returns

          * name: (str)

          * uid: (int)

          * channel: (int)

          *

            access:

                   * callback (bool)

                   * link_auth (bool)

                   * ipmi_msg (bool)

                   * privilege_level:  (str)[callback,   user,   operatorm
                     administrator, proprietary, no_access]

   CLI Examples:

             salt-call ipmi.get_users api_host=172.168.0.7

   salt.modules.ipmi.raw_command(netfn,    command,   bridge_request=None,
   data=(), retry=True, delay_xmit=None, **kwargs)
          Send raw ipmi command

          This allows arbitrary IPMI bytes to be issued.  This is commonly
          used for certain vendor specific commands.

          Parameters

                 * netfn -- Net function number

                 * command -- Command value

                 * bridge_request  -- The target slave address and channel
                   number for the bridge request.

                 * data -- Command data as a tuple or list

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   Returns
          dict -- The response from IPMI device

   CLI Examples:

             salt-call ipmi.raw_command netfn=0x06 command=0x46 data=[0x02]
             # this will return the name of the user with id 2 in bytes

   salt.modules.ipmi.set_bootdev(bootdev='default',         persist=False,
   uefiboot=False, **kwargs)
          Set boot device to use on next reboot

          Parameters

                 * bootdev -- .INDENT 2.0

                 * network: Request network boot

                 * hd: Boot from hard drive

                 * safe: Boot from hard drive, requesting 'safe mode'

                 * optical: boot from CD/DVD/BD drive

                 * setup: Boot into setup utility

                 * default: remove any IPMI directed boot device request

          * persist  --  If true, ask that system firmware use this device
            beyond next boot.  Be aware many systems do not honor this

          * uefiboot -- If true, request UEFI boot  explicitly.   Strictly
            speaking, the spec suggests that if not set, the system should
            BIOS boot and offers no "don't  care"  option.   In  practice,
            this  flag  not  being  set does not preclude UEFI boot on any
            system I've encountered.

          * kwargs -- .INDENT 2.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   Returns
          dict or True -- If callback is not provided, the response
             salt-call ipmi.set_bootdev bootdev=network persist=True

   salt.modules.ipmi.set_channel_access(channel=14,
   access_update_mode='non_volatile',  alerting=False, per_msg_auth=False,
   user_level_auth=False,                            access_mode='always',
   privilege_update_mode='non_volatile',  privilege_level='administrator',
   **kwargs)
          Set channel access

          Parameters

                 * channel -- number [1:7]

                 * access_update_mode -- .INDENT 2.0

                 * 'dont_change'  = don't set or change Channel Access

                 * 'non_volatile' = set non-volatile Channel Access

                 * 'volatile'      =  set  volatile  (active)  setting  of
                   Channel Access

          * alerting -- .INDENT 2.0

          PEF Alerting Enable/Disable

                 * True  = enable PEF Alerting

                 * False = disable PEF Alerting on this channel

                 (Alert  Immediate  command  can still be used to generate
                 alerts)

   * per_msg_auth -- .INDENT 2.0

   Per-message Authentication

          * True  = enable

          * False = disable  Per-message  Authentication.  [Authentication
            required   to  activate  any  session  on  this  channel,  but
            authentication  not  used  on  subsequent  packets   for   the
            session.]

   * user_level_auth -- .INDENT 2.0

   User Level Authentication Enable/Disable.

          * True   =  enable  User  Level  Authentication.  All User Level
            commands are to be authenticated per the  Authentication  Type
            that was negotiated when the session was activated.

          * False  =  disable  User Level Authentication. Allow User Level
            commands to be executed without being authenticated.   If  the
            option   to  disable  User  Level  Command  authentication  is
            accepted, the BMC will accept packets with Authentication Type
            set to None if they contain user level commands.  For outgoing
            packets,   the   BMC   returns   responses   with   the   same
            Authentication Type that was used for the request.

   * access_mode --

     Access  Mode  for  IPMI  messaging  (PEF Alerting is enabled/disabled
     separately from IPMI messaging)

        * disabled = disabled for IPMI messaging

        * pre_boot = pre-boot only channel only available when  system  is
          in a powered down state or in BIOS prior to start of boot.

        * always    =  channel always available regardless of system mode.
          BIOS typically dedicates the serial connection to the BMC.

        * shared   = same as always available, but BIOS  typically  leaves
          the serial port available for software use.

   * privilege_update_mode --

     Channel Privilege Level Limit.  This value sets the maximum privilege
     level that can be accepted on the specified channel.

        * dont_change  = don't set or change channel Privilege Level Limit

        * non_volatile = non-volatile Privilege Level Limit according

        * volatile     = volatile setting of Privilege Level Limit

   * privilege_level -- .INDENT 2.0

   Channel Privilege Level Limit

          * reserved      = unused

          * callback

          * user

          * operator

          * administrator

          * proprietary   = used by OEM

   * kwargs -- .INDENT 2.0

   * api_host=127.0.0.1

   * api_user=admin

   * api_pass=example

   * api_port=623

   * api_kg=None
             salt-call ipmi.set_channel_access privilege_level='administrator'

   salt.modules.ipmi.set_identify(on=True, duration=600, **kwargs)
          Request identify light

          Request the identify light to turn off, on for a duration, or on
          indefinitely.  Other than error exceptions,

          Parameters

                 * on -- Set to True to force on or False to force off

                 * duration  --  Set  if  wanting to request turn on for a
                   duration in seconds, None = indefinitely.

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   CLI Examples:

             salt-call ipmi.set_identify

   salt.modules.ipmi.set_power(state='power_on', wait=True, **kwargs)
          Request power state change

          Parameters

                 * name -- .INDENT 2.0

                 * power_on -- system turn on

                 * power_off -- system turn off (without waiting for OS)

                 * shutdown -- request OS proper shutdown

                 * reset -- reset (without waiting for OS)

                 * boot -- If system is off, then 'on', else 'reset'

          * ensure -- If (bool True), do not return until system  actually
            completes  requested  state  change  for  300  seconds.   If a
            non-zero (int), adjust the wait time to the  requested  number
            of seconds

          * kwargs -- .INDENT 2.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   Returns
     dict -- A dict describing the response retrieved
             salt-call ipmi.set_power state=shutdown wait=True

   salt.modules.ipmi.set_user_access(uid,    channel=14,    callback=True,
   link_auth=True,     ipmi_msg=True,     privilege_level='administrator',
   **kwargs)
          Set user access

          Parameters

                 * uid -- user number [1:16]

                 * channel -- number [1:7]

                 * callback -- .INDENT 2.0

                 User Restricted to Callback

                        * False  =  User  Privilege Limit is determined by
                          the User Privilege Limit parameter,  below,  for
                          both callback and non-callback connections.

                        * True   =  User  Privilege Limit is determined by
                          the User Privilege Limit parameter for  callback
                          connections, but is restricted to Callback level
                          for non-callback connections. Thus, a  user  can
                          only  initiate a Callback when they 'call in' to
                          the BMC, but once the  callback  connection  has
                          been  made, the user could potentially establish
                          a session as an Operator.

          * link_auth -- User Link authentication enable/disable (used  to
            enable  whether this user's name and password information will
            be used for link authentication, e.g. PPP CHAP) for the  given
            channel.  Link  authentication  itself is a global setting for
            the channel  and  is  enabled/disabled  via  the  serial/modem
            configuration parameters.

          * ipmi_msg  --  User  IPMI  Messaging:  (used  to enable/disable
            whether this user's name and password information will be used
            for  IPMI  Messaging. In this case, 'IPMI Messaging' refers to
            the ability to execute generic  IPMI  commands  that  are  not
            associated  with  a  particular  payload type. For example, if
            IPMI Messaging is disabled  for  a  user,  but  that  user  is
            enabled  for  activating  the  SOL  payload  type,  then  IPMI
            commands associated with SOL and session management,  such  as
            Get   SOL  Configuration  Parameters  and  Close  Session  are
            available, but generic IPMI commands such as Get SEL Time  are
            unavailable.)

          * privilege_level --

            User  Privilege Limit. (Determines the maximum privilege level
            that the user  is  allowed  to  switch  to  on  the  specified
            channel.)

               * callback

               * user

               * operator

               * administrator

               * proprietary

               * no_access

          * kwargs -- .INDENT 2.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None
             salt-call ipmi.set_user_access uid=2 privilege_level='operator'

   salt.modules.ipmi.set_user_name(uid, name, **kwargs)
          Set user name

          Parameters

                 * uid -- user number [1:16]

                 * name -- username (limit of 16bytes)

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   CLI Examples:

             salt-call ipmi.set_user_name uid=2 name='steverweber'

   salt.modules.ipmi.set_user_password(uid,           mode='set_password',
   password=None, **kwargs)
          Set user password and (modes)

          Parameters

                 * uid -- id number of user.  see: get_names_uid()['name']

                 * mode -- .INDENT 2.0

                 * disable       = disable user connections

                 * enable        = enable user connections

                 * set_password  = set or ensure password

                 * test_password = test password is correct

          * password -- max 16 char string (optional when mode is [disable
            or enable])

          * kwargs -- .INDENT 2.0

          * api_host=127.0.0.1

          * api_user=admin

          * api_pass=example

          * api_port=623

          * api_kg=None

   Returns
     True  on  success  when  mode  =  test_password,  return False on bad
     password
             salt-call ipmi.set_user_password api_host=127.0.0.1 api_user=admin api_pass=pass
                                              uid=1 password=newPass
             salt-call ipmi.set_user_password uid=1 mode=enable

   salt.modules.ipmi.user_delete(uid, channel=14, **kwargs)
          Delete user (helper)

          Parameters

                 * uid -- user number [1:16]

                 * channel -- number [1:7]

                 * kwargs -- .INDENT 2.0

                 * api_host=127.0.0.1

                 * api_user=admin

                 * api_pass=example

                 * api_port=623

                 * api_kg=None

   CLI Examples:

             salt-call ipmi.user_delete uid=2

   salt.modules.ipset
   Support for ipset

   salt.modules.ipset.add(set=None, entry=None, family='ipv4', **kwargs)
          Append an entry to the specified set.

          CLI Example:

             salt '*' ipset.add setname 192.168.1.26

             salt '*' ipset.add setname 192.168.0.3,AA:BB:CC:DD:EE:FF

   salt.modules.ipset.check(set=None, entry=None, family='ipv4')
          Check that an entry exists in the specified set.

          set    The ipset name

          entry  An entry in the ipset.  This parameter can be a single IP
                 address,  a  range  of  IP  addresses, or a subnet block.
                 Example:

                    192.168.0.1
                    192.168.0.2-192.168.0.19
                    192.168.0.0/25

          family IP protocol version: ipv4 or ipv6

          CLI Example:

             salt '*' ipset.check setname '192.168.0.1 comment "Hello"'

   salt.modules.ipset.check_set(set=None, family='ipv4')
          Check that given ipset set exists.

          New in version 2014.7.0.

          CLI Example:

             salt '*' ipset.check_set setname

   salt.modules.ipset.delete(set=None,     entry=None,      family='ipv4',
   **kwargs)
          Delete an entry from the specified set.

          CLI Example:

             salt '*' ipset.delete setname 192.168.0.3,AA:BB:CC:DD:EE:FF

   salt.modules.ipset.delete_set(set=None, family='ipv4')
          New in version 2014.7.0.

          Delete ipset set.

          CLI Example:

             salt '*' ipset.delete_set custom_set

             IPv6:
             salt '*' ipset.delete_set custom_set family=ipv6

   salt.modules.ipset.flush(set=None, family='ipv4')
          Flush entries in the specified set, Flush all sets if set is not
          specified.

          CLI Example:

             salt '*' ipset.flush

             salt '*' ipset.flush set

             IPv6:
             salt '*' ipset.flush

             salt '*' ipset.flush set

   salt.modules.ipset.list_sets(family='ipv4')
          New in version 2014.7.0.

          List all ipset sets.

          CLI Example:

             salt '*' ipset.list_sets

   salt.modules.ipset.new_set(set=None,   set_type=None,    family='ipv4',
   comment=False, **kwargs)
          New in version 2014.7.0.

          Create new custom set

          CLI Example:

             salt '*' ipset.new_set custom_set list:set

             salt '*' ipset.new_set custom_set list:set comment=True

             IPv6:
             salt '*' ipset.new_set custom_set list:set family=ipv6

   salt.modules.ipset.rename_set(set=None, new_set=None, family='ipv4')
          New in version 2014.7.0.

          Delete ipset set.

          CLI Example:

             salt '*' ipset.rename_set custom_set new_set=new_set_name

             IPv6:
             salt '*' ipset.rename_set custom_set new_set=new_set_name family=ipv6

   salt.modules.ipset.test(set=None, entry=None, family='ipv4', **kwargs)
          Test if an entry is in the specified set.

          CLI Example:

             salt '*' ipset.test setname 192.168.0.2

             IPv6:
             salt '*' ipset.test setname fd81:fc56:9ac7::/48

   salt.modules.ipset.version()
          Return version from ipset --version

          CLI Example:

             salt '*' ipset.version

   salt.modules.iptables
   Support for iptables

   salt.modules.iptables.append(table='filter',   chain=None,   rule=None,
   family='ipv4')
          Append a rule to the specified table/chain.

          This function accepts a rule  in  a  standard  iptables  command
          format,
                 starting  with  the chain. Trying to force users to adapt
                 to a new method of creating rules would be irritating  at
                 best, and we already have a parser that can handle it.

          CLI Example:

             salt '*' iptables.append filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'

             IPv6:
             salt '*' iptables.append filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT' \
                 family=ipv6

   salt.modules.iptables.build_rule(table='filter',            chain=None,
   command=None, position='', full=None, family='ipv4', **kwargs)
          Build a well-formatted iptables rule based on  kwargs.  A  table
          and chain are not required, unless full is True.

          If  full  is  True,  then table, chain and command are required.
          command may be specified as either a short  option  ('I')  or  a
          long  option  (--insert). This will return the iptables command,
          exactly as it would be used from the command line.

          If a position is  required  (as  with  -I  or  -D),  it  may  be
          specified as position. This will only be useful if full is True.

          If  connstate  is passed in, it will automatically be changed to
          state.

          To pass in jump options that doesn't take arguments, pass in  an
          empty string.

          CLI Examples:

             salt '*' iptables.build_rule match=state \
                 connstate=RELATED,ESTABLISHED jump=ACCEPT

             salt '*' iptables.build_rule filter INPUT command=I position=3 \
                 full=True match=state state=RELATED,ESTABLISHED jump=ACCEPT

             salt '*' iptables.build_rule filter INPUT command=A \
                 full=True match=state state=RELATED,ESTABLISHED \
                 source='127.0.0.1' jump=ACCEPT

             .. Invert Rules
             salt '*' iptables.build_rule filter INPUT command=A \
                 full=True match=state state=RELATED,ESTABLISHED \
                 source='! 127.0.0.1' jump=ACCEPT

             salt '*' iptables.build_rule filter INPUT command=A \
                 full=True match=state state=RELATED,ESTABLISHED \
                 destination='not 127.0.0.1' jump=ACCEPT

             IPv6:
             salt '*' iptables.build_rule match=state \
                 connstate=RELATED,ESTABLISHED jump=ACCEPT \
                 family=ipv6
             salt '*' iptables.build_rule filter INPUT command=I position=3 \
                 full=True match=state state=RELATED,ESTABLISHED jump=ACCEPT \
                 family=ipv6

   salt.modules.iptables.check(table='filter',    chain=None,   rule=None,
   family='ipv4')
          Check for the existence of a rule in the table and chain

          This function accepts a rule  in  a  standard  iptables  command
          format,
                 starting  with  the chain. Trying to force users to adapt
                 to a new method of creating rules would be irritating  at
                 best, and we already have a parser that can handle it.

          CLI Example:

             salt '*' iptables.check filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'

             IPv6:
             salt '*' iptables.check filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT' \
                 family=ipv6

   salt.modules.iptables.check_chain(table='filter',           chain=None,
   family='ipv4')
          New in version 2014.1.0.

          Check for the existence of a chain in the table

          CLI Example:

             salt '*' iptables.check_chain filter INPUT

             IPv6:
             salt '*' iptables.check_chain filter INPUT family=ipv6

   salt.modules.iptables.delete(table,     chain=None,      position=None,
   rule=None, family='ipv4')

          Delete  a rule from the specified table/chain, specifying either
          the rule
                 in its entirety, or the rule's position in the chain.

          This function accepts a rule  in  a  standard  iptables  command
          format,
                 starting  with  the chain. Trying to force users to adapt
                 to a new method of creating rules would be irritating  at
                 best, and we already have a parser that can handle it.

          CLI Examples:

             salt '*' iptables.delete filter INPUT position=3
             salt '*' iptables.delete filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'

             IPv6:
             salt '*' iptables.delete filter INPUT position=3 family=ipv6
             salt '*' iptables.delete filter INPUT \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT' \
                 family=ipv6

   salt.modules.iptables.delete_chain(table='filter',          chain=None,
   family='ipv4')
          New in version 2014.1.0.

          Delete custom chain to the specified table.

          CLI Example:

             salt '*' iptables.delete_chain filter CUSTOM_CHAIN

             IPv6:
             salt '*' iptables.delete_chain filter CUSTOM_CHAIN family=ipv6

   salt.modules.iptables.flush(table='filter', chain='', family='ipv4')
          Flush the chain in the specified table, flush all chains in  the
          specified table if not specified chain.

          CLI Example:

             salt '*' iptables.flush filter INPUT

             IPv6:
             salt '*' iptables.flush filter INPUT family=ipv6

   salt.modules.iptables.get_policy(table='filter',            chain=None,
   family='ipv4')
          Return the current policy for the specified table/chain

          CLI Example:

             salt '*' iptables.get_policy filter INPUT

             IPv6:
             salt '*' iptables.get_policy filter INPUT family=ipv6

   salt.modules.iptables.get_rules(family='ipv4')
          Return a data structure of the current, in-memory rules

          CLI Example:

             salt '*' iptables.get_rules

             IPv6:
             salt '*' iptables.get_rules family=ipv6

   salt.modules.iptables.get_saved_policy(table='filter',      chain=None,
   conf_file=None, family='ipv4')
          Return the current policy for the specified table/chain

          CLI Examples:

             salt '*' iptables.get_saved_policy filter INPUT
             salt '*' iptables.get_saved_policy filter INPUT \
                 conf_file=/etc/iptables.saved

             IPv6:
             salt '*' iptables.get_saved_policy filter INPUT family=ipv6
             salt '*' iptables.get_saved_policy filter INPUT \
                 conf_file=/etc/iptables.saved family=ipv6

   salt.modules.iptables.get_saved_rules(conf_file=None, family='ipv4')
          Return a data structure of the rules in the conf file

          CLI Example:

             salt '*' iptables.get_saved_rules

             IPv6:
             salt '*' iptables.get_saved_rules family=ipv6

   salt.modules.iptables.insert(table='filter', chain=None, position=None,
   rule=None, family='ipv4')
          Insert a rule into the specified table/chain, at  the  specified
          position.

          This  function  accepts  a  rule  in a standard iptables command
          format,
                 starting with the chain. Trying to force users  to  adapt
                 to  a new method of creating rules would be irritating at
                 best, and we already have a parser that can handle it.

          If the position specified is a negative number, then the  insert
          will be
                 performed   counting  from  the  end  of  the  list.  For
                 instance, a position of -1 will insert the  rule  as  the
                 second  to  last  rule.  To  insert  a  rule  in the last
                 position, use the append function instead.

          CLI Examples:

             salt '*' iptables.insert filter INPUT position=3 \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'

             IPv6:
             salt '*' iptables.insert filter INPUT position=3 \
                 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT' \
                 family=ipv6

   salt.modules.iptables.new_chain(table='filter',             chain=None,
   family='ipv4')
          New in version 2014.1.0.

          Create new custom chain to the specified table.

          CLI Example:

             salt '*' iptables.new_chain filter CUSTOM_CHAIN

             IPv6:
             salt '*' iptables.new_chain filter CUSTOM_CHAIN family=ipv6

   salt.modules.iptables.save(filename=None, family='ipv4')
          Save the current in-memory rules to disk

          CLI Example:

             salt '*' iptables.save /etc/sysconfig/iptables

             IPv6:
             salt '*' iptables.save /etc/sysconfig/iptables family=ipv6

   salt.modules.iptables.set_policy(table='filter',            chain=None,
   policy=None, family='ipv4')
          Set the current policy for the specified table/chain

          CLI Example:

             salt '*' iptables.set_policy filter INPUT ACCEPT

             IPv6:
             salt '*' iptables.set_policy filter INPUT ACCEPT family=ipv6

   salt.modules.iptables.version(family='ipv4')
          Return version from iptables --version

          CLI Example:

             salt '*' iptables.version

             IPv6:
             salt '*' iptables.version family=ipv6

   salt.modules.iwtools module
   Support for Wireless Tools for Linux

   salt.modules.iwtools.list_interfaces(style=None)
          List all of the wireless interfaces

          CLI Example:
             salt minion iwtools.list_interfaces

   salt.modules.iwtools.scan(iface, style=None)
          List networks on a wireless interface

          CLI Examples:
             salt minion  iwtools.scan  wlp3s0  salt  minion  iwtools.scan
             wlp3s0 list

   salt.modules.iwtools.set_mode(iface, mode)
          List networks on a wireless interface

          CLI Example:
             salt minion iwtools.set_mode wlp3s0 Managed

   salt.modules.jboss7
   Module for managing JBoss AS 7 through the CLI interface.

   New in version 2015.5.0.

   In  order  to  run  each  function,  jboss_config  dictionary  with the
   following properties must be passed:

          * cli_path:  the  path  to  jboss-cli   script,   for   example:
            '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'

          * controller:  the  IP  address  and  port  of  controller,  for
            example: 10.11.12.13:9999

          * cli_user: username to connect to jboss administration  console
            if necessary

          * cli_password:  password  to  connect  to  jboss administration
            console if necessary

   Example:

      jboss_config:
         cli_path: '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'
         controller: 10.11.12.13:9999
         cli_user: 'jbossadm'
         cli_password: 'jbossadm'

   salt.modules.jboss7.create_datasource(jboss_config,               name,
   datasource_properties, profile=None)
          Create datasource in running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          name   Datasource name

          datasource_properties

                 A dictionary of datasource properties to be created:

                        * driver-name: mysql

                        * connection-url:                               '
                          jdbc:mysql://localhost:3306/sampleDatabase'

                        * jndi-name: 'java:jboss/datasources/sampleDS'

                        * user-name: sampleuser

                        * password: secret

                        * min-pool-size: 3

                        * use-java-context: True

          profile
                 The profile name (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.create_datasource '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' 'my_datasource' '{"driver-name": "mysql", "connection-url": "jdbc:mysql://localhost:3306/sampleDatabase", "jndi-name": "java:jboss/datasources/sampleDS", "user-name": "sampleuser", "password": "secret", "min-pool-size": 3, "use-java-context": True}'

   salt.modules.jboss7.create_simple_binding(jboss_config,   binding_name,
   value, profile=None)
          Create a simple jndi binding in the running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          binding_name
                 Binding name to be created

          value  Binding value

          profile
                 The profile name (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.create_simple_binding \
                     '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", \
                     "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' \
                     my_binding_name my_binding_value

   salt.modules.jboss7.deploy(jboss_config, source_file)
          Deploy the application on the jboss instance from the local file
          system where minion is running.

          jboss_config
                 Configuration dictionary with properties specified above.

          source_file
                 Source file to deploy from

          CLI Example:

             salt '*' jboss7.deploy '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' /opt/deploy_files/my_deploy

   salt.modules.jboss7.list_deployments(jboss_config)
          List all deployments on the jboss instance

          jboss_config
                    Configuration  dictionary  with  properties  specified
                    above.

                 CLI Example:

                    salt '*' jboss7.list_deployments '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}'

   salt.modules.jboss7.read_datasource(jboss_config, name, profile=None)
          Read datasource properties in the running jboss instance.

          jboss_config
                 Configuration dictionary with properties specified above.

          name   Datasource name

          profile
                 Profile name (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.read_datasource '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}'

   salt.modules.jboss7.read_simple_binding(jboss_config,     binding_name,
   profile=None)
          Read jndi binding in the running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          binding_name
                 Binding name to be created

          profile
                 The profile name (JBoss domain mode only)

          CLI Example:

             salt     '*'     jboss7.read_simple_binding     '{"cli_path":
             "integration.modules.sysmod.SysModuleTest.test_valid_docs",
             "controller":  "10.11.12.13:9999",  "cli_user":   "jbossadm",
             "cli_password": "jbossadm"}' my_binding_name

   salt.modules.jboss7.reload(jboss_config, host=None)
          Reload running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          host   The  name  of  the  host.  JBoss  domain  mode only - and
                 required if running in domain mode.  The host name is the
                 "name" attribute of the "host" element in host.xml

          CLI Example:

             salt '*' jboss7.reload '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}'

   salt.modules.jboss7.remove_datasource(jboss_config, name, profile=None)
          Remove an existing datasource from the running jboss instance.

          jboss_config
                 Configuration dictionary with properties specified above.

          name   Datasource name

          profile
                 The profile (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.remove_datasource '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' my_datasource_name

   salt.modules.jboss7.status(jboss_config, host=None, server_config=None)
          Get status of running jboss instance.

          jboss_config
                 Configuration dictionary with properties specified above.

          host   The  name  of  the  host.  JBoss  domain  mode only - and
                 required if running in domain mode.  The host name is the
                 "name" attribute of the "host" element in host.xml

          server_config
                 The  name  of the Server Configuration. JBoss Domain mode
                 only - and required if running in domain mode.

          CLI Example:

             salt '*' jboss7.status '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}'

   salt.modules.jboss7.stop_server(jboss_config, host=None)
          Stop running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          host   The name of the  host.  JBoss  domain  mode  only  -  and
                 required if running in domain mode.  The host name is the
                 "name" attribute of the "host" element in host.xml

          CLI Example:

             salt '*' jboss7.stop_server '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}'

   salt.modules.jboss7.undeploy(jboss_config, deployment)
          Undeploy the application from jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          deployment
                 Deployment name to undeploy

          CLI Example:

             salt '*' jboss7.undeploy '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' my_deployment

   salt.modules.jboss7.update_datasource(jboss_config,               name,
   new_properties, profile=None)
          Update an existing datasource in running jboss instance.  If the
          property doesn't exist if will be created, if it does,  it  will
          be updated with the new value

          jboss_config
                 Configuration dictionary with properties specified above.

          name   Datasource name

          new_properties

                 A  dictionary of datasource properties to be updated. For
                 example:

                        * driver-name: mysql

                        * connection-url:                               '
                          jdbc:mysql://localhost:3306/sampleDatabase'

                        * jndi-name: 'java:jboss/datasources/sampleDS'

                        * user-name: sampleuser

                        * password: secret

                        * min-pool-size: 3

                        * use-java-context: True

          profile
                 The profile name (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.update_datasource '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' 'my_datasource' '{"driver-name": "mysql", "connection-url": "jdbc:mysql://localhost:3306/sampleDatabase", "jndi-name": "java:jboss/datasources/sampleDS", "user-name": "sampleuser", "password": "secret", "min-pool-size": 3, "use-java-context": True}'

   salt.modules.jboss7.update_simple_binding(jboss_config,   binding_name,
   value, profile=None)
          Update the simple jndi binding in the running jboss instance

          jboss_config
                 Configuration dictionary with properties specified above.

          binding_name
                 Binding name to be updated

          value  New binding value

          profile
                 The profile name (JBoss domain mode only)

          CLI Example:

             salt '*' jboss7.update_simple_binding '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' my_binding_name my_binding_value

   salt.modules.jboss7_cli
   Module for low-level interaction with JbossAS7 through CLI.

   This module exposes two  ways  of  interaction  with  the  CLI,  either
   through commands or operations.

   NOTE:
      Following             JBoss             documentation             (
      https://developer.jboss.org/wiki/CommandLineInterface):  "Operations
      are  considered  a  low level but comprehensive way to manage the AS
      controller, i.e. if it can't be done with  operations  it  can't  be
      done  in  any  other  way.   Commands,  on  the other hand, are more
      user-friendly in syntax, although most of them still translate  into
      operation  requests  and  some  of  them  even  into a few composite
      operation requests, i.e.  commands  also  simplify  some  management
      operations from the user's point of view."

   The  difference  between  calling a command or operation is in handling
   the result.  Commands  return  a  zero  return  code  if  operation  is
   successful  or  return  non-zero  return  code  and  print  an error to
   standard output in plain text, in case of an error.

   Operations return a json-like structure, that contain more  information
   about  the  result.   In case of a failure, they also return a specific
   return code. This module parses the  output  from  the  operations  and
   returns  it  as  a  dictionary so that an execution of an operation can
   then be verified against specific errors.

   In order  to  run  each  function,  jboss_config  dictionary  with  the
   following properties must be passed:

          * cli_path:   the   path   to  jboss-cli  script,  for  example:
            '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'

          * controller:  the  IP  address  and  port  of  controller,  for
            example: 10.11.12.13:9999

          * cli_user:  username to connect to jboss administration console
            if necessary

          * cli_password: password  to  connect  to  jboss  administration
            console if necessary

   Example:

      jboss_config:
         cli_path: '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'
         controller: 10.11.12.13:9999
         cli_user: 'jbossadm'
         cli_password: 'jbossadm'

   salt.modules.jboss7_cli.run_command(jboss_config,              command,
   fail_on_error=True)
          Execute  a  command  against  jboss  instance  through  the  CLI
          interface.

          jboss_config
                 Configuration dictionary with properties specified above.

          command
                 Command to execute against jboss instance

          fail_on_error (default=True)
                 Is  true,  raise  CommandExecutionException  exception if
                 execution fails.  If false,  'success'  property  of  the
                 returned dictionary is set to False

          CLI Example:

             salt '*' jboss7_cli.run_command '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' my_command

   salt.modules.jboss7_cli.run_operation(jboss_config,          operation,
   fail_on_error=True, retries=1)
          Execute an operation against  jboss  instance  through  the  CLI
          interface.

          jboss_config
                 Configuration dictionary with properties specified above.

          operation
                 An operation to execute against jboss instance

          fail_on_error (default=True)
                 Is  true,  raise  CommandExecutionException  exception if
                 execution fails.  If false,  'success'  property  of  the
                 returned dictionary is set to False

          retries:
                 Number  of  retries  in  case  of  "JBAS012144: Could not
                 connect to remote" error.

          CLI Example:

             salt '*' jboss7_cli.run_operation '{"cli_path": "integration.modules.sysmod.SysModuleTest.test_valid_docs", "controller": "10.11.12.13:9999", "cli_user": "jbossadm", "cli_password": "jbossadm"}' my_operation

   salt.modules.jenkins module
   Module for controlling Jenkins

   New in version 2016.3.0.

   configuration
          This module can be used by either passing an api key and version
          directly or by specifying both in a configuration profile in the
          salt master/minion config.

          For example:

             jenkins:
               api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.jenkins.build_job(name=None, parameters=None)
          Initiate a build for the provided job.

          Parameters

                 * name -- The name of the job is check if it exists.

                 * parameters -- Parameters to send to the job.

          Returns
                 True is successful, otherwise raise an exception.

          CLI Example:

             salt '*' jenkins.build_job jobname

   salt.modules.jenkins.create_job(name=None,             config_xml=None,
   saltenv='base')
          Return the configuration file.

          Parameters

                 * name -- The name of the job is check if it exists.

                 * config_xml  --  The configuration file to use to create
                   the job.

                 * saltenv -- The environment to look for the file in.

          Returns
                 The configuration file used for the job.

          CLI Example:

             salt '*' jenkins.create_job jobname

             salt '*' jenkins.create_job jobname config_xml='salt://jenkins/config.xml'

   salt.modules.jenkins.delete_job(name=None)
          Return true is job is deleted successfully.

          Parameters
                 name -- The name of the job to delete.

          Returns
                 Return true if job is deleted successfully.

          CLI Example:

             salt '*' jenkins.delete_job jobname

   salt.modules.jenkins.disable_job(name=None)
          Return true is job is disabled successfully.

          Parameters
                 name -- The name of the job to disable.

          Returns
                 Return true if job is disabled successfully.

          CLI Example:

             salt '*' jenkins.disable_job jobname

   salt.modules.jenkins.enable_job(name=None)
          Return true is job is enabled successfully.

          Parameters
                 name -- The name of the job to enable.

          Returns
                 Return true if job is enabled successfully.

          CLI Example:

             salt '*' jenkins.enable_job jobname

   salt.modules.jenkins.get_job_config(name=None)
          Return the current job configuration for the provided job.

          Parameters
                 name -- The name of the job to return  the  configuration
                 for.

          Returns
                 The configuration for the job specified.

          CLI Example:

             salt '*' jenkins.get_job_config jobname

   salt.modules.jenkins.get_job_info(name=None)
          Return information about the Jenkins job.

          Parameters
                 name -- The name of the job is check if it exists.

          Returns
                 Information about the Jenkins job.

          CLI Example:

             salt '*' jenkins.get_job_info jobname

   salt.modules.jenkins.get_jobs()
          Return the currently configured jobs.

          Returns
                 The currently configured jobs.

          CLI Example:

             salt '*' jenkins.get_jobs

   salt.modules.jenkins.get_version()
          Return version of Jenkins

          Returns
                 The version of Jenkins

          CLI Example:

             salt '*' jenkins.get_version

   salt.modules.jenkins.job_exists(name=None)
          Check whether the job exists in configured Jenkins jobs.

          Parameters
                 name -- The name of the job is check if it exists.

          Returns
                 True if job exists, False if job does not exist.

          CLI Example:

             salt '*' jenkins.job_exists jobname

   salt.modules.jenkins.job_status(name=None)
          Return the current status, enabled or disabled, of the job.

          Parameters
                 name -- The name of the job to return status for

          Returns
                 Return true if enabled or false if disabled.

          CLI Example:

             salt '*' jenkins.job_status jobname

   salt.modules.jenkins.plugin_installed(name)
          New in version 2016.11.0.

          Return if the plugin is installed for the provided plugin name.

          Parameters
                 name   --   The   name   of   the  parameter  to  confirm
                 installation.

          Returns
                 True if plugin exists, False if plugin does not exist.

          CLI Example:

             salt '*' jenkins.plugin_installed pluginName

   salt.modules.jenkins.update_job(name=None,             config_xml=None,
   saltenv='base')
          Return the updated configuration file.

          Parameters

                 * name -- The name of the job is check if it exists.

                 * config_xml  --  The configuration file to use to create
                   the job.

                 * saltenv -- The environment to look for the file in.

          Returns
                 The configuration file used for the job.

          CLI Example:

             salt '*' jenkins.update_job jobname

             salt '*' jenkins.update_job jobname config_xml='salt://jenkins/config.xml'

   salt.modules.junos
   Module for interfacing to Junos devices.

   salt.modules.junos.cli(command=None)
          Executes the CLI commands and reuturns the text output.

          Usage:

             salt 'device_name' junos.cli 'show version'

          Options:

                 * command: The command that need to be executed on  Junos
                   CLI.

   salt.modules.junos.commit()
          To commit the changes loaded in the candidate configuration.

          Usage:

             salt 'device_name' junos.commit

   salt.modules.junos.diff()
          Gives  the  difference  between  the  candidate  and the current
          configuration.

          Usage:

             salt 'device_name' junos.diff

   salt.modules.junos.facts()
          Displays the facts gathered during the connection.

          Usage:

             salt 'device_name' junos.facts

   salt.modules.junos.facts_refresh()
          Reload the facts  dictionary  from  the  device.   Usually  only
          needed  if  the  device  configuration  is changed by some other
          actor.

          Usage:

             salt 'device_name' junos.facts_refresh

   salt.modules.junos.file_copy(src=None, dest=None)
          Copies the file from the local device to the junos device.

          Usage:

             salt 'device_name' junos.file_copy /home/m2/info.txt info_copy.txt

          Options

                 * src: The sorce path where the file is kept.

                 * dest: The destination  path  where  the  file  will  be
                   copied.

   salt.modules.junos.install_config(path=None, **kwargs)
          Installs   the  given  configuration  file  into  the  candidate
          configuration.  Commits the changes  if  the  commit  checks  or
          throws an error.

          Usage:

             salt 'device_name' junos.install_config '/home/user/config.set' timeout=300

          Options:

                 * path: Path where the configuration file is present.

                 * kwargs:  keyworded  arguments taken by load fucntion of
                   PyEZ

   salt.modules.junos.install_os(path=None, **kwargs)
          Installs the given image on the device. After  the  installation
          is complete the device is rebooted, if reboot=True is given as a
          keyworded argument.

          Usage:

             salt 'device_name' junos.install_os '/home/user/junos_image.tgz' reboot=True

          Options

                 * path: Path where the image file is present.

                 * kwargs:  keyworded  arguments  to  be  given  such   as
                   timeout, reboot etc

   salt.modules.junos.ping()
          To check the connection with the device

          Usage:

             salt 'device_name' junos.ping

   salt.modules.junos.rollback()
          To rollback the last committed configuration changes

          Usage:

             salt 'device_name' junos.rollback

   salt.modules.junos.rpc(cmd=None,    dest=None,   format='xml',   *args,
   **kwargs)
          This function executes the rpc  provided  as  arguments  on  the
          junos  device.   The returned data can be stored in a file whose
          destination  can  be  specified  with  'dest'  keyword  in   the
          arguments.

          Usage:

             salt 'device' junos.rpc 'get_config' 'text' filter='<configuration><system/></configuration>'

             salt 'device' junos.rpc 'get-interface-information' '/home/user/interface.log' interface_name='lo0' terse=True

          Options:

                 * cmd: the rpc to be executed

                 * dest: destination file where the rpc ouput is dumped

                 * format:  the  format  in  which  the  rpc reply must be
                   stored in file specified in the dest  (used  only  when
                   dest is specified)

                 * args: other arguments as taken by rpc call of PyEZ

                 * kwargs: keyworded arguments taken by rpc call of PyEZ

   salt.modules.junos.set_hostname(hostname=None, commit_change=True)
          To set the name of the device.

          Usage:

             salt 'device_name' junos.set_hostname hostname=salt-device

          Options:

                 * hostname: The name to be set.

                 * commit_change:      Whether      to      commit     the
                   changes.(default=True)

   salt.modules.junos.shutdown(time=0)
          Shuts down the device after the given time.

          Usage:

             salt 'device_name' junos.shutdown 10

          Options:

                 * time: Time in seconds after  which  the  device  should
                   shutdown (default=0)

   salt.modules.junos.zeroize()
          Resets the device to default factory settings

          Usage:

             salt 'device_name' junos.zeroize

   salt.modules.k8s
   Salt module to manage Kubernetes cluster

   New in version 2016.3.0.

   Roadmap:

   * Add creation of K8S objects (pod, rc, service, ...)

   * Add replace of K8S objects (pod, rc, service, ...)

   * Add deletion of K8S objects (pod, rc, service, ...)

   * Add rolling update

   * Add (auto)scalling

   salt.modules.k8s.create_namespace(name, apiserver_url=None)
          New in version 2016.3.0.

          Create  kubernetes  namespace  from  the  name,  similar  to the
          functionality added to kubectl since v.1.2.0:
             kubectl create namespaces namespace-name

          CLI Example:

             salt '*' k8s.create_namespace namespace_name

             salt '*' k8s.create_namespace namespace_name http://kube-master.cluster.local

   salt.modules.k8s.create_secret(namespace,        name,         sources,
   apiserver_url=None, force=False, update=False, saltenv='base')
          New in version 2016.3.0.

          Create  k8s  secrets  in  the defined namespace from the list of
          files

          CLI Example:

             salt '*' k8s.create_secret namespace_name secret_name sources

             salt '*' k8s.create_secret namespace_name secret_name sources
             http://kube-master.cluster.local

          sources are either dictionary of {name: path, name1: path} pairs
          or array of strings defining paths.

          Example of paths array:

          ['/full/path/filename',            "file:///full/path/filename",
          "salt://secret/storage/file.txt",
          "http://user:[email protected]/secret-file.json"]

          Example of dictionaries:

          {"nameit":              '/full/path/fiename',             name2:
          "salt://secret/storage/file.txt"}

          optional parameters accepted:

          update=[false] default value is  false  if  set  to  false,  and
          secret  is  already  present  on  the  cluster - warning will be
          returned and no changes to the secret will be done.  In case  it
          is  set  to  "true"  and  secret is present but data is differ -
          secret will be updated.

          force=[true] default value is true if the to False, secret  will
          not  be created in case one of the files is not valid kubernetes
          secret. e.g. capital letters in secret name or _ in  case  force
          is  set  to True, wrong files will be skipped but secret will be
          created any way.

          saltenv=['base'] default value is base in case 'salt://' path is
          used, this parameter can change the visibility of files

   salt.modules.k8s.delete_secret(namespace,   name,   apiserver_url=None,
   force=True)
          New in version 2016.3.0.

          Delete kubernetes secret in the defined namespace. Namespace  is
          the mandatory parameter as well as name.

          CLI Example:

             salt '*' k8s.delete_secret namespace_name secret_name

             salt '*' k8s.delete_secret namespace_name secret_name http://kube-master.cluster.local

   salt.modules.k8s.get_labels(node=None, apiserver_url=None)
          New in version 2016.3.0.

          Get labels from the current node

          CLI Example:

             salt '*' k8s.get_labels
             salt '*' k8s.get_labels kube-node.cluster.local http://kube-master.cluster.local

   salt.modules.k8s.get_namespaces(namespace='', apiserver_url=None)
          New in version 2016.3.0.

          Get one or all kubernetes namespaces.

          If  namespace  parameter  is  omitted,  all  namespaces  will be
          returned back to user, similar to following kubectl example:

             kubectl get namespaces -o json

          In case namespace is set by user, the output will be similar  to
          the one from kubectl:

             kubectl get namespaces namespace_name -o json

          CLI Example:

             salt '*' k8s.get_namespaces
             salt '*' k8s.get_namespaces namespace_name http://kube-master.cluster.local

   salt.modules.k8s.get_secrets(namespace,   name='',  apiserver_url=None,
   decode=False, brief=False)
          Get k8s namespaces

          CLI Example:

             salt '*' k8s.get_secrets namespace_name
             salt '*' k8s.get_secrets namespace_name secret_name http://kube-master.cluster.local

   salt.modules.k8s.label_absent(name, node=None, apiserver_url=None)
          New in version 2016.3.0.

          Delete label to the current node

          CLI Example:

             salt '*' k8s.label_absent hw/disktype
             salt '*' k8s.label_absent hw/disktype kube-node.cluster.local http://kube-master.cluster.local

   salt.modules.k8s.label_folder_absent(name,                   node=None,
   apiserver_url=None)
          New in version 2016.3.0.

          Delete label folder to the current node

          CLI Example:

             salt '*' k8s.label_folder_absent hw
             salt '*' k8s.label_folder_absent hw/ kube-node.cluster.local http://kube-master.cluster.local

   salt.modules.k8s.label_present(name,          value,         node=None,
   apiserver_url=None)
          New in version 2016.3.0.

          Set label to the current node

          CLI Example:

             salt '*' k8s.label_present hw/disktype ssd

             salt '*' k8s.label_present hw/disktype ssd kube-node.cluster.local http://kube-master.cluster.local

   salt.modules.k8s.update_secret(namespace,        name,         sources,
   apiserver_url=None, force=True, saltenv='base')
          New in version 2016.3.0.

          alias to k8s.create_secret with update=true

          CLI Example:

             salt '*' k8s.update_secret namespace_name secret_name sources [apiserver_url] [force=true] [update=false] [saltenv='base']

          sources are either dictionary of {name: path, name1: path} pairs
          or array of strings defining paths.

          Example of paths array:

          ['/full/path/filename',            "file:///full/path/filename",
          "salt://secret/storage/file.txt",
          "http://user:[email protected]/secret-file.json"]

          Example of dictionaries:

          {"nameit":             '/full/path/fiename',              name2:
          "salt://secret/storage/file.txt"}

          optional parameters accepted:

          force=[true]  default value is true if the to False, secret will
          not be created in case one of the files is not valid  kubernetes
          secret.  e.g.  capital letters in secret name or _ in case force
          is set to True, wrong files will be skipped but secret  will  be
          created any way.

          saltenv=['base'] default value is base in case 'salt://' path is
          used, this parameter can change the visibility of files

   salt.modules.kapacitor module
   Kapacitor execution module.

   configuration
          This module accepts connection configuration details  either  as
          parameters  or  as configuration settings in /etc/salt/minion on
          the relevant minions:

             kapacitor.host: 'localhost'
             kapacitor.port: 9092

          This data can also be passed into pillar.  Options  passed  into
          opts will overwrite options passed into pillar.

   New in version 2016.11.0.

   salt.modules.kapacitor.define_task(name,                   tick_script,
   task_type='stream', database=None, retention_policy='default')
          Define a task. Serves as both create/update.

          name   Name of the task.

          tick_script
                 Path to the TICK script for the task. Can  be  a  salt://
                 source.

          task_type
                 Task type. Defaults to 'stream'

          database
                 Which  database  to  fetch  data  from. Defaults to None,
                 which will use the default database in InfluxDB.

          retention_policy
                 Which retention policy to fetch data  from.  Defaults  to
                 'default'.

          CLI Example:

             salt '*' kapacitor.define_task cpu salt://kapacitor/cpu.tick database=telegraf

   salt.modules.kapacitor.delete_task(name)
          Delete a kapacitor task.

          name   Name of the task to delete.

          CLI Example:

             salt '*' kapacitor.delete_task cpu

   salt.modules.kapacitor.disable_task(name)
          Disable a kapacitor task.

          name   Name of the task to disable.

          CLI Example:

             salt '*' kapacitor.disable_task cpu

   salt.modules.kapacitor.enable_task(name)
          Enable a kapacitor task.

          name   Name of the task to enable.

          CLI Example:

             salt '*' kapacitor.enable_task cpu

   salt.modules.kapacitor.get_task(name)
          Get a dict of data on a task.

          name   Name of the task to get information about.

          CLI Example:

             salt '*' kapacitor.get_task cpu

   salt.modules.kapacitor.version(*args)
          Get the kapacitor version.

   salt.modules.kerberos
   Manage Kerberos KDC

   configuration
          In  order  to manage your KDC you will need to generate a keytab
          that can authenticate without requiring a password.

      # ktadd -k /root/secure.keytab kadmin/admin kadmin/changepw

   On the KDC minion you will need to add  the  following  to  the  minion
   configuration  file so Salt knows what keytab to use and what principal
   to authenticate as.

      auth_keytab: /root/auth.keytab
      auth_principal: kadmin/admin

   salt.modules.kerberos.create_keytab(name, keytab, enctypes=None)
          Create keytab

          CLI Example:

             salt 'kdc.example.com' host/host1.example.com host1.example.com.keytab

   salt.modules.kerberos.create_principal(name, enctypes=None)
          Create Principal

          CLI Example:

             salt 'kdc.example.com' kerberos.create_principal host/example.com

   salt.modules.kerberos.delete_principal(name)
          Delete Principal

          CLI Example:

             salt 'kdc.example.com' kerberos.delete_principal host/[email protected]

   salt.modules.kerberos.get_policy(name)
          Get policy details

          CLI Example:

             salt 'kdc.example.com' kerberos.get_policy my_policy

   salt.modules.kerberos.get_principal(name)
          Get princial details

          CLI Example:

             salt 'kdc.example.com' kerberos.get_principal root/admin

   salt.modules.kerberos.get_privs()
          Current privileges

          CLI Example:

             salt 'kdc.example.com' kerberos.get_privs

   salt.modules.kerberos.list_policies()
          List policies

          CLI Example:

             salt 'kdc.example.com' kerberos.list_policies

   salt.modules.kerberos.list_principals()
          Get all principals

          CLI Example:

             salt 'kde.example.com' kerberos.list_principals

   salt.modules.key
   Functions to view the minion's public key information

   salt.modules.key.finger()
          Return the minion's public key fingerprint

          CLI Example:

             salt '*' key.finger

   salt.modules.key.finger_master()
          Return the fingerprint of the master's public key on the minion.

          CLI Example:

             salt '*' key.finger_master

   salt.modules.keyboard
   Module for managing keyboards on  supported  POSIX-like  systems  using
   systemd, or such as Redhat, Debian and Gentoo.

   salt.modules.keyboard.get_sys()
          Get current system keyboard setting

          CLI Example:

             salt '*' keyboard.get_sys

   salt.modules.keyboard.get_x()
          Get current X keyboard setting

          CLI Example:

             salt '*' keyboard.get_x

   salt.modules.keyboard.set_sys(layout)
          Set current system keyboard setting

          CLI Example:

             salt '*' keyboard.set_sys dvorak

   salt.modules.keyboard.set_x(layout)
          Set current X keyboard setting

          CLI Example:

             salt '*' keyboard.set_x dvorak

   salt.modules.keystone
   Module for handling openstack keystone calls.

   optdepends

          * keystoneclient Python adapter

   configuration
          This  module  is  not  usable  until the following are specified
          either in a pillar or in the minion's config file:

             keystone.user: admin
             keystone.password: verybadpass
             keystone.tenant: admin
             keystone.tenant_id: f80919baedab48ec8931f200c65a50df
             keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'

          OR (for token based authentication)

             keystone.token: 'ADMIN'
             keystone.endpoint: 'http://127.0.0.1:35357/v2.0'

          If configuration for multiple openstack  accounts  is  required,
          they  can  be  set  up  as different configuration profiles. For
          example:

             openstack1:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.tenant_id: f80919baedab48ec8931f200c65a50df
               keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'

             openstack2:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.tenant_id: f80919baedab48ec8931f200c65a50df
               keystone.auth_url: 'http://127.0.0.2:5000/v2.0/'

          With this configuration in place, any of the keystone  functions
          can  make  use  of  a  configuration  profile  by  declaring  it
          explicitly.  For example:

             salt '*' keystone.tenant_list profile=openstack1

   salt.modules.keystone.api_version(profile=None, **connection_args)
          Returns the API version derived from endpoint's response.

          CLI Example:

             salt '*' keystone.api_version

   salt.modules.keystone.auth(profile=None, **connection_args)
          Set up keystone credentials. Only intended  to  be  used  within
          Keystone-enabled modules.

          CLI Example:

             salt '*' keystone.auth

   salt.modules.keystone.ec2_credentials_create(user_id=None,   name=None,
   tenant_id=None, tenant=None, profile=None, **connection_args)
          Create EC2-compatible credentials for user per tenant

          CLI Examples:

             salt '*' keystone.ec2_credentials_create name=admin tenant=admin

             salt '*' keystone.ec2_credentials_create         user_id=c965f79c4f864eaaa9c3b41904e67082         tenant_id=722787eb540849158668370dc627ec5f

   salt.modules.keystone.ec2_credentials_delete(user_id=None,   name=None,
   access_key=None, profile=None, **connection_args)
          Delete EC2-compatible credentials

          CLI Examples:

             salt '*' keystone.ec2_credentials_delete         860f8c2c38ca4fab989f9bc56a061a64 access_key=5f66d2f24f604b8bb9cd28886106f442

             salt '*' keystone.ec2_credentials_delete name=admin         access_key=5f66d2f24f604b8bb9cd28886106f442

   salt.modules.keystone.ec2_credentials_get(user_id=None,      name=None,
   access=None, profile=None, **connection_args)
          Return ec2_credentials for a user (keystone ec2-credentials-get)

          CLI Examples:

             salt '*' keystone.ec2_credentials_get c965f79c4f864eaaa9c3b41904e67082 access=722787eb540849158668370
             salt '*' keystone.ec2_credentials_get user_id=c965f79c4f864eaaa9c3b41904e67082 access=722787eb540849158668370
             salt '*' keystone.ec2_credentials_get name=nova access=722787eb540849158668370dc627ec5f

   salt.modules.keystone.ec2_credentials_list(user_id=None,     name=None,
   profile=None, **connection_args)
          Return  a  list of ec2_credentials for a specific user (keystone
          ec2-credentials-list)

          CLI Examples:

             salt '*' keystone.ec2_credentials_list 298ce377245c4ec9b70e1c639c89e654
             salt '*' keystone.ec2_credentials_list user_id=298ce377245c4ec9b70e1c639c89e654
             salt '*' keystone.ec2_credentials_list name=jack

   salt.modules.keystone.endpoint_create(service,          publicurl=None,
   internalurl=None,  adminurl=None,  region=None, profile=None, url=None,
   interface=None, **connection_args)
          Create an endpoint for an Openstack service

          CLI Examples:

             salt 'v2' keystone.endpoint_create nova 'http://public/url' 'http://internal/url' 'http://adminurl/url' region

             salt 'v3' keystone.endpoint_create nova url='http://public/url' interface='public'

   salt.modules.keystone.endpoint_delete(service,            profile=None,
   **connection_args)
          Delete endpoints of an Openstack service

          CLI Examples:

             salt '*' keystone.endpoint_delete nova

   salt.modules.keystone.endpoint_get(service,               profile=None,
   **connection_args)
          Return a specific endpoint (keystone endpoint-get)

          CLI Example:

             salt '*' keystone.endpoint_get nova

   salt.modules.keystone.endpoint_list(profile=None, **connection_args)
          Return a list of available endpoints (keystone endpoints-list)

          CLI Example:

             salt '*' keystone.endpoint_list

   salt.modules.keystone.project_create(name,  domain,   description=None,
   enabled=True, profile=None, **connection_args)
          Create  a  keystone  project.   Overrides keystone tenant_create
          form api V2. For keystone api V3.

          New in version 2016.11.0.

          name   The project name, which must be unique within the  owning
                 domain.

          domain The domain name.

          description
                 The project description.

          enabled
                 Enables or disables the project.

          profile
                 Configuration  profile  -  if  configuration for multiple
                 openstack accounts required.

          CLI Examples:

             salt '*' keystone.project_create nova default description='Nova Compute Project'
             salt '*' keystone.project_create test default enabled=False

   salt.modules.keystone.project_delete(project_id=None,        name=None,
   profile=None, **connection_args)
          Delete  a project (keystone project-delete).  Overrides keystone
          tenant-delete form api V2. For keystone api V3 only.

          New in version 2016.11.0.

          project_id
                 The project id.

          name   The project name.

          profile
                 Configuration profile -  if  configuration  for  multiple
                 openstack accounts required.

          CLI Examples:

             salt '*' keystone.project_delete c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.project_delete project_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.project_delete name=demo

   salt.modules.keystone.project_get(project_id=None,           name=None,
   profile=None, **connection_args)
          Return a  specific  projects  (keystone  project-get)  Overrides
          keystone tenant-get form api V2.  For keystone api V3 only.

          New in version 2016.11.0.

          project_id
                 The project id.

          name   The project name.

          profile
                 Configuration  profile  -  if  configuration for multiple
                 openstack accounts required.

          CLI Examples:

             salt '*' keystone.project_get c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.project_get project_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.project_get name=nova

   salt.modules.keystone.project_list(profile=None, **connection_args)
          Return a list of available  projects  (keystone  projects-list).
          Overrides  keystone  tenants-list form api V2.  For keystone api
          V3 only.

          New in version 2016.11.0.

          profile
                 Configuration profile -  if  configuration  for  multiple
                 openstack accounts required.

          CLI Example:

             salt '*' keystone.project_list

   salt.modules.keystone.project_update(project_id=None,        name=None,
   description=None, enabled=None, profile=None, **connection_args)
          Update a  tenant's  information  (keystone  project-update)  The
          following  fields  may  be  updated: name, description, enabled.
          Can only update name if targeting by ID

          Overrides keystone tenant_update form api V2.  For keystone  api
          V3 only.

          New in version 2016.11.0.

          project_id
                 The project id.

          name   The  project name, which must be unique within the owning
                 domain.

          description
                 The project description.

          enabled
                 Enables or disables the project.

          profile
                 Configuration profile -  if  configuration  for  multiple
                 openstack accounts required.

          CLI Examples:

             salt '*' keystone.project_update name=admin enabled=True
             salt '*' keystone.project_update c965f79c4f864eaaa9c3b41904e67082 name=admin email=[email protected]

   salt.modules.keystone.role_create(name,                   profile=None,
   **connection_args)
          Create a named role.

          CLI Example:

             salt '*' keystone.role_create admin

   salt.modules.keystone.role_delete(role_id=None,              name=None,
   profile=None, **connection_args)
          Delete a role (keystone role-delete)

          CLI Examples:

             salt '*' keystone.role_delete c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.role_delete role_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.role_delete name=admin

   salt.modules.keystone.role_get(role_id=None,  name=None,  profile=None,
   **connection_args)
          Return a specific roles (keystone role-get)

          CLI Examples:

             salt '*' keystone.role_get c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.role_get role_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.role_get name=nova

   salt.modules.keystone.role_list(profile=None, **connection_args)
          Return a list of available roles (keystone role-list)

          CLI Example:

             salt '*' keystone.role_list

   salt.modules.keystone.service_create(name,                service_type,
   description=None, profile=None, **connection_args)
          Add service to Keystone service catalog

          CLI Examples:

             salt '*' keystone.service_create nova compute 'OpenStack Compute Service'

   salt.modules.keystone.service_delete(service_id=None,        name=None,
   profile=None, **connection_args)
          Delete a service from Keystone service catalog

          CLI Examples:

             salt '*' keystone.service_delete c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.service_delete name=nova

   salt.modules.keystone.service_get(service_id=None,           name=None,
   profile=None, **connection_args)
          Return a specific services (keystone service-get)

          CLI Examples:

             salt '*' keystone.service_get c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.service_get service_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.service_get name=nova

   salt.modules.keystone.service_list(profile=None, **connection_args)
          Return a list of available services (keystone services-list)

          CLI Example:

             salt '*' keystone.service_list

   salt.modules.keystone.tenant_create(name,             description=None,
   enabled=True, profile=None, **connection_args)
          Create a keystone tenant

          CLI Examples:

             salt '*' keystone.tenant_create nova description='nova tenant'
             salt '*' keystone.tenant_create test enabled=False

   salt.modules.keystone.tenant_delete(tenant_id=None,          name=None,
   profile=None, **connection_args)
          Delete a tenant (keystone tenant-delete)

          CLI Examples:

             salt '*' keystone.tenant_delete c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.tenant_delete tenant_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.tenant_delete name=demo

   salt.modules.keystone.tenant_get(tenant_id=None,             name=None,
   profile=None, **connection_args)
          Return a specific tenants (keystone tenant-get)

          CLI Examples:

             salt '*' keystone.tenant_get c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.tenant_get tenant_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.tenant_get name=nova

   salt.modules.keystone.tenant_list(profile=None, **connection_args)
          Return a list of available tenants (keystone tenants-list)

          CLI Example:

             salt '*' keystone.tenant_list

   salt.modules.keystone.tenant_update(tenant_id=None,          name=None,
   description=None, enabled=None, profile=None, **connection_args)
          Update  a  tenant's  information  (keystone  tenant-update)  The
          following fields may be  updated:  name,  description,  enabled.
          Can only update name if targeting by ID

          CLI Examples:

             salt '*' keystone.tenant_update name=admin enabled=True
             salt '*' keystone.tenant_update c965f79c4f864eaaa9c3b41904e67082 name=admin email=[email protected]

   salt.modules.keystone.token_get(profile=None, **connection_args)
          Return the configured tokens (keystone token-get)

          CLI Example:

             salt '*' keystone.token_get c965f79c4f864eaaa9c3b41904e67082

   salt.modules.keystone.user_create(name,         password,        email,
   tenant_id=None,    enabled=True,     profile=None,     project_id=None,
   description=None, **connection_args)
          Create a user (keystone user-create)

          CLI Examples:

             salt '*' keystone.user_create name=jack password=zero email=[email protected]         tenant_id=a28a7b5a999a455f84b1f5210264375e enabled=True

   salt.modules.keystone.user_delete(user_id=None,              name=None,
   profile=None, **connection_args)
          Delete a user (keystone user-delete)

          CLI Examples:

             salt '*' keystone.user_delete c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.user_delete user_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.user_delete name=nova

   salt.modules.keystone.user_get(user_id=None,  name=None,  profile=None,
   **connection_args)
          Return a specific users (keystone user-get)

          CLI Examples:

             salt '*' keystone.user_get c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.user_get user_id=c965f79c4f864eaaa9c3b41904e67082
             salt '*' keystone.user_get name=nova

   salt.modules.keystone.user_list(profile=None, **connection_args)
          Return a list of available users (keystone user-list)

          CLI Example:

             salt '*' keystone.user_list

   salt.modules.keystone.user_password_update(user_id=None,     name=None,
   password=None, profile=None, **connection_args)
          Update a user's password (keystone user-password-update)

          CLI Examples:

             salt '*' keystone.user_password_update c965f79c4f864eaaa9c3b41904e67082 password=12345
             salt '*' keystone.user_password_update user_id=c965f79c4f864eaaa9c3b41904e67082 password=12345
             salt '*' keystone.user_password_update name=nova password=12345

   salt.modules.keystone.user_role_add(user_id=None,            user=None,
   tenant_id=None,  tenant=None,  role_id=None,  role=None,  profile=None,
   project_id=None, project_name=None, **connection_args)
          Add role for user in tenant (keystone user-role-add)

          CLI Examples:

             salt '*' keystone.user_role_add user_id=298ce377245c4ec9b70e1c639c89e654 tenant_id=7167a092ece84bae8cead4bf9d15bb3b role_id=ce377245c4ec9b70e1c639c89e8cead4
             salt '*' keystone.user_role_add user=admin tenant=admin role=admin

   salt.modules.keystone.user_role_list(user_id=None,      tenant_id=None,
   user_name=None,    tenant_name=None,   profile=None,   project_id=None,
   project_name=None, **connection_args)
          Return a list of available user_roles (keystone user-roles-list)

          CLI Examples:

             salt '*' keystone.user_role_list user_id=298ce377245c4ec9b70e1c639c89e654 tenant_id=7167a092ece84bae8cead4bf9d15bb3b
             salt '*' keystone.user_role_list user_name=admin tenant_name=admin

   salt.modules.keystone.user_role_remove(user_id=None,         user=None,
   tenant_id=None,  tenant=None,  role_id=None,  role=None,  profile=None,
   project_id=None, project_name=None, **connection_args)
          Remove role for user in tenant (keystone user-role-remove)

          CLI Examples:

             salt '*' keystone.user_role_remove user_id=298ce377245c4ec9b70e1c639c89e654 tenant_id=7167a092ece84bae8cead4bf9d15bb3b role_id=ce377245c4ec9b70e1c639c89e8cead4
             salt '*' keystone.user_role_remove user=admin tenant=admin role=admin

   salt.modules.keystone.user_update(user_id=None, name=None,  email=None,
   enabled=None,       tenant=None,       profile=None,      project=None,
   description=None, **connection_args)
          Update a user's information (keystone user-update) The following
          fields  may  be  updated: name, email, enabled, tenant.  Because
          the name is one of the fields, a valid user id is required.

          CLI Examples:

             salt '*' keystone.user_update user_id=c965f79c4f864eaaa9c3b41904e67082 name=newname
             salt '*' keystone.user_update c965f79c4f864eaaa9c3b41904e67082 name=newname email=[email protected]

   salt.modules.keystone.user_verify_password(user_id=None,     name=None,
   password=None, profile=None, **connection_args)
          Verify a user's password

          CLI Examples:

             salt '*' keystone.user_verify_password name=test password=foobar
             salt '*' keystone.user_verify_password user_id=c965f79c4f864eaaa9c3b41904e67082 password=foobar

   salt.modules.kmod
   Module to manage Linux kernel modules

   salt.modules.kmod.available()
          Return a list of all available kernel modules

          CLI Example:

             salt '*' kmod.available

   salt.modules.kmod.check_available(mod)
          Check to see if the specified kernel module is available

          CLI Example:

             salt '*' kmod.check_available kvm

   salt.modules.kmod.is_loaded(mod)
          Check to see if the specified kernel module is loaded

          CLI Example:

             salt '*' kmod.is_loaded kvm

   salt.modules.kmod.load(mod, persist=False)
          Load the specified kernel module

          mod    Name of module to add

          persist
                 Write  module  to  /etc/modules to make it load on system
                 reboot

          CLI Example:

             salt '*' kmod.load kvm

   salt.modules.kmod.lsmod()
          Return a dict  containing  information  about  currently  loaded
          modules

          CLI Example:

             salt '*' kmod.lsmod

   salt.modules.kmod.mod_list(only_persist=False)
          Return a list of the loaded module names

          only_persist
                 Only return the list of loaded persistent modules

          CLI Example:

             salt '*' kmod.mod_list

   salt.modules.kmod.remove(mod, persist=False, comment=True)
          Remove the specified kernel module

          mod    Name of module to remove

          persist
                 Also remove module from /etc/modules

          comment
                 If persist is set don't remove line from /etc/modules but
                 only comment it

          CLI Example:

             salt '*' kmod.remove kvm

   salt.modules.launchctl
   Module for the management of MacOS systems that use launchd/launchctl

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   depends

          * plistlib Python module

   salt.modules.launchctl.available(job_label)
          Check that the given service is available.

          CLI Example:

             salt '*' service.available com.openssh.sshd

   salt.modules.launchctl.disabled(job_label, runas=None)
          Return True if the named service is disabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service label>

   salt.modules.launchctl.enabled(job_label, runas=None)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.enabled <service label>

   salt.modules.launchctl.get_all()
          Return all installed services

          CLI Example:

             salt '*' service.get_all

   salt.modules.launchctl.missing(job_label)
          The inverse of service.available Check that the given service is
          not available.

          CLI Example:

             salt '*' service.missing com.openssh.sshd

   salt.modules.launchctl.restart(job_label, runas=None)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service label>

   salt.modules.launchctl.start(job_label, runas=None)
          Start the specified service

          CLI Example:

             salt '*' service.start <service label>
             salt '*' service.start org.ntp.ntpd
             salt '*' service.start /System/Library/LaunchDaemons/org.ntp.ntpd.plist

   salt.modules.launchctl.status(job_label, runas=None)
          Return  the  status  for  a  service, returns a bool whether the
          service is running.

          CLI Example:

             salt '*' service.status <service label>

   salt.modules.launchctl.stop(job_label, runas=None)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service label>
             salt '*' service.stop org.ntp.ntpd
             salt '*' service.stop /System/Library/LaunchDaemons/org.ntp.ntpd.plist

   salt.modules.layman
   Support for Layman

   salt.modules.layman.add(overlay)
          Add the given overlay  from  the  cached  remote  list  to  your
          locally  installed  overlays.  Specify 'ALL' to add all overlays
          from the remote list.

          Return a list of the new overlay(s) added:

          CLI Example:

             salt '*' layman.add <overlay name>

   salt.modules.layman.delete(overlay)
          Remove  the  given  overlay  from  the  your  locally  installed
          overlays.  Specify 'ALL' to remove all overlays.

          Return a list of the overlays(s) that were removed:

          CLI Example:

             salt '*' layman.delete <overlay name>

   salt.modules.layman.list_all()
          List all overlays, including remote ones.

          Return a list of available overlays:

          CLI Example:

             salt '*' layman.list_all

   salt.modules.layman.list_local()
          List the locally installed overlays.

          Return a list of installed overlays:

          CLI Example:

             salt '*' layman.list_local

   salt.modules.layman.sync(overlay='ALL')
          Update  the  specified  overlay.  Use  'ALL'  to synchronize all
          overlays.  This is the default if no overlay is specified.

          overlay
                 Name of the overlay to sync. (Defaults to 'ALL')

          CLI Example:

             salt '*' layman.sync

   salt.modules.ldap3
   Query and modify an LDAP database (alternative interface)
   New in version 2016.3.0.

   This is an alternative to the ldap interface provided  by  the  ldapmod
   execution module.

   depends

          * ldap Python module

   exception salt.modules.ldap3.LDAPError(message, cause=None)
          Base class of all LDAP exceptions raised by backends.

          This  is only used for errors encountered while interacting with
          the LDAP server; usage errors (e.g., invalid backend name)  will
          have a different type.

          Variables
                 cause -- backend exception object, if applicable

   salt.modules.ldap3.add(connect_spec, dn, attributes)
          Add an entry to an LDAP database.

          Parameters

                 * connect_spec   --   See   the   documentation  for  the
                   connect_spec parameter for connect().

                 * dn -- Distinguished name of the entry.

                 * attributes -- Non-empty dict mapping each  of  the  new
                   entry's attributes to a non-empty iterable of values.

          Returns
                 True if successful, raises an exception otherwise.

          CLI example:

             salt '*' ldap3.add "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'password': 'secret',
                 },
             }" "dn='dc=example,dc=com'" "attributes={'example': 'values'}"

   salt.modules.ldap3.change(connect_spec, dn, before, after)
          Modify an entry in an LDAP database.

          This  does  the  same  thing  as  modify(),  but  with a simpler
          interface.  Instead of taking a list of directives, it  takes  a
          before  and  after  view of an entry, determines the differences
          between the two, computes the directives, and executes them.

          Any attribute value present in before but missing  in  after  is
          deleted.   Any  attribute  value present in after but missing in
          before is added.  Any attribute value in the  database  that  is
          not  mentioned  in  either  before or after is not altered.  Any
          attribute value that is present in  both  before  and  after  is
          ignored,  regardless  of  whether that attribute value exists in
          the database.

          Parameters

                 * connect_spec  --  See   the   documentation   for   the
                   connect_spec parameter for connect().

                 * dn -- Distinguished name of the entry.

                 * before  --  The  expected  state  of  the  entry before
                   modification.  This is a dict  mapping  each  attribute
                   name to an iterable of values.

                 * after   --   The  desired  state  of  the  entry  after
                   modification.  This is a dict  mapping  each  attribute
                   name to an iterable of values.

          Returns
                 True if successful, raises an exception otherwise.

          CLI example:

             salt '*' ldap3.change "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'password': 'secret'}
             }" dn='cn=admin,dc=example,dc=com'
             before="{'example_value': 'before_val'}"
             after="{'example_value': 'after_val'}"

   salt.modules.ldap3.connect(connect_spec=None)
          Connect and optionally bind to an LDAP server.

          Parameters
                 connect_spec --

                 This  can  be  an  LDAP  connection  object returned by a
                 previous call to connect() (in which case the argument is
                 simply  returned),  None  (in which case an empty dict is
                 used), or a dict with the following keys:

                 *

                   'backend'
                          Optional; default depends on which  Python  LDAP
                          modules  are installed.  Name of the Python LDAP
                          module to use.  Only 'ldap' is supported at  the
                          moment.

                 *

                   'url'  Optional;  defaults  to 'ldapi:///'.  URL to the
                          LDAP server.

                 *

                   'bind' Optional; defaults to None.   Describes  how  to
                          bind  an  identity  to  the LDAP connection.  If
                          None, an anonymous connection  is  made.   Valid
                          keys:

                          *

                            'method'
                                   Optional;   defaults   to   None.   The
                                   authentication method  to  use.   Valid
                                   values  include but are not necessarily
                                   limited to 'simple', 'sasl', and  None.
                                   If  None,  an  anonymous  connection is
                                   made.  Available methods depend on  the
                                   chosen backend.

                          *

                            'mechanism'
                                   Optional;  defaults to 'EXTERNAL'.  The
                                   SASL mechanism to use.  Ignored  unless
                                   the   method   is   'sasl'.   Available
                                   methods depend on  the  chosen  backend
                                   and the server's capabilities.

                          *

                            'credentials'
                                   Optional;  defaults to None.  An object
                                   specific to the chosen  SASL  mechanism
                                   and   backend   that   represents   the
                                   authentication  credentials.    Ignored
                                   unless the method is 'sasl'.

                                   For  the  'ldap'  backend,  this  is  a
                                   dictionary.  If None, an empty dict  is
                                   used.  Keys:

                                   *

                                     'args' Optional; defaults to an empty
                                            list.  A list of arguments  to
                                            pass  to  the  SASL  mechanism
                                            constructor.   See  the   SASL
                                            mechanism          constructor
                                            documentation in the ldap.sasl
                                            Python module.

                                   *

                                     'kwargs'
                                            Optional; defaults to an empty
                                            dict.   A  dict   of   keyword
                                            arguments  to pass to the SASL
                                            mechanism  constructor.    See
                                            the SASL mechanism constructor
                                            documentation in the ldap.sasl
                                            Python module.

                          *

                            'dn'   Optional;  defaults to an empty string.
                                   The distinguished name to bind.

                          *

                            'password'
                                   Optional; defaults to an empty  string.
                                   Password  for  binding.  Ignored if the
                                   method is 'sasl'.

                 *

                   'tls'  Optional; defaults to None.  A  backend-specific
                          object  containing  settings to override default
                          TLS behavior.

                          For the 'ldap' backend, this  is  a  dictionary.
                          Not   all   settings   in  this  dictionary  are
                          supported by all versions of python-ldap or  the
                          underlying  TLS library.  If None, an empty dict
                          is used.  Possible keys:

                          *

                            'starttls'
                                   If present, initiate a  TLS  connection
                                   using  StartTLS.  (The value associated
                                   with this key is ignored.)

                          *

                            'cacertdir'
                                   Set   the   path   of   the   directory
                                   containing CA certificates.

                          *

                            'cacertfile'
                                   Set  the pathname of the CA certificate
                                   file.

                          *

                            'certfile'
                                   Set the  pathname  of  the  certificate
                                   file.

                          *

                            'cipher_suite'
                                   Set the allowed cipher suite.

                          *

                            'crlcheck'
                                   Set the CRL evaluation strategy.  Valid
                                   values are 'none', 'peer', and 'all'.

                          *

                            'crlfile'
                                   Set the pathname of the CRL file.

                          *

                            'dhfile'
                                   Set the pathname of the file containing
                                   the   parameters   for   Diffie-Hellman
                                   ephemeral key exchange.

                          *

                            'keyfile'
                                   Set the pathname of the certificate key
                                   file.

                          *

                            'newctx'
                                   If present, instruct the underlying TLS
                                   library to create a  new  TLS  context.
                                   (The  value associated with this key is
                                   ignored.)

                          *

                            'protocol_min'
                                   Set the minimum protocol version.

                          *

                            'random_file'
                                   Set the pathname  of  the  random  file
                                   when  /dev/random  and /dev/urandom are
                                   not available.

                          *

                            'require_cert'
                                   Set the certificate validation  policy.
                                   Valid   values   are  'never',  'hard',
                                   'demand', 'allow', and 'try'.

                 *

                   'opts' Optional; defaults to None.  A  backend-specific
                          object containing options for the backend.

                          For  the 'ldap' backend, this is a dictionary of
                          OpenLDAP options to set.  If None, an empty dict
                          is  used.  Each key is a the name of an OpenLDAP
                          option constant without the 'LDAP_OPT_'  prefix,
                          then converted to lower case.

          Returns
                 an  object  representing  an  LDAP connection that can be
                 used as the connect_spec argument to any of the functions
                 in  this  module  (to  avoid  the  overhead of making and
                 terminating multiple connections).

                 This object should be used as a context manager.   It  is
                 safe to nest with statements.

          CLI example:

             salt '*' ldap3.connect "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'dn': 'cn=admin,dc=example,dc=com',
                     'password': 'secret'}
             }"

   salt.modules.ldap3.delete(connect_spec, dn)
          Delete an entry from an LDAP database.

          Parameters

                 * connect_spec   --   See   the   documentation  for  the
                   connect_spec parameter for connect().

                 * dn -- Distinguished name of the entry.

          Returns
                 True if successful, raises an exception otherwise.

          CLI example:

             salt '*' ldap3.delete "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'password': 'secret'}
             }" dn='cn=admin,dc=example,dc=com'

   salt.modules.ldap3.modify(connect_spec, dn, directives)
          Modify an entry in an LDAP database.

          Parameters

                 * connect_spec  --  See   the   documentation   for   the
                   connect_spec parameter for connect().

                 * dn -- Distinguished name of the entry.

                 * directives --

                   Iterable  of directives that indicate how to modify the
                   entry.  Each directive is a  tuple  of  the  form  (op,
                   attr, vals), where:

                   * op  identifies the modification operation to perform.
                     One of:

                     * 'add' to add one or more values to the attribute

                     * 'delete' to delete some or all of the  values  from
                       the  attribute.   If  no  values are specified with
                       this operation, all of the attribute's  values  are
                       deleted.   Otherwise,  only  the  named  values are
                       deleted.

                     * 'replace' to replace all of the attribute's  values
                       with zero or more new values

                   * attr names the attribute to modify

                   * vals is an iterable of values to add or delete

          Returns
                 True if successful, raises an exception otherwise.

          CLI example:

             salt '*' ldap3.modify "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'password': 'secret'}
             }" dn='cn=admin,dc=example,dc=com'
             directives="('add', 'example', ['example_val'])"

   salt.modules.ldap3.search(connect_spec,      base,     scope='subtree',
   filterstr='(objectClass=*)', attrlist=None, attrsonly=0)
          Search an LDAP database.

          Parameters

                 * connect_spec  --  See   the   documentation   for   the
                   connect_spec parameter for connect().

                 * base  --  Distinguished  name  of the entry at which to
                   start the search.

                 * scope --

                   One of the following:

                   *

                     'subtree'
                            Search the base and all of its descendants.

                   *

                     'base' Search only the base itself.

                   *

                     'onelevel'
                            Search only the base's immediate children.

                 * filterstr -- String representation  of  the  filter  to
                   apply in the search.

                 * attrlist  --  Limit the returned attributes to those in
                   the specified list.  If None, all  attributes  of  each
                   entry are returned.

                 * attrsonly  --  If  non-zero, don't return any attribute
                   values.

          Returns
                 a dict of results.  The dict is empty  if  there  are  no
                 results.    The   dict   maps   each   returned   entry's
                 distinguished name to  a  dict  that  maps  each  of  the
                 matching attribute names to a list of its values.

          CLI example:

             salt '*' ldap3.search "{
                 'url': 'ldaps://ldap.example.com/',
                 'bind': {
                     'method': 'simple',
                     'dn': 'cn=admin,dc=example,dc=com',
                     'password': 'secret',
                 },
             }" "base='dc=example,dc=com'"

   salt.modules.ldapmod
   Salt interface to LDAP commands

   depends

          * ldap Python module

   configuration
          In  order  to connect to LDAP, certain configuration is required
          in  the  minion  config  on  the  LDAP   server.   The   minimum
          configuration items that must be set are:

             ldap.basedn: dc=acme,dc=com (example values, adjust to suit)

          If  your  LDAP server requires authentication then you must also
          set:

             ldap.anonymous: False
             ldap.binddn: admin
             ldap.bindpw: password

          In addition, the following optional values may be set:

             ldap.server: localhost (default=localhost, see warning below)
             ldap.port: 389 (default=389, standard port)
             ldap.tls: False (default=False, no TLS)
             ldap.no_verify: False (default=False, verify TLS)
             ldap.anonymous: True (default=True, bind anonymous)
             ldap.scope: 2 (default=2, ldap.SCOPE_SUBTREE)
             ldap.attrs: [saltAttr] (default=None, return all attributes)

   WARNING:
      At the  moment  this  module  only  recommends  connection  to  LDAP
      services  listening  on  localhost.  This is deliberate to avoid the
      potentially  dangerous  situation  of   multiple   minions   sending
      identical  update commands to the same LDAP server. It's easy enough
      to override this behavior, but badness may ensue  -  you  have  been
      warned.

   salt.modules.ldapmod.search(filter,  dn=None,  scope=None,  attrs=None,
   **kwargs)
          Run an arbitrary LDAP query and return the results.

          CLI Example:

             salt 'ldaphost' ldap.search "filter=cn=myhost"

          Return data:

             {'myhost': {'count': 1,
                         'results': [['cn=myhost,ou=hosts,o=acme,c=gb',
                                      {'saltKeyValue': ['ntpserver=ntp.acme.local',
                                                        'foo=myfoo'],
                                       'saltState': ['foo', 'bar']}]],
                         'time': {'human': '1.2ms', 'raw': '0.00123'}}}

          Search and connection options can be  overridden  by  specifying
          the relevant option as key=value pairs, for example:

             salt 'ldaphost' ldap.search filter=cn=myhost dn=ou=hosts,o=acme,c=gb
             scope=1 attrs='' server='localhost' port='7393' tls=True bindpw='ssh'

   salt.modules.linux_acl
   Support for Linux File Access Control Lists

   salt.modules.linux_acl.delfacl(acl_type, acl_name='', *args, **kwargs)
          Remove specific FACL from the specified file(s)

          CLI Examples:

             salt '*' acl.delfacl user myuser /tmp/house/kitchen
             salt '*' acl.delfacl default:group mygroup /tmp/house/kitchen
             salt '*' acl.delfacl d:u myuser /tmp/house/kitchen
             salt '*' acl.delfacl g myuser /tmp/house/kitchen /tmp/house/livingroom
             salt '*' acl.delfacl user myuser /tmp/house/kitchen recursive=True

   salt.modules.linux_acl.getfacl(*args, **kwargs)
          Return (extremely verbose) map of FACLs on specified file(s)

          CLI Examples:

             salt '*' acl.getfacl /tmp/house/kitchen
             salt '*' acl.getfacl /tmp/house/kitchen /tmp/house/livingroom
             salt '*' acl.getfacl /tmp/house/kitchen /tmp/house/livingroom recursive=True

   salt.modules.linux_acl.modfacl(acl_type,  acl_name='', perms='', *args,
   **kwargs)
          Add or modify a FACL for the specified file(s)

          CLI Examples:

             salt '*' acl.modfacl user myuser rwx /tmp/house/kitchen
             salt '*' acl.modfacl default:group mygroup rx /tmp/house/kitchen
             salt '*' acl.modfacl d:u myuser 7 /tmp/house/kitchen
             salt '*' acl.modfacl g mygroup 0 /tmp/house/kitchen /tmp/house/livingroom
             salt '*' acl.modfacl user myuser rwx /tmp/house/kitchen recursive=True

   salt.modules.linux_acl.version()
          Return facl version from getfacl --version

          CLI Example:

             salt '*' acl.version

   salt.modules.linux_acl.wipefacls(*args, **kwargs)
          Remove all FACLs from the specified file(s)

          CLI Examples:

             salt '*' acl.wipefacls /tmp/house/kitchen
             salt '*' acl.wipefacls /tmp/house/kitchen /tmp/house/livingroom
             salt '*' acl.wipefacls /tmp/house/kitchen /tmp/house/livingroom recursive=True

   salt.modules.linux_ip module
   The networking module for Non-RH/Deb Linux distros

   salt.modules.linux_ip.down(iface, iface_type=None)
          Shutdown a network interface

          CLI Example:

             salt '*' ip.down eth0

   salt.modules.linux_ip.get_interface(iface)
          Return the contents of an interface script

          CLI Example:

             salt '*' ip.get_interface eth0

   salt.modules.linux_ip.get_routes(iface=None)
          Return the current routing table

          CLI Examples:

             salt '*' ip.get_routes
             salt '*' ip.get_routes eth0

   salt.modules.linux_ip.up(iface, iface_type=None)
          Start up a network interface

          CLI Example:

             salt '*' ip.up eth0

   salt.modules.linux_lvm
   Support for Linux LVM2

   salt.modules.linux_lvm.fullversion()
          Return all version info from lvm version

          CLI Example:

             salt '*' lvm.fullversion

   salt.modules.linux_lvm.lvcreate(lvname,       vgname,        size=None,
   extents=None, snapshot=None, pv=None, thinvolume=False, thinpool=False,
   **kwargs)
          Create a new logical volume,  with  option  for  which  physical
          volume to be used

          CLI Examples:

             salt '*' lvm.lvcreate new_volume_name     vg_name size=10G
             salt '*' lvm.lvcreate new_volume_name     vg_name extents=100 pv=/dev/sdb
             salt '*' lvm.lvcreate new_snapshot        vg_name snapshot=volume_name size=3G

          New in version to_complete.

          Support for thin pools and thin volumes

          CLI Examples:

             salt '*' lvm.lvcreate new_thinpool_name   vg_name               size=20G thinpool=True
             salt '*' lvm.lvcreate new_thinvolume_name vg_name/thinpool_name size=10G thinvolume=True

   salt.modules.linux_lvm.lvdisplay(lvname='')
          Return information about the logical volume(s)

          CLI Examples:

             salt '*' lvm.lvdisplay
             salt '*' lvm.lvdisplay /dev/vg_myserver/root

   salt.modules.linux_lvm.lvremove(lvname, vgname)
          Remove  a  given  existing  logical volume from a named existing
          volume group

          CLI Example:

             salt '*' lvm.lvremove lvname vgname force=True

   salt.modules.linux_lvm.lvresize(size, lvpath)
          Return information about the logical volume(s)

          CLI Examples:

             salt '*' lvm.lvresize +12M /dev/mapper/vg1-test

   salt.modules.linux_lvm.pvcreate(devices, override=True, **kwargs)
          Set a physical device to be used as an LVM physical volume

          override
                 Skip devices, if they are already an LVM physical volumes

          CLI Examples:

             salt mymachine lvm.pvcreate /dev/sdb1,/dev/sdb2
             salt mymachine lvm.pvcreate /dev/sdb1 dataalignmentoffset=7s

   salt.modules.linux_lvm.pvdisplay(pvname='', real=False)
          Return information about the physical volume(s)

          pvname physical device name

          real   dereference any symlinks and report the real device

                 New in version 2015.8.7.

          CLI Examples:

             salt '*' lvm.pvdisplay
             salt '*' lvm.pvdisplay /dev/md0

   salt.modules.linux_lvm.pvremove(devices, override=True)
          Remove a physical device being used as an LVM physical volume

          override
                 Skip devices, if they are already  not  used  as  an  LVM
                 physical volumes

          CLI Examples:

             salt mymachine lvm.pvremove /dev/sdb1,/dev/sdb2

   salt.modules.linux_lvm.version()
          Return LVM version from lvm version

          CLI Example:

             salt '*' lvm.version

   salt.modules.linux_lvm.vgcreate(vgname, devices, **kwargs)
          Create an LVM volume group

          CLI Examples:

             salt mymachine lvm.vgcreate my_vg /dev/sdb1,/dev/sdb2
             salt mymachine lvm.vgcreate my_vg /dev/sdb1 clustered=y

   salt.modules.linux_lvm.vgdisplay(vgname='')
          Return information about the volume group(s)

          CLI Examples:

             salt '*' lvm.vgdisplay
             salt '*' lvm.vgdisplay nova-volumes

   salt.modules.linux_lvm.vgextend(vgname, devices)
          Add physical volumes to an LVM volume group

          CLI Examples:

             salt mymachine lvm.vgextend my_vg /dev/sdb1,/dev/sdb2
             salt mymachine lvm.vgextend my_vg /dev/sdb1

   salt.modules.linux_lvm.vgremove(vgname)
          Remove an LVM volume group

          CLI Examples:

             salt mymachine lvm.vgremove vgname
             salt mymachine lvm.vgremove vgname force=True

   salt.modules.linux_sysctl
   Module for viewing and modifying sysctl parameters

   salt.modules.linux_sysctl.assign(name, value)
          Assign a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.assign net.ipv4.ip_forward 1

   salt.modules.linux_sysctl.default_config()
          Linux  hosts  using systemd 207 or later ignore /etc/sysctl.conf
          and only load from /etc/sysctl.d/*.conf. This function  will  do
          the proper checks and return a default config file which will be
          valid for the Minion. Hosts running  systemd  >=  207  will  use
          /etc/sysctl.d/99-salt.conf.

          CLI Example:

             salt -G 'kernel:Linux' sysctl.default_config

   salt.modules.linux_sysctl.get(name)
          Return a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.get net.ipv4.ip_forward

   salt.modules.linux_sysctl.persist(name, value, config=None)
          Assign and persist a simple sysctl parameter for this minion. If
          config is not specified, a sensible default will be chosen using
          sysctl.default_config.

          CLI Example:

             salt '*' sysctl.persist net.ipv4.ip_forward 1

   salt.modules.linux_sysctl.show(config_file=False)
          Return a list of sysctl parameters for this minion

          config: Pull the data from the system configuration file
                 instead of the live data.

          CLI Example:

             salt '*' sysctl.show

   salt.modules.localemod
   Module for managing locales on POSIX-like systems.

   salt.modules.localemod.avail(locale)
          Check if a locale is available.

          New in version 2014.7.0.

          CLI Example:

             salt '*' locale.avail 'en_US.UTF-8'

   salt.modules.localemod.gen_locale(locale, **kwargs)
          Generate a locale. Options:

          New in version 2014.7.0.

          Parameters
                 locale -- Any locale listed in /usr/share/i18n/locales or
                 /usr/share/i18n/SUPPORTED for  Debian  and  Gentoo  based
                 distributions,  which require the charmap to be specified
                 as part of the locale when generating it.

          verbose
                 Show  extra  warnings  about  errors  that  are  normally
                 ignored.

          CLI Example:

             salt '*' locale.gen_locale en_US.UTF-8
             salt '*' locale.gen_locale 'en_IE.UTF-8 UTF-8'    # Debian/Gentoo only

   salt.modules.localemod.get_locale()
          Get the current system locale

          CLI Example:

             salt '*' locale.get_locale

   salt.modules.localemod.list_avail()
          Lists available (compiled) locales

          CLI Example:

             salt '*' locale.list_avail

   salt.modules.localemod.set_locale(locale)
          Sets the current system locale

          CLI Example:

             salt '*' locale.set_locale 'en_US.UTF-8'

   salt.modules.locate
   Module for using the locate utilities

   salt.modules.locate.locate(pattern, database='', limit=0, **kwargs)
          Performs a file lookup. Valid options (and their defaults) are:

             basename=False
             count=False
             existing=False
             follow=True
             ignore=False
             nofollow=False
             wholename=True
             regex=False
             database=<locate's default database>
             limit=<integer, not set by default>

          See  the  manpage for locate(1) for further explanation of these
          options.

          CLI Example:

             salt '*' locate.locate

   salt.modules.locate.stats()
          Returns statistics about the locate database

          CLI Example:

             salt '*' locate.stats

   salt.modules.locate.updatedb()
          Updates the locate database

          CLI Example:

             salt '*' locate.updatedb

   salt.modules.locate.version()
          Returns the version of locate

          CLI Example:

             salt '*' locate.version

   salt.modules.logadm
   Module for managing Solaris logadm based log rotations.

   salt.modules.logadm.remove(name, conf_file='/etc/logadm.conf')
          Remove log pattern from logadm

          CLI Example:

             salt '*' logadm.remove myapplog

   salt.modules.logadm.rotate(name, pattern=False, count=False, age=False,
   size=False, copy=True, conf_file='/etc/logadm.conf')
          Set up pattern for logging.

          CLI Example:

             salt '*' logadm.rotate myapplog pattern='/var/log/myapp/*.log' count=7

   salt.modules.logadm.show_conf(conf_file='/etc/logadm.conf')
          Show parsed configuration

          CLI Example:

             salt '*' logadm.show_conf

   salt.modules.logrotate
   Module for managing logrotate.

   salt.modules.logrotate.set(key,           value,          setting=None,
   conf_file='/etc/logrotate.conf')
          Set a new value for a specific configuration line

          CLI Example:

             salt '*' logrotate.set rotate 2

          Can also be used to  set  a  single  value  inside  a  multiline
          configuration  block.  For  instance,  to  change  rotate in the
          following block:

             /var/log/wtmp {
                 monthly
                 create 0664 root root
                 rotate 1
             }

          Use the following command:

             salt '*' logrotate.set /var/log/wtmp rotate 2

          This module also has the ability to scan files inside an include
          directory, and make changes in the appropriate file.

   salt.modules.logrotate.show_conf(conf_file='/etc/logrotate.conf')
          Show parsed configuration

          CLI Example:

             salt '*' logrotate.show_conf

   salt.modules.lvs
   Support for LVS (Linux Virtual Server)

   salt.modules.lvs.add_server(protocol=None,        service_address=None,
   server_address=None, packet_forward_method='dr', weight=1, **kwargs)
          Add a real server to a virtual service.

          protocol
                 The service protocol(only support  tcp,  udp  and  fwmark
                 service).

          service_address
                 The LVS service address.

          server_address
                 The real server address.

          packet_forward_method
                 The  LVS  packet forwarding method(dr for direct routing,
                 tunnel   for   tunneling,   nat   for   network    access
                 translation).

          weight The  capacity   of a server relative to the others in the
                 pool.

          CLI Example:

             salt '*' lvs.add_server tcp 1.1.1.1:80 192.168.0.11:8080 nat 1

   salt.modules.lvs.add_service(protocol=None,       service_address=None,
   scheduler='wlc')
          Add a virtual service.

          protocol
                 The  service  protocol(only  support  tcp, udp and fwmark
                 service).

          service_address
                 The LVS service address.

          scheduler
                 Algorithm  for  allocating  TCP   connections   and   UDP
                 datagrams to real servers.

          CLI Example:

             salt '*' lvs.add_service tcp 1.1.1.1:80 rr

   salt.modules.lvs.check_server(protocol=None,      service_address=None,
   server_address=None, **kwargs)
          Check the real server exists in the specified service.

          CLI Example:

             salt '*' lvs.check_server tcp 1.1.1.1:80 192.168.0.11:8080

   salt.modules.lvs.check_service(protocol=None,     service_address=None,
   **kwargs)
          Check the virtual service exists.

          CLI Example:

             salt '*' lvs.check_service tcp 1.1.1.1:80

   salt.modules.lvs.clear()
          Clear the virtual server table

          CLI Example:

             salt '*' lvs.clear

   salt.modules.lvs.delete_server(protocol=None,     service_address=None,
   server_address=None)
          Delete the realserver from the virtual service.

          protocol
                 The service protocol(only support  tcp,  udp  and  fwmark
                 service).

          service_address
                 The LVS service address.

          server_address
                 The real server address.

          CLI Example:

             salt '*' lvs.delete_server tcp 1.1.1.1:80 192.168.0.11:8080

   salt.modules.lvs.delete_service(protocol=None, service_address=None)
          Delete the virtual service.

          protocol
                 The  service  protocol(only  support  tcp, udp and fwmark
                 service).

          service_address
                 The LVS service address.

          CLI Example:

             salt '*' lvs.delete_service tcp 1.1.1.1:80

   salt.modules.lvs.edit_server(protocol=None,       service_address=None,
   server_address=None, packet_forward_method=None, weight=None, **kwargs)
          Edit a real server to a virtual service.

          protocol
                 The  service  protocol(only  support  tcp, udp and fwmark
                 service).

          service_address
                 The LVS service address.

          server_address
                 The real server address.

          packet_forward_method
                 The LVS packet forwarding method(dr for  direct  routing,
                 tunnel    for   tunneling,   nat   for   network   access
                 translation).

          weight The capacity  of a server relative to the others  in  the
                 pool.

          CLI Example:

             salt '*' lvs.edit_server tcp 1.1.1.1:80 192.168.0.11:8080 nat 1

   salt.modules.lvs.edit_service(protocol=None,      service_address=None,
   scheduler=None)
          Edit the virtual service.

          protocol
                 The service protocol(only support  tcp,  udp  and  fwmark
                 service).

          service_address
                 The LVS service address.

          scheduler
                 Algorithm   for   allocating   TCP  connections  and  UDP
                 datagrams to real servers.

          CLI Example:

             salt '*' lvs.edit_service tcp 1.1.1.1:80 rr

   salt.modules.lvs.get_rules()
          Get the virtual server rules

          CLI Example:

             salt '*' lvs.get_rules

   salt.modules.lvs.list(protocol=None, service_address=None)
          List  the  virtual  server  table  if  service_address  is   not
          specified.  If  a service_address is selected, list this service
          only.

          CLI Example:

             salt '*' lvs.list

   salt.modules.lvs.zero(protocol=None, service_address=None)
          Zero the packet, byte and rate counters  in  a  service  or  all
          services.

          CLI Example:

             salt '*' lvs.zero

   salt.modules.lxc
   Control Linux Containers via Salt

   depends
          lxc package for distribution

   lxc >= 1.0 (even beta alpha) is required

   salt.modules.lxc.apply_network_profile(name,           network_profile,
   nic_opts=None, path=None)
          New in version 2015.5.0.

          Apply a network profile to a container

          network_profile
                 profile name or default values (dict)

          nic_opts
                 values to override in defaults (dict) indexed by nic card
                 names

          path   path to the container parent

                 New in version 2015.8.0.

          CLI Examples:

             salt 'minion' lxc.apply_network_profile web1 centos
             salt 'minion' lxc.apply_network_profile web1 centos \
                     nic_opts="{'eth0': {'mac': 'xx:xx:xx:xx:xx:xx'}}"
             salt 'minion' lxc.apply_network_profile web1 \
                     "{'eth0': {'mac': 'xx:xx:xx:xx:xx:yy'}}"
                     nic_opts="{'eth0': {'mac': 'xx:xx:xx:xx:xx:xx'}}"

          The special case to disable use of ethernet nics:

             salt 'minion' lxc.apply_network_profile web1 centos \
                     "{eth0: {disable: true}}"

   salt.modules.lxc.attachable(name, path=None)
          Return  True  if  the named container can be attached to via the
          lxc-attach command

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt 'minion' lxc.attachable ubuntu

   salt.modules.lxc.bootstrap(name,     config=None,     approve_key=True,
   install=True,    pub_key=None,    priv_key=None,    bootstrap_url=None,
   force_install=False,       unconditional_install=False,      path=None,
   bootstrap_delay=None, bootstrap_args=None, bootstrap_shell=None)
          Install and configure salt in a container.

          config Minion configuration  options.  By  default,  the  master
                 option is set to the target host's master.

          approve_key
                 Request  a  pre-approval  of  the  generated  minion key.
                 Requires that the salt-master  be  configured  to  either
                 auto-accept all keys or expect a signing request from the
                 target host. Default: True

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          pub_key
                 Explicit   public   key   to   pressed  the  minion  with
                 (optional).  This can be either a filepath  or  a  string
                 representing the key

          priv_key
                 Explicit   private   key   to  pressed  the  minion  with
                 (optional).  This can be either a filepath  or  a  string
                 representing the key

          bootstrap_delay
                 Delay  in  seconds  between end of container creation and
                 bootstrapping.  Useful  when  waiting  for  container  to
                 obtain a DHCP lease.

                 New in version 2015.5.0.

          bootstrap_url
                 url, content or filepath to the salt bootstrap script

          bootstrap_args
                 salt bootstrap script arguments

          bootstrap_shell
                 shell to execute the script into

          install
                 Whether  to attempt a full installation of salt-minion if
                 needed.

          force_install
                 Force installation even if salt-minion is detected,  this
                 is the way to run vendor bootstrap scripts even if a salt
                 minion is already present in the container

          unconditional_install
                 Run the script even if the container seems seeded

          CLI Examples:

             salt 'minion' lxc.bootstrap container_name [config=config_data] \
                     [approve_key=(True|False)] [install=(True|False)]

   salt.modules.lxc.clone(name, orig, profile=None,  network_profile=None,
   nic_opts=None, **kwargs)
          Create a new container as a clone of another container

          name   Name of the container

          orig   Name of the original container to be cloned

          profile
                 Profile    to    use    in    container    cloning   (see
                 lxc.get_container_profile). Values in a profile  will  be
                 overridden  by  the  Container  Cloning  Arguments listed
                 below.

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          Container Cloning Arguments

          snapshot
                 Use Copy On Write snapshots (LVM)

          size   1G  Size  of  the  volume  to  create. Only applicable if
                 backing=lvm.

          backing
                 The type of storage to use. Set to  lvm  to  use  an  LVM
                 group.  Defaults to filesystem within /var/lib/lxc.

          network_profile
                 Network profile to use for container

                 New in version 2015.8.0.

          nic_opts
                 give extra opts overriding network profile values

                 New in version 2015.8.0.

          CLI Examples:

             salt '*' lxc.clone myclone orig=orig_container
             salt '*' lxc.clone myclone orig=orig_container snapshot=True

   salt.modules.lxc.cloud_init(name, vm_=None, **kwargs)
          Thin  wrapper  to  lxc.init  to  be  used from the saltcloud lxc
          driver

          name   Name of the container may be None and then  guessed  from
                 saltcloud mapping

          vm_    saltcloud mapping defaults for the vm

          CLI Example:

             salt '*' lxc.cloud_init foo

   salt.modules.lxc.cloud_init_interface(name, vm_=None, **kwargs)
          Interface  between  salt.cloud.lxc  driver and lxc.init vm_ is a
          mapping of vm opts in the salt.cloud format  as  documented  for
          the lxc driver.

          This can be used either:

          * from the salt cloud driver

          * because  you  find the argument to give easier here than using
            directly lxc.init

          WARNING:
             BE  REALLY  CAREFUL  CHANGING  DEFAULTS  !!!   IT'S  A  RETRO
             COMPATIBLE INTERFACE WITH THE SALT CLOUD DRIVER (ask kiorky).

          name   name of the lxc container to create

          pub_key
                 public  key  to  preseed  the  minion  with.   Can be the
                 keycontent or a filepath

          priv_key
                 private key to preseed  the  minion  with.   Can  be  the
                 keycontent or a filepath

          path   path   to   the   container  parent  directory  (default:
                 /var/lib/lxc)

                 New in version 2015.8.0.

          profile
                 profile selection

          network_profile
                 network profile selection

          nic_opts
                 per interface settings compatibles with  network  profile
                 (ipv4/ipv6/link/gateway/mac/netmask)

                 eg:

                    - {'eth0': {'mac': '00:16:3e:01:29:40',
                                'gateway': None, (default)
                                'link': 'br0', (default)
                                'gateway': None, (default)
                                'netmask': '', (default)
                                'ip': '22.1.4.25'}}

          unconditional_install
                 given to lxc.bootstrap (see relative doc)

          force_install
                 given to lxc.bootstrap (see relative doc)

          config any extra argument for the salt minion config

          dnsservers
                 dns servers to set inside the container

          autostart
                 autostart the container at boot time

          password
                 administrative password for the container

          bootstrap_delay
                 delay before launching bootstrap script at Container init

          WARNING:
             Legacy but still supported options:

             from_container
                    which  container  we  use  as  a template when running
                    lxc.clone

             image  which template do we use when we are using lxc.create.
                    This  is the default mode unless you specify something
                    in from_container

             backing
                    which backing store to use.  Values can be: overlayfs,
                    dir(default), lvm, zfs, brtfs

             fstype When  using  a  blockdevice level backing store, which
                    filesystem to use on

             size   When using a blockdevice level  backing  store,  which
                    size for the filesystem to use on

             snapshot
                    Use snapshot when cloning the container source

             vgname if using LVM: vgname

             lvname if using LVM: lvname

             ip     ip for the primary nic

             mac    mac address for the primary nic

             netmask
                    netmask  for the primary nic (24) = vm_.get('netmask',
                    '24')

             bridge bridge for the primary nic (lxcbr0)

             gateway
                    network gateway for the container

             additional_ips
                    additional ips which will be wired on the main  bridge
                    (br0)  which  is connected to internet.  Be aware that
                    you may use manual virtual mac addresses  providen  by
                    you  provider  (online,  ovh, etc).  This is a list of
                    mappings {ip: '', mac: '', netmask:''} Set gateway  to
                    None  and  an  interface with a gateway to escape from
                    another interface that eth0.  eg:

                        - {'mac': '00:16:3e:01:29:40',
                           'gateway': None, (default)
                           'link': 'br0', (default)
                           'netmask': '', (default)
                           'ip': '22.1.4.25'}

             users  administrative users for the container default: [root]
                    and [root, ubuntu] on ubuntu

             default_nic
                    name  of  the  first  interface, you should really not
                    override this

          CLI Example:

             salt '*' lxc.cloud_init_interface foo

   salt.modules.lxc.copy_to(name,    source,    dest,     overwrite=False,
   makedirs=False, path=None)
          Changed  in  version  2015.8.0:  Function renamed from lxc.cp to
          lxc.copy_to for consistency with other container  types.  lxc.cp
          will  continue  to  work,  however.   For  versions 2015.2.x and
          earlier, use lxc.cp.

          Copy a file or directory from the host into a container

          name   Container name

          source File to be copied to the container

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          dest   Destination on the container. Must be an absolute path.

                 Changed  in  version  2015.5.0:  If  the destination is a
                 directory, the file will be copied into that directory.

          overwrite
                 False Unless this option is set to True, then if  a  file
                 exists at the location specified by the dest argument, an
                 error will be raised.

                 New in version 2015.8.0.

          makedirs : False
             Create the parent directory on the container if it  does  not
             already exist.

             New in version 2015.5.0.

          CLI Example:

             salt 'minion' lxc.copy_to /tmp/foo /root/foo
             salt 'minion' lxc.cp /tmp/foo /root/foo

   salt.modules.lxc.create(name,         config=None,        profile=None,
   network_profile=None, nic_opts=None, **kwargs)
          Create a new container.

          name   Name of the container

          config The config file to use for  the  container.  Defaults  to
                 system-wide config (usually in /etc/lxc/lxc.conf).

          profile
                 Profile    to    use    in    container   creation   (see
                 lxc.get_container_profile). Values in a profile  will  be
                 overridden  by  the  Container  Creation Arguments listed
                 below.

          network_profile
                 Network profile to use for container

                 New in version 2015.5.0.

          Container Creation Arguments

          template
                 The template to  use.  For  example,  ubuntu  or  fedora.
                 Conflicts with the image argument.

                 NOTE:
                    The  download  template  requires  the following three
                    parameters to be defined in options:

                    * dist - The name of the distribution

                    * release - Release name/version

                    * arch - Architecture of the container

                    The  available  images  can  be   listed   using   the
                    lxc.images function.

          options
                 Template-specific  options  to  pass  to  the  lxc-create
                 command. These  correspond  to  the  long  options  (ones
                 beginning  with  two  dashes)  that  the  template script
                 accepts. For example:

                    options='{"dist": "centos", "release": "6", "arch": "amd64"}'

          image  A tar archive to use as the  rootfs  for  the  container.
                 Conflicts with the template argument.

          backing
                 The  type  of  storage  to  use. Set to lvm to use an LVM
                 group.  Defaults to filesystem within /var/lib/lxc.

          fstype Filesystem type to use on LVM logical volume

          size   1G Size of the  volume  to  create.  Only  applicable  if
                 backing=lvm.

          vgname lxc  Name  of the LVM volume group in which to create the
                 volume   for   this   container.   Only   applicable   if
                 backing=lvm.

          lvname Name  of  the  LVM  logical volume in which to create the
                 volume   for   this   container.   Only   applicable   if
                 backing=lvm.

          nic_opts
                 give extra opts overriding network profile values

          path   parent   path   for   the  container  creation  (default:
                 /var/lib/lxc)

          zfsroot
                 Name of the ZFS root in which to create  the  volume  for
                 this   container.    Only   applicable   if  backing=zfs.
                 (default: tank/lxc)

                 New in version 2015.8.0.

   salt.modules.lxc.destroy(name, stop=False, path=None)
          Destroy the named container.

          WARNING:
             Destroys all data associated with the container.

          path   path  to  the  container   parent   directory   (default:
                 /var/lib/lxc)

                 New in version 2015.8.0.

          stop   False If True, the container will be destroyed even if it
                 is running/frozen.

                 Changed in version 2015.5.0:  Default  value  changed  to
                 False.   This   more  closely  matches  the  behavior  of
                 lxc-destroy(1), and also makes it  less  likely  that  an
                 accidental  command will destroy a running container that
                 was being used for important things.

          CLI Examples:

             salt '*' lxc.destroy foo
             salt '*' lxc.destroy foo stop=True

   salt.modules.lxc.edit_conf(conf_file,              out_format='simple',
   read_only=False, lxc_config=None, **kwargs)
          Edit  an LXC configuration file. If a setting is already present
          inside the file, its value will be  replaced.  If  it  does  not
          exist,  it will be appended to the end of the file. Comments and
          blank lines will be kept in-tact if they already  exist  in  the
          file.

          out_format:
                 Set   to   simple  if  you  need  backward  compatibility
                 (multiple items for a simple key is not supported)

          read_only:
                 return only the edited configuration without applying  it
                 to the underlying lxc configuration file

          lxc_config:
                 List  of  dict  containning  lxc  configuration items For
                 network configuration, you also need to add the device it
                 belongs to, otherwise it will default to eth0.  Also, any
                 change to a network parameter will result  in  the  whole
                 network  reconfiguration  to avoid mismatchs, be aware of
                 that !

          After the file is edited, its  contents  will  be  returned.  By
          default,  it  will  be  returned  in  simple  format, meaning an
          unordered dict (which may not represent the actual file  order).
          Passing  in  an  out_format  of  commented  will  return  a data
          structure which accurately represents the order and  content  of
          the file.

          CLI Example:

             salt 'minion' lxc.edit_conf /etc/lxc/mycontainer.conf \
                 out_format=commented lxc.network.type=veth
             salt 'minion' lxc.edit_conf /etc/lxc/mycontainer.conf \
                 out_format=commented \
                 lxc_config="[{'lxc.network.name': 'eth0', \
                               'lxc.network.ipv4': '1.2.3.4'},
                              {'lxc.network.name': 'eth2', \
                               'lxc.network.ipv4': '1.2.3.5',\
                               'lxc.network.gateway': '1.2.3.1'}]"

   salt.modules.lxc.exists(name, path=None)
          Returns whether the named container exists.

          path   path   to   the   container  parent  directory  (default:
                 /var/lib/lxc)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.exists name

   salt.modules.lxc.freeze(name, **kwargs)
          Freeze the named container

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          start  False If True and the container is stopped, the container
                 will be started before attempting to freeze.

                 New in version 2015.5.0.

          use_vt run the command through VT

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.freeze name

   salt.modules.lxc.get_container_profile(name=None, **kwargs)
          New in version 2015.5.0.

          Gather  a  pre-configured   set   of   container   configuration
          parameters.  If  no  arguments  are  passed, an empty profile is
          returned.

          Profiles can be defined in the minion or master config files, or
          in  pillar  or  grains, and are loaded using config.get. The key
          under   which   LXC   profiles    must    be    configured    is
          lxc.container_profile.profile_name. An example container profile
          would be as follows:

             lxc.container_profile:
               ubuntu:
                 template: ubuntu
                 backing: lvm
                 vgname: lxc
                 size: 1G

          Parameters set  in  a  profile  can  be  overridden  by  passing
          additional container creation arguments (such as the ones passed
          to lxc.create) to this function.

          A profile can be defined either as the name of the profile, or a
          dictionary  of  variable  names and values. See the LXC Tutorial
          for more information on how to use LXC profiles.

          CLI Example:

             salt-call lxc.get_container_profile centos
             salt-call lxc.get_container_profile ubuntu template=ubuntu backing=overlayfs

   salt.modules.lxc.get_network_profile(name=None, **kwargs)
          New in version 2015.5.0.

          Gather a pre-configured set of network configuration parameters.
          If  no  arguments  are  passed, the following default profile is
          returned:

             {'eth0': {'link': 'br0', 'type': 'veth', 'flags': 'up'}}

          Profiles can be defined in the minion or master config files, or
          in  pillar  or  grains, and are loaded using config.get. The key
          under   which   LXC   profiles    must    be    configured    is
          lxc.network_profile.  An  example  network  profile  would be as
          follows:

             lxc.network_profile.centos:
               eth0:
                 link: br0
                 type: veth
                 flags: up

          To disable networking entirely:

             lxc.network_profile.centos:
               eth0:
                 disable: true

          Parameters set  in  a  profile  can  be  overridden  by  passing
          additional arguments to this function.

          A  profile can be passed either as the name of the profile, or a
          dictionary of variable names and values. See  the  LXC  Tutorial
          for more information on how to use network profiles.

          WARNING:
             The  ipv4,  ipv6,  gateway,  and  link  (bridge)  settings in
             network profiles will only  work  if  the  container  doesn't
             redefine   the   network   configuration   (for   example  in
             /etc/sysconfig/network-scripts/ifcfg-<interface_name>      on
             RHEL/CentOS,        or       /etc/network/interfaces       on
             Debian/Ubuntu/etc.)

          CLI Example:

             salt-call lxc.get_network_profile default

   salt.modules.lxc.get_parameter(name, parameter, path=None)
          Returns the value of a cgroup parameter for a container

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.get_parameter container_name memory.limit_in_bytes

   salt.modules.lxc.get_root_path(path)
          Get the configured lxc root for containers

          New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.get_root_path

   salt.modules.lxc.images(dist=None)
          New in version 2015.5.0.

          List the available images for LXC's download template.

          dist   None Filter results to a single Linux distribution

          CLI Examples:

             salt myminion lxc.images
             salt myminion lxc.images dist=centos

   salt.modules.lxc.info(name, path=None)
          Returns information about a container

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.info name

   salt.modules.lxc.init(name,  config=None,  cpuset=None,  cpushare=None,
   memory=None,    profile=None,    network_profile=None,   nic_opts=None,
   cpu=None,   autostart=True,   password=None,   password_encrypted=None,
   users=None,     dnsservers=None,    searchdomains=None,    bridge=None,
   gateway=None,   pub_key=None,    priv_key=None,    force_install=False,
   unconditional_install=False, bootstrap_delay=None, bootstrap_args=None,
   bootstrap_shell=None, bootstrap_url=None, **kwargs)
          Initialize a new container.

          This is a partial  idempotent  function  as  if  it  is  already
          provisioned,  we will reset a bit the lxc configuration file but
          much of the hard work will be escaped as  markers  will  prevent
          re-execution of harmful tasks.

          name   Name of the container

          image  A  tar  archive  to  use as the rootfs for the container.
                 Conflicts with the template argument.

          cpus   Select a random number of cpu cores and assign it to  the
                 cpuset, if the cpuset option is set then this option will
                 be ignored

          cpuset Explicitly define the cpus this container will  be  bound
                 to

          cpushare
                 cgroups cpu shares

          autostart
                 autostart container on reboot

          memory cgroups memory limit, in MB

                 Changed  in  version  2015.5.0: If no value is passed, no
                 limit is set. In earlier Salt versions, not passing  this
                 value  causes a 1024MB memory limit to be set, and it was
                 necessary to pass memory=0 to set no limit.

          gateway
                 the ipv4 gateway to use the  default  does  nothing  more
                 than lxcutils does

          bridge the  bridge  to  use  the  default does nothing more than
                 lxcutils does

          network_profile
                 Network profile to use for the container

                 New in version 2015.5.0.

          nic_opts
                 Extra options for network interfaces, will override

                 {"eth0":    {"hwaddr":    "aa:bb:cc:dd:ee:ff",    "ipv4":
                 "10.1.1.1", "ipv6": "2001:db8::ff00:42:8329"}}

                 or

                 {"eth0":    {"hwaddr":    "aa:bb:cc:dd:ee:ff",    "ipv4":
                 "10.1.1.1/24", "ipv6": "2001:db8::ff00:42:8329"}}

          users  Users for which the  password  defined  in  the  password
                 param  should  be set. Can be passed as a comma separated
                 list or a python list.  Defaults to just the root user.

          password
                 Set the initial password for the  users  defined  in  the
                 users parameter

          password_encrypted
                 False  Set to True to denote a password hash instead of a
                 plaintext password

                 New in version 2015.5.0.

          profile
                 A LXC profile (defined in config or pillar).  This can be
                 either  a real profile mapping or a string to retrieve it
                 in configuration

          start  Start the newly-created container

          dnsservers
                 list of dns servers to set in the container,  default  []
                 (no setting)

          seed   Seed the container with the minion config. Default: True

          install
                 If  salt-minion  is  not  already  installed, install it.
                 Default: True

          config Optional config parameters. By default, the id is set  to
                 the name of the container.

          master salt master (default to minion's master)

          master_port
                 salt master port (default to minion's master port)

          pub_key
                 Explicit   public   key   to   preseed  the  minion  with
                 (optional).  This can be either a filepath  or  a  string
                 representing the key

          priv_key
                 Explicit   private   key   to  preseed  the  minion  with
                 (optional).  This can be either a filepath  or  a  string
                 representing the key

          approve_key
                 If  explicit  preseeding  is not used; Attempt to request
                 key approval from the master. Default: True

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          clone_from
                 Original  from  which  to use a clone operation to create
                 the container.  Default: None

          bootstrap_delay
                 Delay in seconds between end of  container  creation  and
                 bootstrapping.   Useful  when  waiting  for  container to
                 obtain a DHCP lease.

                 New in version 2015.5.0.

          bootstrap_url
                 See lxc.bootstrap

          bootstrap_shell
                 See lxc.bootstrap

          bootstrap_args
                 See lxc.bootstrap

          force_install
                 Force installation even if salt-minion is detected,  this
                 is the way to run vendor bootstrap scripts even if a salt
                 minion is already present in the container

          unconditional_install
                 Run the script even if the container seems seeded

          CLI Example:

             salt 'minion' lxc.init name [cpuset=cgroups_cpuset] \
                     [cpushare=cgroups_cpushare] [memory=cgroups_memory] \
                     [nic=nic_profile] [profile=lxc_profile] \
                     [nic_opts=nic_opts] [start=(True|False)] \
                     [seed=(True|False)] [install=(True|False)] \
                     [config=minion_config] [approve_key=(True|False) \
                     [clone_from=original] [autostart=True] \
                     [priv_key=/path_or_content] [pub_key=/path_or_content] \
                     [bridge=lxcbr0] [gateway=10.0.3.1] \
                     [dnsservers[dns1,dns2]] \
                     [users=[foo]] [password='secret'] \
                     [password_encrypted=(True|False)]

   salt.modules.lxc.list(extra=False, limit=None, path=None)
          List containers classified by state

          extra  Also get per-container specific info.  This  will  change
                 the   return  data.   Instead  of  returning  a  list  of
                 containers,  a  dictionary   of   containers   and   each
                 container's output from lxc.info.

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          limit  Return output matching a specific state (frozen, running,
                 or stopped).

                 New in version 2015.5.0.

          CLI Examples:

             salt '*' lxc.list
             salt '*' lxc.list extra=True
             salt '*' lxc.list limit=running

   salt.modules.lxc.ls(active=None, cache=True, path=None)
          Return a list of the containers available on the minion

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          active If True, return only active (i.e. running) containers

                 New in version 2015.5.0.

          CLI Example:

             salt '*' lxc.ls
             salt '*' lxc.ls active=True

   salt.modules.lxc.read_conf(conf_file, out_format='simple')
          Read in an LXC configuration file. By default returns a  simple,
          unsorted  dict,  but  can  also return a more detailed structure
          including blank lines and comments.

          out_format:
                 set to 'simple' if  you  need  the  old  and  unsupported
                 behavior.   This  won't  support  the multiple lxc values
                 (eg: multiple network nics)

          CLI Examples:

             salt 'minion' lxc.read_conf /etc/lxc/mycontainer.conf
             salt 'minion' lxc.read_conf /etc/lxc/mycontainer.conf out_format=commented

   salt.modules.lxc.reboot(name, path=None)
          Reboot a container.

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Examples:

             salt 'minion' lxc.reboot myvm

   salt.modules.lxc.reconfigure(name,        cpu=None,        cpuset=None,
   cpushare=None,   memory=None,    profile=None,    network_profile=None,
   nic_opts=None, bridge=None, gateway=None, autostart=None, utsname=None,
   rootfs=None, path=None, **kwargs)
          Reconfigure a container.

          This only applies to a few property

          name   Name of the container.

          utsname
                 utsname of the container.

                 New in version 2016.3.0.

          rootfs rootfs of the container.

                 New in version 2016.3.0.

          cpu    Select a random number of cpu cores and assign it to  the
                 cpuset, if the cpuset option is set then this option will
                 be ignored

          cpuset Explicitly define the cpus this container will  be  bound
                 to

          cpushare
                 cgroups cpu shares.

          autostart
                 autostart container on reboot

          memory cgroups  memory  limit,  in MB.  (0 for nolimit, None for
                 old default 1024MB)

          gateway
                 the ipv4 gateway to use the  default  does  nothing  more
                 than lxcutils does

          bridge the  bridge  to  use  the  default does nothing more than
                 lxcutils does

          nic    Network interfaces profile (defined in config or pillar).

          nic_opts
                 Extra options for network interfaces, will override

                 {"eth0": {"mac": "aa:bb:cc:dd:ee:ff", "ipv4": "10.1.1.1",
                 "ipv6": "2001:db8::ff00:42:8329"}}

                 or

                 {"eth0":     {"mac":     "aa:bb:cc:dd:ee:ff",     "ipv4":
                 "10.1.1.1/24", "ipv6": "2001:db8::ff00:42:8329"}}

          path   path to the container parent

                 New in version 2015.8.0.

          CLI Example:

             salt-call -lall mc_lxc_fork.reconfigure foobar nic_opts="{'eth1': {'mac': '00:16:3e:dd:ee:44'}}" memory=4

   salt.modules.lxc.restart(name, path=None, lxc_config=None, force=False)
          New in version 2015.5.0.

          Restart the named container. If the container was  not  running,
          the container will merely be started.

          name   The name of the container

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          lxc_config
                 path to a lxc config file config  file  will  be  guessed
                 from container name otherwise

                 New in version 2015.8.0.

          force  False  If  True,  the  container  will  be  force-stopped
                 instead of gracefully shut down

          CLI Example:

             salt myminion lxc.restart name

   salt.modules.lxc.retcode(name,           cmd,           no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug', use_vt=False, path=None, ignore_retcode=False,
   chroot_fallback=False, keep_env='http_proxy, https_proxy, no_proxy')
          New in version 2015.5.0.

          Run cmd.retcode within a container

          WARNING:
             Many  shell builtins do not work, failing with stderr similar
             to the following:

                 lxc_container: No such file or directory - failed to exec 'command'

             The same error will be displayed in  stderr  if  the  command
             being  run  does not exist. If the retcode is nonzero and not
             what was expected, try using lxc.run_stderr or lxc.run_all.

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True After running the command, return the  container  to
                 its previous state

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console output=all.

          keep_env
                 http_proxy,https_proxy,no_proxy A list  of  env  vars  to
                 preserve. May be passed as commma-delimited list.

          chroot_fallback
                 if  the  container is not running, try to run the command
                 using chroot default: false

          CLI Example:

             salt myminion lxc.retcode mycontainer 'ip addr show'

   salt.modules.lxc.run(name,  cmd,  no_start=False,  preserve_state=True,
   stdin=None,  python_shell=True,  output_loglevel='debug', use_vt=False,
   path=None,         ignore_retcode=False,         chroot_fallback=False,
   keep_env='http_proxy, https_proxy, no_proxy')
          New in version 2015.8.0.

          Run cmd.run within a container

          WARNING:
             Many  shell builtins do not work, failing with stderr similar
             to the following:

                 lxc_container: No such file or directory - failed to exec 'command'

             The same error will be displayed in  stderr  if  the  command
             being run does not exist. If no output is returned using this
             function, try using lxc.run_stderr or lxc.run_all.

          name   Name of the container in which to run the command

          cmd    Command to run

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True  After  running the command, return the container to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console. Assumes output=all.

          chroot_fallback
                 if the container is not running, try to run  the  command
                 using chroot default: false

          keep_env
                 http_proxy,https_proxy,no_proxy  A  list  of  env vars to
                 preserve. May be passed as commma-delimited list.

          CLI Example:

             salt myminion lxc.run mycontainer 'ifconfig -a'

   salt.modules.lxc.run_all(name,           cmd,           no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug', use_vt=False, path=None, ignore_retcode=False,
   chroot_fallback=False, keep_env='http_proxy, https_proxy, no_proxy')
          New in version 2015.5.0.

          Run cmd.run_all within a container

          NOTE:
             While  the  command  is  run  within  the  container,  it  is
             initiated from the host. Therefore, the  PID  in  the  return
             dict is from the host, not from the container.

          WARNING:
             Many  shell builtins do not work, failing with stderr similar
             to the following:

                 lxc_container: No such file or directory - failed to exec 'command'

             The same error will be displayed in  stderr  if  the  command
             being run does not exist.

          name   Name of the container in which to run the command

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True After running the command, return the  container  to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console output=all.

          keep_env
                 http_proxy,https_proxy,no_proxy  A  list  of  env vars to
                 preserve. May be passed as commma-delimited list.

          chroot_fallback
                 if the container is not running, try to run  the  command
                 using chroot default: false

          CLI Example:

             salt myminion lxc.run_all mycontainer 'ip addr show'

   salt.modules.lxc.run_stderr(name,          cmd,         no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug', use_vt=False, path=None, ignore_retcode=False,
   chroot_fallback=False, keep_env='http_proxy, https_proxy, no_proxy')
          New in version 2015.5.0.

          Run cmd.run_stderr within a container

          WARNING:
             Many shell builtins do not work, failing with stderr  similar
             to the following:

                 lxc_container: No such file or directory - failed to exec 'command'

             The  same  error  will  be displayed if the command being run
             does not exist.

          name   Name of the container in which to run the command

          cmd    Command to run

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True  After  running the command, return the container to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console output=all.

          keep_env
                 http_proxy,https_proxy,no_proxy A list  of  env  vars  to
                 preserve. May be passed as commma-delimited list.

          chroot_fallback
                 if  the  container is not running, try to run the command
                 using chroot default: false

          CLI Example:

             salt myminion lxc.run_stderr mycontainer 'ip addr show'

   salt.modules.lxc.run_stdout(name,         cmd,          no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug', use_vt=False, path=None, ignore_retcode=False,
   chroot_fallback=False, keep_env='http_proxy, https_proxy, no_proxy')
          New in version 2015.5.0.

          Run cmd.run_stdout within a container

          WARNING:
             Many  shell builtins do not work, failing with stderr similar
             to the following:

                 lxc_container: No such file or directory - failed to exec 'command'

             The same error will be displayed in  stderr  if  the  command
             being run does not exist. If no output is returned using this
             function, try using lxc.run_stderr or lxc.run_all.

          name   Name of the container in which to run the command

          cmd    Command to run

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True  After  running the command, return the container to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console output=all.

          keep_env
                 http_proxy,https_proxy,no_proxy A list  of  env  vars  to
                 preserve. May be passed as commma-delimited list.

          chroot_fallback
                 if  the  container is not running, try to run the command
                 using chroot default: false

          CLI Example:

             salt myminion lxc.run_stdout mycontainer 'ifconfig -a'

   salt.modules.lxc.running_systemd(name, cache=True, path=None)
          Determine if systemD is running

          path   path to the container parent

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.running_systemd ubuntu

   salt.modules.lxc.search_lxc_bridge()
          Search the first bridge which is potentially  available  as  LXC
          bridge

          CLI Example:

             salt '*' lxc.search_lxc_bridge

   salt.modules.lxc.search_lxc_bridges()
          Search which bridges are potentially available as LXC bridges

          CLI Example:

             salt '*' lxc.search_lxc_bridges

   salt.modules.lxc.set_dns(name,   dnsservers=None,   searchdomains=None,
   path=None)
          Changed in version 2015.5.0: The  dnsservers  and  searchdomains
          parameters can now be passed as a comma-separated list.

          Update /etc/resolv.confo

          path
             path  to  the  container parent default: /var/lib/lxc (system
             default)

             New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.set_dns ubuntu "['8.8.8.8', '4.4.4.4']"

   salt.modules.lxc.set_parameter(name, parameter, value, path=None)
          Set the value of a cgroup parameter for a container.

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.set_parameter name parameter value

   salt.modules.lxc.set_password(name,  users,  password,  encrypted=True,
   path=None)
          Changed in version 2015.5.0: Function renamed from  set_pass  to
          set_password.  Additionally,  this  function  now  supports (and
          defaults to using)  a  password  hash  instead  of  a  plaintext
          password.

          Set the password of one or more system users inside containers

          users  Comma-separated  list (or python list) of users to change
                 password

          password
                 Password to set for the specified user(s)

          encrypted
                 True If true, password must be a password  hash.  Set  to
                 False to set a plaintext password (not recommended).

                 New in version 2015.5.0.

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.set_pass container-name root '$6$uJ2uAyLU$KoI67t8As/0fXtJOPcHKGXmUpcoYUcVR2K6x93walnShTCQvjRwq25yIkiCBOqgbfdKQSFnAo28/ek6716vEV1'
             salt '*' lxc.set_pass container-name root foo encrypted=False

   salt.modules.lxc.start(name, **kwargs)
          Start the named container

          path   path  to  the   container   parent   directory   default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          lxc_config
                 path  to  a  lxc  config file config file will be guessed
                 from container name otherwise

                 New in version 2015.8.0.

          use_vt run the command through VT

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.start name

   salt.modules.lxc.state(name, path=None)
          Returns the state of a container.

          path   path  to  the  container   parent   directory   (default:
                 /var/lib/lxc)

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.state name

   salt.modules.lxc.stop(name, kill=False, path=None, use_vt=None)
          Stop the named container

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          kill: False
                 Do not wait for the container to stop, kill all tasks  in
                 the  container.   Older LXC versions will stop containers
                 like this irrespective of this argument.

                 Changed in version 2015.5.0:  Default  value  changed  to
                 False

          use_vt run the command through VT

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.stop name

   salt.modules.lxc.systemd_running_state(name, path=None)
          Get the operational state of a systemd based container

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.systemd_running_state ubuntu

   salt.modules.lxc.templates()
          New in version 2015.5.0.

          List the available LXC template scripts installed on the minion

          CLI Examples:

             salt myminion lxc.templates

   salt.modules.lxc.test_bare_started_state(name, path=None)
          Test if a non systemd container is fully  started  For  now,  it
          consists only to test if the container is attachable

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.test_bare_started_state ubuntu

   salt.modules.lxc.test_sd_started_state(name, path=None)
          Test if a systemd container is fully started

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.test_sd_started_state ubuntu

   salt.modules.lxc.unfreeze(name, path=None, use_vt=None)
          Unfreeze the named container.

          path   path   to   the   container   parent  directory  default:
                 /var/lib/lxc (system)

                 New in version 2015.8.0.

          use_vt run the command through VT

                 New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.unfreeze name

   salt.modules.lxc.update_lxc_conf(name,    lxc_conf,     lxc_conf_unset,
   path=None)
          Edit LXC configuration options

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.update_lxc_conf ubuntu \
                     lxc_conf="[{'network.ipv4.ip':'10.0.3.5'}]" \
                     lxc_conf_unset="['lxc.utsname']"

   salt.modules.lxc.version()
          Return the actual lxc client version

          New in version 2015.8.0.

          CLI Example:

             salt '*' lxc.version

   salt.modules.lxc.wait_started(name, path=None, timeout=300)
          Check that the system has fully inited

          This is actually very important for systemD based containers

          see https://github.com/saltstack/salt/issues/23847

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          CLI Example:

             salt myminion lxc.wait_started ubuntu

   salt.modules.lxc.write_conf(conf_file, conf)
          Write out an LXC configuration file

          This  is  normally  only used internally. The format of the data
          structure   must   match   that   which   is    returned    from
          lxc.read_conf(), with out_format set to commented.

          An example might look like:

             [
                 {'lxc.utsname': '$CONTAINER_NAME'},
                 '# This is a commented line\n',
                 '\n',
                 {'lxc.mount': '$CONTAINER_FSTAB'},
                 {'lxc.rootfs': {'comment': 'This is another test',
                                 'value': 'This is another test'}},
                 '\n',
                 {'lxc.network.type': 'veth'},
                 {'lxc.network.flags': 'up'},
                 {'lxc.network.link': 'br0'},
                 {'lxc.network.mac': '$CONTAINER_MACADDR'},
                 {'lxc.network.ipv4': '$CONTAINER_IPADDR'},
                 {'lxc.network.name': '$CONTAINER_DEVICENAME'},
             ]

          CLI Example:

             salt 'minion' lxc.write_conf /etc/lxc/mycontainer.conf \
                 out_format=commented

   salt.modules.mac_assistive module
   This  module allows you to manage assistive access on OS X minions with
   10.9+

   New in version 2016.3.0.

      salt '*' assistive.install /usr/bin/osascript

   salt.modules.mac_assistive.enable(app_id, enabled=True)
          Enable or disable an existing assistive access application.

          app_id The bundle ID or command to set assistive access status.

          enabled
                 Sets enabled or disabled status. Default is True.

          CLI Example:

             salt '*' assistive.enable /usr/bin/osascript
             salt '*' assistive.enable com.smileonmymac.textexpander enabled=False

   salt.modules.mac_assistive.enabled(app_id)
          Check if a bundle ID or command is listed  in  assistive  access
          and enabled.

          app_id The  bundle  ID  or  command to retrieve assistive access
                 status.

          CLI Example:

             salt '*' assistive.enabled /usr/bin/osascript
             salt '*' assistive.enabled com.smileonmymac.textexpander

   salt.modules.mac_assistive.install(app_id, enable=True)
          Install a bundle ID or command as being allowed to use assistive
          access.

          app_id The bundle ID or command to install for assistive access.

          enabled
                 Sets enabled or disabled status. Default is True.

          CLI Example:

             salt '*' assistive.install /usr/bin/osascript
             salt '*' assistive.install com.smileonmymac.textexpander

   salt.modules.mac_assistive.installed(app_id)
          Check  if  a bundle ID or command is listed in assistive access.
          This will not check to see if it's enabled.

          app_id The bundle ID or command to check installed status.

          CLI Example:

             salt '*' assistive.installed /usr/bin/osascript
             salt '*' assistive.installed com.smileonmymac.textexpander

   salt.modules.mac_assistive.remove(app_id)
          Remove a bundle ID or command as being allowed to use  assistive
          access.

          app_id The  bundle ID or command to remove from assistive access
                 list.

          CLI Example:

             salt '*' assistive.remove /usr/bin/osascript
             salt '*' assistive.remove com.smileonmymac.textexpander

   salt.modules.mac_brew module
   Homebrew for Mac OS X

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on  a  minion, and it is using a different module (or gives an error
      similar to 'pkg.install' is not available), see here.

   salt.modules.mac_brew.available_version(*names, **kwargs)
          This function is an alias of latest_version.
             Return the latest version of the named package available  for
             upgrade or installation

             Currently  chooses  stable versions, falling back to devel if
             that does not exist.

             CLI Example:

                 salt '*' pkg.latest_version <package name>
                 salt '*' pkg.latest_version <package1> <package2> <package3>

   salt.modules.mac_brew.info_installed(*names)
          Return the information of the named package(s) installed on  the
          system.

          New in version 2016.3.1.

          names  The   names   of   the   packages  for  which  to  return
                 information.

          CLI example:

             salt '*' pkg.info_installed <package1>
             salt '*' pkg.info_installed <package1> <package2> <package3> ...

   salt.modules.mac_brew.install(name=None,     pkgs=None,      taps=None,
   options=None, **kwargs)
          Install the passed package(s) with brew install

          name   The  name  of the formula to be installed. Note that this
                 parameter is ignored if "pkgs" is passed.

                 CLI Example:

                    salt '*' pkg.install <package name>

          taps   Unofficial  GitHub  repos  to  use  when   updating   and
                 installing formulas.

                 CLI Example:

                    salt '*' pkg.install <package name> tap='<tap>'
                    salt '*' pkg.install zlib taps='homebrew/dupes'
                    salt '*' pkg.install php54 taps='["josegonzalez/php", "homebrew/dupes"]'

          options
                 Options to pass to brew. Only applies to initial install.
                 Due to how brew works, modifying chosen options  requires
                 a  full  uninstall followed by a fresh install. Note that
                 if "pkgs" is used, all options  will  be  passed  to  all
                 packages.  Unrecognized  options  for  a  package will be
                 silently ignored by brew.

                 CLI Example:

                    salt '*' pkg.install <package name> tap='<tap>'
                    salt '*' pkg.install php54 taps='["josegonzalez/php", "homebrew/dupes"]' options='["--with-fpm"]'

          Multiple Package Installation Options:

          pkgs   A list of formulas to install. Must be passed as a python
                 list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo","bar"]'

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.install 'package package package'

   salt.modules.mac_brew.latest_version(*names, **kwargs)
          Return  the  latest  version  of the named package available for
          upgrade or installation

          Currently chooses stable versions, falling back to devel if that
          does not exist.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3>

   salt.modules.mac_brew.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.mac_brew.list_upgrades(refresh=True, **kwargs)
          Check whether or not an upgrade is available for all packages

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.mac_brew.refresh_db()
          Update the homebrew package repository.

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.mac_brew.remove(name=None, pkgs=None, **kwargs)
          Removes packages with brew uninstall.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.mac_brew.upgrade(refresh=True)
          Upgrade outdated, unpinned brews.

          refresh
                 Fetch  the  newest  version  of Homebrew and all formulae
                 from GitHub before installing.

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.mac_brew.upgrade_available(pkg)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.mac_brew.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3>

   salt.modules.mac_defaults module
   Set defaults on Mac OS

   salt.modules.mac_defaults.delete(domain, key, user=None)
          Delete a default from the system

          CLI Example:

             salt '*' macdefaults.delete com.apple.CrashReporter DialogType

             salt '*' macdefaults.delete NSGlobalDomain ApplePersistence

          domain The name of the domain to delete from

          key    The key of the given domain to delete

          user   The user to delete the defaults with

   salt.modules.mac_defaults.read(domain, key, user=None)
          Write a default to the system

          CLI Example:

             salt '*' macdefaults.read com.apple.CrashReporter DialogType

             salt '*' macdefaults.read NSGlobalDomain ApplePersistence

          domain The name of the domain to read from

          key    The key of the given domain to read from

          user   The user to write the defaults to

   salt.modules.mac_defaults.write(domain,  key,   value,   type='string',
   user=None)
          Write a default to the system

          CLI Example:

             salt '*' macdefaults.write com.apple.CrashReporter DialogType Server

             salt '*' macdefaults.write NSGlobalDomain ApplePersistence True type=bool

          domain The name of the domain to write to

          key    The key of the given domain to write to

          value  The value to write to the given key

          type   The  type of value to be written, valid types are string,
                 data,   int[eger],   float,   bool[ean],   date,   array,
                 array-add, dict, dict-add

          user   The user to write the defaults to

   salt.modules.mac_desktop module
   Mac OS X implementations of various commands in the "desktop" interface

   salt.modules.mac_desktop.get_output_volume()
          Get the output volume (range 0 to 100)

          CLI Example:

             salt '*' desktop.get_output_volume

   salt.modules.mac_desktop.lock()
          Lock the desktop session

          CLI Example:

             salt '*' desktop.lock

   salt.modules.mac_desktop.say(*words)
          Say some words.

          words  The words to execute the say command with.

          CLI Example:

             salt '*' desktop.say <word0> <word1> ... <wordN>

   salt.modules.mac_desktop.screensaver()
          Launch the screensaver.

          CLI Example:

             salt '*' desktop.screensaver

   salt.modules.mac_desktop.set_output_volume(volume)
          Set the volume of sound.

          volume The level of volume. Can range from 0 to 100.

          CLI Example:

             salt '*' desktop.set_output_volume <volume>

   salt.modules.mac_group
   Manage groups on Mac OS 10.7+

   salt.modules.mac_group.add(name, gid=None, **kwargs)
          Add the specified group

          CLI Example:

             salt '*' group.add foo 3456

   salt.modules.mac_group.adduser(group, name)
          Add a user in the group.

          CLI Example:

             salt '*' group.adduser foo bar

          Verifies  if  a  valid username 'bar' as a member of an existing
          group 'foo', if not then adds it.

   salt.modules.mac_group.chgid(name, gid)
          Change the gid for a named group

          CLI Example:

             salt '*' group.chgid foo 4376

   salt.modules.mac_group.delete(name)
          Remove the named group

          CLI Example:

             salt '*' group.delete foo

   salt.modules.mac_group.deluser(group, name)
          Remove a user from the group

          New in version 2016.3.0.

          CLI Example:

             salt '*' group.deluser foo bar

          Removes a member user 'bar' from a group 'foo'. If group is  not
          present then returns True.

   salt.modules.mac_group.getent(refresh=False)
          Return info on all groups

          CLI Example:

             salt '*' group.getent

   salt.modules.mac_group.info(name)
          Return information about a group

          CLI Example:

             salt '*' group.info foo

   salt.modules.mac_group.members(name, members_list)
          Replaces members of the group with a provided list.

          New in version 2016.3.0.

          CLI Example:
             salt '*' group.members foo 'user1,user2,user3,...'

          Replaces a membership list for a local group 'foo'.

   salt.modules.mac_keychain module
   Install certificates into the keychain on Mac OS

   New in version 2016.3.0.

   salt.modules.mac_keychain.get_default_keychain(user=None,
   domain='user')
          Get the default keychain

          user   The user to check the default keychain of

          domain The    domain     to     use     valid     values     are
                 user|system|common|dynamic, the default is user

          CLI Example:

             salt '*' keychain.get_default_keychain

   salt.modules.mac_keychain.get_friendly_name(cert, password)
          Get the friendly name of the given certificate

          cert   The certificate to install

          password
                 The   password   for   the  certificate  being  installed
                 formatted in the way described for openssl command in the
                 PASS PHRASE ARGUMENTS section

                 Note:  The  password given here will show up as plaintext
                 in the returned job info.

          CLI Example:

             salt '*' keychain.get_friendly_name /tmp/test.p12 test123

   salt.modules.mac_keychain.get_hash(name, password=None)
          Returns the hash of a certificate in the keychain.

          name   The name of the  certificate  (which  you  can  get  from
                 keychain.get_friendly_name)  or  the  location  of  a p12
                 file.

          password
                 The password  that  is  used  in  the  certificate.  Only
                 required  if your passing a p12 file.  Note: This will be
                 outputted to logs

          CLI Example:

             salt '*' keychain.get_hash /tmp/test.p12 test123

   salt.modules.mac_keychain.install(cert,                       password,
   keychain='/Library/Keychains/System.keychain',         allow_any=False,
   keychain_password=None)
          Install a certificate

          cert   The certificate to install

          password
                 The  password  for  the   certificate   being   installed
                 formatted in the way described for openssl command in the
                 PASS PHRASE ARGUMENTS section.

                 Note: The password given here will show up  as  plaintext
                 in the job returned info.

          keychain
                 The keychain to install the certificate to, this defaults
                 to /Library/Keychains/System.keychain

          allow_any
                 Allow any application to access the imported  certificate
                 without warning

          keychain_password
                 If your keychain is likely to be locked pass the password
                 and it will be unlocked before running the import

                 Note: The password given here will show up  as  plaintext
                 in the returned job info.

          CLI Example:

             salt '*' keychain.install test.p12 test123

   salt.modules.mac_keychain.list_certs(keychain='/Library/Keychains/System.keychain')
          List all of the installed certificates

          keychain
                 The keychain to install the certificate to, this defaults
                 to /Library/Keychains/System.keychain

          CLI Example:

             salt '*' keychain.list_certs

   salt.modules.mac_keychain.set_default_keychain(keychain, domain='user',
   user=None)
          Set the default keychain

          keychain
                 The location of the keychain to set as default

          domain The    domain     to     use     valid     values     are
                 user|system|common|dynamic, the default is user

          user   The user to set the default keychain as

          CLI Example:

             salt '*' keychain.set_keychain /Users/fred/Library/Keychains/login.keychain

   salt.modules.mac_keychain.uninstall(cert_name,
   keychain='/Library/Keychains/System.keychain', keychain_password=None)
          Uninstall a certificate from a keychain

          cert_name
                 The name of the certificate to remove

          keychain
                 The keychain to install the certificate to, this defaults
                 to /Library/Keychains/System.keychain

          keychain_password
                 If your keychain is likely to be locked pass the password
                 and it will be unlocked before running the import

                 Note: The password given here will show up  as  plaintext
                 in the returned job info.

          CLI Example:

             salt '*' keychain.install test.p12 test123

   salt.modules.mac_keychain.unlock_keychain(keychain, password)
          Unlock the given keychain with the password

          keychain
                 The keychain to unlock

          password
                 The password to use to unlock the keychain.

                 Note:  The  password given here will show up as plaintext
                 in the returned job info.

          CLI Example:

             salt '*' keychain.unlock_keychain /tmp/test.p12 test123

   salt.modules.mac_package module
   Install pkg, dmg and .app applications on Mac OS X minions.

   salt.modules.mac_package.get_mpkg_ids(mpkg)
          Attempt to get the package IDs from a mounted .mpkg file

          Parameters
                 mpkg (str) -- The location of the mounted mpkg file

          Returns
                 List of package IDs

          Return type
                 list

          CLI Example:

             salt '*' macpackage.get_mpkg_ids /dev/disk2

   salt.modules.mac_package.get_pkg_id(pkg)
          Attempt to get the package ID from a .pkg file

          Parameters
                 pkg (str) -- The location of the pkg file

          Returns
                 List of all of the package IDs

          Return type
                 list

          CLI Example:

             salt '*' macpackage.get_pkg_id /tmp/test.pkg

   salt.modules.mac_package.install(pkg,             target='LocalSystem',
   store=False, allow_untrusted=False)
          Install a pkg file

          Parameters

                 * pkg (str) -- The package to install

                 * target  (str)  --  The  target  in which to install the
                   package to

                 * store (bool) -- Should the package be installed  as  if
                   it was from the store?

                 * allow_untrusted  (bool)  --  Allow  the installation of
                   untrusted packages?

          Returns
                 A dictionary containing the results of the installation

          Return type
                 dict

          CLI Example:

             salt '*' macpackage.install test.pkg

   salt.modules.mac_package.install_app(app, target='/Applications/')
          Install an app file by moving it into the specified Applications
          directory

          Parameters

                 * app (str) -- The location of the .app file

                 * target  (str)  --  The  target  in which to install the
                   package to Default is ''/Applications/''

          Returns
                 The results of the rsync command

          Return type
                 str

          CLI Example:

             salt '*' macpackage.install_app /tmp/tmp.app /Applications/

   salt.modules.mac_package.installed_pkgs()
          Return the list of installed packages on the machine

          Returns
                 List of installed packages

          Return type
                 list

          CLI Example:

             salt '*' macpackage.installed_pkgs

   salt.modules.mac_package.mount(dmg)
          Attempt to mount a dmg file to a temporary location  and  return
          the location of the pkg file inside

          Parameters
                 dmg (str) -- The location of the dmg file to mount

          Returns

                 Tuple  containing  the  results of the command along with
                 the mount
                        point

          Return type
                 tuple

          CLI Example:

             salt '*' macpackage.mount /tmp/software.dmg

   salt.modules.mac_package.uninstall_app(app)
          Uninstall an app file  by  removing  it  from  the  Applications
          directory

          Parameters
                 app (str) -- The location of the .app file

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' macpackage.uninstall_app /Applications/app.app

   salt.modules.mac_package.unmount(mountpoint)
          Attempt to unmount a dmg file from a temporary location

          Parameters
                 mountpoint (str) -- The location of the mount point

          Returns
                 The results of the hdutil detach command

          Return type
                 str

          CLI Example:

             salt '*' macpackage.unmount /dev/disk2

   salt.modules.mac_pkgutil module
   Installer support for OS X.

   Installer is the native .pkg/.mpkg package manager for OS X.

   salt.modules.mac_pkgutil.forget(package_id)
          New in version 2016.3.0.

          Remove  the  receipt  data about the specified package. Does not
          remove files.

          WARNING:
             DO NOT use this command to fix broken package design

          Parameters
                 package_id (str) -- The name of the package to forget

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' pkgutil.forget com.apple.pkg.gcc4.2Leo

   salt.modules.mac_pkgutil.install(source, package_id)
          Install a .pkg from an URI or an absolute path.

          Parameters

                 * source (str) -- The path to a package.

                 * package_id (str) -- The package ID

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' pkgutil.install source=/vagrant/build_essentials.pkg package_id=com.apple.pkg.gcc4.2Leo

   salt.modules.mac_pkgutil.is_installed(package_id)
          Returns whether a given package id is installed.

          Returns
                 True if installed, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' pkgutil.is_installed com.apple.pkg.gcc4.2Leo

   salt.modules.mac_pkgutil.list()
          List the installed packages.

          Returns
                 A list of installed packages

          Return type
                 list

          CLI Example:

             salt '*' pkgutil.list

   salt.modules.mac_ports module
   Support for MacPorts under Mac OSX.

   This module has some caveats.

   1.   Updating   the   database   of   available    ports    is    quite
   resource-intensive.   However,  refresh=True  is  the  default  for all
   operations that need an up-to-date copy of available  ports.   Consider
   refresh=False when you are sure no db update is needed.

   2.  In  some cases MacPorts doesn't always realize when another copy of
   itself is running and will gleefully tromp all over the available ports
   database.   This  makes MacPorts behave in undefined ways until a fresh
   complete copy is retrieved.

   Because of 1 and 2 it is possible to get the salt-minion into  a  state
   where salt mac-machine pkg./something/ won't want to return.  Use

   salt-run jobs.active

   on the master to check for potentially long-running calls to port.

   Finally, ports database updates are always handled with port selfupdate
   as opposed to port  sync.   This  makes  sense  in  the  MacPorts  user
   commmunity  but  may  confuse experienced Linux admins as Linux package
   managers don't upgrade the packaging  software  when  doing  a  package
   database  update.   In  other  words salt mac-machine pkg.refresh_db is
   more like apt-get update; apt-get  upgrade  dpkg  apt-get  than  simply
   apt-get update.

   salt.modules.mac_ports.available_version(*names, **kwargs)
          This function is an alias of latest_version.
             Return  the latest version of the named package available for
             upgrade or installation

             Options:

             refresh
                    Update ports with port selfupdate

             CLI Example:

                 salt '*' pkg.latest_version <package name>
                 salt '*' pkg.latest_version <package1> <package2> <package3>

   salt.modules.mac_ports.install(name=None,   refresh=False,   pkgs=None,
   **kwargs)
          Install the passed package(s) with port install

          name   The  name  of the formula to be installed. Note that this
                 parameter is ignored if "pkgs" is passed.

                 CLI Example:

                    salt '*' pkg.install <package name>

          version
                 Specify a version to pkg to install. Ignored if  pkgs  is
                 specified.

                 CLI Example:

                    salt '*' pkg.install <package name>
                    salt '*' pkg.install git-core version='1.8.5.5'

          variant
                 Specify  a  variant to pkg to install. Ignored if pkgs is
                 specified.

                 CLI Example:

                    salt '*' pkg.install <package name>
                    salt '*' pkg.install git-core version='1.8.5.5' variant='+credential_osxkeychain+doc+pcre'

          Multiple Package Installation Options:

          pkgs   A list of formulas to install. Must be passed as a python
                 list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo","bar"]'
                    salt '*' pkg.install pkgs='["[email protected]","bar"]'
                    salt '*' pkg.install pkgs='["[email protected]+ssl","[email protected]"]'

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.install 'package package package'

   salt.modules.mac_ports.latest_version(*names, **kwargs)
          Return  the  latest  version  of the named package available for
          upgrade or installation

          Options:

          refresh
                 Update ports with port selfupdate

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3>

   salt.modules.mac_ports.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.mac_ports.list_upgrades(refresh=True, **kwargs)
          Check whether or not an upgrade is available for all packages

          Options:

          refresh
                 Update ports with port selfupdate

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.mac_ports.refresh_db()
          Update ports with port selfupdate

   salt.modules.mac_ports.remove(name=None, pkgs=None, **kwargs)
          Removes packages with port uninstall.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.mac_ports.upgrade(refresh=True)
          Run a full upgrade using MacPorts 'port upgrade outdated'

          Options:

          refresh
                 Update ports with port selfupdate

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.mac_ports.upgrade_available(pkg, refresh=True)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.mac_ports.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3>

   salt.modules.mac_power module
   Module for editing power settings on Mac OS X
      New in version 2016.3.0.

   salt.modules.mac_power.get_computer_sleep()
          Display the amount of idle time until the computer sleeps.

          Returns
                 A string representing the sleep settings for the computer

          Return type
                 str

          CLI Example:

          ..code-block:: bash
             salt '*' power.get_computer_sleep

   salt.modules.mac_power.get_display_sleep()
          Display the amount of idle time until the display sleeps.

          Returns
                 A string representing the sleep settings for the displey

          Return type
                 str

          CLI Example:

          ..code-block:: bash
             salt '*' power.get_display_sleep

   salt.modules.mac_power.get_harddisk_sleep()
          Display the amount of idle time until the hard disk sleeps.

          Returns
                 A string representing the sleep  settings  for  the  hard
                 disk

          Return type
                 str

          CLI Example:

          ..code-block:: bash
             salt '*' power.get_harddisk_sleep

   salt.modules.mac_power.get_restart_freeze()
          Displays whether 'restart on freeze' is on or off if supported

          Returns
                 A  string  value  representing  the  "restart  on freeze"
                 settings

          Return type
                 string

          CLI Example:

             salt '*' power.get_restart_freeze

   salt.modules.mac_power.get_restart_power_failure()
          Displays whether 'restart on power failure'  is  on  or  off  if
          supported

          Returns
                 A   string  value  representing  the  "restart  on  power
                 failure" settings

          Return type
                 string

          CLI Example:

             salt '*' power.get_restart_power_failure

   salt.modules.mac_power.get_sleep()
          Displays the amount of  idle  time  until  the  machine  sleeps.
          Settings for Computer, Display, and Hard Disk are displayed.

          Returns
                 A  dictionary  containing  the sleep status for Computer,
                 Display, and

          Hard Disk :rtype: dict

          CLI Example:

             salt '*' power.get_sleep

   salt.modules.mac_power.get_sleep_on_power_button()
          Displays whether 'allow power button to sleep computer' is on or
          off if supported

          Returns
                 A  string  value  representing the "allow power button to
                 sleep

          computer" settings :rtype: string

          CLI Example:

             salt '*' power.get_sleep_on_power_button

   salt.modules.mac_power.get_wake_on_modem()
          Displays whether 'wake on modem' is on or off if supported

          Returns
                 A string value representing the "wake on modem" settings

          Return type
                 str

          CLI Example:

             salt '*' power.get_wake_on_modem

   salt.modules.mac_power.get_wake_on_network()
          Displays whether 'wake on network' is on or off if supported

          Returns
                 A  string  value  representing  the  "wake  on   network"
                 settings

          Return type
                 string

          CLI Example:

             salt '*' power.get_wake_on_network

   salt.modules.mac_power.set_computer_sleep(minutes)
          Set  the  amount  of  idle  time until the computer sleeps. Pass
          "Never" of "Off" to never sleep.

          Parameters
                 minutes -- Can be an integer between 1 and 180 or "Never"
                 or "Off"

          Ptype  int, str

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_computer_sleep 120
             salt '*' power.set_computer_sleep off

   salt.modules.mac_power.set_display_sleep(minutes)
          Set  the  amount  of  idle  time  until the display sleeps. Pass
          "Never" of "Off" to never sleep.

          Parameters
                 minutes -- Can be an integer between 1 and 180 or "Never"
                 or "Off"

          Ptype  int, str

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_display_sleep 120
             salt '*' power.set_display_sleep off

   salt.modules.mac_power.set_harddisk_sleep(minutes)
          Set  the  amount  of  idle  time until the harddisk sleeps. Pass
          "Never" of "Off" to never sleep.

          Parameters
                 minutes -- Can be an integer between 1 and 180 or "Never"
                 or "Off"

          Ptype  int, str

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_harddisk_sleep 120
             salt '*' power.set_harddisk_sleep off

   salt.modules.mac_power.set_restart_freeze(enabled)
          Specifies  whether  the  server  restarts  automatically after a
          system freeze.  This setting doesn't seem to  be  editable.  The
          command  completes  successfully  but the setting isn't actually
          updated. This is probably an OS X bug. The functions remains  in
          case they ever fix the bug.

          Parameters
                 enabled  (bool) -- True to enable, False to disable. "On"
                 and "Off" are

          also acceptable values. Additionally you can pass  1  and  0  to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_restart_freeze True

   salt.modules.mac_power.set_restart_power_failure(enabled)
          Set whether or not the computer will automatically restart after
          a power failure.

          Parameters
                 enabled (bool) -- True to enable, False to disable.  "On"
                 and "Off" are

          also  acceptable  values.  Additionally  you can pass 1 and 0 to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_restart_power_failure True

   salt.modules.mac_power.set_sleep(minutes)
          Sets the amount of idle time until the machine sleeps. Sets  the
          same value for Computer, Display, and Hard Disk. Pass "Never" or
          "Off" for computers that should never sleep.

          Parameters
                 minutes -- Can be an integer between 1 and 180 or "Never"
                 or "Off"

          Ptype  int, str

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_sleep 120
             salt '*' power.set_sleep never

   salt.modules.mac_power.set_sleep_on_power_button(enabled)
          Set whether or not the power button can sleep the computer.

          Parameters
                 enabled  (bool) -- True to enable, False to disable. "On"
                 and "Off" are

          also acceptable values. Additionally you can pass  1  and  0  to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_sleep_on_power_button True

   salt.modules.mac_power.set_wake_on_modem(enabled)
          Set  whether or not the computer will wake from sleep when modem
          activity is detected.

          Parameters
                 enabled (bool) -- True to enable, False to disable.  "On"
                 and "Off" are

          also  acceptable  values.  Additionally  you can pass 1 and 0 to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_wake_on_modem True

   salt.modules.mac_power.set_wake_on_network(enabled)
          Set whether or not  the  computer  will  wake  from  sleep  when
          network activity is detected.

          Parameters
                 enabled  (bool) -- True to enable, False to disable. "On"
                 and "Off" are

          also acceptable values. Additionally you can pass  1  and  0  to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' power.set_wake_on_network True

   salt.modules.mac_service module
   The service module for Mac OS X

   salt.modules.mac_service.available(name)
          Check that the given service is available.

          Parameters
                 name (str) -- The name of the service

          Returns
                 True if the service is available, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' service.available com.openssh.sshd

   salt.modules.mac_service.disable(name, runas=None)
          Disable  a launchd service. Raises an error if the service fails
          to be disabled

          Parameters

                 * name (str) -- Service label, file name, or full path

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if successful or if the service is already disabled

          Return type
                 bool

          CLI Example:

             salt '*' service.disable org.cups.cupsd

   salt.modules.mac_service.disabled(name, runas=None)
          Check if the specified service  is  not  enabled.  This  is  the
          opposite of service.enabled

          Parameters

                 * name (str) -- The name to look up

                 * runas (str) -- User to run launchctl commands

          Returns
                 True  if  the specified service is NOT enabled, otherwise
                 False

          Return type
                 bool

          CLI Example:

             salt '*' service.disabled org.cups.cupsd

   salt.modules.mac_service.enable(name, runas=None)
          Enable a launchd service. Raises an error if the  service  fails
          to be enabled

          Parameters

                 * name (str) -- Service label, file name, or full path

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if successful or if the service is already enabled

          Return type
                 bool

          CLI Example:

             salt '*' service.enable org.cups.cupsd

   salt.modules.mac_service.enabled(name, runas=None)
          Check if the specified service is enabled

          Parameters

                 * name (str) -- The name of the service to look up

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if the specified service enabled, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' service.enabled org.cups.cupsd

   salt.modules.mac_service.get_all(runas=None)
          Return  a list of services that are enabled or available. Can be
          used to find the name of a service.

          Parameters
                 runas (str) -- User to run launchctl commands

          Returns
                 A list of all the services available or enabled

          Return type
                 list

          CLI Example:

             salt '*' service.get_all

   salt.modules.mac_service.get_enabled(runas=None)
          Return a list of all services that are enabled. Can be  used  to
          find the name of a service.

          Parameters
                 runas (str) -- User to run launchctl commands

          Returns
                 A list of all the services enabled on the system

          Return type
                 list

          CLI Example:

             salt '*' service.get_enabled
             salt '*' service.get_enabled running=True

   salt.modules.mac_service.launchctl(sub_cmd, *args, **kwargs)
          Run a launchctl command and raise an error if it fails

          Parameters

                 * sub_cmd (str) -- Sub command supplied to launchctl

                 * args  (tuple)  -- Tuple containing additional arguments
                   to pass to launchctl

                 * kwargs (dict) --  Dictionary  containing  arguments  to
                   pass to cmd.run_all

                 * return_stdout  (bool)  --  A keyword argument.  If true
                   return the stdout of the launchctl command

          Returns
                 True if successful, raise CommandExecutionError  if  not,
                 or the stdout of the launchctl command if requested

          Return type
                 bool, str

          CLI Example:

             salt '*' service.launchctl debug org.cups.cupsd

   salt.modules.mac_service.list(name=None, runas=None)
          Run launchctl list and return the output

          Parameters

                 * name (str) -- The name of the service to list

                 * runas (str) -- User to run launchctl commands

          Returns
                 If  a  name is passed returns information about the named
                 service, otherwise returns a list  of  all  services  and
                 pids

          Return type
                 str

          CLI Example:

             salt '*' service.list
             salt '*' service.list org.cups.cupsd

   salt.modules.mac_service.missing(name)
          The inverse of service.available Check that the given service is
          not available.

          Parameters
                 name (str) -- The name of the service

          Returns
                 True if the service is not available, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' service.missing com.openssh.sshd

   salt.modules.mac_service.restart(name, runas=None)
          Unloads and reloads a launchd service.  Raises an error  if  the
          service fails to reload

          Parameters

                 * name (str) -- Service label, file name, or full path

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt '*' service.restart org.cups.cupsd

   salt.modules.mac_service.show(name)
          Show properties of a launchctl service

          Parameters
                 name (str) -- Service label, file name, or full path

          Returns
                 The service information if the service is found

          Return type
                 dict

          CLI Example:

             salt '*' service.show org.cups.cupsd  # service label
             salt '*' service.show org.cups.cupsd.plist  # file name
             salt '*' service.show /System/Library/LaunchDaemons/org.cups.cupsd.plist  # full path

   salt.modules.mac_service.start(name, runas=None)
          Start  a  launchd service.  Raises an error if the service fails
          to start

          NOTE:
             To start a service in Mac OS X the service  must  be  enabled
             first. Use service.enable to enable the service.

          Parameters

                 * name (str) -- Service label, file name, or full path

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if successful or if the service is already running

          Return type
                 bool

          CLI Example:

             salt '*' service.start org.cups.cupsd

   salt.modules.mac_service.status(name, sig=None, runas=None)
          Return the status for a service.

          Parameters

                 * name  (str) -- Used to find the service from launchctl.
                   Can be  any  part  of  the  service  name  or  a  regex
                   expression.

                 * sig  (str) -- Find the service with status.pid instead.
                   Note that name must still be provided.

                 * runas (str) -- User to run launchctl commands

          Returns
                 The PID for the service if it is  running,  otherwise  an
                 empty string

          Return type
                 str

          CLI Example:

             salt '*' service.status cups

   salt.modules.mac_service.stop(name, runas=None)
          Stop a launchd service.  Raises an error if the service fails to
          stop

          NOTE:
             Though service.stop will unload a service in Mac  OS  X,  the
             service  will  start  on next boot unless it is disabled. Use
             service.disable to disable the service

          Parameters

                 * name (str) -- Service label, file name, or full path

                 * runas (str) -- User to run launchctl commands

          Returns
                 True if successful or if the service is already stopped

          Return type
                 bool

          CLI Example:

             salt '*' service.stop org.cups.cupsd

   salt.modules.mac_shadow module
   New in version 2016.3.0.

   Manage Mac OSX local directory passwords and policies.

   Note that it is usually better to apply password policies  through  the
   creation of a configuration profile.

   salt.modules.mac_shadow.del_password(name)
          Deletes the account password

          Parameters
                 name (str) -- The user name of the account

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.del_password username

   salt.modules.mac_shadow.get_account_created(name)
          Get the date/time the account was created

          Parameters
                 name (str) -- the username of the account

          Returns
                 the  date/time  the  account  was   created   (yyyy-mm-dd
                 hh:mm:ss)

          Return type
                 str

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.get_account_created admin

   salt.modules.mac_shadow.get_change(name)
          Gets the date on which the password expires

          Parameters
                 name (str) -- the name of the user account

          Returns
                 The date the password will expire

          Return type
                 str

          Raises CommandExecutionError on user  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' shadow.get_change username

   salt.modules.mac_shadow.get_expire(name)
          Gets the date on which the account expires

          Parameters
                 name (str) -- the name of the user account

          Returns
                 the date the account expires

          Return type
                 str

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.get_expire username

   salt.modules.mac_shadow.get_last_change(name)
          Get the date/time the account was changed

          Parameters
                 name (str) -- the username of the account

          Returns
                 the  date/time  the  account  was  modified   (yyyy-mm-dd
                 hh:mm:ss)

          Return type
                 str

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.get_last_change admin

   salt.modules.mac_shadow.get_login_failed_count(name)
          Get the the number of failed login attempts

          Parameters
                 name (str) -- the username of the account

          Returns
                 The number of failed login attempts

          Return type
                 int

          Raises CommandExecutionError on user  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' shadow.get_login_failed_count admin

   salt.modules.mac_shadow.get_login_failed_last(name)
          Get the date/time of the last failed login attempt

          Parameters
                 name (str) -- the username of the account

          Returns
                 the  date/time  of  the last failed login attempt on this
                 account

          (yyyy-mm-dd hh:mm:ss) :rtype: str

          Raises CommandExecutionError on user  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' shadow.get_login_failed_last admin

   salt.modules.mac_shadow.get_maxdays(name)
          Get the maximum age of the password

          Parameters
                 name (str) -- the username of the account

          Returns
                 the maximum age of the password in days

          Return type
                 int

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.get_maxdays admin 90

   salt.modules.mac_shadow.info(name)
          Return information for the specified user

          Parameters
                 name (str) -- the username

          Returns
                 A dictionary containing the user's shadow information

          Return type
                 dict

          CLI Example:

             salt '*' shadow.info admin

   salt.modules.mac_shadow.set_change(name, date)
          Sets the date on which the password expires. The  user  will  be
          required to change their password. Format is mm/dd/yyyy

          Parameters

                 * name (str) -- the name of the user account

                 * date  (date) -- the date the password will expire. Must
                   be in mm/dd/yyyy

          format.

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          Raises CommandExecutionError on user  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' shadow.set_change username 09/21/2016

   salt.modules.mac_shadow.set_expire(name, date)
          Sets the date on which the account expires. The user will not be
          able to login after this date. Date format is mm/dd/yyyy

          Parameters

                 * name (str) -- the name of the user account

                 * date (datetime) -- the date the  account  will  expire.
                   Format must be

          mm/dd/yyyy

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.set_expire username 07/23/2015

   salt.modules.mac_shadow.set_inactdays(name, days)
          Set the number if inactive days before the  account  is  locked.
          Not available in OS X

          Parameters

                 * name (str) -- The user name

                 * days (int) -- The number of days

          Returns
                 Will always return False until OSX supports this feature.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.set_inactdays admin 90

   salt.modules.mac_shadow.set_maxdays(name, days)
          Set the maximum age of the password in days

          Parameters

                 * name (str) -- the username of the account

                 * days (int) -- the maximum age of the account in days

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises CommandExecutionError  on  user  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' shadow.set_maxdays admin 90

   salt.modules.mac_shadow.set_mindays(name, days)
          Set the minimum password age in days. Not available in OS X.

          Parameters

                 * name (str) -- The user name

                 * days (int) -- The number of days

          Returns
                 Will always return False until OSX supports this feature.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.set_mindays admin 90

   salt.modules.mac_shadow.set_password(name, password)
          Set the password for a named user (insecure, the  password  will
          be in the process list while the command is running)

          Parameters
                 name  (str)  --  The  name  of  the  local user, which is
                 assumed to be in the

          local directory service

          Parameters
                 password (str) -- The plaintext password to set

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          Raises CommandExecutionError on user  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' mac_shadow.set_password macuser macpassword

   salt.modules.mac_shadow.set_warndays(name, days)
          Set the number of days before the password expires that the user
          will start to see a warning. Not available in OS X

          Parameters

                 * name (str) -- The user name

                 * days (int) -- The number of days

          Returns
                 Will always return False until OSX supports this feature.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.set_warndays admin 90

   salt.modules.mac_softwareupdate module
   Support for the softwareupdate command on MacOS.

   salt.modules.mac_softwareupdate.download(name)
          Download a named update so that it can be installed  later  with
          the update or update_all functions

          Parameters
                 name (str) -- The update to download.

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.download <update name>

   salt.modules.mac_softwareupdate.download_all(recommended=False,
   restart=True)
          Download all available updates so that  they  can  be  installed
          later with the update or update_all functions. It returns a list
          of updates that are now downloaded.

          Parameters
                 recommended (bool) -- If set to True,  only  install  the
                 recommended

          updates. If set to False (default) all updates are installed.

          Parameters
                 restart (bool) -- Set this to False if you do not want to
                 install updates

          that require a restart. Default is True

          Returns
                 A list containing all downloaded updates on the system.

          Return type
                 list

          CLI Example:

             salt '*' softwareupdate.download_all

   salt.modules.mac_softwareupdate.get_catalog()
          New in version 2016.3.0.

          Get the current catalog being  used  for  update  lookups.  Will
          return  a  url if a custom catalog has been specified. Otherwise
          the word 'Default' will be returned

          Returns
                 The catalog being used for update lookups

          Return type
                 str

          CLI Example:

             salt '*' softwareupdates.get_catalog

   salt.modules.mac_softwareupdate.ignore(name)
          Ignore a specific program update. When an update is ignored  the
          '-'   and  version  number  at  the  end  will  be  omitted,  so
          "SecUpd2014-001-1.0"  becomes  "SecUpd2014-001".  It   will   be
          removed  automatically  if  present.  An  update is successfully
          ignored when it no longer shows up after list_updates.

          Parameters
                 name -- The name of the update to add to the ignore list.

          Ptype  str

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.ignore <update-name>

   salt.modules.mac_softwareupdate.list_available(recommended=False,
   restart=False)
          List all available updates.

          Parameters

                 * recommended (bool) -- Show only recommended updates.

                 * restart  (bool)  --  Show  only  updates that require a
                   restart.

          Returns
                 Returns a dictionary containing the updates

          Return type
                 dict

          CLI Example:

             salt '*' softwareupdate.list_available

   salt.modules.mac_softwareupdate.list_downloads()
          Return a list of all updates that have been downloaded locally.

          Returns
                 A list of updates that have been downloaded

          Return type
                 list

          CLI Example:

             salt '*' softwareupdate.list_downloads

   salt.modules.mac_softwareupdate.list_ignored()
          List all updates that have been  ignored.  Ignored  updates  are
          shown without the '-' and version number at the end, this is how
          the softwareupdate command works.

          Returns
                 The list of ignored updates

          Return type
                 list

          CLI Example:

             salt '*' softwareupdate.list_ignored

   salt.modules.mac_softwareupdate.reset_catalog()
          New in version 2016.3.0.

          Reset the Software Update Catalog to the default.

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdates.reset_catalog

   salt.modules.mac_softwareupdate.reset_ignored()
          Make sure the ignored updates are not ignored anymore, returns a
          list of the updates that are no longer ignored.

          Returns
                 True if the list was reset, Otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.reset_ignored

   salt.modules.mac_softwareupdate.schedule_enable(enable)
          Enable/disable automatic update scheduling.

          Parameters
                 enable  --  True/On/Yes/1  to  turn on automatic updates.
                 False/No/Off/0 to

          turn off automatic updates. If this value is empty, the  current
          status will be returned.  :type: bool str

          Returns
                 True if scheduling is enabled, False if disabled

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.schedule_enable on|off

   salt.modules.mac_softwareupdate.schedule_enabled()
          Check the status of automatic update scheduling.

          Returns
                 True  if scheduling is enabled, False if disabled - True:
                 Automatic checking is on, - False: Automatic checking  is
                 off,

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.schedule_enabled

   salt.modules.mac_softwareupdate.set_catalog(url)
          New in version 2016.3.0.

          Set the Software Update Catalog to the URL specified

          Parameters
                 url (str) -- The url to the update catalog

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdates.set_catalog http://swupd.local:8888/index.sucatalog

   salt.modules.mac_softwareupdate.update(name)
          Install a named update.

          Parameters
                 name (str) -- The name of the of the update to install.

          Returns
                 True if successfully updated, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.update <update-name>

   salt.modules.mac_softwareupdate.update_all(recommended=False,
   restart=True)
          Install all available updates. Returns a  dictionary  containing
          the name of the update and the status of its installation.

          Parameters
                 recommended  (bool)  --  If set to True, only install the
                 recommended

          updates. If set to False (default) all updates are installed.

          Parameters
                 restart (bool) -- Set this to False if you do not want to
                 install updates

          that require a restart. Default is True

          Returns
                 A  dictionary  containing the updates that were installed
                 and the

          status of its installation. If  no  updates  were  installed  an
          empty  dictionary  is returned.  :rtype: dict - True: The update
          was installed.  - False: The update was not installed.

          CLI Example:

             salt '*' softwareupdate.update_all

   salt.modules.mac_softwareupdate.update_available(name)
          Check whether or not an update is available with a given name.

          Parameters
                 name (str) -- The name of the update to look for

          Returns
                 True if available, False if not

          Return type
                 bool

          CLI Example:

             salt '*' softwareupdate.update_available <update-name>
             salt '*' softwareupdate.update_available "<update with whitespace>"

   salt.modules.mac_user
   Manage users on Mac OS 10.7+

   IMPORTANT:
      If you feel that Salt should be using this module to manage users on
      a  minion,  and  it  is  using a different module (or gives an error
      similar to 'user.info' is not available), see here.

   salt.modules.mac_user.add(name,   uid=None,   gid=None,    groups=None,
   home=None, shell=None, fullname=None, createhome=True, **kwargs)
          Add a user to the minion

          CLI Example:

             salt '*' user.add name <uid> <gid> <groups> <home> <shell>

   salt.modules.mac_user.chfullname(name, fullname)
          Change the user's Full Name

          CLI Example:

             salt '*' user.chfullname foo 'Foo Bar'

   salt.modules.mac_user.chgid(name, gid)
          Change the default group of the user

          CLI Example:

             salt '*' user.chgid foo 4376

   salt.modules.mac_user.chgroups(name, groups, append=False)
          Change  the  groups  to  which  the  user belongs. Note that the
          user's primary group does not have  to  be  one  of  the  groups
          passed,  membership in the user's primary group is automatically
          assumed.

          groups Groups to which the user should  belong,  can  be  passed
                 either as a python list or a comma-separated string

          append Instead  of removing user from groups not included in the
                 groups parameter, just add user to any groups  for  which
                 they are not members

          CLI Example:

             salt '*' user.chgroups foo wheel,root

   salt.modules.mac_user.chhome(name, home, **kwargs)
          Change the home directory of the user

          CLI Example:

             salt '*' user.chhome foo /Users/foo

   salt.modules.mac_user.chshell(name, shell)
          Change the default shell of the user

          CLI Example:

             salt '*' user.chshell foo /bin/zsh

   salt.modules.mac_user.chuid(name, uid)
          Change the uid for a named user

          CLI Example:

             salt '*' user.chuid foo 4376

   salt.modules.mac_user.delete(name, remove=False, force=False)
          Remove a user from the minion

          CLI Example:

             salt '*' user.delete name remove=True force=True

   salt.modules.mac_user.disable_auto_login()
          New in version 2016.3.0.

          Disables auto login on the machine

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' user.disable_auto_login

   salt.modules.mac_user.enable_auto_login(name)
          New in version 2016.3.0.

          Configures the machine to auto login with the specified user

          Parameters
                 name (str) -- The user account use for auto login

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' user.enable_auto_login stevej

   salt.modules.mac_user.get_auto_login()
          New in version 2016.3.0.

          Gets the current setting for Auto Login

          Returns
                 If  enabled,  returns  the  user  name, otherwise returns
                 False

          Return type
                 str, bool

          CLI Example:

             salt '*' user.get_auto_login

   salt.modules.mac_user.getent(refresh=False)
          Return the list of all info for all users

          CLI Example:

             salt '*' user.getent

   salt.modules.mac_user.info(name)
          Return user information

          CLI Example:

             salt '*' user.info root

   salt.modules.mac_user.list_groups(name)
          Return a list of groups the named user belongs to.

          name
             The name of the user for which to list  groups.  Starting  in
             Salt  2016.11.0,  all  groups  for the user, including groups
             beginning with an underscore will be listed.

             Changed in version 2016.11.0.

          CLI Example:

             salt '*' user.list_groups foo

   salt.modules.mac_user.list_users()
          Return a list of all users

          CLI Example:

             salt '*' user.list_users

   salt.modules.mac_user.primary_group(name)
          Return the primary group of the named user

          New in version 2016.3.0.

          CLI Example:

             salt '*' user.primary_group saltadmin

   salt.modules.mac_user.rename(name, new_name)
          Change the username for a named user

          CLI Example:

             salt '*' user.rename name new_name

   salt.modules.mac_sysctl module
   Module for viewing and modifying sysctl parameters

   salt.modules.mac_sysctl.assign(name, value)
          Assign a single sysctl parameter for this minion

          name   The name of the sysctl value to edit.

          value  The sysctl value to apply.

          CLI Example:

             salt '*' sysctl.assign net.inet.icmp.icmplim 50

   salt.modules.mac_sysctl.get(name)
          Return a single sysctl parameter for this minion

          name   The name of the sysctl value to display.

          CLI Example:

             salt '*' sysctl.get hw.physmem

   salt.modules.mac_sysctl.persist(name, value, config='/etc/sysctl.conf',
   apply_change=False)
          Assign and persist a simple sysctl parameter for this minion

          name   The name of the sysctl value to edit.

          value  The sysctl value to apply.

          config The location of the sysctl configuration file.

          apply_change
                 Default  is False; Default behavior only creates or edits
                 the sysctl.conf file.  If  apply  is  set  to  True,  the
                 changes are applied to the system.

          CLI Example:

             salt '*' sysctl.persist net.inet.icmp.icmplim 50
             salt '*' sysctl.persist coretemp_load NO config=/etc/sysctl.conf

   salt.modules.mac_sysctl.show(config_file=False)
          Return a list of sysctl parameters for this minion

          CLI Example:

             salt '*' sysctl.show

   salt.modules.mac_system module
   New in version 2016.3.0.

   System module for sleeping, restarting, and shutting down the system on
   Mac OS X.

   WARNING:
      Using this module will enable atrun on the system if it is disabled.

   salt.modules.mac_system.get_boot_arch()
          Get the kernel architecture setting from com.apple.Boot.plist

          Returns
                 A string value representing the boot architecture setting

          Return type
                 str

          CLI Example:

             salt '*' system.get_boot_arch

   salt.modules.mac_system.get_computer_name()
          Gets the computer name

          Returns
                 The computer name

          Return type
                 str

          CLI Example:

             salt '*' system.get_computer_name

   salt.modules.mac_system.get_disable_keyboard_on_lock()
          Get whether or not the keyboard should be disabled  when  the  X
          Serve enclosure lock is engaged.

          Returns
                 True if disable keyboard on lock is on, False if off

          Return type
                 bool

          CLI Example:

          ..code-block:: bash
             salt '*' system.get_disable_keyboard_on_lock

   salt.modules.mac_system.get_remote_events()
          Displays whether remote apple events are on or off.

          Returns
                 True if remote apple events are on, False if off

          Return type
                 bool

          CLI Example:

             salt '*' system.get_remote_events

   salt.modules.mac_system.get_remote_login()
          Displays whether remote login (SSH) is on or off.

          Returns
                 True if remote login is on, False if off

          Return type
                 bool

          CLI Example:

             salt '*' system.get_remote_login

   salt.modules.mac_system.get_restart_delay()
          Get the number of seconds after which the computer will start up
          after a power failure.

          Returns
                 A string value representing the  number  of  seconds  the
                 system will

          delay restart after power loss :rtype: str

          CLI Example:

             salt '*' system.get_restart_delay

   salt.modules.mac_system.get_startup_disk()
          Displays the current startup disk

          Returns
                 The current startup disk

          Return type
                 str

          CLI Example:

             salt '*' system.get_startup_disk

   salt.modules.mac_system.get_subnet_name()
          Gets the local subnet name

          Returns
                 The local subnet name

          Return type
                 str

          CLI Example:

             salt '*' system.get_subnet_name

   salt.modules.mac_system.halt(at_time=None)
          Halt a running system

          Parameters
                 at_time  (str)  --  Any valid at expression. For example,
                 some valid at

          expressions could be: - noon - midnight - fri - 9:00 AM  -  2:30
          PM tomorrow - now + 10 minutes

          Note:: If you pass a time only, with no 'AM/PM' designation, you
          have to double quote the parameter  on  the  command  line.  For
          example: '"14:00"'

          CLI Example:

             salt '*' system.halt
             salt '*' system.halt 'now + 10 minutes'

   salt.modules.mac_system.list_startup_disks()
          List all valid startup disks on the system.

          Returns
                 A list of valid startup disks

          Return type
                 list

          CLI Example:

             salt '*' system.list_startup_disks

   salt.modules.mac_system.restart(at_time=None)
          Restart the system

          Parameters
                 at_time  (str)  --  Any valid at expression. For example,
                 some valid at

          expressions could be: - noon - midnight - fri - 9:00 AM  -  2:30
          PM tomorrow - now + 10 minutes

          Note:: If you pass a time only, with no 'AM/PM' designation, you
          have to double quote the parameter  on  the  command  line.  For
          example: '"14:00"'

          CLI Example:

             salt '*' system.restart
             salt '*' system.restart '12:00 PM fri'

   salt.modules.mac_system.set_boot_arch(arch='default')
          Set the kernel to boot in 32 or 64 bit mode on next boot.

          NOTE:
             This command fails with the following error:

             changes to kernel architecture failed to save!

             The  setting is not updated. This is either an apple bug, not
             available on the test system, or a result of system files now
             being locked down in OS X (SIP Protection).

          Parameters
                 arch   (str)   --   A  string  representing  the  desired
                 architecture. If no

          value is passed, default is assumed.  Valid  values  include:  -
          i386 - x86_64 - default

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_boot_arch i386

   salt.modules.mac_system.set_computer_name(name)
          Set the computer name

          Parameters
                 name (str) -- The new computer name

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_computer_name "Mike's Mac"

   salt.modules.mac_system.set_disable_keyboard_on_lock(enable)
          Get  whether  or  not the keyboard should be disabled when the X
          Serve enclosure lock is engaged.

          Parameters
                 enable (bool) -- True to enable, False to  disable.  "On"
                 and "Off" are

          also  acceptable  values.  Additionally  you can pass 1 and 0 to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_disable_keyboard_on_lock False

   salt.modules.mac_system.set_remote_events(enable)
          Set  whether  the  server  responds  to  events  sent  by  other
          computers (such as AppleScripts)

          Parameters
                 enable  (bool)  -- True to enable, False to disable. "On"
                 and "Off" are

          also acceptable values. Additionally you can pass  1  and  0  to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_remote_events On

   salt.modules.mac_system.set_remote_login(enable)
          Set the remote login (SSH) to either on or off.

          Parameters
                 enable  (bool)  -- True to enable, False to disable. "On"
                 and "Off" are

          also acceptable values. Additionally you can pass  1  and  0  to
          represent True and False respectively

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_remote_login True

   salt.modules.mac_system.set_restart_delay(seconds)
          Set the number of seconds after which the computer will start up
          after a power failure.

          WARNING:
             This command fails with the following error:

             Error, IOServiceOpen returned 0x10000003

             The setting is not updated. This is an apple  bug.  It  seems
             like  it  may  only work on certain versions of Mac Server X.
             This article explains the issue in more detail, though it  is
             quite old.

             http://lists.apple.com/archives/macos-x-server/2006/Jul/msg00967.html

          Parameters
                 seconds (int)  --  The  number  of  seconds.  Must  be  a
                 multiple of 30

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_restart_delay 180

   salt.modules.mac_system.set_startup_disk(path)
          Set  the  current  startup  disk  to  the  indicated  path.  Use
          system.list_startup_disks to find valid  startup  disks  on  the
          system.

          Parameters
                 path (str) -- The valid startup disk path

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' system.set_startup_disk /System/Library/CoreServices

   salt.modules.mac_system.set_subnet_name(name)
          Set the local subnet name

          Parameters
                 name (str) -- The new local subnet name

          NOTE:
             Spaces  are  changed  to dashes. Other special characters are
             removed.

          Returns
                 True if successful, False if not

          Return type
                 bool

          CLI Example:

             The following will be set as 'Mikes-Mac'
             salt '*' system.set_subnet_name "Mike's Mac"

   salt.modules.mac_system.shutdown(at_time=None)
          Shutdown the system

          Parameters
                 at_time (str) -- Any valid at  expression.  For  example,
                 some valid at

          expressions  could  be: - noon - midnight - fri - 9:00 AM - 2:30
          PM tomorrow - now + 10 minutes

          Note:: If you pass a time only, with no 'AM/PM' designation, you
          have  to  double  quote  the  parameter on the command line. For
          example: '"14:00"'

          CLI Example:

             salt '*' system.shutdown
             salt '*' system.shutdown 'now + 1 hour'

   salt.modules.mac_system.sleep(at_time=None)
          Sleep the system. If a user is active  on  the  system  it  will
          likely fail to sleep.

          Parameters
                 at_time  (str)  --  Any valid at expression. For example,
                 some valid at

          expressions could be: - noon - midnight - fri - 9:00 AM  -  2:30
          PM tomorrow - now + 10 minutes

          Note:: If you pass a time only, with no 'AM/PM' designation, you
          have to double quote the parameter  on  the  command  line.  For
          example: '"14:00"'

          CLI Example:

             salt '*' system.sleep
             salt '*' system.sleep '10:00 PM'

   salt.modules.mac_timezone module
   Module for editing date/time settings on Mac OS X
      New in version 2016.3.0.

   salt.modules.mac_timezone.get_date()
          Displays the current date

          Returns
                 the system date

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_date

   salt.modules.mac_timezone.get_hwclock()
          Get current hardware clock setting (UTC or localtime)

          CLI Example:

             salt '*' timezone.get_hwclock

   salt.modules.mac_timezone.get_offset()
          Displays the current time zone offset

          Returns
                 The current time zone offset

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_offset

   salt.modules.mac_timezone.get_time()
          Get the current system time.

          Returns
                 The current time in 24 hour format

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_time

   salt.modules.mac_timezone.get_time_server()
          Display the currently set network time server.

          Returns
                 the network time server

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_time_server

   salt.modules.mac_timezone.get_using_network_time()
          Display whether network time is on or off

          Returns
                 True if network time is on, False if off

          Return type
                 bool

          CLI Example:

             salt '*' timezone.get_using_network_time

   salt.modules.mac_timezone.get_zone()
          Displays the current time zone

          Returns
                 The current time zone

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_zone

   salt.modules.mac_timezone.get_zonecode()
          Displays the current time zone abbreviated code

          Returns
                 The current time zone code

          Return type
                 str

          CLI Example:

             salt '*' timezone.get_zonecode

   salt.modules.mac_timezone.list_zones()
          Displays  a  list  of  available  time zones. Use this list when
          setting a time zone using timezone.set_zone

          Returns
                 a list of time zones

          Return type
                 list

          CLI Example:

             salt '*' timezone.list_zones

   salt.modules.mac_timezone.set_date(date)
          Set the current month, day, and year

          Parameters
                 date (str) -- The date to set. Valid date formats are:

          * %m:%d:%y

          * %m:%d:%Y

          * %m/%d/%y

          * %m/%d/%Y

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises SaltInvocationError on Invalid Date format

          Raises CommandExecutionError on failure

          CLI Example:

             salt '*' timezone.set_date 1/13/2016

   salt.modules.mac_timezone.set_hwclock(clock)
          Sets the hardware clock to be either UTC or localtime

          CLI Example:

             salt '*' timezone.set_hwclock UTC

   salt.modules.mac_timezone.set_time(time)
          Sets the current time. Must be in 24 hour format.

          Parameters
                 time (str) -- The time to set in 24 hour format.

          The value must be double quoted. ie: '"17:46"'

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises SaltInvocationError on Invalid Time format

          Raises CommandExecutionError on failure

          CLI Example:

             salt '*' timezone.set_time '"17:34"'

   salt.modules.mac_timezone.set_time_server(time_server='time.apple.com')
          Designates a network time server. Enter the IP  address  or  DNS
          name for the network time server.

          Parameters
                 time_server -- IP or DNS name of the network time server.
                 If nothing is

          passed the time server will be  set  to  the  OS  X  default  of
          'time.apple.com' :type: str

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises CommandExecutionError on failure

          CLI Example:

             salt '*' timezone.set_time_server time.acme.com

   salt.modules.mac_timezone.set_using_network_time(enable)
          Set whether network time is on or off.

          Parameters
                 enable  -- True to enable, False to disable. Can also use
                 'on' or 'off'

          Type   str bool

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises CommandExecutionError on failure

          CLI Example:

             salt '*' timezone.set_using_network_time True

   salt.modules.mac_timezone.set_zone(time_zone)
          Set the local time zone. Use timezone.list_zones to  list  valid
          time_zone arguments

          Parameters
                 time_zone (str) -- The time zone to apply

          Returns
                 True if successful, False if not

          Return type
                 bool

          Raises SaltInvocationError on Invalid Timezone

          Raises CommandExecutionError on failure

          CLI Example:

             salt '*' timezone.set_zone America/Denver

   salt.modules.mac_timezone.zone_compare(time_zone)
          Compares the given timezone name with the system timezone name.

          Returns
                 True if they are the same, False if not

          Return type
                 bool

          CLI Example:

             salt '*' timezone.zone_compare America/Boise

   salt.modules.mac_xattr module
   This  module  allows  you  to  manage  extended  attributes on files or
   directories

      salt '*' xattr.list /path/to/file

   salt.modules.mac_xattr.clear(path)
          Causes the all attributes on the file/directory to be removed

          Parameters
                 path (str) -- The file(s) to get attributes from

          Returns
                 True if successful, otherwise False

          Raises CommandExecutionError on file  not  found  or  any  other
                 unknown error

          CLI Example:

             salt '*' xattr.delete /path/to/file "com.test.attr"

   salt.modules.mac_xattr.delete(path, attribute)
          Removes the given attribute from the file

          Parameters

                 * path (str) -- The file(s) to get attributes from

                 * attribute  (str)  --  The  attribute name to be deleted
                   from the

          file/directory

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          Raises CommandExecutionError on file not  found,  attribute  not
                 found, and

          any other unknown error

          CLI Example:

             salt '*' xattr.delete /path/to/file "com.test.attr"

   salt.modules.mac_xattr.list(path, **kwargs)
          List all of the extended attributes on the given file/directory

          Parameters

                 * path (str) -- The file(s) to get attributes from

                 * hex (bool) -- Return the values with forced hexadecimal
                   values

          Returns
                 A dictionary containing extended  attributes  and  values
                 for the

          given file :rtype: dict

          Raises CommandExecutionError  on  file  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' xattr.list /path/to/file
             salt '*' xattr.list /path/to/file hex=True

   salt.modules.mac_xattr.read(path, attribute, **kwargs)
          Read the given attributes on the given file/directory

          Parameters

                 * path (str) -- The file to get attributes from

                 * attribute (str) -- The attribute to read

                 * hex (bool) -- Return the values with forced hexadecimal
                   values

          Returns
                 A string containing the value of the named attribute

          Return type
                 str

          Raises CommandExecutionError  on  file  not found, attribute not
                 found, and

          any other unknown error

          CLI Example:

             salt '*' xattr.read /path/to/file com.test.attr
             salt '*' xattr.read /path/to/file com.test.attr hex=True

   salt.modules.mac_xattr.write(path, attribute, value, **kwargs)
          Causes the given attribute name to be assigned the given value

          Parameters

                 * path (str) -- The file(s) to get attributes from

                 * attribute (str) -- The attribute name to be written  to
                   the file/directory

                 * value  (str)  --  The  value  to  assign  to  the given
                   attribute

                 * hex (bool) -- Set the values  with  forced  hexadecimal
                   values

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          Raises CommandExecutionError  on  file  not  found  or any other
                 unknown error

          CLI Example:

             salt '*' xattr.write /path/to/file "com.test.attr" "value"

   salt.modules.makeconf
   Support for modifying make.conf under Gentoo

   salt.modules.makeconf.append_cflags(value)
          Add to or create a new CFLAGS in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_cflags '-pipe'

   salt.modules.makeconf.append_cxxflags(value)
          Add to or create a new CXXFLAGS in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_cxxflags '-pipe'

   salt.modules.makeconf.append_emerge_default_opts(value)
          Add to or create a new EMERGE_DEFAULT_OPTS in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_emerge_default_opts '--jobs'

   salt.modules.makeconf.append_features(value)
          Add to or create a new FEATURES in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_features 'webrsync-gpg'

   salt.modules.makeconf.append_gentoo_mirrors(value)
          Add to or create a new GENTOO_MIRRORS in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_gentoo_mirrors 'http://distfiles.gentoo.org'

   salt.modules.makeconf.append_makeopts(value)
          Add to or create a new MAKEOPTS in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_makeopts '-j3'

   salt.modules.makeconf.append_var(var, value)
          Add to or create a new variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.append_var 'LINGUAS' 'en'

   salt.modules.makeconf.cflags_contains(value)
          Verify if CFLAGS variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.cflags_contains '-pipe'

   salt.modules.makeconf.chost_contains(value)
          Verify if CHOST variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.chost_contains 'x86_64-pc-linux-gnu'

   salt.modules.makeconf.cxxflags_contains(value)
          Verify if CXXFLAGS variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.cxxflags_contains '-pipe'

   salt.modules.makeconf.emerge_default_opts_contains(value)
          Verify if  EMERGE_DEFAULT_OPTS  variable  contains  a  value  in
          make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.emerge_default_opts_contains '--jobs'

   salt.modules.makeconf.features_contains(value)
          Verify if FEATURES variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.features_contains 'webrsync-gpg'

   salt.modules.makeconf.gentoo_mirrors_contains(value)
          Verify if GENTOO_MIRRORS variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.gentoo_mirrors_contains 'http://distfiles.gentoo.org'

   salt.modules.makeconf.get_cflags()
          Get the value of CFLAGS variable in the make.conf

          Return  the value of the variable or None if the variable is not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_cflags

   salt.modules.makeconf.get_chost()
          Get the value of CHOST variable in the make.conf

          Return the value of the variable or None if the variable is  not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_chost

   salt.modules.makeconf.get_cxxflags()
          Get the value of CXXFLAGS variable in the make.conf

          Return  the value of the variable or None if the variable is not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_cxxflags

   salt.modules.makeconf.get_emerge_default_opts()
          Get the value of EMERGE_DEFAULT_OPTS variable in the make.conf

          Return the value of the variable or None if the variable is  not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_emerge_default_opts

   salt.modules.makeconf.get_features()
          Get the value of FEATURES variable in the make.conf

          Return  the value of the variable or None if the variable is not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_features

   salt.modules.makeconf.get_gentoo_mirrors()
          Get the value of GENTOO_MIRRORS variable in the make.conf

          Return the value of the variable or None if the variable is  not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_gentoo_mirrors

   salt.modules.makeconf.get_makeopts()
          Get the value of MAKEOPTS variable in the make.conf

          Return  the value of the variable or None if the variable is not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_makeopts

   salt.modules.makeconf.get_sync()
          Get the value of SYNC variable in the make.conf

          Return the value of the variable or None if the variable is  not
          in the make.conf

          CLI Example:

             salt '*' makeconf.get_sync

   salt.modules.makeconf.get_var(var)
          Get the value of a variable in make.conf

          Return  the value of the variable or None if the variable is not
          in make.conf

          CLI Example:

             salt '*' makeconf.get_var 'LINGUAS'

   salt.modules.makeconf.makeopts_contains(value)
          Verify if MAKEOPTS variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.makeopts_contains '-j3'

   salt.modules.makeconf.remove_var(var)
          Remove a variable from the make.conf

          Return a dict containing the new value for the variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.remove_var 'LINGUAS'

   salt.modules.makeconf.set_cflags(value)
          Set the CFLAGS variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_cflags '-march=native -O2 -pipe'

   salt.modules.makeconf.set_chost(value)
          Set the CHOST variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_chost 'x86_64-pc-linux-gnu'

   salt.modules.makeconf.set_cxxflags(value)
          Set the CXXFLAGS variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_cxxflags '-march=native -O2 -pipe'

   salt.modules.makeconf.set_emerge_default_opts(value)
          Set the EMERGE_DEFAULT_OPTS variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_emerge_default_opts '--jobs'

   salt.modules.makeconf.set_gentoo_mirrors(value)
          Set the GENTOO_MIRRORS variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_gentoo_mirrors 'http://distfiles.gentoo.org'

   salt.modules.makeconf.set_makeopts(value)
          Set the MAKEOPTS variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_makeopts '-j3'

   salt.modules.makeconf.set_sync(value)
          Set the SYNC variable

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_sync 'rsync://rsync.namerica.gentoo.org/gentoo-portage'

   salt.modules.makeconf.set_var(var, value)
          Set a variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.set_var 'LINGUAS' 'en'

   salt.modules.makeconf.sync_contains(value)
          Verify if SYNC variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.sync_contains 'rsync://rsync.namerica.gentoo.org/gentoo-portage'

   salt.modules.makeconf.trim_cflags(value)
          Remove a value from CFLAGS variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_cflags '-pipe'

   salt.modules.makeconf.trim_cxxflags(value)
          Remove a value from CXXFLAGS variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_cxxflags '-pipe'

   salt.modules.makeconf.trim_emerge_default_opts(value)
          Remove  a  value  from  EMERGE_DEFAULT_OPTS  variable   in   the
          make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_emerge_default_opts '--jobs'

   salt.modules.makeconf.trim_features(value)
          Remove a value from FEATURES variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_features 'webrsync-gpg'

   salt.modules.makeconf.trim_gentoo_mirrors(value)
          Remove a value from GENTOO_MIRRORS variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_gentoo_mirrors 'http://distfiles.gentoo.org'

   salt.modules.makeconf.trim_makeopts(value)
          Remove a value from MAKEOPTS variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_makeopts '-j3'

   salt.modules.makeconf.trim_var(var, value)
          Remove a value from a variable in the make.conf

          Return a dict containing the new value for variable:

             {'<variable>': {'old': '<old-value>',
                             'new': '<new-value>'}}

          CLI Example:

             salt '*' makeconf.trim_var 'LINGUAS' 'en'

   salt.modules.makeconf.var_contains(var, value)
          Verify if variable contains a value in make.conf

          Return True if value is set for var

          CLI Example:

             salt '*' makeconf.var_contains 'LINGUAS' 'en'

   salt.modules.marathon module
   Module providing a simple management interface to a marathon cluster.

   Currently this only works when run through a proxy minion.

   New in version 2015.8.2.

   salt.modules.marathon.app(id)
          Return the current server configuration for the specified app.

          CLI Example:

             salt marathon-minion-id marathon.app my-app

   salt.modules.marathon.apps()
          Return a list of the currently installed app ids.

          CLI Example:

             salt marathon-minion-id marathon.apps

   salt.modules.marathon.has_app(id)
          Return whether the given app id is currently configured.

          CLI Example:

             salt marathon-minion-id marathon.has_app my-app

   salt.modules.marathon.info()
          Return  configuration  and status information about the marathon
          instance.

          CLI Example:

             salt marathon-minion-id marathon.info

   salt.modules.marathon.restart_app(id, restart=False, force=True)
          Restart the current server configuration for the specified app.

          Parameters

                 * restart -- Restart the app

                 * force -- Override the current deployment

          CLI Example:

             salt marathon-minion-id marathon.restart_app my-app

          By default, this will only check if the app exists in  marathon.
          It  does  not check if there are any tasks associated with it or
          if the app is suspended.

             salt marathon-minion-id marathon.restart_app my-app true true

          The restart option needs to be set to True to actually  issue  a
          rolling restart to marathon.

          The  force  option  tells  marathon  to  ignore  the current app
          deployment if there is one.

   salt.modules.marathon.rm_app(id)
          Remove the specified app from the server.

          CLI Example:

             salt marathon-minion-id marathon.rm_app my-app

   salt.modules.marathon.update_app(id, config)
          Update the specified app with the given configuration.

          CLI Example:

             salt marathon-minion-id marathon.update_app my-app '<config yaml>'

   salt.modules.match
   The match module allows for match routines  to  be  run  and  determine
   target specs

   salt.modules.match.compound(tgt, minion_id=None)
          Return True if the minion ID matches the given compound target

          minion_id
                 Specify  the  minion  ID  to  match  against  the  target
                 expression

                 New in version 2014.7.0.

          CLI Example:

             salt '*' match.compound 'L@cheese,foo and *'

   salt.modules.match.data(tgt)
          Return True if the minion matches the given data target

          CLI Example:

             salt '*' match.data 'spam:eggs'

   salt.modules.match.filter_by(lookup,              expr_form='compound',
   minion_id=None)
          Return the first match in a dictionary of target patterns

          New in version 2014.7.0.

          CLI Example:

             salt '*' match.filter_by '{foo*: Foo!, bar*: Bar!}' minion_id=bar03

          Pillar Example:

             # Filter the data for the current minion into a variable:
             {% set roles = salt['match.filter_by']({
                 'web*': ['app', 'caching'],
                 'db*': ['db'],
             }) %}

             # Make the filtered data available to Pillar:
             roles: {{ roles | yaml() }}

   salt.modules.match.glob(tgt, minion_id=None)
          Return True if the minion ID matches the given glob target

          minion_id
                 Specify  the  minion  ID  to  match  against  the  target
                 expression

                 New in version 2014.7.0.

          CLI Example:

             salt '*' match.glob '*'

   salt.modules.match.grain(tgt, delimiter=':')
          Return True if the minion matches the given  grain  target.  The
          delimiter argument can be used to specify a different delimiter.

          CLI Example:

             salt '*' match.grain 'os:Ubuntu'
             salt '*' match.grain 'ipv6|2001:db8::ff00:42:8329' delimiter='|'

          delimiter
                 Specify  an  alternate delimiter to use when traversing a
                 nested dict

                 New in version 2014.7.0.

          delim  Specify an alternate delimiter to use when  traversing  a
                 nested dict

                 New in version 0.16.4.

                 Deprecated since version 2015.8.0.

   salt.modules.match.grain_pcre(tgt, delimiter=':')
          Return  True  if the minion matches the given grain_pcre target.
          The delimiter argument  can  be  used  to  specify  a  different
          delimiter.

          CLI Example:

             salt '*' match.grain_pcre 'os:Fedo.*'
             salt '*' match.grain_pcre 'ipv6|2001:.*' delimiter='|'

          delimiter
                 Specify  an  alternate delimiter to use when traversing a
                 nested dict

                 New in version 2014.7.0.

          delim  Specify an alternate delimiter to use when  traversing  a
                 nested dict

                 New in version 0.16.4.

                 Deprecated since version 2015.8.0.

   salt.modules.match.ipcidr(tgt)
          Return True if the minion matches the given ipcidr target

          CLI Example:

             salt '*' match.ipcidr '192.168.44.0/24'

          delimiter Pillar Example:

             '172.16.0.0/12':
               - match: ipcidr
               - nodeclass: internal

   salt.modules.match.list(tgt, minion_id=None)
          Return True if the minion ID matches the given list target

          minion_id
                 Specify  the  minion  ID  to  match  against  the  target
                 expression

                 New in version 2014.7.0.

          CLI Example:

             salt '*' match.list 'server1,server2'

   salt.modules.match.pcre(tgt, minion_id=None)
          Return True if the minion ID matches the given pcre target

          minion_id
                 Specify  the  minion  ID  to  match  against  the  target
                 expression

                 New in version 2014.7.0.

          CLI Example:

             salt '*' match.pcre '.*'

   salt.modules.match.pillar(tgt, delimiter=':')
          Return  True  if the minion matches the given pillar target. The
          delimiter argument can be used to specify a different delimiter.

          CLI Example:

             salt '*' match.pillar 'cheese:foo'
             salt '*' match.pillar 'clone_url|https://github.com/saltstack/salt.git' delimiter='|'

          delimiter
                 Specify an alternate delimiter to use when  traversing  a
                 nested dict

                 New in version 2014.7.0.

          delim  Specify  an  alternate delimiter to use when traversing a
                 nested dict

                 New in version 0.16.4.

                 Deprecated since version 2015.8.0.

   salt.modules.match.pillar_pcre(tgt, delimiter=':')
          Return True if the minion matches the given pillar_pcre  target.
          The  delimiter  argument  can  be  used  to  specify a different
          delimiter.

          CLI Example:

             salt '*' match.pillar_pcre 'cheese:(swiss|american)'
             salt '*' match.pillar_pcre 'clone_url|https://github\.com/.*\.git' delimiter='|'

          delimiter
                 Specify an alternate delimiter to use when  traversing  a
                 nested dict

                 New in version 2014.7.0.

          delim  Specify  an  alternate delimiter to use when traversing a
                 nested dict

                 New in version 0.16.4.

                 Deprecated since version 2015.8.0.

   salt.modules.mdadm
   Salt module to manage RAID arrays with mdadm

   salt.modules.mdadm.assemble(name, devices, test_mode=False, **kwargs)
          Assemble a RAID device.

          CLI Examples:

             salt '*' raid.assemble /dev/md0 ['/dev/xvdd', '/dev/xvde']

          NOTE:
             Adding test_mode=True as an argument will print out the mdadm
             command that would have been run.

          name   The name of the array to assemble.

          devices
                 The list of devices comprising the array to assemble.

          kwargs Optional arguments to be passed to mdadm.

          returns

                 test_mode=True:
                        Prints out the full command.

                 test_mode=False (Default):
                        Executes command on the host(s) and prints out the
                        mdadm output.

          For more info, read the mdadm manpage.

   salt.modules.mdadm.create(name,  level,  devices,   metadata='default',
   test_mode=False, **kwargs)
          Create a RAID device.

          Changed in version 2014.7.0.

          WARNING:
             Use with CAUTION, as this function can be very destructive if
             not used properly!

          CLI Examples:

             salt '*' raid.create /dev/md0 level=1 chunk=256 devices="['/dev/xvdd', '/dev/xvde']" test_mode=True

          NOTE:
             Adding test_mode=True as an argument will print out the mdadm
             command that would have been run.

          name   The name of the array to create.

          level  The RAID level to use when creating the raid.

          devices
                 A list of devices used to build the array.

          metadata
                 Version of metadata to use when creating the array.

          kwargs Optional arguments to be passed to mdadm.

          returns

                 test_mode=True:
                        Prints out the full command.

                 test_mode=False (Default):
                        Executes  command on remote the host(s) and Prints
                        out the mdadm output.

          NOTE:
             It takes time to create a  RAID  array.  You  can  check  the
             progress  in  "resync_status:"  field of the results from the
             following command:

                 salt '*' raid.detail /dev/md0

          For more info, read the mdadm(8) manpage

   salt.modules.mdadm.destroy(device)
          Destroy a RAID device.

          WARNING This will zero the superblock of all members of the RAID
          array..

          CLI Example:

             salt '*' raid.destroy /dev/md0

   salt.modules.mdadm.detail(device='/dev/md0')
          Show detail for a specified RAID device

          CLI Example:

             salt '*' raid.detail '/dev/md0'

   salt.modules.mdadm.list()
          List the RAID devices.

          CLI Example:

             salt '*' raid.list

   salt.modules.mdadm.save_config()
          Save RAID configuration to config file.

          Same as: mdadm --detail --scan >> /etc/mdadm/mdadm.conf

          Fixes        this       issue       with       Ubuntu       REF:
          http://askubuntu.com/questions/209702/why-is-my-raid-dev-md1-showing-up-as-dev-md126-is-mdadm-conf-being-ignored

          CLI Example:

             salt '*' raid.save_config

   salt.modules.mdadm.stop()
          Shut  down  all  arrays  that  can  be  shut  down (i.e. are not
          currently in use).

          CLI Example:

             salt '*' raid.stop

   salt.modules.mdata
   Module for managaging metadata in SmartOS Zones

   New in version 2016.3.0.

   maintainer
          Jorge Schrauwen <[email protected]>

   maturity
          new

   platform
          smartos

   salt.modules.mdata.delete(*keyname)
          Delete metadata

          prop   string name of property

          CLI Example:

             salt '*' mdata.get salt:role
             salt '*' mdata.get user-script salt:role

   salt.modules.mdata.get(*keyname)
          Get metadata

          keyname
                 string name of key

          NOTE:
             If no keynames are specified, we get all (public) properties

          CLI Example:

             salt '*' mdata.get salt:role
             salt '*' mdata.get user-script salt:role

   salt.modules.mdata.list()
          List available metadata

          CLI Example:

             salt '*' mdata.list

   salt.modules.mdata.put(keyname, val)
          Put metadata

          prop   string name of property

          val    string value to set

          CLI Example:

             salt '*' mdata.list

   salt.modules.memcached
   Module for Management of Memcached Keys

   New in version 2014.1.0.

   salt.modules.memcached.add(key,  value,  host='127.0.0.1',  port=11211,
   time=0, min_compress_len=0)
          Add  a  key  to  the  memcached  server, but only if it does not
          exist. Returns False if the key already exists.

          CLI Example:

             salt '*' memcached.add <key> <value>

   salt.modules.memcached.decrement(key,    delta=1,     host='127.0.0.1',
   port=11211)
          Decrement the value of a key

          CLI Example:

             salt '*' memcached.decrement <key>
             salt '*' memcached.decrement <key> 2

   salt.modules.memcached.delete(key,     host='127.0.0.1',    port=11211,
   time=0)
          Delete a key from memcache server

          CLI Example:

             salt '*' memcached.delete <key>

   salt.modules.memcached.get(key, host='127.0.0.1', port=11211)
          Retrieve value for a key

          CLI Example:

             salt '*' memcached.get <key>

   salt.modules.memcached.increment(key,    delta=1,     host='127.0.0.1',
   port=11211)
          Increment the value of a key

          CLI Example:

             salt '*' memcached.increment <key>
             salt '*' memcached.increment <key> 2

   salt.modules.memcached.replace(key,       value,      host='127.0.0.1',
   port=11211, time=0, min_compress_len=0)
          Replace a key on the memcached server. This only succeeds if the
          key already exists. This is the opposite of memcached.add

          CLI Example:

             salt '*' memcached.replace <key> <value>

   salt.modules.memcached.set(key,  value,  host='127.0.0.1',  port=11211,
   time=0, min_compress_len=0)
          Set a key on the memcached server, overwriting the value  if  it
          exists.

          CLI Example:

             salt '*' memcached.set <key> <value>

   salt.modules.memcached.status(host='127.0.0.1', port=11211)
          Get memcached status

          CLI Example:

             salt '*' memcached.status

   salt.modules.mine
   The function cache system allows for data to be stored on the master so
   it can be easily read by other minions

   salt.modules.mine.delete(fun)
          Remove specific function contents of  minion.  Returns  True  on
          success.

          CLI Example:

             salt '*' mine.delete 'network.interfaces'

   salt.modules.mine.flush()
          Remove all mine contents of minion. Returns True on success.

          CLI Example:

             salt '*' mine.flush

   salt.modules.mine.get(tgt, fun, expr_form='glob', exclude_minion=False)
          Get  data  from  the  mine  based  on  the  target, function and
          expr_form

          Targets can be matched based on  any  standard  matching  system
          that can be matched on the master via these keywords:

             glob
             pcre
             grain
             grain_pcre
             compound
             pillar
             pillar_pcre

          Note  that  all  pillar  matches,  whether  using  the  compound
          matching system or the pillar matching  system,  will  be  exact
          matches, with globbing disabled.

          exclude_minion
                 Excludes the current minion from the result set

          CLI Example:

             salt '*' mine.get '*' network.interfaces
             salt '*' mine.get 'os:Fedora' network.interfaces grain
             salt '*' mine.get 'os:Fedora and [email protected]/24' network.ipaddrs compound

          SEE ALSO:
             Retrieving Mine data from Pillar and Orchestrate

             This  execution module is intended to be executed on minions.
             Master-side operations such as  Pillar  or  Orchestrate  that
             require  Mine data should use the Mine Runner module instead;
             it can be invoked from an SLS file using the  saltutil.runner
             module. For example:

                 {% set minion_ips = salt.saltutil.runner('mine.get',
                     tgt='*',
                     fun='network.ip_addrs',
                     tgt_type='glob') %}

   salt.modules.mine.get_docker(interfaces=None,               cidrs=None,
   with_container_id=False)
          Get  all  mine  data  for  'docker.get_containers'  and  run  an
          aggregation  routine.  The  "interfaces"  parameter  allows  for
          specifying which network interfaces to select ip addresses from.
          The  "cidrs"  parameter  allows  for  specifying a list of cidrs
          which the ip address must match.

          with_container_id
                 Boolean, to expose container_id in the list of results

                 New in version 2015.8.2.

          CLI Example:

             salt '*' mine.get_docker
             salt '*' mine.get_docker interfaces='eth0'
             salt '*' mine.get_docker interfaces='["eth0", "eth1"]'
             salt '*' mine.get_docker cidrs='107.170.147.0/24'
             salt '*' mine.get_docker cidrs='["107.170.147.0/24", "172.17.42.0/24"]'
             salt '*' mine.get_docker interfaces='["eth0", "eth1"]' cidrs='["107.170.147.0/24", "172.17.42.0/24"]'

   salt.modules.mine.send(func, *args, **kwargs)
          Send a specific function to the mine.

          CLI Example:

             salt '*' mine.send network.ip_addrs eth0
             salt '*' mine.send eth0_ip_addrs mine_function=network.ip_addrs eth0

   salt.modules.mine.update(clear=False)
          Execute the configured functions and send the data  back  up  to
          the  master.   The  functions to be executed are merged from the
          master  config,  pillar  and  minion  config  under  the  option
          mine_functions:

             mine_functions:
               network.ip_addrs:
                 - eth0
               disk.usage: []

          The  function  cache  will  be  populated  with information from
          executing these functions

          CLI Example:

             salt '*' mine.update

   salt.modules.mine.valid()
          List valid entries in mine configuration.

          CLI Example:

             salt '*' mine.valid

   salt.modules.minion module
   Module to provide information about minions

   salt.modules.minion.kill(timeout=15)
          Kill the salt minion.

          timeout
                 int seconds to wait for the minion to die.

          If you have a monitor that restarts  salt-minion  when  it  dies
          then this is a great way to restart after a minion upgrade.

          CLI example:

             >$ salt minion[12] minion.kill
             minion1:
                 ----------
                 killed:
                     7874
                 retcode:
                     0
             minion2:
                 ----------
                 killed:
                     29071
                 retcode:
                     0

          The  result  of  the  salt  command  shows the process ID of the
          minions and the results of a kill signal to the minion in as the
          retcode value: 0 is success, anything else is a failure.

   salt.modules.minion.list()
          Return a list of accepted, denied, unaccepted and rejected keys.
          This is the same output as salt-key -L

          CLI Example:

             salt 'master' minion.list

   salt.modules.minion.restart()
          Kill and restart the salt minion.

          The configuration key minion_restart_command is an argv list for
          the command to restart the minion.  If minion_restart_command is
          not specified or empty then the argv of the current process will
          be used.

          if the configuration value minion_restart_command is not set and
          the -d (daemonize) argument is missing from argv then the minion
          will  be  killed  but will not be restarted and will require the
          parent  process  to  perform  the  restart.   This  behavior  is
          intended for managed salt minion processes.

          CLI example:

             >$ salt minion[12] minion.restart
             minion1:
                 ----------
                 comment:
                     - Restart using process argv:
                     -     /home/omniture/install/bin/salt-minion
                     -     -d
                     -     -c
                     -     /home/omniture/install/etc/salt
                 killed:
                     10070
                 restart:
                     ----------
                     stderr:
                     stdout:
                 retcode:
                     0
             minion2:
                 ----------
                 comment:
                     - Using configuration minion_restart_command:
                     -     /home/omniture/install/bin/salt-minion
                     -     --not-an-option
                     -     -d
                     -     -c
                     -     /home/omniture/install/etc/salt
                     - Restart failed
                 killed:
                     10896
                 restart:
                     ----------
                     stderr:
                         Usage: salt-minion

                         salt-minion: error: no such option: --not-an-option
                     stdout:
                 retcode:
                     64

          The  result  of the command shows the process ID of minion1 that
          is shutdown (killed) and the results of the restart.   If  there
          is  a  failure in the restart it will be reflected in a non-zero
          retcode and possibly output in the stderr and/or  stdout  values
          along  with  addition  information  in  the  comment field as is
          demonstrated with minion2.

   salt.modules.mod_random
   Provides access to randomness generators.
   New in version 2014.7.0.

   salt.modules.mod_random.get_str(length=20)
          New in version 2014.7.0.

          Returns a random string of the specified length.

          length 20 Any valid number of bytes.

          CLI Example:

             salt '*' random.get_str 128

   salt.modules.mod_random.hash(value, algorithm='sha512')
          New in version 2014.7.0.

          Encodes a value with the specified encoder.

          value  The value to be hashed.

          algorithm
                 sha512 The algorithm to use. May be any  valid  algorithm
                 supported by hashlib.

          CLI Example:

             salt '*' random.hash 'I am a string' md5

   salt.modules.mod_random.rand_int(start=1, end=10)
          Returns  a  random  integer  number  between  the  start and end
          number.

          start  1 Any valid integer number

          end    10 Any valid integer number

          CLI Example:

             salt '*' random.rand_int 1 10

   salt.modules.mod_random.seed(range=10, hash=None)
          Returns a random number within a range. Optional  hash  argument
          can  be  any hashable object. If hash is omitted or None, the id
          of the minion is used.

          hash: None
                 Any hashable object.

          range: 10
                 Any valid integer number

          CLI Example:

             salt '*' random.seed 10 hash=None

   salt.modules.mod_random.shadow_hash(crypt_salt=None,     password=None,
   algorithm='sha512')
          Generates a salted hash suitable for /etc/shadow.

          crypt_salt
                 None  Salt  to  be used in the generation of the hash. If
                 one is not provided, a random salt will be generated.

          password
                 None Value to  be  salted  and  hashed.  If  one  is  not
                 provided, a random password will be generated.

          algorithm
                 sha512 Hash algorithm to use.

          CLI Example:

             salt '*' random.shadow_hash 'My5alT' 'MyP@asswd' md5

   salt.modules.mod_random.str_encode(value, encoder='base64')
          New in version 2014.7.0.

          value  The value to be encoded.

          encoder
                 base64 The encoder to use on the subsequent string.

          CLI Example:

             salt '*' random.str_encode 'I am a new string' base64

   salt.modules.modjk
   Control    Modjk   via   the   Apache   Tomcat   "Status"   worker   (
   http://tomcat.apache.org/connectors-doc/reference/status.html)

   Below is an example of the configuration needed for this  module.  This
   configuration data can be placed either in grains or pillar.

   If  using  grains,  this  can be accomplished statically or via a grain
   module.

   If using pillar, the yaml configuration can be placed directly  into  a
   pillar SLS file, making this both the easier and more dynamic method of
   configuring this module.

      modjk:
        default:
          url: http://localhost/jkstatus
          user: modjk
          pass: secret
          realm: authentication realm for digest passwords
          timeout: 5
        otherVhost:
          url: http://otherVhost/jkstatus
          user: modjk
          pass: secret2
          realm: authentication realm2 for digest passwords
          timeout: 600

   salt.modules.modjk.bulk_activate(workers, lbn, profile='default')
          Activate all the given workers in the specific load balancer

          CLI Examples:

             salt '*' modjk.bulk_activate node1,node2,node3 loadbalancer1
             salt '*' modjk.bulk_activate node1,node2,node3 loadbalancer1 other-profile

             salt '*' modjk.bulk_activate ["node1","node2","node3"] loadbalancer1
             salt '*' modjk.bulk_activate ["node1","node2","node3"] loadbalancer1 other-profile

   salt.modules.modjk.bulk_disable(workers, lbn, profile='default')
          Disable all the given workers in the specific load balancer

          CLI Examples:

             salt '*' modjk.bulk_disable node1,node2,node3 loadbalancer1
             salt '*' modjk.bulk_disable node1,node2,node3 loadbalancer1 other-profile

             salt '*' modjk.bulk_disable ["node1","node2","node3"] loadbalancer1
             salt '*' modjk.bulk_disable ["node1","node2","node3"] loadbalancer1 other-profile

   salt.modules.modjk.bulk_recover(workers, lbn, profile='default')
          Recover all the given workers in the specific load balancer

          CLI Examples:

             salt '*' modjk.bulk_recover node1,node2,node3 loadbalancer1
             salt '*' modjk.bulk_recover node1,node2,node3 loadbalancer1 other-profile

             salt '*' modjk.bulk_recover ["node1","node2","node3"] loadbalancer1
             salt '*' modjk.bulk_recover ["node1","node2","node3"] loadbalancer1 other-profile

   salt.modules.modjk.bulk_stop(workers, lbn, profile='default')
          Stop all the given workers in the specific load balancer

          CLI Examples:

             salt '*' modjk.bulk_stop node1,node2,node3 loadbalancer1
             salt '*' modjk.bulk_stop node1,node2,node3 loadbalancer1 other-profile

             salt '*' modjk.bulk_stop ["node1","node2","node3"] loadbalancer1
             salt '*' modjk.bulk_stop ["node1","node2","node3"] loadbalancer1 other-profile

   salt.modules.modjk.dump_config(profile='default')
          Dump the original configuration that was loaded from disk

          CLI Examples:

             salt '*' modjk.dump_config
             salt '*' modjk.dump_config other-profile

   salt.modules.modjk.get_running(profile='default')
          Get the current running config (not from disk)

          CLI Examples:

             salt '*' modjk.get_running
             salt '*' modjk.get_running other-profile

   salt.modules.modjk.lb_edit(lbn, settings, profile='default')
          Edit the loadbalancer settings

          Note:
          http://tomcat.apache.org/connectors-doc/reference/status.html
          Data Parameters for the standard Update Action

          CLI Examples:

             salt '*' modjk.lb_edit loadbalancer1 "{'vlr': 1, 'vlt': 60}"
             salt '*' modjk.lb_edit loadbalancer1 "{'vlr': 1, 'vlt': 60}" other-profile

   salt.modules.modjk.list_configured_members(lbn, profile='default')
          Return a list of member workers from the configuration files

          CLI Examples:

             salt '*' modjk.list_configured_members loadbalancer1
             salt '*' modjk.list_configured_members loadbalancer1 other-profile

   salt.modules.modjk.recover_all(lbn, profile='default')
          Set the all the workers in lbn to recover and activate  them  if
          they are not

          CLI Examples:

             salt '*' modjk.recover_all loadbalancer1
             salt '*' modjk.recover_all loadbalancer1 other-profile

   salt.modules.modjk.reset_stats(lbn, profile='default')
          Reset all runtime statistics for the load balancer

          CLI Examples:

             salt '*' modjk.reset_stats loadbalancer1
             salt '*' modjk.reset_stats loadbalancer1 other-profile

   salt.modules.modjk.version(profile='default')
          Return the modjk version

          CLI Examples:

             salt '*' modjk.version
             salt '*' modjk.version other-profile

   salt.modules.modjk.worker_activate(worker, lbn, profile='default')
          Set the worker to activate state in the lbn load balancer

          CLI Examples:

             salt '*' modjk.worker_activate node1 loadbalancer1
             salt '*' modjk.worker_activate node1 loadbalancer1 other-profile

   salt.modules.modjk.worker_disable(worker, lbn, profile='default')
          Set the worker to disable state in the lbn load balancer

          CLI Examples:

             salt '*' modjk.worker_disable node1 loadbalancer1
             salt '*' modjk.worker_disable node1 loadbalancer1 other-profile

   salt.modules.modjk.worker_edit(worker,          lbn,          settings,
   profile='default')
          Edit the worker settings

          Note:
          http://tomcat.apache.org/connectors-doc/reference/status.html
          Data Parameters for the standard Update Action

          CLI Examples:

             salt '*' modjk.worker_edit node1 loadbalancer1 "{'vwf': 500, 'vwd': 60}"
             salt '*' modjk.worker_edit node1 loadbalancer1 "{'vwf': 500, 'vwd': 60}" other-profile

   salt.modules.modjk.worker_recover(worker, lbn, profile='default')
          Set the worker to recover this module will fail if it is  in  OK
          state

          CLI Examples:

             salt '*' modjk.worker_recover node1 loadbalancer1
             salt '*' modjk.worker_recover node1 loadbalancer1 other-profile

   salt.modules.modjk.worker_status(worker, profile='default')
          Return the state of the worker

          CLI Examples:

             salt '*' modjk.worker_status node1
             salt '*' modjk.worker_status node1 other-profile

   salt.modules.modjk.worker_stop(worker, lbn, profile='default')
          Set the worker to stopped state in the lbn load balancer

          CLI Examples:

             salt '*' modjk.worker_activate node1 loadbalancer1
             salt '*' modjk.worker_activate node1 loadbalancer1 other-profile

   salt.modules.modjk.workers(profile='default')
          Return a list of member workers and their status

          CLI Examples:

             salt '*' modjk.workers
             salt '*' modjk.workers other-profile

   salt.modules.mongodb
   Module to provide MongoDB functionality to Salt

   configuration
          This  module  uses PyMongo, and accepts configuration details as
          parameters as well as configuration settings:

             mongodb.host: 'localhost'
             mongodb.port: 27017
             mongodb.user: ''
             mongodb.password: ''

          This data can also be passed into pillar.  Options  passed  into
          opts will overwrite options passed into pillar.

   salt.modules.mongodb.db_exists(name,      user=None,     password=None,
   host=None, port=None, authdb=None)
          Checks if a database exists in Mongodb

          CLI Example:

             salt '*' mongodb.db_exists <name> <user> <password> <host> <port>

   salt.modules.mongodb.db_list(user=None,    password=None,    host=None,
   port=None, authdb=None)
          List all Mongodb databases

          CLI Example:

             salt '*' mongodb.db_list <user> <password> <host> <port>

   salt.modules.mongodb.db_remove(name,      user=None,     password=None,
   host=None, port=None, authdb=None)
          Remove a Mongodb database

          CLI Example:

             salt '*' mongodb.db_remove <name> <user> <password> <host> <port>

   salt.modules.mongodb.find(collection,      query=None,       user=None,
   password=None, host=None, port=None, database='admin', authdb=None)
          Find an object or list of objects in a collection

          CLI Example:

             salt '*' mongodb.find mycollection '[{"foo": "FOO", "bar": "BAR"}]' <user> <password> <host> <port> <database>

   salt.modules.mongodb.insert(objects,       collection,       user=None,
   password=None, host=None, port=None, database='admin', authdb=None)
          Insert an object or list of objects into a collection

          CLI Example:

             salt '*' mongodb.insert '[{"foo": "FOO", "bar": "BAR"}, {"foo": "BAZ", "bar": "BAM"}]' mycollection <user> <password> <host> <port> <database>

   salt.modules.mongodb.remove(collection,     query=None,      user=None,
   password=None,    host=None,    port=None,    database='admin',    w=1,
   authdb=None)
          Remove an object or list of objects into a collection

          CLI Example:

             salt '*' mongodb.remove mycollection '[{"foo": "FOO", "bar": "BAR"}, {"foo": "BAZ", "bar": "BAM"}]' <user> <password> <host> <port> <database>

   salt.modules.mongodb.update_one(objects,     collection,     user=None,
   password=None, host=None, port=None, database='admin', authdb=None)
          Update       an       object       into       a       collection
          http://api.mongodb.com/python/current/api/pymongo/collection.html#pymongo.collection.Collection.update_one

          New in version 2016.11.0.

          CLI Example:

             salt '*' mongodb.update_one '{"_id": "my_minion"} {"bar": "BAR"}' mycollection <user> <password> <host> <port> <database>

   salt.modules.mongodb.user_create(name,        passwd,        user=None,
   password=None, host=None, port=None, database='admin', authdb=None)
          Create a Mongodb user

          CLI Example:

             salt '*' mongodb.user_create <name> <user> <password> <host> <port> <database>

   salt.modules.mongodb.user_exists(name,    user=None,     password=None,
   host=None, port=None, database='admin', authdb=None)
          Checks if a user exists in Mongodb

          CLI Example:

             salt '*' mongodb.user_exists <name> <user> <password> <host> <port> <database>

   salt.modules.mongodb.user_grant_roles(name, roles, database, user=None,
   password=None, host=None, port=None, authdb=None)
          Grant one or many roles to a Mongodb user

          CLI Examples:

             salt '*' mongodb.user_grant_roles johndoe '["readWrite"]' dbname admin adminpwd localhost 27017

             salt '*' mongodb.user_grant_roles janedoe '[{"role": "readWrite", "db": "dbname" }, {"role": "read", "db": "otherdb"}]' dbname admin adminpwd localhost 27017

   salt.modules.mongodb.user_list(user=None,   password=None,   host=None,
   port=None, database='admin', authdb=None)
          List users of a Mongodb database

          CLI Example:

             salt '*' mongodb.user_list <user> <password> <host> <port> <database>

   salt.modules.mongodb.user_remove(name,     user=None,    password=None,
   host=None, port=None, database='admin', authdb=None)
          Remove a Mongodb user

          CLI Example:

             salt '*' mongodb.user_remove <name> <user> <password> <host> <port> <database>

   salt.modules.mongodb.user_revoke_roles(name,      roles,      database,
   user=None, password=None, host=None, port=None, authdb=None)
          Revoke one or many roles to a Mongodb user

          CLI Examples:

             salt '*' mongodb.user_revoke_roles johndoe '["readWrite"]' dbname admin adminpwd localhost 27017

             salt '*' mongodb.user_revoke_roles janedoe '[{"role": "readWrite", "db": "dbname" }, {"role": "read", "db": "otherdb"}]' dbname admin adminpwd localhost 27017

   salt.modules.mongodb.user_roles_exists(name,      roles,      database,
   user=None, password=None, host=None, port=None, authdb=None)
          Checks if a user of a Mongodb database has specified roles

          CLI Examples:

             salt '*' mongodb.user_roles_exists johndoe '["readWrite"]' dbname admin adminpwd localhost 27017

             salt '*' mongodb.user_roles_exists johndoe '[{"role": "readWrite", "db": "dbname" }, {"role": "read", "db": "otherdb"}]' dbname admin adminpwd localhost 27017

   salt.modules.monit
   Monit service module. This module will  create  a  monit  type  service
   watcher.

   salt.modules.monit.configtest()
          New in version 2016.3.0.

          Test monit configuration syntax

          CLI Example:

             salt '*' monit.configtest

   salt.modules.monit.id(reset=False)
          New in version 2016.3.0.

          Return monit unique id.

          reset  False  Reset  current  id and generate a new id when it's
                 True.

          CLI Example:

             salt '*' monit.id [reset=True]

   salt.modules.monit.monitor(name)
          monitor service via monit

          CLI Example:

             salt '*' monit.monitor <service name>

   salt.modules.monit.reload()
          New in version 2016.3.0.

          Reload monit configuration

          CLI Example:

             salt '*' monit.reload

   salt.modules.monit.restart(name)
          Restart service via monit

          CLI Example:

             salt '*' monit.restart <service name>

   salt.modules.monit.start(name)
          CLI Example:

             salt '*' monit.start <service name>

   salt.modules.monit.status(svc_name='')
          Display a process status from monit

          CLI Example:

             salt '*' monit.status
             salt '*' monit.status <service name>

   salt.modules.monit.stop(name)
          Stops service via monit

          CLI Example:

             salt '*' monit.stop <service name>

   salt.modules.monit.summary(svc_name='')
          Display a summary from monit

          CLI Example:

             salt '*' monit.summary
             salt '*' monit.summary <service name>

   salt.modules.monit.unmonitor(name)
          Unmonitor service via monit

          CLI Example:

             salt '*' monit.unmonitor <service name>

   salt.modules.monit.validate()
          New in version 2016.3.0.

          Check all services

          CLI Example:

             salt '*' monit.validate

   salt.modules.monit.version()
          New in version 2016.3.0.

          Return version from monit -V

          CLI Example:

             salt '*' monit.version

   salt.modules.moosefs
   Module for gathering and managing information about MooseFS

   salt.modules.moosefs.dirinfo(path, opts=None)
          Return information on a directory located on the Moose

          CLI Example:

             salt '*' moosefs.dirinfo /path/to/dir/ [-[n][h|H]]

   salt.modules.moosefs.fileinfo(path)
          Return information on a file located on the Moose

          CLI Example:

             salt '*' moosefs.fileinfo /path/to/dir/

   salt.modules.moosefs.getgoal(path, opts=None)
          Return goal(s) for a file or directory

          CLI Example:

             salt '*' moosefs.getgoal /path/to/file [-[n][h|H]]
             salt '*' moosefs.getgoal /path/to/dir/ [-[n][h|H][r]]

   salt.modules.moosefs.mounts()
          Return a list of current MooseFS mounts

          CLI Example:

             salt '*' moosefs.mounts

   salt.modules.mount
   Salt module to manage Unix mounts and the fstab file

   salt.modules.mount.active(extended=False)
          List the active mounts.

          CLI Example:

             salt '*' mount.active

   salt.modules.mount.automaster(config='/etc/auto_salt')
          List the contents of the auto master

          CLI Example:

             salt '*' mount.automaster

   salt.modules.mount.fstab(config='/etc/fstab')
          Changed in version 2016.3.2.

          List the contents of the fstab

          CLI Example:

             salt '*' mount.fstab

   salt.modules.mount.is_fuse_exec(cmd)
          Returns  true  if  the  command  passed  is  a  fuse   mountable
          application.

          CLI Example:

             salt '*' mount.is_fuse_exec sshfs

   salt.modules.mount.is_mounted(name)
          New in version 2014.7.0.

          Provide information if the path is mounted

          CLI Example:

             salt '*' mount.is_mounted /mnt/share

   salt.modules.mount.mount(name,    device,    mkmnt=False,    fstype='',
   opts='defaults', user=None, util='mount')
          Mount a device

          CLI Example:

             salt '*' mount.mount /mnt/foo /dev/sdz1 True

   salt.modules.mount.remount(name,   device,   mkmnt=False,    fstype='',
   opts='defaults', user=None)
          Attempt  to  remount  a  device,  if  the  device is not already
          mounted, mount is called

          CLI Example:

             salt '*' mount.remount /mnt/foo /dev/sdz1 True

   salt.modules.mount.rm_automaster(name, device, config='/etc/auto_salt')
          Remove the mount point from the auto_master

          CLI Example:

             salt '*' mount.rm_automaster /mnt/foo /dev/sdg

   salt.modules.mount.rm_fstab(name, device, config='/etc/fstab')
          Changed in version 2016.3.2.

          Remove the mount point from the fstab

          CLI Example:

             salt '*' mount.rm_fstab /mnt/foo /dev/sdg

   salt.modules.mount.rm_vfstab(name, device, config='/etc/vfstab')
          New in version 2016.3.2.

          Remove the mount point from the vfstab

          CLI Example:

             salt '*' mount.rm_vfstab /mnt/foo /device/c0t0d0p0

   salt.modules.mount.set_automaster(name,   device,   fstype,    opts='',
   config='/etc/auto_salt', test=False, **kwargs)
          Verify  that  this mount is represented in the auto_salt, change
          the mount to match the data passed, or add the mount  if  it  is
          not present.

          CLI Example:

             salt '*' mount.set_automaster /mnt/foo /dev/sdz1 ext4

   salt.modules.mount.set_fstab(name,   device,  fstype,  opts='defaults',
   dump=0, pass_num=0, config='/etc/fstab',  test=False,  match_on='auto',
   **kwargs)
          Verify  that  this mount is represented in the fstab, change the
          mount to match the data passed, or add the mount if  it  is  not
          present.

          CLI Example:

             salt '*' mount.set_fstab /mnt/foo /dev/sdz1 ext4

   salt.modules.mount.set_vfstab(name,     device,    fstype,    opts='-',
   device_fsck='-',          pass_fsck='-',           mount_at_boot='yes',
   config='/etc/vfstab', test=False, match_on='auto', **kwargs)
          ..verionadded::  2016.3.2  Verify that this mount is represented
          in the fstab, change the mount to match the data passed, or  add
          the mount if it is not present.

          CLI Example:

             salt '*' mount.set_vfstab /mnt/foo /device/c0t0d0p0 ufs

   salt.modules.mount.swapoff(name)
          Deactivate a named swap mount

          Changed in version 2016.3.2.

          CLI Example:

             salt '*' mount.swapoff /root/swapfile

   salt.modules.mount.swapon(name, priority=None)
          Activate a swap disk

          Changed in version 2016.3.2.

          CLI Example:

             salt '*' mount.swapon /root/swapfile

   salt.modules.mount.swaps()
          Return a dict containing information on active swap

          Changed in version 2016.3.2.

          CLI Example:

             salt '*' mount.swaps

   salt.modules.mount.umount(name, device=None, user=None, util='mount')
          Attempt  to  unmount  a device by specifying the directory it is
          mounted on

          CLI Example:

             salt '*' mount.umount /mnt/foo

          New in version 2015.5.0.

             salt '*' mount.umount /mnt/foo /dev/xvdc1

   salt.modules.mount.vfstab(config='/etc/vfstab')
          New in version 2016.3.2.

          List the contents of the vfstab

          CLI Example:

             salt '*' mount.vfstab

   salt.modules.mssql
   Module to provide MS SQL Server compatibility to salt.

   depends

          * FreeTDS

          * pymssql Python module

   configuration
          In order to connect to MS SQL Server, certain  configuration  is
          required in minion configs/pillars on the relevant minions. Some
          sample pillars might look like:

             mssql.server: 'localhost'
             mssql.port:   1433
             mssql.user:   'sysdba'
             mssql.password:   'Some preferable complex password'
             mssql.database: ''

          The default for the port is '1433' and for the  database  is  ''
          (empty  string);  in  most cases they can be left at the default
          setting.  Options that are directly passed into  functions  will
          overwrite options from configs or pillars.

   salt.modules.mssql.db_exists(database_name, **kwargs)
          Find if a specific database exists on the MS SQL server.

          CLI Example:

             salt minion mssql.db_exists database_name='DBNAME'

   salt.modules.mssql.db_list(**kwargs)
          Return the databse list created on a MS SQL server.

          CLI Example:

             salt minion mssql.db_list

   salt.modules.mssql.db_remove(database_name, **kwargs)
          Drops  a  specific database from the MS SQL server.  It will not
          drop any of 'master', 'model', 'msdb' or 'tempdb'.

          CLI Example:

             salt minion mssql.db_remove database_name='DBNAME'

   salt.modules.mssql.login_exists(login, **kwargs)
          Find if a login exists in the MS SQL server.

          CLI Example:

             salt minion mssql.login_exists 'LOGIN'

   salt.modules.mssql.role_create(role, owner=None, **kwargs)
          Creates a new database role.  If no owner is specified, the role
          will  be  owned  by the user that executes CREATE ROLE, which is
          the user argument or mssql.user option.

          CLI Example:

             salt minion mssql.role_create role=product01 owner=sysdba

   salt.modules.mssql.role_exists(role, **kwargs)
          Checks if a role exists.

          CLI Example:

             salt minion mssql.role_exists db_owner

   salt.modules.mssql.role_list(**kwargs)
          Lists database roles.

          CLI Example:

             salt minion mssql.role_list

   salt.modules.mssql.role_remove(role, **kwargs)
          Remove a database role.

          CLI Example:

             salt minion mssql.role_create role=test_role01

   salt.modules.mssql.tsql_query(query, **kwargs)
          Run a SQL query and return query result as list of tuples, or  a
          list  of dictionaries if as_dict was passed, or an empty list if
          no data is available.

          CLI Example:

             salt minion mssql.tsql_query 'SELECT @@version as version' as_dict=True

   salt.modules.mssql.user_create(username,       new_login_password=None,
   **kwargs)
          Creates a new user.  If new_login_password is not specified, the
          user will be created without a login.

          CLI Example:

             salt minion mssql.user_create USERNAME database=DBNAME [new_login_password=PASSWORD]

   salt.modules.mssql.user_exists(username, **kwargs)
          Find if an user exists in a specific  database  on  the  MS  SQL
          server.

          NOTE:
             database argument is mandatory

          CLI Example:

             salt minion mssql.user_exists 'USERNAME' [database='DBNAME']

   salt.modules.mssql.user_list(**kwargs)
          Get the user list for a specific database on the MS SQL server.

          CLI Example:

             salt minion mssql.user_list [database='DBNAME']

   salt.modules.mssql.user_remove(username, **kwargs)
          Removes an user.

          CLI Example:

             salt minion mssql.user_remove USERNAME database=DBNAME

   salt.modules.mssql.version(**kwargs)
          Return the version of a MS SQL server.

          CLI Example:

             salt minion mssql.version

   salt.modules.munin
   Run munin plugins/checks from salt and format the output as data.

   salt.modules.munin.list_plugins()
          List all the munin plugins

          CLI Example:

             salt '*' munin.list_plugins

   salt.modules.munin.run(plugins)
          Run one or more named munin plugins

          CLI Example:

             salt '*' munin.run uptime
             salt '*' munin.run uptime,cpu,load,memory

   salt.modules.munin.run_all()
          Run all the munin plugins

          CLI Example:

             salt '*' munin.run_all

   salt.modules.mysql
   Module to provide MySQL compatibility to salt.

   depends

          * MySQLdb Python module

   NOTE:
      On   CentOS   5   (and   possibly  RHEL  5)  both  MySQL-python  and
      python26-mysqldb need to be installed.

   configuration
          In order to connect to MySQL, certain configuration is  required
          in /etc/salt/minion on the relevant minions. Some sample configs
          might look like:

             mysql.host: 'localhost'
             mysql.port: 3306
             mysql.user: 'root'
             mysql.pass: ''
             mysql.db: 'mysql'
             mysql.unix_socket: '/tmp/mysql.sock'
             mysql.charset: 'utf8'

          You can also use a defaults file:

             mysql.default_file: '/etc/mysql/debian.cnf'

   Changed in version 2014.1.0: 'charset' connection argument added.  This
   is a MySQL charset, not a python one.

   Changed  in version 0.16.2: Connection arguments from the minion config
   file can be overridden on the CLI by using the arguments defined  here.
   Additionally, it is now possible to setup a user with no password.

   salt.modules.mysql.alter_db(name,   character_set=None,   collate=None,
   **connection_args)
          Modify database using ALTER DATABASE  %(dbname)s  CHARACTER  SET
          %(charset)s COLLATE %(collation)s; query.

          CLI Example:

             salt '*' mysql.alter_db testdb charset='latin1'

   salt.modules.mysql.db_check(name, table=None, **connection_args)
          Repairs the full database or just a given table

          CLI Example:

             salt '*' mysql.db_check dbname
             salt '*' mysql.db_check dbname dbtable

   salt.modules.mysql.db_create(name,   character_set=None,  collate=None,
   **connection_args)
          Adds a databases to the MySQL server.

          name   The name of the database to manage

          character_set
                 The character set, if left empty the MySQL  default  will
                 be used

          collate
                 The  collation,  if  left empty the MySQL default will be
                 used

          CLI Example:

             salt '*' mysql.db_create 'dbname'
             salt '*' mysql.db_create 'dbname' 'utf8' 'utf8_general_ci'

   salt.modules.mysql.db_exists(name, **connection_args)
          Checks if a database exists on the MySQL server.

          CLI Example:

             salt '*' mysql.db_exists 'dbname'

   salt.modules.mysql.db_get(name, **connection_args)
          Return a list of databases of a MySQL server  using  the  output
          from        the        SELECT        DEFAULT_CHARACTER_SET_NAME,
          DEFAULT_COLLATION_NAME  FROM  INFORMATION_SCHEMA.SCHEMATA  WHERE
          SCHEMA_NAME='dbname'; query.

          CLI Example:

             salt '*' mysql.db_get test

   salt.modules.mysql.db_list(**connection_args)
          Return  a  list  of databases of a MySQL server using the output
          from the SHOW DATABASES query.

          CLI Example:

             salt '*' mysql.db_list

   salt.modules.mysql.db_optimize(name, table=None, **connection_args)
          Optimizes the full database or just a given table

          CLI Example:

             salt '*' mysql.db_optimize dbname

   salt.modules.mysql.db_remove(name, **connection_args)
          Removes a databases from the MySQL server.

          CLI Example:

             salt '*' mysql.db_remove 'dbname'

   salt.modules.mysql.db_repair(name, table=None, **connection_args)
          Repairs the full database or just a given table

          CLI Example:

             salt '*' mysql.db_repair dbname

   salt.modules.mysql.db_tables(name, **connection_args)
          Shows the tables in the given MySQL database (if exists)

          CLI Example:

             salt '*' mysql.db_tables 'database'

   salt.modules.mysql.free_slave(**connection_args)
          Frees a slave from its master.  This is a WIP, do not use.

          CLI Example:

             salt '*' mysql.free_slave

   salt.modules.mysql.get_master_status(**connection_args)
          Retrieves the master status from the minion.

          Returns:

             {'host.domain.com': {'Binlog_Do_DB': '',
                              'Binlog_Ignore_DB': '',
                              'File': 'mysql-bin.000021',
                              'Position': 107}}

          CLI Example:

             salt '*' mysql.get_master_status

   salt.modules.mysql.get_slave_status(**connection_args)
          Retrieves the slave status from the minion.

          Returns:

             {'host.domain.com': {'Connect_Retry': 60,
                            'Exec_Master_Log_Pos': 107,
                            'Last_Errno': 0,
                            'Last_Error': '',
                            'Last_IO_Errno': 0,
                            'Last_IO_Error': '',
                            'Last_SQL_Errno': 0,
                            'Last_SQL_Error': '',
                            'Master_Host': 'comet.scion-eng.com',
                            'Master_Log_File': 'mysql-bin.000021',
                            'Master_Port': 3306,
                            'Master_SSL_Allowed': 'No',
                            'Master_SSL_CA_File': '',
                            'Master_SSL_CA_Path': '',
                            'Master_SSL_Cert': '',
                            'Master_SSL_Cipher': '',
                            'Master_SSL_Key': '',
                            'Master_SSL_Verify_Server_Cert': 'No',
                            'Master_Server_Id': 1,
                            'Master_User': 'replu',
                            'Read_Master_Log_Pos': 107,
                            'Relay_Log_File': 'klo-relay-bin.000071',
                            'Relay_Log_Pos': 253,
                            'Relay_Log_Space': 553,
                            'Relay_Master_Log_File': 'mysql-bin.000021',
                            'Replicate_Do_DB': '',
                            'Replicate_Do_Table': '',
                            'Replicate_Ignore_DB': '',
                            'Replicate_Ignore_Server_Ids': '',
                            'Replicate_Ignore_Table': '',
                            'Replicate_Wild_Do_Table': '',
                            'Replicate_Wild_Ignore_Table': '',
                            'Seconds_Behind_Master': 0,
                            'Skip_Counter': 0,
                            'Slave_IO_Running': 'Yes',
                            'Slave_IO_State': 'Waiting for master to send event',
                            'Slave_SQL_Running': 'Yes',
                            'Until_Condition': 'None',
                            'Until_Log_File': '',
                            'Until_Log_Pos': 0}}

          CLI Example:

             salt '*' mysql.get_slave_status

   salt.modules.mysql.grant_add(grant, database,  user,  host='localhost',
   grant_option=False, escape=True, ssl_option=False, **connection_args)
          Adds a grant to the MySQL server.

          For database, make sure you specify database.table or database.*

          CLI Example:

             salt '*' mysql.grant_add             'SELECT,INSERT,UPDATE,...' 'database.*' 'frank' 'localhost'

   salt.modules.mysql.grant_exists(grant,          database,         user,
   host='localhost', grant_option=False, escape=True, **connection_args)
          Checks to see if a grant exists in the database

          CLI Example:

             salt '*' mysql.grant_exists              'SELECT,INSERT,UPDATE,...' 'database.*' 'frank' 'localhost'

   salt.modules.mysql.grant_revoke(grant,         database,          user,
   host='localhost', grant_option=False, escape=True, **connection_args)
          Removes a grant from the MySQL server.

          CLI Example:

             salt '*' mysql.grant_revoke             'SELECT,INSERT,UPDATE' 'database.*' 'frank' 'localhost'

   salt.modules.mysql.processlist(**connection_args)
          Retrieves  the  processlist from the MySQL server via "SHOW FULL
          PROCESSLIST".

          Returns: a list of dicts, with each dict representing a process:

                 {'Command': 'Query',
                        'Host': 'localhost', 'Id': 39, 'Info': 'SHOW  FULL
                        PROCESSLIST',  'Rows_examined': 0, 'Rows_read': 1,
                        'Rows_sent': 0, 'State': None, 'Time': 0,  'User':
                        'root', 'db': 'mysql'}

          CLI Example:

             salt '*' mysql.processlist

   salt.modules.mysql.query(database, query, **connection_args)
          Run  an arbitrary SQL query and return the results or the number
          of affected rows.

          CLI Example:

             salt '*' mysql.query mydb "UPDATE mytable set myfield=1 limit 1"

          Return data:

             {'query time': {'human': '39.0ms', 'raw': '0.03899'}, 'rows affected': 1L}

          CLI Example:

             salt '*' mysql.query mydb "SELECT id,name,cash from users limit 3"

          Return data:

             {'columns': ('id', 'name', 'cash'),
                 'query time': {'human': '1.0ms', 'raw': '0.001'},
                 'results': ((1L, 'User 1', Decimal('110.000000')),
                             (2L, 'User 2', Decimal('215.636756')),
                             (3L, 'User 3', Decimal('0.040000'))),
                 'rows returned': 3L}

          CLI Example:

             salt '*' mysql.query mydb 'INSERT into users values (null,"user 4", 5)'

          Return data:

             {'query time': {'human': '25.6ms', 'raw': '0.02563'}, 'rows affected': 1L}

          CLI Example:

             salt '*' mysql.query mydb 'DELETE from users where id = 4 limit 1'

          Return data:

             {'query time': {'human': '39.0ms', 'raw': '0.03899'}, 'rows affected': 1L}

          Jinja Example: Run a query on mydb and use  row  0,  column  0's
          data.

             {{ salt['mysql.query']('mydb', 'SELECT info from mytable limit 1')['results'][0][0] }}

   salt.modules.mysql.quote_identifier(identifier, for_grants=False)
          Return an identifier name (column, table, database, etc) escaped
          for MySQL

          This  means  surrounded  by  "`"  character  and  escaping  this
          character  inside.  It also means doubling the '%' character for
          MySQLdb internal usage.

          Parameters

                 * identifier -- the table, column or database identifier

                 * for_grants -- is False by default, when using  database
                   names  on  grant  queries  you should set it to True to
                   also escape "_" and  "%"  characters  as  requested  by
                   MySQL.  Note  that  theses  characters  should  only be
                   escaped when requesting grants on  the  database  level
                   (my_%db.*)    but    not   for   table   level   grants
                   (my_%db.`foo`)

          CLI Example:

             salt '*' mysql.quote_identifier 'foo`bar'

   salt.modules.mysql.showglobal(**connection_args)
          Retrieves the show global variables from the minion.

          Returns::
                 show global variables full dict

          CLI Example:

             salt '*' mysql.showglobal

   salt.modules.mysql.showvariables(**connection_args)
          Retrieves the show variables from the minion.

          Returns::
                 show variables full dict

          CLI Example:

             salt '*' mysql.showvariables

   salt.modules.mysql.slave_lag(**connection_args)
          Return the number of seconds that a slave SQL server is  lagging
          behind the master, if the host is not a slave it will return -1.
          If the server is configured to be a slave  for  replication  but
          slave  IO  is not running then -2 will be returned. If there was
          an error connecting  to  the  database  or  checking  the  slave
          status, -3 will be returned.

          CLI Example:

             salt '*' mysql.slave_lag

   salt.modules.mysql.status(**connection_args)
          Return  the  status  of a MySQL server using the output from the
          SHOW STATUS query.

          CLI Example:

             salt '*' mysql.status

   salt.modules.mysql.tokenize_grant(grant)
          External wrapper function :param grant: :return: dict

          CLI Example:

             salt '*' mysql.tokenize_grant             "GRANT SELECT, INSERT ON testdb.* TO 'testuser'@'localhost'"

   salt.modules.mysql.user_chpass(user,  host='localhost',  password=None,
   password_hash=None,     allow_passwordless=False,     unix_socket=None,
   password_column=None, **connection_args)
          Change password for a MySQL user

          host   Host for which this user/password combo applies

          password
                 The  password  to  set  for  the  new  user.  Will   take
                 precedence  over  the  password_hash  option  if both are
                 specified.

          password_hash
                 The password  in  hashed  form.  Be  sure  to  quote  the
                 password because YAML doesn't like the *. A password hash
                 can be obtained from the mysql command-line  client  like
                 so:

                    mysql> SELECT PASSWORD('mypass');
                    +-------------------------------------------+
                    | PASSWORD('mypass')                        |
                    +-------------------------------------------+
                    | *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
                    +-------------------------------------------+
                    1 row in set (0.00 sec)

          allow_passwordless
                 If  True,  then password and password_hash can be omitted
                 (or set to None) to permit a passwordless login.

          New in version 0.16.2: The allow_passwordless option was added.

          CLI Examples:

             salt '*' mysql.user_chpass frank localhost newpassword
             salt '*' mysql.user_chpass frank localhost password_hash='hash'
             salt '*' mysql.user_chpass frank localhost allow_passwordless=True

   salt.modules.mysql.user_create(user,  host='localhost',  password=None,
   password_hash=None,     allow_passwordless=False,    unix_socket=False,
   password_column=None, **connection_args)
          Creates a MySQL user

          host   Host for which this user/password combo applies

          password
                 The  password  to  use  for  the  new  user.  Will   take
                 precedence  over  the  password_hash  option  if both are
                 specified.

          password_hash
                 The password  in  hashed  form.  Be  sure  to  quote  the
                 password because YAML doesn't like the *. A password hash
                 can be obtained from the mysql command-line  client  like
                 so:

                    mysql> SELECT PASSWORD('mypass');
                    +-------------------------------------------+
                    | PASSWORD('mypass')                        |
                    +-------------------------------------------+
                    | *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
                    +-------------------------------------------+
                    1 row in set (0.00 sec)

          allow_passwordless
                 If  True,  then password and password_hash can be omitted
                 (or set to None) to permit a passwordless login.

          unix_socket
                 If True and allow_passwordless is True then will be  used
                 unix_socket auth plugin.

          New in version 0.16.2: The allow_passwordless option was added.

          CLI Examples:

             salt '*' mysql.user_create 'username' 'hostname' 'password'
             salt '*' mysql.user_create 'username' 'hostname' password_hash='hash'
             salt '*' mysql.user_create 'username' 'hostname' allow_passwordless=True

   salt.modules.mysql.user_exists(user,  host='localhost',  password=None,
   password_hash=None,       passwordless=False,        unix_socket=False,
   password_column=None, **connection_args)
          Checks  if  a  user  exists  on the MySQL server. A login can be
          checked to see if passwordless login is  permitted  by  omitting
          password and password_hash, and using passwordless=True.

          New in version 0.16.2: The passwordless option was added.

          CLI Example:

             salt '*' mysql.user_exists 'username' 'hostname' 'password'
             salt '*' mysql.user_exists 'username' 'hostname' password_hash='hash'
             salt '*' mysql.user_exists 'username' passwordless=True
             salt '*' mysql.user_exists 'username' password_column='authentication_string'

   salt.modules.mysql.user_grants(user,                  host='localhost',
   **connection_args)
          Shows the grants for the given MySQL user (if it exists)

          CLI Example:

             salt '*' mysql.user_grants 'frank' 'localhost'

   salt.modules.mysql.user_info(user, host='localhost', **connection_args)
          Get full info on a MySQL user

          CLI Example:

             salt '*' mysql.user_info root localhost

   salt.modules.mysql.user_list(**connection_args)
          Return a list of users on a MySQL server

          CLI Example:

             salt '*' mysql.user_list

   salt.modules.mysql.user_remove(user,                  host='localhost',
   **connection_args)
          Delete MySQL user

          CLI Example:

             salt '*' mysql.user_remove frank localhost

   salt.modules.mysql.version(**connection_args)
          Return  the  version of a MySQL server using the output from the
          SELECT VERSION() query.

          CLI Example:

             salt '*' mysql.version

   salt.modules.nacl
   This module helps include encrypted passwords in  pillars,  grains  and
   salt state files.

   depends
          libnacl, https://github.com/saltstack/libnacl

   This  is  often  useful  if  you  wish  to store your pillars in source
   control or share your pillar data with others that you trust.  I  don't
   advise  making  your pillars public regardless if they are encrypted or
   not.

   When generating keys and encrypting passwords use  --local  when  using
   salt-call  for extra security. Also consider using just the salt runner
   nacl when encrypting pillar passwords.

   The nacl lib uses 32byte keys, these keys are base64  encoded  to  make
   your life more simple.  To generate your key or keyfile you can use:

      salt-call --local nacl.keygen keyfile=/root/.nacl

   Now with your key, you can encrypt some data:

      salt-call --local nacl.enc mypass keyfile=/root/.nacl
      DRB7Q6/X5gGSRCTpZyxS6hXO5LnlJIIJ4ivbmUlbWj0llUA+uaVyvou3vJ4=

   To decrypt the data:

      salt-call --local nacl.dec data='DRB7Q6/X5gGSRCTpZyxS6hXO5LnlJIIJ4ivbmUlbWj0llUA+uaVyvou3vJ4=' keyfile=/root/.nacl
      mypass

   The  following  optional configurations can be defined in the minion or
   master config. Avoid storing the config in pillars!

      cat /etc/salt/master.d/nacl.conf
      nacl.config:
          key: 'cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='
          keyfile: /root/.nacl

   When the key is defined in the master config you can use  it  from  the
   nacl runner:

      salt-run nacl.enc 'myotherpass'

   Now you can create a pillar with protected data like:

      pillarexample:
          user: root
          password: {{ salt.nacl.dec('DRB7Q6/X5gGSRCTpZyxS6hXO5LnlJIIJ4ivbmUlbWj0llUA+uaVyvou3vJ4=') }}

   Or do something interesting with grains like:

      salt-call nacl.enc minionname:dbrole
      AL24Z2C5OlkReer3DuQTFdrNLchLuz3NGIhGjZkLtKRYry/b/CksWM8O9yskLwH2AGVLoEXI5jAa

      salt minionname grains.setval role 'AL24Z2C5OlkReer3DuQTFdrNLchLuz3NGIhGjZkLtKRYry/b/CksWM8O9yskLwH2AGVLoEXI5jAa'

      {%- set r = grains.get('role') %}
      {%- set role = None %}
      {%- if r and 'nacl.dec' in salt %}
          {%- set r = salt['nacl.dec'](r,keyfile='/root/.nacl').split(':') %}
          {%- if opts['id'] == r[0] %}
              {%- set role = r[1] %}
          {%- endif %}
      {%- endif %}
      base:
          {%- if role %}
          '{{ opts['id'] }}':
              - {{ role }}
          {%- endif %}

   Multi-line  text  items  like certificates require a bit of extra work.
   You have to strip the new lines and replace them with '/n'  characters.
   Certificates specifically require some leading white space when calling
   nacl.enc so that the  '--'  in  the  first  line  (commonly  -----BEGIN
   CERTIFICATE-----)  doesn't  get interpreted as an argument to nacl.enc.
   For instance if you have a certificate file that lives in cert.crt:

      cert=$(cat cert.crt |awk '{printf "%s\n",$0} END {print ""}'); salt-run nacl.enc "  $cert"

   Pillar data should look the same, even though the secret will be  quite
   long.  However, when calling multiline encrypted secrets from pillar in
   a state, use the following format to  avoid  issues  with  /n  creating
   extra whitespace at the beginning of each line in the cert file:

      secret.txt:
          file.managed:
              - template: jinja
              - user: user
              - group: group
              - mode: 700
              - contents: "{{- salt['pillar.get']('secret') }}"

   The '{{-' will tell jinja to strip the whitespace from the beginning of
   each of the new lines.

   salt.modules.nacl.dec(data, **kwargs)
          Takes a key generated from nacl.keygen and decrypt some data.

          CLI Examples:

             salt-call --local nacl.dec pEXHQM6cuaF7A=
             salt-call --local nacl.dec data='pEXHQM6cuaF7A=' keyfile=/root/.nacl
             salt-call --local nacl.dec data='pEXHQM6cuaF7A=' key='cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='

   salt.modules.nacl.enc(data, **kwargs)
          Takes a key generated from nacl.keygen and encrypt some data.

          CLI Examples:

             salt-call --local nacl.enc datatoenc
             salt-call --local nacl.enc datatoenc keyfile=/root/.nacl
             salt-call --local nacl.enc datatoenc key='cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='

   salt.modules.nacl.keygen(keyfile=None)
          Use libnacl to generate a private key

          CLI Examples:

             salt-call --local nacl.keygen
             salt-call --local nacl.keygen keyfile=/root/.nacl
             salt-call --local --out=newline_values_only nacl.keygen > /root/.nacl

   salt.modules.nagios
   Run nagios plugins/checks from salt and get the return as data.

   salt.modules.nagios.list_plugins()
          List all the nagios plugins

          CLI Example:

             salt '*' nagios.list_plugins

   salt.modules.nagios.retcode(plugin, args='', key_name=None)
          Run one nagios plugin and return retcode of the execution

   salt.modules.nagios.retcode_pillar(pillar_name)
          Run one or more nagios plugins from  pillar  data  and  get  the
          result of cmd.retcode The pillar have to be in this format:

             ------
             webserver:
                 Ping_google:
                     - check_icmp: 8.8.8.8
                     - check_icmp: google.com
                 Load:
                     - check_load: -w 0.8 -c 1
                 APT:
                     - check_apt
             -------

          webserver  is the role to check, the next keys are the group and
          the items the check with the arguments if needed

          You must to group different checks(one o  more)  and  always  it
          will return the highest value of all the checks

          CLI Example:

             salt '*' nagios.retcode webserver

   salt.modules.nagios.run(plugin, args='')
          Run nagios plugin and return all the data execution with cmd.run

          CLI Example:

             salt '*' nagios.run check_apt
             salt '*' nagios.run check_icmp '8.8.8.8'

   salt.modules.nagios.run_all(plugin, args='')
          Run  nagios  plugin  and  return  all  the  data  execution with
          cmd.run_all

   salt.modules.nagios.run_all_pillar(pillar_name)
          Run one or more nagios plugins from  pillar  data  and  get  the
          result of cmd.run_all The pillar have to be in this format:

             ------
             webserver:
                 Ping_google:
                     - check_icmp: 8.8.8.8
                     - check_icmp: google.com
                 Load:
                     - check_load: -w 0.8 -c 1
                 APT:
                     - check_apt
             -------

          webserver  is the role to check, the next keys are the group and
          the items the check with the arguments if needed

          You have to group different checks in a group

          CLI Example:

             salt '*' nagios.run webserver

   salt.modules.nagios.run_pillar(pillar_name)
          Run one or more nagios plugins from  pillar  data  and  get  the
          result of cmd.run The pillar have to be in this format:

             ------
             webserver:
                 Ping_google:
                     - check_icmp: 8.8.8.8
                     - check_icmp: google.com
                 Load:
                     - check_load: -w 0.8 -c 1
                 APT:
                     - check_apt
             -------

          webserver  is the role to check, the next keys are the group and
          the items the check with the arguments if needed

          You have to group different checks in a group

          CLI Example:

             salt '*' nagios.run webserver

   salt.modules.nagios_rpc
   Check Host & Service status from Nagios via JSON RPC.

   New in version 2015.8.0.

   salt.modules.nagios_rpc.host_status(hostname=None, **kwargs)
          Check status of  a  particular  host  By  default  statuses  are
          returned in a numeric format.

          Parameters:

          hostname
                 The  hostname  to  check  the  status  of  the service in
                 Nagios.

          numeric
                 Turn to false in order to return status  in  text  format
                 ('OK' instead of 0, 'Warning' instead of 1 etc)

          Returns
                 status:     'OK', 'Warning', 'Critical' or 'Unknown'

          CLI Example:

             salt '*' nagios_rpc.host_status hostname=webserver.domain.com
             salt '*' nagios_rpc.host_status hostname=webserver.domain.com numeric=False

   salt.modules.nagios_rpc.service_status(hostname=None,     service=None,
   **kwargs)
          Check status of a particular service on a host on it in  Nagios.
          By default statuses are returned in a numeric format.

          Parameters:

          hostname
                 The  hostname  to  check  the  status  of  the service in
                 Nagios.

          service
                 The service to check the status of in Nagios.

          numeric
                 Turn to false in order to return status  in  text  format
                 ('OK' instead of 0, 'Warning' instead of 1 etc)

          Returns
                 status:     'OK', 'Warning', 'Critical' or 'Unknown'

          CLI Example:

             salt '*' nagios_rpc.service_status hostname=webserver.domain.com service='HTTP'
             salt '*' nagios_rpc.service_status hostname=webserver.domain.com service='HTTP' numeric=False

   salt.modules.napalm_bgp module
   NAPALM BGP
   Manages BGP configuration on network devices and provides statistics.

   codeauthor
          Mircea   Ulinic   <[email protected]>  &  Jerome  Fleury  <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * napalm proxy minion

   New in version 2016.11.0.

   salt.modules.napalm_bgp.config(group=None, neighbor=None)
          Provides the BGP configuration on the device.

          Parameters

                 * group -- Name of the  group  selected  to  display  the
                   configuration.

                 * neighbor  --  IP Address of the neighbor to display the
                   configuration.

          If the group parameter is not specified,  the  neighbor  setting
          will  be  ignored.   :return:  A  dictionary  containing the BGP
          configuration from the network device.  The  keys  of  the  main
          dictionary are the group names.

          Each group has the following properties:

             * type (string)

             * description (string)

             * apply_groups (string list)

             * multihop_ttl (int)

             * multipath (True/False)

             * local_address (string)

             * local_as (int)

             * remote_as (int)

             * import_policy (string)

             * export_policy (string)

             * remove_private_as (True/False)

             * prefix_limit (dictionary)

             * neighbors (dictionary)

          Each neighbor in the dictionary of neighbors provides:

             * description (string)

             * import_policy (string)

             * export_policy (string)

             * local_address (string)

             * local_as (int)

             * remote_as (int)

             * authentication_key (string)

             * prefix_limit (dictionary)

             * route_reflector_client (True/False)

             * nhs (True/False)

          CLI Example:

             salt '*' bgp.config # entire BGP config
             salt '*' bgp.config PEERS-GROUP-NAME # provides detail only about BGP group PEERS-GROUP-NAME
             salt '*' bgp.config PEERS-GROUP-NAME 172.17.17.1 # provides details only about BGP neighbor 172.17.17.1,
             # configured in the group PEERS-GROUP-NAME

          Output Example:

             {
                 'PEERS-GROUP-NAME':{
                     'type'          : u'external',
                     'description'   : u'Here we should have a nice description',
                     'apply_groups'  : [u'BGP-PREFIX-LIMIT'],
                     'import_policy' : u'PUBLIC-PEER-IN',
                     'export_policy' : u'PUBLIC-PEER-OUT',
                     'remove_private': True,
                     'multipath'     : True,
                     'multihop_ttl'  : 30,
                     'neighbors'     : {
                         '192.168.0.1': {
                             'description'   : 'Facebook [CDN]',
                             'prefix_limit'  : {
                                 'inet': {
                                     'unicast': {
                                         'limit': 100,
                                         'teardown': {
                                             'threshold' : 95,
                                             'timeout'   : 5
                                         }
                                     }
                                 }
                             }
                             'peer-as'        : 32934,
                             'route_reflector': False,
                             'nhs'            : True
                         },
                         '172.17.17.1': {
                             'description'   : 'Twitter [CDN]',
                             'prefix_limit'  : {
                                 'inet': {
                                     'unicast': {
                                         'limit': 500,
                                         'no-validate': 'IMPORT-FLOW-ROUTES'
                                     }
                                 }
                             }
                             'peer_as'        : 13414
                             'route_reflector': False,
                             'nhs'            : False
                         }
                     }
                 }
             }

   salt.modules.napalm_bgp.neighbors(neighbor=None)
          Provides  details  regarding  the BGP sessions configured on the
          network device.

          Parameters
                 neighbor -- IP Address of a specific neighbor.

          Returns
                 A dictionary with the statistics of the all/selected  BGP
                 neighbors.

          Outer  dictionary  keys  represent  the VRF name.  Keys of inner
          dictionary represent the AS numbers, while the values are  lists
          of dictionaries, having the following keys:

             * up (True/False)

             * local_as (int)

             * remote_as (int)

             * local_address (string)

             * routing_table (string)

             * local_address_configured (True/False)

             * local_port (int)

             * remote_address (string)

             * remote_port (int)

             * multihop (True/False)

             * multipath (True/False)

             * remove_private_as (True/False)

             * import_policy (string)

             * export_policy (string)

             * input_messages (int)

             * output_messages (int)

             * input_updates (int)

             * output_updates (int)

             * messages_queued_out (int)

             * connection_state (string)

             * previous_connection_state (string)

             * last_event (string)

             * suppress_4byte_as (True/False)

             * local_as_prepend (True/False)

             * holdtime (int)

             * configured_holdtime (int)

             * keepalive (int)

             * configured_keepalive (int)

             * active_prefix_count (int)

             * received_prefix_count (int)

             * accepted_prefix_count (int)

             * suppressed_prefix_count (int)

             * advertised_prefix_count (int)

             * flap_count (int)

          CLI Example:

             salt '*' bgp.neighbors  # all neighbors
             salt '*' bgp.neighbors 172.17.17.1  # only session with BGP neighbor(s) 172.17.17.1

          Output Example:

             {
                 'default': {
                     8121: [
                         {
                             'up'                        : True,
                             'local_as'                  : 13335,
                             'remote_as'                 : 8121,
                             'local_address'             : u'172.101.76.1',
                             'local_address_configured'  : True,
                             'local_port'                : 179,
                             'remote_address'            : u'192.247.78.0',
                             'router_id':                : u'192.168.0.1',
                             'remote_port'               : 58380,
                             'multihop'                  : False,
                             'import_policy'             : u'4-NTT-TRANSIT-IN',
                             'export_policy'             : u'4-NTT-TRANSIT-OUT',
                             'input_messages'            : 123,
                             'output_messages'           : 13,
                             'input_updates'             : 123,
                             'output_updates'            : 5,
                             'messages_queued_out'       : 23,
                             'connection_state'          : u'Established',
                             'previous_connection_state' : u'EstabSync',
                             'last_event'                : u'RecvKeepAlive',
                             'suppress_4byte_as'         : False,
                             'local_as_prepend'          : False,
                             'holdtime'                  : 90,
                             'configured_holdtime'       : 90,
                             'keepalive'                 : 30,
                             'configured_keepalive'      : 30,
                             'active_prefix_count'       : 132808,
                             'received_prefix_count'     : 566739,
                             'accepted_prefix_count'     : 566479,
                             'suppressed_prefix_count'   : 0,
                             'advertise_prefix_count'    : 0,
                             'flap_count'                : 27
                         }
                     ]
                 }
             }

   salt.modules.napalm_network module
   NAPALM Network
   Basic  methods  for  interaction  with  the  network device through the
   virtual proxy 'napalm'.

   codeauthor
          Mircea  Ulinic  <[email protected]>  &  Jerome   Fleury   <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * napalm proxy minion

   New in version 2016.11.0.

   salt.modules.napalm_network.arp(interface='', ipaddr='', macaddr='')
          NAPALM  returns  a  list of dictionaries with details of the ARP
          entries.

          Parameters

                 * interface -- interface name to filter on

                 * ipaddr -- IP address to filter on

                 * macaddr -- MAC address to filter on

          Returns
                 List of the entries in the ARP table

          CLI Example:

             salt '*' net.arp
             salt '*' net.arp macaddr='5c:5e:ab:da:3c:f0'

          Example output:

             [
                 {
                     'interface' : 'MgmtEth0/RSP0/CPU0/0',
                     'mac'       : '5c:5e:ab:da:3c:f0',
                     'ip'        : '172.17.17.1',
                     'age'       : 1454496274.84
                 },
                 {
                     'interface': 'MgmtEth0/RSP0/CPU0/0',
                     'mac'       : '66:0e:94:96:e0:ff',
                     'ip'        : '172.17.17.2',
                     'age'       : 1435641582.49
                 }
             ]

   salt.modules.napalm_network.cli(*commands)
          Returns a dictionary with the raw output of all commands  passed
          as arguments.

          Parameters
                 commands -- list of commands to be executed on the device

          Returns
                 a  dictionary  with  the mapping between each command and
                 its raw output

          CLI Example:

             salt '*' net.cli "show version" "show chassis fan"

          Example output:

             {
                 u'show version and haiku':  u'Hostname: re0.edge01.arn01
                                               Model: mx480
                                               Junos: 13.3R6.5
                                                 Help me, Obi-Wan
                                                 I just saw Episode Two
                                                 You're my only hope
                                              ',
                 u'show chassis fan' :   u'Item                      Status   RPM     Measurement
                                           Top Rear Fan              OK       3840    Spinning at intermediate-speed
                                           Bottom Rear Fan           OK       3840    Spinning at intermediate-speed
                                           Top Middle Fan            OK       3900    Spinning at intermediate-speed
                                           Bottom Middle Fan         OK       3840    Spinning at intermediate-speed
                                           Top Front Fan             OK       3810    Spinning at intermediate-speed
                                           Bottom Front Fan          OK       3840    Spinning at intermediate-speed
                                          '
             }

   salt.modules.napalm_network.commit()
          Commits the configuration changes made on the network device.

          CLI Example:

             salt '*' net.commit

   salt.modules.napalm_network.compare_config()
          Returns the  difference  between  the  running  config  and  the
          candidate config.

          CLI Example:

             salt '*' net.compare_config

   salt.modules.napalm_network.config_changed()
          Will prompt if the configuration has been changed.

          Returns
                 A  tuple  with a boolean that specifies if the config was
                 changed on the device.    And a string that provides more
                 details  of  the  reason  why  the  configuration was not
                 changed.

          CLI Example:

             salt '*' net.config_changed

   salt.modules.napalm_network.config_control()
          Will check if the configuration  was  changed.   If  differences
          found,  will  try  to commit.  In case commit unsuccessful, will
          try to rollback.

          Returns
                 A tuple with a boolean that specifies if the  config  was
                 changed/commited/rollbacked   on  the  device.     And  a
                 string that provides more details of the reason  why  the
                 configuration was not commited properly.

          CLI Example:

             salt '*' net.config_control

   salt.modules.napalm_network.connected()
          Specifies  if  the  proxy  succeeded  to  connect to the network
          device.

          CLI Example:

             salt '*' net.connected

   salt.modules.napalm_network.discard_config()
          Discards the changes applied.

          CLI Example:

             salt '*' net.discard_config

   salt.modules.napalm_network.environment()
          Returns the environment of the device.

          CLI Example:

             salt '*' net.environment

          Example output:

             {
                 'fans': {
                     'Bottom Rear Fan': {
                         'status': True
                     },
                     'Bottom Middle Fan': {
                         'status': True
                     },
                     'Top Middle Fan': {
                         'status': True
                     },
                     'Bottom Front Fan': {
                         'status': True
                     },
                     'Top Front Fan': {
                         'status': True
                     },
                     'Top Rear Fan': {
                         'status': True
                     }
                 },
                 'memory': {
                     'available_ram': 16349,
                     'used_ram': 4934
                 },
                 'temperature': {
                    'FPC 0 Exhaust A': {
                         'is_alert': False,
                         'temperature': 35.0,
                         'is_critical': False
                     }
                 },
                 'cpu': {
                     '1': {
                         '%usage': 19.0
                     },
                     '0': {
                         '%usage': 35.0
                     }
                 }
             }

   salt.modules.napalm_network.facts()
          Returns characteristics  of  the  network  device.   :return:  a
          dictionary with the following keys:

             * uptime - Uptime of the device in seconds.

             * vendor - Manufacturer of the device.

             * model - Device model.

             * hostname - Hostname of the device

             * fqdn - Fqdn of the device

             * os_version  -  String  with  the  OS version running on the
               device.

             * serial_number - Serial number of the device

             * interface_list - List of the interfaces of the device

          CLI Example:

             salt '*' net.facts

          Example output:

             {
                 'os_version': u'13.3R6.5',
                 'uptime': 10117140,
                 'interface_list': [
                     'lc-0/0/0',
                     'pfe-0/0/0',
                     'pfh-0/0/0',
                     'xe-0/0/0',
                     'xe-0/0/1',
                     'xe-0/0/2',
                     'xe-0/0/3',
                     'gr-0/0/10',
                     'ip-0/0/10'
                 ],
                 'vendor': u'Juniper',
                 'serial_number': u'JN131356FBFA',
                 'model': u'MX480',
                 'hostname': u're0.edge05.syd01',
                 'fqdn': u're0.edge05.syd01'
             }

   salt.modules.napalm_network.interfaces()
          Returns details of the interfaces on the device.

          Returns
                 Returns a dictionary of dictionaries.      The  keys  for
                 the  first  dictionary  will  be  the  interfaces  in the
                 devices.

          CLI Example:

             salt '*' net.interfaces

          Example output:

             {
                 u'Management1': {
                     'is_up': False,
                     'is_enabled': False,
                     'description': u'',
                     'last_flapped': -1,
                     'speed': 1000,
                     'mac_address': u'dead:beef:dead',
                 },
                 u'Ethernet1':{
                     'is_up': True,
                     'is_enabled': True,
                     'description': u'foo',
                     'last_flapped': 1429978575.1554043,
                     'speed': 1000,
                     'mac_address': u'beef:dead:beef',
                 }
             }

   salt.modules.napalm_network.ipaddrs()
          Returns IP addresses configured on the device.

          Returns
                 A dictionary with the IPv4  and  IPv6  addresses  of  the
                 interfaces.    Returns all configured IP addresses on all
                 interfaces as a dictionary of  dictionaries.     Keys  of
                 the  main dictionary represent the name of the interface.
                 Values of the main dictionary represent are  dictionaries
                 that  may  consist of two keys    'ipv4' and 'ipv6' (one,
                 both or none) which are themselvs dictionaries witht  the
                 IP addresses as keys.

          CLI Example:

             salt '*' net.ipaddrs

          Example output:

             {
                 u'FastEthernet8': {
                     u'ipv4': {
                         u'10.66.43.169': {
                             'prefix_length': 22
                         }
                     }
                 },
                 u'Loopback555': {
                     u'ipv4': {
                         u'192.168.1.1': {
                             'prefix_length': 24
                         }
                     },
                     u'ipv6': {
                         u'1::1': {
                             'prefix_length': 64
                         },
                         u'2001:DB8:1::1': {
                             'prefix_length': 64
                         },
                         u'FE80::3': {
                             'prefix_length': u'N/A'
                         }
                     }
                 }
             }

   salt.modules.napalm_network.lldp(interface='')
          Returns a detailed view of the LLDP neighbors.

          Parameters
                 interface -- interface name to filter on

          Returns
                 A dictionary with the LLDL neighbors.    The keys are the
                 interfaces with LLDP activated on.

          CLI Example:

             salt '*' net.lldp
             salt '*' net.lldp interface='TenGigE0/0/0/8'

          Example output:

             {
                 'TenGigE0/0/0/8': [
                     {
                         'parent_interface': u'Bundle-Ether8',
                         'interface_description': u'TenGigE0/0/0/8',
                         'remote_chassis_id': u'8c60.4f69.e96c',
                         'remote_system_name': u'switch',
                         'remote_port': u'Eth2/2/1',
                         'remote_port_description': u'Ethernet2/2/1',
                         'remote_system_description': u'Cisco Nexus Operating System (NX-OS) Software 7.1(0)N1(1a)
                               TAC support: http://www.cisco.com/tac
                               Copyright (c) 2002-2015, Cisco Systems, Inc. All rights reserved.',
                         'remote_system_capab': u'B, R',
                         'remote_system_enable_capab': u'B'
                     }
                 ]
             }

   salt.modules.napalm_network.load_config(filename=None,       text=None,
   test=False, commit=True, replace=False)
          Populates  the  candidate configuration. It can be loaded from a
          file or from a string. If you send both a filename and a  string
          containing the configuration, the file takes precedence.

          If you use this method the existing configuration will be merged
          with the candidate configuration once you commit the changes.

          Be  aware  that  by  default  this  method   will   commit   the
          configuration.  If  there are no changes, it does not commit and
          the flag already_configured will be set as True  to  point  this
          out.

          Parameters

                 * filename  --  Path  to  the file containing the desired
                   configuration. By default is None.

                 * text -- String containing the desired configuration.

                 * test -- Dry run? If set as True, will apply the config,
                   discard  and  return the changes. Default: False    and
                   will commit the changes on the device.

                 * commit -- Commit? (default: True) Sometimes it  is  not
                   needed     to    commit    the    config    immediately
                   after loading the changes. E.g.: a state loads a couple
                   of parts (add / remove / update)                    and
                   would not be optimal to commit  after  each  operation.
                   Also,  from  the  CLI  when the user needs to apply the
                   similar        changes        before        committing,
                   can  specify  commit=False  and  will  not  discard the
                   config.

                 * replace -- Load and replace the configuration. Default:
                   False.

          Returns
                 a dictionary having the following keys:

          * result  (bool):  if the config was applied successfully. It is
            False only in case of failure. In case

          there are no changes to be applied and successfully performs all
          operations   it   is   still   True   and   so   will   be   the
          already_configured flag  (example  below)  *  comment  (str):  a
          message  for the user * already_configured (bool): flag to check
          if there were no changes  applied  *  diff  (str):  returns  the
          config changes applied

          CLI Example:

             salt '*' net.load_config text='ntp peer 192.168.0.1'
             salt '*' net.load_config filename='/absolute/path/to/your/file'
             salt '*' net.load_config filename='/absolute/path/to/your/file' test=True
             salt '*' net.load_config filename='/absolute/path/to/your/file' commit=False

          Example output:

             {
                 'comment': 'Configuration discarded.',
                 'already_configured': False,
                 'result': True,
                 'diff': '[edit interfaces xe-0/0/5]+   description "Adding a description";'
             }

   salt.modules.napalm_network.load_template(template_name,
   template_source=None,  template_path=None,   test=False,   commit=True,
   replace=False, **template_vars)
          Renders a configuration template (Jinja) and loads the result on
          the device.

          By default will commit the changes. To  force  a  dry  run,  set
          test=True.

          Parameters

                 * template_name -- Identifies the template name.

                 * (optional) (template_path) -- Inline config template to
                   be rendered and loaded on the device.

                 * (optional)  --  Specifies  the  absolute  path   to   a
                   different     directory     for    the    configuration
                   templates. If not specified, by default  will  use  the
                   default templates defined in NAPALM.

                 * test -- Dry run? If set to True, will apply the config,
                   discard and return the changes. Default:  False     and
                   will commit the changes on the device.

                 * commit  --  Commit? (default: True) Sometimes it is not
                   needed    to    commit    the    config     immediately
                   after loading the changes. E.g.: a state loads a couple
                   of parts (add / remove / update)                    and
                   would  not  be  optimal to commit after each operation.
                   Also, from the CLI when the user  needs  to  apply  the
                   similar        changes        before        committing,
                   can specify  commit=False  and  will  not  discard  the
                   config.

                 * replace -- Load and replace the configuration.

                 * template_vars  --  Dictionary  with the arguments to be
                   used when the template is rendered.

          Returns
                 a dictionary having the following keys:

          * result (bool): if the config was applied successfully.  It  is
            False  only  in  case  of  failure.  In  case     there are no
            changes to be applied and successfully performs all operations
            it  is  still  True  and so will be     the already_configured
            flag (example below)

          * comment (str): a message for the user

          * already_configured (bool): flag to  check  if  there  were  no
            changes applied

          * diff (str): returns the config changes applied

          The  template can use variables from the grains, pillar or opts,
          for example:

             {% set router_model = grains.get('model') -%}
             {% set router_vendor = grains.get('vendor') -%}
             {% set hostname = pillar.get('proxy', {}).get('host') -%}
             {% if router_vendor|lower == 'juniper' %}
             system {
                 host-name {{hostname}};
             }
             {% endif %}

          CLI Example:

             salt '*' net.load_template ntp_peers peers=[192.168.0.1]  # uses NAPALM default templates
             salt '*' net.load_template set_hostname template_source='system { domain-name {{domain_name}}; }'
             domain_name='test.com'
             salt '*' net.load_template my_template template_path='/tmp/tpl/' my_param='aaa'  # will commit
             salt '*' net.load_template my_template template_path='/tmp/tpl/' my_param='aaa' test=True  # dry run

          Example output:

             {
                 'comment': '',
                 'already_configured': False,
                 'result': True,
                 'diff': '[edit system]+  host-name edge01.bjm01'
             }

   salt.modules.napalm_network.mac(address='', interface='', vlan=0)
          Returns the MAC Address Table on the device.

          Parameters

                 * address -- MAC address to filter on

                 * interface -- Interface name to filter on

                 * vlan -- VLAN identifier

          Returns
                 A list of dictionaries representing the  entries  in  the
                 MAC Address Table

          CLI Example:

             salt '*' net.mac
             salt '*' net.mac vlan=10

          Example output:

             [
                 {
                     'mac'       : '00:1c:58:29:4a:71',
                     'interface' : 'xe-3/0/2',
                     'static'    : False,
                     'active'    : True,
                     'moves'     : 1,
                     'vlan'      : 10,
                     'last_move' : 1454417742.58
                 },
                 {
                     'mac'       : '8c:60:4f:58:e1:c1',
                     'interface' : 'xe-1/0/1',
                     'static'    : False,
                     'active'    : True,
                     'moves'     : 2,
                     'vlan'      : 42,
                     'last_move' : 1453191948.11
                 }
             ]

   salt.modules.napalm_network.ping(destination,     source='',     ttl=0,
   timeout=0, size=0, count=0)
          Executes a ping on the network device and returns  a  dictionary
          as a result.

          Parameters

                 * destination -- Hostname or IP address of remote host

                 * source -- Source address of echo request

                 * ttl  --  IP  time-to-live  value (IPv6 hop-limit value)
                   (1..255 hops)

                 * timeout -- Maximum wait time after sending final packet
                   (seconds)

                 * size -- Size of request packets (0..65468 bytes)

                 * count -- Number of ping requests to send (1..2000000000
                   packets)

          CLI Example:

             salt '*' net.ping 8.8.8.8
             salt '*' net.ping 8.8.8.8 ttl=3 size=65468
             salt '*' net.ping 8.8.8.8 source=127.0.0.1 timeout=1 count=100

   salt.modules.napalm_network.rollback()
          Rollbacks the configuration.

          CLI Example:

             salt '*' net.rollback

   salt.modules.napalm_network.traceroute(destination,  source='',  ttl=0,
   timeout=0)
          Calls  the  method  traceroute from the NAPALM driver object and
          returns a dictionary with the result of the  traceroute  command
          executed on the device.

          Parameters

                 * destination -- Hostname or address of remote host

                 * source  -- Source address to use in outgoing traceroute
                   packets

                 * ttl -- IP maximum time-to-live value (or  IPv6  maximum
                   hop-limit value)

                 * timeout  --  Number  of  seconds  to  wait for response
                   (seconds)

          CLI Example:

             salt '*' net.traceroute 8.8.8.8
             salt '*' net.traceroute 8.8.8.8 source=127.0.0.1 ttl=5 timeout=1

   salt.modules.napalm_ntp module
   NAPALM NTP
   Manages NTP on network devices.

   codeauthor
          Mircea  Ulinic  <[email protected]>  &  Jerome   Fleury   <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * NAPALM proxy minion

   * NET basic features

   SEE ALSO:
      NTP peers management state

   New in version 2016.11.0.

   salt.modules.napalm_ntp.delete_peers(*peers, **options)
          Removes NTP peers configured on the device.

          Parameters

                 * peers  --  list  of  IP  Addresses/Domain  Names  to be
                   removed as NTP peers

                 * (bool) (test) -- discard loaded config. By default test
                   is False (will not dicard the changes)

          Commit commit (bool)
                 commit  loaded  config.  By  default commit is True (will
                 commit the changes). Useful when

          the user does not want to commit after each change, but after  a
          couple.

          By  default  this  function  will  commit the config changes (if
          any). To load without commiting, use the commit option. For  dry
          run use the test argument.

          CLI Example:

             salt '*' ntp.delete_peers 8.8.8.8 time.apple.com
             salt '*' ntp.delete_peers 172.17.17.1 test=True  # only displays the diff
             salt '*' ntp.delete_peers 192.168.0.1 commit=False  # preserves the changes, but does not commit

   salt.modules.napalm_ntp.delete_servers(*servers, **options)
          Removes NTP servers configured on the device.

          Parameters

                 * servers  --  list  of  IP  Addresses/Domain Names to be
                   removed as NTP servers

                 * (bool) (test) -- discard loaded config. By default test
                   is False (will not dicard the changes)

          Commit commit (bool)
                 commit  loaded  config.  By  default commit is True (will
                 commit the changes). Useful when

          the user does not want to commit after each change, but after  a
          couple.

          By  default  this  function  will  commit the config changes (if
          any). To load without commiting, use the commit option. For  dry
          run use the test argument.

          CLI Example:

             salt '*' ntp.delete_servers 8.8.8.8 time.apple.com
             salt '*' ntp.delete_servers 172.17.17.1 test=True  # only displays the diff
             salt '*' ntp.delete_servers 192.168.0.1 commit=False  # preserves the changes, but does not commit

   salt.modules.napalm_ntp.peers()
          Returns a list the NTP peers configured on the network device.

          Returns
                 configured NTP peers as list.

          CLI Example:

             salt '*' ntp.peers

          Example output:

             [
                 '192.168.0.1',
                 '172.17.17.1',
                 '172.17.17.2',
                 '2400:cb00:6:1024::c71b:840a'
             ]

   salt.modules.napalm_ntp.servers()
          Returns a list of the configured NTP servers on the device.

          CLI Example:

             salt '*' ntp.servers

   salt.modules.napalm_ntp.set_peers(*peers, **options)
          Configures a list of NTP peers on the device.

          Parameters

                 * peers -- list of IP Addresses/Domain Names

                 * (bool) (test) -- discard loaded config. By default test
                   is False (will not dicard the changes)

          Commit commit (bool)
                 commit loaded config. By default  commit  is  True  (will
                 commit the changes). Useful when

          the  user does not want to commit after each change, but after a
          couple.

          By default this function will  commit  the  config  changes  (if
          any).  To load without commiting, use the commit option. For dry
          run use the test argument.

          CLI Example:

             salt '*' ntp.set_peers 192.168.0.1 172.17.17.1 time.apple.com
             salt '*' ntp.set_peers 172.17.17.1 test=True  # only displays the diff
             salt '*' ntp.set_peers 192.168.0.1 commit=False  # preserves the changes, but does not commit

   salt.modules.napalm_ntp.set_servers(*servers, **options)
          Configures a list of NTP servers on the device.

          Parameters

                 * servers -- list of IP Addresses/Domain Names

                 * (bool) (test) -- discard loaded config. By default test
                   is False (will not dicard the changes)

          Commit commit (bool)
                 commit  loaded  config.  By  default commit is True (will
                 commit the changes). Useful when

          the user does not want to commit after each change, but after  a
          couple.

          By  default  this  function  will  commit the config changes (if
          any). To load without commiting, use the commit option. For  dry
          run use the test argument.

          CLI Example:

             salt '*' ntp.set_servers 192.168.0.1 172.17.17.1 time.apple.com
             salt '*' ntp.set_servers 172.17.17.1 test=True  # only displays the diff
             salt '*' ntp.set_servers 192.168.0.1 commit=False  # preserves the changes, but does not commit

   salt.modules.napalm_ntp.stats(peer=None)
          Returns  a  dictionary containing synchronization details of the
          NTP peers.

          Parameters
                 peer -- Returns only the details of a specific NTP peer.

          Returns
                 a list of dictionaries, with the following keys:

                 * remote

                 * referenceid

                 * synchronized

                 * stratum

                 * type

                 * when

                 * hostpoll

                 * reachability

                 * delay

                 * offset

                 * jitter

          CLI Example:

             salt '*' ntp.stats

          Example output:

             [
                 {
                     'remote'        : u'188.114.101.4',
                     'referenceid'   : u'188.114.100.1',
                     'synchronized'  : True,
                     'stratum'       : 4,
                     'type'          : u'-',
                     'when'          : u'107',
                     'hostpoll'      : 256,
                     'reachability'  : 377,
                     'delay'         : 164.228,
                     'offset'        : -13.866,
                     'jitter'        : 2.695
                 }
             ]

   salt.modules.napalm_probes module
   NAPALM Probes
   Manages RPM/SLA probes on the network device.

   codeauthor
          Mircea  Ulinic  <[email protected]>  &  Jerome   Fleury   <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * napalm proxy minion

   * NET basic features

   SEE ALSO:
      Probes configuration management state

   New in version 2016.11.0.

   salt.modules.napalm_probes.config()
          Returns the configuration of the RPM probes.

          Returns
                 A  dictionary containing the configuration of the RPM/SLA
                 probes.

          CLI Example:

             salt '*' probes.config

          Output Example:

             {
                 'probe1':{
                     'test1': {
                         'probe_type'   : 'icmp-ping',
                         'target'       : '192.168.0.1',
                         'source'       : '192.168.0.2',
                         'probe_count'  : 13,
                         'test_interval': 3
                     },
                     'test2': {
                         'probe_type'   : 'http-ping',
                         'target'       : '172.17.17.1',
                         'source'       : '192.17.17.2',
                         'probe_count'  : 5,
                         'test_interval': 60
                     }
                 }
             }

   salt.modules.napalm_probes.delete_probes(probes,            test=False,
   commit=True)
          Removes  RPM/SLA  probes  from  the  network  device.  Calls the
          configuration template 'delete_probes' from the NAPALM  library,
          providing   as  input  a  rich  formatted  dictionary  with  the
          configuration details of the  probes  to  be  removed  from  the
          configuration of the device.

          Parameters
                 probes  -- Dictionary with a similar format as the output
                 dictionary of the function config(),

          where the details are not necessary.  :param test: Dry  run?  If
          set  as  True,  will  apply  the  config, discard and return the
          changes. Default: False and  will  commit  the  changes  on  the
          device.   :param commit: Commit? (default: True) Sometimes it is
          not needed to commit the config immediately
             after loading the changes. E.g.: a state loads  a  couple  of
             parts  (add  /  remove  / update) and would not be optimal to
             commit after each operation.  Also, from  the  CLI  when  the
             user  needs  to  apply the similar changes before committing,
             can specify commit=False and will not discard the config.

          Raises MergeConfigException -- If  there  is  an  error  on  the
                 configuration sent.

          Return a dictionary having the following keys

                 * result  (bool): if the config was applied successfully.
                   It is False only in case of failure. In case

                 there are no  changes  to  be  applied  and  successfully
                 performs  all  operations it is still True and so will be
                 the already_configured flag  (example  below)  *  comment
                 (str):  a  message  for  the  user  *  already_configured
                 (bool): flag to check if there were no changes applied  *
                 diff (str): returns the config changes applied

          Input example:

             probes = {
                 'existing_probe':{
                     'existing_test1': {},
                     'existing_test2': {}
                 }
             }

   salt.modules.napalm_probes.results()
          Provides the results of the measurements of the RPM/SLA probes.

          :return a dictionary with the results of the probes.

          CLI Example:

             salt '*' probes.results

          Output example:

             {
                 'probe1':  {
                     'test1': {
                         'last_test_min_delay'   : 63.120,
                         'global_test_min_delay' : 62.912,
                         'current_test_avg_delay': 63.190,
                         'global_test_max_delay' : 177.349,
                         'current_test_max_delay': 63.302,
                         'global_test_avg_delay' : 63.802,
                         'last_test_avg_delay'   : 63.438,
                         'last_test_max_delay'   : 65.356,
                         'probe_type'            : 'icmp-ping',
                         'rtt'                   : 63.138,
                         'last_test_loss'        : 0,
                         'round_trip_jitter'     : -59.0,
                         'target'                : '192.168.0.1',
                         'source'                : '192.168.0.2'
                         'probe_count'           : 15,
                         'current_test_min_delay': 63.138
                     },
                     'test2': {
                         'last_test_min_delay'   : 176.384,
                         'global_test_min_delay' : 169.226,
                         'current_test_avg_delay': 177.098,
                         'global_test_max_delay' : 292.628,
                         'current_test_max_delay': 180.055,
                         'global_test_avg_delay' : 177.959,
                         'last_test_avg_delay'   : 177.178,
                         'last_test_max_delay'   : 184.671,
                         'probe_type'            : 'icmp-ping',
                         'rtt'                   : 176.449,
                         'last_test_loss'        : 0,
                         'round_trip_jitter'     : -34.0,
                         'target'                : '172.17.17.1',
                         'source'                : '172.17.17.2'
                         'probe_count'           : 15,
                         'current_test_min_delay': 176.402
                     }
                 }
             }

   salt.modules.napalm_probes.schedule_probes(probes,          test=False,
   commit=True)
          Will schedule the probes. On Cisco devices, it is not enough  to
          define  the probes, it is also necessary to schedule them.  This
          method calls the configuration template  'schedule_probes'  from
          the   NAPALM  library,  providing  as  input  a  rich  formatted
          dictionary with the names of the probes  and  the  tests  to  be
          scheduled.

          Parameters
                 probes  -- Dictionary with a similar format as the output
                 dictionary of the function config(),

          where the details are not necessary.  :param test: Dry  run?  If
          set  as  True,  will  apply  the  config, discard and return the
          changes. Default: False and  will  commit  the  changes  on  the
          device.   :param commit: Commit? (default: True) Sometimes it is
          not needed to commit the config immediately
             after loading the changes. E.g.: a state loads  a  couple  of
             parts  (add  /  remove  / update) and would not be optimal to
             commit after each operation.  Also, from  the  CLI  when  the
             user  needs  to  apply the similar changes before committing,
             can specify commit=False and will not discard the config.

          Raises MergeConfigException -- If  there  is  an  error  on  the
                 configuration sent.

          Return a dictionary having the following keys

                 * result  (bool): if the config was applied successfully.
                   It is False only in case of failure. In case

                 there are no  changes  to  be  applied  and  successfully
                 performs  all  operations it is still True and so will be
                 the already_configured flag  (example  below)  *  comment
                 (str):  a  message  for  the  user  *  already_configured
                 (bool): flag to check if there were no changes applied  *
                 diff (str): returns the config changes applied

          Input example:

             probes = {
                 'new_probe':{
                     'new_test1': {},
                     'new_test2': {}
                 }
             }

   salt.modules.napalm_probes.set_probes(probes, test=False, commit=True)
          Configures   RPM/SLA   probes   on   the   device.    Calls  the
          configuration template 'set_probes'  from  the  NAPALM  library,
          providing   as  input  a  rich  formatted  dictionary  with  the
          configuration details of the probes to be configured.

          Parameters

                 * probes -- Dictionary formatted as  the  output  of  the
                   function config()

                 * test -- Dry run? If set as True, will apply the config,
                   discard and return the changes. Default: False

          and will commit the  changes  on  the  device.   :param  commit:
          Commit? (default: True) Sometimes it is not needed to commit the
          config immediately
             after loading the changes. E.g.: a state loads  a  couple  of
             parts  (add  /  remove  / update) and would not be optimal to
             commit after each operation.  Also, from  the  CLI  when  the
             user  needs  to  apply the similar changes before committing,
             can specify commit=False and will not discard the config.

          Raises MergeConfigException -- If  there  is  an  error  on  the
                 configuration sent.

          Return a dictionary having the following keys

                 * result  (bool): if the config was applied successfully.
                   It is False only in case of failure. In case

                 there are no  changes  to  be  applied  and  successfully
                 performs  all  operations it is still True and so will be
                 the already_configured flag  (example  below)  *  comment
                 (str):  a  message  for  the  user  *  already_configured
                 (bool): flag to check if there were no changes applied  *
                 diff (str): returns the config changes applied

          Input example - via state/script:

             probes = {
                 'new_probe':{
                     'new_test1': {
                         'probe_type'   : 'icmp-ping',
                         'target'       : '192.168.0.1',
                         'source'       : '192.168.0.2',
                         'probe_count'  : 13,
                         'test_interval': 3
                     },
                     'new_test2': {
                         'probe_type'   : 'http-ping',
                         'target'       : '172.17.17.1',
                         'source'       : '192.17.17.2',
                         'probe_count'  : 5,
                         'test_interval': 60
                     }
                 }
             }
             set_probes(probes)

          CLI Example - to push cahnges on the fly (not recommended):

             salt 'junos_minion' probes.set_probes "{'new_probe':{'new_test1':{'probe_type':'icmp-ping',            'target':'192.168.0.1','source':'192.168.0.2','probe_count':13,'test_interval':3}}}" test=True

          Output example - for the CLI example above:

             junos_minion:
                 ----------
                 already_configured:
                     False
                 comment:
                     Configuration discarded.
                 diff:
                     [edit services rpm]
                          probe transit { ... }
                     +    probe new_probe {
                     +        test new_test1 {
                     +            probe-type icmp-ping;
                     +            target address 192.168.0.1;
                     +            probe-count 13;
                     +            test-interval 3;
                     +            source-address 192.168.0.2;
                     +        }
                     +    }
                 result:
                     True

   salt.modules.netaddress
   Module for getting information about network addresses.

   New in version 2016.3.0.

   depends
          netaddr

   salt.modules.netaddress.cidr_broadcast(cidr)
          Get the broadcast address associated with a CIDR address.

          CLI example:

             salt myminion netaddress.cidr_netmask 192.168.0.0/20

   salt.modules.netaddress.cidr_netmask(cidr)
          Get the netmask address associated with a CIDR address.

          CLI example:

             salt myminion netaddress.cidr_netmask 192.168.0.0/20

   salt.modules.netaddress.list_cidr_ips(cidr)
          Get a list of IP addresses from a CIDR.

          CLI example:

             salt myminion netaddress.list_cidr_ips 192.168.0.0/20

   salt.modules.netaddress.list_cidr_ips_ipv6(cidr)
          Get a list of IPv6 addresses from a CIDR.

          CLI example:

             salt myminion netaddress.list_cidr_ips_ipv6 192.168.0.0/20

   salt.modules.netbsd_sysctl
   Module for viewing and modifying sysctl parameters

   salt.modules.netbsd_sysctl.assign(name, value)
          Assign a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.assign net.inet.icmp.icmplim 50

   salt.modules.netbsd_sysctl.get(name)
          Return a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.get hw.physmem

   salt.modules.netbsd_sysctl.persist(name,                         value,
   config='/etc/sysctl.conf')
          Assign and persist a simple sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.persist net.inet.icmp.icmplim 50

   salt.modules.netbsd_sysctl.show(config_file=False)
          Return a list of sysctl parameters for this minion

          CLI Example:

             salt '*' sysctl.show

   salt.modules.netbsdservice
   The service module for NetBSD

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   salt.modules.netbsdservice.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.netbsdservice.disable(name, **kwargs)
          Disable the named service to start at boot

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.netbsdservice.disabled(name)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.netbsdservice.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.netbsdservice.enabled(name, **kwargs)
          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.netbsdservice.force_reload(name)
          Force-reload the named service

          CLI Example:

             salt '*' service.force_reload <service name>

   salt.modules.netbsdservice.get_all()
          Return all available boot services

          CLI Example:

             salt '*' service.get_all

   salt.modules.netbsdservice.get_disabled()
          Return a set of services that are installed but disabled

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.netbsdservice.get_enabled()
          Return a list of service that are enabled on boot

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.netbsdservice.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.netbsdservice.reload(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.netbsdservice.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.netbsdservice.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.netbsdservice.status(name, sig=None)
          Return the status for a service,  returns  a  bool  whether  the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.netbsdservice.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.netscaler
   Module  to  provide  Citrix Netscaler compatibility to Salt (compatible
   with netscaler 9.2+)

   New in version 2015.2.0.

   depends

   * nsnitro Python module

   NOTE:
      You can install nsnitro using:

          pip install nsnitro

   configuration
          This module accepts connection configuration details  either  as
          parameters,  or as configuration settings in /etc/salt/minion on
          the relevant minions

             netscaler.host: 1.2.3.4
             netscaler.user: user
             netscaler.pass: password

          This data can also be passed into pillar.  Options  passed  into
          opts will overwrite options passed into pillar.

   CLI Examples
          Calls  relying  on  configuration passed using /etc/salt/minion,
          grains, or pillars:
             salt-call netscaler.server_exists server_name

          Calls passing configuration as opts
             salt-call         netscaler.server_exists         server_name
             netscaler_host=1.2.3.4                netscaler_user=username
             netscaler_pass=password   salt-call   netscaler.server_exists
             server_name  netscaler_host=1.2.3.5  netscaler_user=username2
             netscaler_pass=password2  salt-call   netscaler.server_enable
             server_name2 netscaler_host=1.2.3.5

   salt.modules.netscaler.server_add(s_name,      s_ip,      s_state=None,
   **connection_args)
          Add a server Note: The default server state is ENABLED

          CLI Example:

             salt '*' netscaler.server_add 'serverName' 'serverIpAddress'
             salt '*' netscaler.server_add 'serverName' 'serverIpAddress' 'serverState'

   salt.modules.netscaler.server_delete(s_name, **connection_args)
          Delete a server

          CLI Example:

             salt '*' netscaler.server_delete 'serverName'

   salt.modules.netscaler.server_disable(s_name, **connection_args)
          Disable a server globally

          CLI Example:

             salt '*' netscaler.server_disable 'serverName'

   salt.modules.netscaler.server_enable(s_name, **connection_args)
          Enables a server globally

          CLI Example:

             salt '*' netscaler.server_enable 'serverName'

   salt.modules.netscaler.server_enabled(s_name, **connection_args)
          Check if a server is enabled globally

          CLI Example:

             salt '*' netscaler.server_enabled 'serverName'

   salt.modules.netscaler.server_exists(s_name,   ip=None,   s_state=None,
   **connection_args)
          Checks if a server exists

          CLI Example:

             salt '*' netscaler.server_exists 'serverName'

   salt.modules.netscaler.server_update(s_name, s_ip, **connection_args)
          Update a server's attributes

          CLI Example:

             salt '*' netscaler.server_update 'serverName' 'serverIP'

   salt.modules.netscaler.service_disable(s_name,            s_delay=None,
   **connection_args)
          Disable a service

          CLI Example:

             salt '*' netscaler.service_disable 'serviceName'
             salt '*' netscaler.service_disable 'serviceName' 'delayInSeconds'

   salt.modules.netscaler.service_enable(s_name, **connection_args)
          Enable a service

          CLI Example:

             salt '*' netscaler.service_enable 'serviceName'

   salt.modules.netscaler.service_exists(s_name, **connection_args)
          Checks if a service exists

          CLI Example:

             salt '*' netscaler.service_exists 'serviceName'

   salt.modules.netscaler.service_up(s_name, **connection_args)
          Checks if a service is UP

          CLI Example:

             salt '*' netscaler.service_up 'serviceName'

   salt.modules.netscaler.servicegroup_add(sg_name,        sg_type='HTTP',
   **connection_args)
          Add  a  new  service group If no service type is specified, HTTP
          will be  used.   Most  common  service  types:  HTTP,  SSL,  and
          SSL_BRIDGE

          CLI Example:

             salt '*' netscaler.servicegroup_add 'serviceGroupName'
             salt '*' netscaler.servicegroup_add 'serviceGroupName' 'serviceGroupType'

   salt.modules.netscaler.servicegroup_delete(sg_name, **connection_args)
          Delete a new service group

          CLI Example:

             salt '*' netscaler.servicegroup_delete 'serviceGroupName'

   salt.modules.netscaler.servicegroup_exists(sg_name,       sg_type=None,
   **connection_args)
          Checks if a service group exists

          CLI Example:

             salt '*' netscaler.servicegroup_exists 'serviceGroupName'

   salt.modules.netscaler.servicegroup_server_add(sg_name, s_name, s_port,
   **connection_args)
          Add a server:port member to a servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_add 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.servicegroup_server_delete(sg_name,      s_name,
   s_port, **connection_args)
          Remove a server:port member from a servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_delete 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.servicegroup_server_disable(sg_name,     s_name,
   s_port, **connection_args)
          Disable a server:port member of a servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_disable 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.servicegroup_server_enable(sg_name,      s_name,
   s_port, **connection_args)
          Enable a server:port member of a servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_enable 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.servicegroup_server_exists(sg_name,      s_name,
   s_port=None, **connection_args)
          Check if a server:port combination is a member of a servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_exists 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.servicegroup_server_up(sg_name,  s_name, s_port,
   **connection_args)
          Check  if  a  server:port  combination  is  in  state  UP  in  a
          servicegroup

          CLI Example:

             salt '*' netscaler.servicegroup_server_up 'serviceGroupName' 'serverName' 'serverPort'

   salt.modules.netscaler.vserver_add(v_name,    v_ip,   v_port,   v_type,
   **connection_args)
          Add a new lb vserver

          CLI Example:

             salt '*' netscaler.vserver_add 'vserverName' 'vserverIP' 'vserverPort' 'vserverType'
             salt '*' netscaler.vserver_add 'alex.patate.chaude.443' '1.2.3.4' '443' 'SSL'

   salt.modules.netscaler.vserver_delete(v_name, **connection_args)
          Delete a lb vserver

          CLI Example:

             salt '*' netscaler.vserver_delete 'vserverName'

   salt.modules.netscaler.vserver_exists(v_name,  v_ip=None,  v_port=None,
   v_type=None, **connection_args)
          Checks if a vserver exists

          CLI Example:

             salt '*' netscaler.vserver_exists 'vserverName'

   salt.modules.netscaler.vserver_servicegroup_add(v_name,        sg_name,
   **connection_args)
          Bind a servicegroup to a vserver

          CLI Example:

             salt '*' netscaler.vserver_servicegroup_add 'vserverName' 'serviceGroupName'

   salt.modules.netscaler.vserver_servicegroup_delete(v_name,     sg_name,
   **connection_args)
          Unbind a servicegroup from a vserver

          CLI Example:

             salt '*' netscaler.vserver_servicegroup_delete 'vserverName' 'serviceGroupName'

   salt.modules.netscaler.vserver_servicegroup_exists(v_name,     sg_name,
   **connection_args)
          Checks if a servicegroup is tied to a vserver

          CLI Example:

             salt '*' netscaler.vserver_servicegroup_exists 'vserverName' 'serviceGroupName'

   salt.modules.netscaler.vserver_sslcert_add(v_name,             sc_name,
   **connection_args)
          Binds a SSL certificate to a vserver

          CLI Example:

             salt '*' netscaler.vserver_sslcert_add 'vserverName' 'sslCertificateName'

   salt.modules.netscaler.vserver_sslcert_delete(v_name,          sc_name,
   **connection_args)
          Unbinds a SSL certificate from a vserver

          CLI Example:

             salt '*' netscaler.vserver_sslcert_delete 'vserverName' 'sslCertificateName'

   salt.modules.netscaler.vserver_sslcert_exists(v_name,          sc_name,
   **connection_args)
          Checks if a SSL certificate is tied to a vserver

          CLI Example:

             salt '*' netscaler.vserver_sslcert_exists 'vserverName' 'sslCertificateName'

   salt.modules.network
   Module for gathering and managing network information

   salt.modules.network.active_tcp()
          Return  a  dict containing information on all of the running TCP
          connections (currently linux and solaris only)

          Changed in version 2015.8.4: Added support for SunOS

          CLI Example:

             salt '*' network.active_tcp

   salt.modules.network.arp()
          Return the arp table from the minion

          Changed in version 2015.8.0: Added support for SunOS

          CLI Example:

             salt '*' network.arp

   salt.modules.network.calc_net(ip_addr, netmask=None)
          Returns the CIDR of a  subnet  based  on  an  IP  address  (CIDR
          notation supported) and optional netmask.

          CLI Example:

             salt '*' network.calc_net 172.17.0.5 255.255.255.240
             salt '*' network.calc_net 2a02:f6e:a000:80:84d8:8332:7866:4e07/64

          New in version 2015.8.0.

   salt.modules.network.connect(host, port=None, **kwargs)
          Test  connectivity  to  a  host using a particular port from the
          minion.

          New in version 2014.7.0.

          CLI Example:

             salt '*' network.connect archlinux.org 80

             salt '*' network.connect archlinux.org 80 timeout=3

             salt '*' network.connect archlinux.org 80 timeout=3 family=ipv4

             salt '*' network.connect google-public-dns-a.google.com port=53 proto=udp timeout=3

   salt.modules.network.convert_cidr(cidr)
          returns the network and subnet mask of a cidr addr

          New in version 2016.3.0.

          CLI Example:

             salt '*' network.convert_cidr 172.31.0.0/16

   salt.modules.network.default_route(family=None)
          Return default route(s) from routing table

          Changed in version 2015.8.0: Added support  for  SunOS  (Solaris
          10, Illumos, SmartOS)

          CLI Example:

             salt '*' network.default_route

   salt.modules.network.dig(host)
          Performs a DNS lookup with dig

          CLI Example:

             salt '*' network.dig archlinux.org

   salt.modules.network.get_bufsize(iface)
          Return network buffer sizes as a dict (currently linux only)

          CLI Example:

             salt '*' network.get_bufsize eth0

   salt.modules.network.get_hostname()
          Get hostname

          CLI Example:

             salt '*' network.get_hostname

   salt.modules.network.get_route(ip)
          Return routing information for given destination ip

          New in version 2015.5.3.

          Changed  in  version  2015.8.0: Added support for SunOS (Solaris
          10, Illumos, SmartOS) Added support for OpenBSD

          CLI Example:

             salt '*' network.get_route 10.10.10.10

   salt.modules.network.hw_addr(iface)
          Return the hardware address (a.k.a. MAC  address)  for  a  given
          interface

          CLI Example:

             salt '*' network.hw_addr eth0

   salt.modules.network.hwaddr(iface)
          This function is an alias of hw_addr.
             Return  the hardware address (a.k.a. MAC address) for a given
             interface

             CLI Example:

                 salt '*' network.hw_addr eth0

   salt.modules.network.ifacestartswith(cidr)
          Retrieve the interface name from a specific CIDR

          New in version 2016.11.0.

          CLI Example:

             salt '*' network.ifacestartswith 10.0

   salt.modules.network.in_subnet(cidr)
          Returns True if  host  is  within  specified  subnet,  otherwise
          False.

          CLI Example:

             salt '*' network.in_subnet 10.0.0.0/16

   salt.modules.network.interface(iface)
          Return the inet address for a given interface

          New in version 2014.7.0.

          CLI Example:

             salt '*' network.interface eth0

   salt.modules.network.interface_ip(iface)
          Return the inet address for a given interface

          New in version 2014.7.0.

          CLI Example:

             salt '*' network.interface_ip eth0

   salt.modules.network.interfaces()
          Return  a  dictionary of information about all the interfaces on
          the minion

          CLI Example:

             salt '*' network.interfaces

   salt.modules.network.ip_addrs(interface=None,   include_loopback=False,
   cidr=None, type=None)
          Returns a list of IPv4 addresses assigned to the host. 127.0.0.1
          is ignored,  unless  'include_loopback=True'  is  indicated.  If
          'interface'  is  provided,  then  only  IP  addresses  from that
          interface   will   be   returned.    Providing   a   CIDR    via
          'cidr="10.0.0.0/8"'  will  return  only  the addresses which are
          within that subnet. If 'type'  is  'public',  then  only  public
          addresses will be returned. Ditto for 'type'='private'.

          CLI Example:

             salt '*' network.ip_addrs

   salt.modules.network.ip_addrs6(interface=None,  include_loopback=False,
   cidr=None)
          Returns a list of IPv6 addresses assigned to the  host.  ::1  is
          ignored,   unless   'include_loopback=True'   is  indicated.  If
          'interface' is  provided,  then  only  IP  addresses  from  that
          interface    will   be   returned.    Providing   a   CIDR   via
          'cidr="2000::/3"' will  return  only  the  addresses  which  are
          within that subnet.

          CLI Example:

             salt '*' network.ip_addrs6

   salt.modules.network.ip_in_subnet(ip_addr, cidr)
          Returns  True  if given IP is within specified subnet, otherwise
          False.

          CLI Example:

             salt '*' network.ip_in_subnet 172.17.0.4 172.16.0.0/12

   salt.modules.network.ipaddrs(interface=None,    include_loopback=False,
   cidr=None, type=None)
          This function is an alias of ip_addrs.
             Returns  a  list  of  IPv4  addresses  assigned  to the host.
             127.0.0.1  is  ignored,  unless  'include_loopback=True'   is
             indicated. If 'interface' is provided, then only IP addresses
             from that interface will be returned.  Providing a  CIDR  via
             'cidr="10.0.0.0/8"'  will return only the addresses which are
             within that subnet. If 'type' is 'public', then  only  public
             addresses will be returned. Ditto for 'type'='private'.

             CLI Example:

                 salt '*' network.ip_addrs

   salt.modules.network.ipaddrs6(interface=None,   include_loopback=False,
   cidr=None)
          This function is an alias of ip_addrs6.
             Returns a list of IPv6 addresses assigned to the host. ::1 is
             ignored,  unless  'include_loopback=True'  is  indicated.  If
             'interface' is provided, then only  IP  addresses  from  that
             interface   will   be   returned.    Providing   a  CIDR  via
             'cidr="2000::/3"' will return only the  addresses  which  are
             within that subnet.

             CLI Example:

                 salt '*' network.ip_addrs6

   salt.modules.network.iphexval(ip)
          Retrieve the interface name from a specific CIDR

          New in version 2016.11.0.

          CLI Example:

             salt '*' network.iphexval 10.0.0.1

   salt.modules.network.is_loopback(ip_addr)
          Check if the given IP address is a loopback address

          New in version 2014.7.0.

          Changed in version 2015.8.0: IPv6 support

          CLI Example:

             salt '*' network.is_loopback 127.0.0.1

   salt.modules.network.is_private(ip_addr)
          Check if the given IP address is a private address

          New in version 2014.7.0.

          Changed in version 2015.8.0: IPv6 support

          CLI Example:

             salt '*' network.is_private 10.0.0.3

   salt.modules.network.mod_bufsize(iface, *args, **kwargs)
          Modify network interface buffers (currently linux only)

          CLI Example:

             salt '*' network.mod_bufsize tx=<val> rx=<val> rx-mini=<val> rx-jumbo=<val>

   salt.modules.network.mod_hostname(hostname)
          Modify hostname

          Changed  in  version  2015.8.0: Added support for SunOS (Solaris
          10, Illumos, SmartOS)

          CLI Example:

             salt '*' network.mod_hostname master.saltstack.com

   salt.modules.network.netstat()
          Return information on open ports and states

          NOTE:
             On  BSD  minions,  the  output  contains  PID   info   (where
             available)    for    each   netstat   entry,   fetched   from
             sockstat/fstat output.

          Changed in version 2014.1.4: Added support for OpenBSD, FreeBSD,
          and NetBSD

          Changed in version 2015.8.0: Added support for SunOS

          CLI Example:

             salt '*' network.netstat

   salt.modules.network.ping(host, timeout=False, return_boolean=False)
          Performs an ICMP ping to a host

          Changed in version 2015.8.0: Added support for SunOS

          CLI Example:

             salt '*' network.ping archlinux.org

          New in version 2015.5.0.

          Return a True or False instead of ping output.

             salt '*' network.ping archlinux.org return_boolean=True

          Set the time to wait for a response in seconds.

             salt '*' network.ping archlinux.org timeout=3

   salt.modules.network.reverse_ip(ip_addr)
          Returns the reversed IP address

          Changed in version 2015.8.0: IPv6 support

          CLI Example:

             salt '*' network.reverse_ip 172.17.0.4

   salt.modules.network.routes(family=None)
          Return currently configured routes from routing table

          Changed  in  version  2015.8.0: Added support for SunOS (Solaris
          10, Illumos, SmartOS)

          CLI Example:

             salt '*' network.routes

   salt.modules.network.subnets(interfaces=None)
          Returns a list of IPv4 subnets to which the host belongs

          CLI Example:

             salt '*' network.subnets
             salt '*' network.subnets interfaces=eth1

   salt.modules.network.subnets6()
          Returns a list of IPv6 subnets to which the host belongs

          CLI Example:

             salt '*' network.subnets

   salt.modules.network.traceroute(host)
          Performs a traceroute to a 3rd party host

          Changed in version 2015.8.0: Added support for SunOS

          CLI Example:

             salt '*' network.traceroute archlinux.org

   salt.modules.network.wol(mac, bcast='255.255.255.255', destport=9)
          Send Wake On Lan packet to a host

          CLI Example:

             salt '*' network.wol 08-00-27-13-69-77
             salt '*' network.wol 080027136977 255.255.255.255 7
             salt '*' network.wol 08:00:27:13:69:77 255.255.255.255 7

   salt.modules.neutron
   Module for handling OpenStack Neutron calls

   depends

          * neutronclient Python module

   configuration
          This module is not usable until the user, password, tenant,  and
          auth  URL  are  specified  either in a pillar or in the minion's
          config file.  For example:

             keystone.user: 'admin'
             keystone.password: 'password'
             keystone.tenant: 'admin'
             keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
             keystone.region_name: 'RegionOne'
             keystone.service_type: 'network'

          If configuration for multiple OpenStack  accounts  is  required,
          they  can  be  set  up  as different configuration profiles: For
          example:

             openstack1:
               keystone.user: 'admin'
               keystone.password: 'password'
               keystone.tenant: 'admin'
               keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
               keystone.region_name: 'RegionOne'
               keystone.service_type: 'network'

             openstack2:
               keystone.user: 'admin'
               keystone.password: 'password'
               keystone.tenant: 'admin'
               keystone.auth_url: 'http://127.0.0.2:5000/v2.0/'
               keystone.region_name: 'RegionOne'
               keystone.service_type: 'network'

          With this configuration in place, any of the  neutron  functions
          can  make  use  of  a  configuration  profile  by  declaring  it
          explicitly.  For example:

             salt '*' neutron.network_list profile=openstack1

   salt.modules.neutron.add_gateway_router(router,            ext_network,
   profile=None)
          Adds an external network gateway to the specified router

          CLI Example:

             salt '*' neutron.add_gateway_router router-name ext-network-name

          Parameters

                 * router -- ID or name of the router

                 * ext_network  --  ID or name of the external network the
                   gateway

                 * profile -- Profile to build on (Optional)

          Returns
                 Added Gateway router information

   salt.modules.neutron.add_interface_router(router, subnet, profile=None)
          Adds an internal network interface to the specified router

          CLI Example:

             salt '*' neutron.add_interface_router router-name subnet-name

          Parameters

                 * router -- ID or name of the router

                 * subnet -- ID or name of the subnet

                 * profile -- Profile to build on (Optional)

          Returns
                 Added interface information

   salt.modules.neutron.create_firewall_rule(protocol,             action,
   profile=None, **kwargs)
          Creates a new firewall rule

          CLI Example:

             salt '*' neutron.create_firewall_rule protocol action
                     tenant_id=TENANT_ID name=NAME description=DESCRIPTION ip_version=IP_VERSION
                     source_ip_address=SOURCE_IP_ADDRESS destination_ip_address=DESTINATION_IP_ADDRESS source_port=SOURCE_PORT
                     destination_port=DESTINATION_PORT shared=SHARED enabled=ENABLED

          Parameters

                 * protocol  --  Protocol  for  the  firewall rule, choose
                   "tcp","udp","icmp" or "None".

                 * action -- Action for the firewall rule, choose  "allow"
                   or "deny".

                 * tenant_id -- The owner tenant ID. (Optional)

                 * name -- Name for the firewall rule. (Optional)

                 * description  --  Description  for  the  firewall  rule.
                   (Optional)

                 * ip_version  --  IP  protocol   version,   default:   4.
                   (Optional)

                 * source_ip_address  --  Source  IP  address  or  subnet.
                   (Optional)

                 * destination_ip_address --  Destination  IP  address  or
                   subnet. (Optional)

                 * source_port  --  Source  port (integer in [1, 65535] or
                   range in a:b). (Optional)

                 * destination_port -- Destination port  (integer  in  [1,
                   65535] or range in a:b). (Optional)

                 * shared   --   Set   shared  to  True,  default:  False.
                   (Optional)

                 * enabled  --  To  enable  this  rule,   default:   True.
                   (Optional)

   salt.modules.neutron.create_floatingip(floating_network,     port=None,
   profile=None)
          Creates a new floatingIP

          CLI Example:

             salt '*' neutron.create_floatingip network-name port-name

          Parameters

                 * floating_network -- Network  name  or  ID  to  allocate
                   floatingIP from

                 * port   --  Of  the  port  to  be  associated  with  the
                   floatingIP (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created floatingIP information

   salt.modules.neutron.create_ikepolicy(name, profile=None, **kwargs)
          Creates a new IKEPolicy

          CLI Example:

             salt '*' neutron.create_ikepolicy ikepolicy-name
                     phase1_negotiation_mode=main auth_algorithm=sha1
                     encryption_algorithm=aes-128 pfs=group5

          Parameters

                 * name -- Name of the IKE policy

                 * phase1_negotiation_mode -- IKE Phase1 negotiation  mode
                   in lowercase, default: main (Optional)

                 * auth_algorithm    --    Authentication   algorithm   in
                   lowercase, default: sha1 (Optional)

                 * encryption_algorithm   --   Encryption   algorithm   in
                   lowercase.  default:aes-128 (Optional)

                 * pfs  -- Prefect Forward Security in lowercase, default:
                   group5 (Optional)

                 * units  --  IKE  lifetime  attribute.  default:  seconds
                   (Optional)

                 * value   --   IKE   lifetime  attribute.  default:  3600
                   (Optional)

                 * ike_version -- IKE version in  lowercase,  default:  v1
                   (Optional)

                 * profile -- Profile to build on (Optional)

                 * kwargs --

          Returns
                 Created IKE policy information

   salt.modules.neutron.create_ipsec_site_connection(name,    ipsecpolicy,
   ikepolicy,  vpnservice,   peer_cidrs,   peer_address,   peer_id,   psk,
   admin_state_up=True, profile=None, **kwargs)
          Creates a new IPsecSiteConnection

          CLI Example:

             salt '*' neutron.show_ipsec_site_connection connection-name
                     ipsec-policy-name ikepolicy-name vpnservice-name
                     192.168.XXX.XXX/24 192.168.XXX.XXX 192.168.XXX.XXX secret

          Parameters

                 * name -- Set friendly name for the connection

                 * ipsecpolicy  -- IPSec policy ID or name associated with
                   this connection

                 * ikepolicy -- IKE policy ID or name associated with this
                   connection

                 * vpnservice   --   VPN   service  instance  ID  or  name
                   associated with this connection

                 * peer_cidrs -- Remote subnet(s) in CIDR format

                 * peer_address -- Peer gateway public  IPv4/IPv6  address
                   or FQDN

                 * peer_id  -- Peer router identity for authentication Can
                   be IPv4/IPv6 address, e-mail address, key id, or FQDN

                 * psk -- Pre-shared key string

                 * initiator   --   Initiator    state    in    lowercase,
                   default:bi-directional

                 * admin_state_up  -- Set admin state up to true or false,
                   default: True (Optional)

                 * mtu -- size for the connection, default:1500 (Optional)

                 * dpd_action   --   Dead   Peer   Detection    attribute:
                   hold/clear/disabled/ restart/restart-by-peer (Optional)

                 * dpd_interval   --   Dead   Peer   Detection   attribute
                   (Optional)

                 * dpd_timeout -- Dead Peer Detection attribute (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created IPSec site connection information

   salt.modules.neutron.create_ipsecpolicy(name, profile=None, **kwargs)
          Creates a new IPsecPolicy

          CLI Example:

             salt '*' neutron.create_ipsecpolicy ipsecpolicy-name
                     transform_protocol=esp auth_algorithm=sha1
                     encapsulation_mode=tunnel encryption_algorithm=aes-128

          Parameters

                 * name -- Name of the IPSec policy

                 * transform_protocol -- Transform protocol in  lowercase,
                   default: esp (Optional)

                 * auth_algorithm    --    Authentication   algorithm   in
                   lowercase, default: sha1 (Optional)

                 * encapsulation_mode -- Encapsulation mode in  lowercase,
                   default: tunnel (Optional)

                 * encryption_algorithm   --   Encryption   algorithm   in
                   lowercase, default:aes-128 (Optional)

                 * pfs -- Prefect Forward Security in lowercase,  default:
                   group5 (Optional)

                 * units  --  IPSec  lifetime  attribute. default: seconds
                   (Optional)

                 * value  --  IPSec  lifetime  attribute.  default:   3600
                   (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created IPSec policy information

   salt.modules.neutron.create_network(name,              router_ext=None,
   admin_state_up=True,     network_type=None,      physical_network=None,
   segmentation_id=None, shared=None, profile=None)
          Creates a new network

          CLI Example:

             salt '*' neutron.create_network network-name
             salt '*' neutron.create_network network-name profile=openstack1

          Parameters

                 * name -- Name of network to create

                 * admin_state_up  --  should  the state of the network be
                   up?  default: True (Optional)

                 * router_ext -- True then if create the external  network
                   (Optional)

                 * network_type  --  the Type of network that the provider
                   is such as GRE, VXLAN, VLAN, FLAT, or LOCAL (Optional)

                 * physical_network -- the name of the physical network as
                   neutron knows it (Optional)

                 * segmentation_id -- the vlan id or GRE id (Optional)

                 * shared -- is the network shared or not (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created network information

   salt.modules.neutron.create_port(name,     network,     device_id=None,
   admin_state_up=True, profile=None)
          Creates a new port

          CLI Example:

             salt '*' neutron.create_port network-name port-name

          Parameters

                 * name -- Name of port to create

                 * network -- Network name or ID

                 * device_id -- ID of device (Optional)

                 * admin_state_up -- Set admin state up to true or  false,
                   default: true (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created port information

   salt.modules.neutron.create_router(name,              ext_network=None,
   admin_state_up=True, profile=None)
          Creates a new router

          CLI Example:

             salt '*' neutron.create_router new-router-name

          Parameters

                 * name -- Name of router to create (must be first)

                 * ext_network -- ID or  name  of  the  external  for  the
                   gateway (Optional)

                 * admin_state_up  -- Set admin state up to true or false,
                   default:true (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created router information

   salt.modules.neutron.create_security_group(name=None, description=None,
   profile=None)
          Creates a new security group

          CLI Example:

             salt '*' neutron.create_security_group security-group-name                 description='Security group for servers'

          Parameters

                 * name -- Name of security group (Optional)

                 * description -- Description of security group (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created security group information

   salt.modules.neutron.create_security_group_rule(security_group,
   remote_group_id=None,        direction='ingress',        protocol=None,
   port_range_min=None,       port_range_max=None,       ethertype='IPv4',
   profile=None)
          Creates a new security group rule

          CLI Example:

             salt '*' neutron.show_security_group_rule security-group-rule-id

          Parameters

                 * security_group -- Security group name or ID to add rule

                 * remote_group_id -- Remote security group name or ID  to
                   apply rule (Optional)

                 * direction  --  Direction  of  traffic:  ingress/egress,
                   default: ingress (Optional)

                 * protocol  --  Protocol  of  packet:  null/icmp/tcp/udp,
                   default: null (Optional)

                 * port_range_min -- Starting port range (Optional)

                 * port_range_max -- Ending port range (Optional)

                 * ethertype -- IPv4/IPv6, default: IPv4 (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created security group rule information

   salt.modules.neutron.create_subnet(network,       cidr,      name=None,
   ip_version=4, profile=None)
          Creates a new subnet

          CLI Example:

             salt '*' neutron.create_subnet network-name 192.168.1.0/24

          Parameters

                 * network -- Network ID or name this subnet belongs to

                 * cidr -- CIDR of subnet to create (Ex. '192.168.1.0/24')

                 * name -- Name of the subnet to create (Optional)

                 * ip_version  --  Version  to  use,  default  is  4(IPv4)
                   (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created subnet information

   salt.modules.neutron.create_vpnservice(subnet,       router,      name,
   admin_state_up=True, profile=None)
          Creates a new VPN service

          CLI Example:

             salt '*' neutron.create_vpnservice router-name name

          Parameters

                 * subnet -- Subnet unique identifier for the VPN  service
                   deployment

                 * router -- Router unique identifier for the VPN service

                 * name -- Set a name for the VPN service

                 * admin_state_up  -- Set admin state up to true or false,
                   default:True (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Created VPN service information

   salt.modules.neutron.delete_firewall_rule(firewall_rule, profile=None)
          Deletes the specified firewall_rule

          CLI Example:

             salt '*' neutron.delete_firewall_rule firewall-rule

          Parameters

                 * firewall_rule -- ID or name of firewall rule to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_floatingip(floatingip_id, profile=None)
          Deletes the specified floating IP

          CLI Example:

             salt '*' neutron.delete_floatingip floatingip-id

          Parameters

                 * floatingip_id -- ID of floatingIP to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_ikepolicy(ikepolicy, profile=None)
          Deletes the specified IKEPolicy

          CLI Example:

             salt '*' neutron.delete_ikepolicy ikepolicy-name

          Parameters

                 * ikepolicy -- ID or name of IKE policy to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_ipsec_site_connection(ipsec_site_connection,
   profile=None)
          Deletes the specified IPsecSiteConnection

          CLI Example:

             salt '*' neutron.delete_ipsec_site_connection connection-name

          Parameters

                 * ipsec_site_connection  --  ID  or  name  of  ipsec site
                   connection to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_ipsecpolicy(ipsecpolicy, profile=None)
          Deletes the specified IPsecPolicy

          CLI Example:

             salt '*' neutron.delete_ipsecpolicy ipsecpolicy-name

          Parameters

                 * ipsecpolicy -- ID or name of IPSec policy to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_network(network, profile=None)
          Deletes the specified network

          CLI Example:

             salt '*' neutron.delete_network network-name
             salt '*' neutron.delete_network network-name profile=openstack1

          Parameters

                 * network -- ID or name of network to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_port(port, profile=None)
          Deletes the specified port

          CLI Example:

             salt '*' neutron.delete_network port-name
             salt '*' neutron.delete_network port-name profile=openstack1

          Parameters

                 * port -- port name or ID

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_quota(tenant_id, profile=None)
          Delete the specified tenant's quota value

          CLI Example:

             salt '*' neutron.update_quota tenant-id
             salt '*' neutron.update_quota tenant-id profile=openstack1

          Parameters

                 * tenant_id -- ID of tenant to quota delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Delete succeed) or False(Delete failed)

   salt.modules.neutron.delete_router(router, profile=None)
          Delete the specified router

          CLI Example:

             salt '*' neutron.delete_router router-name

          Parameters

                 * router -- ID or name of router to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_security_group(security_group,
   profile=None)
          Deletes the specified security group

          CLI Example:

             salt '*' neutron.delete_security_group security-group-name

          Parameters

                 * security_group  --  ID  or  name  of  security group to
                   delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_security_group_rule(security_group_rule_id,
   profile=None)
          Deletes the specified security group rule

          CLI Example:

             salt '*' neutron.delete_security_group_rule security-group-rule-id

          Parameters

                 * security_group_rule_id  -- ID of security group rule to
                   delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_subnet(subnet, profile=None)
          Deletes the specified subnet

          CLI Example:

             salt '*' neutron.delete_subnet subnet-name
             salt '*' neutron.delete_subnet subnet-name profile=openstack1

          Parameters

                 * subnet -- ID or name of subnet to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.delete_vpnservice(vpnservice, profile=None)
          Deletes the specified VPN service

          CLI Example:

             salt '*' neutron.delete_vpnservice vpnservice-name

          Parameters

                 * vpnservice -- ID or name of vpn service to delete

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.get_quotas_tenant(profile=None)
          Fetches tenant info in  server's  context  for  following  quota
          operation

          CLI Example:

             salt '*' neutron.get_quotas_tenant
             salt '*' neutron.get_quotas_tenant profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 Quotas information

   salt.modules.neutron.list_agents(profile=None)
          List agents.

          CLI Example:

             salt '*' neutron.list_agents

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 agents message.

   salt.modules.neutron.list_extensions(profile=None)
          Fetches a list of all extensions on server side

          CLI Example:

             salt '*' neutron.list_extensions
             salt '*' neutron.list_extensions profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of extensions

   salt.modules.neutron.list_firewall_rules(profile=None)
          Fetches a list of all firewall rules for a tenant CLI Example:

             salt '*' neutron.list_firewall_rules

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of firewall rules

   salt.modules.neutron.list_firewalls(profile=None)
          Fetches a list of all firewalls for a tenant CLI Example:

             salt '*' neutron.list_firewalls

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of firewalls

   salt.modules.neutron.list_floatingips(profile=None)
          Fetch a list of all floatingIPs for a tenant

          CLI Example:

             salt '*' neutron.list_floatingips
             salt '*' neutron.list_floatingips profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of floatingIP

   salt.modules.neutron.list_ikepolicies(profile=None)
          Fetches a list of all configured IKEPolicies for a tenant

          CLI Example:

             salt '*' neutron.list_ikepolicies
             salt '*' neutron.list_ikepolicies profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of IKE policy

   salt.modules.neutron.list_ipsec_site_connections(profile=None)
          Fetches all configured IPsec Site Connections for a tenant

          CLI Example:

             salt '*' neutron.list_ipsec_site_connections
             salt '*' neutron.list_ipsec_site_connections profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of IPSec site connection

   salt.modules.neutron.list_ipsecpolicies(profile=None)
          Fetches a list of all configured IPsecPolicies for a tenant

          CLI Example:

             salt '*' neutron.list_ipsecpolicies ipsecpolicy-name
             salt '*' neutron.list_ipsecpolicies ipsecpolicy-name profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of IPSec policy

   salt.modules.neutron.list_l3_agent_hosting_routers(router,
   profile=None)
          List L3 agents hosting a router.

          CLI Example:

             salt '*' neutron.list_l3_agent_hosting_routers router

          :param router:router name  or  ID  to  query.   :param  profile:
          Profile to build on (Optional) :return: L3 agents message.

   salt.modules.neutron.list_networks(profile=None)
          Fetches a list of all networks for a tenant

          CLI Example:

             salt '*' neutron.list_networks
             salt '*' neutron.list_networks profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of network

   salt.modules.neutron.list_ports(profile=None)
          Fetches a list of all networks for a tenant

          CLI Example:

             salt '*' neutron.list_ports
             salt '*' neutron.list_ports profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of port

   salt.modules.neutron.list_quotas(profile=None)
          Fetches all tenants quotas

          CLI Example:

             salt '*' neutron.list_quotas
             salt '*' neutron.list_quotas profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of quotas

   salt.modules.neutron.list_routers(profile=None)
          Fetches a list of all routers for a tenant

          CLI Example:

             salt '*' neutron.list_routers
             salt '*' neutron.list_routers profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of router

   salt.modules.neutron.list_security_group_rules(profile=None)
          Fetches a list of all security group rules for a tenant

          CLI Example:

             salt '*' neutron.list_security_group_rules
             salt '*' neutron.list_security_group_rules profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of security group rule

   salt.modules.neutron.list_security_groups(profile=None)
          Fetches a list of all security groups for a tenant

          CLI Example:

             salt '*' neutron.list_security_groups
             salt '*' neutron.list_security_groups profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of security group

   salt.modules.neutron.list_subnets(profile=None)
          Fetches a list of all networks for a tenant

          CLI Example:

             salt '*' neutron.list_subnets
             salt '*' neutron.list_subnets profile=openstack1

          Parameters
                 profile -- Profile to build on (Optional)

          Returns
                 List of subnet

   salt.modules.neutron.list_vpnservices(retrieve_all=True,  profile=None,
   **kwargs)
          Fetches a list of all configured VPN services for a tenant

          CLI Example:

             salt '*' neutron.list_vpnservices

          Parameters

                 * retrieve_all -- True or False, default: True (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 List of VPN service

   salt.modules.neutron.remove_gateway_router(router, profile=None)
          Removes an external network gateway from the specified router

          CLI Example:

             salt '*' neutron.remove_gateway_router router-name

          Parameters

                 * router -- ID or name of router

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.remove_interface_router(router,            subnet,
   profile=None)
          Removes an internal network interface from the specified router

          CLI Example:

             salt '*' neutron.remove_interface_router router-name subnet-name

          Parameters

                 * router -- ID or name of the router

                 * subnet -- ID or name of the subnet

                 * profile -- Profile to build on (Optional)

          Returns
                 True(Succeed) or False

   salt.modules.neutron.show_firewall(firewall, profile=None)
          Fetches information of a specific firewall rule

          CLI Example:

             salt '*' neutron.show_firewall firewall

          Parameters

                 * firewall -- ID or name of firewall to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 firewall information

   salt.modules.neutron.show_firewall_rule(firewall_rule, profile=None)
          Fetches information of a specific firewall rule

          CLI Example:

             salt '*' neutron.show_firewall_rule firewall-rule-name

          Parameters

                 * ipsecpolicy -- ID or name of firewall rule to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 firewall rule information

   salt.modules.neutron.show_floatingip(floatingip_id, profile=None)
          Fetches information of a certain floatingIP

          CLI Example:

             salt '*' neutron.show_floatingip floatingip-id

          Parameters

                 * floatingip_id -- ID of floatingIP to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Floating IP information

   salt.modules.neutron.show_ikepolicy(ikepolicy, profile=None)
          Fetches information of a specific IKEPolicy

          CLI Example:

             salt '*' neutron.show_ikepolicy ikepolicy-name

          Parameters

                 * ikepolicy -- ID or name of ikepolicy to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 IKE policy information

   salt.modules.neutron.show_ipsec_site_connection(ipsec_site_connection,
   profile=None)
          Fetches information of a specific IPsecSiteConnection

          CLI Example:

             salt '*' neutron.show_ipsec_site_connection connection-name

          Parameters

                 * ipsec_site_connection --  ID  or  name  of  ipsec  site
                   connection to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 IPSec site connection information

   salt.modules.neutron.show_ipsecpolicy(ipsecpolicy, profile=None)
          Fetches information of a specific IPsecPolicy

          CLI Example:

             salt '*' neutron.show_ipsecpolicy ipsecpolicy-name

          Parameters

                 * ipsecpolicy -- ID or name of IPSec policy to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 IPSec policy information

   salt.modules.neutron.show_network(network, profile=None)
          Fetches information of a certain network

          CLI Example:

             salt '*' neutron.show_network network-name
             salt '*' neutron.show_network network-name profile=openstack1

          Parameters

                 * network -- ID or name of network to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Network information

   salt.modules.neutron.show_port(port, profile=None)
          Fetches information of a certain port

          CLI Example:

             salt '*' neutron.show_port port-id
             salt '*' neutron.show_port port-id profile=openstack1

          Parameters

                 * port -- ID or name of port to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Port information

   salt.modules.neutron.show_quota(tenant_id, profile=None)
          Fetches information of a certain tenant's quotas

          CLI Example:

             salt '*' neutron.show_quota tenant-id
             salt '*' neutron.show_quota tenant-id profile=openstack1

          Parameters

                 * tenant_id -- ID of tenant

                 * profile -- Profile to build on (Optional)

          Returns
                 Quota information

   salt.modules.neutron.show_router(router, profile=None)
          Fetches information of a certain router

          CLI Example:

             salt '*' neutron.show_router router-name

          Parameters

                 * router -- ID or name of router to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Router information

   salt.modules.neutron.show_security_group(security_group, profile=None)
          Fetches information of a certain security group

          CLI Example:

             salt '*' neutron.show_security_group security-group-name

          Parameters

                 * security_group  -- ID or name of security group to look
                   up

                 * profile -- Profile to build on (Optional)

          Returns
                 Security group information

   salt.modules.neutron.show_security_group_rule(security_group_rule_id,
   profile=None)
          Fetches information of a certain security group rule

          CLI Example:

             salt '*' neutron.show_security_group_rule security-group-rule-id

          Parameters

                 * security_group_rule_id  -- ID of security group rule to
                   look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Security group rule information

   salt.modules.neutron.show_subnet(subnet, profile=None)
          Fetches information of a certain subnet

          CLI Example:

             salt '*' neutron.show_subnet subnet-name

          Parameters

                 * subnet -- ID or name of subnet to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 Subnet information

   salt.modules.neutron.show_vpnservice(vpnservice,          profile=None,
   **kwargs)
          Fetches information of a specific VPN service

          CLI Example:

             salt '*' neutron.show_vpnservice vpnservice-name

          Parameters

                 * vpnservice -- ID or name of vpn service to look up

                 * profile -- Profile to build on (Optional)

          Returns
                 VPN service information

   salt.modules.neutron.update_firewall_rule(firewall_rule, protocol=None,
   action=None,     name=None,     description=None,      ip_version=None,
   source_ip_address=None,  destination_ip_address=None, source_port=None,
   destination_port=None, shared=None, enabled=None, profile=None)
          Update a firewall rule

          CLI Example:

             salt '*' neutron.update_firewall_rule firewall_rule protocol=PROTOCOL action=ACTION
                     name=NAME description=DESCRIPTION ip_version=IP_VERSION
                     source_ip_address=SOURCE_IP_ADDRESS destination_ip_address=DESTINATION_IP_ADDRESS
                     source_port=SOURCE_PORT destination_port=DESTINATION_PORT shared=SHARED enabled=ENABLED

          Parameters

                 * firewall_rule -- ID or name of firewall rule to update.

                 * protocol -- Protocol  for  the  firewall  rule,  choose
                   "tcp","udp","icmp" or "None". (Optional)

                 * action  -- Action for the firewall rule, choose "allow"
                   or "deny". (Optional)

                 * name -- Name for the firewall rule. (Optional)

                 * description  --  Description  for  the  firewall  rule.
                   (Optional)

                 * ip_version   --   IP   protocol  version,  default:  4.
                   (Optional)

                 * source_ip_address  --  Source  IP  address  or  subnet.
                   (Optional)

                 * destination_ip_address  --  Destination  IP  address or
                   subnet. (Optional)

                 * source_port -- Source port (integer in  [1,  65535]  or
                   range in a:b). (Optional)

                 * destination_port  --  Destination  port (integer in [1,
                   65535] or range in a:b). (Optional)

                 * shared  --  Set  shared  to   True,   default:   False.
                   (Optional)

                 * enabled   --   To  enable  this  rule,  default:  True.
                   (Optional)

                 * profile -- Profile to build on (Optional)

   salt.modules.neutron.update_floatingip(floatingip_id,             port,
   profile=None)
          Updates a floatingIP

          CLI Example:

             salt '*' neutron.update_floatingip network-name port-name

          Parameters

                 * floatingip_id -- ID of floatingIP

                 * port -- ID or name of port

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated floating IP information

   salt.modules.neutron.update_network(network, name, profile=None)
          Updates a network

          CLI Example:

             salt '*' neutron.update_network network-name new-network-name

          Parameters

                 * network -- ID or name of network to update

                 * name -- Name of this network

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated network information

   salt.modules.neutron.update_port(port,    name,    admin_state_up=True,
   profile=None)
          Updates a port

          CLI Example:

             salt '*' neutron.update_port port-name network-name new-port-name

          Parameters

                 * port -- Port name or ID

                 * name -- Name of this port

                 * admin_state_up -- Set admin state up to true or  false,
                   default: true (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated port information

   salt.modules.neutron.update_quota(tenant_id,  subnet=None, router=None,
   network=None,    floatingip=None,    port=None,    security_group=None,
   security_group_rule=None, profile=None)
          Update a tenant's quota

          CLI Example:

             salt '*' neutron.update_quota tenant-id subnet=40 router=50
                                         network=10 floatingip=30 port=30

          Parameters

                 * tenant_id -- ID of tenant

                 * subnet -- Value of subnet quota (Optional)

                 * router -- Value of router quota (Optional)

                 * network -- Value of network quota (Optional)

                 * floatingip -- Value of floatingip quota (Optional)

                 * port -- Value of port quota (Optional)

                 * security_group -- Value of security group (Optional)

                 * security_group_rule  --  Value  of  security group rule
                   (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated quota

   salt.modules.neutron.update_router(router,                   name=None,
   admin_state_up=None, profile=None, **kwargs)
          Updates a router

          CLI Example:

             salt '*' neutron.update_router router_id name=new-router-name
                     admin_state_up=True

          Parameters

                 * router -- ID or name of router to update

                 * name -- Name of this router

                 * ext_network  --  ID  or  name  of  the external for the
                   gateway (Optional)

                 * admin_state_up -- Set admin state up to true or  false,
                   default: true (Optional)

                 * profile -- Profile to build on (Optional)

                 * kwargs --

          Returns
                 Value of updated router information

   salt.modules.neutron.update_security_group(security_group,   name=None,
   description=None, profile=None)
          Updates a security group

          CLI Example:

             salt '*' neutron.update_security_group security-group-name                 new-security-group-name

          Parameters

                 * security_group -- ID  or  name  of  security  group  to
                   update

                 * name -- Name of this security group (Optional)

                 * description -- Description of security group (Optional)

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated security group information

   salt.modules.neutron.update_subnet(subnet, name, profile=None)
          Updates a subnet

          CLI Example:

             salt '*' neutron.update_subnet subnet-name new-subnet-name

          Parameters

                 * subnet -- ID or name of subnet to update

                 * name -- Name of this subnet

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated subnet information

   salt.modules.neutron.update_vpnservice(vpnservice, desc, profile=None)
          Updates a VPN service

          CLI Example:

             salt '*' neutron.update_vpnservice vpnservice-name desc='VPN Service1'

          Parameters

                 * vpnservice -- ID or name of vpn service to update

                 * desc -- Set a description for the VPN service

                 * profile -- Profile to build on (Optional)

          Returns
                 Value of updated VPN service information

   salt.modules.nfs3
   Module for managing NFS version 3.

   salt.modules.nfs3.del_export(exports='/etc/exports', path=None)
          Remove an export

          CLI Example:

             salt '*' nfs.del_export /media/storage

   salt.modules.nfs3.list_exports(exports='/etc/exports')
          List configured exports

          CLI Example:

             salt '*' nfs.list_exports

   salt.modules.nftables
   Support for nftables

   salt.modules.nftables.append(table='filter',   chain=None,   rule=None,
   family='ipv4')
          Append a rule to the specified table & chain.

          This function accepts a rule  in  a  standard  nftables  command
          format,
                 starting  with  the chain. Trying to force users to adapt
                 to a new method of creating rules would be irritating  at
                 best, and we already have a parser that can handle it.

          CLI Example:

             salt '*' nftables.append filter input \
                 rule='input tcp dport 22 log accept'

             IPv6:
             salt '*' nftables.append filter input \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

   salt.modules.nftables.build_rule(table=None,  chain=None, command=None,
   position='', full=None, family='ipv4', **kwargs)
          Build a well-formatted nftables rule based on kwargs.   A  table
          and chain are not required, unless full is True.

          If  full  is  True,  then table, chain and command are required.
          command may be specified as either insert,  append,  or  delete.
          This  will  return  the nftables command, exactly as it would be
          used from the command line.

          If a position is required (as with insert or delete), it may  be
          specified as position. This will only be useful if full is True.

          If  connstate  is passed in, it will automatically be changed to
          state.

          CLI Examples:

             salt '*' nftables.build_rule match=state \
                 connstate=RELATED,ESTABLISHED jump=ACCEPT
             salt '*' nftables.build_rule filter input command=insert position=3 \
                 full=True match=state state=related,established jump=accept

             IPv6:
             salt '*' nftables.build_rule match=state \
                 connstate=related,established jump=accept \
                 family=ipv6
             salt '*' nftables.build_rule filter input command=insert position=3 \
                 full=True match=state state=related,established jump=accept \
                 family=ipv6

   salt.modules.nftables.check(table='filter',   chain=None,    rule=None,
   family='ipv4')
          Check for the existence of a rule in the table and chain

          This  function  accepts  a  rule  in a standard nftables command
          format,
                 starting with the chain. Trying to force users  to  adapt
                 to  a new method of creating rules would be irritating at
                 best, and we already have a parser that can handle it.

          CLI Example:

             salt '*' nftables.check filter input \
                 rule='input tcp dport 22 log accept'

             IPv6:
             salt '*' nftables.check filter input \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

   salt.modules.nftables.check_chain(table='filter',           chain=None,
   family='ipv4')
          New in version 2014.7.0.

          Check for the existence of a chain in the table

          CLI Example:

             salt '*' nftables.check_chain filter input

             IPv6:
             salt '*' nftables.check_chain filter input family=ipv6

   salt.modules.nftables.check_table(table=None, family='ipv4')
          Check for the existence of a table

          CLI Example:

             salt '*' nftables.check_table nat

   salt.modules.nftables.delete(table,      chain=None,     position=None,
   rule=None, family='ipv4')

          Delete a rule from  the  specified  table  &  chain,  specifying
          either the rule
                 in its entirety, or the rule's position in the chain.

          This  function  accepts  a  rule  in a standard nftables command
          format,
                 starting with the chain. Trying to force users  to  adapt
                 to  a new method of creating rules would be irritating at
                 best, and we already have a parser that can handle it.

          CLI Examples:

             salt '*' nftables.delete filter input position=3

             salt '*' nftables.delete filter input \
                 rule='input tcp dport 22 log accept'

             IPv6:
             salt '*' nftables.delete filter input position=3 family=ipv6

             salt '*' nftables.delete filter input \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

   salt.modules.nftables.delete_chain(table='filter',          chain=None,
   family='ipv4')
          New in version 2014.7.0.

          Delete the chain from the specified table.

          CLI Example:

             salt '*' nftables.delete_chain filter input

             salt '*' nftables.delete_chain filter foo

             IPv6:
             salt '*' nftables.delete_chain filter input family=ipv6

             salt '*' nftables.delete_chain filter foo family=ipv6

   salt.modules.nftables.delete_table(table, family='ipv4')
          New in version 2014.7.0.

          Create new custom table.

          CLI Example:

             salt '*' nftables.delete_table filter

             IPv6:
             salt '*' nftables.delete_table filter family=ipv6

   salt.modules.nftables.flush(table='filter', chain='', family='ipv4')
          Flush  the chain in the specified table, flush all chains in the
          specified table if chain is not specified.

          CLI Example:

             salt '*' nftables.flush filter

             salt '*' nftables.flush filter input

             IPv6:
             salt '*' nftables.flush filter input family=ipv6

   salt.modules.nftables.get_rule_handle(table='filter',       chain=None,
   rule=None, family='ipv4')
          Get the handle for a particular rule

          This  function  accepts  a  rule  in a standard nftables command
          format,
                 starting with the chain. Trying to force users  to  adapt
                 to  a new method of creating rules would be irritating at
                 best, and we already have a parser that can handle it.

          CLI Example:

             salt '*' nftables.get_rule_handle filter input \
                 rule='input tcp dport 22 log accept'

             IPv6:
             salt '*' nftables.get_rule_handle filter input \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

   salt.modules.nftables.get_rules(family='ipv4')
          Return a data structure of the current, in-memory rules

          CLI Example:

             salt '*' nftables.get_rules

             salt '*' nftables.get_rules family=ipv6

   salt.modules.nftables.get_saved_rules(conf_file=None, family='ipv4')
          Return a data structure of the rules in the conf file

          CLI Example:

             salt '*' nftables.get_saved_rules

   salt.modules.nftables.insert(table='filter', chain=None, position=None,
   rule=None, family='ipv4')
          Insert a rule into the specified table & chain, at the specified
          position.

          If position is not specified, rule will  be  inserted  in  first
          position.

          This  function  accepts  a  rule  in a standard nftables command
          format,
                 starting with the chain. Trying to force users  to  adapt
                 to  a new method of creating rules would be irritating at
                 best, and we already have a parser that can handle it.

          CLI Examples:

             salt '*' nftables.insert filter input \
                 rule='input tcp dport 22 log accept'

             salt '*' nftables.insert filter input position=3 \
                 rule='input tcp dport 22 log accept'

             IPv6:
             salt '*' nftables.insert filter input \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

             salt '*' nftables.insert filter input position=3 \
                 rule='input tcp dport 22 log accept' \
                 family=ipv6

   salt.modules.nftables.new_chain(table='filter',             chain=None,
   table_type=None, hook=None, priority=None, family='ipv4')
          New in version 2014.7.0.

          Create new chain to the specified table.

          CLI Example:

             salt '*' nftables.new_chain filter input

             salt '*' nftables.new_chain filter input \
                     table_type=filter hook=input priority=0

             salt '*' nftables.new_chain filter foo

             IPv6:
             salt '*' nftables.new_chain filter input family=ipv6

             salt '*' nftables.new_chain filter input \
                     table_type=filter hook=input priority=0 family=ipv6

             salt '*' nftables.new_chain filter foo family=ipv6

   salt.modules.nftables.new_table(table, family='ipv4')
          New in version 2014.7.0.

          Create new custom table.

          CLI Example:

             salt '*' nftables.new_table filter

             IPv6:
             salt '*' nftables.new_table filter family=ipv6

   salt.modules.nftables.save(filename=None, family='ipv4')
          Save the current in-memory rules to disk

          CLI Example:

             salt '*' nftables.save /etc/nftables

   salt.modules.nftables.version()
          Return version from nftables --version

          CLI Example:

             salt '*' nftables.version

   salt.modules.nginx
   Support for nginx

   salt.modules.nginx.build_info()
          Return server and build arguments

          CLI Example:

             salt '*' nginx.build_info

   salt.modules.nginx.configtest()
          test configuration and exit

          CLI Example:

             salt '*' nginx.configtest

   salt.modules.nginx.signal(signal=None)
          Signals nginx to start, reload, reopen or stop.

          CLI Example:

             salt '*' nginx.signal reload

   salt.modules.nginx.status(url='http://127.0.0.1/status')
          Return  the  data  from  an  Nginx  status page as a dictionary.
          http://wiki.nginx.org/HttpStubStatusModule

          url    The  URL   of   the   status   page.   Defaults   to   '
                 http://127.0.0.1/status'

          CLI Example:

             salt '*' nginx.status

   salt.modules.nginx.version()
          Return server version from nginx -v

          CLI Example:

             salt '*' nginx.version

   salt.modules.nova
   Module for handling OpenStack Nova calls

   depends

          * novaclient Python module

   configuration
          This  module is not usable until the user, password, tenant, and
          auth URL are specified either in a pillar  or  in  the  minion's
          config file.  For example:

             keystone.user: admin
             keystone.password: verybadpass
             keystone.tenant: admin
             keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
             # Optional
             keystone.region_name: 'RegionOne'

          If  configuration  for  multiple OpenStack accounts is required,
          they can be set up  as  different  configuration  profiles:  For
          example:

             openstack1:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'

             openstack2:
               keystone.user: admin
               keystone.password: verybadpass
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.2:5000/v2.0/'

          With  this configuration in place, any of the nova functions can
          make use of a configuration profile by declaring it  explicitly.
          For example:

             salt '*' nova.flavor_list profile=openstack1

   salt.modules.nova.boot(name,   flavor_id=0,  image_id=0,  profile=None,
   timeout=300)
          Boot (create) a new instance

          name   Name of the new instance (must be first)

          flavor_id
                 Unique integer ID for the flavor

          image_id
                 Unique integer ID for the image

          timeout
                 How long to wait, after creating the  instance,  for  the
                 provider  to  return  information  about  it (default 300
                 seconds).

                 New in version 2014.1.0.

          CLI Example:

             salt '*' nova.boot myinstance flavor_id=4596 image_id=2

          The flavor_id and image_id are  obtained  from  nova.flavor_list
          and nova.image_list

             salt '*' nova.flavor_list
             salt '*' nova.image_list

   salt.modules.nova.delete(instance_id, profile=None)
          Delete an instance

          instance_id
                 ID of the instance to be deleted

          CLI Example:

             salt '*' nova.delete 1138

   salt.modules.nova.flavor_create(name,   flavor_id=0,   ram=0,   disk=0,
   vcpus=1, profile=None)
          Add  a  flavor  to  nova  (nova  flavor-create).  The  following
          parameters are required:

          name   Name of the new flavor (must be first)

          flavor_id
                 Unique integer ID for the new flavor

          ram    Memory size in MB

          disk   Disk size in GB

          vcpus  Number of vcpus

          CLI Example:

             salt '*' nova.flavor_create myflavor flavor_id=6                 ram=4096 disk=10 vcpus=1

   salt.modules.nova.flavor_delete(flavor_id, profile=None)
          Delete a flavor from nova by id (nova flavor-delete)

          CLI Example:

             salt '*' nova.flavor_delete 7

   salt.modules.nova.flavor_list(profile=None)
          Return a list of available flavors (nova flavor-list)

          CLI Example:

             salt '*' nova.flavor_list

   salt.modules.nova.image_list(name=None, profile=None)
          Return  a  list  of  available  images  (nova images-list + nova
          image-show) If a name is  provided,  only  that  image  will  be
          displayed.

          CLI Examples:

             salt '*' nova.image_list
             salt '*' nova.image_list myimage

   salt.modules.nova.image_meta_delete(image_id=None,           name=None,
   keys=None, profile=None)
          Delete a key=value pair from the metadata  for  an  image  (nova
          image-meta set)

          CLI Examples:

             salt '*' nova.image_meta_delete                 6f52b2ff-0b31-4d84-8fd1-af45b84824f6 keys=cheese
             salt '*' nova.image_meta_delete name=myimage keys=salad,beans

   salt.modules.nova.image_meta_set(image_id=None,              name=None,
   profile=None, **kwargs)
          Sets a key=value  pair  in  the  metadata  for  an  image  (nova
          image-meta set)

          CLI Examples:

             salt '*' nova.image_meta_set 6f52b2ff-0b31-4d84-8fd1-af45b84824f6                 cheese=gruyere
             salt '*' nova.image_meta_set name=myimage salad=pasta beans=baked

   salt.modules.nova.keypair_add(name,      pubfile=None,     pubkey=None,
   profile=None)
          Add a keypair to nova (nova keypair-add)

          CLI Examples:

             salt '*' nova.keypair_add mykey pubfile='/home/myuser/.ssh/id_rsa.pub'
             salt '*' nova.keypair_add mykey pubkey='ssh-rsa <key> myuser@mybox'

   salt.modules.nova.keypair_delete(name, profile=None)
          Add a keypair to nova (nova keypair-delete)

          CLI Example:

             salt '*' nova.keypair_delete mykey'

   salt.modules.nova.keypair_list(profile=None)
          Return a list of available keypairs (nova keypair-list)

          CLI Example:

             salt '*' nova.keypair_list

   salt.modules.nova.list(profile=None)
          To maintain the feel of the nova  command  line,  this  function
          simply calls the server_list function.

          CLI Example:

             salt '*' nova.list

   salt.modules.nova.lock(instance_id, profile=None)
          Lock an instance

          instance_id
                 ID of the instance to be locked

          CLI Example:

             salt '*' nova.lock 1138

   salt.modules.nova.resume(instance_id, profile=None)
          Resume an instance

          instance_id
                 ID of the instance to be resumed

          CLI Example:

             salt '*' nova.resume 1138

   salt.modules.nova.secgroup_create(name, description, profile=None)
          Add a secgroup to nova (nova secgroup-create)

          CLI Example:

             salt '*' nova.secgroup_create mygroup 'This is my security group'

   salt.modules.nova.secgroup_delete(name, profile=None)
          Delete a secgroup to nova (nova secgroup-delete)

          CLI Example:

             salt '*' nova.secgroup_delete mygroup

   salt.modules.nova.secgroup_list(profile=None)
          Return a list of available security groups (nova items-list)

          CLI Example:

             salt '*' nova.secgroup_list

   salt.modules.nova.server_by_name(name, profile=None)
          Return information about a server

          name   Server Name

          CLI Example:

             salt '*' nova.server_by_name myserver profile=openstack

   salt.modules.nova.server_list(profile=None)
          Return list of active servers

          CLI Example:

             salt '*' nova.server_list

   salt.modules.nova.server_list_detailed(profile=None)
          Return detailed list of active servers

          CLI Example:

             salt '*' nova.server_list_detailed

   salt.modules.nova.server_show(server_id, profile=None)
          Return detailed information for an active server

          CLI Example:

             salt '*' nova.server_show <server_id>

   salt.modules.nova.show(server_id, profile=None)
          To  maintain  the  feel  of the nova command line, this function
          simply calls the server_show function.

          CLI Example:

             salt '*' nova.show

   salt.modules.nova.suspend(instance_id, profile=None)
          Suspend an instance

          instance_id
                 ID of the instance to be suspended

          CLI Example:

             salt '*' nova.suspend 1138

   salt.modules.nova.volume_attach(name, server_name,  device='/dev/xvdb',
   profile=None, timeout=300)
          Attach a block storage volume

          name   Name of the new volume to attach

          server_name
                 Name of the server to attach to

          device Name of the device on the server

          profile
                 Profile to build on

          CLI Example:

             salt '*' nova.volume_attach myblock slice.example.com profile=openstack
             salt '*' nova.volume_attach myblock server.example.com                 device='/dev/xvdb' profile=openstack

   salt.modules.nova.volume_create(name,      size=100,     snapshot=None,
   voltype=None, profile=None)
          Create a block storage volume

          name   Name of the new volume (must be first)

          size   Volume size

          snapshot
                 Block storage snapshot id

          voltype
                 Type of storage

          profile
                 Profile to build on

          CLI Example:

             salt '*' nova.volume_create myblock size=300 profile=openstack

   salt.modules.nova.volume_delete(name, profile=None)
          Destroy the volume

          name   Name of the volume

          profile
                 Profile to build on

          CLI Example:

             salt '*' nova.volume_delete myblock profile=openstack

   salt.modules.nova.volume_detach(name, profile=None, timeout=300)
          Attach a block storage volume

          name   Name of the new volume to attach

          server_name
                 Name of the server to detach from

          profile
                 Profile to build on

          CLI Example:

             salt '*' nova.volume_detach myblock profile=openstack

   salt.modules.nova.volume_list(search_opts=None, profile=None)
          List storage volumes

          search_opts
                 Dictionary of search options

          profile
                 Profile to use

          CLI Example:

             salt '*' nova.volume_list                 search_opts='{"display_name": "myblock"}'                 profile=openstack

   salt.modules.nova.volume_show(name, profile=None)
          Create a block storage volume

          name   Name of the volume

          profile
                 Profile to use

          CLI Example:

             salt '*' nova.volume_show myblock profile=openstack

   salt.modules.npm
   Manage and query NPM packages.

   salt.modules.npm.cache_clean(path=None, runas=None, env=None)
          Clean cached NPM packages.

          If no path for a specific package is provided the  entire  cache
          will be cleared.

          path   The  cache subpath to delete, or None to clear the entire
                 cache

          runas  The user to run NPM with

          env    Environment variables to set when invoking npm. Uses  the
                 same env format as the cmd.run execution function.

          CLI Example:

             salt '*' npm.cache_clean

   salt.modules.npm.cache_list(path=None, runas=None, env=None)
          List NPM cached packages.

          If no path for a specific package is provided this will list all
          the cached packages.

          path   The cache subpath to list, or None  to  list  the  entire
                 cache

          runas  The user to run NPM with

          env    Environment  variables to set when invoking npm. Uses the
                 same env format as the cmd.run execution function.

          CLI Example:

             salt '*' npm.cache_clean

   salt.modules.npm.cache_path(runas=None, env=None)
          List path of the NPM cache directory.

          runas  The user to run NPM with

          env    Environment variables to set when invoking npm. Uses  the
                 same env format as the cmd.run execution function.

          CLI Example:

             salt '*' npm.cache_path

   salt.modules.npm.install(pkg=None,   pkgs=None,  dir=None,  runas=None,
   registry=None, env=None, dry_run=False, silent=True)
          Install an NPM package.

          If no directory is specified,  the  package  will  be  installed
          globally.  If  no  package  is specified, the dependencies (from
          package.json) of the package in  the  given  directory  will  be
          installed.

          pkg    A package name in any format accepted by NPM, including a
                 version identifier

          pkgs   A list of package names in the same format  as  the  name
                 parameter

                 New in version 2014.7.0.

          dir    The  target directory in which to install the package, or
                 None for global installation

          runas  The user to run NPM with

          registry
                 The NPM registry to install the package from.

                 New in version 2014.7.0.

          env    Environment variables to set when invoking npm. Uses  the
                 same env format as the cmd.run execution function.

                 New in version 2014.7.0.

          silent Whether or not to run NPM install with --silent flag.

                 New in version 2016.3.0.

          dry_run
                 Whether or not to run NPM install with --dry-run flag.

                 New in version 2015.8.4.

          silent Whether or not to run NPM install with --silent flag.

                 New in version 2015.8.5.

          CLI Example:

             salt '*' npm.install coffee-script

             salt '*' npm.install [email protected]

   salt.modules.npm.list(pkg=None, dir=None, runas=None, env=None)
          List installed NPM packages.

          If  no  directory  is  specified,  this  will return the list of
          globally- installed packages.

          pkg    Limit package listing by name

          dir    The directory whose packages will be listed, or None  for
                 global installation

          runas  The user to run NPM with

                 New in version 2014.7.0.

          env    Environment  variables to set when invoking npm. Uses the
                 same env format as the cmd.run execution function.

                 New in version 2014.7.0.

          CLI Example:

             salt '*' npm.list

   salt.modules.npm.uninstall(pkg, dir=None, runas=None, env=None)
          Uninstall an NPM package.

          If no directory is specified, the package  will  be  uninstalled
          globally.

          pkg    A package name in any format accepted by NPM

          dir    The target directory from which to uninstall the package,
                 or None for global installation

          runas  The user to run NPM with

          env    Environment variables to set when invoking npm. Uses  the
                 same env format as the cmd.run execution function.

                 New in version 2015.5.3.

          CLI Example:

             salt '*' npm.uninstall coffee-script

   salt.modules.nspawn
   Manage nspawn containers

   New in version 2015.8.0.

   systemd-nspawn(1)  is  a  tool  used  to  manage  lightweight namespace
   containers. This execution module provides several  functions  to  help
   manage these containers.

   Minions   running   systemd   >=  219  will  place  new  containers  in
   /var/lib/machines, while those running systemd < 219 will place them in
   /var/lib/container.

   salt.modules.nspawn.bootstrap_container(name, dist=None, version=None)
          Bootstrap  a container from package servers, if dist is None the
          os the minion is running  as  will  be  created,  otherwise  the
          needed  bootstrapping  tools  will  need  to be available on the
          host.

          CLI Example:

             salt myminion nspawn.bootstrap_container <name>

   salt.modules.nspawn.bootstrap_salt(name, config=None, approve_key=True,
   install=True,    pub_key=None,    priv_key=None,    bootstrap_url=None,
   force_install=False, unconditional_install=False, bootstrap_delay=None,
   bootstrap_args=None, bootstrap_shell=None)
          Bootstrap  a container from package servers, if dist is None the
          os the minion is running  as  will  be  created,  otherwise  the
          needed  bootstrapping  tools  will  need  to be available on the
          host.

          CLI Example:

             salt '*' nspawn.bootstrap_salt arch1

   salt.modules.nspawn.copy_to(name, *args, **kwargs)
          Copy a file from the host into a container

          name   Container name

          source File to be copied to the container

          dest   Destination on the container. Must be an absolute path.

          overwrite
                 False Unless this option is set to True, then if  a  file
                 exists at the location specified by the dest argument, an
                 error will be raised.

          makedirs : False
             Create the parent directory on the container if it  does  not
             already exist.

          CLI Example:

             salt 'minion' nspawn.copy_to /tmp/foo /root/foo

   salt.modules.nspawn.disable(name, *args, **kwargs)
          Set the named container to not be launched at boot

          CLI Example:

             salt myminion nspawn.enable <name>

   salt.modules.nspawn.enable(name, *args, **kwargs)
          Set the named container to be launched at boot

          CLI Example:

             salt myminion nspawn.enable <name>

   salt.modules.nspawn.exists(name)
          Returns true if the named container exists

          CLI Example:

             salt myminion nspawn.exists <name>

   salt.modules.nspawn.info(name, **kwargs)
          Return info about a container

          NOTE:
             The  container  must  be  running  for  machinectl  to gather
             information about it. If the container is stopped, then  this
             function will start it.

          start  False  If  True,  then  the  container will be started to
                 retrieve the info. A Started key will be  in  the  return
                 data if the container was started.

          CLI Example:

             salt myminion nspawn.info arch1
             salt myminion nspawn.info arch1 force_start=False

   salt.modules.nspawn.list_all()
          Lists all nspawn containers

          CLI Example:

             salt myminion nspawn.list_all

   salt.modules.nspawn.list_running()
          Lists running nspawn containers

          NOTE:
             nspawn.list also works to list running containers

          CLI Example:

             salt myminion nspawn.list_running
             salt myminion nspawn.list

   salt.modules.nspawn.list_stopped()
          Lists stopped nspawn containers

          CLI Example:

             salt myminion nspawn.list_stopped

   salt.modules.nspawn.pid(name, *args, **kwargs)
          Returns the PID of a container

          name   Container name

          CLI Example:

             salt myminion nspawn.pid arch1

   salt.modules.nspawn.poweroff(name)
          Issue  a clean shutdown to the container.  Equivalent to running
          machinectl poweroff on the named container.

          For convenience,  running  nspawn.stop``(as  shown  in  the  CLI
          examples below) is equivalent to running ``nspawn.poweroff.

          NOTE:
             machinectl  poweroff  is only supported in systemd >= 219. On
             earlier systemd versions, running this function  will  simply
             issue a clean shutdown via systemctl.

          CLI Examples:

             salt myminion nspawn.poweroff arch1
             salt myminion nspawn.stop arch1

   salt.modules.nspawn.pull_dkr(url, name, index)
          Execute a machinectl pull-dkr to download a docker image and add
          it to /var/lib/machines as a new container.

          NOTE:
             Requires systemd >= 219

          url    URL from which to download the container

          name   Name for the new container

          index  URL of the Docker index server from which to  pull  (must
                 be an http:// or https:// URL).

          CLI Examples:

             salt myminion nspawn.pull_dkr centos/centos6 cent6 index=https://get.docker.com
             salt myminion nspawn.pull_docker centos/centos6 cent6 index=https://get.docker.com

   salt.modules.nspawn.pull_raw(url, name, verify=False)
          Execute  a  machinectl pull-raw to download a .qcow2 or raw disk
          image, and add it to /var/lib/machines as a new container.

          NOTE:
             Requires systemd >= 219

          url    URL from which to download the container

          name   Name for the new container

          verify False Perform signature or checksum verification  on  the
                 container. See the machinectl(1) man page (section titled
                 "Image  Transfer  Commands")  for  more  information   on
                 requirements for image verification. To perform signature
                 verification,   use   verify=signature.   For    checksum
                 verification,   use   verify=checksum.   By  default,  no
                 verification will be performed.

          CLI Examples:

             salt myminion nspawn.pull_raw http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz fedora21

   salt.modules.nspawn.pull_tar(url, name, verify=False)
          Execute a machinectl  pull-raw  to  download  a  .tar  container
          image, and add it to /var/lib/machines as a new container.

          NOTE:
             Requires systemd >= 219

          url    URL from which to download the container

          name   Name for the new container

          verify False  Perform  signature or checksum verification on the
                 container. See the machinectl(1) man page (section titled
                 "Image   Transfer  Commands")  for  more  information  on
                 requirements for image verification. To perform signature
                 verification,    use   verify=signature.   For   checksum
                 verification,  use  verify=checksum.   By   default,   no
                 verification will be performed.

          CLI Examples:

             salt myminion nspawn.pull_tar http://foo.domain.tld/containers/archlinux-2015.02.01.tar.gz arch2

   salt.modules.nspawn.reboot(name, *args, **kwargs)
          Reboot  the  container  by sending a SIGINT to its init process.
          Equivalent to running machinectl reboot on the named container.

          For convenience, running nspawn.restart (as  shown  in  the  CLI
          examples below) is equivalent to running nspawn.reboot.

          NOTE:
             machinectl  reboot  is  only  supported in systemd >= 219. On
             earlier systemd versions, running this function will  instead
             restart the container via systemctl.

          CLI Examples:

             salt myminion nspawn.reboot arch1
             salt myminion nspawn.restart arch1

   salt.modules.nspawn.remove(name, *args, **kwargs)
          Remove the named container

          WARNING:
             This  function  will  remove  all  data  associated  with the
             container. It will not, however, remove the btrfs  subvolumes
             created   by   pulling   container  images  (nspawn.pull_raw,
             nspawn.pull_tar, nspawn.pull_dkr).

          stop   False If True, the container will be destroyed even if it
                 is running/frozen.

          CLI Examples:

             salt '*' nspawn.remove foo
             salt '*' nspawn.remove foo stop=True

   salt.modules.nspawn.retcode(name,          cmd,         no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug',       use_vt=False,      ignore_retcode=False,
   keep_env=None)
          Run cmd.retcode within a container

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True After running the command, return the  container  to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console. Assumes output=all.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion nspawn.retcode mycontainer 'ip addr show'

   salt.modules.nspawn.run(name, cmd, no_start=False, preserve_state=True,
   stdin=None,  python_shell=True,  output_loglevel='debug', use_vt=False,
   ignore_retcode=False, keep_env=None)
          Run cmd.run within a container

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True After running the command, return the  container  to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion nspawn.run mycontainer 'ifconfig -a'

   salt.modules.nspawn.run_all(name,         cmd,          no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug',      use_vt=False,       ignore_retcode=False,
   keep_env=None)
          Run cmd.run_all within a container

          NOTE:
             While  the  command  is  run  within  the  container,  it  is
             initiated from the host. Therefore, the  PID  in  the  return
             dict is from the host, not from the container.

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True  After  running the command, return the container to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console. Assumes output=all.

          keep_env
                 None If not passed, only a sane default PATH  environment
                 variable  will be set. If True, all environment variables
                 from the container's host  will  be  kept.  Otherwise,  a
                 comma-separated  list  (or  Python  list)  of environment
                 variable names  can  be  passed,  and  those  environment
                 variables will be kept.

          CLI Example:

             salt myminion nspawn.run_all mycontainer 'ip addr show'

   salt.modules.nspawn.run_stderr(name,        cmd,        no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug',       use_vt=False,      ignore_retcode=False,
   keep_env=None)
          Run cmd.run_stderr within a container

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True After running the command, return the  container  to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug  Level at which to log the output from the command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console. Assumes output=all.

          keep_env
                 None  If not passed, only a sane default PATH environment
                 variable will be set. If True, all environment  variables
                 from  the  container's  host  will  be kept. Otherwise, a
                 comma-separated list  (or  Python  list)  of  environment
                 variable  names  can  be  passed,  and  those environment
                 variables will be kept.

          CLI Example:

             salt myminion nspawn.run_stderr mycontainer 'ip addr show'

   salt.modules.nspawn.run_stdout(name,        cmd,        no_start=False,
   preserve_state=True,           stdin=None,           python_shell=True,
   output_loglevel='debug',      use_vt=False,       ignore_retcode=False,
   keep_env=None)
          Run cmd.run_stdout within a container

          name   Name of the container in which to run the command

          cmd    Command to run

          no_start
                 False If the container is not running, don't start it

          preserve_state
                 True  After  running the command, return the container to
                 its previous state

          stdin  None Standard input to be used for the command

          output_loglevel
                 debug Level at which to log the output from the  command.
                 Set to quiet to suppress logging.

          use_vt False  Use  SaltStack's  utils.vt  to  stream  output  to
                 console. Assumes output=all.

          keep_env
                 None If not passed, only a sane default PATH  environment
                 variable  will be set. If True, all environment variables
                 from the container's host  will  be  kept.  Otherwise,  a
                 comma-separated  list  (or  Python  list)  of environment
                 variable names  can  be  passed,  and  those  environment
                 variables will be kept.

          CLI Example:

             salt myminion nspawn.run_stdout mycontainer 'ifconfig -a'

   salt.modules.nspawn.start(name, *args, **kwargs)
          Start the named container

          CLI Example:

             salt myminion nspawn.start <name>

   salt.modules.nspawn.state(name, *args, **kwargs)
          Return state of container (running or stopped)

          CLI Example:

             salt myminion nspawn.state <name>

   salt.modules.nspawn.terminate(name)
          Kill  all  processes  in  the  container without issuing a clean
          shutdown.  Equivalent to running  machinectl  terminate  on  the
          named container.

          For  convenience,  running nspawn.stop and passing kill=True (as
          shown in the  CLI  examples  below)  is  equivalent  to  running
          nspawn.terminate.

          NOTE:
             machinectl  terminate is only supported in systemd >= 219. On
             earlier systemd versions, running this function  will  simply
             issue a clean shutdown via systemctl.

          CLI Examples:

             salt myminion nspawn.terminate arch1
             salt myminion nspawn.stop arch1 kill=True

   salt.modules.nxos module
   Execution module for Cisco NX OS Switches Proxy minions

   New in version 2016.11.0.

   For  documentation  on  setting  up  the  nxos proxy minion look in the
   documentation for salt.proxy.nxos.

   salt.modules.nxos.cmd(command, *args, **kwargs)
          run commands from __proxy__ salt.proxy.nxos

          command
                 function from salt.proxy.nxos to run

          args   positional args to pass to command function

          kwargs key word arguments to pass to command function

             salt '*' nxos.cmd sendline 'show ver'
             salt '*' nxos.cmd show_run
             salt '*' nxos.cmd check_password username=admin password='$5$lkjsdfoi$blahblahblah' encrypted=True

   salt.modules.nxos.system_info()
          Return system information for grains of the NX OS proxy minion

             salt '*' nxos.system_info

   salt.modules.omapi
   This module interacts with an ISC DHCP Server via OMAPI.  server_ip and
   server_port params may be set in the minion config or pillar:

      omapi.server_ip: 127.0.0.1
      omapi.server_port: 7991

   depends
          pypureomapi Python module

   salt.modules.omapi.add_host(mac,    name=None,   ip=None,   ddns=False,
   group=None, supersede_host=False)
          Add a host object for the given mac.

          CLI Example:

             salt dhcp-server omapi.add_host ab:ab:ab:ab:ab:ab name=host1

          Add ddns-hostname and a fixed-ip statements:

             salt dhcp-server omapi.add_host ab:ab:ab:ab:ab:ab name=host1 ip=10.1.1.1 ddns=true

   salt.modules.omapi.delete_host(mac=None, name=None)
          Delete the host with the given mac or name.

          CLI Examples:

             salt dhcp-server omapi.delete_host name=host1
             salt dhcp-server omapi.delete_host mac=ab:ab:ab:ab:ab:ab

   salt.modules.openbsd_sysctl
   Module for viewing and modifying OpenBSD sysctl parameters

   salt.modules.openbsd_sysctl.assign(name, value)
          Assign a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.assign net.inet.ip.forwarding 1

   salt.modules.openbsd_sysctl.get(name)
          Return a single sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.get hw.physmem

   salt.modules.openbsd_sysctl.persist(name,                        value,
   config='/etc/sysctl.conf')
          Assign and persist a simple sysctl parameter for this minion

          CLI Example:

             salt '*' sysctl.persist net.inet.ip.forwarding 1

   salt.modules.openbsd_sysctl.show(config_file=False)
          Return a list of sysctl parameters for this minion

          CLI Example:

             salt '*' sysctl.show

   salt.modules.openbsdpkg
   Package support for OpenBSD

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   salt.modules.openbsdpkg.install(name=None,   pkgs=None,   sources=None,
   **kwargs)
          Install the passed package

          Return a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example, Install one package:

             salt '*' pkg.install <package name>

          CLI Example, Install more than one package:

             salt '*' pkg.install pkgs='["<package name>", "<package name>"]'

          CLI Example, Install more than  one  package  from  a  alternate
          source (e.g. salt file-server, HTTP, FTP, local filesystem):

             salt '*' pkg.install sources='[{"<pkg name>": "salt://pkgs/<pkg filename>"}]'

   salt.modules.openbsdpkg.latest_version(*names, **kwargs)
          The available version of the package in the repository

          CLI Example:

             salt '*' pkg.latest_version <package name>

   salt.modules.openbsdpkg.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.openbsdpkg.purge(name=None, pkgs=None, **kwargs)
          Package  purges are not supported, this function is identical to
          remove().

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.openbsdpkg.remove(name=None, pkgs=None, **kwargs)
          Remove a single package with pkg_delete

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.openbsdpkg.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.openbsdrcctl
   The rcctl service module for OpenBSD

   salt.modules.openbsdrcctl.available(name)
          Return True if the named service is available.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.openbsdrcctl.disable(name, **kwargs)
          Disable the named service to not start at boot.

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.openbsdrcctl.disabled(name)
          Return True if the named service  is  disabled  at  boot,  False
          otherwise.

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.openbsdrcctl.enable(name, **kwargs)
          Enable the named service to start at boot.

          flags  None Set optional flags to run the service with.

          service.flags can be used to change the default flags.

          CLI Example:

             salt '*' service.enable <service name>
             salt '*' service.enable <service name> flags=<flags>

   salt.modules.openbsdrcctl.enabled(name, **kwargs)
          Return  True  if  the  named  service is enabled at boot and the
          provided flags match the configured ones (if any). Return  False
          otherwise.

          name   Service name

          CLI Example:

             salt '*' service.enabled <service name>
             salt '*' service.enabled <service name> flags=<flags>

   salt.modules.openbsdrcctl.get_all()
          Return all installed services.

          CLI Example:

             salt '*' service.get_all

   salt.modules.openbsdrcctl.get_disabled()
          Return  what  services are available but not enabled to start at
          boot.

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.openbsdrcctl.get_enabled()
          Return what services are set to run on boot.

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.openbsdrcctl.missing(name)
          The inverse of service.available.   Return  True  if  the  named
          service is not available.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.openbsdrcctl.reload(name)
          Reload the named service.

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.openbsdrcctl.restart(name)
          Restart the named service.

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.openbsdrcctl.start(name)
          Start the named service.

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.openbsdrcctl.status(name, sig=None)
          Return  the  status  for  a  service, returns a bool whether the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.openbsdrcctl.stop(name)
          Stop the named service.

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.openbsdservice
   The service module for OpenBSD

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   salt.modules.openbsdservice.available(name)
          New in version 2014.7.0.

          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.openbsdservice.disabled(name)
          New in version 2014.7.0.

          Return True if the named service is disabled, false otherwise

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.openbsdservice.enabled(name, **kwargs)
          New in version 2014.7.0.

          Return True if the named service is enabled, false otherwise

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.openbsdservice.get_all()
          New in version 2014.7.0.

          Return all available boot services

          CLI Example:

             salt '*' service.get_all

   salt.modules.openbsdservice.get_disabled()
          New in version 2014.7.0.

          Return a set of services that are installed but disabled

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.openbsdservice.get_enabled()
          New in version 2014.7.0.

          Return a list of service that are enabled on boot

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.openbsdservice.missing(name)
          New in version 2014.7.0.

          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.openbsdservice.reload(name)
          New in version 2014.7.0.

          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.openbsdservice.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.openbsdservice.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.openbsdservice.status(name, sig=None)
          Return the status for a service,  returns  a  bool  whether  the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.openbsdservice.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.openstack_config
   Modify, retrieve, or delete values from OpenStack configuration files.

   maintainer
          Jeffrey C. Ollie <[email protected]>

   maturity
          new

   depends

   platform
          linux

   salt.modules.openstack_config.delete(filename, section, parameter)
          Delete a value from an OpenStack configuration file.

          filename
                 The full path to the configuration file

          section
                 The section from which to delete the parameter

          parameter
                 The parameter to delete

          CLI Example:

             salt-call openstack_config.delete /etc/keystone/keystone.conf sql connection

   salt.modules.openstack_config.get(filename, section, parameter)
          Get a value from an OpenStack configuration file.

          filename
                 The full path to the configuration file

          section
                 The section from which to search for the parameter

          parameter
                 The parameter to return

          CLI Example:

             salt-call openstack_config.get /etc/keystone/keystone.conf sql connection

   salt.modules.openstack_config.set(filename, section, parameter, value)
          Set a value in an OpenStack configuration file.

          filename
                 The full path to the configuration file

          section
                 The section in which the parameter will be set

          parameter
                 The parameter to change

          value  The value to set

          CLI Example:

             salt-call openstack_config.set /etc/keystone/keystone.conf sql connection foo

   salt.modules.openvswitch module
   Support for Open vSwitch - module with basic Open vSwitch commands.

   Suitable for setting up Openstack Neutron.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.modules.openvswitch.bridge_create(br, may_exist=True)
          Creates a new bridge.

          Parameters

                 * br -- A string - bridge name

                 * may_exist  --  Bool,  if False - attempting to create a
                   bridge that exists returns False.

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.bridge_create br0

   salt.modules.openvswitch.bridge_delete(br, if_exists=True)
          Deletes bridge and all of  its  ports.

          Parameters

                 * br -- A string - bridge name

                 * if_exists -- Bool, if False - attempting  to  delete  a
                   bridge that does not exist returns False.

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.bridge_delete br0

   salt.modules.openvswitch.bridge_exists(br)
          Tests whether bridge exists as a real or fake  bridge.

          Returns
                 True if Bridge exists, else False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.bridge_exists br0

   salt.modules.openvswitch.bridge_list()
          Lists all existing real and fake bridges.

          Returns
                 List of bridges (or empty list), False on failure.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.bridge_list

   salt.modules.openvswitch.interface_get_options(port)
          Port's interface's optional parameters.

          Parameters
                 port -- A string - port name.

          Returns
                 String   containing   optional   parameters   of   port's
                 interface, False on failure.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.interface_get_options tap0

   salt.modules.openvswitch.interface_get_type(port)
          Type of port's interface.

          Parameters
                 port -- A string - port name.

          Returns
                 String - type of interface  or  empty  string,  False  on
                 failure.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.interface_get_type tap0

   salt.modules.openvswitch.port_add(br, port, may_exist=False)
          Creates on bridge a new port named port.

          Returns
                 True on success, else False.

          Parameters

                 * br -- A string - bridge name

                 * port -- A string - port name

                 * may_exist  --  Bool,  if False - attempting to create a
                   port that exists returns False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.port_add br0 8080

   salt.modules.openvswitch.port_create_gre(br, port, id, remote)
          Generic Routing  Encapsulation  -  creates  GRE  tunnel  between
          endpoints.

          Parameters

                 * br -- A string - bridge name.

                 * port -- A string - port name.

                 * id  --  An  integer  - unsigned 32-bit number, tunnel's
                   key.

                 * remote -- A string - remote endpoint's IP address.

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt   '*'   openvswitch.port_create_gre   br0   gre1    5001
             192.168.1.10

   salt.modules.openvswitch.port_create_vlan(br, port, id)
          Isolate VM traffic using VLANs.

          Parameters

                 * br -- A string - bridge name.

                 * port -- A string - port name.

                 * id  --  An  integer  in  the  valid  range  0  to  4095
                   (inclusive), name of VLAN.

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.port_create_vlan br0 tap0 100

   salt.modules.openvswitch.port_create_vxlan(br,   port,   id,    remote,
   dst_port=None)
          Virtual  eXtensible  Local  Area  Network - creates VXLAN tunnel
          between endpoints.

          Parameters

                 * br -- A string - bridge name.

                 * port -- A string - port name.

                 * id -- An integer -  unsigned  64-bit  number,  tunnel's
                   key.

                 * remote -- A string - remote endpoint's IP address.

                 * dst_port  --  An  integer  -  port to use when creating
                   tunnelport in the switch.

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt   '*'   openvswitch.port_create_vxlan   br0   vx1   5001
             192.168.1.10 8472

   salt.modules.openvswitch.port_get_tag(port)
          Lists tags of the port.

          Parameters
                 port -- A string - port name.

          Returns
                 List of tags (or empty list), False on failure.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.port_get_tag tap0

   salt.modules.openvswitch.port_list(br)
          Lists all of the ports within bridge.

          Parameters
                 br -- A string - bridge name.

          Returns
                 List of bridges (or empty list), False on failure.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.port_list br0

   salt.modules.openvswitch.port_remove(br, port, if_exists=True)
             Deletes port.

          Parameters

                 * br  --  A string - bridge name (If bridge is None, port
                   is removed from  whatever bridge contains it)

                 * port -- A string - port name.

                 * if_exists -- Bool, if False - attempting  to  delete  a
                   por that  does  not exist returns False. (Default True)

          Returns
                 True on success, else False.

          New in version 2016.3.0.

          CLI Example:
             salt '*' openvswitch.port_remove br0 8080

   salt.modules.opkg module
   Support for Opkg

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   NOTE:
      For  version  comparison  support,  the  opkg-utils  package must be
      installed.

   salt.modules.opkg.available_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.opkg.del_repo(alias)
          Delete a repo from /etc/opkg/
          *
          .conf

          If  the  file does not contain any other repo configuration, the
          file itself will be deleted.

          CLI Examples:

             salt '*' pkg.del_repo alias

   salt.modules.opkg.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying  any  packages  will return a list of _every_ file on
          the system's package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.opkg.file_list(*packages)
          List the files that belong to  a  package.  Not  specifying  any
          packages  will  return  a  list  of _every_ file on the system's
          package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.opkg.get_repo(alias)
          Display a repo from the /etc/opkg/
          *
          .conf

          CLI Examples:

             salt '*' pkg.get_repo alias

   salt.modules.opkg.hold(name=None, pkgs=None, sources=None, **kwargs)
          Set package in 'hold' state, meaning it will not be upgraded.

          name   The name of the package, e.g., 'tmux'

                 CLI Example:

                    salt '*' pkg.hold <package name>

          pkgs   A list of packages to hold. Must be passed  as  a  python
                 list.

                 CLI Example:

                    salt '*' pkg.hold pkgs='["foo", "bar"]'

   salt.modules.opkg.install(name=None,      refresh=False,     pkgs=None,
   sources=None, **kwargs)
          Install the passed package, add refresh=True to update the  opkg
          database.

          name   The  name  of the package to be installed. Note that this
                 parameter is ignored if either  "pkgs"  or  "sources"  is
                 passed.  Additionally,  please  note that this option can
                 only  be  used  to  install  packages  from  a   software
                 repository.  To  install a package file manually, use the
                 "sources" option.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 Whether or not to refresh  the  package  database  before
                 installing.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must be passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo", "bar"]'

          sources
                 A list of IPK packages to install. Must be  passed  as  a
                 list of dicts, with the keys being package names, and the
                 values being the source URI or local path to the package.
                 Dependencies  are  automatically  resolved  and marked as
                 auto-installed.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.deb"},{"bar": "salt://bar.deb"}]'

          install_recommends
                 Whether to install the packages  marked  as  recommended.
                 Default is True.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.opkg.latest_version(*names, **kwargs)
          Return  the  latest  version  of the named package available for
          upgrade or installation.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          If  the  latest version of a given package is already installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.opkg.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs
             salt '*' pkg.list_pkgs versions_as_list=True

   salt.modules.opkg.list_repos()
          Lists all repos on /etc/opkg/
          *
          .conf

          CLI Example:

             salt '*' pkg.list_repos

   salt.modules.opkg.list_upgrades(refresh=True)
          List all available package upgrades.

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.opkg.mod_repo(alias, **kwargs)
          Modify one or more values for a repo.   If  the  repo  does  not
          exist, it will be created, so long as uri is defined.

          The following options are available to modify a repo definition:

          alias  alias by which opkg refers to the repo.

          uri    the URI to the repo.

          compressed
                 defines (True or False) if the index file is compressed

          enabled
                 enable  or  disable (True or False) repository but do not
                 remove if disabled.

          refresh
                 enable or disable (True or  False)  auto-refresh  of  the
                 repositories

          CLI Examples:

             salt '*' pkg.mod_repo alias uri=http://new/uri
             salt '*' pkg.mod_repo alias enabled=False

   salt.modules.opkg.owner(*paths)
          Return the name of the package that owns the file. Multiple file
          paths      can      be      passed.       Like       pkg.version
          <salt.modules.opkg.version, if a single path is passed, a string
          will be returned, and if multiple paths are passed, a dictionary
          of file/package name pairs will be returned.

          If  the file is not owned by a package, or is not present on the
          minion, then an empty string will be returned for that path.

          CLI Example:
             salt '*'  pkg.owner  /usr/bin/apachectl  salt  '*'  pkg.owner
             /usr/bin/apachectl /usr/bin/basename

   salt.modules.opkg.purge(name=None, pkgs=None, **kwargs)
          Package  purges  are  not  supported  by  opkg, this function is
          identical to pkg.remove.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.opkg.refresh_db()
          Updates  the  opkg  database  to  latest  packages  based   upon
          repositories

          Returns  a  dict,  with the keys being package databases and the
          values being the result of the update attempt. Values can be one
          of the following:

          * True: Database updated successfully

          * False: Problem updating database

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.opkg.remove(name=None, pkgs=None, **kwargs)
          Remove packages using opkg remove.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.opkg.unhold(name=None, pkgs=None, sources=None, **kwargs)
          Set package current in 'hold' state to install state, meaning it
          will be upgraded.

          name   The name of the package, e.g., 'tmux'

                 CLI Example:

                    salt '*' pkg.unhold <package name>

          pkgs   A list of packages to hold. Must be passed  as  a  python
                 list.

                 CLI Example:

                    salt '*' pkg.unhold pkgs='["foo", "bar"]'

   salt.modules.opkg.upgrade(refresh=True)
          Upgrades all packages via opkg upgrade

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.opkg.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.opkg.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          string if not installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.opkg.version_cmp(pkg1, pkg2, ignore_epoch=False)
          Do  a  cmp-style comparison on two packages. Return -1 if pkg1 <
          pkg2, 0 if pkg1 == pkg2, and 1 if pkg1 > pkg2.  Return  None  if
          there was a problem making the comparison.

          ignore_epoch
                 False  Set  to  True  to  ignore the epoch when comparing
                 versions

                 New in version 2016.3.4.

          CLI Example:

             salt '*' pkg.version_cmp '0.2.4-0' '0.2.4.1-0'

   salt.modules.oracle
   Oracle DataBase connection module

   maintainer
          Vladimir Bormotov <[email protected]>

   maturity
          new

   depends
          cx_Oracle

   platform
          all

   configuration
          module provide connections for multiple Oracle DB instances.

          OS Environment

             ORACLE_HOME: path to oracle product
             PATH: path to Oracle Client libs need to be in PATH

          pillar

             oracle.dbs: list of known based
             oracle.dbs.<db>.uri: connection credentials in format:
                 user/password@host[:port]/sid[ as {sysdba|sysoper}]

   salt.modules.oracle.client_version()
          Oracle Client Version

          CLI Example:

             salt '*' oracle.client_version

   salt.modules.oracle.run_query(db, query)
          Run SQL query and return result

          CLI Example:

             salt '*' oracle.run_query my_db "select * from my_table"

   salt.modules.oracle.show_dbs(*dbs)
          Show databases configuration from pillar. Filter by *args

          CLI Example:

             salt '*' oracle.show_dbs
             salt '*' oracle.show_dbs my_db

   salt.modules.oracle.show_env()
          Show Environment used by Oracle Client

          CLI Example:

             salt '*' oracle.show_env

          NOTE:
             at first _connect() NLS_LANG will forced to '.AL32UTF8'

   salt.modules.oracle.show_pillar(item=None)
          Show  Pillar  segment  oracle.*  and   subitem   with   notation
          "item:subitem"

          CLI Example:

             salt '*' oracle.show_pillar
             salt '*' oracle.show_pillar dbs:my_db

   salt.modules.oracle.version(*dbs)
          Server Version (select banner  from v$version)

          CLI Example:

             salt '*' oracle.version
             salt '*' oracle.version my_db

   salt.modules.osquery
   Support for OSQuery - https://osquery.io.

   New in version 2015.8.0.

   salt.modules.osquery.acpi_tables(attrs=None, where=None)
          Return acpi_tables information from osquery

          CLI Example:

             salt '*' osquery.acpi_tables

   salt.modules.osquery.alf(attrs=None, where=None)
          Return alf information from osquery

          CLI Example:

             salt '*' osquery.alf

   salt.modules.osquery.alf_exceptions(attrs=None, where=None)
          Return alf_exceptions information from osquery

          CLI Example:

             salt '*' osquery.alf_exceptions

   salt.modules.osquery.alf_explicit_auths(attrs=None, where=None)
          Return alf_explicit_auths information from osquery

          CLI Example:

             salt '*' osquery.alf_explicit_auths

   salt.modules.osquery.alf_services(attrs=None, where=None)
          Return alf_services information from osquery

          CLI Example:

             salt '*' osquery.alf_services

   salt.modules.osquery.apps(attrs=None, where=None)
          Return apps information from osquery

          CLI Example:

             salt '*' osquery.apps

   salt.modules.osquery.apt_sources(attrs=None, where=None)
          Return apt_sources information from osquery

          CLI Example:

             salt '*' osquery.apt_sources

   salt.modules.osquery.arp_cache(attrs=None, where=None)
          Return arp_cache information from osquery

          CLI Example:

             salt '*' osquery.arp_cache

   salt.modules.osquery.block_devices(attrs=None, where=None)
          Return block_devices information from osquery

          CLI Example:

             salt '*' osquery.block_devices

   salt.modules.osquery.certificates(attrs=None, where=None)
          Return certificates information from osquery

          CLI Example:

             salt '*' osquery.certificates

   salt.modules.osquery.chrome_extensions(attrs=None, where=None)
          Return chrome_extensions information from osquery

          CLI Example:

             salt '*' osquery.chrome_extensions

   salt.modules.osquery.cpuid(attrs=None, where=None)
          Return cpuid information from osquery

          CLI Example:

             salt '*' osquery.cpuid

   salt.modules.osquery.crontab(attrs=None, where=None)
          Return crontab information from osquery

          CLI Example:

             salt '*' osquery.crontab

   salt.modules.osquery.deb_packages(attrs=None, where=None)
          Return deb_packages information from osquery

          CLI Example:

             salt '*' osquery.deb_packages

   salt.modules.osquery.etc_hosts(attrs=None, where=None)
          Return etc_hosts information from osquery

          CLI Example:

             salt '*' osquery.etc_hosts

   salt.modules.osquery.etc_services(attrs=None, where=None)
          Return etc_services information from osquery

          CLI Example:

             salt '*' osquery.etc_services

   salt.modules.osquery.file(attrs=None, where=None)
          Return file information from osquery

          CLI Example:

             salt '*' osquery.file

   salt.modules.osquery.file_changes(attrs=None, where=None)
          Return file_changes information from osquery

          CLI Example:

             salt '*' osquery.file_changes

   salt.modules.osquery.firefox_addons(attrs=None, where=None)
          Return firefox_addons information from osquery

          CLI Example:

             salt '*' osquery.firefox_addons

   salt.modules.osquery.groups(attrs=None, where=None)
          Return groups information from osquery

          CLI Example:

             salt '*' osquery.groups

   salt.modules.osquery.hardware_events(attrs=None, where=None)
          Return hardware_events information from osquery

          CLI Example:

             salt '*' osquery.hardware_events

   salt.modules.osquery.hash(attrs=None, where=None)
          Return hash information from osquery

          CLI Example:

             salt '*' osquery.hash

   salt.modules.osquery.homebrew_packages(attrs=None, where=None)
          Return homebrew_packages information from osquery

          CLI Example:

             salt '*' osquery.homebrew_packages

   salt.modules.osquery.interface_addresses(attrs=None, where=None)
          Return interface_addresses information from osquery

          CLI Example:

             salt '*' osquery.interface_addresses

   salt.modules.osquery.interface_details(attrs=None, where=None)
          Return interface_details information from osquery

          CLI Example:

             salt '*' osquery.interface_details

   salt.modules.osquery.iokit_devicetree(attrs=None, where=None)
          Return iokit_devicetree information from osquery

          CLI Example:

             salt '*' osquery.iokit_devicetree

   salt.modules.osquery.iokit_registry(attrs=None, where=None)
          Return iokit_registry information from osquery

          CLI Example:

             salt '*' osquery.iokit_registry

   salt.modules.osquery.kernel_extensions(attrs=None, where=None)
          Return kernel_extensions information from osquery

          CLI Example:

             salt '*' osquery.kernel_extensions

   salt.modules.osquery.kernel_info(attrs=None, where=None)
          Return kernel_info information from osquery

          CLI Example:

             salt '*' osquery.kernel_info

   salt.modules.osquery.kernel_integrity(attrs=None, where=None)
          Return kernel_integrity information from osquery

          CLI Example:

             salt '*' osquery.kernel_integrity

   salt.modules.osquery.kernel_modules(attrs=None, where=None)
          Return kernel_modules information from osquery

          CLI Example:

             salt '*' osquery.kernel_modules

   salt.modules.osquery.keychain_items(attrs=None, where=None)
          Return keychain_items information from osquery

          CLI Example:

             salt '*' osquery.keychain_items

   salt.modules.osquery.last(attrs=None, where=None)
          Return last information from osquery

          CLI Example:

             salt '*' osquery.last

   salt.modules.osquery.launchd(attrs=None, where=None)
          Return launchd information from osquery

          CLI Example:

             salt '*' osquery.launchd

   salt.modules.osquery.listening_ports(attrs=None, where=None)
          Return listening_ports information from osquery

          CLI Example:

             salt '*' osquery.listening_ports

   salt.modules.osquery.logged_in_users(attrs=None, where=None)
          Return logged_in_users information from osquery

          CLI Example:

             salt '*' osquery.logged_in_users

   salt.modules.osquery.memory_map(attrs=None, where=None)
          Return memory_map information from osquery

          CLI Example:

             salt '*' osquery.memory_map

   salt.modules.osquery.mounts(attrs=None, where=None)
          Return mounts information from osquery

          CLI Example:

             salt '*' osquery.mounts

   salt.modules.osquery.nfs_shares(attrs=None, where=None)
          Return nfs_shares information from osquery

          CLI Example:

             salt '*' osquery.nfs_shares

   salt.modules.osquery.nvram(attrs=None, where=None)
          Return nvram information from osquery

          CLI Example:

             salt '*' osquery.nvram

   salt.modules.osquery.os_version(attrs=None, where=None)
          Return os_version information from osquery

          CLI Example:

             salt '*' osquery.os_version

   salt.modules.osquery.osquery_extensions(attrs=None, where=None)
          Return osquery_extensions information from osquery

          CLI Example:

             salt '*' osquery.osquery_extensions

   salt.modules.osquery.osquery_flags(attrs=None, where=None)
          Return osquery_flags information from osquery

          CLI Example:

             salt '*' osquery.osquery_flags

   salt.modules.osquery.osquery_info(attrs=None, where=None)
          Return osquery_info information from osquery

          CLI Example:

             salt '*' osquery.osquery_info

   salt.modules.osquery.osquery_registry(attrs=None, where=None)
          Return osquery_registry information from osquery

          CLI Example:

             salt '*' osquery.osquery_registry

   salt.modules.osquery.passwd_changes(attrs=None, where=None)
          Return passwd_changes information from osquery

          CLI Example:

             salt '*' osquery.passwd_changes

   salt.modules.osquery.pci_devices(attrs=None, where=None)
          Return pci_devices information from osquery

          CLI Example:

             salt '*' osquery.pci_devices

   salt.modules.osquery.preferences(attrs=None, where=None)
          Return preferences information from osquery

          CLI Example:

             salt '*' osquery.preferences

   salt.modules.osquery.process_envs(attrs=None, where=None)
          Return process_envs information from osquery

          CLI Example:

             salt '*' osquery.process_envs

   salt.modules.osquery.process_memory_map(attrs=None, where=None)
          Return process_memory_map information from osquery

          CLI Example:

             salt '*' osquery.process_memory_map

   salt.modules.osquery.process_open_files(attrs=None, where=None)
          Return process_open_files information from osquery

          CLI Example:

             salt '*' osquery.process_open_files

   salt.modules.osquery.process_open_sockets(attrs=None, where=None)
          Return process_open_sockets information from osquery

          CLI Example:

             salt '*' osquery.process_open_sockets

   salt.modules.osquery.processes(attrs=None, where=None)
          Return processes information from osquery

          CLI Example:

             salt '*' osquery.processes

   salt.modules.osquery.quarantine(attrs=None, where=None)
          Return quarantine information from osquery

          CLI Example:

             salt '*' osquery.quarantine

   salt.modules.osquery.query(sql=None)
          Return time information from osquery

          CLI Example:

             salt '*' osquery.query "select * from users;"

   salt.modules.osquery.routes(attrs=None, where=None)
          Return routes information from osquery

          CLI Example:

             salt '*' osquery.routes

   salt.modules.osquery.rpm_packages(attrs=None, where=None)
          Return cpuid information from osquery

          CLI Example:

             salt '*' osquery.rpm_packages

   salt.modules.osquery.safari_extensions(attrs=None, where=None)
          Return safari_extensions information from osquery

          CLI Example:

             salt '*' osquery.safari_extensions

   salt.modules.osquery.shared_memory(attrs=None, where=None)
          Return shared_memory information from osquery

          CLI Example:

             salt '*' osquery.shared_memory

   salt.modules.osquery.shell_history(attrs=None, where=None)
          Return shell_history information from osquery

          CLI Example:

             salt '*' osquery.shell_history

   salt.modules.osquery.smbios_tables(attrs=None, where=None)
          Return smbios_tables information from osquery

          CLI Example:

             salt '*' osquery.smbios_tables

   salt.modules.osquery.startup_items(attrs=None, where=None)
          Return startup_items information from osquery

          CLI Example:

             salt '*' osquery.startup_items

   salt.modules.osquery.suid_bin(attrs=None, where=None)
          Return suid_bin information from osquery

          CLI Example:

             salt '*' osquery.suid_bin

   salt.modules.osquery.system_controls(attrs=None, where=None)
          Return system_controls information from osquery

          CLI Example:

             salt '*' osquery.system_controls

   salt.modules.osquery.time(attrs=None)
          Return time information from osquery

          CLI Example:

             salt '*' osquery.time

   salt.modules.osquery.usb_devices(attrs=None, where=None)
          Return usb_devices information from osquery

          CLI Example:

             salt '*' osquery.usb_devices

   salt.modules.osquery.users(attrs=None, where=None)
          Return users information from osquery

          CLI Example:

             salt '*' osquery.users

   salt.modules.osquery.version()
          Return version of osquery

          CLI Example:

             salt '*' osquery.version

   salt.modules.osquery.xattr_where_from(attrs=None, where=None)
          Return xattr_where_from information from osquery

          CLI Example:

             salt '*' osquery.xattr_where_from

   salt.modules.osquery.xprotect_entries(attrs=None, where=None)
          Return xprotect_entries information from osquery

          CLI Example:

             salt '*' osquery.xprotect_entries

   salt.modules.osquery.xprotect_reports(attrs=None, where=None)
          Return xprotect_reports information from osquery

          CLI Example:

             salt '*' osquery.xprotect_reports

   salt.modules.pacman
   A   module   to   wrap   pacman  calls,  since  Arch  is  the  best  (
   https://wiki.archlinux.org/index.php/Arch_is_the_best)

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on  a  minion, and it is using a different module (or gives an error
      similar to 'pkg.install' is not available), see here.

   salt.modules.pacman.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying  any  packages  will return a list of _every_ file on
          the system's package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.pacman.file_list(*packages)
          List the files that belong to  a  package.  Not  specifying  any
          packages  will  return  a  list  of _every_ file on the system's
          package database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.pacman.group_diff(name)
          New in version 2016.11.0.

          Lists which of a group's packages are installed  and  which  are
          not installed

          Compatible   with   yumpkg.group_diff   for   easy   support  of
          state.pkg.group_installed

          CLI Example:

             salt '*' pkg.group_diff 'xorg'

   salt.modules.pacman.group_info(name)
          New in version 2016.11.0.

          Lists all packages in the specified group

          CLI Example:

             salt '*' pkg.group_info 'xorg'

   salt.modules.pacman.group_list()
          New in version 2016.11.0.

          Lists all groups known by pacman on this system

          CLI Example:

             salt '*' pkg.group_list

   salt.modules.pacman.install(name=None, refresh=False, sysupgrade=False,
   pkgs=None, sources=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any pacman commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Install (pacman -S) the specified packag(s). Add refresh=True to
          install with -y, add sysupgrade=True to install with -u.

          name   The name of the package to be installed. Note  that  this
                 parameter is ignored if either pkgs or sources is passed.
                 Additionally, please note that this option  can  only  be
                 used  to  install packages from a software repository. To
                 install a package file manually, use the sources option.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 Whether or not to refresh  the  package  database  before
                 installing.

          sysupgrade
                 Whether  or  not  to  upgrade  the system packages before
                 installing.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must  be  passed  as  a  python  list. A specific version
                 number can be specified by using  a  single-element  dict
                 representing  the  package  and  its version. As with the
                 version parameter above, comparison operators can be used
                 to target a specific version of a package.

                 CLI Examples:

                    salt '*' pkg.install pkgs='["foo", "bar"]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "1.2.3-4"}]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "<1.2.3-4"}]'

          sources
                 A  list  of packages to install. Must be passed as a list
                 of dicts, with the keys  being  package  names,  and  the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install                 sources='[{"foo": "salt://foo.pkg.tar.xz"},                 {"bar": "salt://bar.pkg.tar.xz"}]'

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.pacman.latest_version(*names, **kwargs)
          Return  the  latest  version  of the named package available for
          upgrade or installation.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          If  the  latest version of a given package is already installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.pacman.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.pacman.list_upgrades(refresh=False, root=None, **kwargs)
          List all available package upgrades on this system

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.pacman.owner(*paths)
          New in version 2014.7.0.

          Return the name of the package that owns the file. Multiple file
          paths       can       be      passed.      Like      pkg.version
          <salt.modules.yumpkg.version, if a  single  path  is  passed,  a
          string  will  be  returned,  and if multiple paths are passed, a
          dictionary of file/package name pairs will be returned.

          If the file is not owned by a package, or is not present on  the
          minion, then an empty string will be returned for that path.

          CLI Example:
             salt  '*'  pkg.owner  /usr/bin/apachectl  salt  '*' pkg.owner
             /usr/bin/apachectl /usr/bin/zsh

   salt.modules.pacman.purge(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any pacman commands spawned by Salt when the salt-minion
          service  is  restarted.  (see  KillMode  in  the systemd.kill(5)
          manpage  for   more   information).   If   desired,   usage   of
          systemd-run(1)  can  be  suppressed  by  setting a config option
          called systemd.scope, with a value of False (no quotes).

          Recursively remove a package and  all  dependencies  which  were
          installed with it, this will call a pacman -Rsc

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.pacman.refresh_db(root=None)
          Just run a pacman -Sy, return a dict:

             {'<database name>': Bool}

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.pacman.remove(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any pacman commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Remove packages with pacman -R.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.pacman.upgrade(refresh=False, root=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any pacman commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Run a full system upgrade, a pacman -Syu

          refresh
                 Whether  or  not  to  refresh the package database before
                 installing.

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.pacman.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.pacman.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.pagerduty
   Module for Firing Events via PagerDuty

   New in version 2014.1.0.

   configuration
          This  module  can  be  used  by  specifying  the   name   of   a
          configuration  profile  in  the minion config, minion pillar, or
          master config.

          For example:

             my-pagerduty-account:
                 pagerduty.api_key: F3Rbyjbve43rfFWf2214
                 pagerduty.subdomain: mysubdomain

   salt.modules.pagerduty.create_event(service_key=None, description=None,
   details=None, incident_key=None, profile=None)
          Create an event in PagerDuty. Designed for use in states.

          CLI Example:

             salt myminion pagerduty.create_event <service_key> <description> <details>         profile=my-pagerduty-account

          The following parameters are required:

          service_key
                 This key can be found by using pagerduty.list_services.

          description
                 This is a short description of the event.

          details
                 This can be a more detailed description of the event.

          profile
                 This  refers  to  the  configuration  profile  to  use to
                 connect to the PagerDuty service.

   salt.modules.pagerduty.list_escalation_policies(profile=None,
   api_key=None)
          This function is an alias of list_policies.
             List escalation policies belonging to this account

             CLI Example:
                 salt           myminion           pagerduty.list_policies
                 my-pagerduty-account            salt             myminion
                 pagerduty.list_escalation_policies my-pagerduty-account

   salt.modules.pagerduty.list_incidents(profile=None, api_key=None)
          List incidents belonging to this account

          CLI Example:
             salt myminion pagerduty.list_incidents my-pagerduty-account

   salt.modules.pagerduty.list_maintenance_windows(profile=None,
   api_key=None)
          This function is an alias of list_windows.
             List maintenance windows belonging to this account

             CLI Example:
                 salt myminion pagerduty.list_windows my-pagerduty-account
                 salt      myminion     pagerduty.list_maintenance_windows
                 my-pagerduty-account

   salt.modules.pagerduty.list_policies(profile=None, api_key=None)
          List escalation policies belonging to this account

          CLI Example:
             salt  myminion  pagerduty.list_policies  my-pagerduty-account
             salt        myminion       pagerduty.list_escalation_policies
             my-pagerduty-account

   salt.modules.pagerduty.list_schedules(profile=None, api_key=None)
          List schedules belonging to this account

          CLI Example:
             salt myminion pagerduty.list_schedules my-pagerduty-account

   salt.modules.pagerduty.list_services(profile=None, api_key=None)
          List services belonging to this account

          CLI Example:
             salt myminion pagerduty.list_services my-pagerduty-account

   salt.modules.pagerduty.list_users(profile=None, api_key=None)
          List users belonging to this account

          CLI Example:
             salt myminion pagerduty.list_users my-pagerduty-account

   salt.modules.pagerduty.list_windows(profile=None, api_key=None)
          List maintenance windows belonging to this account

          CLI Example:
             salt  myminion  pagerduty.list_windows   my-pagerduty-account
             salt        myminion       pagerduty.list_maintenance_windows
             my-pagerduty-account

   salt.modules.pagerduty_util
   Module for manageing PagerDuty resource

   configuration
          This  module  can  be  used  by  specifying  the   name   of   a
          configuration  profile  in  the minion config, minion pillar, or
          master  config.   The  default  configuration  profile  name  is
          'pagerduty.'

          For example:

             pagerduty:
                 pagerduty.api_key: F3Rbyjbve43rfFWf2214
                 pagerduty.subdomain: mysubdomain

   For            PagerDuty           API           details,           see
   https://developer.pagerduty.com/documentation/rest

   salt.modules.pagerduty_util.create_or_update_resource(resource_name,
   identifier_fields,      data,      diff=None,      profile='pagerduty',
   subdomain=None, api_key=None)
          create or  update  any  pagerduty  resource  Helper  method  for
          present().

          Determining  if  two  resources  are  the  same is different for
          different PD resource, so this method accepts a  diff  function.
          The  diff  function  will  be invoked as diff(state_information,
          object_returned_from_pagerduty), and should  return  a  dict  of
          data  to  pass to the PagerDuty update API method, or None if no
          update is to be performed.  If no diff method is  provided,  the
          default  behavor  is  to scan the keys in the state_information,
          comparing      the      matching       values       in       the
          object_returned_from_pagerduty,   and  update  any  values  that
          differ.  examples

          create_or_update_resource("user",         ["id","name","email"])
          create_or_update_resource("escalation_policies",  ["id","name"],
          diff=my_diff_function)

   salt.modules.pagerduty_util.delete_resource(resource_name,         key,
   identifier_fields, profile='pagerduty', subdomain=None, api_key=None)
          delete any pagerduty resource

          Helper method for absent() example

          delete_resource("users", key, ["id","name","email"]) # delete by
          id or name or email

   salt.modules.pagerduty_util.get_escalation_policies(profile='pagerduty',
   subdomain=None, api_key=None)
          List escalation_policies belonging to this account

          CLI Example:
             salt myminion pagerduty.get_escalation_policies

   salt.modules.pagerduty_util.get_resource(resource_name,            key,
   identifier_fields, profile='pagerduty', subdomain=None, api_key=None)
          Get any single pagerduty resource by key.

          We allow flexible lookup by any of a list of  identifier_fields.
          So,  for example, you can look up users by email address or name
          by calling:
             get_resource('users', key, ['name', 'email'], ...)

          This method is mainly used to translate state sls into pagerduty
          id's for dependent objects.  For example, a pagerduty escalation
          policy contains one or more schedules, which must be  passed  by
          their  pagerduty  id.   We  look up the schedules by name (using
          this method), and then translate the names into id's.

          This method  is  implemented  by  getting  all  objects  of  the
          resource  type  (cached  into  __context__),  then  brute  force
          searching through the list  and  trying  to  match  any  of  the
          identifier_fields.   The  __context__  cache is purged after any
          create, update or delete to the resource.

   salt.modules.pagerduty_util.get_schedules(profile='pagerduty',
   subdomain=None, api_key=None)
          List schedules belonging to this account

          CLI Example:
             salt myminion pagerduty.get_schedules

   salt.modules.pagerduty_util.get_services(profile='pagerduty',
   subdomain=None, api_key=None)
          List services belonging to this account

          CLI Example:
             salt myminion pagerduty.get_services

   salt.modules.pagerduty_util.get_users(profile='pagerduty',
   subdomain=None, api_key=None)
          List users belonging to this account

          CLI Example:
             salt myminion pagerduty.get_users

   salt.modules.pagerduty_util.resource_absent(resource,
   identifier_fields, profile='pagerduty',  subdomain=None,  api_key=None,
   **kwargs)
          Generic  resource.absent state method.   Pagerduty state modules
          should be a thin wrapper over this method, with  a  custom  diff
          function.

          This  method calls delete_resource() and formats the result as a
          salt state return value.  example

          resource_absent("users", ["id","name","email"])

   salt.modules.pagerduty_util.resource_present(resource,
   identifier_fields,   diff=None,   profile='pagerduty',  subdomain=None,
   api_key=None, **kwargs)
          Generic resource.present state method.   Pagerduty state modules
          should  be  a  thin wrapper over this method, with a custom diff
          function.

          This method calls create_or_update_resource()  and  formats  the
          result as a salt state return value.  example

          resource_present("users", ["id","name","email"])

   salt.modules.pam
   Support for pam

   salt.modules.pam.read_file(file_name)
          This is just a test function, to make sure parsing works

          CLI Example:

             salt '*' pam.read_file /etc/pam.d/login

   salt.modules.parallels module
   Manage  Parallels  Desktop VMs with prlctl and prlsrvctl.  Only some of
   the prlctl commands implemented  so  far.   Of  those  that  have  been
   implemented,  not all of the options may have been provided yet.  For a
   complete reference, see the Parallels Desktop Reference Guide.

   What  has  not  been  implemented   yet   can   be   accessed   through
   parallels.prlctl  and  parallels.prlsrvctl  (note the preceeding double
   dash -- as necessary):

   New in version 2016.3.0.

   salt.modules.parallels.clone(name,       new_name,        linked=False,
   template=False, runas=None)
          Clone a VM

          New in version 2016.11.0.

          Parameters

                 * name (str) -- Name/ID of VM to clone

                 * new_name (str) -- Name of the new VM

                 * linked (bool) -- Create a linked virtual machine.

                 * template  (bool)  --  Create a virtual machine template
                   instead of a real virtual machine.

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.clone macvm macvm_new runas=macdev
             salt '*' parallels.clone macvm macvm_templ template=True runas=macdev

   salt.modules.parallels.delete(name, runas=None)
          Delete a VM

          New in version 2016.11.0.

          Parameters

                 * name (str) -- Name/ID of VM to clone

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.exec macvm 'find /etc/paths.d' runas=macdev

   salt.modules.parallels.delete_snapshot(name,   snap_name,   runas=None,
   all=False)
          Delete a snapshot

          NOTE:
             Deleting  a  snapshot  from which other snapshots are dervied
             will not delete the derived snapshots

          Parameters

                 * name (str) -- Name/ID of  VM  whose  snapshot  will  be
                   deleted

                 * snap_name (str) -- Name/ID of snapshot to delete

                 * runas (str) -- The user that the prlctl command will be
                   run as

                 * all (bool) --

                   Delete all snapshots having the name given

                   New in version 2016.11.0.

          Example:

             salt '*' parallels.delete_snapshot macvm 'unneeded snapshot' runas=macdev
             salt '*' parallels.delete_snapshot macvm 'Snapshot for linked clone' all=True runas=macdev

   salt.modules.parallels.exec(name, command, runas=None)
          Run a command on a VM

          Parameters

                 * name (str) -- Name/ID of VM whose exec will be returned

                 * command (str) -- Command to run on the VM

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.exec macvm 'find /etc/paths.d' runas=macdev

   salt.modules.parallels.exists(name, runas=None)
          Query whether a VM exists

          New in version 2016.11.0.

          Parameters

                 * name (str) -- Name/ID of VM

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.exists macvm runas=macdev

   salt.modules.parallels.list_snapshots(name, snap_name=None, tree=False,
   names=False, runas=None)
          List the snapshots

          Parameters

                 * name  (str)  --  Name/ID  of VM whose snapshots will be
                   listed

                 * snap_id  (str)  --  Name/ID  of  snapshot  to   display
                   information  about.   If  tree=True  is also specified,
                   display the snapshot subtree having  this  snapshot  as
                   the root snapshot

                 * tree  (bool)  --  List  snapshots in tree format rather
                   than tabular format

                 * names (bool) -- List snapshots as ID, name pairs

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.list_snapshots macvm runas=macdev
             salt '*' parallels.list_snapshots macvm tree=True runas=macdev
             salt '*' parallels.list_snapshots macvm snap_name=original runas=macdev
             salt '*' parallels.list_snapshots macvm names=True runas=macdev

   salt.modules.parallels.list_vms(name=None,    info=False,    all=False,
   args=None, runas=None, template=False)
          List information about the VMs

          Parameters

                 * name (str) --

                   Name/ID of VM to list

                   Changed  in  version  2016.11.0:  No   longer   implies
                   info=True

                 * info (str) -- List extra information

                 * all (bool) -- List all non-template VMs

                 * args  (tuple)  --  Additional  arguments given to prctl
                   list

                 * runas (str) -- The user that the prlctl command will be
                   run as

                 * template (bool) --

                   List the available virtual machine templates.  The real
                   virtual machines will not be included in the output

                   New in version 2016.11.0.

          Example:

             salt '*' parallels.list_vms runas=macdev
             salt '*' parallels.list_vms name=macvm info=True runas=macdev
             salt '*' parallels.list_vms info=True runas=macdev
             salt '*' parallels.list_vms ' -o uuid,status' all=True runas=macdev

   salt.modules.parallels.prlctl(sub_cmd, args=None, runas=None)
          Execute a prlctl command

          Parameters

                 * sub_cmd (str) -- prlctl subcommand to execute

                 * args  (str)  --  The  arguments  supplied   to   prlctl
                   <sub_cmd>

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.prlctl user list runas=macdev
             salt '*' parallels.prlctl exec 'macvm uname' runas=macdev
             salt -- '*' parallels.prlctl capture 'macvm --file macvm.display.png' runas=macdev

   salt.modules.parallels.prlsrvctl(sub_cmd, args=None, runas=None)
          Execute a prlsrvctl command

          New in version 2016.11.0.

          Parameters

                 * sub_cmd (str) -- prlsrvctl subcommand to execute

                 * args (str)  --  The  arguments  supplied  to  prlsrvctl
                   <sub_cmd>

                 * runas (str) -- The user that the prlsrvctl command will
                   be run as

          Example:

             salt '*' parallels.prlsrvctl info runas=macdev
             salt '*' parallels.prlsrvctl usb list runas=macdev
             salt -- '*' parallels.prlsrvctl set '--mem-limit auto' runas=macdev

   salt.modules.parallels.reset(name, runas=None)
          Reset a VM by performing a hard shutdown and then a restart

          Parameters

                 * name (str) -- Name/ID of VM to reset

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.reset macvm runas=macdev

   salt.modules.parallels.restart(name, runas=None)
          Restart  a VM by gracefully shutting it down and then restarting
          it

          Parameters

                 * name (str) -- Name/ID of VM to restart

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.restart macvm runas=macdev

   salt.modules.parallels.revert_snapshot(name, snap_name, runas=None)
          Revert a VM to a snapshot

          Parameters

                 * name (str) -- Name/ID of VM to revert to a snapshot

                 * snap_name (str) -- Name/ID of snapshot to revert to

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.revert_snapshot macvm base-with-updates runas=macdev

   salt.modules.parallels.snapshot(name,    snap_name=None,     desc=None,
   runas=None)
          Create a snapshot

          Parameters

                 * name (str) -- Name/ID of VM to take a snapshot of

                 * snap_name (str) -- Name of snapshot

                 * desc (str) -- Description of snapshot

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.create_snapshot macvm snap_name=macvm-original runas=macdev
             salt '*' parallels.create_snapshot macvm snap_name=macvm-updates desc='clean install with updates' runas=macdev

   salt.modules.parallels.snapshot_id_to_name(name, snap_id, strict=False,
   runas=None)
          Attempt  to  convert  a  snapshot ID to a snapshot name.  If the
          snapshot has no name or if the ID is not found  or  invalid,  an
          empty string will be returned

          Parameters

                 * name  (str)  --  Name/ID  of  VM  whose  snapshots  are
                   inspected

                 * snap_id (str) -- ID of the snapshot

                 * strict (bool) -- Raise an exception if a name cannot be
                   found for the given snap_id

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example data

             ID: {a5b8999f-5d95-4aff-82de-e515b0101b66}
             Name: original
             Date: 2016-03-04 10:50:34
             Current: yes
             State: poweroff
             Description: original state

          CLI Example:

             salt '*' parallels.snapshot_id_to_name macvm a5b8999f-5d95-4aff-82de-e515b0101b66 runas=macdev

   salt.modules.parallels.snapshot_name_to_id(name,             snap_name,
   strict=False, runas=None)
          Attempt  to  convert  a  snapshot name to a snapshot ID.  If the
          name is not found an empty  string  is  returned.   If  multiple
          snapshots share the same name, a list will be returned

          Parameters

                 * name  (str)  --  Name/ID  of  VM  whose  snapshots  are
                   inspected

                 * snap_name (str) -- Name of the snapshot

                 * strict  (bool)  --  Raise  an  exception  if   multiple
                   snapshot IDs are found

                 * runas (str) -- The user that the prlctl command will be
                   run as

          CLI Example:

             salt '*' parallels.snapshot_id_to_name macvm original runas=macdev

   salt.modules.parallels.start(name, runas=None)
          Start a VM

          Parameters

                 * name (str) -- Name/ID of VM to start

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.start macvm runas=macdev

   salt.modules.parallels.status(name, runas=None)
          Status of a VM

          Parameters

                 * name  (str)  --  Name/ID  of  VM  whose  status will be
                   returned

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.status macvm runas=macdev

   salt.modules.parallels.stop(name, kill=False, runas=None)
          Stop a VM

          Parameters

                 * name (str) -- Name/ID of VM to stop

                 * kill (bool) -- Perform a hard shutdown

                 * runas (str) -- The user that the prlctl command will be
                   run as

          Example:

             salt '*' parallels.stop macvm runas=macdev
             salt '*' parallels.stop macvm kill=True runas=macdev

   salt.modules.parted
   Module for managing partitions on POSIX-like systems.

   depends

          * parted,  partprobe,  lsblk  (usually  parted  and   util-linux
            packages)

   Some  functions  may  not  be  available,  depending on your version of
   parted.

   Check the manpage for parted(8) for more  information,  or  the  online
   docs at:

   http://www.gnu.org/software/parted/manual/html_chapter/parted_2.html

   In  light of parted not directly supporting partition IDs, some of this
   module  has  been  written  to  utilize  sfdisk  instead.  For  further
   information, please reference the man page for sfdisk(8).

   salt.modules.parted.align_check(device, part_type, partition)
          Check   if  partition  satisfies  the  alignment  constraint  of
          part_type.  Type must be "minimal" or "optimal".

          CLI Example:

             salt '*' partition.align_check /dev/sda minimal 1

   salt.modules.parted.check(device, minor)
          Checks if the file system on partition <minor> has any errors.

          CLI Example:

             salt '*' partition.check 1

   salt.modules.parted.cp(device, from_minor, to_minor)
          Copies  the  file  system  on  the  partition  <from-minor>   to
          partition  <to-minor>,  deleting  the  original  contents of the
          destination partition.

          CLI Example:

             salt '*' partition.cp /dev/sda 2 3

   salt.modules.parted.exists(device='')
          Check to see if the partition exists

          CLI Example:

             salt '*' partition.exists /dev/sdb1

   salt.modules.parted.get_block_device()
          Retrieve a list of disk devices

          New in version 2014.7.0.

          CLI Example:

             salt '*' partition.get_block_device

   salt.modules.parted.get_id(device, minor)
          Prints the system ID for the partition. Some typical values are:

              b: FAT32 (vfat)
              7: HPFS/NTFS
             82: Linux Swap
             83: Linux
             8e: Linux LVM
             fd: Linux RAID Auto

          CLI Example:

             salt '*' partition.get_id /dev/sda 1

   salt.modules.parted.list(device, unit=None)
          Prints partition information of given <device>

          CLI Examples:

             salt '*' partition.list /dev/sda
             salt '*' partition.list /dev/sda unit=s
             salt '*' partition.list /dev/sda unit=kB

   salt.modules.parted.mkfs(device, fs_type)
          Makes a file system <fs_type> on partition <device>,  destroying
          all  data  that resides on that partition. <fs_type> must be one
          of "ext2", "fat32",  "fat16",  "linux-swap"  or  "reiserfs"  (if
          libreiserfs is installed)

          CLI Example:

             salt '*' partition.mkfs /dev/sda2 fat32

   salt.modules.parted.mklabel(device, label_type)
          Create a new disklabel (partition table) of label_type.

          Type  should  be  one  of  "aix",  "amiga", "bsd", "dvh", "gpt",
          "loop", "mac", "msdos", "pc98", or "sun".

          CLI Example:

             salt '*' partition.mklabel /dev/sda msdos

   salt.modules.parted.mkpart(device, part_type, fs_type=None, start=None,
   end=None)
          Make  a part_type partition for filesystem fs_type, beginning at
          start and ending at end (by default  in  megabytes).   part_type
          should be one of "primary", "logical", or "extended".

          CLI Examples:

             salt '*' partition.mkpart /dev/sda primary fs_type=fat32 start=0 end=639
             salt '*' partition.mkpart /dev/sda primary start=0 end=639

   salt.modules.parted.mkpartfs(device, part_type, fs_type, start, end)
          Make a <part_type> partition with a new filesystem of <fs_type>,
          beginning  at  <start>  and  ending  at  <end>  (by  default  in
          megabytes).

          <part_type>   should   be   one   of  "primary",  "logical",  or
          "extended". <fs_type> must be one of "ext2",  "fat32",  "fat16",
          "linux-swap" or "reiserfs" (if libreiserfs is installed)

          CLI Example:

             salt '*' partition.mkpartfs /dev/sda logical ext2 440 670

   salt.modules.parted.name(device, partition, name)
          Set  the  name  of  partition to name. This option works only on
          Mac, PC98, and GPT disklabels. The name can be placed in quotes,
          if necessary.

          CLI Example:

             salt '*' partition.name /dev/sda 1 'My Documents'

   salt.modules.parted.probe(*devices)
          Ask  the kernel to update its local partition data. When no args
          are specified all block devices are tried.

          Caution:  Generally  only  works  on  devices  with  no  mounted
          partitions  and  may  take  a  long  time to return if specified
          devices are in use.

          CLI Examples:

             salt '*' partition.probe
             salt '*' partition.probe /dev/sda
             salt '*' partition.probe /dev/sda /dev/sdb

   salt.modules.parted.rescue(device, start, end)
          Rescue a lost partition that was located somewhere between start
          and  end.   If a partition is found, parted will ask if you want
          to create an entry for it in the partition table.

          CLI Example:

             salt '*' partition.rescue /dev/sda 0 8056

   salt.modules.parted.resize(device, minor, start, end)
          Resizes the partition with number <minor>.

          The partition will start <start> from the beginning of the disk,
          and  end  <end>  from  the  beginning  of the disk. resize never
          changes the minor number.  Extended partitions can  be  resized,
          so  long  as  the new extended partition completely contains all
          logical partitions.

          CLI Example:

             salt '*' partition.resize /dev/sda 3 200 850

   salt.modules.parted.rm(device, minor)
          Removes the partition with number <minor>.

          CLI Example:

             salt '*' partition.rm /dev/sda 5

   salt.modules.parted.set(device, minor, flag, state)
          Changes a flag on the partition with number <minor>.

          A flag can be either "on" or "off"  (make  sure  to  use  proper
          quoting,  see  YAML  Idiosyncrasies). Some or all of these flags
          will be available, depending on what disk label you are using.

          Valid flags are: bios_grub, legacy_boot, boot, lba, root,  swap,
          hidden, raid,
                 LVM, PALO, PREP, DIAG

          CLI Example:

             salt '*' partition.set /dev/sda 1 boot '"on"'

   salt.modules.parted.set_id(device, minor, system_id)
          Sets the system ID for the partition. Some typical values are:

              b: FAT32 (vfat)
              7: HPFS/NTFS
             82: Linux Swap
             83: Linux
             8e: Linux LVM
             fd: Linux RAID Auto

          CLI Example:

             salt '*' partition.set_id /dev/sda 1 83

   salt.modules.parted.system_types()
          List  the  system  types  that  are  supported  by the installed
          version of sfdisk

          CLI Example:

             salt '*' partition.system_types

   salt.modules.parted.toggle(device, partition, flag)

          Toggle the state of <flag> on <partition>. Valid flags  are  the
          same as
                 the set command.

          CLI Example:

             salt '*' partition.toggle /dev/sda 1 boot

   salt.modules.pcs module
   Configure a Pacemaker/Corosync cluster with PCS
   Configure  Pacemaker/Cororsync  clusters  with  the Pacemaker/Cororsync
   conifguration system (PCS)

   depends
          pcs

   New in version 2016.3.0.

   salt.modules.pcs.auth(nodes,                       pcsuser='hacluster',
   pcspasswd='hacluster', extra_args=None)
          Authorize nodes to the cluster

          nodes  a list of nodes which should be authorized to the cluster

          pcsuser
                 user for communitcation with PCS (default: hacluster)

          pcspasswd
                 password for pcsuser (default: hacluster)

          extra_args
                 list of extra option for the 'pcs cluster auth' command

          CLI Example:

             salt '*' pcs.auth nodes='[ node1.example.org node2.example.org ]' \
                               pcsuser='hacluster' \
                               pcspasswd='hoonetorg' \
                               extra_args=[ '--force' ]

   salt.modules.pcs.cib_create(cibfile,             scope='configuration',
   extra_args=None)
          Create a CIB-file from the current CIB of the cluster

          cibfile
                 name/path of the file containing the CIB

          scope  specific section of the CIB (default: configuration)

          extra_args
                 additional options for creating the CIB-file

          CLI Example:

             salt '*' pcs.cib_create cibfile='/tmp/VIP_apache_1.cib' \
                                     'scope=False'

   salt.modules.pcs.cib_push(cibfile,               scope='configuration',
   extra_args=None)
          Push a CIB-file as the new CIB to the cluster

          cibfile
                 name/path of the file containing the CIB

          scope  specific section of the CIB (default: configuration)

          extra_args
                 additional options for creating the CIB-file

          CLI Example:

             salt '*' pcs.cib_push cibfile='/tmp/VIP_apache_1.cib' \
                                   'scope=False'

   salt.modules.pcs.cluster_node_add(node, extra_args=None)
          Add a node to the pacemaker cluster via pcs command

          node   node that should be added

          extra_args
                 list  of  extra  option  for  the  'pcs cluster node add'
                 command

          CLI Example:

             salt '*' pcs.cluster_node_add node=node2.example.org'

   salt.modules.pcs.cluster_setup(nodes,      pcsclustername='pcscluster',
   extra_args=None)
          Setup pacemaker cluster via pcs command

          nodes  a list of nodes which should be set up

          pcsclustername
                 Name of the Pacemaker cluster (default: pcscluster)

          extra_args
                 list of extra option for the 'pcs cluster setup' command

          CLI Example:

             salt '*' pcs.cluster_setup nodes='[ node1.example.org node2.example.org ]' \
                                        pcsclustername='pcscluster'

   salt.modules.pcs.config_show(cibfile=None)
          Show config of cluster

          cibfile
                 name/path of the file containing the CIB

          CLI Example:

             salt '*' pcs.config_show cibfile='/tmp/cib_for_galera'

   salt.modules.pcs.is_auth(nodes)
          Check if nodes are already authorized

          nodes  a  list  of  nodes to be checked for authorization to the
                 cluster

          CLI Example:

             salt '*' pcs.is_auth nodes='[node1.example.org node2.example.org]'

   salt.modules.pcs.item_create(item, item_id, item_type, create='create',
   extra_args=None, cibfile=None)
          Create  an  item  via  pcs  command (mainly for use with the pcs
          state module)

          item   config, property, resource, constraint etc.

          item_id
                 id of the item

          item_type
                 item type

          create create command (create or set f.e., default: create)

          extra_args
                 additional options for the pcs command

          cibfile
                 use cibfile instead of the live CIB

   salt.modules.pcs.item_show(item,     item_id=None,      item_type=None,
   show='show', extra_args=None, cibfile=None)
          Show  an item via pcs command (mainly for use with the pcs state
          module)

          item   config, property, resource, constraint etc.

          item_id
                 id of the item

          item_type
                 item type

          show   show command (probably None, default: show)

          extra_args
                 additional options for the pcs command

          cibfile
                 use cibfile instead of the live CIB

   salt.modules.pcs.prop_set(prop, value, extra_args=None, cibfile=None)
          Set the value of a cluster property

          prop   name of the property

          value  value of the property prop

          extra_args
                 additional options for the pcs property command

          cibfile
                 use cibfile instead of the live CIB

          CLI Example:

             salt '*' pcs.prop_set prop='no-quorum-policy' \
                                   value='ignore' \
                                   cibfile='/tmp/2_node_cluster.cib'

   salt.modules.pcs.prop_show(prop, extra_args=None, cibfile=None)
          Show the value of a cluster property

          prop   name of the property

          extra_args
                 additional options for the pcs property command

          cibfile
                 use cibfile instead of the live CIB

          CLI Example:

             salt '*' pcs.prop_show cibfile='/tmp/2_node_cluster.cib' \
                                    prop='no-quorum-policy' \
                                    cibfile='/tmp/2_node_cluster.cib'

   salt.modules.pcs.resource_create(resource_id,            resource_type,
   resource_options=None, cibfile=None)
          Create a resource via pcs command

          resource_id
                 name for the resource

          resource_type
                 resource type (f.e. ocf:heartbeat:IPaddr2 or VirtualIP)

          resource_options
                 additional options for creating the resource

          cibfile
                 use cibfile instead of the live CIB for manipulation

          CLI Example:

             salt '*' pcs.resource_create resource_id='galera' \
                              resource_type='ocf:heartbeat:galera' \
                              resource_options="[ \
                                  'wsrep_cluster_address=gcomm://node1.example.org,node2.example.org,node3.example.org' \
                                  '--master' \
                              ]" \
                              cibfile='/tmp/cib_for_galera.cib'

   salt.modules.pcs.resource_show(resource_id,            extra_args=None,
   cibfile=None)
          Show a resource via pcs command

          resource_id
                 name of the resource

          extra_args
                 additional options for the pcs command

          cibfile
                 use cibfile instead of the live CIB

          CLI Example:

             salt '*' pcs.resource_show resource_id='galera' \
                                        cibfile='/tmp/cib_for_galera.cib'

   salt.modules.pcs.stonith_create(stonith_id,        stonith_device_type,
   stonith_device_options=None, cibfile=None)
          Create a stonith resource via pcs command

          stonith_id
                 name for the stonith resource

          stonith_device_type
                 name of the stonith agent fence_eps, fence_xvm f.e.

          stonith_device_options
                 additional options for creating the stonith resource

          cibfile
                 use cibfile instead of the live CIB for manipulation

          CLI Example:

             salt '*' pcs.stonith_create stonith_id='eps_fence' \
                                         stonith_device_type='fence_eps' \
                                         stonith_device_options="[ \
                                           'pcmk_host_map=node1.example.org:01;node2.example.org:02', \
                                           'ipaddr=myepsdevice.example.org', \
                                           'action=reboot', \
                                           'power_wait=5', \
                                           'verbose=1', \
                                           'debug=/var/log/pcsd/eps_fence.log', \
                                           'login=hidden', \
                                           'passwd=hoonetorg' \
                                         ]" \
                                         cibfile='/tmp/cib_for_stonith.cib'

   salt.modules.pcs.stonith_show(stonith_id,              extra_args=None,
   cibfile=None)
          Show the value of a cluster stonith

          stonith_id
                 name for the stonith resource

          extra_args
                 additional options for the pcs stonith command

          cibfile
                 use cibfile instead of the live CIB

          CLI Example:

             salt '*' pcs.stonith_show stonith_id='eps_fence' \
                                       cibfile='/tmp/2_node_cluster.cib'

   salt.modules.pecl
   Manage PHP pecl extensions.

   salt.modules.pecl.install(pecls,      defaults=False,      force=False,
   preferred_state='stable')
          New in version 0.17.0.

          Installs one or several pecl extensions.

          pecls  The pecl extensions to install.

          defaults
                 Use  default  answers  for  extensions  such as pecl_http
                 which ask questions  before  installation.  Without  this
                 option,  the  pecl.installed state will hang indefinitely
                 when trying to install these extensions.

          force  Whether to force the installed version or not

          CLI Example:

             salt '*' pecl.install fuse

   salt.modules.pecl.list(channel=None)
          List installed pecl extensions.

          CLI Example:

             salt '*' pecl.list

   salt.modules.pecl.uninstall(pecls)
          Uninstall one or several pecl extensions.

          pecls  The pecl extensions to uninstall.

          CLI Example:

             salt '*' pecl.uninstall fuse

   salt.modules.pecl.update(pecls)
          Update one or several pecl extensions.

          pecls  The pecl extensions to update.

          CLI Example:

             salt '*' pecl.update fuse

   salt.modules.philips_hue module
   Philips HUE lamps module for proxy.

   New in version 2015.8.3.

   salt.modules.pillar
   Extract the pillar data for this minion

   salt.modules.pillar.ext(external, pillar=None)
          Generate the pillar and apply an explicit external pillar

          CLI Example:

          pillar None If specified, allows for a dictionary of pillar data
                 to  be made available to pillar and ext_pillar rendering.
                 These pillar variables will also override  any  variables
                 of the same name in pillar or ext_pillar.

                 New in version 2015.5.0.

             salt '*' pillar.ext '{libvirt: _}'

   salt.modules.pillar.fetch(key,   default=<type  'exceptions.KeyError'>,
   merge=False, delimiter=':', saltenv=None)
          New in version 0.14.

          Attempt to retrieve the named value from pillar,  if  the  named
          value  is  not  available return the passed default. The default
          return       is       an       empty        string        except
          __opts__['pillar_raise_on_missing']  is  set  to  True, in which
          case a KeyError will be raised.

          If the merge parameter is set  to  True,  the  default  will  be
          recursively merged into the returned pillar data.

          The  value  can  also represent a value in a nested dict using a
          ":" delimiter for the dict. This means that if a dict in  pillar
          looks like this:

             {'pkg': {'apache': 'httpd'}}

          To  retrieve the value associated with the apache key in the pkg
          dict this key can be passed:

             pkg:apache

          merge  Specify whether or not the  retrieved  values  should  be
                 recursively merged into the passed default.

                 New in version 2014.7.0.

          delimiter
                 Specify  an  alternate delimiter to use when traversing a
                 nested dict

                 New in version 2014.7.0.

          saltenv
                 If specified, this function  will  query  the  master  to
                 generate  fresh pillar data on the fly, specifically from
                 the requested pillar  environment.  Note  that  this  can
                 produce   different   pillar  data  than  executing  this
                 function without an environment, as its  normal  behavior
                 is  just  to  return a value from minion's pillar data in
                 memory (which can be sourced from more  than  one  pillar
                 environment).

                 Using  this  argument  will not affect the pillar data in
                 memory. It will however be slightly slower and  use  more
                 resources on the master due to the need for the master to
                 generate and send the  minion  fresh  pillar  data.  This
                 tradeoff  in  performance however allows for the use case
                 where  pillar  data  is  desired  only  from   a   single
                 environment.

                 New in version Nitrogen.

          CLI Example:

             salt '*' pillar.get pkg:apache

   salt.modules.pillar.file_exists(path, saltenv=None)
          New in version 2016.3.0.

          This  is  a master-only function. Calling from the minion is not
          supported.

          Use  the  given  path  and  search  relative   to   the   pillar
          environments to see if a file exists at that path.

          If  the  saltenv  argument  is  given,  restrict  search to that
          environment only.

          Will only work with pillar_roots, not external pillars.

          Returns True if the file is found, and False otherwise.

          path   The path to the file in question. Will be  treated  as  a
                 relative path

          saltenv
                 Optional  argument  to  restrict the search to a specific
                 saltenv

          CLI Example:

             salt '*' pillar.file_exists foo/bar.sls

   salt.modules.pillar.get(key,   default=<type    'exceptions.KeyError'>,
   merge=False, delimiter=':', saltenv=None)
          New in version 0.14.

          Attempt  to  retrieve  the named value from pillar, if the named
          value is not available return the passed  default.  The  default
          return        is        an       empty       string       except
          __opts__['pillar_raise_on_missing'] is set  to  True,  in  which
          case a KeyError will be raised.

          If  the  merge  parameter  is  set  to True, the default will be
          recursively merged into the returned pillar data.

          The value can also represent a value in a nested  dict  using  a
          ":"  delimiter for the dict. This means that if a dict in pillar
          looks like this:

             {'pkg': {'apache': 'httpd'}}

          To retrieve the value associated with the apache key in the  pkg
          dict this key can be passed:

             pkg:apache

          merge  Specify  whether  or  not  the retrieved values should be
                 recursively merged into the passed default.

                 New in version 2014.7.0.

          delimiter
                 Specify an alternate delimiter to use when  traversing  a
                 nested dict

                 New in version 2014.7.0.

          saltenv
                 If  specified,  this  function  will  query the master to
                 generate fresh pillar data on the fly, specifically  from
                 the  requested  pillar  environment.  Note  that this can
                 produce  different  pillar  data  than   executing   this
                 function  without  an environment, as its normal behavior
                 is just to return a value from minion's  pillar  data  in
                 memory  (which  can  be sourced from more than one pillar
                 environment).

                 Using this argument will not affect the  pillar  data  in
                 memory.  It  will however be slightly slower and use more
                 resources on the master due to the need for the master to
                 generate  and  send  the  minion  fresh pillar data. This
                 tradeoff in performance however allows for the  use  case
                 where   pillar   data  is  desired  only  from  a  single
                 environment.

                 New in version Nitrogen.

          CLI Example:

             salt '*' pillar.get pkg:apache

   salt.modules.pillar.item(*args, **kwargs)
          New in version 0.16.2.

          Return one or more pillar entries

          pillar if specified, allows for a dictionary of pillar  data  to
                 be  made  available  to  pillar and ext_pillar rendering.
                 these pillar variables will also override  any  variables
                 of the same name in pillar or ext_pillar.

                 New in version 2015.5.0.

          CLI Examples:

             salt '*' pillar.item foo
             salt '*' pillar.item foo bar baz

   salt.modules.pillar.items(*args, **kwargs)
          Calls  the  master  for  a fresh pillar and generates the pillar
          data on the fly

          Contrast with raw()  which  returns  the  pillar  data  that  is
          currently loaded into the minion.

          pillar if  specified,  allows for a dictionary of pillar data to
                 be made available to  pillar  and  ext_pillar  rendering.
                 these  pillar  variables will also override any variables
                 of the same name in pillar or ext_pillar.

                 New in version 2015.5.0.

          saltenv
                 Pass a specific pillar environment from which to  compile
                 pillar  data.   If  unspecified, the minion's environment
                 option is used, and if that also is  not  specified  then
                 all  configured pillar environments will be merged into a
                 single pillar dictionary and returned.

                 New in version Nitrogen.

          CLI Example:

             salt '*' pillar.items

   salt.modules.pillar.keys(key, delimiter=':')
          New in version 2015.8.0.

          Attempt to retrieve a list of keys from the named value from the
          pillar.

          The  value  can  also represent a value in a nested dict using a
          ":" delimiter for the dict, similar to how pillar.get works.

          delimiter
                 Specify an alternate delimiter to use when  traversing  a
                 nested dict

          CLI Example:

             salt '*' pillar.keys web:sites

   salt.modules.pillar.ls(*args)
          New in version 2015.8.0.

          Calls  the  master for a fresh pillar, generates the pillar data
          on the fly (same as items()), but only shows the available  main
          keys.

          CLI Examples:

             salt '*' pillar.ls

   salt.modules.pillar.obfuscate(*args)
          New in version 2015.8.0.

          Same  as  items(),  but replace pillar values with a simple type
          indication.

          This is useful to  avoid  displaying  sensitive  information  on
          console  or  flooding  the  console  with  long  output, such as
          certificates.  For many debug or control  purposes,  the  stakes
          lie more in dispatching than in actual values.

          In  case  the  value  is  itself  a collection type, obfuscation
          occurs within the  value.   For  mapping  types,  keys  are  not
          obfuscated.  Here are some examples:

          * 'secret password' becomes '<str>'

          * ['secret', 1] becomes ['<str>', '<int>']

          * {'login':  'somelogin',  'pwd':  'secret'}  becomes  {'login':
            '<str>', 'pwd': '<str>'}

          CLI Examples:

             salt '*' pillar.obfuscate

   salt.modules.pillar.raw(key=None)
          Return the raw pillar data that is  currently  loaded  into  the
          minion.

          Contrast  with  items() which calls the master to fetch the most
          up-to-date Pillar.

          CLI Example:

             salt '*' pillar.raw

          With the optional key argument, you can select a subtree of  the
          pillar raw data.:

             salt '*' pillar.raw key='roles'

   salt.modules.pip
   Install Python packages with pip to either the system or a virtualenv

   Windows Support
   New in version 2014.7.4.

   Salt  now  uses a portable python. As a result the entire pip module is
   now functional on the salt installation itself.  You  can  pip  install
   dependencies  for your custom modules. You can even upgrade salt itself
   using pip. For this to work properly,  you  must  specify  the  Current
   Working  Directory  (cwd) and the Pip Binary (bin_env) salt should use.
   The variable pip_bin can be either a virtualenv path or the path to the
   pip binary itself.

   For  example,  the  following  command will list all software installed
   using pip to your current salt environment:

      salt <minion> pip.list cwd='C:\salt	in\Scripts' bin_env='C:\salt	in\Scripts\pip.exe'

   Specifying the cwd and bin_env options  ensures  you're  modifying  the
   salt  environment.  If  these are omitted, it will default to the local
   installation of python. If python is not installed locally it will fail
   saying it couldn't find pip.

   State File Support
   This  functionality works in states as well. If you need to pip install
   colorama with a state, for example, the following will work:

      install_colorama:
        pip.installed:
          - name: colorama
          - cwd: 'C:\salt	in\scripts'
          - bin_env: 'C:\salt	in\scripts\pip.exe'
          - upgrade: True

   Upgrading Salt using Pip
   You can now update salt using pip to any version from the 2014.7 branch
   forward.  Previous version require recompiling some of the dependencies
   which is painful in windows.

   To do this you just use pip with git to update to the version you  want
   and then restart the service. Here is a sample state file that upgrades
   salt to the head of the 2015.5 branch:

      install_salt:
        pip.installed:
          - cwd: 'C:\salt	in\scripts'
          - bin_env: 'C:\salt	in\scripts\pip.exe'
          - editable: git+https://github.com/saltstack/[email protected]#egg=salt
          - upgrade: True

      restart_service:
        service.running:
          - name: salt-minion
          - enable: True
          - watch:
            - pip: install_salt

   NOTE:
      If you're having problems, you might try doubling the back  slashes.
      For example, cwd: 'C:\salt	in\scripts'. Sometimes python thinks the
      single back slash is an escape character.

   salt.modules.pip.freeze(bin_env=None,       user=None,        cwd=None,
   use_vt=False)
          Return  a  list  of installed packages either globally or in the
          specified virtualenv

          bin_env
                 path to pip bin  or  path  to  virtualenv.  If  doing  an
                 uninstall  from  the  system  python  and  want  to use a
                 specific pip bin (pip-2.7, pip-2.6, etc..)  just  specify
                 the pip bin you want.  If uninstalling from a virtualenv,
                 just    use    the     path     to     the     virtualenv
                 (/home/code/path/to/virtualenv/)

          user   The user under which to run pip

          cwd    Current working directory to run pip from

          CLI Example:

             salt '*' pip.freeze /home/code/path/to/virtualenv/

   salt.modules.pip.install(pkgs=None,   requirements=None,  bin_env=None,
   use_wheel=False,     no_use_wheel=False,     log=None,      proxy=None,
   timeout=None,     editable=None,    find_links=None,    index_url=None,
   extra_index_url=None,   no_index=False,    mirrors=None,    build=None,
   target=None,     download=None,    download_cache=None,    source=None,
   upgrade=False,      force_reinstall=False,      ignore_installed=False,
   exists_action=None, no_deps=False, no_install=False, no_download=False,
   global_options=None, install_options=None,  user=None,  no_chown=False,
   cwd=None,   pre_releases=False,   cert=None,  allow_all_external=False,
   allow_external=None,                             allow_unverified=None,
   process_dependency_links=False,      saltenv='base',     env_vars=None,
   use_vt=False, trusted_host=None, no_cache_dir=False)
          Install packages with pip

          Install packages individually or from a pip  requirements  file.
          Install packages globally or to a virtualenv.

          pkgs   Comma separated list of packages to install

          requirements
                 Path to requirements

          bin_env
                 Path  to pip bin or path to virtualenv. If doing a system
                 install, and want to use a  specific  pip  bin  (pip-2.7,
                 pip-2.6, etc..) just specify the pip bin you want.

                 NOTE:
                    If  installing into a virtualenv, just use the path to
                    the virtualenv (e.g. /home/code/path/to/virtualenv/)

          use_wheel
                 Prefer wheel archives (requires pip>=1.4)

          no_use_wheel
                 Force to not use wheel archives (requires pip>=1.4)

          log    Log file where a complete (maximum verbosity) record will
                 be kept

          proxy  Specify       a       proxy       in       the       form
                 user:[email protected]:port.     Note     that      the
                 user:password@  is  optional and required only if you are
                 behind   an   authenticated   proxy.   If   you   provide
                 [email protected]:port  then  you  will be prompted for a
                 password.

          timeout
                 Set the socket timeout (default 15 seconds)

          editable
                 install         something         editable          (e.g.
                 git+https://github.com/worldcompany/djangoembed.git#egg=djangoembed)

          find_links
                 URL to search for packages

          index_url
                 Base URL of Python Package Index

          extra_index_url
                 Extra URLs of package  indexes  to  use  in  addition  to
                 index_url

          no_index
                 Ignore package index

          mirrors
                 Specific  mirror  URL(s)  to  query  (automatically  adds
                 --use-mirrors)

                 WARNING:
                    This option has been deprecated  and  removed  in  pip
                    version    7.0.0.    Please   use   index_url   and/or
                    extra_index_url instead.

          build  Unpack packages into build dir

          target Install packages into target dir

          download
                 Download packages into  download  instead  of  installing
                 them

          download_cache
                 Cache downloaded packages in download_cache dir

          source Check out editable packages into source dir

          upgrade
                 Upgrade all packages to the newest available version

          force_reinstall
                 When  upgrading,  reinstall all packages even if they are
                 already up-to-date.

          ignore_installed
                 Ignore the installed packages (reinstalling instead)

          exists_action
                 Default action when  a  path  already  exists:  (s)witch,
                 (i)gnore, (w)ipe, (b)ackup

          no_deps
                 Ignore package dependencies

          no_install
                 Download  and  unpack  all  packages,  but don't actually
                 install them

          no_download
                 Don't  download  any  packages,  just  install  the  ones
                 already   downloaded   (completes  an  install  run  with
                 --no-install)

          install_options
                 Extra arguments to be supplied to  the  setup.py  install
                 command                    (e.g.                     like
                 --install-option='--install-scripts=/usr/local/bin').
                 Use  multiple  --install-option  options to pass multiple
                 options to setup.py install. If you are using  an  option
                 with a directory path, be sure to use absolute path.

          global_options
                 Extra  global options to be supplied to the setup.py call
                 before the install command.

          user   The user under which to run pip

          no_chown
                 When user is given, do not attempt to copy  and  chown  a
                 requirements file

          cwd    Current working directory to run pip from

          pre_releases
                 Include pre-releases in the available versions

          cert   Provide a path to an alternate CA bundle

          allow_all_external
                 Allow the installation of all externally hosted files

          allow_external
                 Allow  the installation of externally hosted files (comma
                 separated list)

          allow_unverified
                 Allow the installation of insecure and unverifiable files
                 (comma separated list)

          process_dependency_links
                 Enable the processing of dependency links

          env_vars
                 Set  environment  variables  that some builds will depend
                 on. For example, a Python C-module may  have  a  Makefile
                 that  needs  INCLUDE_PATH  set  to  pick up a header file
                 while  compiling.   This  must  be  in  the  form  of   a
                 dictionary or a mapping.

                 Example:

                    salt '*' pip.install django_app env_vars="{'CUSTOM_PATH': '/opt/django_app'}"

          trusted_host
                 Mark  this  host as trusted, even though it does not have
                 valid or any HTTPS.

          use_vt Use VT terminal emulation (see output while installing)

          no_cache_dir
                 Disable the cache.

          CLI Example:

             salt '*' pip.install <package name>,<package2 name>
             salt '*' pip.install requirements=/path/to/requirements.txt
             salt '*' pip.install <package name> bin_env=/path/to/virtualenv
             salt '*' pip.install <package name> bin_env=/path/to/pip_bin

          Complicated CLI example:

             salt '*' pip.install markdown,django                 editable=git+https://github.com/worldcompany/djangoembed.git#egg=djangoembed upgrade=True no_deps=True

   salt.modules.pip.list(prefix=None, bin_env=None, user=None, cwd=None)
          Filter list of installed apps from freeze and check  to  see  if
          prefix exists in the list of packages installed.

          CLI Example:

             salt '*' pip.list salt

   salt.modules.pip.list_upgrades(bin_env=None, user=None, cwd=None)
          Check whether or not an upgrade is available for all packages

          CLI Example:

             salt '*' pip.list_upgrades

   salt.modules.pip.uninstall(pkgs=None,  requirements=None, bin_env=None,
   log=None,   proxy=None,   timeout=None,   user=None,    no_chown=False,
   cwd=None, saltenv='base', use_vt=False)
          Uninstall packages with pip

          Uninstall packages individually or from a pip requirements file.
          Uninstall packages globally or from a virtualenv.

          pkgs   comma separated list of packages to install

          requirements
                 path to requirements.

          bin_env
                 path to pip bin  or  path  to  virtualenv.  If  doing  an
                 uninstall  from  the  system  python  and  want  to use a
                 specific pip bin (pip-2.7, pip-2.6, etc..)  just  specify
                 the pip bin you want.  If uninstalling from a virtualenv,
                 just    use    the     path     to     the     virtualenv
                 (/home/code/path/to/virtualenv/)

          log    Log file where a complete (maximum verbosity) record will
                 be kept

          proxy  Specify       a       proxy       in       the       form
                 user:[email protected]:port.      Note     that     the
                 user:password@ is optional and required only if  you  are
                 behind   an   authenticated   proxy.    If   you  provide
                 [email protected]:port then you will be  prompted  for  a
                 password.

          timeout
                 Set the socket timeout (default 15 seconds)

          user   The user under which to run pip

          no_chown
                 When  user  is  given, do not attempt to copy and chown a
                 requirements file (needed if the requirements file refers
                 to  other files via relative paths, as the copy-and-chown
                 procedure does not account for such files)

          cwd    Current working directory to run pip from

          use_vt Use VT terminal emulation (see output while installing)

          CLI Example:

             salt '*' pip.uninstall <package name>,<package2 name>
             salt '*' pip.uninstall requirements=/path/to/requirements.txt
             salt '*' pip.uninstall <package name> bin_env=/path/to/virtualenv
             salt '*' pip.uninstall <package name> bin_env=/path/to/pip_bin

   salt.modules.pip.upgrade(bin_env=None,       user=None,       cwd=None,
   use_vt=False)
          New in version 2015.5.0.

          Upgrades outdated pip packages

          Returns a dict containing the changes.

             {'<package>': {'old': '<old-version>',
                    'new': '<new-version>'}}

          CLI Example:

             salt '*' pip.upgrade

   salt.modules.pip.upgrade_available(pkg,     bin_env=None,    user=None,
   cwd=None)
          New in version 2015.5.0.

          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pip.upgrade_available <package name>

   salt.modules.pip.version(bin_env=None)
          New in version 0.17.0.

          Returns the version of pip. Use bin_env to specify the path to a
          virtualenv and get the version of pip in that virtualenv.

          If unable to detect the pip version, returns None.

          CLI Example:

             salt '*' pip.version

   salt.modules.pkg_resource
   Resources needed by pkg providers

   salt.modules.pkg_resource.add_pkg(pkgs, name, pkgver)
          Add a package to a dict of installed packages.

          CLI Example:

             salt '*' pkg_resource.add_pkg '{}' bind 9

   salt.modules.pkg_resource.check_extra_requirements(pkgname, pkgver)
          Check   if   the   installed   package  already  has  the  given
          requirements.   This  function  will  return   the   result   of
          pkg.check_extra_requirements  if  this  function  exists for the
          minion, otherwise it will return True.

          CLI Example:

             salt '*' pkg_resource.check_extra_requirements <pkgname> <extra_requirements>

   salt.modules.pkg_resource.pack_sources(sources, normalize=True)
          Accepts list of dicts (or a string representing a list of dicts)
          and packs the key/value pairs into a single dict.

          '[{"foo":  "salt://foo.rpm"},  {"bar": "salt://bar.rpm"}]' would
          become {"foo": "salt://foo.rpm", "bar": "salt://bar.rpm"}

          normalize
                 True  Normalize  the  package  name   by   removing   the
                 architecture,  if  the  architecture  of  the  package is
                 different from the architecture of the operating  system.
                 The  ability  to  disable  this  behavior  is  useful for
                 poorly-created packages which include the architecture as
                 an  actual part of the name, such as kernel modules which
                 match a specific kernel version.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' pkg_resource.pack_sources '[{"foo": "salt://foo.rpm"}, {"bar": "salt://bar.rpm"}]'

   salt.modules.pkg_resource.parse_targets(name=None,           pkgs=None,
   sources=None, saltenv='base', normalize=True, **kwargs)
          Parses  the input to pkg.install and returns back the package(s)
          to be installed. Returns a list of packages, as well as a string
          noting  whether  the packages are to come from a repository or a
          binary package.

          CLI Example:

             salt '*' pkg_resource.parse_targets

   salt.modules.pkg_resource.sort_pkglist(pkgs)
          Accepts a dict obtained from pkg.list_pkgs() and sorts in  place
          the  list  of  versions  for  any  packages  that  have multiple
          versions installed, so that two package lists can be compared to
          one another.

          CLI Example:

             salt '*' pkg_resource.sort_pkglist '["3.45", "2.13"]'

   salt.modules.pkg_resource.stringify(pkgs)
          Takes  a dict of package name/version information and joins each
          list of installed versions into a string.

          CLI Example:

             salt '*' pkg_resource.stringify 'vim: 7.127'

   salt.modules.pkg_resource.version(*names, **kwargs)
          Common  interface  for  obtaining  the  version   of   installed
          packages.

          CLI Example:

             salt '*' pkg_resource.version vim
             salt '*' pkg_resource.version foo bar baz
             salt '*' pkg_resource.version 'python*'

   salt.modules.pkg_resource.version_clean(verstr)
          Clean  the  version  string  removing extra data.  This function
          will simply try to call pkg.version_clean.

          CLI Example:

             salt '*' pkg_resource.version_clean <version_string>

   salt.modules.pkgin
   Package support for  pkgin  based  systems,  inspired  from  freebsdpkg
   module

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   salt.modules.pkgin.available_version(*names, **kwargs)
          This function is an alias of latest_version.
             Return  the latest version of the named package available for
             upgrade or installation.

             If  the  latest  version  of  a  given  package  is   already
             installed, an empty string will be returned for that package.

             CLI Example:

                 salt '*' pkg.latest_version <package name>
                 salt '*' pkg.latest_version <package1> <package2> ...

   salt.modules.pkgin.file_dict(*packages)
          List the files that belong to a package.

          CLI Examples:

             salt '*' pkg.file_dict nginx
             salt '*' pkg.file_dict nginx varnish

   salt.modules.pkgin.file_list(package)
          List the files that belong to a package.

          CLI Examples:

             salt '*' pkg.file_list nginx

   salt.modules.pkgin.install(name=None,   refresh=False,   fromrepo=None,
   pkgs=None, sources=None, **kwargs)
          Install the passed package

          name   The name of the package to be installed.

          refresh
                 Whether or not to refresh  the  package  database  before
                 installing.

          fromrepo
                 Specify a package repository to install from.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must be passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo","bar"]'

          sources
                 A list of packages to install. Must be passed as  a  list
                 of  dicts,  with  the  keys  being package names, and the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.deb"},{"bar": "salt://bar.deb"}]'

          Return a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.install <package name>

   salt.modules.pkgin.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade or installation.

          If  the  latest version of a given package is already installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> ...

   salt.modules.pkgin.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.pkgin.purge(name=None, pkgs=None, **kwargs)
          Package purges are not supported, this function is identical  to
          remove().

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.pkgin.refresh_db()
          Use pkg update to get latest pkg_summary

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.pkgin.remove(name=None, pkgs=None, **kwargs)

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a list containing the removed packages.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.pkgin.search(pkg_name)
          Searches for an exact match using pkgin ^package$

          CLI Example:

             salt '*' pkg.search 'mysql-server'

   salt.modules.pkgin.upgrade()
          Run pkg upgrade, if pkgin used. Otherwise do nothing

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.pkgin.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          string if not installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.pkgng
   Support for pkgng, the new package manager for FreeBSD

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   WARNING:
      This  module  has  been  completely  rewritten.  Up to and including
      version  0.17.x,   it   was   available   as   the   pkgng   module,
      (pkgng.install,  pkgng.delete, etc.), but moving forward this module
      will no longer be available as pkgng,  as  it  will  behave  like  a
      normal  Salt  pkg  provider.  The  documentation below should not be
      considered to apply to this module in versions <=  0.17.x.  If  your
      minion  is running a 0.17.x release or older, then the documentation
      for this module can be viewed using the sys.doc function:

          salt bsdminion sys.doc pkgng

   This module provides an interface to pkg(8). It  acts  as  the  default
   package provider for FreeBSD 10 and newer. For FreeBSD hosts which have
   been upgraded to use pkgng, you will need to override the pkg  provider
   by setting the providers parameter in your Minion config file, in order
   to use this module to manage packages, like so:

      providers:
        pkg: pkgng

   salt.modules.pkgng.audit(jail=None, chroot=None, root=None)
          Audits installed packages against known vulnerabilities

          CLI Example:

             salt '*' pkg.audit

          jail   Audit packages within the specified jail

                 CLI Example:

                    salt '*' pkg.audit jail=<jail name or id>

          chroot Audit packages within the specified  chroot  (ignored  if
                 jail is specified)

          root   Audit packages within the specified root (ignored if jail
                 is specified)

                 CLI Example:

                    salt '*' pkg.audit chroot=/path/to/chroot

   salt.modules.pkgng.autoremove(jail=None,    chroot=None,     root=None,
   dryrun=False)
          Delete   packages   which   were   automatically   installed  as
          dependencies and are not required anymore.

          dryrun Dry-run mode. The list of changes to packages  is  always
                 printed, but no changes are actually made.

          CLI Example:

             salt '*' pkg.autoremove
             salt '*' pkg.autoremove jail=<jail name or id>
             salt '*' pkg.autoremove dryrun=True
             salt '*' pkg.autoremove jail=<jail name or id> dryrun=True

   salt.modules.pkgng.backup(file_name, jail=None, chroot=None, root=None)
          Export installed packages into yaml+mtree file

          CLI Example:

             salt '*' pkg.backup /tmp/pkg

          jail   Backup  packages  from the specified jail. Note that this
                 will run the command within the jail, and so the path  to
                 the backup file will be relative to the root of the jail

                 CLI Example:

                    salt '*' pkg.backup /tmp/pkg jail=<jail name or id>

          chroot Backup  packages  from  the  specified chroot (ignored if
                 jail is specified). Note that this will run  the  command
                 within  the  chroot,  and  so the path to the backup file
                 will be relative to the root of the chroot.

          root   Backup packages from the specified root (ignored if  jail
                 is specified). Note that this will run the command within
                 the root, and so the path to  the  backup  file  will  be
                 relative to the root of the root.

                 CLI Example:

                    salt '*' pkg.backup /tmp/pkg chroot=/path/to/chroot

   salt.modules.pkgng.check(jail=None,       chroot=None,       root=None,
   depends=False, recompute=False, checksum=False)
          Sanity checks installed packages

          jail   Perform the sanity check in the specified jail

                 CLI Example:

                    salt '*' pkg.check jail=<jail name or id>

          chroot Perform the sanity check in the specified chroot (ignored
                 if jail is specified)

          root   Perform  the  sanity check in the specified root (ignored
                 if jail is specified)

                 CLI Example:

                    salt '*' pkg.check chroot=/path/to/chroot

          Of the below, at least one must be set to True.

          depends
                 Check for and install missing dependencies.

                 CLI Example:

                    salt '*' pkg.check recompute=True

          recompute
                 Recompute sizes and checksums of installed packages.

                 CLI Example:

                    salt '*' pkg.check depends=True

          checksum
                 Find invalid checksums for installed packages.

                 CLI Example:

                    salt '*' pkg.check checksum=True

   salt.modules.pkgng.clean(jail=None, chroot=None, root=None)
          Cleans the local cache of fetched remote packages

          CLI Example:

             salt '*' pkg.clean
             salt '*' pkg.clean jail=<jail name or id>
             salt '*' pkg.clean chroot=/path/to/chroot

   salt.modules.pkgng.fetch(name,   jail=None,   chroot=None,   root=None,
   fetch_all=False,  quiet=False,  fromrepo=None,  glob=True, regex=False,
   pcre=False, local=False, depends=False)
          Fetches remote packages

          CLI Example:

             salt '*' pkg.fetch <package name>

          jail   Fetch package in the specified jail

                 CLI Example:

                    salt '*' pkg.fetch <package name> jail=<jail name or id>

          chroot Fetch package in the specified chroot (ignored if jail is
                 specified)

          root   Fetch  package  in the specified root (ignored if jail is
                 specified)

                 CLI Example:

                    salt '*' pkg.fetch <package name> chroot=/path/to/chroot

          fetch_all
                 Fetch all packages.

                 CLI Example:

                    salt '*' pkg.fetch <package name> fetch_all=True

          quiet  Quiet mode. Show less output.

                 CLI Example:

                    salt '*' pkg.fetch <package name> quiet=True

          fromrepo
                 Fetches packages from the given  repo  if  multiple  repo
                 support is enabled. See pkg.conf(5).

                 CLI Example:

                    salt '*' pkg.fetch <package name> fromrepo=repo

          glob   Treat pkg_name as a shell glob pattern.

                 CLI Example:

                    salt '*' pkg.fetch <package name> glob=True

          regex  Treat pkg_name as a regular expression.

                 CLI Example:

                    salt '*' pkg.fetch <regular expression> regex=True

          pcre   Treat pkg_name is an extended regular expression.

                 CLI Example:

                    salt '*' pkg.fetch <extended regular expression> pcre=True

          local  Skip updating the repository catalogs with pkg-update(8).
                 Use the local cache only.

                 CLI Example:

                    salt '*' pkg.fetch <package name> local=True

          depends
                 Fetch the package and its dependencies as well.

                 CLI Example:

                    salt '*' pkg.fetch <package name> depends=True

   salt.modules.pkgng.install(name=None,     fromrepo=None,     pkgs=None,
   sources=None,    jail=None,   chroot=None,   root=None,   orphan=False,
   force=False,  glob=False,   local=False,   dryrun=False,   quiet=False,
   reinstall_requires=False, regex=False, pcre=False, **kwargs)
          Install package(s) from a repository

          name   The name of the package to install

                 CLI Example:

                    salt '*' pkg.install <package name>

          jail   Install the package into the specified jail

          chroot Install the package into the specified chroot (ignored if
                 jail is specified)

          root   Install the package into the specified root  (ignored  if
                 jail is specified)

          orphan Mark   the   installed   package   as   orphan.  Will  be
                 automatically removed if  no  other  packages  depend  on
                 them.    For    more    information   please   refer   to
                 pkg-autoremove(8).

                 CLI Example:

                    salt '*' pkg.install <package name> orphan=True

          force  Force  the  reinstallation  of  the  package  if  already
                 installed.

                 CLI Example:

                    salt '*' pkg.install <package name> force=True

          glob   Treat the package names as shell glob patterns.

                 CLI Example:

                    salt '*' pkg.install <package name> glob=True

          local  Do not update the repository catalogs with pkg-update(8).
                 A value of True here is equivalent to using the  -U  flag
                 with pkg install.

                 CLI Example:

                    salt '*' pkg.install <package name> local=True

          dryrun Dru-run  mode.  The list of changes to packages is always
                 printed, but no changes are actually made.

                 CLI Example:

                    salt '*' pkg.install <package name> dryrun=True

          quiet  Force quiet output, except when dryrun is used, where pkg
                 install  will  always  show  packages  to  be  installed,
                 upgraded or deleted.

                 CLI Example:

                    salt '*' pkg.install <package name> quiet=True

          reinstall_requires
                 When  used  with  force,  reinstalls  any  packages  that
                 require the given package.

                 CLI Example:

                    salt '*' pkg.install <package name> reinstall_requires=True force=True

                 Changed  in  version  2014.7.0:  require kwarg renamed to
                 reinstall_requires

          fromrepo
                 In multi-repo mode, override the  pkg.conf  ordering  and
                 only   attempt   to  download  packages  from  the  named
                 repository.

                 CLI Example:

                    salt '*' pkg.install <package name> fromrepo=repo

          regex  Treat the package names as a regular expression

                 CLI Example:

                    salt '*' pkg.install <regular expression> regex=True

          pcre   Treat the package names as extended regular expressions.

                 CLI Example:

                    salt '*' pkg.install <extended regular expression> pcre=True

   salt.modules.pkgng.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package name> jail=<jail name or id>
             salt '*' pkg.latest_version <package name> chroot=/path/to/chroot

   salt.modules.pkgng.list_pkgs(versions_as_list=False,         jail=None,
   chroot=None, root=None, with_origin=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          jail   List the packages in the specified jail

          chroot List the packages in the  specified  chroot  (ignored  if
                 jail is specified)

          root   List  the packages in the specified root (ignored if jail
                 is specified)

          with_origin
                 False Return a  nested  dictionary  containing  both  the
                 origin name and version for each installed package.

                 New in version 2014.1.0.

          CLI Example:

             salt '*' pkg.list_pkgs
             salt '*' pkg.list_pkgs jail=<jail name or id>
             salt '*' pkg.list_pkgs chroot=/path/to/chroot

   salt.modules.pkgng.parse_config(file_name='/usr/local/etc/pkg.conf')
          Return dict of uncommented global variables.

          CLI Example:

             salt '*' pkg.parse_config

          NOTE: not working properly right now

   salt.modules.pkgng.refresh_db(jail=None,     chroot=None,    root=None,
   force=False)
          Refresh PACKAGESITE contents

          NOTE:
             This function can accessed using pkg.update  in  addition  to
             pkg.refresh_db,  to  more  closely  match  the  CLI  usage of
             pkg(8).

          CLI Example:

             salt '*' pkg.refresh_db

          jail   Refresh the pkg database within the specified jail

          chroot Refresh the pkg  database  within  the  specified  chroot
                 (ignored if jail is specified)

          root   Refresh  the  pkg  database  within  the  specified  root
                 (ignored if jail is specified)

          force  Force a full download of the repository  catalog  without
                 regard  to  the  respective  ages of the local and remote
                 copies of the catalog.

                 CLI Example:

                    salt '*' pkg.refresh_db force=True

   salt.modules.pkgng.remove(name=None, pkgs=None, jail=None, chroot=None,
   root=None,  all_installed=False, force=False, glob=False, dryrun=False,
   recurse=False, regex=False, pcre=False, **kwargs)
          Remove a package from the database and system

          NOTE:
             This function can accessed using pkg.delete  in  addition  to
             pkg.remove, to more closely match the CLI usage of pkg(8).

          name   The package to remove

                 CLI Example:

                    salt '*' pkg.remove <package name>

          jail   Delete the package from the specified jail

          chroot Delete  the package from the specified chroot (ignored if
                 jail is specified)

          root   Delete the package from the specified  root  (ignored  if
                 jail is specified)

          all_installed
                 Deletes  all  installed  packages  from  the  system  and
                 empties the database. USE WITH CAUTION!

                 CLI Example:

                    salt '*' pkg.remove all all_installed=True force=True

          force  Forces packages to be removed despite leaving  unresolved
                 dependencies.

                 CLI Example:

                    salt '*' pkg.remove <package name> force=True

          glob   Treat the package names as shell glob patterns.

                 CLI Example:

                    salt '*' pkg.remove <package name> glob=True

          dryrun Dry  run  mode.  The list of packages to delete is always
                 printed, but no packages are actually deleted.

                 CLI Example:

                    salt '*' pkg.remove <package name> dryrun=True

          recurse
                 Delete all packages that require the  listed  package  as
                 well.

                 CLI Example:

                    salt '*' pkg.remove <package name> recurse=True

          regex  Treat the package names as regular expressions.

                 CLI Example:

                    salt '*' pkg.remove <regular expression> regex=True

          pcre   Treat the package names as extended regular expressions.

                 CLI Example:

                    salt '*' pkg.remove <extended regular expression> pcre=True

   salt.modules.pkgng.restore(file_name,      jail=None,      chroot=None,
   root=None)
          Reads archive  created  by  pkg  backup  -d  and  recreates  the
          database.

          CLI Example:

             salt '*' pkg.restore /tmp/pkg

          jail   Restore  database  to  the specified jail. Note that this
                 will run the command within the jail, and so the path  to
                 the  file from which the pkg database will be restored is
                 relative to the root of the jail.

                 CLI Example:

                    salt '*' pkg.restore /tmp/pkg jail=<jail name or id>

          chroot Restore database to the specified chroot (ignored if jail
                 is specified). Note that this will run the command within
                 the chroot, and so the path to the file  from  which  the
                 pkg  database will be restored is relative to the root of
                 the chroot.

          root   Restore database to the specified root (ignored  if  jail
                 is specified). Note that this will run the command within
                 the root, and so the path to the file from which the  pkg
                 database  will be restored is relative to the root of the
                 root.

                 CLI Example:

                    salt '*' pkg.restore /tmp/pkg chroot=/path/to/chroot

   salt.modules.pkgng.search(name,  jail=None,   chroot=None,   root=None,
   exact=False,   glob=False,   regex=False,   pcre=False,  comment=False,
   desc=False,   full=False,   depends=False,   size=False,   quiet=False,
   origin=False, prefix=False)
          Searches in remote package repositories

          CLI Example:

             salt '*' pkg.search pattern

          jail   Perform   the  search  using  the  pkg.conf(5)  from  the
                 specified jail

                 CLI Example:

                    salt '*' pkg.search pattern jail=<jail name or id>

          chroot Perform  the  search  using  the  pkg.conf(5)  from   the
                 specified chroot (ignored if jail is specified)

          root   Perform   the  search  using  the  pkg.conf(5)  from  the
                 specified root (ignored if jail is specified)

                 CLI Example:

                    salt '*' pkg.search pattern chroot=/path/to/chroot

          exact  Treat pattern as exact pattern.

                 CLI Example:

                    salt '*' pkg.search pattern exact=True

          glob   Treat pattern as a shell glob pattern.

                 CLI Example:

                    salt '*' pkg.search pattern glob=True

          regex  Treat pattern as a regular expression.

                 CLI Example:

                    salt '*' pkg.search pattern regex=True

          pcre   Treat pattern as an extended regular expression.

                 CLI Example:

                    salt '*' pkg.search pattern pcre=True

          comment
                 Search  for  pattern  in  the  package  comment  one-line
                 description.

                 CLI Example:

                    salt '*' pkg.search pattern comment=True

          desc   Search for pattern in the package description.

                 CLI Example:

                    salt '*' pkg.search pattern desc=True

          full   Displays full information about the matching packages.

                 CLI Example:

                    salt '*' pkg.search pattern full=True

          depends
                 Displays the dependencies of pattern.

                 CLI Example:

                    salt '*' pkg.search pattern depends=True

          size   Displays the size of the package

                 CLI Example:

                    salt '*' pkg.search pattern size=True

          quiet  Be  quiet.  Prints only the requested information without
                 displaying many hints.

                 CLI Example:

                    salt '*' pkg.search pattern quiet=True

          origin Displays pattern origin.

                 CLI Example:

                    salt '*' pkg.search pattern origin=True

          prefix Displays  the  installation  prefix  for   each   package
                 matching pattern.

                 CLI Example:

                    salt '*' pkg.search pattern prefix=True

   salt.modules.pkgng.stats(local=False,      remote=False,     jail=None,
   chroot=None, root=None)
          Return pkgng stats.

          CLI Example:

             salt '*' pkg.stats

          local  Display stats only for the local package database.

                 CLI Example:

                    salt '*' pkg.stats local=True

          remote Display stats only for the remote package database(s).

                 CLI Example:

                    salt '*' pkg.stats remote=True

          jail   Retrieve stats from the specified jail.

                 CLI Example:

                    salt '*' pkg.stats jail=<jail name or id>
                    salt '*' pkg.stats jail=<jail name or id> local=True
                    salt '*' pkg.stats jail=<jail name or id> remote=True

          chroot Retrieve stats from the specified chroot (ignored if jail
                 is specified).

          root   Retrieve  stats  from the specified root (ignored if jail
                 is specified).

                 CLI Example:

                    salt '*' pkg.stats chroot=/path/to/chroot
                    salt '*' pkg.stats chroot=/path/to/chroot local=True
                    salt '*' pkg.stats chroot=/path/to/chroot remote=True

   salt.modules.pkgng.update_package_site(new_url)
          Updates remote package repo URL, PACKAGESITE var to be exact.

          Must use http://, ftp://, or https:// protocol

          CLI Example:

             salt '*' pkg.update_package_site http://127.0.0.1/

   salt.modules.pkgng.updating(name,  jail=None,  chroot=None,  root=None,
   filedate=None, filename=None)
          ' Displays UPDATING entries of software packages

          CLI Example:

             salt '*' pkg.updating foo

          jail   Perform the action in the specified jail

                 CLI Example:

                    salt '*' pkg.updating foo jail=<jail name or id>

          chroot Perform  the  action  in the specified chroot (ignored if
                 jail is specified)

          root   Perform the action in the specified root (ignored if jail
                 is specified)

                 CLI Example:

                    salt '*' pkg.updating foo chroot=/path/to/chroot

          filedate
                 Only  entries  newer  than date are shown. Use a YYYYMMDD
                 date format.

                 CLI Example:

                    salt '*' pkg.updating foo filedate=20130101

          filename
                 Defines an alternative location of the UPDATING file.

                 CLI Example:

                    salt '*' pkg.updating foo filename=/tmp/UPDATING

   salt.modules.pkgng.upgrade(*names, **kwargs)
          Upgrade named or all packages (run a pkg upgrade).  If  <package
          name> is omitted, the operation is executed on all packages.

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade <package name>

          jail   Audit packages within the specified jail

                 CLI Example:

                    salt '*' pkg.upgrade <package name> jail=<jail name or id>

          chroot Audit  packages  within  the specified chroot (ignored if
                 jail is specified)

          root   Audit packages within the specified root (ignored if jail
                 is specified)

                 CLI Example:

                    salt '*' pkg.upgrade <package name> chroot=/path/to/chroot

          Any of the below options can also be used with jail or chroot.

          force  Force reinstalling/upgrading the whole set of packages.

                 CLI Example:

                    salt '*' pkg.upgrade <package name> force=True

          local  Do not update the repository catalogs with pkg-update(8).
                 A value of True here is equivalent to using the  -U  flag
                 with pkg upgrade.

                 CLI Example:

                    salt '*' pkg.upgrade <package name> local=True

          dryrun Dry-run  mode: show what packages have updates available,
                 but do not perform any upgrades. Repository catalogs will
                 be  updated  as  usual  unless  the  local option is also
                 given.

                 CLI Example:

                    salt '*' pkg.upgrade <package name> dryrun=True

   salt.modules.pkgng.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          NOTE:
             This function can accessed  using  pkg.info  in  addition  to
             pkg.version, to more closely match the CLI usage of pkg(8).

          jail   Get package version information for the specified jail

          chroot Get  package version information for the specified chroot
                 (ignored if jail is specified)

          root   Get package version information for  the  specified  root
                 (ignored if jail is specified)

          with_origin
                 False  Return  a  nested  dictionary  containing both the
                 origin name and version for each specified package.

                 New in version 2014.1.0.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package name> jail=<jail name or id>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.pkgng.version_cmp(pkg1, pkg2, ignore_epoch=False)
          Do a cmp-style comparison on two packages. Return -1 if  pkg1  <
          pkg2,  0  if  pkg1 == pkg2, and 1 if pkg1 > pkg2. Return None if
          there was a problem making the comparison.

          CLI Example:

             salt '*' pkg.version_cmp '2.1.11' '2.1.12'

   salt.modules.pkgng.which(path,   jail=None,   chroot=None,   root=None,
   origin=False, quiet=False)
          Displays which package installed a specific file

          CLI Example:

             salt '*' pkg.which <file name>

          jail   Perform the check in the specified jail

                 CLI Example:

                    salt '*' pkg.which <file name> jail=<jail name or id>

          chroot Perform  the  check  in  the specified chroot (ignored if
                 jail is specified)

          root   Perform the check in the specified root (ignored if  jail
                 is specified)

                 CLI Example:

                    salt '*' pkg.which <file name> chroot=/path/to/chroot

          origin Shows the origin of the package instead of name-version.

                 CLI Example:

                    salt '*' pkg.which <file name> origin=True

          quiet  Quiet output.

                 CLI Example:

                    salt '*' pkg.which <file name> quiet=True

   salt.modules.pkgutil
   Pkgutil support for Solaris

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   salt.modules.pkgutil.install(name=None,   refresh=False,  version=None,
   pkgs=None, **kwargs)
          Install packages using the pkgutil tool.

          CLI Example:

             salt '*' pkg.install <package_name>
             salt '*' pkg.install SMClgcc346

          Multiple Package Installation Options:

          pkgs   A list of packages  to  install  from  OpenCSW.  Must  be
                 passed as a python list.

                 CLI Example:

                    salt '*' pkg.install pkgs='["foo", "bar"]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "1.2.3"}]'

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.pkgutil.latest_version(*names, **kwargs)
          Return  the  latest  version  of the named package available for
          upgrade or installation.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          If  the  latest version of a given package is already installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkgutil.latest_version CSWpython
             salt '*' pkgutil.latest_version <package1> <package2> <package3> ...

   salt.modules.pkgutil.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs
             salt '*' pkg.list_pkgs versions_as_list=True

   salt.modules.pkgutil.list_upgrades(refresh=True, **kwargs)
          List all available package upgrades on this system

          CLI Example:

             salt '*' pkgutil.list_upgrades

   salt.modules.pkgutil.purge(name=None, pkgs=None, **kwargs)
          Package purges are not supported, this function is identical  to
          remove().

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.pkgutil.refresh_db()
          Updates the pkgutil repo database (pkgutil -U)

          CLI Example:

             salt '*' pkgutil.refresh_db

   salt.modules.pkgutil.remove(name=None, pkgs=None, **kwargs)
          Remove  a  package and all its dependencies which are not in use
          by other packages.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.pkgutil.upgrade(refresh=True)
          Upgrade all of the packages to the latest available version.

          Returns a dict containing the changes:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Example:

             salt '*' pkgutil.upgrade

   salt.modules.pkgutil.upgrade_available(name)
          Check if there is an upgrade available for a certain package

          CLI Example:

             salt '*' pkgutil.upgrade_available CSWpython

   salt.modules.pkgutil.version(*names, **kwargs)
          Returns a version if the package is installed, else  returns  an
          empty string

          CLI Example:

             salt '*' pkgutil.version CSWpython

   salt.modules.portage_config
   Configure portage(5)

   salt.modules.portage_config.append_to_package_conf(conf,       atom='',
   flags=None, string='', overwrite=False)
          Append a string or a list of flags for a given package or DEPEND
          atom to a given configuration file.

          CLI Example:

             salt '*' portage_config.append_to_package_conf use string="app-admin/salt ldap -libvirt"
             salt '*' portage_config.append_to_package_conf use atom="> = app-admin/salt-0.14.1" flags="['ldap', '-libvirt']"

   salt.modules.portage_config.append_use_flags(atom,           uses=None,
   overwrite=False)
          Append a list of use flags for a given package or DEPEND atom

          CLI Example:

             salt '*' portage_config.append_use_flags "app-admin/salt[ldap, -libvirt]"
             salt '*' portage_config.append_use_flags ">=app-admin/salt-0.14.1" "['ldap', '-libvirt']"

   salt.modules.portage_config.enforce_nice_config()
          Enforce  a  nice  tree  structure   for   /etc/portage/package.*
          configuration files.

          SEE ALSO:

             salt.modules.ebuild.ex_mod_init()
                    for information on automatically running this when pkg
                    is used.

          CLI Example:

             salt '*' portage_config.enforce_nice_config

   salt.modules.portage_config.filter_flags(use,        use_expand_hidden,
   usemasked, useforced)
          New in version 2015.8.0.

          Filter  function  to  remove  hidden  or  otherwise not normally
          visible USE flags from a list.

          @type use: list @param use: the USE flag list  to  be  filtered.
          @type use_expand_hidden: list @param  use_expand_hidden: list of
          flags hidden.  @type usemasked: list @param usemasked:  list  of
          masked  USE  flags.  @type useforced: list @param useforced: the
          forced USE flags.  @rtype: list @return the filtered USE flags.

   salt.modules.portage_config.get_all_cpv_use(cp)
          New in version 2015.8.0.

          Uses portage to determine final USE flags and  settings  for  an
          emerge.

          @type  cp:  string  @param  cp: eg cat/pkg @rtype: lists @return
          use, use_expand_hidden, usemask, useforce

   salt.modules.portage_config.get_cleared_flags(cp)
          New in version 2015.8.0.

          Uses portage for compare use flags which is used for  installing
          package     and     use    flags    which    now    exist    int
          /etc/portage/package.use/

          @type cp: string @param cp: eg cat/pkg  @rtype:  tuple  @rparam:
          tuple  with  two  lists  -  list of used flags and list of flags
          which will be used

   salt.modules.portage_config.get_flags_from_package_conf(conf, atom)
          Get flags for a given package or  DEPEND  atom.   Warning:  This
          only  works  if  the  configuration files tree is in the correct
          format (the one enforced by enforce_nice_config)

          CLI Example:

             salt '*' portage_config.get_flags_from_package_conf license salt

   salt.modules.portage_config.get_installed_use(cp, use='USE')
          New in version 2015.8.0.

          Gets the installed USE flags from the VARDB.

          @type: cp: string @param cp: cat/pkg @type  use:  string  @param
          use:  1 of ["USE", "PKGUSE"] @rtype list @returns [] or the list
          of IUSE flags

   salt.modules.portage_config.get_iuse(cp)
          New in version 2015.8.0.

          Gets the current IUSE flags from the tree.

          @type: cpv: string @param cpv: cat/pkg @rtype list  @returns  []
          or the list of IUSE flags

   salt.modules.portage_config.get_missing_flags(conf, atom, flags)
          Find  out  which  of the given flags are currently not set.  CLI
          Example:

             salt '*' portage_config.get_missing_flags use salt "['ldap', '-libvirt', 'openssl']"

   salt.modules.portage_config.has_flag(conf, atom, flag)
          Verify if the given package or DEPEND atom has the  given  flag.
          Warning:  This  only works if the configuration files tree is in
          the correct format (the one enforced by enforce_nice_config)

          CLI Example:

             salt '*' portage_config.has_flag license salt Apache-2.0

   salt.modules.portage_config.has_use(atom, use)
          Verify if the given package or DEPEND atom  has  the  given  use
          flag.   Warning: This only works if the configuration files tree
          is   in   the   correct   format   (the    one    enforced    by
          enforce_nice_config)

          CLI Example:

             salt '*' portage_config.has_use salt libvirt

   salt.modules.portage_config.is_changed_uses(cp)
          New in version 2015.8.0.

          Uses portage for determine if the use flags of installed package
          is compatible with use flags in portage configs.

          @type cp: string @param cp: eg cat/pkg

   salt.modules.portage_config.is_present(conf, atom)
          Tell if a given  package  or  DEPEND  atom  is  present  in  the
          configuration  files  tree.   Warning:  This  only  works if the
          configuration files tree is  in  the  correct  format  (the  one
          enforced by enforce_nice_config)

          CLI Example:

             salt '*' portage_config.is_present unmask salt

   salt.modules.postfix
   Support for Postfix

   This  module  is  currently  little  more than a config file viewer and
   editor. It is able to read the master.cf file (which is one style)  and
   files in the style of main.cf (which is a different style, that is used
   in multiple postfix configuration files).

   The design of this module is such that when files are edited, a minimum
   of  changes  are  made to them. Each file should look as if it has been
   edited by hand; order, comments and whitespace are all preserved.

   salt.modules.postfix.delete(queue_id)
          Delete message(s) from the mail queue

          CLI Example:

             salt '*' postfix.delete 5C33CA0DEA

             salt '*' postfix.delete ALL

   salt.modules.postfix.hold(queue_id)
          Put message(s) on hold from the mail queue

          CLI Example:

             salt '*' postfix.hold 5C33CA0DEA

             salt '*' postfix.hold ALL

   salt.modules.postfix.requeue(queue_id)
          Requeue message(s) in the mail queue

          CLI Example:

             salt '*' postfix.requeue 5C33CA0DEA

             salt '*' postfix.requeue ALL

   salt.modules.postfix.set_main(key, value, path='/etc/postfix/main.cf')
          Set a single config value in the main.cf file. If the value does
          not already exist, it will be appended to the end.

          CLI Example:
             salt <minion> postfix.set_main mailq_path /usr/bin/mailq

   salt.modules.postfix.set_master(service,     conn_type,    private='y',
   unpriv='y',   chroot='y',   wakeup='n',   maxproc='100',    command='',
   write_conf=True, path='/etc/postfix/master.cf')
          Set  a  single  config value in the master.cf file. If the value
          does not already exist, it will be appended to the end.

          Because of shell parsing issues, '-' cannot be set as  a  value,
          as  is normal in the master.cf file; either 'y', 'n' or a number
          should be used when calling this function from the command line.
          If  the  value  used  matches the default, it will internally be
          converted to a '-'. Calling this function from the Python API is
          not affected by this limitation

          The  settings  and  their default values, in order, are: service
          (required),  conn_type  (required),  private  (y),  unpriv  (y),
          chroot (y), wakeup (n), maxproc (100), command (required).

          By  default,  this  function  will  write out the changes to the
          master.cf file, and then returns the full contents of the  file.
          By  setting the write_conf option to False, it will skip writing
          the file.

          CLI Example:
             salt <minion> postfix.set_master smtp inet n y n n 100 smtpd

   salt.modules.postfix.show_main(path='/etc/postfix/main.cf')
          Return a dict of active config values.  This  does  not  include
          comments,   spacing  or  order.  Bear  in  mind  that  order  is
          functionally important in the main.cf file, since  keys  can  be
          referred to as variables. This means that the data returned from
          this function should not be used for direct modification of  the
          main.cf file; other functions are available for that.

          CLI Examples:
             salt     <minion>     postfix.show_main     salt     <minion>
             postfix.show_main path=/path/to/main.cf

   salt.modules.postfix.show_master(path='/etc/postfix/master.cf')
          Return a dict of active config values.  This  does  not  include
          comments, spacing or order.

          The  data  returned  from  this  function should not be used for
          direct modification of the main.cf  file;  other  functions  are
          available for that.

          CLI Examples:
             salt     <minion>     postfix.show_master    salt    <minion>
             postfix.show_master path=/path/to/master.cf

   salt.modules.postfix.show_queue()
          Show contents of the mail queue

          CLI Example:

             salt '*' postfix.show_queue

   salt.modules.postfix.unhold(queue_id)
          Set held message(s) in the mail queue to unheld

          CLI Example:

             salt '*' postfix.unhold 5C33CA0DEA

             salt '*' postfix.unhold ALL

   salt.modules.postgres
   Module to provide Postgres compatibility to salt.

   configuration
          In order  to  connect  to  Postgres,  certain  configuration  is
          required  in  /etc/salt/minion  on  the  relevant  minions. Some
          sample configs might look like:

             postgres.host: 'localhost'
             postgres.port: '5432'
             postgres.user: 'postgres' -> db user
             postgres.pass: ''
             postgres.maintenance_db: 'postgres'

          The default for the maintenance_db is  'postgres'  and  in  most
          cases it can be left at the default setting.  This data can also
          be passed into pillar. Options passed into opts  will  overwrite
          options passed into pillar

   note   This  module  uses  MD5  hashing which may not be compliant with
          certain security audits.

   note   When installing postgres from the official  postgres  repos,  on
          certain  linux  distributions,  either  the  psql  or the initdb
          binary  is  not  automatically  placed  on  the  path.   Add   a
          configuration  to the location of the postgres bin's path to the
          relevant minion for this module:

             postgres.bins_dir: '/usr/pgsql-9.5/bin/'

   salt.modules.postgres.available_extensions(user=None,        host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          List available postgresql extensions

          CLI Example:

             salt '*' postgres.available_extensions

   salt.modules.postgres.create_extension(name,        if_not_exists=None,
   schema=None, ext_version=None, from_version=None, user=None, host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Install a postgresql extension

          CLI Example:

             salt '*' postgres.create_extension 'adminpack'

   salt.modules.postgres.create_metadata(name,           ext_version=None,
   schema=None,  user=None,  host=None,  port=None,   maintenance_db=None,
   password=None, runas=None)
          Get lifecycle information about an extension

          CLI Example:

             salt '*' postgres.create_metadata adminpack

   salt.modules.postgres.datadir_exists(name)
          New in version 2016.3.0.

          Checks if postgres data directory has been initialized

          CLI Example:

             salt '*' postgres.datadir_exists '/var/lib/pgsql/data'

          name   Name of the directory to check

   salt.modules.postgres.datadir_init(name,   auth='password',  user=None,
   password=None, encoding='UTF8', locale=None, runas=None)
          New in version 2016.3.0.

          Initializes a postgres data directory

          CLI Example:

             salt '*' postgres.datadir_init '/var/lib/pgsql/data'

          name   The name of the directory to initialize

          auth   The default authentication method for local connections

          password
                 The password to set for the postgres user

          user   The database superuser name

          encoding
                 The default encoding for new databases

          locale The default locale for new databases

          runas  The system user the  operation  should  be  performed  on
                 behalf of

   salt.modules.postgres.db_alter(name,  user=None,  host=None, port=None,
   maintenance_db=None,   password=None,   tablespace=None,    owner=None,
   owner_recurse=False, runas=None)
          Change tablespace or/and owner of database.

          CLI Example:

             salt '*' postgres.db_alter dbname owner=otheruser

   salt.modules.postgres.db_create(name,  user=None, host=None, port=None,
   maintenance_db=None,  password=None,  tablespace=None,   encoding=None,
   lc_collate=None, lc_ctype=None, owner=None, template=None, runas=None)
          Adds a databases to the Postgres server.

          CLI Example:

             salt '*' postgres.db_create 'dbname'

             salt '*' postgres.db_create 'dbname' template=template_postgis

   salt.modules.postgres.db_exists(name,  user=None, host=None, port=None,
   maintenance_db=None, password=None, runas=None)
          Checks if a database exists on the Postgres server.

          CLI Example:

             salt '*' postgres.db_exists 'dbname'

   salt.modules.postgres.db_list(user=None,     host=None,      port=None,
   maintenance_db=None, password=None, runas=None)
          Return dictionary with information about databases of a Postgres
          server.

          CLI Example:

             salt '*' postgres.db_list

   salt.modules.postgres.db_remove(name, user=None, host=None,  port=None,
   maintenance_db=None, password=None, runas=None)
          Removes a databases from the Postgres server.

          CLI Example:

             salt '*' postgres.db_remove 'dbname'

   salt.modules.postgres.drop_extension(name,              if_exists=None,
   restrict=None,   cascade=None,   user=None,    host=None,    port=None,
   maintenance_db=None, password=None, runas=None)
          Drop an installed postgresql extension

          CLI Example:

             salt '*' postgres.drop_extension 'adminpack'

   salt.modules.postgres.get_available_extension(name,          user=None,
   host=None, port=None, maintenance_db=None, password=None, runas=None)
          Get info about an available postgresql extension

          CLI Example:

             salt '*' postgres.get_available_extension plpgsql

   salt.modules.postgres.get_installed_extension(name,          user=None,
   host=None, port=None, maintenance_db=None, password=None, runas=None)
          Get info about an installed postgresql extension

          CLI Example:

             salt '*' postgres.get_installed_extension plpgsql

   salt.modules.postgres.group_create(groupname,   user=None,   host=None,
   port=None,    maintenance_db=None,    password=None,     createdb=None,
   createuser=None,    createroles=None,    encrypted=None,    login=None,
   inherit=None,  superuser=None,   replication=None,   rolepassword=None,
   groups=None, runas=None)
          Creates  a  Postgres  group. A group is postgres is similar to a
          user, but cannot login.

          CLI Example:

             salt '*' postgres.group_create 'groupname' user='user' \
                     host='hostname' port='port' password='password' \
                     rolepassword='rolepassword'

   salt.modules.postgres.group_remove(groupname,   user=None,   host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Removes a group from the Postgres server.

          CLI Example:

             salt '*' postgres.group_remove 'groupname'

   salt.modules.postgres.group_update(groupname,   user=None,   host=None,
   port=None,    maintenance_db=None,    password=None,     createdb=None,
   createroles=None,    createuser=None,   encrypted=None,   inherit=None,
   login=None,   superuser=None,   replication=None,    rolepassword=None,
   groups=None, runas=None)
          Updates a postgres group

          CLI Examples:

             salt '*' postgres.group_update 'username' user='user' \
                     host='hostname' port='port' password='password' \
                     rolepassword='rolepassword'

   salt.modules.postgres.has_privileges(name,   object_name,  object_type,
   privileges=None,          grant_option=None,          prepend='public',
   maintenance_db=None,  user=None,  host=None,  port=None, password=None,
   runas=None)
          New in version 2016.3.0.

          Check if a role has the specified privileges on an object

          CLI Example:

             salt '*' postgres.has_privileges user_name table_name table \
             SELECT,INSERT maintenance_db=db_name

          name   Name of the role whose privileges should  be  checked  on
                 object_type

          object_name
                 Name of the object on which the check is to be performed

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          privileges
                 Comma  separated  list  of  privileges to check, from the
                 list below:

                 * INSERT

                 * CREATE

                 * TRUNCATE

                 * CONNECT

                 * TRIGGER

                 * SELECT

                 * USAGE

                 * TEMPORARY

                 * UPDATE

                 * EXECUTE

                 * REFERENCES

                 * DELETE

                 * ALL

          grant_option
                 If grant_option is set to True, the grant option check is
                 performed

          prepend
                 Table  and  Sequence  object types live under a schema so
                 this should be provided if the object is  not  under  the
                 default public schema

          maintenance_db
                 The database to connect to

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System  user all operations should be performed on behalf
                 of

   salt.modules.postgres.installed_extensions(user=None,        host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          List installed postgresql extensions

          CLI Example:

             salt '*' postgres.installed_extensions

   salt.modules.postgres.is_available_extension(name,           user=None,
   host=None, port=None, maintenance_db=None, password=None, runas=None)
          Test if a specific extension is available

          CLI Example:

             salt '*' postgres.is_available_extension

   salt.modules.postgres.is_installed_extension(name,           user=None,
   host=None, port=None, maintenance_db=None, password=None, runas=None)
          Test if a specific extension is installed

          CLI Example:

             salt '*' postgres.is_installed_extension

   salt.modules.postgres.language_create(name,  maintenance_db, user=None,
   host=None, port=None, password=None, runas=None)
          New in version 2016.3.0.

          Installs a language into a database

          CLI Example:

             salt '*' postgres.language_create plpgsql dbname

          name   Language to install

          maintenance_db
                 The database to install the language in

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.language_exists(name,  maintenance_db, user=None,
   host=None, port=None, password=None, runas=None)
          New in version 2016.3.0.

          Checks if language exists in a database.

          CLI Example:

             salt '*' postgres.language_exists plpgsql dbname

          name   Language to check for

          maintenance_db
                 The database to check in

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.language_list(maintenance_db,          user=None,
   host=None, port=None, password=None, runas=None)
          New in version 2016.3.0.

          Return a list of languages in a database.

          CLI Example:

             salt '*' postgres.language_list dbname

          maintenance_db
                 The database to check

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.language_remove(name,  maintenance_db, user=None,
   host=None, port=None, password=None, runas=None)
          New in version 2016.3.0.

          Removes a language from a database

          CLI Example:

             salt '*' postgres.language_remove plpgsql dbname

          name   Language to remove

          maintenance_db
                 The database to install the language in

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.owner_to(dbname, ownername, user=None, host=None,
   port=None, password=None, runas=None)
          Set the owner of  all  schemas,  functions,  tables,  views  and
          sequences to the given username.

          CLI Example:

             salt '*' postgres.owner_to 'dbname' 'username'

   salt.modules.postgres.privileges_grant(name,  object_name, object_type,
   privileges=None,          grant_option=None,          prepend='public',
   maintenance_db=None,  user=None,  host=None,  port=None, password=None,
   runas=None)
          New in version 2016.3.0.

          Grant privileges on a postgres object

          CLI Example:

             salt '*' postgres.privileges_grant user_name table_name table \
             SELECT,UPDATE maintenance_db=db_name

          name   Name of the role to which privileges should be granted

          object_name
                 Name of the object on which the grant is to be performed

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          privileges
                 Comma separated list of privileges  to  grant,  from  the
                 list below:

                 * INSERT

                 * CREATE

                 * TRUNCATE

                 * CONNECT

                 * TRIGGER

                 * SELECT

                 * USAGE

                 * TEMPORARY

                 * UPDATE

                 * EXECUTE

                 * REFERENCES

                 * DELETE

                 * ALL

          grant_option
                 If  grant_option  is  set  to  True, the recipient of the
                 privilege can in turn grant it to others

          prepend
                 Table and Sequence object types live under  a  schema  so
                 this  should  be  provided if the object is not under the
                 default public schema

          maintenance_db
                 The database to connect to

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.privileges_list(name,                object_type,
   prepend='public', maintenance_db=None, user=None, host=None, port=None,
   password=None, runas=None)
          New in version 2016.3.0.

          Return a list of privileges for the specified object.

          CLI Example:

             salt '*' postgres.privileges_list table_name table maintenance_db=db_name

          name   Name  of  the  object for which the permissions should be
                 returned

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          prepend
                 Table and Sequence object types live under  a  schema  so
                 this  should  be  provided if the object is not under the
                 default public schema

          maintenance_db
                 The database to connect to

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.privileges_revoke(name, object_name, object_type,
   privileges=None,  prepend='public',   maintenance_db=None,   user=None,
   host=None, port=None, password=None, runas=None)
          New in version 2016.3.0.

          Revoke privileges on a postgres object

          CLI Example:

             salt '*' postgres.privileges_revoke user_name table_name table \
             SELECT,UPDATE maintenance_db=db_name

          name   Name of the role whose privileges should be revoked

          object_name
                 Name of the object on which the revoke is to be performed

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          privileges
                 Comma  separated  list  of privileges to revoke, from the
                 list below:

                 * INSERT

                 * CREATE

                 * TRUNCATE

                 * CONNECT

                 * TRIGGER

                 * SELECT

                 * USAGE

                 * TEMPORARY

                 * UPDATE

                 * EXECUTE

                 * REFERENCES

                 * DELETE

                 * ALL

          maintenance_db
                 The database to connect to

          user   database username if different from config or default

          password
                 user password if any password for a specified user

          host   Database host if different from config or default

          port   Database port if different from config or default

          runas  System user all operations should be performed on  behalf
                 of

   salt.modules.postgres.psql_query(query,      user=None,      host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Run an SQL-Query and return the results as a list. This  command
          only  supports SELECT statements.  This limitation can be worked
          around with a query like this:

          WITH updated AS (UPDATE pg_authid SET rolconnlimit = 2000  WHERE
          rolname  =  'rolename'  RETURNING  rolconnlimit)  SELECT  * FROM
          updated;

          query  The query string.

          user   Database username, if different from config or default.

          host   Database host, if different from config or default.

          port   Database port, if different from the config or default.

          maintenance_db
                 The database to run the query against.

          password
                 User password, if different from the config or default.

          runas  User to run the command as.

          CLI Example:

             salt '*' postgres.psql_query 'select * from pg_stat_activity'

   salt.modules.postgres.role_get(name, user=None,  host=None,  port=None,
   maintenance_db=None, password=None, runas=None, return_password=False)
          Return a dict with information about users of a Postgres server.

          Set return_password to True to get password hash in the result.

          CLI Example:

             salt '*' postgres.role_get postgres

   salt.modules.postgres.schema_create(dbname,      name,      owner=None,
   user=None, db_user=None, db_password=None, db_host=None, db_port=None)
          Creates a Postgres schema.

          CLI Example:

             salt '*' postgres.schema_create dbname name owner='owner' \
                     user='user' \
                     db_user='user' db_password='password'
                     db_host='hostname' db_port='port'

   salt.modules.postgres.schema_exists(dbname,     name,     db_user=None,
   db_password=None, db_host=None, db_port=None)
          Checks if a schema exists on the Postgres server.

          CLI Example:

             salt '*' postgres.schema_exists dbname schemaname

          dbname Database name we query on

          name   Schema name we look for

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.modules.postgres.schema_get(dbname,       name,      db_user=None,
   db_password=None, db_host=None, db_port=None)
          Return a dict with information about schemas in a database.

          CLI Example:

             salt '*' postgres.schema_get dbname name

          dbname Database name we query on

          name   Schema name we look for

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.modules.postgres.schema_list(dbname,                 db_user=None,
   db_password=None, db_host=None, db_port=None)
          Return  a  dict  with  information  about  schemas in a Postgres
          database.

          CLI Example:

             salt '*' postgres.schema_list dbname

          dbname Database name we query on

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.modules.postgres.schema_remove(dbname,      name,       user=None,
   db_user=None, db_password=None, db_host=None, db_port=None)
          Removes a schema from the Postgres server.

          CLI Example:

             salt '*' postgres.schema_remove dbname schemaname

          dbname Database name we work on

          schemaname
                 The schema's name we'll remove

          user   System  user all operations should be performed on behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.modules.postgres.tablespace_alter(name,   user=None,    host=None,
   port=None,     maintenance_db=None,    password=None,    new_name=None,
   new_owner=None, set_option=None, reset_option=None, runas=None)
          Change tablespace name, owner, or options.

          CLI Example:

             salt '*' postgres.tablespace_alter tsname new_owner=otheruser
             salt '*' postgres.tablespace_alter index_space new_name=fast_raid
             salt '*' postgres.tablespace_alter test set_option="{'seq_page_cost': '1.1'}"
             salt '*' postgres.tablespace_alter tsname reset_option=seq_page_cost

          New in version 2015.8.0.

   salt.modules.postgres.tablespace_create(name,  location,  options=None,
   owner=None,   user=None,   host=None,  port=None,  maintenance_db=None,
   password=None, runas=None)
          Adds a tablespace to the Postgres server.

          CLI Example:

             salt '*' postgres.tablespace_create tablespacename '/path/datadir'

          New in version 2015.8.0.

   salt.modules.postgres.tablespace_exists(name,   user=None,   host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Checks if a tablespace exists on the Postgres server.

          CLI Example:

             salt '*' postgres.tablespace_exists 'dbname'

          New in version 2015.8.0.

   salt.modules.postgres.tablespace_list(user=None,  host=None, port=None,
   maintenance_db=None, password=None, runas=None)
          Return  dictionary  with  information  about  tablespaces  of  a
          Postgres server.

          CLI Example:

             salt '*' postgres.tablespace_list

          New in version 2015.8.0.

   salt.modules.postgres.tablespace_remove(name,   user=None,   host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Removes a tablespace from the Postgres server.

          CLI Example:

             salt '*' postgres.tablespace_remove tsname

          New in version 2015.8.0.

   salt.modules.postgres.user_create(username,    user=None,    host=None,
   port=None,     maintenance_db=None,    password=None,    createdb=None,
   createuser=None,    createroles=None,     inherit=None,     login=None,
   connlimit=None,   encrypted=None,   superuser=None,   replication=None,
   rolepassword=None, groups=None, runas=None)
          Creates a Postgres user.

          CLI Examples:

             salt '*' postgres.user_create 'username' user='user' \
                     host='hostname' port='port' password='password' \
                     rolepassword='rolepassword'

   salt.modules.postgres.user_exists(name,      user=None,      host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Checks if a user exists on the Postgres server.

          CLI Example:

             salt '*' postgres.user_exists 'username'

   salt.modules.postgres.user_list(user=None,     host=None,    port=None,
   maintenance_db=None, password=None, runas=None, return_password=False)
          Return a dict with information about users of a Postgres server.

          Set return_password to True to get password hash in the result.

          CLI Example:

             salt '*' postgres.user_list

   salt.modules.postgres.user_remove(username,    user=None,    host=None,
   port=None, maintenance_db=None, password=None, runas=None)
          Removes a user from the Postgres server.

          CLI Example:

             salt '*' postgres.user_remove 'username'

   salt.modules.postgres.user_update(username,    user=None,    host=None,
   port=None,    maintenance_db=None,    password=None,     createdb=None,
   createuser=None,   createroles=None,   encrypted=None,  superuser=None,
   inherit=None,     login=None,     connlimit=None,     replication=None,
   rolepassword=None, groups=None, runas=None)
          Updates a Postgres user.

          CLI Examples:

             salt '*' postgres.user_update 'username' user='user' \
                     host='hostname' port='port' password='password' \
                     rolepassword='rolepassword'

   salt.modules.postgres.version(user=None,      host=None,     port=None,
   maintenance_db=None, password=None, runas=None)
          Return the version of a Postgres server.

          CLI Example:

             salt '*' postgres.version

   salt.modules.poudriere
   Support for poudriere

   salt.modules.poudriere.bulk_build(jail, pkg_file, keep=False)
          Run bulk build on poudriere server.

          Return number of pkg builds, failures, and errors, on error dump
          to CLI

          CLI Example:

             salt -N buildbox_group poudriere.bulk_build 90amd64 /root/pkg_list

   salt.modules.poudriere.create_jail(name, arch, version='9.0-RELEASE')
          Creates a new poudriere jail if one does not exist

          NOTE  creating  a new jail will take some time the master is not
          hanging

          CLI Example:

             salt '*' poudriere.create_jail 90amd64 amd64

   salt.modules.poudriere.create_ports_tree()
          Not working need to run portfetch non interactive

   salt.modules.poudriere.delete_jail(name)
          Deletes poudriere jail with name

          CLI Example:

             salt '*' poudriere.delete_jail 90amd64

   salt.modules.poudriere.is_jail(name)
          Return True if jail exists False if not

          CLI Example:

             salt '*' poudriere.is_jail <jail name>

   salt.modules.poudriere.list_jails()
          Return a list of current jails managed by poudriere

          CLI Example:

             salt '*' poudriere.list_jails

   salt.modules.poudriere.list_ports()
          Return a list of current port trees managed by poudriere

          CLI Example:

             salt '*' poudriere.list_ports

   salt.modules.poudriere.make_pkgng_aware(jname)
          Make jail jname pkgng aware

          CLI Example:

             salt '*' poudriere.make_pkgng_aware <jail name>

   salt.modules.poudriere.parse_config(config_file=None)
          Returns a dict of poudriere main configuration definitions

          CLI Example:

             salt '*' poudriere.parse_config

   salt.modules.poudriere.update_jail(name)
          Run freebsd-update on name poudriere jail

          CLI Example:

             salt '*' poudriere.update_jail freebsd:10:x86:64

   salt.modules.poudriere.update_ports_tree(ports_tree)
          Updates the ports tree, either the  default  or  the  ports_tree
          specified

          CLI Example:

             salt '*' poudriere.update_ports_tree staging

   salt.modules.poudriere.version()
          Return poudriere version

          CLI Example:

             salt '*' poudriere.version

   salt.modules.powerpath
   powerpath support.

   Assumes RedHat

   salt.modules.powerpath.add_license(key)
          Add a license

   salt.modules.powerpath.list_licenses()
          returns a list of applied powerpath license keys

   salt.modules.powerpath.remove_license(key)
          Remove a license

   salt.modules.proxy module
   This module allows you to manage proxy settings

      salt '*' network.get_http_proxy

   salt.modules.proxy.get_ftp_proxy(network_service='Ethernet')
          Returns the current ftp proxy settings

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          CLI Example:

             salt '*' proxy.get_ftp_proxy Ethernet

   salt.modules.proxy.get_http_proxy(network_service='Ethernet')
          Returns the current http proxy settings

          network_service
                 The network service to apply the changes  to,  this  only
                 necessary on OSX

          CLI Example:

             salt '*' proxy.get_http_proxy Ethernet

   salt.modules.proxy.get_https_proxy(network_service='Ethernet')
          Returns the current https proxy settings

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          CLI Example:

             salt '*' proxy.get_https_proxy Ethernet

   salt.modules.proxy.get_proxy_bypass(network_service='Ethernet')
          Returns the current domains that can bypass the proxy

          network_service
                 The network service to get the bypass domains from,  this
                 is only necessary on OSX

          CLI Example:

             salt '*' proxy.get_proxy_bypass

   salt.modules.proxy.get_proxy_win()
          Gets  all  of  the proxy settings in one call, only available on
          Windows

          CLI Example:

             salt '*' proxy.get_proxy_win

   salt.modules.proxy.set_ftp_proxy(server,        port,        user=None,
   password=None, network_service='Ethernet', bypass_hosts=None)
          Sets the ftp proxy settings

          server The proxy server to use

          port   The port used by the proxy server

          user   The username to use for the proxy server if required

          password
                 The password to use if required by the server

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          bypass_hosts
                 The hosts that are allowed to by  pass  the  proxy.  Only
                 used  on  Windows  for other OS's use set_proxy_bypass to
                 edit the bypass hosts.

          CLI Example:

             salt '*' proxy.set_ftp_proxy example.com 1080 user=proxy_user password=proxy_pass network_service=Ethernet

   salt.modules.proxy.set_http_proxy(server,       port,        user=None,
   password=None, network_service='Ethernet', bypass_hosts=None)
          Sets  the  http  proxy  settings.  Note:  On  Windows  this will
          override any other proxy settings you have, the preferred method
          of updating proxies on windows is using set_proxy.

          server The proxy server to use

          port   The port used by the proxy server

          user   The username to use for the proxy server if required

          password
                 The password to use if required by the server

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          bypass_hosts
                 The hosts that are allowed to by  pass  the  proxy.  Only
                 used  on  Windows  for other OS's use set_proxy_bypass to
                 edit the bypass hosts.

          CLI Example:

             salt '*' proxy.set_http_proxy example.com 1080 user=proxy_user password=proxy_pass network_service=Ethernet

   salt.modules.proxy.set_https_proxy(server,       port,       user=None,
   password=None, network_service='Ethernet', bypass_hosts=None)
          Sets  the  https  proxy  settings.  Note:  On  Windows this will
          override any other proxy settings you have, the preferred method
          of updating proxies on windows is using set_proxy.

          server The proxy server to use

          port   The port used by the proxy server

          user   The username to use for the proxy server if required

          password
                 The password to use if required by the server

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          bypass_hosts
                 The hosts that are allowed to by  pass  the  proxy.  Only
                 used  on  Windows  for other OS's use set_proxy_bypass to
                 edit the bypass hosts.

          CLI Example:

             salt '*' proxy.set_https_proxy example.com 1080 user=proxy_user password=proxy_pass network_service=Ethernet

   salt.modules.proxy.set_proxy_bypass(domains,
   network_service='Ethernet')
          Sets the domains that can bypass the proxy

          domains
                 An array of domains allowed to bypass the proxy

          network_service
                 The  network  service  to apply the changes to, this only
                 necessary on OSX

          CLI Example:

             salt '*' proxy.set_proxy_bypass "['127.0.0.1', 'localhost']"

   salt.modules.proxy.set_proxy_win(server,       port,        types=None,
   bypass_hosts=None)
          Sets the http proxy settings, only works with Windows.

          server The proxy server to use

          password
                 The password to use if required by the server

          types  The  types of proxy connections should be setup with this
                 server. Valid types are http and https.

          bypass_hosts
                 The hosts that are allowed to by pass the proxy.

          CLI Example:

             salt '*' proxy.set_http_proxy example.com 1080 types="['http', 'https']"

   salt.modules.ps
   A salt  interface  to  psutil,  a  system  and  process  library.   See
   http://code.google.com/p/psutil.

   depends

          * psutil Python module, version 0.3.0 or later

          * python-utmp package (optional)

   salt.modules.ps.boot_time(time_format=None)
          Return the boot time in number of seconds since the epoch began.

          CLI Example:

          time_format
                 Optionally   specify   a   strftime  format  string.  Use
                 time_format='%c'  to  get   a   nicely-formatted   locale
                 specific date and time (i.e. Fri May  2 19:08:32 2014).

                 New in version 2014.1.4.

             salt '*' ps.boot_time

   salt.modules.ps.cpu_percent(interval=0.1, per_cpu=False)
          Return the percent of time the CPU is busy.

          interval
                 the number of seconds to sample CPU usage over

          per_cpu
                 if True return an array of CPU percent busy for each CPU,
                 otherwise aggregate all percents into one number

          CLI Example:

             salt '*' ps.cpu_percent

   salt.modules.ps.cpu_times(per_cpu=False)
          Return the percent of time the CPU spends in  each  state,  e.g.
          user, system, idle, nice, iowait, irq, softirq.

          per_cpu
                 if  True  return  an  array  of  percents  for  each CPU,
                 otherwise aggregate all percents into one number

          CLI Example:

             salt '*' ps.cpu_times

   salt.modules.ps.disk_io_counters(device=None)
          Return disk I/O statistics.

          CLI Example:

             salt '*' ps.disk_io_counters

             salt '*' ps.disk_io_counters device=sda1

   salt.modules.ps.disk_partition_usage(all=False)
          Return  a  list  of  disk  partitions  plus  the  mount   point,
          filesystem and usage statistics.

          CLI Example:

             salt '*' ps.disk_partition_usage

   salt.modules.ps.disk_partitions(all=False)
          Return  a list of disk partitions and their device, mount point,
          and filesystem type.

          all    if set to False, only return local,  physical  partitions
                 (hard disk, USB, CD/DVD partitions).  If True, return all
                 filesystems.

          CLI Example:

             salt '*' ps.disk_partitions

   salt.modules.ps.disk_usage(path)
          Given a path, return a dict listing the total available space as
          well as the free space, and used space.

          CLI Example:

             salt '*' ps.disk_usage /home

   salt.modules.ps.get_pid_list()
          Return a list of process ids (PIDs) for all running processes.

          CLI Example:

             salt '*' ps.get_pid_list

   salt.modules.ps.get_users()
          Return logged-in users.

          CLI Example:

             salt '*' ps.get_users

   salt.modules.ps.kill_pid(pid, signal=15)
          Kill a process by PID.

             salt 'minion' ps.kill_pid pid [signal=signal_number]

          pid    PID of process to kill.

          signal Signal to send to the process. See manpage entry for kill
                 for possible values. Default: 15 (SIGTERM).

          Example:

          Send SIGKILL to process with PID 2000:

             salt 'minion' ps.kill_pid 2000 signal=9

   salt.modules.ps.lsof(name)
          Retrieve the lsof informations of the given process name.

          CLI Example:

             salt '*' ps.lsof apache2

   salt.modules.ps.netstat(name)
          Retrieve the netstat informations of the given process name.

          CLI Example:

             salt '*' ps.netstat apache2

   salt.modules.ps.network_io_counters(interface=None)
          Return network I/O statistics.

          CLI Example:

             salt '*' ps.network_io_counters

             salt '*' ps.network_io_counters interface=eth0

   salt.modules.ps.num_cpus()
          Return the number of CPUs.

          CLI Example:

             salt '*' ps.num_cpus

   salt.modules.ps.pgrep(pattern, user=None, full=False)
          Return the pids for processes matching a pattern.

          If full is true, the full command line is searched for a  match,
          otherwise only the name of the command is searched.

             salt '*' ps.pgrep pattern [user=username] [full=(true|false)]

          pattern
                 Pattern to search for in the process list.

          user   Limit matches to the given username. Default: All users.

          full   A  boolean  value indicating whether only the name of the
                 command or  the  full  command  line  should  be  matched
                 against the pattern.

          Examples:

          Find all httpd processes on all 'www' minions:

             salt 'www.*' ps.pgrep httpd

          Find all bash processes owned by user 'tom':

             salt '*' ps.pgrep bash user=tom

   salt.modules.ps.pkill(pattern, user=None, signal=15, full=False)
          Kill processes matching a pattern.

             salt '*' ps.pkill pattern [user=username] [signal=signal_number] \
                     [full=(true|false)]

          pattern
                 Pattern to search for in the process list.

          user   Limit matches to the given username. Default: All users.

          signal Signal  to send to the process(es). See manpage entry for
                 kill for possible values. Default: 15 (SIGTERM).

          full   A boolean value indicating whether only the name  of  the
                 command  or  the  full  command  line  should  be matched
                 against the pattern.

          Examples:

          Send SIGHUP to all httpd processes on all 'www' minions:

             salt 'www.*' ps.pkill httpd signal=1

          Send SIGKILL to all bash processes owned by user 'tom':

             salt '*' ps.pkill bash signal=9 user=tom

   salt.modules.ps.proc_info(pid, attrs=None)
          Return a dictionary of information for a process id (PID).

          CLI Example:

             salt '*' ps.proc_info 2322
             salt '*' ps.proc_info 2322 attrs='["pid", "name"]'

          pid    PID of process to query.

          attrs  Optional list of desired process attributes.  The list of
                 possible     attributes     can     be     found    here:
                 http://pythonhosted.org/psutil/#psutil.Process

   salt.modules.ps.psaux(name)
          Retrieve information corresponding to a "ps aux"  filtered  with
          the  given  pattern.  It  could  be  just  a  name  or a regular
          expression (using python search from "re" module).

          CLI Example:

             salt '*' ps.psaux www-data.+apache2

   salt.modules.ps.swap_memory()
          New in version 2014.7.0.

          Return a dict that describes swap memory statistics.

          NOTE:
             This function is only available in psutil version  0.6.0  and
             above.

          CLI Example:

             salt '*' ps.swap_memory

   salt.modules.ps.top(num_processes=5, interval=3)
          Return  a  list  of  top  CPU  consuming  processes  during  the
          interval.  num_processes  =  return  the  top  N  CPU  consuming
          processes  interval  = the number of seconds to sample CPU usage
          over

          CLI Examples:

             salt '*' ps.top

             salt '*' ps.top 5 10

   salt.modules.ps.total_physical_memory()
          Return the total number of bytes of physical memory.

          CLI Example:

             salt '*' ps.total_physical_memory

   salt.modules.ps.virtual_memory()
          New in version 2014.7.0.

          Return a dict that  describes  statistics  about  system  memory
          usage.

          NOTE:
             This  function  is only available in psutil version 0.6.0 and
             above.

          CLI Example:

             salt '*' ps.virtual_memory

   salt.modules.publish
   Publish a command from a minion to a target

   salt.modules.publish.full_data(tgt,  fun,  arg=None,  expr_form='glob',
   returner='', timeout=5)
          Return  the  full data about the publication, this is invoked in
          the same way as the publish function

          CLI Example:

             salt system.example.com publish.full_data '*' cmd.run 'ls -la /tmp'

             Attention

                    If you need to pass a value to a function argument and
                    that  value  contains  an equal sign, you must include
                    the argument name.  For example:

                 salt '*' publish.full_data test.kwarg arg='cheese=spam'

   salt.modules.publish.publish(tgt,  fun,   arg=None,   expr_form='glob',
   returner='', timeout=5, via_master=None)
          Publish a command from the minion out to other minions.

          Publications  need  to  be  enabled  on  the Salt master and the
          minion needs to have permission to publish the command. The Salt
          master  will  also  prevent  a  recursive publication loop, this
          means that a minion cannot command  another  minion  to  command
          another minion as that would create an infinite command loop.

          The  expr_form  argument  is  used to pass a target other than a
          glob into the execution, the available options are:

          * glob

          * pcre

          * grain

          * grain_pcre

          * pillar

          * pillar_pcre

          * ipcidr

          * range

          * compound

          Note that for pillar matches must be exact, both in  the  pillar
          matcher and the compound matcher. No globbing is supported.

          The  arguments sent to the minion publish function are separated
          with commas. This means that for a minion  executing  a  command
          with multiple args it will look like this:

             salt system.example.com publish.publish '*' user.add 'foo,1020,1020'
             salt system.example.com publish.publish 'os:Fedora' network.interfaces '' grain

          CLI Example:

             salt system.example.com publish.publish '*' cmd.run 'ls -la /tmp'

             Attention

                    If you need to pass a value to a function argument and
                    that value contains an equal sign,  you  must  include
                    the argument name.  For example:

                 salt '*' publish.publish test.kwarg arg='cheese=spam'

             Multiple keyword arguments should be passed as a list.

                 salt '*' publish.publish test.kwarg arg="['cheese=spam','spam=cheese']"

          When  running  via  salt-call, the via_master flag may be set to
          specific which master the publication should be  sent  to.  Only
          one  master  may be specified. If unset, the publication will be
          sent only to the first master in minion configuration.

   salt.modules.publish.runner(fun, arg=None, timeout=5)
          Execute a runner on the master and  return  the  data  from  the
          runner function

          CLI Example:

             salt publish.runner manage.down

   salt.modules.puppet
   Execute puppet routines

   salt.modules.puppet.disable(message=None)
          New in version 2014.7.0.

          Disable the puppet agent

          message
                 New in version 2015.5.2.

                 Disable message to send to puppet

          CLI Example:

             salt '*' puppet.disable
             salt '*' puppet.disable 'Disabled, contact XYZ before enabling'

   salt.modules.puppet.enable()
          New in version 2014.7.0.

          Enable the puppet agent

          CLI Example:

             salt '*' puppet.enable

   salt.modules.puppet.fact(name, puppet=False)
          Run facter for a specific fact

          CLI Example:

             salt '*' puppet.fact kernel

   salt.modules.puppet.facts(puppet=False)
          Run facter and return the results

          CLI Example:

             salt '*' puppet.facts

   salt.modules.puppet.noop(*args, **kwargs)
          Execute  a  puppet  noop  run and return a dict with the stderr,
          stdout, return code, etc. Usage is the same as for puppet.run.

          CLI Example:

             salt '*' puppet.noop
             salt '*' puppet.noop tags=basefiles::edit,apache::server
             salt '*' puppet.noop debug
             salt '*' puppet.noop apply /a/b/manifest.pp modulepath=/a/b/modules tags=basefiles::edit,apache::server

   salt.modules.puppet.plugin_sync()
          Runs a plugin synch between the puppet master and agent

          CLI Example:
             salt '*' puppet.plugin_sync

   salt.modules.puppet.run(*args, **kwargs)
          Execute a puppet run and return a dict with the stderr,  stdout,
          return code, etc. The first positional argument given is checked
          as  a  subcommand.  Following  positional  arguments  should  be
          ordered   with  arguments  required  by  the  subcommand  first,
          followed by non-keyword arguments.  Tags are specified by a  tag
          keyword    and    comma    separated    list   of   values.   --
          http://docs.puppetlabs.com/puppet/latest/reference/lang_tags.html

          CLI Examples:

             salt '*' puppet.run
             salt '*' puppet.run tags=basefiles::edit,apache::server
             salt '*' puppet.run agent onetime no-daemonize no-usecacheonfailure no-splay ignorecache
             salt '*' puppet.run debug
             salt '*' puppet.run apply /a/b/manifest.pp modulepath=/a/b/modules tags=basefiles::edit,apache::server

   salt.modules.puppet.status()
          New in version 2014.7.0.

          Display puppet agent status

          CLI Example:

             salt '*' puppet.status

   salt.modules.puppet.summary()
          New in version 2014.7.0.

          Show a summary of the last puppet agent run

          CLI Example:

             salt '*' puppet.summary

   salt.modules.pushbullet module
   Module for sending messages to Pushbullet (https://www.pushbullet.com)

   New in version 2015.8.0.

   Requires an api_key in /etc/salt/minion:

   For example:

      pushbullet:
        device: "Chrome"
        title: "Example push message"
        body: "Message body."

   salt.modules.pushbullet.push_note(device=None, title=None, body=None)
          Pushing a text note.

          Parameters

                 * device -- Pushbullet target device

                 * title -- Note title

                 * body -- Note body

          Returns
                 Boolean if message was sent successfully.

          CLI Example:

             salt "*" pushbullet.push_note device="Chrome" title="Example title" body="Example body."

   salt.modules.pushover_notify
   Module for sending messages to Pushover (https://www.pushover.net)

   New in version 2016.3.0.

   configuration
          This module can be used by either passing an api key and version
          directly or by specifying both in a configuration profile in the
          salt master/minion config.

          For example:

             pushover:
               token: abAHuZyCLtdH8P4zhmFZmgUHUsv1ei8

   salt.modules.pushover_notify.post_message(user=None,       device=None,
   message=None,  title=None,  priority=None,   expire=None,   retry=None,
   sound=None, api_version=1, token=None)
          Send a message to a Pushover user or group.

          Parameters

                 * user  --  The  user or group to send to, must be key of
                   user or group not email address.

                 * message -- The message to send to the PushOver user  or
                   group.

                 * title -- Specify who the message is from.

                 * priority -- The priority of the message, defaults to 0.

                 * expire  --  The message should expire after N number of
                   seconds.

                 * retry -- The number of  times  the  message  should  be
                   retried.

                 * sound -- The sound to associate with the message.

                 * api_version   --  The  PushOver  API  version,  if  not
                   specified in the configuration.

                 * token -- The PushOver token, if not  specified  in  the
                   configuration.

          Returns
                 Boolean if message was sent successfully.

          CLI Example:

             salt '*' pushover.post_message user='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' title='Message from Salt' message='Build is done'

             salt '*' pushover.post_message user='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' title='Message from Salt' message='Build is done' priority='2' expire='720' retry='5'

   salt.modules.pw_group
   Manage groups on FreeBSD

   IMPORTANT:
      If  you  feel that Salt should be using this module to manage groups
      on a minion, and it is using a different module (or gives  an  error
      similar to 'group.info' is not available), see here.

   salt.modules.pw_group.add(name, gid=None, **kwargs)
          Add the specified group

          CLI Example:

             salt '*' group.add foo 3456

   salt.modules.pw_group.adduser(name, username)
          Add a user in the group.

          CLI Example:

             salt '*' group.adduser foo bar

          Verifies  if  a  valid username 'bar' as a member of an existing
          group 'foo', if not then adds it.

   salt.modules.pw_group.chgid(name, gid)
          Change the gid for a named group

          CLI Example:

             salt '*' group.chgid foo 4376

   salt.modules.pw_group.delete(name)
          Remove the named group

          CLI Example:

             salt '*' group.delete foo

   salt.modules.pw_group.deluser(name, username)
          Remove a user from the group.

          CLI Example:

             salt '*' group.deluser foo bar

          Removes a member user 'bar' from a group 'foo'. If group is  not
          present then returns True.

   salt.modules.pw_group.getent(refresh=False)
          Return info on all groups

          CLI Example:

             salt '*' group.getent

   salt.modules.pw_group.info(name)
          Return information about a group

          CLI Example:

             salt '*' group.info foo

   salt.modules.pw_group.members(name, members_list)
          Replaces members of the group with a provided list.

          New in version 2015.5.4.

          CLI Example:
             salt '*' group.members foo 'user1,user2,user3,...'

          Replaces a membership list for a local group 'foo'.
                 foo:x:1234:user1,user2,user3,...

   salt.modules.pw_user
   Manage users with the useradd command

   IMPORTANT:
      If you feel that Salt should be using this module to manage users on
      a minion, and it is using a different  module  (or  gives  an  error
      similar to 'user.info' is not available), see here.

   salt.modules.pw_user.add(name,    uid=None,    gid=None,   groups=None,
   home=None,   shell=None,   unique=True,   fullname='',   roomnumber='',
   workphone='', homephone='', createhome=True, loginclass=None, **kwargs)
          Add a user to the minion

          CLI Example:

             salt '*' user.add name <uid> <gid> <groups> <home> <shell>

   salt.modules.pw_user.chfullname(name, fullname)
          Change the user's Full Name

          CLI Example:

             salt '*' user.chfullname foo "Foo Bar"

   salt.modules.pw_user.chgid(name, gid)
          Change the default group of the user

          CLI Example:

             salt '*' user.chgid foo 4376

   salt.modules.pw_user.chgroups(name, groups, append=False)
          Change the groups to which a user belongs

          name   Username to modify

          groups List  of  groups  to set for the user. Can be passed as a
                 comma-separated list or a Python list.

          append False Set to True to append these groups  to  the  user's
                 existing  list of groups. Otherwise, the specified groups
                 will replace any existing groups for the user.

          CLI Example:

             salt '*' user.chgroups foo wheel,root True

   salt.modules.pw_user.chhome(name, home, persist=False)
          Set a new home directory for an existing user

          name   Username to modify

          home   New home directory to set

          persist
                 False Set to True to prevent configuration files  in  the
                 new  home  directory  from being overwritten by the files
                 from the skeleton directory.

          CLI Example:

             salt '*' user.chhome foo /home/users/foo True

   salt.modules.pw_user.chhomephone(name, homephone)
          Change the user's Home Phone

          CLI Example:

             salt '*' user.chhomephone foo "7735551234"

   salt.modules.pw_user.chloginclass(name, loginclass, root=None)
          Change the default login class of the user

          New in version 2016.3.5.

          CLI Example:

             salt '*' user.chloginclass foo staff

   salt.modules.pw_user.chroomnumber(name, roomnumber)
          Change the user's Room Number

          CLI Example:

             salt '*' user.chroomnumber foo 123

   salt.modules.pw_user.chshell(name, shell)
          Change the default shell of the user

          CLI Example:

             salt '*' user.chshell foo /bin/zsh

   salt.modules.pw_user.chuid(name, uid)
          Change the uid for a named user

          CLI Example:

             salt '*' user.chuid foo 4376

   salt.modules.pw_user.chworkphone(name, workphone)
          Change the user's Work Phone

          CLI Example:

             salt '*' user.chworkphone foo "7735550123"

   salt.modules.pw_user.delete(name, remove=False, force=False)
          Remove a user from the minion

          CLI Example:

             salt '*' user.delete name remove=True force=True

   salt.modules.pw_user.get_loginclass(name)
          Get the login class of the user

          New in version 2016.3.0.

          CLI Example:

             salt '*' user.get_loginclass foo

   salt.modules.pw_user.getent(refresh=False)
          Return the list of all info for all users

          CLI Example:

             salt '*' user.getent

   salt.modules.pw_user.info(name)
          Return user information

          CLI Example:

             salt '*' user.info root

   salt.modules.pw_user.list_groups(name)
          Return a list of groups the named user belongs to

          CLI Example:

             salt '*' user.list_groups foo

   salt.modules.pw_user.list_users()
          Return a list of all users

          CLI Example:

             salt '*' user.list_users

   salt.modules.pw_user.rename(name, new_name)
          Change the username for a named user

          CLI Example:

             salt '*' user.rename name new_name

   salt.modules.pyenv
   Manage python installations with pyenv.

   NOTE:
      Git needs to be installed and available via PATH if pyenv is  to  be
      installed automatically by the module.

   New in version v2014.04.

   salt.modules.pyenv.default(python=None, runas=None)
          Returns or sets the currently defined default python.

          python=None
                 The  version  to  set as the default. Should match one of
                 the versions listed by  pyenv.versions.  Leave  blank  to
                 return the current default.

          CLI Example:

             salt '*' pyenv.default
             salt '*' pyenv.default 2.0.0-p0

   salt.modules.pyenv.do(cmdline=None, runas=None)
          Execute a python command with pyenv's shims from the user or the
          system.

          CLI Example:

             salt '*' pyenv.do 'gem list bundler'
             salt '*' pyenv.do 'gem list bundler' deploy

   salt.modules.pyenv.do_with_python(python, cmdline, runas=None)
          Execute a python command with pyenv's  shims  using  a  specific
          python version.

          CLI Example:

             salt '*' pyenv.do_with_python 2.0.0-p0 'gem list bundler'
             salt '*' pyenv.do_with_python 2.0.0-p0 'gem list bundler' deploy

   salt.modules.pyenv.install(runas=None, path=None)
          Install pyenv systemwide

          CLI Example:

             salt '*' pyenv.install

   salt.modules.pyenv.install_python(python, runas=None)
          Install a python implementation.

          python The version of python to install, should match one of the
                 versions listed by pyenv.list

          CLI Example:

             salt '*' pyenv.install_python 2.0.0-p0

   salt.modules.pyenv.is_installed(runas=None)
          Check if pyenv is installed.

          CLI Example:

             salt '*' pyenv.is_installed

   salt.modules.pyenv.list(runas=None)
          List the installable versions of python.

          CLI Example:

             salt '*' pyenv.list

   salt.modules.pyenv.rehash(runas=None)
          Run pyenv rehash to update the installed shims.

          CLI Example:

             salt '*' pyenv.rehash

   salt.modules.pyenv.uninstall_python(python, runas=None)
          Uninstall a python implementation.

          python The version of python to uninstall. Should match  one  of
                 the versions listed by pyenv.versions

          CLI Example:

             salt '*' pyenv.uninstall_python 2.0.0-p0

   salt.modules.pyenv.update(runas=None, path=None)
          Updates the current versions of pyenv and python-Build

          CLI Example:

             salt '*' pyenv.update

   salt.modules.pyenv.versions(runas=None)
          List the installed versions of python.

          CLI Example:

             salt '*' pyenv.versions

   salt.modules.qemu_img
   Qemu-img Command Wrapper
   The qemu img command is wrapped for specific functions

   depends
          qemu-img

   salt.modules.qemu_img.convert(orig, dest, fmt)
          Convert an existing disk image to another format using qemu-img

          CLI Example:

             salt '*' qemu_img.convert /path/to/original.img /path/to/new.img qcow2

   salt.modules.qemu_img.make_image(location, size, fmt)
          Create  a blank virtual machine image file of the specified size
          in megabytes. The image can be created in any  format  supported
          by qemu

          CLI Example:

             salt '*' qemu_img.make_image /tmp/image.qcow 2048 qcow2
             salt '*' qemu_img.make_image /tmp/image.raw 10240 raw

   salt.modules.qemu_nbd
   Qemu Command Wrapper

   The  qemu  system  comes  with  powerful  tools,  such  as qemu-img and
   qemu-nbd which are used here to build up kvm images.

   salt.modules.qemu_nbd.clear(mnt)
          Pass in the mnt dict returned  from  nbd_mount  to  unmount  and
          disconnect  the  image  from  nbd.  If all of the partitions are
          unmounted  return  an  empty  dict,  otherwise  return  a   dict
          containing the still mounted partitions

          CLI Example:

             salt '*' qemu_nbd.clear '{"/mnt/foo": "/dev/nbd0p1"}'

   salt.modules.qemu_nbd.connect(image)
          Activate nbd for an image file.

          CLI Example:

             salt '*' qemu_nbd.connect /tmp/image.raw

   salt.modules.qemu_nbd.init(image, root=None)
          Mount the named image via qemu-nbd and return the mounted roots

          CLI Example:

             salt '*' qemu_nbd.init /srv/image.qcow2

   salt.modules.qemu_nbd.mount(nbd, root=None)
          Pass in the nbd connection device location, mount all partitions
          and return a dict of mount points

          CLI Example:

             salt '*' qemu_nbd.mount /dev/nbd0

   salt.modules.quota
   Module for managing quotas on POSIX-like systems.

   salt.modules.quota.get_mode(device)
          Report whether the quota system for this device is on or off

          CLI Example:

             salt '*' quota.get_mode

   salt.modules.quota.off(device)
          Turns off the quota system

          CLI Example:

             salt '*' quota.off

   salt.modules.quota.on(device)
          Turns on the quota system

          CLI Example:

             salt '*' quota.on

   salt.modules.quota.report(mount)
          Report on quotas for a specific volume

          CLI Example:

             salt '*' quota.report /media/data

   salt.modules.quota.set(device, **kwargs)
          Calls out to setquota, for a specific user or group

          CLI Example:

             salt '*' quota.set /media/data user=larry block-soft-limit=1048576
             salt '*' quota.set /media/data group=painters file-hard-limit=1000

   salt.modules.quota.stats()
          Runs the quotastats command, and returns the parsed output

          CLI Example:

             salt '*' quota.stats

   salt.modules.quota.warn()
          Runs the warnquota command, to send warning emails to users  who
          are over their quota limit.

          CLI Example:

             salt '*' quota.warn

   salt.modules.rabbitmq
   Module to provide RabbitMQ compatibility to Salt.  Todo: A lot, need to
   add cluster support, logging, and minion configuration data.

   salt.modules.rabbitmq.add_user(name, password=None, runas=None)
          Add a rabbitMQ user via rabbitmqctl user_add <user> <password>

          CLI Example:

             salt '*' rabbitmq.add_user rabbit_user password

   salt.modules.rabbitmq.add_vhost(vhost, runas=None)
          Adds a vhost via rabbitmqctl add_vhost.

          CLI Example:

             salt '*' rabbitmq add_vhost '<vhost_name>'

   salt.modules.rabbitmq.change_password(name, password, runas=None)
          Changes a user's password.

          CLI Example:

             salt '*' rabbitmq.change_password rabbit_user password

   salt.modules.rabbitmq.check_password(name, password, runas=None)
          New in version 2016.3.0.

          Checks if a user's password is valid.

          CLI Example:

             salt '*' rabbitmq.check_password rabbit_user password

   salt.modules.rabbitmq.clear_password(name, runas=None)
          Removes a user's password.

          CLI Example:

             salt '*' rabbitmq.clear_password rabbit_user

   salt.modules.rabbitmq.cluster_status(runas=None)
          return rabbitmq cluster_status

          CLI Example:

             salt '*' rabbitmq.cluster_status

   salt.modules.rabbitmq.delete_policy(vhost, name, runas=None)
          Delete a policy based on rabbitmqctl clear_policy.

          Reference: http://www.rabbitmq.com/ha.html

          CLI Example:

             salt '*' rabbitmq.delete_policy / HA'

   salt.modules.rabbitmq.delete_user(name, runas=None)
          Deletes a user via rabbitmqctl delete_user.

          CLI Example:

             salt '*' rabbitmq.delete_user rabbit_user

   salt.modules.rabbitmq.delete_vhost(vhost, runas=None)
          Deletes a vhost rabbitmqctl delete_vhost.

          CLI Example:

             salt '*' rabbitmq.delete_vhost '<vhost_name>'

   salt.modules.rabbitmq.disable_plugin(name, runas=None)
          Disable a RabbitMQ plugin via the rabbitmq-plugins command.

          CLI Example:

             salt '*' rabbitmq.disable_plugin foo

   salt.modules.rabbitmq.enable_plugin(name, runas=None)
          Enable a RabbitMQ plugin via the rabbitmq-plugins command.

          CLI Example:

             salt '*' rabbitmq.enable_plugin foo

   salt.modules.rabbitmq.force_reset(runas=None)
          Forcefully Return a RabbitMQ node to its virgin state

          CLI Example:

             salt '*' rabbitmq.force_reset

   salt.modules.rabbitmq.join_cluster(host, user='rabbit',  ram_node=None,
   runas=None)
          Join a rabbit cluster

          CLI Example:

             salt '*' rabbitmq.join_cluster 'rabbit.example.com' 'rabbit'

   salt.modules.rabbitmq.list_permissions(vhost, runas=None)
          Lists permissions for vhost via rabbitmqctl list_permissions

          CLI Example:

             salt '*' rabbitmq.list_permissions '/myvhost'

   salt.modules.rabbitmq.list_policies(vhost='/', runas=None)
          Return  a  dictionary of policies nested by vhost and name based
          on the data returned from rabbitmqctl list_policies.

          Reference: http://www.rabbitmq.com/ha.html

          CLI Example:

             salt '*' rabbitmq.list_policies'

   salt.modules.rabbitmq.list_queues(runas=None, *args)
          Returns queue details of the / virtual host

          CLI Example:

             salt '*' rabbitmq.list_queues messages consumers

   salt.modules.rabbitmq.list_queues_vhost(vhost, runas=None, *args)
          Returns queue details of specified virtual  host.  This  command
          will consider first parameter as the vhost name and rest will be
          treated as queueinfoitem. For getting details on  vhost  /,  use
          list_queues instead).

          CLI Example:

             salt '*' rabbitmq.list_queues messages consumers

   salt.modules.rabbitmq.list_user_permissions(name, runas=None)
          List     permissions     for     a    user    via    rabbitmqctl
          list_user_permissions

          CLI Example:

             salt '*' rabbitmq.list_user_permissions 'user'.

   salt.modules.rabbitmq.list_users(runas=None)
          Return a list of users based off of rabbitmqctl user_list.

          CLI Example:

             salt '*' rabbitmq.list_users

   salt.modules.rabbitmq.list_vhosts(runas=None)
          Return a list of vhost based on rabbitmqctl list_vhosts.

          CLI Example:

             salt '*' rabbitmq.list_vhosts

   salt.modules.rabbitmq.plugin_is_enabled(name, runas=None)
          Return whether the plugin is enabled.

          CLI Example:

             salt '*' rabbitmq.plugin_is_enabled foo

   salt.modules.rabbitmq.policy_exists(vhost, name, runas=None)
          Return  whether  the  policy   exists   based   on   rabbitmqctl
          list_policies.

          Reference: http://www.rabbitmq.com/ha.html

          CLI Example:

             salt '*' rabbitmq.policy_exists / HA

   salt.modules.rabbitmq.reset(runas=None)
          Return a RabbitMQ node to its virgin state

          CLI Example:

             salt '*' rabbitmq.reset

   salt.modules.rabbitmq.set_permissions(vhost,      user,      conf='.*',
   write='.*', read='.*', runas=None)
          Sets permissions for vhost via rabbitmqctl set_permissions

          CLI Example:

             salt '*' rabbitmq.set_permissions 'myvhost' 'myuser'

   salt.modules.rabbitmq.set_policy(vhost,  name,   pattern,   definition,
   priority=None, runas=None)
          Set a policy based on rabbitmqctl set_policy.

          Reference: http://www.rabbitmq.com/ha.html

          CLI Example:

             salt '*' rabbitmq.set_policy / HA '.*' '{"ha-mode":"all"}'

   salt.modules.rabbitmq.set_user_tags(name, tags, runas=None)
          Add user tags via rabbitmqctl set_user_tags

          CLI Example:

             salt '*' rabbitmq.set_user_tags 'myadmin' 'administrator'

   salt.modules.rabbitmq.start_app(runas=None)
          Start the RabbitMQ application.

          CLI Example:

             salt '*' rabbitmq.start_app

   salt.modules.rabbitmq.status(runas=None)
          return rabbitmq status

          CLI Example:

             salt '*' rabbitmq.status

   salt.modules.rabbitmq.stop_app(runas=None)
          Stops the RabbitMQ application, leaving the Erlang node running.

          CLI Example:

             salt '*' rabbitmq.stop_app

   salt.modules.rabbitmq.user_exists(name, runas=None)
          Return whether the user exists based on rabbitmqctl list_users.

          CLI Example:

             salt '*' rabbitmq.user_exists rabbit_user

   salt.modules.rabbitmq.vhost_exists(name, runas=None)
          Return   whether   the   vhost   exists   based  on  rabbitmqctl
          list_vhosts.

          CLI Example:

             salt '*' rabbitmq.vhost_exists rabbit_host

   salt.modules.raet_publish
   Publish a command from a minion to a target

   salt.modules.raet_publish.full_data(tgt,         fun,         arg=None,
   expr_form='glob', returner='', timeout=5)
          Return  the  full data about the publication, this is invoked in
          the same way as the publish function

          CLI Example:

             salt system.example.com publish.full_data '*' cmd.run 'ls -la /tmp'

             Attention

                    If you need to pass a value to a function argument and
                    that  value  contains  an equal sign, you must include
                    the argument name.  For example:

                 salt '*' publish.full_data test.kwarg arg='cheese=spam'

   salt.modules.raet_publish.publish(tgt, fun, arg=None, expr_form='glob',
   returner='', timeout=5)
          Publish a command from the minion out to other minions.

          Publications  need  to  be  enabled  on  the Salt master and the
          minion needs to have permission to publish the command. The Salt
          master  will  also  prevent  a  recursive publication loop, this
          means that a minion cannot command  another  minion  to  command
          another minion as that would create an infinite command loop.

          The  expr_form  argument  is  used to pass a target other than a
          glob into the execution, the available options are:

          * glob

          * pcre

          * grain

          * grain_pcre

          * pillar

          * pillar_pcre

          * ipcidr

          * range

          * compound

          The arguments sent to the minion publish function are  separated
          with  commas.  This  means that for a minion executing a command
          with multiple args it will look like this:

             salt system.example.com publish.publish '*' user.add 'foo,1020,1020'
             salt system.example.com publish.publish 'os:Fedora' network.interfaces '' grain

          CLI Example:

             salt system.example.com publish.publish '*' cmd.run 'ls -la /tmp'

             Attention

                    If you need to pass a value to a function argument and
                    that  value  contains  an equal sign, you must include
                    the argument name.  For example:

                 salt '*' publish.publish test.kwarg arg='cheese=spam'

   salt.modules.raet_publish.runner(fun, arg=None, timeout=5)
          Execute a runner on the master and  return  the  data  from  the
          runner function

          CLI Example:

             salt publish.runner manage.down

   salt.modules.rallydev
   Support for RallyDev

   New in version 2015.8.0.

   Requires a username and a password in /etc/salt/minion:

   salt.modules.rallydev.list_items(name)
          List items of a particular type

          CLI Examples:

             salt myminion rallydev.list_<item name>s
             salt myminion rallydev.list_users
             salt myminion rallydev.list_artifacts

   salt.modules.rallydev.list_users()
          List the users

          CLI Example:

             salt myminion rallydev.list_users

   salt.modules.rallydev.query_item(name, query_string, order='Rank')
          Query  a  type of record for one or more items. Requires a valid
          query                        string.                         See
          https://rally1.rallydev.com/slm/doc/webservice/introduction.jsp
          for information on query syntax.

          CLI Example:

             salt myminion rallydev.query_<item name> <query string> [<order>]
             salt myminion rallydev.query_task '(Name contains github)'
             salt myminion rallydev.query_task '(Name contains reactor)' Rank

   salt.modules.rallydev.query_user(query_string, order='UserName')
          Update a user

          CLI Example:

             salt myminion rallydev.query_user '(Name contains Jo)'

   salt.modules.rallydev.show_artifact(id_)
          Show an artifact

          CLI Example:

             salt myminion rallydev.show_artifact <artifact id>

   salt.modules.rallydev.show_item(name, id_)
          Show an item

          CLI Example:

             salt myminion rallydev.show_<item name> <item id>

   salt.modules.rallydev.show_user(id_)
          Show a user

          CLI Example:

             salt myminion rallydev.show_user <user id>

   salt.modules.rallydev.update_item(name,  id_,  field=None,  value=None,
   postdata=None)
          Update  an  item. Either a field and a value, or a chunk of POST
          data, may be used, but not both.

          CLI Example:

             salt myminion rallydev.update_<item name> <item id> field=<field> value=<value>
             salt myminion rallydev.update_<item name> <item id> postdata=<post data>

   salt.modules.rallydev.update_user(id_, field, value)
          Update a user

          CLI Example:

             salt myminion rallydev.update_user <user id> <field> <new value>

   salt.modules.random_org
   Module for retrieving random information from Random.org

   New in version 2015.5.0.

   configuration
          This module can be used by either passing an api key and version
          directly or by specifying both in a configuration profile in the
          salt master/minion config.

          For example:

             random_org:
               api_key: 7be1402d-5719-5bd3-a306-3def9f135da5
               api_version: 1

   salt.modules.random_org.generateBlobs(api_key=None,   api_version=None,
   **kwargs)
          List all Slack users.

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * format  -- Specifies the format in which the blobs will
                   be returned. Values allowed are base64 and hex.

          Returns
                 The user list.

          CLI Example:

             salt '*' get_integers number=5 min=1 max=6

             salt '*' get_integers number=5 min=1 max=6

   salt.modules.random_org.generateDecimalFractions(api_key=None,
   api_version=None, **kwargs)
          Generates true random decimal fractions

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * number  --  How many random decimal fractions you need.
                   Must be within the [1,1e4] range.

                 * decimalPlaces -- The number of decimal places  to  use.
                   Must be within the [1,20] range.

                 * replacement  --  Specifies  whether  the random numbers
                   should be picked with replacement. The  default  (true)
                   will  cause  the numbers to be picked with replacement,
                   i.e.,  the  resulting  numbers  may  contain  duplicate
                   values  (like  a series of dice rolls). If you want the
                   numbers picked to be unique (like raffle tickets  drawn
                   from a container), set this value to false.

          Returns
                 A list of decimal fraction

          CLI Example:

             salt '*' random_org.generateDecimalFractions number=10 decimalPlaces=4

             salt '*' random_org.generateDecimalFractions number=10 decimalPlaces=4 replacement=True

   salt.modules.random_org.generateGaussians(api_key=None,
   api_version=None, **kwargs)
          This method  generates  true  random  numbers  from  a  Gaussian
          distribution (also known as a normal distribution).

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * number  --  How  many random numbers you need.  Must be
                   within the [1,1e4] range.

                 * mean -- The distribution's mean.  Must  be  within  the
                   [-1e6,1e6] range.

                 * standardDeviation   --   The   distribution's  standard
                   deviation. Must be within the [-1e6,1e6] range.

                 * significantDigits -- The number of  significant  digits
                   to use. Must be within the [2,20] range.

          Returns
                 The user list.

          CLI Example:

             salt '*' random_org.generateGaussians number=10 mean=0.0 standardDeviation=1.0 significantDigits=8

   salt.modules.random_org.generateIntegers(api_key=None,
   api_version=None, **kwargs)
          Generate random integers

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * number -- The number of integers to generate

                 * minimum -- The lower boundary for the range from  which
                   the  random  numbers will be picked. Must be within the
                   [-1e9,1e9] range.

                 * maximum -- The upper boundary for the range from  which
                   the  random  numbers will be picked. Must be within the
                   [-1e9,1e9] range.

                 * replacement -- Specifies  whether  the  random  numbers
                   should  be  picked with replacement. The default (true)
                   will cause the numbers to be picked  with  replacement,
                   i.e.,  the  resulting  numbers  may  contain  duplicate
                   values (like a series of dice rolls). If you  want  the
                   numbers  picked to be unique (like raffle tickets drawn
                   from a container), set this value to false.

                 * base -- Specifies the base that will be used to display
                   the  numbers.  Values allowed are 2, 8, 10 and 16. This
                   affects the JSON types and formatting of the  resulting
                   data as discussed below.

          Returns
                 A list of integers.

          CLI Example:

             salt '*' random_org.generateIntegers number=5 minimum=1 maximum=6

             salt '*' random_org.generateIntegers number=5 minimum=2 maximum=255 base=2

   salt.modules.random_org.generateStrings(api_key=None, api_version=None,
   **kwargs)
          Generate random strings.

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * number -- The number of strings to generate.

                 * length -- The length of each string. Must be within the
                   [1,20] range. All strings will be of the same length

                 * characters  --  A  string  that  contains  the  set  of
                   characters that are allowed  to  occur  in  the  random
                   strings. The maximum number of characters is 80.

                 * replacement  --  Specifies  whether  the random strings
                   should be picked with replacement. The  default  (true)
                   will  cause  the strings to be picked with replacement,
                   i.e.,  the  resulting  list  of  strings  may   contain
                   duplicates  (like  a series of dice rolls). If you want
                   the strings to be unique  (like  raffle  tickets  drawn
                   from a container), set this value to false.

          Returns
                 A list of strings.

          CLI Example:

             salt '*' random_org.generateStrings number=5 length=8 characters='abcdefghijklmnopqrstuvwxyz'

             salt '*' random_org.generateStrings number=10 length=16 characters'abcdefghijklmnopqrstuvwxyz'

   salt.modules.random_org.generateUUIDs(api_key=None,   api_version=None,
   **kwargs)
          Generate a list of random UUIDs

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

                 * number -- How many random  UUIDs  you  need.   Must  be
                   within the [1,1e3] range.

          Returns
                 A list of UUIDs

          CLI Example:

             salt '*' random_org.generateUUIDs number=5

   salt.modules.random_org.getUsage(api_key=None, api_version=None)
          Show current usages statistics

          Parameters

                 * api_key -- The Random.org api key.

                 * api_version -- The Random.org api version.

          Returns
                 The current usage statistics.

          CLI Example:

             salt '*' random_org.getUsage

             salt '*' random_org.getUsage api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15 api_version=1

   salt.modules.rbenv
   Manage  ruby  installations with rbenv. rbenv is supported on Linux and
   Mac OS X.  rbenv doesn't work on Windows (and isn't really necessary on
   Windows  as  there  is  no  system  Ruby  on  Windows). On Windows, the
   RubyInstaller and/or Pik  are  both  good  alternatives  to  work  with
   multiple versions of Ruby on the same box.

   http://misheska.com/blog/2013/06/15/using-rbenv-to-manage-multiple-versions-of-ruby/

   New in version 0.16.0.

   salt.modules.rbenv.default(ruby=None, runas=None)
          Returns or sets the currently defined default ruby

          ruby   The version to set as the default. Should  match  one  of
                 the  versions  listed  by rbenv.versions.  Leave blank to
                 return the current default.

          CLI Example:

             salt '*' rbenv.default
             salt '*' rbenv.default 2.0.0-p0

   salt.modules.rbenv.do(cmdline, runas=None, env=None)
          Execute a ruby command with rbenv's shims from the user  or  the
          system

          CLI Example:

             salt '*' rbenv.do 'gem list bundler'
             salt '*' rbenv.do 'gem list bundler' deploy

   salt.modules.rbenv.do_with_ruby(ruby, cmdline, runas=None)
          Execute  a ruby command with rbenv's shims using a specific ruby
          version

          CLI Example:

             salt '*' rbenv.do_with_ruby 2.0.0-p0 'gem list bundler'
             salt '*' rbenv.do_with_ruby 2.0.0-p0 'gem list bundler' runas=deploy

   salt.modules.rbenv.install(runas=None, path=None)
          Install rbenv systemwide

          CLI Example:

             salt '*' rbenv.install

   salt.modules.rbenv.install_ruby(ruby, runas=None)
          Install a ruby implementation.

          ruby   The version of Ruby to install, should match one  of  the
                 versions listed by rbenv.list

          runas  The user under which to run rbenv. If not specified, then
                 rbenv will be  run  as  the  user  under  which  Salt  is
                 running.

          Additional  environment  variables can be configured in pillar /
          grains / master:

             rbenv:
               build_env: 'CONFIGURE_OPTS="--no-tcmalloc" CFLAGS="-fno-tree-dce"'

          CLI Example:

             salt '*' rbenv.install_ruby 2.0.0-p0

   salt.modules.rbenv.is_installed(runas=None)
          Check if rbenv is installed

          CLI Example:

             salt '*' rbenv.is_installed

   salt.modules.rbenv.list(runas=None)
          List the installable versions of ruby

          runas  The user under which to run rbenv. If not specified, then
                 rbenv  will  be  run  as  the  user  under  which Salt is
                 running.

          CLI Example:

             salt '*' rbenv.list

   salt.modules.rbenv.rehash(runas=None)
          Run rbenv rehash to update the installed shims

          runas  The user under which to run rbenv. If not specified, then
                 rbenv  will  be  run  as  the  user  under  which Salt is
                 running.

          CLI Example:

             salt '*' rbenv.rehash

   salt.modules.rbenv.uninstall_ruby(ruby, runas=None)
          Uninstall a ruby implementation.

          ruby   The version of ruby to uninstall. Should match one of the
                 versions listed by rbenv.versions.

          runas  The user under which to run rbenv. If not specified, then
                 rbenv will be  run  as  the  user  under  which  Salt  is
                 running.

          CLI Example:

             salt '*' rbenv.uninstall_ruby 2.0.0-p0

   salt.modules.rbenv.update(runas=None, path=None)
          Updates the current versions of rbenv and ruby-build

          runas  The user under which to run rbenv. If not specified, then
                 rbenv will be  run  as  the  user  under  which  Salt  is
                 running.

          CLI Example:

             salt '*' rbenv.update

   salt.modules.rbenv.versions(runas=None)
          List the installed versions of ruby

          CLI Example:

             salt '*' rbenv.versions

   salt.modules.rdp
   Manage RDP Service on Windows servers

   salt.modules.rdp.disable()
          Disable RDP the service on the server

          CLI Example:

             salt '*' rdp.disable

   salt.modules.rdp.disconnect_session(session_id)
          Disconnect a session.

          New in version 2016.11.0.

          Parameters
                 session_id -- The numeric Id of the session.

          Returns
                 A boolean representing whether the disconnect succeeded.

          CLI Example:

             salt '*' rdp.disconnect_session session_id

             salt '*' rdp.disconnect_session 99

   salt.modules.rdp.enable()
          Enable RDP the service on the server

          CLI Example:

             salt '*' rdp.enable

   salt.modules.rdp.get_session(session_id)
          Get information about a session.

          New in version 2016.11.0.

          Parameters
                 session_id -- The numeric Id of the session.

          Returns
                 A dictionary of session information.

          CLI Example:

             salt '*' rdp.get_session session_id

             salt '*' rdp.get_session 99

   salt.modules.rdp.list_sessions(logged_in_users_only=False)
          List information about the sessions.

          New in version 2016.11.0.

          Parameters
                 logged_in_users_only  --  If  True,  only return sessions
                 with users logged in.

          Returns
                 A list containing dictionaries of session information.

          CLI Example:

             salt '*' rdp.list_sessions

   salt.modules.rdp.logoff_session(session_id)
          Initiate the logoff of a session.

          New in version 2016.11.0.

          Parameters
                 session_id -- The numeric Id of the session.

          Returns
                 A boolean representing whether the logoff succeeded.

          CLI Example:

             salt '*' rdp.logoff_session session_id

             salt '*' rdp.logoff_session 99

   salt.modules.rdp.status()
          Show if rdp is enabled on the server

          CLI Example:

             salt '*' rdp.status

   salt.modules.redis
   Module to provide redis functionality to Salt

   New in version 2014.7.0.

   configuration
          This module requires  the  redis  python  module  and  uses  the
          following  defaults  which  may  be  overridden  in  the  minion
          configuration:

      redis.host: 'localhost'
      redis.port: 6379
      redis.db: 0
      redis.password: None

   salt.modules.redismod.bgrewriteaof(host=None,    port=None,    db=None,
   password=None)
          Asynchronously rewrite the append-only file

          CLI Example:

             salt '*' redis.bgrewriteaof

   salt.modules.redismod.bgsave(host=None,       port=None,       db=None,
   password=None)
          Asynchronously save the dataset to disk

          CLI Example:

             salt '*' redis.bgsave

   salt.modules.redismod.config_get(pattern='*',   host=None,   port=None,
   db=None, password=None)
          Get redis server configuration values

          CLI Example:

             salt '*' redis.config_get
             salt '*' redis.config_get port

   salt.modules.redismod.config_set(name,   value,  host=None,  port=None,
   db=None, password=None)
          Set redis server configuration values

          CLI Example:

             salt '*' redis.config_set masterauth luv_kittens

   salt.modules.redismod.dbsize(host=None,       port=None,       db=None,
   password=None)
          Return the number of keys in the selected database

          CLI Example:

             salt '*' redis.dbsize

   salt.modules.redismod.delete(*keys, **connection_args)
          Deletes the keys from redis, returns number of keys deleted

          CLI Example:

             salt '*' redis.delete foo

   salt.modules.redismod.exists(key,    host=None,   port=None,   db=None,
   password=None)
          Return true if the key exists in redis

          CLI Example:

             salt '*' redis.exists foo

   salt.modules.redismod.expire(key,   seconds,   host=None,    port=None,
   db=None, password=None)
          Set a keys time to live in seconds

          CLI Example:

             salt '*' redis.expire foo 300

   salt.modules.redismod.expireat(key,  timestamp,  host=None,  port=None,
   db=None, password=None)
          Set a keys expire at given UNIX time

          CLI Example:

             salt '*' redis.expireat foo 1400000000

   salt.modules.redismod.flushall(host=None,      port=None,      db=None,
   password=None)
          Remove all keys from all databases

          CLI Example:

             salt '*' redis.flushall

   salt.modules.redismod.flushdb(host=None,       port=None,      db=None,
   password=None)
          Remove all keys from the selected database

          CLI Example:

             salt '*' redis.flushdb

   salt.modules.redismod.get_key(key,   host=None,   port=None,   db=None,
   password=None)
          Get redis key value

          CLI Example:

             salt '*' redis.get_key foo

   salt.modules.redismod.get_master_ip(host=None,               port=None,
   password=None)
          Get host information about slave

          CLI Example:

             salt '*' redis.get_master_ip

   salt.modules.redismod.hget(key, field, host=None,  port=None,  db=None,
   password=None)
          Get specific field value from a redis hash, returns dict

          CLI Example:

             salt '*' redis.hget foo_hash bar_field

   salt.modules.redismod.hgetall(key,   host=None,   port=None,   db=None,
   password=None)
          Get all fields and values from a redis hash, returns dict

          CLI Example:

             salt '*' redis.hgetall foo_hash

   salt.modules.redismod.info(host=None,        port=None,        db=None,
   password=None)
          Get information and statistics about the server

          CLI Example:

             salt '*' redis.info

   salt.modules.redismod.key_type(key,   host=None,   port=None,  db=None,
   password=None)
          Get redis key type

          CLI Example:

             salt '*' redis.type foo

   salt.modules.redismod.keys(pattern='*', host=None, port=None,  db=None,
   password=None)
          Get redis keys, supports glob style patterns

          CLI Example:

             salt '*' redis.keys
             salt '*' redis.keys test*

   salt.modules.redismod.lastsave(host=None,      port=None,      db=None,
   password=None)
          Get the UNIX time in seconds of the last successful save to disk

          CLI Example:

             salt '*' redis.lastsave

   salt.modules.redismod.llen(key,    host=None,    port=None,    db=None,
   password=None)
          Get the length of a list in Redis

          CLI Example:

             salt '*' redis.llen foo_list

   salt.modules.redismod.lrange(key,  start,  stop,  host=None, port=None,
   db=None, password=None)
          Get a range of values from a list in Redis

          CLI Example:

             salt '*' redis.lrange foo_list 0 10

   salt.modules.redismod.ping(host=None,        port=None,        db=None,
   password=None)
          Ping the server, returns False on connection errors

          CLI Example:

             salt '*' redis.ping

   salt.modules.redismod.save(host=None,        port=None,        db=None,
   password=None)
          Synchronously save the dataset to disk

          CLI Example:

             salt '*' redis.save

   salt.modules.redismod.sentinel_get_master_ip(master,         host=None,
   port=None, password=None)
          Get ip for sentinel master

          CLI Example:

             salt '*' redis.sentinel_get_master_ip 'mymaster'

   salt.modules.redismod.set_key(key,    value,    host=None,   port=None,
   db=None, password=None)
          Set redis key value

          CLI Example:

             salt '*' redis.set_key foo bar

   salt.modules.redismod.shutdown(host=None,      port=None,      db=None,
   password=None)
          Synchronously  save  the  dataset to disk and then shut down the
          server

          CLI Example:

             salt '*' redis.shutdown

   salt.modules.redismod.slaveof(master_host=None,       master_port=None,
   host=None, port=None, db=None, password=None)
          Make  the  server  a slave of another instance, or promote it as
          master

          CLI Example:

             # Become slave of redis-n01.example.com:6379
             salt '*' redis.slaveof redis-n01.example.com 6379
             salt '*' redis.slaveof redis-n01.example.com
             # Become master
             salt '*' redis.slaveof

   salt.modules.redismod.smembers(key,  host=None,   port=None,   db=None,
   password=None)
          Get members in a Redis set

          CLI Example:

             salt '*' redis.smembers foo_set

   salt.modules.redismod.time(host=None,        port=None,        db=None,
   password=None)
          Return the current server UNIX time in seconds

          CLI Example:

             salt '*' redis.time

   salt.modules.redismod.zcard(key,   host=None,    port=None,    db=None,
   password=None)
          Get the length of a sorted set in Redis

          CLI Example:

             salt '*' redis.zcard foo_sorted

   salt.modules.redismod.zrange(key,  start,  stop,  host=None, port=None,
   db=None, password=None)
          Get a range of values from a sorted set in Redis by index

          CLI Example:

             salt '*' redis.zrange foo_sorted 0 10

   salt.modules.reg
   Manage the Windows registry
   Hives
   Hives are the main sections of the registry and all begin with the word
   HKEY.  - HKEY_LOCAL_MACHINE - HKEY_CURRENT_USER - HKEY_USER

   Keys
   Keys  are  the  folders  in  the  registry.  Keys  can have many nested
   subkeys. Keys can have a value assigned to them under the (Default)

   Values or Entries
   Values/Entries are name/data pairs. There can be many values in a  key.
   The  (Default)  value  corresponds  to  the Key, the rest are their own
   value pairs.

   depends

          * winreg Python module

   class salt.modules.reg.Registry
          Delay '_winreg' usage until this module is used

   salt.modules.reg.broadcast_change()
          Refresh the windows environment.

          Returns (bool): True if successful, otherwise False

          CLI Example:

             salt '*' reg.broadcast_change

   salt.modules.reg.delete_key_recursive(hive,                        key,
   use_32bit_registry=False)
          New in version 2015.5.4.

          Delete a registry key to include all subkeys.

          Parameters

                 * hive --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key -- The key to remove (looks like a path)

                 * use_32bit_registry  (bool) -- Deletes the 32bit portion
                   of  the  registry  on  64bit  installations.  On  32bit
                   machines this is ignored.

          Returns
                 A  dictionary  listing the keys that deleted successfully
                 as well as those that failed to delete.

          Return type
                 dict

          The following example will remove salt and all its subkeys  from
          the SOFTWARE key in HKEY_LOCAL_MACHINE:

          CLI Example:

             salt '*' reg.delete_key_recursive HKLM SOFTWARE\salt

   salt.modules.reg.delete_value(hive,           key,          vname=None,
   use_32bit_registry=False)
          Delete a registry value entry or the default value for a key.

          Parameters

                 * hive (str) --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key (str) -- The key (looks like a path) to  the  value
                   name.

                 * vname (str) -- The value name. These are the individual
                   name/data pairs under the key. If not passed,  the  key
                   (Default) value will be deleted.

                 * use_32bit_registry  (bool) -- Deletes the 32bit portion
                   of  the  registry  on  64bit  installations.  On  32bit
                   machines this is ignored.

          Returns
                 Returns True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' reg.delete_value HKEY_CURRENT_USER 'SOFTWARE\Salt' 'version'

   salt.modules.reg.list_keys(hive, key=None, use_32bit_registry=False)
          Enumerates the subkeys in a registry key or hive.

          Parameters

                 * hive (str) --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key  (str)  -- The key (looks like a path) to the value
                   name. If a key is not passed, the keys under  the  hive
                   will be returned.

                 * use_32bit_registry (bool) -- Accesses the 32bit portion
                   of the registry  on  64  bit  installations.  On  32bit
                   machines this is ignored.

          Returns
                 A list of keys/subkeys under the hive or key.

          Return type
                 list

          CLI Example:

             salt '*' reg.list_keys HKLM 'SOFTWARE'

   salt.modules.reg.list_values(hive,  key=None, use_32bit_registry=False,
   include_default=True)
          Enumerates the values in a registry key or hive.

          Parameters

                 * hive (str) --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key (str) -- The key (looks like a path) to  the  value
                   name. If a key is not passed, the values under the hive
                   will be returned.

                 * use_32bit_registry (bool) -- Accesses the 32bit portion
                   of  the  registry  on  64  bit  installations. On 32bit
                   machines this is ignored.

                 * include_default (bool) -- Toggle whether to include the
                   '(Default)' value.

          Returns
                 A list of values under the hive or key.

          Return type
                 list

          CLI Example:

             salt '*' reg.list_values HKLM 'SYSTEM\CurrentControlSet\Services\Tcpip'

   salt.modules.reg.read_value(hive,            key,           vname=None,
   use_32bit_registry=False)
          Reads a registry value entry or the default value for a key.

          Parameters

                 * hive (str) --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key (str) -- The key (looks like a path) to  the  value
                   name.

                 * vname (str) -- The value name. These are the individual
                   name/data pairs under the key. If not passed,  the  key
                   (Default) value will be returned

                 * use_32bit_registry (bool) -- Accesses the 32bit portion
                   of  the  registry  on  64bit  installations.  On  32bit
                   machines this is ignored.

          Returns
                 A  dictionary  containing  the passed settings as well as
                 the  value_data  if  successful.  If  unsuccessful,  sets
                 success to False.

          Return type
                 dict

          If vname is not passed:

          * Returns the first unnamed value (Default) as a string.

          * Returns none if first unnamed value is empty.

          * Returns False if key not found.

          CLI Example:

             salt '*' reg.read_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version'

   salt.modules.reg.set_value(hive,     key,    vname=None,    vdata=None,
   vtype=u'REG_SZ', use_32bit_registry=False, volatile=False)
          Sets a registry value entry or the default value for a key.

          Parameters

                 * hive (str) --

                   The name of the hive. Can be one of the following

                   * HKEY_LOCAL_MACHINE or HKLM

                   * HKEY_CURRENT_USER or HKCU

                   * HKEY_USER or HKU

                 * key (str) -- The key (looks like a path) to  the  value
                   name.

                 * vname (str) -- The value name. These are the individual
                   name/data pairs under the key. If not passed,  the  key
                   (Default) value will be set.

                 * vdata (object) --

                   The  value  data  to  be  set.   What  the type of this
                   paramater should be is determined by the value  of  the
                   vtype paramater. The correspondence is as follows:

                   REG_BINARY
                          binary  data (i.e. str in python version < 3 and
                          bytes in version >=3)

                   REG_DWORD
                          int

                   REG_EXPAND_SZ
                          str

                   REG_MULTI_SZ
                          list of objects of type str

                   REG_SZ str

                 * vtype (str) -- The value type.  The possible values  of
                   the   vtype   paramater  are  indicated  above  in  the
                   description of the vdata paramater.

                 * use_32bit_registry (bool) -- Sets the 32bit portion  of
                   the  registry on 64bit installations. On 32bit machines
                   this is ignored.

                 * volatile (bool) -- When this paramater has a  value  of
                   True,  the  registry key will be made volatile (i.e. it
                   will not persist beyond a system  reset  or  shutdown).
                   This  paramater  only has an effect when a key is being
                   created and at no other time.

          Returns
                 Returns True if successful, False if not

          Return type
                 bool

          CLI Example:

             salt '*' reg.set_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version' '2015.5.2'

          This function is strict about the type of  vdata.  For  instance
          the  the  next  example  will  fail because vtype has a value of
          REG_SZ and vdata has a  type  of  int  (as  opposed  to  str  as
          expected).

          CLI Example:

             salt '*' reg.set_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version' '2015.5.2' \
             vtype=REG_SZ vdata=0

          However, this next example where vdata is properly quoted should
          succeed.

          CLI Example:

             salt '*' reg.set_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version' '2015.5.2' \
             vtype=REG_SZ vdata="'0'"

          An example of using vtype REG_BINARY is as follows:

          CLI Example:

             salt '*' reg.set_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version' '2015.5.2' \
             vtype=REG_BINARY vdata='!!binary d2hhdCdzIHRoZSBwb2ludA=='

          An example of using vtype REG_LIST is as follows:

          CLI Example:

             salt '*' reg.set_value HKEY_LOCAL_MACHINE 'SOFTWARE\Salt' 'version' '2015.5.2' \
             vtype=REG_LIST vdata='[a,b,c]'

   salt.modules.rest_package
   Package support for the REST example

   salt.modules.rest_package.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.rest_service
   Provide the service module for the proxy-minion REST sample

   salt.modules.rest_service.enabled(name, sig=None)
          Only the 'redbull' service is 'enabled' in the test

          New in version 2015.8.1.

   salt.modules.rest_service.get_all()
          Return a list of all available services

          New in version 2015.8.0.

          CLI Example:

             salt '*' service.get_all

   salt.modules.rest_service.list()
          Return a list of all available services.

          CLI Example:

             salt '*' service.list

   salt.modules.rest_service.restart(name, sig=None)
          Restart the specified service with rest_sample

          New in version 2015.8.0.

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.rest_service.running(name, sig=None)
          Return whether this service is running.

          New in version 2015.8.0.

   salt.modules.rest_service.start(name, sig=None)
          Start the specified service on the rest_sample

          New in version 2015.8.0.

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.rest_service.status(name, sig=None)
          Return the status for a service via rest_sample, returns a  bool
          whether the service is running.

          New in version 2015.8.0.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.rest_service.stop(name, sig=None)
          Stop the specified service on the rest_sample

          New in version 2015.8.0.

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.restartcheck module
   checkrestart functionality for Debian and Red Hat Based systems

   Identifies  services  (processes) that are linked against deleted files
   (for example after downloading an updated binary of a shared library).

   Based on checkrestart script  from  debian-goodies  (written   by  Matt
   Zimmerman      for      the      Debian     GNU/Linux     distribution,
   https://packages.debian.org/debian-goodies) and psdel by Sam Morris.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.modules.restartcheck.restartcheck(ignorelist=None, blacklist=None,
   excludepid=None, verbose=True)
          Analyzes  files  openeded  by  running  processes  and seeks for
          packages which need to be restarted.

          Parameters

                 * ignorelist -- string or list of packages to be ignored

                 * blacklist -- string or list of file paths to be ignored

                 * excludepid -- string or  list  of  process  IDs  to  be
                   ignored

                 * verbose -- boolean, enables extensive output

          Returns
                 True if no packages for restart found.  False on failure.
                 String with checkrestart output if some package seems  to
                 need to be restarted.

          New in version 2015.8.3.

          CLI Example:
             salt '*' restartcheck.restartcheck

   salt.modules.ret
   Module  to integrate with the returner system and retrieve data sent to
   a salt returner

   salt.modules.ret.get_fun(returner, fun)
          Return info about last time fun was called on each minion

          CLI Example:

             salt '*' ret.get_fun mysql network.interfaces

   salt.modules.ret.get_jid(returner, jid)
          Return the information for a specified job id

          CLI Example:

             salt '*' ret.get_jid redis 20421104181954700505

   salt.modules.ret.get_jids(returner)
          Return a list of all job ids

          CLI Example:

             salt '*' ret.get_jids mysql

   salt.modules.ret.get_minions(returner)
          Return a list of all minions

          CLI Example:

             salt '*' ret.get_minions mysql

   salt.modules.rh_ip
   The networking module for RHEL/Fedora based distros

   salt.modules.rh_ip.apply_network_settings(**settings)
          Apply global network configuration.

          CLI Example:

             salt '*' ip.apply_network_settings

   salt.modules.rh_ip.build_bond(iface, **settings)
          Create a bond script in /etc/modprobe.d with the passed settings
          and load the bonding kernel module.

          CLI Example:

             salt '*' ip.build_bond bond0 mode=balance-alb

   salt.modules.rh_ip.build_interface(iface,      iface_type,     enabled,
   **settings)
          Build an interface script for a network interface.

          CLI Example:

             salt '*' ip.build_interface eth0 eth <settings>

   salt.modules.rh_ip.build_network_settings(**settings)
          Build the global network script.

          CLI Example:

             salt '*' ip.build_network_settings <settings>

   salt.modules.rh_ip.build_routes(iface, **settings)
          Build a route script for a network interface.

          CLI Example:

             salt '*' ip.build_routes eth0 <settings>

   salt.modules.rh_ip.down(iface, iface_type)
          Shutdown a network interface

          CLI Example:

             salt '*' ip.down eth0

   salt.modules.rh_ip.get_bond(iface)
          Return the content of a bond script

          CLI Example:

             salt '*' ip.get_bond bond0

   salt.modules.rh_ip.get_interface(iface)
          Return the contents of an interface script

          CLI Example:

             salt '*' ip.get_interface eth0

   salt.modules.rh_ip.get_network_settings()
          Return the contents of the global network script.

          CLI Example:

             salt '*' ip.get_network_settings

   salt.modules.rh_ip.get_routes(iface)
          Return the contents of the interface routes script.

          CLI Example:

             salt '*' ip.get_routes eth0

   salt.modules.rh_ip.up(iface, iface_type)
          Start up a network interface

          CLI Example:

             salt '*' ip.up eth0

   salt.modules.rh_service
   Service support for RHEL-based  systems,  including  support  for  both
   upstart and sysvinit

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on a minion, and it is using a different module (or gives  an  error
      similar to 'service.start' is not available), see here.

   salt.modules.rh_service.available(name, limit='')
          Return  True  if  the named service is available.  Use the limit
          param to restrict results to services of that type.

          CLI Examples:

             salt '*' service.available sshd
             salt '*' service.available sshd limit=upstart
             salt '*' service.available sshd limit=sysvinit

   salt.modules.rh_service.delete(name, **kwargs)
          Delete the named service

          New in version 2016.3.

          CLI Example:

             salt '*' service.delete <service name>

   salt.modules.rh_service.disable(name, **kwargs)
          Disable the named service to start at boot

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.rh_service.disabled(name)
          Check to see if the named service is disabled to start on boot

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.rh_service.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.rh_service.enabled(name, **kwargs)
          Check to see if the named service is enabled to start on boot

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.rh_service.get_all(limit='')
          Return all installed services. Use the limit param  to  restrict
          results to services of that type.

          CLI Example:

             salt '*' service.get_all
             salt '*' service.get_all limit=upstart
             salt '*' service.get_all limit=sysvinit

   salt.modules.rh_service.get_disabled(limit='')
          Return  the  disabled  services. Use the limit param to restrict
          results to services of that type.

          CLI Example:

             salt '*' service.get_disabled
             salt '*' service.get_disabled limit=upstart
             salt '*' service.get_disabled limit=sysvinit

   salt.modules.rh_service.get_enabled(limit='')
          Return the enabled services. Use the  limit  param  to  restrict
          results to services of that type.

          CLI Examples:

             salt '*' service.get_enabled
             salt '*' service.get_enabled limit=upstart
             salt '*' service.get_enabled limit=sysvinit

   salt.modules.rh_service.missing(name, limit='')
          The  inverse  of  service.available.   Return  True if the named
          service is not available.   Use  the  limit  param  to  restrict
          results to services of that type.

          CLI Examples:

             salt '*' service.missing sshd
             salt '*' service.missing sshd limit=upstart
             salt '*' service.missing sshd limit=sysvinit

   salt.modules.rh_service.reload(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.rh_service.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.rh_service.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.rh_service.status(name, sig=None)
          Return  the  status  for  a  service, returns a bool whether the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.rh_service.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.riak
   Riak Salt Module

   salt.modules.riak.cluster_commit()
          Commit Cluster Changes

          Changed in version 2015.8.0.

          CLI Example:

             salt '*' riak.cluster_commit

   salt.modules.riak.cluster_join(username, hostname)
          Join a Riak cluster

          Changed in version 2015.8.0.

          CLI Example:

             salt '*' riak.cluster_join <user> <host>

          username - The riak username to join the cluster hostname -  The
          riak hostname you are connecting to

   salt.modules.riak.cluster_leave(username, hostname)
          Leave a Riak cluster

          New in version 2015.8.0.

          CLI Example:

             salt '*' riak.cluster_leave <username> <host>

          username  - The riak username to join the cluster hostname - The
          riak hostname you are connecting to

   salt.modules.riak.cluster_plan()
          Review Cluster Plan

          Changed in version 2015.8.0.

          CLI Example:

             salt '*' riak.cluster_plan

   salt.modules.riak.member_status()
          Get cluster member status

          Changed in version 2015.8.0.

          CLI Example:

             salt '*' riak.member_status

   salt.modules.riak.services()
          List available services on a node

          New in version 2015.8.0.

          CLI Example:

             salt '*' riak.services

   salt.modules.riak.start()
          Start Riak

          CLI Example:

             salt '*' riak.start

   salt.modules.riak.status()
          Current node status

          New in version 2015.8.0.

          CLI Example:

             salt '*' riak.status

   salt.modules.riak.stop()
          Stop Riak

          Changed in version 2015.8.0.

          CLI Example:

             salt '*' riak.stop

   salt.modules.riak.test()
          Runs a test of a few standard Riak operations

          New in version 2015.8.0.

          CLI Example:

             salt '*' riak.test

   salt.modules.rpm
   Support for rpm

   salt.modules.rpm.bin_pkg_info(path, saltenv='base')
          New in version 2015.8.0.

          Parses RPM metadata and  returns  a  dictionary  of  information
          about the package (name, version, etc.).

          path   Path  to  the  file.  Can either be an absolute path to a
                 file on the  minion,  or  a  salt  fileserver  URL  (e.g.
                 salt://path/to/file.rpm).   If  a  salt fileserver URL is
                 passed, the file will be cached to the minion so that  it
                 can be examined.

          saltenv
                 base  Salt  fileserver envrionment from which to retrieve
                 the package. Ignored if path is a local file path on  the
                 minion.

          CLI Example:

             salt '*' lowpkg.bin_pkg_info /root/salt-2015.5.1-2.el7.noarch.rpm
             salt '*' lowpkg.bin_pkg_info salt://salt-2015.5.1-2.el7.noarch.rpm

   salt.modules.rpm.checksum(*paths)
          Return if the signature of a RPM file is valid.

          CLI Example:

             salt '*' lowpkg.checksum /path/to/package1.rpm
             salt '*' lowpkg.checksum /path/to/package1.rpm /path/to/package2.rpm

   salt.modules.rpm.diff(package, path)
          Return  a  formatted diff between current file and original in a
          package.  NOTE: this function includes all files  (configuration
          and not), but does not work on binary content.

          Parameters

                 * package -- The name of the package

                 * path -- Full path to the installed file

          Returns
                 Difference  or  empty  string.  For  binary  files only a
                 notification.

          CLI example:

             salt '*' lowpkg.diff apache2 /etc/apache2/httpd.conf

   salt.modules.rpm.file_dict(*packages)
          List the files that belong to a package, sorted  by  group.  Not
          specifying  any  packages  will return a list of _every_ file on
          the system's rpm database (not generally recommended).

          CLI Examples:

             salt '*' lowpkg.file_dict httpd
             salt '*' lowpkg.file_dict httpd postfix
             salt '*' lowpkg.file_dict

   salt.modules.rpm.file_list(*packages)
          List the files that belong to  a  package.  Not  specifying  any
          packages  will return a list of _every_ file on the system's rpm
          database (not generally recommended).

          CLI Examples:

             salt '*' lowpkg.file_list httpd
             salt '*' lowpkg.file_list httpd postfix
             salt '*' lowpkg.file_list

   salt.modules.rpm.info(*packages, **attr)
          Return  a  detailed  package(s)  summary  information.   If   no
          packages specified, all packages will be returned.

          Parameters

                 * packages --

                 * attr --

                   Comma-separated  package  attributes.  If  no 'attr' is
                   specified, all available attributes returned.

                   Valid attributes are:
                          version,    vendor,     release,     build_date,
                          build_date_time_t,                 install_date,
                          install_date_time_t,     build_host,      group,
                          source_rpm,    arch,   epoch,   size,   license,
                          signature, packager, url, summary, description.

          Returns

          CLI example:

             salt '*' lowpkg.info apache2 bash
             salt '*' lowpkg.info apache2 bash attr=version
             salt '*' lowpkg.info apache2 bash attr=version,build_date_iso,size

   salt.modules.rpm.list_pkgs(*packages)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' lowpkg.list_pkgs

   salt.modules.rpm.modified(*packages, **flags)
          List the modified files that belong to a package. Not specifying
          any  packages  will return a list of _all_ modified files on the
          system's RPM database.

          New in version 2015.5.0.

          CLI examples:

             salt '*' lowpkg.modified httpd
             salt '*' lowpkg.modified httpd postfix
             salt '*' lowpkg.modified

   salt.modules.rpm.owner(*paths)
          Return the name of the package that owns the file. Multiple file
          paths  can  be passed. If a single path is passed, a string will
          be returned, and if multiple paths are passed, a  dictionary  of
          file/package name pairs will be returned.

          If  the file is not owned by a package, or is not present on the
          minion, then an empty string will be returned for that path.

          CLI Examples:

             salt '*' lowpkg.owner /usr/bin/apachectl
             salt '*' lowpkg.owner /usr/bin/apachectl /etc/httpd/conf/httpd.conf

   salt.modules.rpm.verify(*packages, **kwargs)
          Runs an rpm -Va on a system, and returns the results in a dict

          Files with an attribute of config, doc, ghost, license or readme
          in  the  package  header  can  be ignored using the ignore_types
          keyword argument

          CLI Example:

             salt '*' lowpkg.verify
             salt '*' lowpkg.verify httpd
             salt '*' lowpkg.verify httpd postfix
             salt '*' lowpkg.verify httpd postfix ignore_types=['config','doc']

   salt.modules.rpm.version_cmp(ver1, ver2, ignore_epoch=False)
          New in version 2015.8.9.

          Do a cmp-style comparison on two packages. Return -1 if  ver1  <
          ver2,  0  if  ver1 == ver2, and 1 if ver1 > ver2. Return None if
          there was a problem making the comparison.

          ignore_epoch
                 False Set to True to  ignore  the  epoch  when  comparing
                 versions

                 New in version 2015.8.10,2016.3.2.

          CLI Example:

             salt '*' pkg.version_cmp '0.2-001' '0.2.0.1-002'

   salt.modules.rpmbuild
   RPM Package builder system

   New in version 2015.8.0.

   This  system  allows  for all of the components to build rpms safely in
   chrooted environments. This also provides a function  to  generate  yum
   repositories

   This module implements the pkgbuild interface

   salt.modules.rpmbuild.build(runas,  tgt, dest_dir, spec, sources, deps,
   env, template, saltenv='base', log_dir='/var/log/salt/pkgbuild')
          Given the package destination directory, the  spec  file  source
          and package sources, use mock to safely build the rpm defined in
          the spec file

          CLI Example:

             salt '*' pkgbuild.build mock epel-7-x86_64 /var/www/html https://raw.githubusercontent.com/saltstack/libnacl/master/pkg/rpm/python-libnacl.spec https://pypi.python.org/packages/source/l/libnacl/libnacl-1.3.5.tar.gz

          This example command should build the libnacl package for rhel 7
          using user mock and place it in /var/www/html/ on the minion

   salt.modules.rpmbuild.make_repo(repodir,      keyid=None,     env=None,
   use_passphrase=False,   gnupghome='/etc/salt/gpgkeys',    runas='root',
   timeout=15.0)
          Make a package repository and optionally sign packages present

          Given  the  repodir,  create  a  yum  repository out of the rpms
          therein and optionally sign it and packages present, the name is
          directory  to  turn  into  a  repo. This state is best used with
          onchanges linked to your package building states.

          repodir
                 The directory to  find  packages  that  will  be  in  the
                 repository.

          keyid  Changed in version 2016.3.0.

                 Optional   Key   ID   to  use  in  signing  packages  and
                 repository.  Utilizes Public and Private keys  associated
                 with  keyid  which  have  been  loaded  into the minion's
                 Pillar data.

                 For example, contents from a Pillar data file with  named
                 Public and Private keys as follows:

                    gpg_pkg_priv_key: |
                      -----BEGIN PGP PRIVATE KEY BLOCK-----
                      Version: GnuPG v1

                      lQO+BFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      Ebe+8JCQTwqSXPRTzXmy/b5WXDeM79CkLWvuGpXFor76D+ECMRPv/rawukEcNptn
                      R5OmgHqvydEnO4pWbn8JzQO9YX/Us0SMHBVzLC8eIi5ZIopzalvX
                      =JvW8

                      -----END PGP PRIVATE KEY BLOCK-----
                    gpg_pkg_priv_keyname: gpg_pkg_key.pem

                    gpg_pkg_pub_key: |
                      -----BEGIN PGP PUBLIC KEY BLOCK-----
                      Version: GnuPG v1

                      mQENBFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      bYP7t5iwJmQzRMyFInYRt77wkJBPCpJc9FPNebL9vlZcN4zv0KQta+4alcWivvoP
                      4QIxE+/+trC6QRw2m2dHk6aAeq/J0Sc7ilZufwnNA71hf9SzRIwcFXMsLx4iLlki
                      inNqW9c=
                      =s1CX

                      -----END PGP PUBLIC KEY BLOCK-----
                    gpg_pkg_pub_keyname: gpg_pkg_key.pub

          env    Changed in version 2016.3.0.

                 A  dictionary  of environment variables to be utilized in
                 creating the repository.

                 NOTE:
                    This  parameter   is   not   used   for   making   yum
                    repositories.

          use_passphrase
                 False New in version 2016.3.0.

                 Use a passphrase with the signing key presented in keyid.
                 Passphrase is received from Pillar data  which  could  be
                 passed  on  the  command  line with pillar parameter. For
                 example:

                    pillar='{ "gpg_passphrase" : "my_passphrase" }'

          gnupghome
                 /etc/salt/gpgkeys New in version 2016.3.0.

                 Location where GPG related files are  stored,  used  with
                 keyid.

          runas  root New in version 2016.3.0.

                 User  to  create  the  repository as, and optionally sign
                 packages.

                 NOTE:
                    Ensure the user has correct permissions to  any  files
                    and directories which are to be utilized.

          timeout
                 15.0 New in version 2016.3.4.

                 Timeout  in  seconds to wait for the prompt for inputting
                 the passphrase.

          CLI Example:

             salt '*' pkgbuild.make_repo /var/www/html/

   salt.modules.rpmbuild.make_src_pkg(dest_dir, spec,  sources,  env=None,
   template=None, saltenv='base')
          Create a source rpm from the given spec file and sources

          CLI Example:

             salt '*' pkgbuild.make_src_pkg /var/www/html/ https://raw.githubusercontent.com/saltstack/libnacl/master/pkg/rpm/python-libnacl.spec https://pypi.python.org/packages/source/l/libnacl/libnacl-1.3.5.tar.gz

          This example command should build the libnacl SOURCE package and
          place it in /var/www/html/ on the minion

   salt.modules.rsync
   Wrapper for rsync

   New in version 2014.1.0.

   This data can also be passed into pillar.   Options  passed  into  opts
   will overwrite options passed into pillar.

   salt.modules.rsync.config(conf_path='/etc/rsyncd.conf')
          Changed  in  version 2016.3.0: Return data now contains just the
          contents of the rsyncd.conf as a string, instead of a dictionary
          as returned from cmd.run_all.

          Returns the contents of the rsync config file

          conf_path
                 /etc/rsyncd.conf Path to the config file

          CLI Example:

             salt '*' rsync.config

   salt.modules.rsync.rsync(src,     dst,    delete=False,    force=False,
   update=False,   passwordfile=None,   exclude=None,    excludefrom=None,
   dryrun=False)
          Changed  in  version 2016.3.0: Return data now contains just the
          output of the rsync command, instead of a dictionary as returned
          from cmd.run_all.

          Rsync files from src to dst

          CLI Example:

             salt '*' rsync.rsync {src} {dst} {delete=True} {update=True} {passwordfile=/etc/pass.crt} {exclude=xx}
             salt '*' rsync.rsync {src} {dst} {delete=True} {excludefrom=/xx.ini}

   salt.modules.rsync.version()
          Changed  in  version 2016.3.0: Return data now contains just the
          version number as a string, instead of a dictionary as  returned
          from cmd.run_all.

          Returns rsync version

          CLI Example:

             salt '*' rsync.version

   salt.modules.runit
   runit service module (http://smarden.org/runit)

   This module is compatible with the service states, so it can be used to
   maintain services using the provider argument:

      myservice:
        service:
          - running
          - provider: runit

   Provides virtual service module on systems using runit as init.

   Service management rules (sv command):
      service $n is ENABLED   if file SERVICE_DIR/$n/run exists service $n
      is  AVAILABLE  if  ENABLED  or  if  file AVAIL_SVR_DIR/$n/run exists
      service $n is DISABLED  if AVAILABLE but not ENABLED

      SERVICE_DIR/$n is normally a symlink to a AVAIL_SVR_DIR/$n folder

   Service auto-start/stop mechanism:
      sv (auto)starts/stops service as soon  as  SERVICE_DIR/<service>  is
      created/deleted, both on service creation or a boot time.

      autostart  feature  is disabled if file SERVICE_DIR/<n>/down exists.
      This does not  affect  the  current's  service  status  (if  already
      running) nor manual service management.

   Service's alias:
      Service  sva  is  an  alias  of  service  svc when AVAIL_SVR_DIR/sva
      symlinks to folder AVAIL_SVR_DIR/svc. svc can't be enabled if it  is
      already enabled through an alias already enabled, since sv files are
      stored in folder SERVICE_DIR/svc/.

      XBPS package management uses a service's alias to  provides  service
      alternative(s), such as chrony and openntpd both aliased to ntpd.

   salt.modules.runit.add_svc_avail_path(path)
          Add  a path that may contain available services.  Return True if
          added (or already present), False on error.

          path   directory to add to AVAIL_SVR_DIRS

   salt.modules.runit.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          name   the service's name

          CLI Example:

             salt '*' runit.available <service name>

   salt.modules.runit.disable(name, stop=False, **kwargs)
          Don't  start  service  name at boot Returns True if operation is
          successfull

          name   the service's name

          stop   if True, also stops the service

          CLI Example:

             salt '*' service.disable <name> [stop=True]

   salt.modules.runit.disabled(name)
          Return True if the named service is disabled, False  otherwise

          name   the service's name

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.runit.enable(name, start=False, **kwargs)
          Start service name  at  boot.   Returns  True  if  operation  is
          successful

          name   the service's name

          start

                 False  Do  not  start  the  service once enabled. Default
                        mode.  (consistent with other service management)

                 True  : also start the service at the same time  (default
                 sv mode)

          CLI Example:

             salt '*' service.enable <name> [start=True]

   salt.modules.runit.enabled(name)
          Return True if the named service is enabled, False otherwise

          name   the service's name

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.runit.full_restart(name)
          Calls runit.restart()

          name   the service's name

          CLI Example:

             salt '*' runit.full_restart <service name>

   salt.modules.runit.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' runit.get_all

   salt.modules.runit.get_disabled()
          Return a list of all disabled services

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.runit.get_enabled()
          Return a list of all enabled services

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.runit.get_svc_alias()
          Returns  the  list  of service's name that are aliased and their
          alias path(s)

   salt.modules.runit.get_svc_avail_path()
          Return list of paths that may contain available services

   salt.modules.runit.get_svc_broken_path(name='*')
          Return list of broken path(s) in SERVICE_DIR that match name

          A path is broken if it is a broken symlink or can not be a runit
          service

          name   a glob for service name. default is '*'

          CLI Example:

             salt '*' runit.get_svc_broken_path <service name>

   salt.modules.runit.missing(name)
          The  inverse  of runit.available.  Returns True if the specified
          service is not available, otherwise returns False.

          name   the service's name

          CLI Example:

             salt '*' runit.missing <service name>

   salt.modules.runit.reload(name)
          Reload service

          name   the service's name

          CLI Example:

             salt '*' runit.reload <service name>

   salt.modules.runit.remove(name)
          Remove  the  service  <name>  from  system.   Returns  True   if
          operation is successfull.  The service will be also stopped.

          name   the service's name

          CLI Example:

             salt '*' service.remove <name>

   salt.modules.runit.restart(name)
          Restart service

          name   the service's name

          CLI Example:

             salt '*' runit.restart <service name>

   salt.modules.runit.show(name)
          Show properties of one or more units/jobs or the manager

          name   the service's name

          CLI Example:
             salt '*' service.show <service name>

   salt.modules.runit.start(name)
          Start service

          name   the service's name

          CLI Example:

             salt '*' runit.start <service name>

   salt.modules.runit.status(name, sig=None)
          Return True if service is running

          name   the service's name

          sig    signature to identify with ps

          CLI Example:

             salt '*' runit.status <service name>

   salt.modules.runit.status_autostart(name)
          Return  True  if  service  <name>  is  autostarted  by  sv (file
          $service_folder/down does not exist) NB:  return  False  if  the
          service is not enabled.

          name   the service's name

          CLI Example:

             salt '*' runit.status_autostart <service name>

   salt.modules.runit.stop(name)
          Stop service

          name   the service's name

          CLI Example:

             salt '*' runit.stop <service name>

   salt.modules.rvm
   Manage  ruby  installations  and  gemsets  with  RVM,  the Ruby Version
   Manager.

   salt.modules.rvm.do(ruby, command, runas=None, cwd=None)
          Execute a command in an RVM controlled environment.

          ruby   Which ruby to use

          command
                 The rvm command to execute

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          cwd    The directory from which to run the rvm command. Defaults
                 to the user's home directory.

          CLI Example:

             salt '*' rvm.do 2.0.0 <command>

   salt.modules.rvm.gemset_copy(source, destination, runas=None)
          Copy all gems from one gemset to another.

          source The name of  the  gemset  to  copy,  complete  with  ruby
                 version

          destination
                 The destination gemset

          runas  The  user  under which to run rvm. If not specified, then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_copy foobar bazquo

   salt.modules.rvm.gemset_create(ruby, gemset, runas=None)
          Creates a gemset.

          ruby   The ruby version for which to create the gemset

          gemset The name of the gemset to create

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_create 2.0.0 foobar

   salt.modules.rvm.gemset_delete(ruby, gemset, runas=None)
          Delete a gemset

          ruby   The ruby version to which the gemset belongs

          gemset The gemset to delete

          runas  The  user  under which to run rvm. If not specified, then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_delete 2.0.0 foobar

   salt.modules.rvm.gemset_empty(ruby, gemset, runas=None)
          Remove all gems from a gemset.

          ruby   The ruby version to which the gemset belongs

          gemset The gemset to empty

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_empty 2.0.0 foobar

   salt.modules.rvm.gemset_list(ruby='default', runas=None)
          List all gemsets for the given ruby.

          ruby   default The ruby version for which to list the gemsets

          runas  The  user  under which to run rvm. If not specified, then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_list

   salt.modules.rvm.gemset_list_all(runas=None)
          List all gemsets for all installed rubies.

          Note that you must have set a default ruby before this can work.

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.gemset_list_all

   salt.modules.rvm.get(version='stable', runas=None)
          Update RVM

          version
                 stable  Which  version of RVM to install, (e.g. stable or
                 head)

          CLI Example:

             salt '*' rvm.get

   salt.modules.rvm.install(runas=None)
          Install RVM system-wide

          runas  The user under which to run the rvm installer script.  If
                 not  specified,  then  it  be run as the user under which
                 Salt is running.

          CLI Example:

             salt '*' rvm.install

   salt.modules.rvm.install_ruby(ruby, runas=None)
          Install a ruby implementation.

          ruby   The version of ruby to install

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.install_ruby 1.9.3-p385

   salt.modules.rvm.is_installed(runas=None)
          Check if RVM is installed.

          CLI Example:

             salt '*' rvm.is_installed

   salt.modules.rvm.list(runas=None)
          List all rvm-installed rubies

          runas  The  user  under which to run rvm. If not specified, then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.list

   salt.modules.rvm.reinstall_ruby(ruby, runas=None)
          Reinstall a ruby implementation

          ruby   The version of ruby to reinstall

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.reinstall_ruby 1.9.3-p385

   salt.modules.rvm.rubygems(ruby, version, runas=None)
          Installs a specific rubygems version in the given ruby

          ruby   The ruby for which to install rubygems

          version
                 The  version  of  rubygems to install, or 'remove' to use
                 the version that ships with 1.9

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.rubygems 2.0.0 1.8.24

   salt.modules.rvm.set_default(ruby, runas=None)
          Set the default ruby

          ruby   The version of ruby to make the default

          runas  The  user  under which to run rvm. If not specified, then
                 rvm will be run as the user under which Salt is running.

          CLI Example:

             salt '*' rvm.set_default 2.0.0

   salt.modules.rvm.wrapper(ruby_string,    wrapper_prefix,    runas=None,
   *binaries)
          Install RVM wrapper scripts

          ruby_string
                 Ruby/gemset to install wrappers for

          wrapper_prefix
                 What  to  prepend  to  the  name of the generated wrapper
                 binaries

          runas  The user under which to run rvm. If not  specified,  then
                 rvm will be run as the user under which Salt is running.

          binaries
                 None  The  names  of the binaries to create wrappers for.
                 When nothing is given, wrappers for ruby, gem, rake, irb,
                 rdoc, ri and testrb are generated.

          CLI Example:

             salt '*' rvm.wrapper <ruby_string> <wrapper_prefix>

   salt.modules.s3
   Connection module for Amazon S3

   configuration
          This module accepts explicit s3 credentials but can also utilize
          IAM roles assigned to the instance  through  Instance  Profiles.
          Dynamic credentials are then automatically obtained from AWS API
          and no further  configuration  is  necessary.  More  Information
          available at:

             http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If  IAM  roles are not used you need to specify them either in a
          pillar or in the minion's config file:

             s3.keyid: GKTADJGHEIQSXMKKRBJ08H
             s3.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

          A service_url may also be specified in the configuration:

             s3.service_url: s3.amazonaws.com

          A role_arn may also be specified in the configuration:

             s3.role_arn: arn:aws:iam::111111111111:role/my-role-to-assume

          If  a   service_url   is   not   specified,   the   default   is
          s3.amazonaws.com. This may appear in various documentation as an
          "endpoint". A comprehensive list for Amazon S3 may be found at:

             http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region

          The service_url will form the basis for the final endpoint  that
          is used to query the service.

          SSL verification may also be turned off in the configuration:
             s3.verify_ssl: False

          This is required if using S3 bucket names that contain a period,
          as these will  not  match  Amazon's  S3  wildcard  certificates.
          Certificate verification is enabled by default.

          AWS region may be specified in the configuration:
             s3.location: eu-central-1

          Default is us-east-1.

          This  module  should  be usable to query other S3-like services,
          such as Eucalyptus.

   depends
          requests

   salt.modules.s3.delete(bucket,   path=None,   action=None,    key=None,
   keyid=None,    service_url=None,    verify_ssl=None,    kms_keyid=None,
   location=None, role_arn=None)
          Delete a bucket, or delete an object from a bucket.

          CLI Example to delete a bucket:

             salt myminion s3.delete mybucket

          CLI Example to delete an object from a bucket:

             salt myminion s3.delete mybucket remoteobject

   salt.modules.s3.get(bucket=None,      path=None,      return_bin=False,
   action=None,  local_file=None,  key=None, keyid=None, service_url=None,
   verify_ssl=None, kms_keyid=None, location=None, role_arn=None)
          List the contents of a  bucket,  or  return  an  object  from  a
          bucket.  Set  return_bin  to True in order to retrieve an object
          wholesale.  Otherwise,  Salt  will  attempt  to  parse  an   XML
          response.

          CLI Example to list buckets:

             salt myminion s3.get

          CLI Example to list the contents of a bucket:

             salt myminion s3.get mybucket

          CLI Example to return the binary contents of an object:

             salt myminion s3.get mybucket myfile.png return_bin=True

          CLI  Example to save the binary contents of an object to a local
          file:

             salt myminion s3.get mybucket myfile.png local_file=/tmp/myfile.png

          It is also possible to perform an action on a bucket. Currently,
          S3 supports the following actions:

             acl
             cors
             lifecycle
             policy
             location
             logging
             notification
             tagging
             versions
             requestPayment
             versioning
             website

          To perform an action on a bucket:

             salt myminion s3.get mybucket myfile.png action=acl

   salt.modules.s3.head(bucket,     path=None,    key=None,    keyid=None,
   service_url=None,   verify_ssl=None,   kms_keyid=None,   location=None,
   role_arn=None)
          Return the metadata for a bucket, or an object in a bucket.

          CLI Examples:

             salt myminion s3.head mybucket
             salt myminion s3.head mybucket myfile.png

   salt.modules.s3.put(bucket,  path=None,  return_bin=False, action=None,
   local_file=None,      key=None,      keyid=None,      service_url=None,
   verify_ssl=None, kms_keyid=None, location=None, role_arn=None)
          Create a new bucket, or upload an object to a bucket.

          CLI Example to create a bucket:

             salt myminion s3.put mybucket

          CLI Example to upload an object to a bucket:

             salt myminion s3.put mybucket remotepath local_file=/path/to/file

   salt.modules.s6 module
   s6 service module

   This module is compatible with the service states, so it can be used to
   maintain services using the provider argument:

      myservice:
        service:
          - running
          - provider: s6

   Note that the enabled argument is not available with this provider.

   codeauthor

          :email:`Marek Skrobacki <[email protected]>`

   salt.modules.s6.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' s6.available foo

   salt.modules.s6.full_restart(name)
          Calls s6.restart() function

          CLI Example:

             salt '*' s6.full_restart <service name>

   salt.modules.s6.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' s6.get_all

   salt.modules.s6.missing(name)
          The  inverse  of  s6.available.   Returns  True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' s6.missing foo

   salt.modules.s6.reload(name)
          Send a HUP to service via s6

          CLI Example:

             salt '*' s6.reload <service name>

   salt.modules.s6.restart(name)
          Restart service via s6. This will stop/start service

          CLI Example:

             salt '*' s6.restart <service name>

   salt.modules.s6.start(name)
          Starts service via s6

          CLI Example:

             salt '*' s6.start <service name>

   salt.modules.s6.status(name, sig=None)
          Return the status for a service via s6, return pid if running

          CLI Example:

             salt '*' s6.status <service name>

   salt.modules.s6.stop(name)
          Stops service via s6

          CLI Example:

             salt '*' s6.stop <service name>

   salt.modules.s6.term(name)
          Send a TERM to service via s6

          CLI Example:

             salt '*' s6.term <service name>

   salt.modules.salt_proxy module
   Salt proxy module

   New in version 2015.8.3.

   Module to deploy and manage salt-proxy processes on a minion.

   salt.modules.salt_proxy.configure_proxy(proxyname, start=True)
          Create the salt proxy  file  and  start  the  proxy  process  if
          required

          Parameters

                 * proxyname  --  Name  to  be used for this proxy (should
                   match entries in pillar)

                 * start -- Boolean indicating if the  process  should  be
                   started default = True

          CLI Example:

             salt deviceminion salt_proxy.configure_proxy p8000

   salt.modules.salt_proxy.is_running(proxyname)
          Check  if  the  salt-proxy  process  associated  with this proxy
          (name) is running.

          Returns True if the process is running False otherwise

          Parameters
                 proxyname -- String name of the proxy (p8000 for example)

          CLI Example:

             salt deviceminion salt_proxy.is_running p8000

   salt.modules.saltcloudmod
   Control a salt cloud system

   salt.modules.saltcloudmod.create(name, profile)
          Create the named vm

          CLI Example:

             salt <minion-id> saltcloud.create webserver rackspace_centos_512

   salt.modules.saltutil
   The Saltutil module is used to manage the  state  of  the  salt  minion
   itself. It is used to manage minion modules as well as automate updates
   to the salt minion.

   depends

          * esky Python module for update functionality

   salt.modules.saltutil.clear_cache()
          Forcibly removes all caches on a minion.

          New in version 2014.7.0.

          WARNING: The safest way to clear a  minion  cache  is  by  first
          stopping  the  minion  and  then deleting the cache files before
          restarting it.

          CLI Example:

             salt '*' saltutil.clear_cache

   salt.modules.saltutil.cmd(tgt,     fun,      arg=(),      timeout=None,
   expr_form='glob', ret='', kwarg=None, ssh=False, **kwargs)
          Assuming this minion is a master, execute a salt command

          CLI Example:

             salt '*' saltutil.cmd

   salt.modules.saltutil.cmd_iter(tgt,    fun,    arg=(),    timeout=None,
   expr_form='glob', ret='', kwarg=None, ssh=False, **kwargs)
          Assuming this minion is a master, execute a salt command

          CLI Example:

             salt '*' saltutil.cmd_iter

   salt.modules.saltutil.find_cached_job(jid)
          Return the data for a specific cached job  id.  Note  this  only
          works  if  cache_jobs  has  previously  been  set to True on the
          minion.

          CLI Example:

             salt '*' saltutil.find_cached_job <job id>

   salt.modules.saltutil.find_job(jid)
          Return the data for a specific job id that is currently running.

          jid    The job id to search for and return data.

          CLI Example:

             salt '*' saltutil.find_job <job id>

          Note that the find_job function  only  returns  job  information
          when  the job is still running. If the job is currently running,
          the output looks something like this:

             # salt my-minion saltutil.find_job 20160503150049487736
             my-minion:
                 ----------
                 arg:
                     - 30
                 fun:
                     test.sleep
                 jid:
                     20160503150049487736
                 pid:
                     9601
                 ret:
                 tgt:
                     my-minion
                 tgt_type:
                     glob
                 user:
                     root

          If the job has already completed, the job cannot  be  found  and
          therefore  the function returns an empty dictionary, which looks
          like this on the CLI:

             # salt my-minion saltutil.find_job 20160503150049487736
             my-minion:
                 ----------

   salt.modules.saltutil.is_running(fun)
          If the named function is running return the data associated with
          it/them.  The argument can be a glob

          CLI Example:

             salt '*' saltutil.is_running state.highstate

   salt.modules.saltutil.kill_all_jobs()
          Sends a kill signal (SIGKILL 9) to all currently running jobs

          CLI Example:

             salt '*' saltutil.kill_all_jobs

   salt.modules.saltutil.kill_job(jid)
          Sends a kill signal (SIGKILL 9) to the named salt job's process

          CLI Example:

             salt '*' saltutil.kill_job <job id>

   salt.modules.saltutil.mmodule(saltenv, fun, *args, **kwargs)
          Loads  minion  modules  from  an environment so that they can be
          used in pillars for that environment

          CLI Example:

             salt '*' saltutil.mmodule base test.ping

   salt.modules.saltutil.refresh_beacons()
          Signal the minion to refresh the beacons.

          CLI Example:

             salt '*' saltutil.refresh_beacons

   salt.modules.saltutil.refresh_modules(async=True)
          Signal the minion to refresh the module and grain data

          The default is to refresh module asynchronously. To block  until
          the module refresh is complete, set the 'async' flag to False.

          CLI Example:

             salt '*' saltutil.refresh_modules

   salt.modules.saltutil.refresh_pillar()
          Signal the minion to refresh the pillar data.

          CLI Example:

             salt '*' saltutil.refresh_pillar

   salt.modules.saltutil.regen_keys()
          Used to regenerate the minion keys.

          CLI Example:

             salt '*' saltutil.regen_keys

   salt.modules.saltutil.revoke_auth(preserve_minion_cache=False)
          The  minion sends a request to the master to revoke its own key.
          Note that the minion session will be revoked and the minion  may
          not  be  able  to  return the result of this command back to the
          master.

          If the 'preserve_minion_cache' flag is set to True,  the  master
          cache for this minion will not be removed.

          CLI Example:

             salt '*' saltutil.revoke_auth

   salt.modules.saltutil.runner(name, **kwargs)
          Execute  a  runner  function.  This  function must be run on the
          master, either by targeting a minion running on a master  or  by
          using salt-call on a master.

          New in version 2014.7.0.

          name   The name of the function to run

          kwargs Any keyword arguments to pass to the runner function

          CLI Example:

          In  this  example, assume that master_minion is a minion running
          on a master.

             salt master_minion saltutil.runner jobs.list_jobs

   salt.modules.saltutil.running()
          Return the data on all running salt processes on the minion

          CLI Example:

             salt '*' saltutil.running

   salt.modules.saltutil.signal_job(jid, sig)
          Sends a signal to the named salt job's process

          CLI Example:

             salt '*' saltutil.signal_job <job id> 15

   salt.modules.saltutil.sync_all(saltenv=None, refresh=True)
          Changed in version 2015.8.11,2016.3.2:  On  masterless  minions,
          pillar modules are now synced, and refreshed when refresh is set
          to True.

          Sync down all of the dynamic modules from the file server for  a
          specific environment. This function synchronizes custom modules,
          states, beacons, grains, returners, output  modules,  renderers,
          and utils.

          refresh
                 True  Also  refresh  the  execution modules and recompile
                 pillar data available to the minion. This refresh will be
                 performed  even if no new dynamic modules are synced. Set
                 to False to prevent this refresh.

          IMPORTANT:
             If this function is executed using a  module.run  state,  the
             SLS  file  will  not  have  access  to newly synced execution
             modules unless a refresh argument is added to the state, like
             so:

                 load_my_custom_module:
                   module.run:
                     - name: saltutil.sync_all
                     - refresh: True

             See  here  for  a  more  detailed  explanation of why this is
             necessary.

          CLI Examples:

             salt '*' saltutil.sync_all
             salt '*' saltutil.sync_all saltenv=dev
             salt '*' saltutil.sync_all saltenv=base,dev

   salt.modules.saltutil.sync_beacons(saltenv=None, refresh=True)
          New in version 2015.5.1.

          Sync beacons from salt://_beacons to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If  True,  refresh  the  available  beacons  on  the
                 minion.  This  refresh  will  be performed even if no new
                 beacons are synced. Set to False to prevent this refresh.

          CLI Example:

             salt '*' saltutil.sync_beacons
             salt '*' saltutil.sync_beacons saltenv=dev
             salt '*' saltutil.sync_beacons saltenv=base,dev

   salt.modules.saltutil.sync_engines(saltenv=None, refresh=False)
          New in version 2016.3.0.

          Sync engine modules from salt://_engines to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new engine modules are synced.  Set to False  to  prevent
                 this refresh.

          CLI Examples:

             salt '*' saltutil.sync_engines
             salt '*' saltutil.sync_engines saltenv=base,dev

   salt.modules.saltutil.sync_grains(saltenv=None, refresh=True)
          New in version 0.10.0.

          Sync grains modules from salt://_grains to the minion

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules and
                 recompile pillar data for the minion. This  refresh  will
                 be  performed  even  if no new grains modules are synced.
                 Set to False to prevent this refresh.

          CLI Examples:

             salt '*' saltutil.sync_grains
             salt '*' saltutil.sync_grains saltenv=dev
             salt '*' saltutil.sync_grains saltenv=base,dev

   salt.modules.saltutil.sync_log_handlers(saltenv=None, refresh=True)
          New in version 2015.8.0.

          Sync log handlers from salt://_log_handlers to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new log handlers are synced.  Set  to  False  to  prevent
                 this refresh.

          CLI Examples:

             salt '*' saltutil.sync_log_handlers
             salt '*' saltutil.sync_log_handlers saltenv=dev
             salt '*' saltutil.sync_log_handlers saltenv=base,dev

   salt.modules.saltutil.sync_modules(saltenv=None, refresh=True)
          New in version 0.10.0.

          Sync execution modules from salt://_modules to the minion

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True  If True, refresh the available execution modules on
                 the minion.  This refresh will be performed  even  if  no
                 new execution modules are synced. Set to False to prevent
                 this refresh.

          IMPORTANT:
             If this function is executed using a  module.run  state,  the
             SLS  file  will  not  have  access  to newly synced execution
             modules unless a refresh argument is added to the state, like
             so:

                 load_my_custom_module:
                   module.run:
                     - name: saltutil.sync_modules
                     - refresh: True

             See  here  for  a  more  detailed  explanation of why this is
             necessary.

          CLI Example:

             salt '*' saltutil.sync_modules
             salt '*' saltutil.sync_modules saltenv=dev
             salt '*' saltutil.sync_modules saltenv=base,dev

   salt.modules.saltutil.sync_output(saltenv=None, refresh=True)
          Sync outputters from salt://_output to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new outputters are synced.  Set to False to prevent  this
                 refresh.

          CLI Examples:

             salt '*' saltutil.sync_output
             salt '*' saltutil.sync_output saltenv=dev
             salt '*' saltutil.sync_output saltenv=base,dev

   salt.modules.saltutil.sync_outputters(saltenv=None, refresh=True)
          This function is an alias of sync_output.
             Sync outputters from salt://_output to the minion

             saltenv
                    base The fileserver environment from which to sync. To
                    sync  from  more  than   one   environment,   pass   a
                    comma-separated list.

             refresh
                    True  If True, refresh the available execution modules
                    on the minion.  This refresh will be performed even if
                    no new outputters are synced.  Set to False to prevent
                    this refresh.

             CLI Examples:

                 salt '*' saltutil.sync_output
                 salt '*' saltutil.sync_output saltenv=dev
                 salt '*' saltutil.sync_output saltenv=base,dev

   salt.modules.saltutil.sync_pillar(saltenv=None, refresh=True)
          New in version 2015.8.11,2016.3.2.

          Sync pillar modules from the  salt://_pillar  directory  on  the
          Salt  fileserver.  This  function is environment-aware, pass the
          desired  environment  to  grab  the  contents  of  the   _pillar
          directory  from  that  environment.  The default environment, if
          none is specified,  is base.

          refresh
                 True Also refresh the execution modules available to  the
                 minion, and refresh pillar data.

          NOTE:
             This   function   will  raise  an  error  if  executed  on  a
             traditional (i.e.  not masterless) minion

          CLI Examples:

             salt '*' saltutil.sync_pillar
             salt '*' saltutil.sync_pillar saltenv=dev

   salt.modules.saltutil.sync_proxymodules(saltenv=None, refresh=False)
          New in version 2015.8.2.

          Sync proxy modules from salt://_proxy to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new proxy modules are synced.  Set to  False  to  prevent
                 this refresh.

          CLI Examples:

             salt '*' saltutil.sync_proxymodules
             salt '*' saltutil.sync_proxymodules saltenv=dev
             salt '*' saltutil.sync_proxymodules saltenv=base,dev

   salt.modules.saltutil.sync_renderers(saltenv=None, refresh=True)
          New in version 0.10.0.

          Sync renderers from salt://_renderers to the minion

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True  If True, refresh the available execution modules on
                 the minion.  This refresh will be performed  even  if  no
                 new  renderers  are synced.  Set to False to prevent this
                 refresh. Set to False to prevent this refresh.

          CLI Examples:

             salt '*' saltutil.sync_renderers
             salt '*' saltutil.sync_renderers saltenv=dev
             salt '*' saltutil.sync_renderers saltenv=base,dev

   salt.modules.saltutil.sync_returners(saltenv=None, refresh=True)
          New in version 0.10.0.

          Sync beacons from salt://_returners to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new returners are synced. Set to False  to  prevent  this
                 refresh.

          CLI Examples:

             salt '*' saltutil.sync_returners
             salt '*' saltutil.sync_returners saltenv=dev

   salt.modules.saltutil.sync_sdb(saltenv=None)
          New in version 2015.5.8,2015.8.3.

          Sync sdb modules from salt://_sdb to the minion

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 False  This  argument  has  no affect and is included for
                 consistency with the other sync functions.

          CLI Example:

             salt '*' saltutil.sync_sdb
             salt '*' saltutil.sync_sdb saltenv=dev
             salt '*' saltutil.sync_sdb saltenv=base,dev

   salt.modules.saltutil.sync_states(saltenv=None, refresh=True)
          New in version 0.10.0.

          Sync state modules from salt://_states to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available states on the minion.
                 This  refresh  will  be  performed  even  if no new state
                 modules are synced. Set to False to prevent this refresh.

          CLI Examples:

             salt '*' saltutil.sync_states
             salt '*' saltutil.sync_states saltenv=dev
             salt '*' saltutil.sync_states saltenv=base,dev

   salt.modules.saltutil.sync_utils(saltenv=None, refresh=True)
          New in version 2014.7.0.

          Sync utility modules from salt://_utils to the minion

          saltenv
                 base The fileserver environment from which  to  sync.  To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          refresh
                 True If True, refresh the available execution modules  on
                 the  minion.   This  refresh will be performed even if no
                 new utility modules are synced. Set to False  to  prevent
                 this refresh.

          CLI Examples:

             salt '*' saltutil.sync_utils
             salt '*' saltutil.sync_utils saltenv=dev
             salt '*' saltutil.sync_utils saltenv=base,dev

   salt.modules.saltutil.term_all_jobs()
          Sends a termination signal (SIGTERM 15) to all currently running
          jobs

          CLI Example:

             salt '*' saltutil.term_all_jobs

   salt.modules.saltutil.term_job(jid)
          Sends a termination signal (SIGTERM 15) to the named salt  job's
          process

          CLI Example:

             salt '*' saltutil.term_job <job id>

   salt.modules.saltutil.update(version=None)
          Update    the    salt   minion   from   the   URL   defined   in
          opts['update_url'] SaltStack, Inc  provides  the  latest  builds
          here: update_url: https://repo.saltstack.com/windows/

          Be  aware  that  as of 2014-8-11 there's a bug in esky such that
          only the latest version  available  in  the  update_url  can  be
          downloaded and installed.

          This  feature  requires  the  minion  to be running a bdist_esky
          build.

          The version number is optional and  will  default  to  the  most
          recent version available at opts['update_url'].

          Returns details about the transaction upon completion.

          CLI Examples:

             salt '*' saltutil.update
             salt '*' saltutil.update 0.10.3

   salt.modules.saltutil.wheel(name, *args, **kwargs)
          Execute  a  wheel module and function. This function must be run
          against a minion that is local to the master.

          New in version 2014.7.0.

          name   The name of the function to run

          args   Any positional arguments to pass to the wheel function. A
                 common  example of this would be the match arg needed for
                 key functions.

                 New in version v2015.8.11.

          kwargs Any keyword arguments to pass to the wheel function

          CLI Example:

             salt my-local-minion saltutil.wheel key.accept jerry
             salt my-local-minion saltutil.wheel minions.connected

          NOTE:
             Since this function must be run  against  a  minion  that  is
             running  locally  on  the  master  in  order  to get accurate
             returns, if this function is run against minions that are not
             local to the master, "empty" returns are expected. The remote
             minion does not have access  to  wheel  functions  and  their
             return data.

   salt.modules.schedule
   Module for managing the Salt schedule on a minion

   New in version 2014.7.0.

   salt.modules.schedule.add(name, **kwargs)
          Add a job to the schedule

          CLI Example:

             salt '*' schedule.add job1 function='test.ping' seconds=3600
             # If function have some arguments, use job_args
             salt '*' schedule.add job2 function='cmd.run' job_args="['date >> /tmp/date.log']" seconds=60

   salt.modules.schedule.build_schedule_item(name, **kwargs)
          Build a schedule job

          CLI Example:

             salt '*' schedule.build_schedule_item job1 function='test.ping' seconds=3600

   salt.modules.schedule.copy(name, target, **kwargs)
          Copy scheduled job to another minion or minions.

          CLI Example:

             salt '*' schedule.copy jobname target

   salt.modules.schedule.delete(name, **kwargs)
          Delete a job from the minion's schedule

          CLI Example:

             salt '*' schedule.delete job1

   salt.modules.schedule.disable(**kwargs)
          Disable all scheduled jobs on the minion

          CLI Example:

             salt '*' schedule.disable

   salt.modules.schedule.disable_job(name, **kwargs)
          Disable a job in the minion's schedule

          CLI Example:

             salt '*' schedule.disable_job job1

   salt.modules.schedule.enable(**kwargs)
          Enable all scheduled jobs on the minion

          CLI Example:

             salt '*' schedule.enable

   salt.modules.schedule.enable_job(name, **kwargs)
          Enable a job in the minion's schedule

          CLI Example:

             salt '*' schedule.enable_job job1

   salt.modules.schedule.is_enabled(name)
          List a Job only if its enabled

          New in version 2015.5.3.

          CLI Example:

             salt '*' schedule.is_enabled name=job_name

   salt.modules.schedule.list(show_all=False,          show_disabled=True,
   where=None, return_yaml=True)
          List the jobs currently scheduled on the minion

          CLI Example:

             salt '*' schedule.list

             # Show all jobs including hidden internal jobs
             salt '*' schedule.list show_all=True

             # Hide disabled jobs from list of jobs
             salt '*' schedule.list show_disabled=False

   salt.modules.schedule.modify(name, **kwargs)
          Modify an existing job in the schedule

          CLI Example:

             salt '*' schedule.modify job1 function='test.ping' seconds=3600

   salt.modules.schedule.move(name, target, **kwargs)
          Move scheduled job to another minion or minions.

          CLI Example:

             salt '*' schedule.move jobname target

   salt.modules.schedule.purge(**kwargs)
          Purge all the jobs currently scheduled on the minion

          CLI Example:

             salt '*' schedule.purge

   salt.modules.schedule.reload()
          Reload saved scheduled jobs on the minion

          CLI Example:

             salt '*' schedule.reload

   salt.modules.schedule.run_job(name, force=False)
          Run a scheduled job on the minion immediately

          CLI Example:

             salt '*' schedule.run_job job1

             salt '*' schedule.run_job job1 force=True
             Force the job to run even if it is disabled.

   salt.modules.schedule.save(**kwargs)
          Save all scheduled jobs on the minion

          CLI Example:

             salt '*' schedule.save

   salt.modules.scsi
   SCSI administration module

   salt.modules.scsi.ls(get_size=True)
          List SCSI devices, with details

          CLI Examples:

             salt '*' scsi.ls
             salt '*' scsi.ls get_size=False

          get_size
                 True Get the size information  for  scsi  devices.   This
                 option  should be set to False for older OS distributions
                 (RHEL6 and older) due to lack of  support  for  the  '-s'
                 option in lsscsi.

                 New in version 2015.5.10.

   salt.modules.scsi.rescan_all(host)
          List scsi devices

          CLI Example:

             salt '*' scsi.rescan_all(0)

   salt.modules.sdb
   Module for Manipulating Data via the Salt DB API
   salt.modules.sdb.delete(uri)
          Delete  a  value  from  a  db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>.  If the uri provided does not start  with
          sdb:// or the value is not successfully deleted, return False.

          CLI Example:

             salt '*' sdb.delete sdb://mymemcached/foo

   salt.modules.sdb.get(uri)
          Get   a   value   from  a  db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>. If the uri provided does not  start  with
          sdb://, then it will be returned as-is.

          CLI Example:

             salt '*' sdb.get sdb://mymemcached/foo

   salt.modules.sdb.set(uri, value)
          Set   a   value   in   a   db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>.  If the uri provided does not start  with
          sdb:// or the value is not successfully set, return False.

          CLI Example:

             salt '*' sdb.set sdb://mymemcached/foo bar

   salt.modules.seed
   Virtual machine image management tools

   salt.modules.seed.apply(path,  id_=None, config=None, approve_key=True,
   install=True,    prep_install=False,    pub_key=None,    priv_key=None,
   mount_point=None)
          Seed  a  location  (disk image, directory, or block device) with
          the minion config, approve  the  minion's  key,  and/or  install
          salt-minion.

          CLI Example:

             salt 'minion' seed.apply path id [config=config_data] \
                     [gen_key=(true|false)] [approve_key=(true|false)] \
                     [install=(true|false)]

          path   Full path to the directory, device, or disk image  on the
                 target minion's file system.

          id     Minion id with which to seed the path.

          config Minion configuration options. By  default,  the  'master'
                 option is set to the target host's 'master'.

          approve_key
                 Request  a  pre-approval  of  the  generated  minion key.
                 Requires that the salt-master  be  configured  to  either
                 auto-accept all keys or expect a signing request from the
                 target host. Default: true.

          install
                 Install salt-minion, if absent. Default: true.

          prep_install
                 Prepare the bootstrap script, but don't run it.  Default:
                 false

   salt.modules.seed.mkconfig(config=None,       tmp=None,       id_=None,
   approve_key=True, pub_key=None, priv_key=None)
          Generate keys and config and put them in a tmp directory.

          pub_key
                 absolute path or file content of  an  optional  preseeded
                 salt key

          priv_key
                 absolute  path  or  file content of an optional preseeded
                 salt key

          CLI Example:

             salt 'minion' seed.mkconfig [config=config_data] [tmp=tmp_dir] \
                     [id_=minion_id] [approve_key=(true|false)]

   salt.modules.seed.prep_bootstrap(mpt)
          Update and get the random script to a random place

          CLI Example:

             salt '*' seed.prep_bootstrap /tmp

   salt.modules.selinux
   Execute calls on selinux

   NOTE:
      This module requires the semanage, setsebool, and semodule  commands
      to  be  available on the minion. On RHEL-based distributions, ensure
      that the policycoreutils  and  policycoreutils-python  packages  are
      installed.  If  not  on a Fedora or RHEL-based distribution, consult
      the selinux documentation for your distribution to ensure  that  the
      proper packages are installed.

   salt.modules.selinux.getenforce()
          Return the mode selinux is running in

          CLI Example:

             salt '*' selinux.getenforce

   salt.modules.selinux.getsebool(boolean)
          Return the information on a specific selinux boolean

          CLI Example:

             salt '*' selinux.getsebool virt_use_usb

   salt.modules.selinux.getsemod(module)
          Return the information on a specific selinux module

          CLI Example:

             salt '*' selinux.getsemod mysql

          New in version 2016.3.0.

   salt.modules.selinux.list_sebool()
          Return  a  structure  listing all of the selinux booleans on the
          system and what state they are in

          CLI Example:

             salt '*' selinux.list_sebool

   salt.modules.selinux.list_semod()
          Return a structure listing all of the  selinux  modules  on  the
          system and what state they are in

          CLI Example:

             salt '*' selinux.list_semod

          New in version 2016.3.0.

   salt.modules.selinux.selinux_fs_path(*args)
          Return the location of the SELinux VFS directory

          CLI Example:

             salt '*' selinux.selinux_fs_path

   salt.modules.selinux.setenforce(mode)
          Set the SELinux enforcing mode

          CLI Example:

             salt '*' selinux.setenforce enforcing

   salt.modules.selinux.setsebool(boolean, value, persist=False)
          Set the value for a boolean

          CLI Example:

             salt '*' selinux.setsebool virt_use_usb off

   salt.modules.selinux.setsebools(pairs, persist=False)
          Set the value of multiple booleans

          CLI Example:

             salt '*' selinux.setsebools '{virt_use_usb: on, squid_use_tproxy: off}'

   salt.modules.selinux.setsemod(module, state)
          Enable or disable an SELinux module.

          CLI Example:

             salt '*' selinux.setsemod nagios Enabled

          New in version 2016.3.0.

   salt.modules.sensors
   Read lm-sensors

   New in version 2014.1.3.

   salt.modules.sensors.sense(chip, fahrenheit=False)
          Gather lm-sensors data from a given chip

          To  determine  the  chip to query, use the 'sensors' command and
          see the leading line in the block.

          Example:

          /usr/bin/sensors

          coretemp-isa-0000 Adapter: ISA adapter Physical id  0:   +56.0C
          (high = +87.0C, crit = +105.0C) Core 0:         +52.0C  (high
          = +87.0C, crit = +105.0C) Core  1:          +50.0C   (high  =
          +87.0C,  crit  =  +105.0C)  Core  2:          +56.0C  (high =
          +87.0C, crit =  +105.0C)  Core  3:          +53.0C   (high  =
          +87.0C, crit = +105.0C)

          Given the above, the chip is 'coretemp-isa-0000'.

   salt.modules.serverdensity_device
   Wrapper around Server Density API
   New in version 2014.7.0.

   salt.modules.serverdensity_device.create(name, **params)
          Function  to create device in Server Density. For more info, see
          the API docs.

          CLI Example:

             salt '*' serverdensity_device.create lama
             salt '*' serverdensity_device.create rich_lama group=lama_band installedRAM=32768

   salt.modules.serverdensity_device.delete(device_id)
          Delete a device from Server Density. For more  information,  see
          the API docs.

          CLI Example:

             salt '*' serverdensity_device.delete 51f7eafcdba4bb235e000ae4

   salt.modules.serverdensity_device.get_sd_auth(val,
   sd_auth_pillar_name='serverdensity')
          Returns  requested  Server  Density  authentication  value  from
          pillar.

          CLI Example:

             salt '*' serverdensity_device.get_sd_auth <val>

   salt.modules.serverdensity_device.install_agent(agent_key,
   agent_version=1)
          Function  downloads  Server  Density  installation  agent,   and
          installs  sd-agent  with agent_key. Optionally the agent_version
          would select the series to use (defaults on the v1 one).

          CLI Example:

             salt '*' serverdensity_device.install_agent c2bbdd6689ff46282bdaa07555641498
             salt '*' serverdensity_device.install_agent c2bbdd6689ff46282bdaa07555641498 2

   salt.modules.serverdensity_device.ls(**params)
          List devices in Server Density

          Results will be filtered by any params passed to this  function.
          For more information, see the API docs on listing and searching.

          CLI Example:

             salt '*' serverdensity_device.ls
             salt '*' serverdensity_device.ls name=lama
             salt '*' serverdensity_device.ls name=lama group=lama_band installedRAM=32768

   salt.modules.serverdensity_device.update(device_id, **params)
          Updates   device   information   in  Server  Density.  For  more
          information see the API docs.

          CLI Example:

             salt '*' serverdensity_device.update 51f7eafcdba4bb235e000ae4 name=lama group=lama_band
             salt '*' serverdensity_device.update 51f7eafcdba4bb235e000ae4 name=better_lama group=rock_lamas swapSpace=512

   salt.modules.service
   service is a virtual module that is fulfilled by one of  the  following
   modules:

               
               Execution Module  Used for                   
               
               debian_service    Debian Wheezy and earlier  
               
               freebsdservice    FreeBSD-based  OSes  using 
                                 service(8)                 
               
               gentoo_service    Gentoo     Linux     using 
                                 sysvinit and rc-update(8)  
               
               launchctl         Mac    OS    hosts   using 
                                 launchctl(1)               
               
               netbsdservice     NetBSD-based OSes          
               
               openbsdservice    OpenBSD-based OSes         
               
               rh_service        RedHat-based  distros  and 
                                 derivatives          using 
                                 service(8)             and 
                                 chkconfig(8).     Supports 
                                 both  pure  sysvinit   and 
                                 mixed     sysvinit/upstart 
                                 systems.                   
               
               service           Fallback   which    simply 
                                 wraps sysvinit scripts     
               
               smf               Solaris-based  OSes  which 
                                 use SMF                    
               
               systemd           Linux  distros  which  use 
                                 systemd                    
               
               upstart           Ubuntu-based distros using 
                                 upstart                    
               
               win_service       Windows                    
               

   If Salt's OS detection does not identify a  different  virtual  service
   module,  the  minion  will  fall back to using this basic module, which
   simply wraps sysvinit scripts.

   salt.modules.service.available(name)
          Returns True if the specified service  is  available,  otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.service.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' service.get_all

   salt.modules.service.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.service.reload(name)
          Refreshes config files  by  calling  service  reload.  Does  not
          perform a full restart.

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.service.restart(name)
          Restart the specified service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.service.run(name, action)
          Run the specified service with an action.

          New in version 2015.8.1.

          name   Service name.

          action Action name (like start,  stop,  reload,  restart).

          CLI Example:

             salt '*' service.run apache2 reload
             salt '*' service.run postgresql initdb

   salt.modules.service.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.service.status(name, sig=None)
          Return  the  status  for  a service, returns the PID or an empty
          string if the service is running or not, pass a signature to use
          to find the service via ps

          CLI Example:

             salt '*' service.status <service name> [service signature]

   salt.modules.service.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.shadow
   shadow  is  a  virtual module that is fulfilled by one of the following
   modules:

                
                Execution Module  Used for                 
                
                shadow            Linux                    
                
                bsd_shadow        FreeBSD, OpenBSD, NetBSD 
                
                solaris_shadow    Solaris-based OSes       
                
                win_shadow        Windows                  
                

   Manage the shadow file on Linux systems

   IMPORTANT:
      If you feel  that  Salt  should  be  using  this  module  to  manage
      passwords  on a minion, and it is using a different module (or gives
      an error similar to 'shadow.info' is not available), see here.

   salt.modules.shadow.default_hash()
          Returns the default hash used for unset passwords

          CLI Example:

             salt '*' shadow.default_hash

   salt.modules.shadow.del_password(name)
          New in version 2014.7.0.

          Delete the password from name user

          CLI Example:

             salt '*' shadow.del_password username

   salt.modules.shadow.gen_password(password,             crypt_salt=None,
   algorithm='sha512')
          New in version 2014.7.0.

          Generate hashed password

          NOTE:
             When   called   this   function   is   called   directly  via
             remote-execution, the password argument may be  displayed  in
             the  system's  process  list.  This may be a security risk on
             certain systems.

          password
                 Plaintext password to be hashed.

          crypt_salt
                 Crpytographic salt. If not given,  a  random  8-character
                 salt will be generated.

          algorithm
                 The following hash algorithms are supported:

                 * md5

                 * blowfish  (not  in  mainline  glibc,  only available in
                   distros that add it)

                 * sha256

                 * sha512 (default)

          CLI Example:

             salt '*' shadow.gen_password 'I_am_password'
             salt '*' shadow.gen_password 'I_am_password' crypt_salt='I_am_salt' algorithm=sha256

   salt.modules.shadow.info(name)
          Return information for the specified user

          CLI Example:

             salt '*' shadow.info root

   salt.modules.shadow.lock_password(name)
          New in version 2016.11.0.

          Lock the password from name user

          CLI Example:

             salt '*' shadow.lock_password username

   salt.modules.shadow.set_date(name, date)
          Sets the value for the date the password  was  last  changed  to
          days since the epoch (January 1, 1970). See man chage.

          CLI Example:

             salt '*' shadow.set_date username 0

   salt.modules.shadow.set_expire(name, expire)
          Changed in version 2014.7.0.

          Sets  the  value  for the date the account expires as days since
          the epoch (January 1, 1970). Using a  value  of  -1  will  clear
          expiration. See man chage.

          CLI Example:

             salt '*' shadow.set_expire username -1

   salt.modules.shadow.set_inactdays(name, inactdays)
          Set  the  number  of  days  of  inactivity  after a password has
          expired before the account is locked. See man chage.

          CLI Example:

             salt '*' shadow.set_inactdays username 7

   salt.modules.shadow.set_maxdays(name, maxdays)
          Set the maximum number of days during which a password is valid.
          See man chage.

          CLI Example:

             salt '*' shadow.set_maxdays username 90

   salt.modules.shadow.set_mindays(name, mindays)
          Set the minimum number of days between password changes. See man
          chage.

          CLI Example:

             salt '*' shadow.set_mindays username 7

   salt.modules.shadow.set_password(name, password, use_usermod=False)
          Set the password for a  named  user.  The  password  must  be  a
          properly  defined  hash. The password hash can be generated with
          this command:

          python   -c   "import   crypt;   print   crypt.crypt('password',
          '\$6\$SALTsalt')"

          SALTsalt is the 8-character crpytographic salt. Valid characters
          in the salt are ., /, and any alphanumeric character.

          Keep in mind that the $6 represents a sha512 hash, if your OS is
          using  a  different  hashing  algorithm this needs to be changed
          accordingly

          CLI Example:

             salt '*' shadow.set_password root '$1$UYCIxa628.9qXjpQCjM4a..'

   salt.modules.shadow.set_warndays(name, warndays)
          Set the number of days of warning before a  password  change  is
          required.  See man chage.

          CLI Example:

             salt '*' shadow.set_warndays username 7

   salt.modules.shadow.unlock_password(name)
          New in version 2016.11.0.

          Unlock the password from name user

          CLI Example:

             salt '*' shadow.unlock_password username

   salt.modules.slack_notify
   Module for sending messages to Slack

   New in version 2015.5.0.

   configuration
          This module can be used by either passing an api key and version
          directly or by specifying both in a configuration profile in the
          salt master/minion config.

          For example:

             slack:
               api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.slack_notify.call_hook(message,           attachment=None,
   color='good',     short=False,      identifier=None,      channel=None,
   username=None, icon_emoji=None)
          Send message to Slack incomming webhook.

          Parameters

                 * message -- The topic of message.

                 * attachment  --  The  message  to  send  to  the  Slacke
                   WebHook.

                 * color -- The color of border of left side

                 * short -- An optional flag indicating whether the  value
                   is short enough to be displayed side-by-side with other
                   values.

                 * identifier -- The identifier of WebHook.

                 * channel -- The channel to use instead  of  the  WebHook
                   default.

                 * username -- Username to use instead of WebHook default.

                 * icon_emoji -- Icon to use instead of WebHook default.

          Returns
                 Boolean if message was sent successfuly.

          CLI Example:

             salt '*' slack.post_hook message='Hello, from SaltStack'

   salt.modules.slack_notify.find_room(name, api_key=None)
          Find a room by name and return it.

          Parameters

                 * name -- The room name.

                 * api_key -- The Slack admin api key.

          Returns
                 The room object.

          CLI Example:

             salt '*' slack.find_room name="random"

             salt '*' slack.find_room name="random" api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.slack_notify.find_user(name, api_key=None)
          Find a user by name and return it.

          Parameters

                 * name -- The user name.

                 * api_key -- The Slack admin api key.

          Returns
                 The user object.

          CLI Example:

             salt '*' slack.find_user name="ThomasHatch"

             salt '*' slack.find_user name="ThomasHatch" api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.slack_notify.list_rooms(api_key=None)
          List all Slack rooms.

          Parameters
                 api_key -- The Slack admin api key.

          Returns
                 The room list.

          CLI Example:

             salt '*' slack.list_rooms

             salt '*' slack.list_rooms api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.slack_notify.list_users(api_key=None)
          List all Slack users.

          Parameters
                 api_key -- The Slack admin api key.

          Returns
                 The user list.

          CLI Example:

             salt '*' slack.list_users

             salt '*' slack.list_users api_key=peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.modules.slack_notify.post_message(channel,   message,   from_name,
   api_key=None, icon=None)
          Send a message to a Slack channel.

          Parameters

                 * channel -- The channel name, either will work.

                 * message -- The message to send to the Slack channel.

                 * from_name -- Specify who the message is from.

                 * api_key -- The Slack api key, if not specified  in  the
                   configuration.

                 * icon  --  URL  to  an image to use as the icon for this
                   message

          Returns
                 Boolean if message was sent successfully.

          CLI Example:

             salt '*' slack.post_message channel="Development Room" message="Build is done" from_name="Build Server"

   salt.modules.slsutil
   Utility functions for use with or in SLS files

   salt.modules.slsutil.renderer(path=None,                   string=None,
   default_renderer='jinja|yaml', **kwargs)
          Parse a string or file through Salt's renderer system

          This  is an open-ended function and can be used for a variety of
          tasks. It makes use of Salt's "renderer pipes" system to  run  a
          string  or  file  through  a  pipe of any of the loaded renderer
          modules.

          Parameters

                 * path -- The path to a file on the filesystem.

                 * string -- An inline string to be used as  the  file  to
                   send   through  the  renderer  system.  Note,  not  all
                   renderer  modules  can  work  with  strings;  the  'py'
                   renderer requires a file, for example.

                 * default_renderer  -- The renderer pipe to send the file
                   through; this is overridden by a "she-bang" at the  top
                   of the file.

                 * kwargs    --   Keyword   args   to   pass   to   Salt's
                   compile_template() function.

          Keep  in  mind  the  goal  of  each  renderer  when  choosing  a
          render-pipe;  for  example,  the Jinja renderer processes a text
          file and produces a string, however the YAML renderer  processes
          a text file and produces a data structure.

          One  possible  use  is  to  allow  writing  "map  files", as are
          commonly seen in Salt formulas, but without tying  the  renderer
          of  the map file to the renderer used in the other sls files. In
          other words, a map file could use the Python renderer and  still
          be  included  and  used  by  an  sls  file that uses the default
          'jinja|yaml' renderer.

          For example, the  two  following  map  files  produce  identical
          results but one is written using the normal 'jinja|yaml' and the
          other is using 'py':

             #!jinja|yaml
             {% set apache = salt.grains.filter_by({
                 ...normal jinja map file here...
             }, merge=salt.pillar.get('apache:lookup')) %}
             {{ apache | yaml() }}

             #!py
             def run():
                 apache = __salt__.grains.filter_by({
                     ...normal map here but as a python dict...
                 }, merge=__salt__.pillar.get('apache:lookup'))
                 return apache

          Regardless of which of the above map files is used,  it  can  be
          accessed  from  any other sls file by calling this function. The
          following is a usage example in Jinja:

             {% set apache = salt.slsutil.renderer('map.sls') %}

          CLI Example:

             salt '*' slsutil.renderer /path/to/file
             salt '*' slsutil.renderer /path/to/file.jinja 'jinja'
             salt '*' slsutil.renderer /path/to/file.sls 'jinja|yaml'
             salt '*' slsutil.renderer string='Inline template! {{ saltenv }}'
             salt '*' slsutil.renderer string='Hello, {{ name }}.' name='world'

   salt.modules.smartos_imgadm
   Module for running imgadm command on SmartOS

   salt.modules.smartos_imgadm.avail(search=None, verbose=False)
          Return a list of available images

          search string search keyword

          verbose
                 boolean (False) toggle verbose output

          CLI Example:

             salt '*' imgadm.avail [percona]
             salt '*' imgadm.avail verbose=True

   salt.modules.smartos_imgadm.delete(uuid)
          Remove an installed image

          uuid   string Specifies uuid to import

          CLI Example:

             salt '*' imgadm.delete e42f8c84-bbea-11e2-b920-078fab2aab1f

   salt.modules.smartos_imgadm.get(uuid)
          Return info on an installed image

          uuid   string uuid of image

          CLI Example:

             salt '*' imgadm.get e42f8c84-bbea-11e2-b920-078fab2aab1f

   salt.modules.smartos_imgadm.import(uuid, verbose=False)
          Import an image from the repository

          uuid   string uuid to import

          verbose
                 boolean (False) toggle verbose output

          CLI Example:

             salt '*' imgadm.import e42f8c84-bbea-11e2-b920-078fab2aab1f [verbose=True]

   salt.modules.smartos_imgadm.list(verbose=False)
          Return a list of installed images

          verbose
                 boolean (False) toggle verbose output

          CLI Example:

             salt '*' imgadm.list [verbose=True]

   salt.modules.smartos_imgadm.show(uuid)
          Show manifest of a given image

          uuid   string uuid of image

          CLI Example:

             salt '*' imgadm.show e42f8c84-bbea-11e2-b920-078fab2aab1f

   salt.modules.smartos_imgadm.update(uuid='')
          Gather info on unknown image(s) (locally installed)

          uuid   string optional uuid of image

          CLI Example:

             salt '*' imgadm.update [uuid]

   salt.modules.smartos_imgadm.vacuum(verbose=False)
          Remove unused images

          verbose
                 boolean (False) toggle verbose output

          CLI Example:

             salt '*' imgadm.vacuum [verbose=True]

   salt.modules.smartos_imgadm.version()
          Return imgadm version

          CLI Example:

             salt '*' imgadm.version

   salt.modules.smartos_nictagadm module
   Module for running nictagadm command on SmartOS  :maintainer:     Jorge
   Schrauwen    <[email protected]>    :maturity:         new   :depends:
   nictagadm binary, dladm binary :platform:      smartos

   ..versionadded:: 2016.11.0

   salt.modules.smartos_nictagadm.add(name, mac, mtu=1500)
          Add a new nictag

          name   string name of new nictag

          mac    string mac of parent interface or 'etherstub' to create a
                 ether stub

          mtu    int MTU

          CLI Example:

             salt '*' nictagadm.add storage etherstub
             salt '*' nictagadm.add trunk 'DE:AD:OO:OO:BE:EF' 9000

   salt.modules.smartos_nictagadm.delete(name, force=False)
          Delete nictag

          name   string nictag to delete

          force  boolean force delete even if vms attached

          CLI Example:

             salt '*' nictagadm.exists admin

   salt.modules.smartos_nictagadm.exists(*nictag, **kwargs)
          Check if nictags exists

          nictag string one or more nictags to check

          verbose
                 boolean return list of nictags

          CLI Example:

             salt '*' nictagadm.exists admin

   salt.modules.smartos_nictagadm.list(include_etherstubs=True)
          List all nictags

          include_etherstubs
                 boolean toggle include of etherstubs

          CLI Example:

             salt '*' nictagadm.list

   salt.modules.smartos_nictagadm.update(name, mac=None, mtu=None)
          Update a nictag

          name   string name of nictag

          mac    string optional new mac for nictag

          mtu    int optional new MTU for nictag

          CLI Example:

             salt '*' nictagadm.update trunk mtu=9000

   salt.modules.smartos_nictagadm.vms(nictag)
          List all vms connect to nictag

          nictag string name of nictag

          CLI Example:

             salt '*' nictagadm.vms admin

   salt.modules.smartos_virt
   virst compatibility module for managing VMs on SmartOS

   salt.modules.smartos_virt.create(domain)
          Deprecated since version Nitrogen: Use start() instead.

          Start a defined domain

          CLI Example:

             salt '*' virt.create <domain>

   salt.modules.smartos_virt.destroy(domain)
          Deprecated since version Nitrogen: Use stop() instead.

          Power off a defined domain

          CLI Example:

             salt '*' virt.destroy <domain>

   salt.modules.smartos_virt.get_macs(domain)
          Return a list off MAC addresses from the named VM

          CLI Example:

             salt '*' virt.get_macs <domain>

   salt.modules.smartos_virt.init(**kwargs)
          Initialize a new VM

          CLI Example:

             salt '*' virt.init image_uuid='...' alias='...' [...]

   salt.modules.smartos_virt.list_active_vms()
          Return a list of uuids for active virtual machine on the minion

          CLI Example:

             salt '*' virt.list_active_vms

   salt.modules.smartos_virt.list_domains()
          Return a list of virtual machine names on the minion

          CLI Example:

             salt '*' virt.list_domains

   salt.modules.smartos_virt.list_inactive_vms()
          Return  a  list  of  uuids  for  inactive virtual machine on the
          minion

          CLI Example:

             salt '*' virt.list_inactive_vms

   salt.modules.smartos_virt.list_vms()
          Deprecated since version Nitrogen: Use list_domains() instead.

          List all virtual machines.

          CLI Example:

             salt '*' virt.list_vms <domain>

   salt.modules.smartos_virt.reboot(domain)
          Reboot a domain via ACPI request

          CLI Example:

             salt '*' virt.reboot <domain>

   salt.modules.smartos_virt.setmem(domain, memory)
          Change the amount of memory allocated to VM.  <memory> is to  be
          specified in MB.

          Note for KVM : this would require a restart of the VM.

          CLI Example:

             salt '*' virt.setmem <domain> 512

   salt.modules.smartos_virt.shutdown(domain)
          Send a soft shutdown signal to the named vm

          CLI Example:

             salt '*' virt.shutdown <domain>

   salt.modules.smartos_virt.start(domain)
          Start a defined domain

          CLI Example:

             salt '*' virt.start <domain>

   salt.modules.smartos_virt.stop(domain)
          Hard  power  down  the  virtual  machine,  this is equivalent to
          powering off the hardware.

          CLI Example:

             salt '*' virt.destroy <domain>

   salt.modules.smartos_virt.vm_info(domain)
          Return a dict with information about the specified VM on this CN

          CLI Example:

             salt '*' virt.vm_info <domain>

   salt.modules.smartos_virt.vm_virt_type(domain)
          Return VM virtualization type : OS or KVM

          CLI Example:

             salt '*' virt.vm_virt_type <domain>

   salt.modules.smartos_vmadm
   Module for running vmadm command on SmartOS

   salt.modules.smartos_vmadm.create(from_file=None, **kwargs)
          Create a new vm

          from_file
                 string json file to create the vm from -- if present, all
                 other options will be ignored

          kwargs string|int|...  options to set for the vm

          CLI Example:

             salt '*' vmadm.create from_file=/tmp/new_vm.json
             salt '*' vmadm.create image_uuid='...' alias='...' nics='[{ "nic_tag": "admin", "ip": "198.51.100.123", ...}, {...}]' [...]

   salt.modules.smartos_vmadm.create_snapshot(vm, name, key='uuid')
          Create snapshot of a vm

          vm     string vm to be targeted

          name   string.INDENT 7.0

          snapshot name
                 The  snapname must be 64 characters or less and must only
                 contain alphanumeric characters and characters in the set
                 [-_.:%] to comply with ZFS restrictions.

   key    string [uuid|alias|hostname] value type of 'vm' parameter

   CLI Example:

             salt '*' vmadm.create_snapshot 186da9ab-7392-4f55-91a5-b8f1fe770543 baseline
             salt '*' vmadm.create_snapshot nacl baseline key=alias

   salt.modules.smartos_vmadm.delete(vm, key='uuid')
          Delete a vm

          vm     string vm to be deleted

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.delete 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.delete nacl key=alias

   salt.modules.smartos_vmadm.delete_snapshot(vm, name, key='uuid')
          Delete snapshot of a vm

          vm     string vm to be targeted

          name   string.INDENT 7.0

          snapshot name
                 The  snapname must be 64 characters or less and must only
                 contain alphanumeric characters and characters in the set
                 [-_.:%] to comply with ZFS restrictions.

   key    string [uuid|alias|hostname] value type of 'vm' parameter

   CLI Example:

             salt '*' vmadm.delete_snapshot 186da9ab-7392-4f55-91a5-b8f1fe770543 baseline
             salt '*' vmadm.delete_snapshot nacl baseline key=alias

   salt.modules.smartos_vmadm.get(vm, key='uuid')
          Output the JSON object describing a VM

          vm     string vm to be targeted

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.get 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.get nacl key=alias

   salt.modules.smartos_vmadm.info(vm, info_type='all', key='uuid')
          Lookup info on running kvm

          vm     string vm to be targeted

          info_type
                 string
                 [all|block|blockstats|chardev|cpus|kvm|pci|spice|version|vnc]
                 info type to return

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.info 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.info 186da9ab-7392-4f55-91a5-b8f1fe770543 vnc
             salt '*' vmadm.info nacl key=alias
             salt '*' vmadm.info nacl vnc key=alias

   salt.modules.smartos_vmadm.list(search=None,   sort=None,  order='uuid,
   type, ram, state, alias', keyed=True)
          Return a list of VMs

          search string vmadm filter property

          sort   string vmadm sort (-s) property

          order  string   vmadm   order   (-o)   property   --    Default:
                 uuid,type,ram,state,alias

          keyed  boolean.INDENT 7.0

          specified  if  the  output  should  be  an array (False) or dict
          (True)
                 For a dict the key is  the  first  item  from  the  order
                 parameter.  Note: If key is not unique last vm wins.

   CLI Example:

             salt '*' vmadm.list
             salt '*' vmadm.list order=alias,ram,cpu_cap sort=-ram,-cpu_cap
             salt '*' vmadm.list search='type=KVM'

   salt.modules.smartos_vmadm.lookup(search=None, order=None, one=False)
          Return a list of VMs using lookup

          search string vmadm filter property

          order  string    vmadm   order   (-o)   property   --   Default:
                 uuid,type,ram,state,alias

          one    boolean return only one result (vmadm's -1)

          CLI Example:

             salt '*' vmadm.lookup search='state=running'
             salt '*' vmadm.lookup search='state=running' order=uuid,alias,hostname
             salt '*' vmadm.lookup search='alias=nacl' one=True

   salt.modules.smartos_vmadm.reboot(vm, force=False, key='uuid')
          Reboot a vm

          vm     string vm to be rebooted

          force  boolean force reboot of vm if true

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.reboot 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.reboot 186da9ab-7392-4f55-91a5-b8f1fe770543 True
             salt '*' vmadm.reboot vm=nacl key=alias
             salt '*' vmadm.reboot vm=nina.example.org key=hostname

   salt.modules.smartos_vmadm.receive(uuid, source)
          Receive a vm from a directory

          uuid   string uuid of vm to be received

          source string source directory

          CLI Example:

             salt '*' vmadm.receive 186da9ab-7392-4f55-91a5-b8f1fe770543 /opt/backups

   salt.modules.smartos_vmadm.reprovision(vm, image, key='uuid')
          Reprovision a vm

          vm     string vm to be reprovisioned

          image  string uuid of new image

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.reprovision 186da9ab-7392-4f55-91a5-b8f1fe770543 c02a2044-c1bd-11e4-bd8c-dfc1db8b0182
             salt '*' vmadm.reprovision nacl c02a2044-c1bd-11e4-bd8c-dfc1db8b0182 key=alias

   salt.modules.smartos_vmadm.rollback_snapshot(vm, name, key='uuid')
          Rollback snapshot of a vm

          vm     string vm to be targeted

          name   string.INDENT 7.0

          snapshot name
                 The snapname must be 64 characters or less and must  only
                 contain alphanumeric characters and characters in the set
                 [-_.:%] to comply with ZFS restrictions.

   key    string [uuid|alias|hostname] value type of 'vm' parameter

   CLI Example:

             salt '*' vmadm.rollback_snapshot 186da9ab-7392-4f55-91a5-b8f1fe770543 baseline
             salt '*' vmadm.rollback_snapshot nacl baseline key=alias

   salt.modules.smartos_vmadm.send(vm, target, key='uuid')
          Send a vm to a directory

          vm     string vm to be sent

          target string target directory

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.send 186da9ab-7392-4f55-91a5-b8f1fe770543 /opt/backups
             salt '*' vmadm.send vm=nacl target=/opt/backups key=alias

   salt.modules.smartos_vmadm.start(vm, options=None, key='uuid')
          Start a vm

          vm     string vm to be started

          options
                 string optional additional options

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.start 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.start 186da9ab-7392-4f55-91a5-b8f1fe770543 'order=c,once=d cdrom=/path/to/image.iso,ide'
             salt '*' vmadm.start vm=nacl key=alias
             salt '*' vmadm.start vm=nina.example.org key=hostname

   salt.modules.smartos_vmadm.stop(vm, force=False, key='uuid')
          Stop a vm

          vm     string vm to be stopped

          force  boolean force stop of vm if true

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.stop 186da9ab-7392-4f55-91a5-b8f1fe770543
             salt '*' vmadm.stop 186da9ab-7392-4f55-91a5-b8f1fe770543 True
             salt '*' vmadm.stop vm=nacl key=alias
             salt '*' vmadm.stop vm=nina.example.org key=hostname

   salt.modules.smartos_vmadm.sysrq(vm, action='nmi', key='uuid')
          Send non-maskable interrupt to vm or capture a screenshot

          vm     string vm to be targeted

          action string nmi or screenshot -- Default: nmi

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          CLI Example:

             salt '*' vmadm.sysrq 186da9ab-7392-4f55-91a5-b8f1fe770543 nmi
             salt '*' vmadm.sysrq 186da9ab-7392-4f55-91a5-b8f1fe770543 screenshot
             salt '*' vmadm.sysrq nacl nmi key=alias

   salt.modules.smartos_vmadm.update(vm,    from_file=None,    key='uuid',
   **kwargs)
          Update a new vm

          vm     string vm to be updated

          from_file
                 string json file to update the vm with -- if present, all
                 other options will be ignored

          key    string [uuid|alias|hostname] value type of 'vm' parameter

          kwargs string|int|...  options to update for the vm

          CLI Example:

             salt '*' vmadm.update vm=186da9ab-7392-4f55-91a5-b8f1fe770543 from_file=/tmp/new_vm.json
             salt '*' vmadm.update vm=nacl key=alias from_file=/tmp/new_vm.json
             salt '*' vmadm.update vm=186da9ab-7392-4f55-91a5-b8f1fe770543 max_physical_memory=1024

   salt.modules.smbios
   Interface to SMBIOS/DMI

   (Parsing through dmidecode)

   External References
   Desktop Management Interface (DMI)
   System Management BIOS
   DMIdecode

   salt.modules.smbios.get(string, clean=True)
          Get an individual DMI string from SMBIOS info

          string

                 The string to fetch. DMIdecode supports:

                        * bios-vendor

                        * bios-version

                        * bios-release-date

                        * system-manufacturer

                        * system-product-name

                        * system-version

                        * system-serial-number

                        * system-uuid

                        * baseboard-manufacturer

                        * baseboard-product-name

                        * baseboard-version

                        * baseboard-serial-number

                        * baseboard-asset-tag

                        * chassis-manufacturer

                        * chassis-type

                        * chassis-version

                        * chassis-serial-number

                        * chassis-asset-tag

                        * processor-family

                        * processor-manufacturer

                        * processor-version

                        * processor-frequency

          clean
                 Don't return well-known false information
                 (invalid UUID's, serial 000000000's, etcetera)
                 Defaults to True

          CLI Example:

             salt '*' smbios.get system-uuid clean=False

   salt.modules.smbios.records(rec_type=None, fields=None, clean=True)
          Return DMI records from SMBIOS

          type   Return only records of type(s) The  SMBIOS  specification
                 defines the following DMI types:

                            
                            Type  Information                
                            
                            0     BIOS                       
                            
                            1     System                     
                            
                            2     Baseboard                  
                            
                            3     Chassis                    
                            
                            4     Processor                  
                            
                            5     Memory Controller          
                            
                            6     Memory Module              
                            
                            7     Cache                      
                            
                            8     Port Connector             
                            
                            9     System Slots               
                            
                            10    On Board Devices           
                            
                            11    OEM Strings                
                            
                            12    System       Configuration 
                                  Options                    
                            
                            13    BIOS Language              
                            
                            14    Group Associations         
                            
                            15    System Event Log           
                            
                            16    Physical Memory Array      
                            
                            17    Memory Device              
                            
                            18    32-bit Memory Error        
                            
                            19    Memory    Array     Mapped 
                                  Address                    
                            
                            20    Memory    Device    Mapped 
                                  Address                    
                            
                            21    Built-in Pointing Device   
                            
                            22    Portable Battery           
                            
                            23    System Reset               
                            
                            24    Hardware Security          
                            
                            25    System Power Controls      
                            
                            26    Voltage Probe              
                            
                            27    Cooling Device             
                            
                            28    Temperature Probe          
                            
                            29    Electrical Current Probe   
                            
                            30    Out-of-band Remote Access  
                            
                            31    Boot Integrity Services    
                            
                            32    System Boot                
                            

                            33    64-bit Memory Error        
                            
                            34    Management Device          
                            
                            35    Management          Device 
                                  Component                  
                            
                            36    Management          Device 
                                  Threshold Data             
                            
                            37    Memory Channel             
                            
                            38    IPMI Device                
                            
                            39    Power Supply               
                            
                            40    Additional Information     
                            
                            41    Onboard  Devices  Extended 
                                  Information                
                            
                            42    Management Controller Host 
                                  Interface                  
                            

          clean
                 Don't return well-known false information
                 (invalid UUID's, serial 000000000's, etcetera)
                 Defaults to True

          CLI Example:

             salt '*' smbios.records clean=False
             salt '*' smbios.records 14
             salt '*' smbios.records 4 core_count,thread_count,current_speed

   salt.modules.smf
   Service support for Solaris 10 and 11, should work with  other  systems
   that use SMF also. (e.g. SmartOS)

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on a minion, and it is using a different module (or gives  an  error
      similar to 'service.start' is not available), see here.

   salt.modules.smf.available(name)
          Returns  True  if  the specified service is available, otherwise
          returns False.

          We look up the name with the svcs command to get back  the  FMRI
          This allows users to use simpler service names

          CLI Example:

             salt '*' service.available net-snmp

   salt.modules.smf.disable(name, **kwargs)
          Disable the named service to start at boot

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.smf.disabled(name)
          Check to see if the named service is disabled to start on boot

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.smf.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.smf.enabled(name, **kwargs)
          Check to see if the named service is enabled to start on boot

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.smf.get_all()
          Return all installed services

          CLI Example:

             salt '*' service.get_all

   salt.modules.smf.get_disabled()
          Return the disabled services

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.smf.get_enabled()
          Return the enabled services

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.smf.get_running()
          Return the running services

          CLI Example:

             salt '*' service.get_running

   salt.modules.smf.get_stopped()
          Return the stopped services

          CLI Example:

             salt '*' service.get_stopped

   salt.modules.smf.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing net-snmp

   salt.modules.smf.reload(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.smf.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.smf.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.smf.status(name, sig=None)
          Return the status for a service,  returns  a  bool  whether  the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.smf.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.smtp
   Module for Sending Messages via SMTP

   New in version 2014.7.0.

   depends

          * smtplib python module

   configuration
          This  module  can  be  used by either passing a jid and password
          directly to  send_message,  or  by  specifying  the  name  of  a
          configuration  profile  in  the minion config, minion pillar, or
          master config.

          For example:

             my-smtp-login:
                 smtp.server: smtp.domain.com
                 smtp.tls: True
                 smtp.sender: [email protected]
                 smtp.username: myuser
                 smtp.password: verybadpass

          The resourcename refers to  the  resource  that  is  using  this
          account.  It  is  user-definable,  and  optional.  The following
          configurations are both valid:

             my-smtp-login:
                 smtp.server: smtp.domain.com
                 smtp.tls: True
                 smtp.sender: [email protected]
                 smtp.username: myuser
                 smtp.password: verybadpass

             another-smtp-login:
                 smtp.server: smtp.domain.com
                 smtp.tls: True
                 smtp.sender: [email protected]
                 smtp.username: myuser
                 smtp.password: verybadpass

   salt.modules.smtp.send_msg(recipient,  message,  subject='Message  from
   Salt',   sender=None,   server=None,   use_ssl='True',   username=None,
   password=None, profile=None)
          Send a message to an SMTP recipient. Designed for use in states.

          CLI Examples:

             smtp.send_msg '[email protected]' 'This is a salt module test'             profile='my-smtp-account'
             smtp.send_msg '[email protected]' 'This is a salt module test'             username='myuser' password='verybadpass' sender="[email protected]'             server='smtp.domain.com'

   salt.modules.solaris_fmadm
   Module for running fmadm and fmdump on Solaris

   maintainer
          Jorge Schrauwen <[email protected]>

   maturity
          new

   platform
          solaris,illumos

   New in version 2016.3.0.

   salt.modules.solaris_fmadm.acquit(fmri)
          Acquit resource or acquit case

          fmri: string
                 fmri or uuid

          CLI Example:

             salt '*' fmadm.acquit fmri | uuid

   salt.modules.solaris_fmadm.config()
          Display fault manager configuration

          CLI Example:

             salt '*' fmadm.config

   salt.modules.solaris_fmadm.faulty()
          Display list of faulty resources

          CLI Example:

             salt '*' fmadm.faulty

   salt.modules.solaris_fmadm.flush(fmri)
          Flush cached state for resource

          fmri: string
                 fmri

          CLI Example:

             salt '*' fmadm.flush fmri

   salt.modules.solaris_fmadm.healthy()
          Return whether fmadm is reporting faults

          CLI Example:

             salt '*' fmadm.healthy

   salt.modules.solaris_fmadm.list(after=None, before=None)
          Display fault management logs

          after  string filter events  after  time,  see  man  fmdump  for
                 format

          before string  filter  events  before  time,  see man fmdump for
                 format

          CLI Example:

             salt '*' fmadm.list

   salt.modules.solaris_fmadm.load(path)
          Load specified fault manager module

          path: string
                 path of fault manager module

          CLI Example:

             salt '*' fmadm.load /module/path

   salt.modules.solaris_fmadm.repaired(fmri)
          Notify fault manager that resource has been repaired

          fmri: string
                 fmri

          CLI Example:

             salt '*' fmadm.repaired fmri

   salt.modules.solaris_fmadm.replaced(fmri)
          Notify fault manager that resource has been replaced

          fmri: string
                 fmri

          CLI Example:

             salt '*' fmadm.repaired fmri

   salt.modules.solaris_fmadm.reset(module, serd=None)
          Reset module or sub-component

          module: string
                 module to unload

          serd   string serd sub module

          CLI Example:

             salt '*' fmadm.reset software-response

   salt.modules.solaris_fmadm.show(uuid)
          Display log details

          uuid: string
                 uuid of fault

          CLI Example:

             salt '*' fmadm.show 11b4070f-4358-62fa-9e1e-998f485977e1

   salt.modules.solaris_fmadm.unload(module)
          Unload specified fault manager module

          module: string
                 module to unload

          CLI Example:

             salt '*' fmadm.unload software-response

   salt.modules.solaris_group
   Manage groups on Solaris

   IMPORTANT:
      If you feel that Salt should be using this module to  manage  groups
      on  a  minion, and it is using a different module (or gives an error
      similar to 'group.info' is not available), see here.

   salt.modules.solaris_group.add(name, gid=None, **kwargs)
          Add the specified group

          CLI Example:

             salt '*' group.add foo 3456

   salt.modules.solaris_group.chgid(name, gid)
          Change the gid for a named group

          CLI Example:

             salt '*' group.chgid foo 4376

   salt.modules.solaris_group.delete(name)
          Remove the named group

          CLI Example:

             salt '*' group.delete foo

   salt.modules.solaris_group.getent(refresh=False)
          Return info on all groups

          CLI Example:

             salt '*' group.getent

   salt.modules.solaris_group.info(name)
          Return information about a group

          CLI Example:

             salt '*' group.info foo

   salt.modules.solaris_shadow
   Manage the password database on Solaris systems

   IMPORTANT:
      If you feel  that  Salt  should  be  using  this  module  to  manage
      passwords  on a minion, and it is using a different module (or gives
      an error similar to 'shadow.info' is not available), see here.

   salt.modules.solaris_shadow.default_hash()
          Returns the default hash used for unset passwords

          CLI Example:

             salt '*' shadow.default_hash

   salt.modules.solaris_shadow.del_password(name)
          New in version 2015.8.8.

          Delete the password from name user

          CLI Example:

             salt '*' shadow.del_password username

   salt.modules.solaris_shadow.gen_password(password,     crypt_salt=None,
   algorithm='sha512')
          New in version 2015.8.8.

          Generate hashed password

          NOTE:
             When   called   this   function   is   called   directly  via
             remote-execution, the password argument may be  displayed  in
             the  system's  process  list.  This may be a security risk on
             certain systems.

          password
                 Plaintext password to be hashed.

          crypt_salt
                 Crpytographic salt. If not given,  a  random  8-character
                 salt will be generated.

          algorithm
                 The following hash algorithms are supported:

                 * md5

                 * blowfish  (not  in  mainline  glibc,  only available in
                   distros that add it)

                 * sha256

                 * sha512 (default)

          CLI Example:

             salt '*' shadow.gen_password 'I_am_password'
             salt '*' shadow.gen_password 'I_am_password' crypt_salt='I_am_salt' algorithm=sha256

   salt.modules.solaris_shadow.info(name)
          Return information for the specified user

          CLI Example:

             salt '*' shadow.info root

   salt.modules.solaris_shadow.set_maxdays(name, maxdays)
          Set the maximum number of days during which a password is valid.
          See man passwd.

          CLI Example:

             salt '*' shadow.set_maxdays username 90

   salt.modules.solaris_shadow.set_mindays(name, mindays)
          Set the minimum number of days between password changes. See man
          passwd.

          CLI Example:

             salt '*' shadow.set_mindays username 7

   salt.modules.solaris_shadow.set_password(name, password)
          Set the password for a  named  user.  The  password  must  be  a
          properly  defined  hash, the password hash can be generated with
          this command: openssl passwd -1 <plaintext password>

          CLI Example:

             salt '*' shadow.set_password root $1$UYCIxa628.9qXjpQCjM4a..

   salt.modules.solaris_shadow.set_warndays(name, warndays)
          Set the number of days of warning before a  password  change  is
          required.  See man passwd.

          CLI Example:

             salt '*' shadow.set_warndays username 7

   salt.modules.solaris_system
   Support for reboot, shutdown, etc

   This module is assumes we are using solaris-like shutdown

   New in version 2016.3.0.

   salt.modules.solaris_system.halt()
          Halt a running system

          CLI Example:

             salt '*' system.halt

   salt.modules.solaris_system.init(state)
          Change the system runlevel on sysV compatible systems

          CLI Example:

          state  string Init state

             salt '*' system.init 3

   salt.modules.solaris_system.poweroff()
          Poweroff a running system

          CLI Example:

             salt '*' system.poweroff

   salt.modules.solaris_system.reboot(delay=0, message=None)
          Reboot the system

          delay  int  Optional wait time in seconds before the system will
                 be rebooted.

          message
                 string Optional message to broadcast before rebooting.

          CLI Example:

             salt '*' system.reboot
             salt '*' system.reboot 60 "=== system upgraded ==="

   salt.modules.solaris_system.shutdown(delay=0, message=None)
          Shutdown a running system

          delay  int Optional wait time in seconds before the system  will
                 be shutdown.

          message
                 string Optional message to broadcast before rebooting.

          CLI Example:

             salt '*' system.shutdown
             salt '*' system.shutdown 60 "=== disk replacement ==="

   salt.modules.solaris_user
   Manage users with the useradd command

   IMPORTANT:
      If you feel that Salt should be using this module to manage users on
      a minion, and it is using a different  module  (or  gives  an  error
      similar to 'user.info' is not available), see here.

   salt.modules.solaris_user.add(name,  uid=None,  gid=None,  groups=None,
   home=None,   shell=None,   unique=True,   fullname='',   roomnumber='',
   workphone='', homephone='', createhome=True, **kwargs)
          Add a user to the minion

          CLI Example:

             salt '*' user.add name <uid> <gid> <groups> <home> <shell>

   salt.modules.solaris_user.chfullname(name, fullname)
          Change the user's Full Name

          CLI Example:

             salt '*' user.chfullname foo "Foo Bar"

   salt.modules.solaris_user.chgid(name, gid)
          Change the default group of the user

          CLI Example:

             salt '*' user.chgid foo 4376

   salt.modules.solaris_user.chgroups(name, groups, append=False)
          Change the groups to which a user belongs

          name   Username to modify

          groups List  of  groups  to set for the user. Can be passed as a
                 comma-separated list or a Python list.

          append False Set to True to append these groups  to  the  user's
                 existing  list of groups. Otherwise, the specified groups
                 will replace any existing groups for the user.

          CLI Example:

             salt '*' user.chgroups foo wheel,root True

   salt.modules.solaris_user.chhome(name, home, persist=False)
          Set a new home directory for an existing user

          name   Username to modify

          home   New home directory to set

          persist
                 False Set to True to prevent configuration files  in  the
                 new  home  directory  from being overwritten by the files
                 from the skeleton directory.

          CLI Example:

             salt '*' user.chhome foo /home/users/foo True

   salt.modules.solaris_user.chhomephone(name, homephone)
          Change the user's Home Phone

          CLI Example:

             salt '*' user.chhomephone foo "7735551234"

   salt.modules.solaris_user.chroomnumber(name, roomnumber)
          Change the user's Room Number

          CLI Example:

             salt '*' user.chroomnumber foo 123

   salt.modules.solaris_user.chshell(name, shell)
          Change the default shell of the user

          CLI Example:

             salt '*' user.chshell foo /bin/zsh

   salt.modules.solaris_user.chuid(name, uid)
          Change the uid for a named user

          CLI Example:

             salt '*' user.chuid foo 4376

   salt.modules.solaris_user.chworkphone(name, workphone)
          Change the user's Work Phone

          CLI Example:

             salt '*' user.chworkphone foo "7735550123"

   salt.modules.solaris_user.delete(name, remove=False, force=False)
          Remove a user from the minion

          CLI Example:

             salt '*' user.delete name remove=True force=True

   salt.modules.solaris_user.getent(refresh=False)
          Return the list of all info for all users

          CLI Example:

             salt '*' user.getent

   salt.modules.solaris_user.info(name)
          Return user information

          CLI Example:

             salt '*' user.info root

   salt.modules.solaris_user.list_groups(name)
          Return a list of groups the named user belongs to

          CLI Example:

             salt '*' user.list_groups foo

   salt.modules.solaris_user.list_users()
          Return a list of all users CLI Example:
             salt '*' user.list_users

   salt.modules.solaris_user.rename(name, new_name)
          Change the username for a named user

          CLI Example:

             salt '*' user.rename name new_name

   salt.modules.solarisips
   IPS pkg support for Solaris

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on  a  minion, and it is using a different module (or gives an error
      similar to 'pkg.install' is not available), see here.

   This module provides support for Solaris 11 new  package  management  -
   IPS  (Image  Packaging  System).   This  is  the default pkg module for
   Solaris 11 (and later).

   If you want to use also other packaging module (e.g. pkgutil)  together
   with  IPS,  you  need  to  override  the  pkg  provider in sls for each
   package:

      mypackage:
        pkg.installed:
          - provider: pkgutil

   Or you can override it globally by setting the providers  parameter  in
   your Minion config file like this:

      providers:
        pkg: pkgutil

   Or  you  can override it globally by setting the providers parameter in
   your Minion config file like this:

      providers:
        pkg: pkgutil

   salt.modules.solarisips.available_version(name, **kwargs)
          This function is an alias of latest_version.
             The available version of the package in the  repository.   In
             case  of  multiple  matches,  it  returns list of all matched
             packages.   Accepts  full  or  partial  FMRI.    Please   use
             pkg.latest_version    as   pkg.available_version   is   being
             deprecated.

             CLI Example:

                 salt '*' pkg.latest_version pkg://solaris/entire

   salt.modules.solarisips.get_fmri(name, **kwargs)
          Returns FMRI from partial name. Returns empty string ('') if not
          found.   In case of multiple match, the function returns list of
          all matched packages.

          CLI Example:

             salt '*' pkg.get_fmri bash

   salt.modules.solarisips.install(name=None,  refresh=False,   pkgs=None,
   version=None, test=False, **kwargs)
          Install  the  named  package using the IPS pkg command.  Accepts
          full or partial FMRI.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          Multiple Package Installation Options:

          pkgs   A list of packages to install. Must be passed as a python
                 list.

          CLI Example:

             salt '*' pkg.install vim
             salt '*' pkg.install pkg://solaris/editor/vim
             salt '*' pkg.install pkg://solaris/editor/vim refresh=True
             salt '*' pkg.install pkgs='["foo", "bar"]'

   salt.modules.solarisips.is_installed(name, **kwargs)
          Returns  True  if  the  package  is installed. Otherwise returns
          False.  Name can be full or partial FMRI.  In case  of  multiple
          match from partial FMRI name, it returns True.

          CLI Example:

             salt '*' pkg.is_installed bash

   salt.modules.solarisips.latest_version(name, **kwargs)
          The available version of the package in the repository.  In case
          of multiple matches, it returns list of  all  matched  packages.
          Accepts  full or partial FMRI.  Please use pkg.latest_version as
          pkg.available_version is being deprecated.

          CLI Example:

             salt '*' pkg.latest_version pkg://solaris/entire

   salt.modules.solarisips.list_pkgs(versions_as_list=False, **kwargs)
          List the currently installed packages as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.solarisips.list_upgrades(refresh=False, **kwargs)
          Lists all packages available for update.

          When run in global zone, it reports only upgradable packages for
          the global zone.

          When  run  in  non-global  zone,  it  can report more upgradable
          packages than pkg update -vn, because pkg update hides  packages
          that  require newer version of pkg://solaris/entire (which means
          that they can  be  upgraded  only  from  the  global  zone).  If
          pkg://solaris/entire  is found in the list of upgrades, then the
          global zone should be updated to get all possible  updates.  Use
          refresh=True to refresh the package database.

          refresh
                 False  Set  to True to force a full pkg DB refresh before
                 listing

          CLI Example:

             salt '*' pkg.list_upgrades
             salt '*' pkg.list_upgrades refresh=True

   salt.modules.solarisips.normalize_name(name, **kwargs)
          Internal function. Normalizes  pkg  name  to  full  FMRI  before
          running pkg.install. In case of multiple matches or no match, it
          returns the name without modifications.

          CLI Example:

             salt '*' pkg.normalize_name vim

   salt.modules.solarisips.purge(name, **kwargs)
          Remove specified package. Accepts full or partial FMRI.

          Returns a list containing the removed packages.

          CLI Example:

             salt '*' pkg.purge <package name>

   salt.modules.solarisips.refresh_db(full=False)
          Updates the remote repos database.

          full : False
             Set to True to force  a  refresh  of  the  pkg  DB  from  all
             publishers, regardless of the last refresh time.

          CLI Example:

             salt '*' pkg.refresh_db
             salt '*' pkg.refresh_db full=True

   salt.modules.solarisips.remove(name=None, pkgs=None, **kwargs)
          Remove specified package. Accepts full or partial FMRI.  In case
          of multiple match, the command fails and won't modify the OS.

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          Returns a list containing the removed packages.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove tcsh
             salt '*' pkg.remove pkg://solaris/shell/tcsh
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.solarisips.search(name, versions_as_list=False, **kwargs)
          Searches the repository for given pkg name.   The  name  can  be
          full  or  partial  FMRI. All matches are printed. Globs are also
          supported.

          CLI Example:

             salt '*' pkg.search bash

   salt.modules.solarisips.upgrade(refresh=False, **kwargs)
          Upgrade all packages to the latest possible version.   When  run
          in  global  zone,  it  updates  also  all  non-global zones.  In
          non-global zones upgrade is  limited  by  dependency  constrains
          linked to the version of pkg://solaris/entire.

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          When  there is a failure, an explanation is also included in the
          error message, based on  the  return  code  of  the  pkg  update
          command.

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.solarisips.upgrade_available(name)
          Check  if  there  is  an upgrade available for a certain package
          Accepts full or partial FMRI. Returns all matches found.

          CLI Example:

             salt '*' pkg.upgrade_available apache-22

   salt.modules.solarisips.version(*names, **kwargs)
          Common  interface  for  obtaining  the  version   of   installed
          packages.   Accepts  full  or  partial  FMRI.  If  called  using
          pkg_resource, full FMRI is required.

          CLI Example:

             salt '*' pkg.version vim
             salt '*' pkg.version foo bar baz
             salt '*' pkg_resource.version pkg://solaris/entire

   salt.modules.solarispkg
   Package support for Solaris

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on  a  minion, and it is using a different module (or gives an error
      similar to 'pkg.install' is not available), see here.

   salt.modules.solarispkg.install(name=None,                sources=None,
   saltenv='base', **kwargs)
          Install  the  passed  package.  Can  install  packages  from the
          following sources:

          * Locally (package already exists on the minion

          * HTTP/HTTPS server

          * FTP server

          * Salt master

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

          CLI Examples:

             # Installing a data stream pkg that already exists on the minion

             salt '*' pkg.install sources='[{"<pkg name>": "/dir/on/minion/<pkg filename>"}]'
             salt '*' pkg.install sources='[{"SMClgcc346": "/var/spool/pkg/gcc-3.4.6-sol10-sparc-local.pkg"}]'

             # Installing a data stream pkg that exists on the salt master

             salt '*' pkg.install sources='[{"<pkg name>": "salt://pkgs/<pkg filename>"}]'
             salt '*' pkg.install sources='[{"SMClgcc346": "salt://pkgs/gcc-3.4.6-sol10-sparc-local.pkg"}]'

          CLI Example:

             # Installing a data stream pkg that exists on a HTTP server
             salt '*' pkg.install sources='[{"<pkg name>": "http://packages.server.com/<pkg filename>"}]'
             salt '*' pkg.install sources='[{"SMClgcc346": "http://packages.server.com/gcc-3.4.6-sol10-sparc-local.pkg"}]'

          If working with solaris zones and you want to install a  package
          only in the global zone you can pass 'current_zone_only=True' to
          salt to have the package only  installed  in  the  global  zone.
          (Behind  the scenes this is passing '-G' to the pkgadd command.)
          Solaris default when installing a package in the global zone  is
          to install it in all zones. This overrides that and installs the
          package only in the global.

          CLI Example:

             # Installing a data stream package only in the global zone:
             salt 'global_zone' pkg.install sources='[{"SMClgcc346": "/var/spool/pkg/gcc-3.4.6-sol10-sparc-local.pkg"}]' current_zone_only=True

          By default salt automatically provides an adminfile, to automate
          package installation, with these options set:

             email=
             instance=quit
             partial=nocheck
             runlevel=nocheck
             idepend=nocheck
             rdepend=nocheck
             space=nocheck
             setuid=nocheck
             conflict=nocheck
             action=nocheck
             basedir=default

          You can override any of these options in two ways. First you can
          optionally  pass  any  of  the  options  as  a  kwarg   to   the
          module/state to override the default value or you can optionally
          pass the 'admin_source' option providing your own  adminfile  to
          the minions.

          Note: You can find all of the possible options to provide to the
          adminfile by reading the admin man page:

             man -s 4 admin

          CLI Example:

             # Overriding the 'instance' adminfile option when calling the module directly
             salt '*' pkg.install sources='[{"<pkg name>": "salt://pkgs/<pkg filename>"}]' instance="overwrite"

          SLS Example:

             # Overriding the 'instance' adminfile option when used in a state

             SMClgcc346:
               pkg.installed:
                 - sources:
                   - SMClgcc346: salt://srv/salt/pkgs/gcc-3.4.6-sol10-sparc-local.pkg
                 - instance: overwrite

          NOTE:
             The ID declaration is ignored, as the package  name  is  read
             from the sources parameter.

          CLI Example:

             # Providing your own adminfile when calling the module directly

             salt '*' pkg.install sources='[{"<pkg name>": "salt://pkgs/<pkg filename>"}]' admin_source='salt://pkgs/<adminfile filename>'

             # Providing your own adminfile when using states

             <pkg name>:
               pkg.installed:
                 - sources:
                   - <pkg name>: salt://pkgs/<pkg filename>
                 - admin_source: salt://pkgs/<adminfile filename>

          NOTE:
             The  ID  declaration  is ignored, as the package name is read
             from the sources parameter.

   salt.modules.solarispkg.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

          NOTE:  As  package  repositories are not presently supported for
          Solaris pkgadd, this function will always return an empty string
          for a given package.

   salt.modules.solarispkg.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.solarispkg.purge(name=None, pkgs=None, **kwargs)
          Package  purges are not supported, this function is identical to
          remove().

          name   The name of the package to be deleted

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.solarispkg.remove(name=None,  pkgs=None,   saltenv='base',
   **kwargs)
          Remove packages with pkgrm

          name   The name of the package to be deleted

          By default salt automatically provides an adminfile, to automate
          package removal, with these options set:

             email=
             instance=quit
             partial=nocheck
             runlevel=nocheck
             idepend=nocheck
             rdepend=nocheck
             space=nocheck
             setuid=nocheck
             conflict=nocheck
             action=nocheck
             basedir=default

          You can override any of these options in two ways. First you can
          optionally   pass   any  of  the  options  as  a  kwarg  to  the
          module/state to override the default value or you can optionally
          pass  the  'admin_source' option providing your own adminfile to
          the minions.

          Note: You can find all of the possible options to provide to the
          adminfile by reading the admin man page:

             man -s 4 admin

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove SUNWgit
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.solarispkg.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.solarispkg.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          string if not installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.solr
   Apache Solr Salt Module

   Author: Jed Glazner Version: 0.2.1 Modified: 12/09/2011

   This  module  uses  HTTP  requests  to  talk to the apache solr request
   handlers to gather information and report errors. Because of  this  the
   minion doesn't necessarily need to reside on the actual slave.  However
   if you want to use the signal function the minion must  reside  on  the
   physical solr host.

   This  module  supports multi-core and standard setups.  Certain methods
   are master/slave specific.  Make sure you set  the  solr.type.  If  you
   have questions or want a feature request please ask.

   Coming Features in 0.3
   1. Add command for checking for replication failures on slaves

   2. Improve  match_index_versions  since  it's  pointless  on  busy solr
      masters

   3. Add additional local  fs  checks  for  backups  to  make  sure  they
      succeeded

   Override these in the minion config
   solr.cores
          A  list  of  core  names  e.g. ['core1','core2'].  An empty list
          indicates non-multicore setup.

   solr.baseurl
          The root level URL to access solr via HTTP

   solr.request_timeout
          The number  of  seconds  before  timing  out  an  HTTP/HTTPS/FTP
          request.  If nothing is specified then the python global timeout
          setting is used.

   solr.type
          Possible values are 'master' or 'slave'

   solr.backup_path
          The path to store your backups. If you are using cores  and  you
          can  specify  to  append the core name to the path in the backup
          method.

   solr.num_backups
          For versions of solr >= 3.5. Indicates the number of backups  to
          keep. This option is ignored if your version is less.

   solr.init_script
          The full path to your init script with start/stop options

   solr.dih.options
          A list of options to pass to the DIH.

   Required Options for DIH
   clean  False Clear the index before importing

   commit True Commit the documents to the index upon completion

   optimize
          True Optimize the index after commit is complete

   verbose
          True Get verbose output

   salt.modules.solr.abort_import(handler,    host=None,   core_name=None,
   verbose=False)
          MASTER ONLY Aborts an existing import command to  the  specified
          handler.   This  command  can  only  be  run  if  the  minion is
          configured with solr.type=master

          handler
                 str The name of the data import handler.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core   str (None) The core the handler belongs to.

          verbose
                 boolean (False) Run the command with verbose output.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.abort_import dataimport None music {'clean':True}

   salt.modules.solr.backup(host=None,                     core_name=None,
   append_core_to_path=False)
          Tell solr make a backup.  This method can be  mis-leading  since
          it  uses  the backup API.  If an error happens during the backup
          you are not notified.  The status: 'OK' in the  response  simply
          means that solr received the request successfully.

          host   str  (None)  The  solr host to query. __opts__['host'] is
                 default.

          core_name
                 str (None) The name of the  solr  core  if  using  cores.
                 Leave  this  blank  if  you are not using cores or if you
                 want to check all cores.

          append_core_to_path
                 boolean (False) If True add the name of the core  to  the
                 backup path. Assumes that minion backup path is not None.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.backup music

   salt.modules.solr.core_status(host=None, core_name=None)
          MULTI-CORE  HOSTS  ONLY  Get  the status for a given core or all
          cores if no core is specified

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core_name
                 str The name of the core to reload

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.core_status None music

   salt.modules.solr.delta_import(handler,    host=None,   core_name=None,
   options=None, extra=None)
          Submits  an  import  command  to  the  specified  handler  using
          specified  options.   This command can only be run if the minion
          is configured with solr.type=master

          handler
                 str The name of the data import handler.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core   str (None) The core the handler belongs to.

          options
                 dict (__opts__) A list of options such as clean, optimize
                 commit, verbose, and pause_replication.  leave  blank  to
                 use  __opts__  defaults.  options  will  be  merged  with
                 __opts__

          extra  dict ([]) Extra name value pairs to pass to the  handler.
                 e.g. ["name=value"]

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.delta_import dataimport None music {'clean':True}

   salt.modules.solr.full_import(handler,    host=None,    core_name=None,
   options=None, extra=None)
          MASTER ONLY Submits an import command to the  specified  handler
          using  specified  options.   This command can only be run if the
          minion is configured with solr.type=master

          handler
                 str The name of the data import handler.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core   str (None) The core the handler belongs to.

          options
                 dict (__opts__) A list of options such as clean, optimize
                 commit, verbose, and pause_replication.  leave  blank  to
                 use  __opts__  defaults.  options  will  be  merged  with
                 __opts__

          extra  dict ([]) Extra name value pairs to pass to the  handler.
                 e.g. ["name=value"]

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.full_import dataimport None music {'clean':True}

   salt.modules.solr.import_status(handler,   host=None,   core_name=None,
   verbose=False)
          Submits  an  import  command  to  the  specified  handler  using
          specified  options.   This command can only be run if the minion
          is configured with solr.type: 'master'

          handler
                 str The name of the data import handler.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core   str (None) The core the handler belongs to.

          verbose
                 boolean (False) Specifies verbose output

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.import_status dataimport None music False

   salt.modules.solr.is_replication_enabled(host=None, core_name=None)
          SLAVE  CALL  Check  for  errors,  and  determine  if  a slave is
          replicating or not.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core_name
                 str  (None)  The  name  of  the solr core if using cores.
                 Leave this blank if you are not using  cores  or  if  you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.is_replication_enabled music

   salt.modules.solr.lucene_version(core_name=None)
          Gets the lucene version that solr is using. If you are running a
          multi-core setup you should specify a core name  since  all  the
          cores  run  under the same servlet container, they will all have
          the same version.

          core_name
                 str (None) The name of the  solr  core  if  using  cores.
                 Leave  this  blank  if  you are not using cores or if you
                 want to check all cores.

          Return: dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.lucene_version

   salt.modules.solr.match_index_versions(host=None, core_name=None)
          SLAVE CALL Verifies that the master and the slave  versions  are
          in  sync  by  comparing the index version. If you are constantly
          pushing updates the index the master  and  slave  versions  will
          seldom  match.  A  solution  to  this is pause indexing every so
          often to allow the slave to replicate and then call this  method
          before allowing indexing to resume.

          host   str  (None)  The  solr host to query. __opts__['host'] is
                 default.

          core_name
                 str (None) The name of the  solr  core  if  using  cores.
                 Leave  this  blank  if  you are not using cores or if you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.match_index_versions music

   salt.modules.solr.optimize(host=None, core_name=None)
          Search queries fast, but it is a very expensive  operation.  The
          ideal  process is to run this with a master/slave configuration.
          Then you can optimize the master, and push the  optimized  index
          to the slaves.  If you are running a single solr instance, or if
          you are going to run this  on  a  slave  be  aware  than  search
          performance  will  be  horrible while this command is being run.
          Additionally it can take a  LONG  time  to  run  and  your  HTTP
          request  may  timeout.  If  that  happens  adjust  your  timeout
          settings.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core_name
                 str  (None)  The  name  of  the solr core if using cores.
                 Leave this blank if you are not using  cores  or  if  you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.optimize music

   salt.modules.solr.ping(host=None, core_name=None)
          Does  a  health  check  on solr, makes sure solr can talk to the
          indexes.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core_name
                 str  (None)  The  name  of  the solr core if using cores.
                 Leave this blank if you are not using  cores  or  if  you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.ping music

   salt.modules.solr.reload_core(host=None, core_name=None)
          MULTI-CORE   HOSTS   ONLY   Load   a  new  core  from  the  same
          configuration as an existing registered core.  While  the  "new"
          core  is  initializing,  the  "old"  one will continue to accept
          requests. Once it has finished, all new request will go  to  the
          "new" core, and the "old" core will be unloaded.

          host   str  (None)  The  solr host to query. __opts__['host'] is
                 default.

          core_name
                 str The name of the core to reload

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.reload_core None music

          Return data is in the following format:

             {'success':bool, 'data':dict, 'errors':list, 'warnings':list}

   salt.modules.solr.reload_import_config(handler,              host=None,
   core_name=None, verbose=False)
          MASTER  ONLY re-loads the handler config XML file.  This command
          can only be run if the minion is a 'master' type

          handler
                 str The name of the data import handler.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core   str (None) The core the handler belongs to.

          verbose
                 boolean (False) Run the command with verbose output.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.reload_import_config dataimport None music {'clean':True}

   salt.modules.solr.replication_details(host=None, core_name=None)
          Get the full replication details.

          host   str  (None)  The  solr host to query. __opts__['host'] is
                 default.

          core_name
                 str (None) The name of the  solr  core  if  using  cores.
                 Leave  this  blank  if  you are not using cores or if you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.replication_details music

   salt.modules.solr.set_is_polling(polling, host=None, core_name=None)
          SLAVE CALL Prevent  the  slaves  from  polling  the  master  for
          updates.

          polling
                 boolean True will enable polling. False will disable it.

          host   str  (None)  The  solr host to query. __opts__['host'] is
                 default.

          core_name
                 str (None) The name of the  solr  core  if  using  cores.
                 Leave  this  blank  if  you are not using cores or if you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.set_is_polling False

   salt.modules.solr.set_replication_enabled(status,            host=None,
   core_name=None)
          MASTER  ONLY  Sets  the  master to ignore poll requests from the
          slaves. Useful when you don't want the slaves replicating during
          indexing or when clearing the index.

          status boolean  Sets  the  replication  status  to the specified
                 state.

          host   str (None) The solr host to  query.  __opts__['host']  is
                 default.

          core_name
                 str  (None)  The  name  of  the solr core if using cores.
                 Leave this blank if you are not using  cores  or  if  you
                 want to set the status on all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.set_replication_enabled false, None, music

   salt.modules.solr.signal(signal=None)
          Signals  Apache  Solr to start, stop, or restart. Obviously this
          is only going to work if the minion resides on  the  solr  host.
          Additionally  Solr  doesn't ship with an init script so one must
          be created.

          signal str (None) The command to pass to the  apache  solr  init
                 valid values are 'start', 'stop', and 'restart'

          CLI Example:

             salt '*' solr.signal restart

   salt.modules.solr.version(core_name=None)
          Gets  the  solr  version  for  the  core  specified.  You should
          specify a core here as all the cores will  run  under  the  same
          servlet container and so will all have the same version.

          core_name
                 str  (None)  The  name  of  the solr core if using cores.
                 Leave this blank if you are not using  cores  or  if  you
                 want to check all cores.

          Return : dict<str,obj>:

             {'success':boolean, 'data':dict, 'errors':list, 'warnings':list}

          CLI Example:

             salt '*' solr.version

   salt.modules.splunk
   Module for interop with the Splunk API

   New in version 2016.3.0..

   depends

          * splunk-sdk python module

   configuration
          Configure  this module by specifying the name of a configuration
          profile in the minion config, minion pillar, or  master  config.
          The module will use the 'splunk' key by default, if defined.

          For example:

             splunk:
                 username: alice
                 password: abc123
                 host: example.splunkcloud.com
                 port: 8080

   salt.modules.splunk.create_user(email, profile='splunk', **kwargs)
          create a splunk user by name/email

          CLI Example:
             salt     myminion     splunk.create_user     [email protected]
             roles=['user'] realname="Test User" name=testuser

   salt.modules.splunk.delete_user(email, profile='splunk')
          Delete a splunk user by email

          CLI Example:
             salt myminion splunk_user.delete '[email protected]'

   salt.modules.splunk.get_user(email, profile='splunk', **kwargs)
          Get a splunk user by name/email

          CLI Example:
             salt     myminion     splunk.get_user      '[email protected]'
             user_details=false      salt     myminion     splunk.get_user
             '[email protected]' user_details=true

   salt.modules.splunk.list_users(profile='splunk')
          List all users in the splunk DB

          CLI Example:
             salt myminion splunk.list_users

   salt.modules.splunk.update_user(email, profile='splunk', **kwargs)
          Create a splunk user by email

          CLI Example:
             salt    myminion    splunk.update_user     [email protected]
             roles=['user'] realname="Test User"

   salt.modules.splunk_search
   Module for interop with the Splunk API

   New in version 2015.5.0.

   depends

          * splunk-sdk python module

   configuration
          Configure  this module by specifying the name of a configuration
          profile in the minion config, minion pillar, or  master  config.
          The module will use the 'splunk' key by default, if defined.

          For example:

             splunk:
                 username: alice
                 password: abc123
                 host: example.splunkcloud.com
                 port: 8080

   salt.modules.splunk_search.create(name, profile='splunk', **kwargs)
          Create a splunk search

          CLI Example:
             splunk_search.create 'my search name' search='error msg'

   salt.modules.splunk_search.delete(name, profile='splunk')
          Delete a splunk search

          CLI Example:
             splunk_search.delete 'my search name'

   salt.modules.splunk_search.get(name, profile='splunk')
          Get a splunk search

          CLI Example:
             splunk_search.get 'my search name'

   salt.modules.splunk_search.list(profile='splunk')
          List splunk searches (names only)

          CLI Example:
                 splunk_search.list

   salt.modules.splunk_search.list_all(prefix=None,  app=None, owner=None,
   description_contains=None, name_not_contains=None, profile='splunk')
          Get all splunk search details. Produces results that can be used
          to create an sls file.

          if  app  or  owner  are  specified,  results  will be limited to
          matching saved searches.

          if description_contains is specified, results will be limited to
          those  where  "description_contains  in  description" is true if
          name_not_contains is specified, results will be limited to those
          where "name_not_contains not in name" is true.

          If  prefix parameter is given, alarm names in the output will be
          prepended with the prefix; alarms that have the prefix  will  be
          skipped.  This  can  be  used  to  convert existing alarms to be
          managed by salt, as follows:

          CLI example:

             1.

                Make a backup of all existing searches
                       $ salt-call splunk_search.list_all --out=txt |  sed
                       "s/local: //" > legacy_searches.sls

             2.

                Get all searches with new prefixed names
                       $          salt-call         splunk_search.list_all
                       "prefix=**MANAGED  BY  SALT**  "  --out=txt  |  sed
                       "s/local: //" > managed_searches.sls

             3.

                Insert the managed searches into splunk
                       $ salt-call state.sls managed_searches.sls

             4. Manually verify that the new searches look right

             5. Delete  the  original  searches  $  sed  s/present/absent/
                legacy_searches.sls   >    remove_legacy_searches.sls    $
                salt-call state.sls remove_legacy_searches.sls

             6. Get  all  searches  again,  verify  no changes $ salt-call
                splunk_search.list_all --out=txt |  sed  "s/local:  //"  >
                final_searches.sls      $      diff     final_searches.sls
                managed_searches.sls

   salt.modules.splunk_search.update(name, profile='splunk', **kwargs)
          Update a splunk search

          CLI Example:
             splunk_search.update 'my search name' sharing=app

   salt.modules.sqlite3
   Support for SQLite3

   salt.modules.sqlite3.fetch(db=None, sql=None)
          Retrieve data from an sqlite3 db (returns all rows, be careful!)

          CLI Example:

             salt '*' sqlite3.fetch /root/test.db 'SELECT * FROM test;'

   salt.modules.sqlite3.indexes(db=None)
          Show all indices in the database, for people with poor  spelling
          skills

          CLI Example:

             salt '*' sqlite3.indexes /root/test.db

   salt.modules.sqlite3.indices(db=None)
          Show all indices in the database

          CLI Example:

             salt '*' sqlite3.indices /root/test.db

   salt.modules.sqlite3.modify(db=None, sql=None)
          Issue  an  SQL  query  to sqlite3 (with no return data), usually
          used to modify the database in some way (insert, delete, create,
          etc)

          CLI Example:

             salt '*' sqlite3.modify /root/test.db 'CREATE TABLE test(id INT, testdata TEXT);'

   salt.modules.sqlite3.sqlite_version()
          Return version of sqlite

          CLI Example:

             salt '*' sqlite3.sqlite_version

   salt.modules.sqlite3.tables(db=None)
          Show all tables in the database

          CLI Example:

             salt '*' sqlite3.tables /root/test.db

   salt.modules.sqlite3.version()
          Return version of pysqlite

          CLI Example:

             salt '*' sqlite3.version

   salt.modules.ssh
   Manage client ssh components

   NOTE:
      This module requires the use of MD5 hashing. Certain security audits
      may not permit the use of MD5. For those cases, this  module  should
      be disabled or removed.

   salt.modules.ssh.auth_keys(user=None, config='.ssh/authorized_keys')
          Return the authorized keys for users

          CLI Example:

             salt '*' ssh.auth_keys
             salt '*' ssh.auth_keys root
             salt '*' ssh.auth_keys user=root
             salt '*' ssh.auth_keys user="[user1, user2]"

   salt.modules.ssh.check_key(user,    key,    enc,    comment,   options,
   config='.ssh/authorized_keys', cache_keys=None)
          Check to see if a key needs updating, returns "update", "add" or
          "exists"

          CLI Example:

             salt '*' ssh.check_key <user> <key> <enc> <comment> <options>

   salt.modules.ssh.check_key_file(user,                           source,
   config='.ssh/authorized_keys', saltenv='base')
          Check a keyfile from a source destination against the local keys
          and return the keys to change

          CLI Example:

             salt '*' ssh.check_key_file root salt://ssh/keyfile

   salt.modules.ssh.check_known_host(user=None,  hostname=None,  key=None,
   fingerprint=None, config=None, port=None)
          Check the record in known_hosts file, either by its value or  by
          fingerprint  (it's  enough  to set up either key or fingerprint,
          you don't need to set up both).

          If provided key or fingerprint doesn't match with stored  value,
          return  "update",  if no value is found for a given host, return
          "add", otherwise return "exists".

          If neither key, nor  fingerprint  is  defined,  then  additional
          validation is not performed.

          CLI Example:

             salt '*' ssh.check_known_host <user> <hostname> key='AAAA...FAaQ=='

   salt.modules.ssh.get_known_host(user, hostname, config=None, port=None)
          Return information about known host from the configfile, if any.
          If there is no such key, return None.

          CLI Example:

             salt '*' ssh.get_known_host <user> <hostname>

   salt.modules.ssh.hash_known_hosts(user=None, config=None)
          Hash all the hostnames in the known hosts file.

          New in version 2014.7.0.

          user   hash known hosts of this user

          config path to known hosts file: can be absolute or relative  to
                 user's home directory

          CLI Example:

             salt '*' ssh.hash_known_hosts

   salt.modules.ssh.host_keys(keydir=None, private=True)
          Return the minion's host keys

          CLI Example:

             salt '*' ssh.host_keys
             salt '*' ssh.host_keys keydir=/etc/ssh
             salt '*' ssh.host_keys keydir=/etc/ssh private=False

   salt.modules.ssh.key_is_encrypted(key)
          New in version 2015.8.7.

          Function  to determine whether or not a private key is encrypted
          with a passphrase.

          Checks key for a Proc-Type header with ENCRYPTED in  the  value.
          If found, returns True, otherwise returns False.

          CLI Example:

             salt '*' ssh.key_is_encrypted /root/id_rsa

   salt.modules.ssh.recv_known_host(hostname,     enc=None,     port=None,
   hash_known_hosts=True, timeout=5)
          Retrieve information about host public key from remote server

          hostname
                 The name of the remote host (e.g. "github.com")

          enc    Defines what type of key is being used, can  be  ed25519,
                 ecdsa ssh-rsa or ssh-dss

          port   optional parameter, denoting the port of the remote host,
                 which will be used in case, if the  public  key  will  be
                 requested from it. By default the port 22 is used.

          hash_known_hosts
                 True  Hash all hostnames and addresses in the known hosts
                 file.

          timeout
                 int Set the timeout for connection attempts.  If  timeout
                 seconds  have elapsed since a connection was initiated to
                 a host or since the last time anything was read from that
                 host,  then  the  connection  is  closed  and the host in
                 question considered unavailable.  Default is 5 seconds.

                 New in version 2016.3.0.

          CLI Example:

             salt '*' ssh.recv_known_host <hostname> enc=<enc> port=<port>

   salt.modules.ssh.rm_auth_key(user, key, config='.ssh/authorized_keys')
          Remove an authorized key from the  specified  user's  authorized
          key file

          CLI Example:

             salt '*' ssh.rm_auth_key <user> <key>

   salt.modules.ssh.rm_auth_key_from_file(user,                    source,
   config='.ssh/authorized_keys', saltenv='base')
          Remove an authorized key from the  specified  user's  authorized
          key file, using a file as source

          CLI Example:

             salt '*' ssh.rm_auth_key_from_file <user> salt://ssh_keys/<user>.id_rsa.pub

   salt.modules.ssh.rm_known_host(user=None,  hostname=None,  config=None,
   port=None)
          Remove all keys belonging to hostname from a known_hosts file.

          CLI Example:

             salt '*' ssh.rm_known_host <user> <hostname>

   salt.modules.ssh.set_auth_key(user,  key,  enc='ssh-rsa',   comment='',
   options=None, config='.ssh/authorized_keys', cache_keys=None)
          Add  a key to the authorized_keys file. The "key" parameter must
          only be the string of text that is the encoded key. If  the  key
          begins  with "ssh-rsa" or ends with user@host, remove those from
          the key before passing it to this function.

          CLI Example:

             salt '*' ssh.set_auth_key <user> '<key>' enc='dsa'

   salt.modules.ssh.set_auth_key_from_file(user,                   source,
   config='.ssh/authorized_keys', saltenv='base')
          Add  a  key  to  the  authorized_keys  file, using a file as the
          source.

          CLI Example:

             salt '*' ssh.set_auth_key_from_file <user> salt://ssh_keys/<user>.id_rsa.pub

   salt.modules.ssh.set_known_host(user=None,               hostname=None,
   fingerprint=None,    key=None,    port=None,   enc=None,   config=None,
   hash_known_hosts=True, timeout=5)
          Download SSH public key from remote host "hostname",  optionally
          validate its fingerprint against "fingerprint" variable and save
          the record in the known_hosts file.

          If such a record does already exists in there, do nothing.

          user   The user who owns the ssh authorized keys file to modify

          hostname
                 The name of the remote host (e.g. "github.com")

          fingerprint
                 The fingerprint of the key which must be presented in the
                 known_hosts file (optional if key specified)

          key    The public key which must be presented in the known_hosts
                 file (optional if fingerprint specified)

          port   optional parameter, denoting the port of the remote host,
                 which  will  be  used  in case, if the public key will be
                 requested from it. By default the port 22 is used.

          enc    Defines what type of key is being used, can  be  ed25519,
                 ecdsa ssh-rsa or ssh-dss

          config The  location of the authorized keys file relative to the
                 user's home directory, defaults to ".ssh/known_hosts". If
                 no      user      is      specified,      defaults     to
                 "/etc/ssh/ssh_known_hosts".  If  present,  must   be   an
                 absolute path when a user is not specified.

          hash_known_hosts
                 True  Hash all hostnames and addresses in the known hosts
                 file.

          timeout
                 int Set the timeout for connection attempts.  If  timeout
                 seconds  have elapsed since a connection was initiated to
                 a host or since the last time anything was read from that
                 host,  then  the  connection  is  closed  and the host in
                 question considered unavailable.  Default is 5 seconds.

                 New in version 2016.3.0.

          CLI Example:

             salt '*' ssh.set_known_host <user> fingerprint='xx:xx:..:xx' enc='ssh-rsa' config='.ssh/known_hosts'

   salt.modules.ssh.user_keys(user=None, pubfile=None, prvfile=None)
          Return the user's ssh keys on the minion

          New in version 2014.7.0.

          CLI Example:

             salt '*' ssh.user_keys
             salt '*' ssh.user_keys user=user1
             salt '*' ssh.user_keys user=user1 pubfile=/home/user1/.ssh/id_rsa.pub prvfile=/home/user1/.ssh/id_rsa
             salt '*' ssh.user_keys user=user1 prvfile=False
             salt '*' ssh.user_keys user="['user1','user2'] pubfile=id_rsa.pub prvfile=id_rsa

          As you can see you can tell Salt not to  read  from  the  user's
          private  (or public) key file by setting the file path to False.
          This can be useful to prevent Salt from publishing private  data
          via Salt Mine or others.

   salt.modules.ssh_package module
   Service support for the REST example

   salt.modules.ssh_service module
   Provide the service module for the proxy-minion SSH sample

   salt.modules.ssh_service.enabled(name, sig=None)
          Only the 'redbull' service is 'enabled' in the test

   salt.modules.ssh_service.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' service.get_all

   salt.modules.ssh_service.list()
          Return a list of all available services.

          CLI Example:

             salt '*' service.list

   salt.modules.ssh_service.restart(name, sig=None)
          Restart the specified service with rest_sample CLI Example:

             salt '*' service.restart <service name>

   salt.modules.ssh_service.running(name, sig=None)
          Return whether this service is running.

   salt.modules.ssh_service.start(name, sig=None)
          Start the specified service on the rest_sample

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.ssh_service.status(name, sig=None)
          Return  the status for a service via rest_sample, returns a bool
          whether the service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.ssh_service.stop(name, sig=None)
          Stop the specified service on the rest_sample

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.state
   Control the state system on the minion.

   State Caching
   When a highstate is called, the minion automatically caches a  copy  of
   the last high data. If you then run a highstate with cache=True it will
   use that cached highdata  and  won't  hit  the  fileserver  except  for
   salt:// links in the states themselves.

   salt.modules.state.apply(mods=None, **kwargs)
          New in version 2015.5.0.

          This  function  will  call state.highstate or state.sls based on
          the arguments passed to this function.   It  exists  as  a  more
          intuitive way of applying states.

          APPLYING ALL STATES CONFIGURED IN TOP.SLS (A.K.A. HIGHSTATE)

          To apply all configured states, simply run state.apply:

             salt '*' state.apply

          The  following  additional  arguments  are  also  accepted  when
          applying all states configured in top.sls:

          test   Run states in test-only (dry-run) mode

          pillar Custom Pillar values, passed as a dictionary of key-value
                 pairs

                    salt '*' state.apply test pillar='{"foo": "bar"}'

                 NOTE:
                    Values passed this way will override Pillar values set
                    via pillar_roots or an external Pillar source.

          queue  False Instead of failing immediately when  another  state
                 run  is  in  progress,  queue  the new state run to begin
                 running once the other has finished.

                 This option starts a new thread  for  each  queued  state
                 run, so use this option sparingly.

          localconfig
                 Optionally,  instead  of  using  the  minion config, load
                 minion opts from the file specified by this argument, and
                 then  merge them with the options from the minion config.
                 This functionality allows for specific states to  be  run
                 with  their  own  custom  minion configuration, including
                 different pillars, file_roots, etc.

                    salt '*' state.apply localconfig=/path/to/minion.yml

          APPLYING INDIVIDUAL SLS FILES (A.K.A. STATE.SLS)

          To apply individual SLS files, pass them  as  a  comma-separated
          list:

             # Run the states configured in salt://test.sls (or salt://test/init.sls)
             salt '*' state.apply test
             # Run the states configured in salt://test.sls (or salt://test/init.sls)
             # and salt://pkgs.sls (or salt://pkgs/init.sls).
             salt '*' state.apply test,pkgs

          The  following  additional  arguments  are  also  accepted  when
          applying individual SLS files:

          test   Run states in test-only (dry-run) mode

          pillar Custom Pillar values, passed as a dictionary of key-value
                 pairs

                    salt '*' state.apply test pillar='{"foo": "bar"}'

                 NOTE:
                    Values passed this way will override Pillar values set
                    via pillar_roots or an external Pillar source.

          queue  False Instead of failing immediately when  another  state
                 run  is  in  progress,  queue  the new state run to begin
                 running once the other has finished.

                 This option starts a new thread  for  each  queued  state
                 run, so use this option sparingly.

          concurrent
                 False Execute state runs concurrently instead of serially

                 WARNING:
                    This flag is potentially dangerous. It is designed for
                    use when multiple state runs can safely be run at  the
                    same  time.  Do  not  use  this  flag  for performance
                    optimization.

          saltenv
                 None Specify a salt fileserver  environment  to  be  used
                 when applying states

                 Changed in version 0.17.0: Argument name changed from env
                 to saltenv

                 Changed in version 2014.7.0: If no saltenv is  specified,
                 the minion config will be checked for a saltenv parameter
                 and if found, it will be used. If  none  is  found,  base
                 will  be  used.  In prior releases, the minion config was
                 not checked and base would always  be  assumed  when  the
                 saltenv was not explicitly set.

          pillarenv
                 Specify  a  Pillar  environment  to be used when applying
                 states. By  default,  all  Pillar  environments  will  be
                 merged together and used.

          localconfig
                 Optionally,  instead  of  using  the  minion config, load
                 minion opts from the file specified by this argument, and
                 then  merge them with the options from the minion config.
                 This functionality allows for specific states to  be  run
                 with  their  own  custom  minion configuration, including
                 different pillars, file_roots, etc.

                    salt '*' state.apply test localconfig=/path/to/minion.yml

   salt.modules.state.check_request(name=None)
          New in version 2015.5.0.

          Return the state request information, if any

          CLI Example:

             salt '*' state.check_request

   salt.modules.state.clear_cache()
          Clear out cached state files, forcing even cache runs to refresh
          the cache on the next state execution.

          Remember that the state cache is completely disabled by default,
          this execution only applies if cache=True is used in states

          CLI Example:

             salt '*' state.clear_cache

   salt.modules.state.clear_request(name=None)
          New in version 2015.5.0.

          Clear out the state execution request without executing it

          CLI Example:

             salt '*' state.clear_request

   salt.modules.state.disable(states)
          Disable state runs.

          CLI Example:

             salt '*' state.disable highstate

             salt '*' state.disable highstate,test.succeed_without_changes

          NOTE:
             To disable a state file from running provide  the  same  name
             that would be passed in a state.sls call.

             salt '*' state.disable bind.config

   salt.modules.state.enable(states)
          Enable state function or sls run

          CLI Example:

             salt '*' state.enable highstate

             salt '*' state.enable test.succeed_without_changes

          NOTE:
             To  enable  a  state  file from running provide the same name
             that would be passed in a state.sls call.

             salt '*' state.disable bind.config

   salt.modules.state.event(tagmatch='*',      count=-1,      quiet=False,
   sock_dir=None, pretty=False, node='minion')
          Watch Salt's event bus and block until the given tag is matched

          New in version 2016.3.0.

          This is useful for utilizing Salt's event bus from shell scripts
          or for taking simple actions directly from the CLI.

          Enable debug logging to see ignored events.

          Parameters

                 * tagmatch -- the event is written to stdout for each tag
                   that  matches  this  pattern;  uses  the  same matching
                   semantics as Salt's Reactor.

                 * count -- this number is decremented for each event that
                   matches  the  tagmatch  parameter;  pass  -1  to listen
                   forever.

                 * quiet -- do not print to stdout; just block

                 * sock_dir -- path to  the  Salt  master's  event  socket
                   file.

                 * pretty -- Output the JSON all on a single line if False
                   (useful for shell tools); pretty-print the JSON  output
                   if True.

                 * node -- Watch the minion-side or master-side event bus.

          CLI Example:

             salt-call --local state.event pretty=True

   salt.modules.state.high(data, test=None, queue=False, **kwargs)
          Execute the compound calls stored in a single set of high data

          This  function  is  mostly intended for testing the state system
          and is not likely to be needed in everyday usage.

          CLI Example:

             salt '*' state.high '{"vim": {"pkg": ["installed"]}}'

   salt.modules.state.highstate(test=None, queue=False, **kwargs)
          Retrieve the state data from the salt master for this minion and
          execute it

          test   Run states in test-only (dry-run) mode

          pillar Custom Pillar values, passed as a dictionary of key-value
                 pairs

                    salt '*' state.apply test pillar='{"foo": "bar"}'

                 NOTE:
                    Values passed this way will override Pillar values set
                    via pillar_roots or an external Pillar source.

                 Changed  in  version  2016.3.0:  GPG-encrypted CLI Pillar
                 data is now supported via the GPG renderer. See here  for
                 details.

          pillar_enc
                 Specify  which  renderer to use to decrypt encrypted data
                 located within the pillar value. Currently, only  gpg  is
                 supported.

                 New in version 2016.3.0.

          queue  False  Instead  of failing immediately when another state
                 run is in progress, queue the  new  state  run  to  begin
                 running once the other has finished.

                 This  option  starts  a  new thread for each queued state
                 run, so use this option sparingly.

          localconfig
                 Optionally, instead of  using  the  minion  config,  load
                 minion opts from the file specified by this argument, and
                 then merge them with the options from the minion  config.
                 This  functionality  allows for specific states to be run
                 with their own  custom  minion  configuration,  including
                 different pillars, file_roots, etc.

          mock:  The  mock  option  allows  for  the  state run to execute
                 without actually calling any states. This then returns  a
                 mocked  return  which will show the requisite ordering as
                 well as fully validate the state run.

                 New in version 2015.8.4.

          CLI Examples:

             salt '*' state.highstate

             salt '*' state.highstate whitelist=sls1_to_run,sls2_to_run
             salt '*' state.highstate exclude=sls_to_exclude
             salt '*' state.highstate exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"

             salt '*' state.highstate pillar="{foo: 'Foo!', bar: 'Bar!'}"

   salt.modules.state.list_disabled()
          List the states which are currently disabled

          CLI Example:

             salt '*' state.list_disabled

   salt.modules.state.low(data, queue=False, **kwargs)
          Execute a single low data call

          This function is mostly intended for testing  the  state  system
          and is not likely to be needed in everyday usage.

          CLI Example:

             salt '*' state.low '{"state": "pkg", "fun": "installed", "name": "vi"}'

   salt.modules.state.orchestrate(mods,     saltenv='base',     test=None,
   exclude=None, pillar=None, pillarenv=None)
          New in version 2016.11.0.

          Execute the orchestrate runner from a masterless minion.

          SEE ALSO:
             More Orchestrate documentation

             * Full Orchestrate Tutorial

             * Docs for the ``salt` state module <salt.states.saltmod>`

          CLI Examples:

             salt-call --local state.orchestrate webserver
             salt-call --local state.orchestrate webserver saltenv=dev test=True
             salt-call --local state.orchestrate webserver saltenv=dev pillarenv=aws

   salt.modules.state.pkg(pkg_path,   pkg_sum,    hash_type,    test=None,
   **kwargs)
          Execute  a packaged state run, the packaged state run will exist
          in a tarball available  locally.  This  packaged  state  can  be
          generated using salt-ssh.

          CLI Example:

             salt '*' state.pkg /tmp/salt_state.tgz 760a9353810e36f6d81416366fc426dc md5

   salt.modules.state.request(mods=None, **kwargs)
          New in version 2015.5.0.

          Request  that  the local admin execute a state run via salt-call
          state.run_request All arguments match state.apply

          CLI Example:

             salt '*' state.request
             salt '*' state.request test
             salt '*' state.request test,pkgs

   salt.modules.state.run_request(name='default', **kwargs)
          New in version 2015.5.0.

          Execute the pending state request

          CLI Example:

             salt '*' state.run_request

   salt.modules.state.running(concurrent=False)
          Return a list of strings that contain state  return  data  if  a
          state  function  is  already  running.  This function is used to
          prevent multiple state calls from being run at the same time.

          CLI Example:

             salt '*' state.running

   salt.modules.state.show_highstate(queue=False, **kwargs)
          Retrieve the highstate data from the salt master and display it

          Custom Pillar data can be passed with the pillar kwarg.

          CLI Example:

             salt '*' state.show_highstate

   salt.modules.state.show_low_sls(mods,    saltenv='base',     test=None,
   queue=False, **kwargs)
          Display   the   low  data  from  a  specific  sls.  The  default
          environment  is  base,  use  saltenv  to  specify  a   different
          environment.

          CLI Example:

             salt '*' state.show_low_sls foo

   salt.modules.state.show_lowstate(queue=False, **kwargs)
          List out the low data that will be applied to this minion

          CLI Example:

             salt '*' state.show_lowstate

   salt.modules.state.show_sls(mods,       saltenv='base',      test=None,
   queue=False, **kwargs)
          Display the state data from a specific sls or list of sls  files
          on  the  master. The default environment is base, use saltenv to
          specify a different environment.

          This function does not support topfiles.  For top.sls please use
          show_top instead.

          Custom Pillar data can be passed with the pillar kwarg.

          CLI Example:

             salt '*' state.show_sls core,edit.vim dev

   salt.modules.state.show_top(queue=False, **kwargs)
          Return the top data that the minion will use for a highstate

          CLI Example:

             salt '*' state.show_top

   salt.modules.state.single(fun, name, test=None, queue=False, **kwargs)
          Execute  a  single state function with the named kwargs, returns
          False if insufficient data is sent to the command

          By default, the values of the kwargs will be parsed as YAML. So,
          you can specify lists values, or lists of single entry key-value
          maps, as you would in a  YAML  salt  file.  Alternatively,  JSON
          format of keyword values is also supported.

          CLI Example:

             salt '*' state.single pkg.installed name=vim

   salt.modules.state.sls(mods,   saltenv=None,  test=None,  exclude=None,
   queue=False, pillarenv=None, **kwargs)
          Execute the states in one or more SLS files

          test   Run states in test-only (dry-run) mode

          pillar Custom Pillar values, passed as a dictionary of key-value
                 pairs

                    salt '*' state.apply test pillar='{"foo": "bar"}'

                 NOTE:
                    Values passed this way will override Pillar values set
                    via pillar_roots or an external Pillar source.

                 Changed in version  2016.3.0:  GPG-encrypted  CLI  Pillar
                 data  is now supported via the GPG renderer. See here for
                 details.

          pillar_enc
                 Specify which renderer to use to decrypt  encrypted  data
                 located  within  the pillar value. Currently, only gpg is
                 supported.

                 New in version 2016.3.0.

          queue  False Instead of failing immediately when  another  state
                 run  is  in  progress,  queue  the new state run to begin
                 running once the other has finished.

                 This option starts a new thread  for  each  queued  state
                 run, so use this option sparingly.

          concurrent
                 False Execute state runs concurrently instead of serially

                 WARNING:
                    This flag is potentially dangerous. It is designed for
                    use when multiple state runs can safely be run at  the
                    same  time.  Do  not  use  this  flag  for performance
                    optimization.

          saltenv
                 None Specify a salt fileserver  environment  to  be  used
                 when applying states

                 Changed in version 0.17.0: Argument name changed from env
                 to saltenv.

                 Changed in version 2014.7.0: If no saltenv is  specified,
                 the minion config will be checked for a saltenv parameter
                 and if found, it will be used. If  none  is  found,  base
                 will  be  used.  In prior releases, the minion config was
                 not checked and base would always  be  assumed  when  the
                 saltenv was not explicitly set.

          pillarenv
             Specify a Pillar environment to be used when applying states.
             By default, all Pillar environments will be  merged  together
             and used.

          localconfig
             Optionally,  instead  of using the minion config, load minion
             opts from the file specified by this argument, and then merge
             them   with   the   options  from  the  minion  config.  This
             functionality allows for specific states to be run with their
             own custom minion configuration, including different pillars,
             file_roots, etc.

          mock:  The mock option allows  for  the  state  run  to  execute
                 without  actually calling any states. This then returns a
                 mocked return which will show the requisite  ordering  as
                 well as fully validate the state run.

                 New in version 2015.8.4.

          CLI Example:

             salt '*' state.sls core,edit.vim dev
             salt '*' state.sls core exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"

             salt '*' state.sls myslsfile pillar="{foo: 'Foo!', bar: 'Bar!'}"

   salt.modules.state.sls_id(id_,    mods,    saltenv='base',   test=None,
   queue=False, **kwargs)
          Call a single  ID  from  the  named  module(s)  and  handle  all
          requisites

          The state ID comes before the module ID(s) on the command line.

          New in version 2014.7.0.

          CLI Example:

             salt '*' state.sls_id my_state my_module

   salt.modules.state.template(tem, queue=False, **kwargs)
          Execute the information stored in a template file on the minion.

          This function does not ask a master for a SLS file to render but
          instead directly processes the file at the provided path on  the
          minion.

          CLI Example:

             salt '*' state.template '<Path to template on the minion>'

   salt.modules.state.template_str(tem, queue=False, **kwargs)
          Execute the information stored in a string from an sls template

          CLI Example:

             salt '*' state.template_str '<Template String>'

   salt.modules.state.top(topfn,   test=None,  queue=False,  saltenv=None,
   **kwargs)
          Execute a specific top file instead  of  the  default.  This  is
          useful to apply configurations from a different environment (for
          example, dev or prod), without modifying the default top file.

          CLI Example:

             salt '*' state.top reverse_top.sls
             salt '*' state.top prod_top.sls exclude=sls_to_exclude
             salt '*' state.top dev_top.sls exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"

   salt.modules.status
   Module for returning various status data about a  minion.   These  data
   can be useful for compiling into stats later.

   salt.modules.status.all_status()
          Return  a composite of all status data and info for this minion.
          Warning: There is a LOT here!

          CLI Example:

             salt '*' status.all_status

   salt.modules.status.cpuinfo()
          ..versionchanged:: 2016.3.2 Return the CPU info for this minion

          CLI Example:

             salt '*' status.cpuinfo

   salt.modules.status.cpustats()
          Return the CPU stats for this minion

          CLI Example:

             salt '*' status.cpustats

   salt.modules.status.custom()
          Return a custom composite of  status  data  and  info  for  this
          minion,  based on the minion config file. An example config like
          might be:

             status.cpustats.custom: [ 'cpu', 'ctxt', 'btime', 'processes' ]

          Where status refers to status.py, cpustats is the function where
          we get our data, and custom is this function It is followed by a
          list of keys that we want returned.

          This function is meant to replace  all_status(),  which  returns
          anything and everything, which we probably don't want.

          By  default, nothing is returned. Warning: Depending on what you
          include, there can be a LOT here!

          CLI Example:

             salt '*' status.custom

   salt.modules.status.diskstats()
          ..versionchanged:: 2016.3.2  Return  the  disk  stats  for  this
          minion

          CLI Example:

             salt '*' status.diskstats

   salt.modules.status.diskusage(*args)
          Return the disk usage for this minion

          Usage:

             salt '*' status.diskusage [paths and/or filesystem types]

          CLI Example:

             salt '*' status.diskusage         # usage for all filesystems
             salt '*' status.diskusage / /tmp  # usage for / and /tmp
             salt '*' status.diskusage ext?    # usage for ext[234] filesystems
             salt '*' status.diskusage / ext?  # usage for / and all ext filesystems

   salt.modules.status.loadavg()
          Return the load averages for this minion

          CLI Example:

             salt '*' status.loadavg

             :raises CommandExecutionError: If the system cannot report loadaverages to Python

   salt.modules.status.master(master=None, connected=True)
          New in version 2014.7.0.

          Return  the  connection status with master. Fire an event if the
          connection to master is not as expected. This function is  meant
          to  be  run via a scheduled job from the minion. If master_ip is
          an FQDN/Hostname, it must be resolvable to a valid IPv4 address.

          CLI Example:

             salt '*' status.master

   salt.modules.status.meminfo()
          Return the memory info for this minion

          CLI Example:

             salt '*' status.meminfo

   salt.modules.status.netdev()
          ..versionchanged:: 2016.3.2 Return the network device stats  for
          this minion

          CLI Example:

             salt '*' status.netdev

   salt.modules.status.netstats()
          Return the network stats for this minion

          CLI Example:

             salt '*' status.netstats

   salt.modules.status.nproc()
          Return the number of processing units available on this system

          CLI Example:

             salt '*' status.nproc

   salt.modules.status.pid(sig)
          Return  the  PID or an empty string if the process is running or
          not.  Pass a signature to use to find the process via ps.   Note
          you  can  pass  a Python-compatible regular expression to return
          all pids of processes matching the regexp.

          CLI Example:

             salt '*' status.pid <sig>

   salt.modules.status.ping_master(master)
          New in version 2016.3.0.

          Sends   ping   request    to    the    given    master.    Fires
          '__master_failback' event on success.  Returns bool result.

          CLI Example:

             salt '*' status.ping_master localhost

   salt.modules.status.procs()
          Return the process data

          CLI Example:

             salt '*' status.procs

   salt.modules.status.time(format='%A, %d. %B %Y %I:%M%p')
          New in version 2016.3.0.

          Return  the  current  time on the minion, formatted based on the
          format parameter.

          Default date format: Monday, 27. July 2015 07:55AM

          CLI Example:

             salt '*' status.time

             salt '*' status.time '%s'

   salt.modules.status.uptime()
          Return the uptime for this system.

          Changed in version 2015.8.9: The uptime function was changed  to
          return  a  dictionary of easy-to-read key/value pairs containing
          uptime information, instead of the output from a cmd.run call.

          Changed in version  2016.11.0:  Support  for  OpenBSD,  FreeBSD,
          NetBSD, MacOS, and Solaris

          CLI Example:

             salt '*' status.uptime

   salt.modules.status.version()
          Return the system version for this minion

          CLI Example:

             salt '*' status.version

   salt.modules.status.vmstats()
          ..versionchanged::  2016.3.2 Return the virtual memory stats for
          this minion

          CLI Example:

             salt '*' status.vmstats

   salt.modules.status.w()
          Return a list of logged in users for this minion,  using  the  w
          command

          CLI Example:

             salt '*' status.w

   salt.modules.stormpath
   Support for Stormpath

   New in version 2015.8.0.

   salt.modules.stormpath.create_account(directory_id,   email,  password,
   givenName, surname, **kwargs)
          Create an account

          CLI Examples:
             salt   myminion    stormpath.create_account    <directory_id>
             [email protected] letmein Shemp Howard

   salt.modules.stormpath.delete_account(account_id)
          Delete an account.

          CLI Examples:
             salt myminion stormpath.delete_account <account_id>

   salt.modules.stormpath.list_accounts()
          Show all accounts.

          CLI Example:
             salt myminion stormpath.list_accounts

   salt.modules.stormpath.list_directories()
          Show all directories.

          CLI Example:
             salt myminion stormpath.list_directories

   salt.modules.stormpath.show_account(account_id=None,        email=None,
   directory_id=None, application_id=None, group_id=None, **kwargs)
          Show a specific account.

          CLI Example:
             salt myminion stormpath.show_account <account_id>

   salt.modules.stormpath.show_tenant()
          Get the tenant for the login being used.

   salt.modules.stormpath.update_account(account_id, key=None, value=None,
   items=None)
          Update  one  or more items for this account. Specifying an empty
          value will clear it for that account.

          CLI Examples:
             salt myminion stormpath.update_account <account_id> givenName
             shemp  salt  myminion  stormpath.update_account  <account_id>
             middleName   ''   salt   myminion    stormpath.update_account
             <account_id>   items='{"givenName":  "Shemp"}  salt  myminion
             stormpath.update_account  <account_id>  items='{"middlename":
             ""}

   salt.modules.supervisord
   Provide  the  service module for system supervisord or supervisord in a
   virtualenv

   salt.modules.supervisord.add(name,      user=None,      conf_file=None,
   bin_env=None)
          Activates any updates in config for process/group.

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.add <name>

   salt.modules.supervisord.custom(command,   user=None,   conf_file=None,
   bin_env=None)
          Run any custom supervisord command

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.custom "mstop '*gunicorn*'"

   salt.modules.supervisord.options(name, conf_file=None)
          New in version 2014.1.0.

          Read the config file and return the config options for  a  given
          process

          name   Name of the configured process

          conf_file
                 path to supervisord config file

          CLI Example:

             salt '*' supervisord.options foo

   salt.modules.supervisord.remove(name,     user=None,    conf_file=None,
   bin_env=None)
          Removes process/group from active config

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.remove <name>

   salt.modules.supervisord.reread(user=None,              conf_file=None,
   bin_env=None)
          Reload the daemon's configuration files

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.reread

   salt.modules.supervisord.restart(name='all', user=None, conf_file=None,
   bin_env=None)
          Restart the named  service.   Process  group  names  should  not
          include a trailing asterisk.

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.restart <service>
             salt '*' supervisord.restart <group>:

   salt.modules.supervisord.start(name='all',  user=None,  conf_file=None,
   bin_env=None)
          Start the named service.  Process group names should not include
          a trailing asterisk.

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.start <service>
             salt '*' supervisord.start <group>:

   salt.modules.supervisord.status(name=None,  user=None,  conf_file=None,
   bin_env=None)
          List programs and its state

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.status

   salt.modules.supervisord.status_raw(name=None,               user=None,
   conf_file=None, bin_env=None)
          Display the raw output of status

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.status_raw

   salt.modules.supervisord.stop(name='all',   user=None,  conf_file=None,
   bin_env=None)
          Stop the named service.  Process group names should not  include
          a trailing asterisk.

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

          CLI Example:

             salt '*' supervisord.stop <service>
             salt '*' supervisord.stop <group>:

   salt.modules.supervisord.update(user=None,              conf_file=None,
   bin_env=None, name=None)
          Reload config and add/remove/update as necessary

          user   user to run supervisorctl as

          conf_file
                 path to supervisord config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

          name   name of the process group to update. if none then  update
                 any process group that has changes

          CLI Example:

             salt '*' supervisord.update

   salt.modules.svn
   Subversion SCM

   salt.modules.svn.add(cwd,     targets,     user=None,    username=None,
   password=None, *opts)
          Add files to be tracked by the Subversion working-copy checkout

          cwd    The path to the Subversion repository

          targets
                 None files and directories to  pass  to  the  command  as
                 arguments

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.add /path/to/repo /path/to/new/file

   salt.modules.svn.checkout(cwd,    remote,    target=None,    user=None,
   username=None, password=None, *opts)
          Download a working copy  of  the  remote  Subversion  repository
          directory or file

          cwd    The path to the Subversion repository

          remote None URL to checkout

          target None  The name to give the file or directory working copy
                 Default: svn uses the remote basename

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.checkout /path/to/repo svn://remote/repo

   salt.modules.svn.commit(cwd,   targets=None,    msg=None,    user=None,
   username=None, password=None, *opts)
          Commit  the  current  directory,  files,  or  directories to the
          remote Subversion repository

          cwd    The path to the Subversion repository

          targets
                 None files and directories to  pass  to  the  command  as
                 arguments Default: svn uses '.'

          msg    None Message to attach to the commit log

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.commit /path/to/repo

   salt.modules.svn.diff(cwd,   targets=None,   user=None,  username=None,
   password=None, *opts)
          Return the diff of the current directory, files, or  directories
          from the remote Subversion repository

          cwd    The path to the Subversion repository

          targets
                 None  files  and  directories  to  pass to the command as
                 arguments Default: svn uses '.'

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.diff /path/to/repo

   salt.modules.svn.export(cwd,    remote,     target=None,     user=None,
   username=None, password=None, revision='HEAD', *opts)
          Create an unversioned copy of a tree.

          cwd    The path to the Subversion repository

          remote None URL and path to file or directory checkout

          target None  The name to give the file or directory working copy
                 Default: svn uses the remote basename

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.export /path/to/repo svn://remote/repo

   salt.modules.svn.info(cwd,  targets=None,   user=None,   username=None,
   password=None, fmt='str')
          Display the Subversion information from the checkout.

          cwd    The path to the Subversion repository

          targets
                 None  files, directories, and URLs to pass to the command
                 as arguments svn uses '.' by default

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          fmt    str How to fmt the output from info.   (str,  xml,  list,
                 dict)

          CLI Example:

             salt '*' svn.info /path/to/svn/repo

   salt.modules.svn.remove(cwd,      targets,     msg=None,     user=None,
   username=None, password=None, *opts)
          Remove files and directories from the Subversion repository

          cwd    The path to the Subversion repository

          targets
                 None files, directories, and URLs to pass to the  command
                 as arguments

          msg    None Message to attach to the commit log

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.remove /path/to/repo /path/to/repo/remove

   salt.modules.svn.status(cwd,  targets=None,  user=None,  username=None,
   password=None, *opts)
          Display  the  status  of  the  current  directory,   files,   or
          directories in the Subversion repository

          cwd    The path to the Subversion repository

          targets
                 None  files, directories, and URLs to pass to the command
                 as arguments Default: svn uses '.'

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          CLI Example:

             salt '*' svn.status /path/to/repo

   salt.modules.svn.switch(cwd,    remote,     target=None,     user=None,
   username=None, password=None, *opts)
          New in version 2014.1.0.

          Switch   a  working  copy  of  a  remote  Subversion  repository
          directory

          cwd    The path to the Subversion repository

          remote None URL to switch

          target None The name to give the file or directory working  copy
                 Default: svn uses the remote basename

          user   None Run svn as a user other than what the minion runs as

          username
                 None Connect to the Subversion server as another user

          password
                 None Connect to the Subversion server with this password

          CLI Example:

             salt '*' svn.switch /path/to/repo svn://remote/repo

   salt.modules.svn.update(cwd,  targets=None,  user=None,  username=None,
   password=None, *opts)
          Update the current directory, files,  or  directories  from  the
          remote Subversion repository

          cwd    The path to the Subversion repository

          targets
                 None  files  and  directories  to  pass to the command as
                 arguments Default: svn uses '.'

          user   None Run svn as a user other than what the minion runs as

          password
                 None Connect to the Subversion server with this password

                 New in version 0.17.0.

          username
                 None Connect to the Subversion server as another user

          CLI Example:

             salt '*' svn.update /path/to/repo

   salt.modules.swift
   Module for handling OpenStack Swift calls Author:  Anthony  Stanton  <
   [email protected]>

   Inspired by the S3 and Nova modules

   depends

          * swiftclient Python module

   configuration
          This  module is not usable until the user, tenant, auth URL, and
          password or auth_key are specified either in a pillar or in  the
          minion's config file.  For example:

             keystone.user: admin
             keystone.tenant: admin
             keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
             keystone.password: verybadpass
             # or
             keystone.auth_key: 203802934809284k2j34lkj2l3kj43k

          If  configuration  for  multiple OpenStack accounts is required,
          they can be set up  as  different  configuration  profiles:  For
          example:

             openstack1:
               keystone.user: admin
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
               keystone.password: verybadpass
               # or
               keystone.auth_key: 203802934809284k2j34lkj2l3kj43k

             openstack2:
               keystone.user: admin
               keystone.tenant: admin
               keystone.auth_url: 'http://127.0.0.2:5000/v2.0/'
               keystone.password: verybadpass
               # or
               keystone.auth_key: 303802934809284k2j34lkj2l3kj43k

          With this configuration in place, any of the swift functions can
          make use of a configuration profile by declaring it  explicitly.
          For example:

             salt '*' swift.get mycontainer myfile /tmp/file profile=openstack1

          NOTE:  For Rackspace cloud files setting keystone.auth_version =
          1 is recommended.

   salt.modules.swift.delete(cont, path=None, profile=None)
          Delete a container, or delete an object from a container.

          CLI Example to delete a container:

             salt myminion swift.delete mycontainer

          CLI Example to delete an object from a container:

             salt myminion swift.delete mycontainer remoteobject

   salt.modules.swift.get(cont=None,      path=None,      local_file=None,
   return_bin=False, profile=None)
          List  the  contents  of  a container, or return an object from a
          container. Set return_bin to True in order to retrieve an object
          wholesale.   Otherwise,  Salt  will  attempt  to  parse  an  XML
          response.

          CLI Example to list containers:

             salt myminion swift.get

          CLI Example to list the contents of a container:

             salt myminion swift.get mycontainer

          CLI Example to return the binary contents of an object:

             salt myminion swift.get mycontainer myfile.png return_bin=True

          CLI Example to save the binary contents of an object to a  local
          file:

             salt myminion swift.get mycontainer myfile.png local_file=/tmp/myfile.png

   salt.modules.swift.put(cont, path=None, local_file=None, profile=None)
          Create a new container, or upload an object to a container.

          CLI Example to create a container:

             salt myminion swift.put mycontainer

          CLI Example to upload an object to a container:

             salt myminion swift.put mycontainer remotepath local_file=/path/to/file

   salt.modules.sysbench
   The  'sysbench'  module  is  used  to  analyze  the  performance of the
   minions, right from the master!  It measures various system  parameters
   such as CPU, Memory, File I/O, Threads and Mutex.

   salt.modules.sysbench.cpu()
          Tests for the CPU performance of minions.

          CLI Examples:

             salt '*' sysbench.cpu

   salt.modules.sysbench.fileio()
          This  tests for the file read and write operations Various modes
          of operations are

          * sequential write

          * sequential rewrite

          * sequential read

          * random read

          * random write

          * random read and write

          The test works with 32 files with each file being  1Gb  in  size
          The test consumes a lot of time. Be patient!

          CLI Examples:

             salt '*' sysbench.fileio

   salt.modules.sysbench.memory()
          This tests the memory for read and write operations.

          CLI Examples:

             salt '*' sysbench.memory

   salt.modules.sysbench.mutex()
          Tests the implementation of mutex

          CLI Examples:

             salt '*' sysbench.mutex

   salt.modules.sysbench.threads()
          This tests the performance of the processor's scheduler

          CLI Example:

             salt '*' sysbench.threads

   salt.modules.sysfs module
   Module for interfacing with SysFS

   SEE ALSO:
      https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt

   New in version 2016.3.0.

   salt.modules.sysfs.attr(key, value=None)
          Access/write  a SysFS attribute.  If the attribute is a symlink,
          it's destination is returned

          Returns
                 value or bool

          CLI example:

                    salt '*' sysfs.attr block/sda/queue/logical_block_size

   salt.modules.sysfs.interfaces(root)
          Generate a dictionary with all available interfaces relative  to
          root.  Symlinks are not followed.

          CLI example:

                    salt '*' sysfs.interfaces block/bcache0/bcache

          Output example:

                    {
                       "r": [
                         "state",
                         "partial_stripes_expensive",
                         "writeback_rate_debug",
                         "stripe_size",
                         "dirty_data",
                         "stats_total/cache_hits",
                         "stats_total/cache_bypass_misses",
                         "stats_total/bypassed",
                         "stats_total/cache_readaheads",
                         "stats_total/cache_hit_ratio",
                         "stats_total/cache_miss_collisions",
                         "stats_total/cache_misses",
                         "stats_total/cache_bypass_hits",
                       ],
                       "rw": [
                         "writeback_rate",
                         "writeback_rate_update_seconds",
                         "cache_mode",
                         "writeback_delay",
                         "label",
                         "writeback_running",
                         "writeback_metadata",
                         "running",
                         "writeback_rate_p_term_inverse",
                         "sequential_cutoff",
                         "writeback_percent",
                         "writeback_rate_d_term",
                         "readahead"
                       ],
                       "w": [
                         "stop",
                         "clear_stats",
                         "attach",
                         "detach"
                       ]
                    }

          NOTE:

             * 'r' interfaces are read-only

             * 'w' interfaces are write-only (e.g. actions)

             * 'rw' are interfaces that can both be read or written

   salt.modules.sysfs.read(key, root='')
          Read from SysFS

          Parameters
                 key  -- file or path in SysFS; if key is a list then root
                 will be prefixed on each key

          Returns
                 the full (tree of) SysFS attributes under key

          CLI example:

                    salt '*' sysfs.read class/net/em1/statistics

   salt.modules.sysfs.target(key, full=True)
          Return the basename of a SysFS key path

          Parameters

                 * key -- the location to resolve within SysFS

                 * full -- full path instead of basename

          Returns
                 fullpath or basename of path

          CLI example:

                    salt '*' sysfs.read class/ttyS0

   salt.modules.sysfs.write(key, value)
          Write a SysFS attribute/action

          CLI example:

                    salt '*' sysfs.write devices/system/cpu/cpu0/cpufreq/scaling_governor 'performance'

   salt.modules.syslog_ng
   Module for getting information about syslog-ng

   maintainer
          Tibor Benke <[email protected]>

   maturity
          new

   depends
          cmd

   platform
          all

   This module is capable  of  managing  syslog-ng  instances  which  were
   installed  via  a  package  manager  or  from  source.  Users can use a
   directory as a parameter in the case of most functions, which  contains
   the syslog-ng and syslog-ng-ctl binaries.

   Syslog-ng can be installed via a package manager or from source. In the
   latter case, the syslog-ng and syslog-ng-ctl binaries are not available
   from  the PATH, so users should set location of the sbin directory with
   syslog_ng.set_binary_path.

   Similarly, users can specify the location  of  the  configuration  file
   with  syslog_ng.set_config_file,  then the module will use it. If it is
   not set, syslog-ng uses the default configuration file.

   class salt.modules.syslog_ng.Argument(value='')
          A TypedParameterValue has one or  more  Arguments.  For  example
          this can be the value of key_file.

          Does not need examples.

   class    salt.modules.syslog_ng.Buildable(iterable,    join_body_on='',
   append_extra_newline=True)
          Base class of most classes, which have a build method.

          It contains a common build function.

          Does not need examples.

          build()
                 Builds  the   textual   representation   of   the   whole
                 configuration object with it's children.

          build_body()
                 Builds the body of a syslog-ng configuration object.

          build_header()
                 Builds the header of a syslog-ng configuration object.

          build_tail()
                 Builds the tail of a syslog-ng configuration object.

   class salt.modules.syslog_ng.GivenStatement(value, add_newline=True)

          This  statement returns a string without modification. It can be
          used to
                 use existing configuration snippets.

          Does not need examples.

   class salt.modules.syslog_ng.NamedStatement(type, id='', options=None)
          It represents a configuration statement, which has a name,  e.g.
          a source.

          Does not need examples.

   class salt.modules.syslog_ng.Option(type='', params=None)
          A Statement class contains Option instances.

          An instance of Option can represent a file(), tcp(), udp(), etc.
          option.

          Does not need examples.

   class salt.modules.syslog_ng.Parameter(iterable=None, join_body_on='')
          An Option has one or more Parameter instances.

          Does not need examples.

   class              salt.modules.syslog_ng.ParameterValue(iterable=None,
   join_body_on='')
          A TypedParameter can have one or more values.

          Does not need examples.

   class salt.modules.syslog_ng.SimpleParameter(value='')
          A  Parameter  is  a SimpleParameter, if it's just a simple type,
          like a string.

          For example:

             destination d_file {
                 file(
                     '/var/log/messages'
                 );
             };

          /var/log/messages is a SimpleParameter.

          Does not need examples.

   class salt.modules.syslog_ng.SimpleParameterValue(value='')
          A ParameterValuem which holds a simple type, like a string or  a
          number.

          For     example     in     ip(127.0.0.1)    127.0.0.1    is    a
          SimpleParameterValue.

          Does not need examples.

   class   salt.modules.syslog_ng.Statement(type,   id='',   options=None,
   has_name=True)
          It  represents a syslog-ng configuration statement, e.g. source,
          destination, filter.

          Does not need examples.

   class salt.modules.syslog_ng.TypedParameter(type='', values=None)
          A Parameter, which has a type:

             destination d_tcp {
                 tcp(
                     ip(127.0.0.1)
                 );
             };

          ip(127.0.0.1) is a TypedParameter.

          Does not need examples.

   class               salt.modules.syslog_ng.TypedParameterValue(type='',
   arguments=None)
          We have to go deeper...

          A TypedParameter can have a 'parameter', which also have a type.
          For example key_file and cert_file:

             source demo_tls_source {
                 tcp(
                     ip(0.0.0.0)
                     port(1999)
                     tls(
                         key_file('/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key')
                         cert_file('/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert')
                     )
                 );
             };

          Does not need examples.

   class salt.modules.syslog_ng.UnnamedStatement(type, options=None)
          It represents a configuration statement, which  doesn't  have  a
          name, e.g. a log path.

          Does not need examples.

   salt.modules.syslog_ng.config(name, config, write=True)
          Builds  syslog-ng configuration. This function is intended to be
          used from the state module, users should not use it directly!

          name : the id of the Salt  document  or  it  is  the  format  of
          <statement  name>.id  config  :  the parsed YAML code write : if
          True,  it  writes   the  config  into  the  configuration  file,
          otherwise just returns it

          CLI Example:

             salt '*' syslog_ng.config name='s_local' config="[{'tcp':[{'ip':'127.0.0.1'},{'port':1233}]}]"

   salt.modules.syslog_ng.config_test(syslog_ng_sbin_dir=None,
   cfgfile=None)
          Runs syntax check  against  cfgfile.  If  syslog_ng_sbin_dir  is
          specified, it is added to the PATH during the test.

          CLI Example:

             salt '*' syslog_ng.config_test
             salt '*' syslog_ng.config_test /home/user/install/syslog-ng/sbin
             salt '*' syslog_ng.config_test /home/user/install/syslog-ng/sbin /etc/syslog-ng/syslog-ng.conf

   salt.modules.syslog_ng.get_config_file()
          Returns    the    configuration    directory,   which   contains
          syslog-ng.conf.

          CLI Example:

             salt '*' syslog_ng.get_config_file

   salt.modules.syslog_ng.modules(syslog_ng_sbin_dir=None)
          Returns  the  available  modules.   If   syslog_ng_sbin_dir   is
          specified,  it  is added to the PATH during the execution of the
          command syslog-ng.

          CLI Example:

             salt '*' syslog_ng.modules
             salt '*' syslog_ng.modules /home/user/install/syslog-ng/sbin

   salt.modules.syslog_ng.reload(name)
          Reloads syslog-ng. This function is intended  to  be  used  from
          states.

          If  syslog_ng.set_config_file,  is  called before, this function
          will use the set binary path.

          CLI Example:

             salt '*' syslog_ng.reload

   salt.modules.syslog_ng.set_binary_path(name)
          Sets the path, where the syslog-ng binary  can  be  found.  This
          function is intended to be used from states.

          If  syslog-ng  is  installed  via a package manager, users don't
          need to use this function.

          CLI Example:

             salt '*' syslog_ng.set_binary_path name=/usr/sbin

   salt.modules.syslog_ng.set_config_file(name)
          Sets the configuration's name. This function is intended  to  be
          used from states.

          CLI Example:

             salt '*' syslog_ng.set_config_file name=/etc/syslog-ng

   salt.modules.syslog_ng.set_parameters(version=None,   binary_path=None,
   config_file=None, *args, **kwargs)
          Sets variables.

          CLI Example:

             salt '*' syslog_ng.set_parameters version='3.6'
             salt '*' syslog_ng.set_parameters  binary_path=/home/user/install/syslog-ng/sbin config_file=/home/user/install/syslog-ng/etc/syslog-ng.conf

   salt.modules.syslog_ng.start(name=None,     user=None,      group=None,
   chroot=None, caps=None, no_caps=False, pidfile=None, enable_core=False,
   fd_limit=None, verbose=False, debug=False, trace=False,  yydebug=False,
   persist_file=None, control=None, worker_threads=None)
          Ensures,  that  syslog-ng  is  started via the given parameters.
          This function is intended to be used from the state module.

          Users shouldn't use this function,  if  the  service  module  is
          available  on  their  system.  If  syslog_ng.set_config_file, is
          called before, this function will use the set binary path.

          CLI Example:

             salt '*' syslog_ng.start

   salt.modules.syslog_ng.stats(syslog_ng_sbin_dir=None)
          Returns statistics  from  the  running  syslog-ng  instance.  If
          syslog_ng_sbin_dir  is specified, it is added to the PATH during
          the execution of the command syslog-ng-ctl.

          CLI Example:

             salt '*' syslog_ng.stats
             salt '*' syslog_ng.stats /home/user/install/syslog-ng/sbin

   salt.modules.syslog_ng.stop(name=None)
          Kills syslog-ng. This function is intended to be used  from  the
          state module.

          Users  shouldn't  use  this  function,  if the service module is
          available on  their  system.   If  syslog_ng.set_config_file  is
          called before, this function will use the set binary path.

          CLI Example:

             salt '*' syslog_ng.stop

   salt.modules.syslog_ng.version(syslog_ng_sbin_dir=None)
          Returns   the   version   of   the   installed   syslog-ng.   If
          syslog_ng_sbin_dir is specified, it is added to the PATH  during
          the execution of the command syslog-ng.

          CLI Example:

             salt '*' syslog_ng.version
             salt '*' syslog_ng.version /home/user/install/syslog-ng/sbin

   salt.modules.syslog_ng.write_config(config, newlines=2)
          Writes  the  given  parameter  config into the config file. This
          function is intended to be used from states.

          If syslog_ng.set_config_file, is called  before,  this  function
          will use the set config file.

          CLI Example:

             salt '*' syslog_ng.write_config config='# comment'

   salt.modules.syslog_ng.write_version(name)
          Removes  the previous configuration file, then creates a new one
          and writes the name line. This function is intended to  be  used
          from states.

          If  syslog_ng.set_config_file,  is  called before, this function
          will use the set config file.

          CLI Example:

             salt '*' syslog_ng.write_version name="3.6"

   salt.modules.sysmod
   The sys module provides information about the  available  functions  on
   the minion

   salt.modules.sysmod.argspec(module='')
          Return the argument specification of functions in Salt execution
          modules.

          CLI Example:

             salt '*' sys.argspec pkg.install
             salt '*' sys.argspec sys
             salt '*' sys.argspec

          Module names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.argspec 'pkg.*'

   salt.modules.sysmod.doc(*args)
          Return the docstrings for all  modules.  Optionally,  specify  a
          module or a function to narrow the selection.

          The  strings are aggregated into a single document on the master
          for easy reading.

          Multiple modules/functions can be specified.

          CLI Example:

             salt '*' sys.doc
             salt '*' sys.doc sys
             salt '*' sys.doc sys.doc
             salt '*' sys.doc network.traceroute user.info

          Modules can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.doc 'sys.*'
             salt '*' sys.doc 'sys.list_*'

   salt.modules.sysmod.list_functions(*args, **kwargs)
          List the functions for all modules. Optionally, specify a module
          or modules from which to list.

          CLI Example:

             salt '*' sys.list_functions
             salt '*' sys.list_functions sys
             salt '*' sys.list_functions sys user

          Function names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_functions 'sys.list_*'

          New in version ?.

             salt '*' sys.list_functions 'module.specific_function'

   salt.modules.sysmod.list_modules(*args)
          List the modules loaded on the minion

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.list_modules

          Module names can be specified as globs.

             salt '*' sys.list_modules 's*'

   salt.modules.sysmod.list_renderers(*args)
          List the renderers loaded on the minion

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.list_renderers

          Render names can be specified as globs.

             salt '*' sys.list_renderers 'yaml*'

   salt.modules.sysmod.list_returner_functions(*args, **kwargs)
          List the functions for all returner modules. Optionally, specify
          a returner module or modules from which to list.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_returner_functions
             salt '*' sys.list_returner_functions mysql
             salt '*' sys.list_returner_functions mysql etcd

          Returner names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_returner_functions 'sqlite3.get_*'

   salt.modules.sysmod.list_returners(*args)
          List the returners loaded on the minion

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_returners

          Returner names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_returners 's*'

   salt.modules.sysmod.list_runner_functions(*args, **kwargs)
          List the functions for all runner modules. Optionally, specify a
          runner module or modules from which to list.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_runner_functions
             salt '*' sys.list_runner_functions state
             salt '*' sys.list_runner_functions state virt

          Runner function names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_runner_functions 'state.*' 'virt.*'

   salt.modules.sysmod.list_runners(*args)
          List the runners loaded on the minion

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_runners

          Runner names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_runners 'm*'

   salt.modules.sysmod.list_state_functions(*args, **kwargs)
          List  the functions for all state modules. Optionally, specify a
          state module or modules from which to list.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_state_functions
             salt '*' sys.list_state_functions file
             salt '*' sys.list_state_functions pkg user

          State function names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_state_functions 'file.*'
             salt '*' sys.list_state_functions 'file.s*'

          New in version ?.

             salt '*' sys.list_state_functions 'module.specific_function'

   salt.modules.sysmod.list_state_modules(*args)
          List the modules loaded on the minion

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.list_state_modules

          State module names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.list_state_modules 'mysql_*'

   salt.modules.sysmod.reload_modules()
          Tell the minion to reload the execution modules

          CLI Example:

             salt '*' sys.reload_modules

   salt.modules.sysmod.renderer_doc(*args)
          Return the docstrings for all renderers. Optionally,  specify  a
          renderer or a function to narrow the selection.

          The  strings are aggregated into a single document on the master
          for easy reading.

          Multiple renderers can be specified.

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.renderer_doc
             salt '*' sys.renderer_doc cheetah
             salt '*' sys.renderer_doc jinja json

          Renderer names can be specified as globs.

             salt '*' sys.renderer_doc 'c*' 'j*'

   salt.modules.sysmod.returner_argspec(module='')
          Return the argument specification of functions in Salt  returner
          modules.

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.returner_argspec xmpp
             salt '*' sys.returner_argspec xmpp smtp
             salt '*' sys.returner_argspec

          Returner names can be specified as globs.

             salt '*' sys.returner_argspec 'sqlite3.*'

   salt.modules.sysmod.returner_doc(*args)
          Return  the  docstrings for all returners. Optionally, specify a
          returner or a function to narrow the selection.

          The strings are aggregated into a single document on the  master
          for easy reading.

          Multiple returners/functions can be specified.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.returner_doc
             salt '*' sys.returner_doc sqlite3
             salt '*' sys.returner_doc sqlite3.get_fun
             salt '*' sys.returner_doc sqlite3.get_fun etcd.get_fun

          Returner names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.returner_doc 'sqlite3.get_*'

   salt.modules.sysmod.runner_argspec(module='')
          Return  the  argument  specification of functions in Salt runner
          modules.

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.runner_argspec state
             salt '*' sys.runner_argspec http
             salt '*' sys.runner_argspec

          Runner names can be specified as globs.

             salt '*' sys.runner_argspec 'winrepo.*'

   salt.modules.sysmod.runner_doc(*args)
          Return the docstrings for all  runners.  Optionally,  specify  a
          runner or a function to narrow the selection.

          The  strings are aggregated into a single document on the master
          for easy reading.

          Multiple runners/functions can be specified.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.runner_doc
             salt '*' sys.runner_doc cache
             salt '*' sys.runner_doc cache.grains
             salt '*' sys.runner_doc cache.grains mine.get

          Runner names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.runner_doc 'cache.clear_*'

   salt.modules.sysmod.state_argspec(module='')
          Return the argument specification of  functions  in  Salt  state
          modules.

          New in version 2015.5.0.

          CLI Example:

             salt '*' sys.state_argspec pkg.installed
             salt '*' sys.state_argspec file
             salt '*' sys.state_argspec

          State names can be specified as globs.

             salt '*' sys.state_argspec 'pkg.*'

   salt.modules.sysmod.state_doc(*args)
          Return  the  docstrings  for  all  states. Optionally, specify a
          state or a function to narrow the selection.

          The strings are aggregated into a single document on the  master
          for easy reading.

          Multiple states/functions can be specified.

          New in version 2014.7.0.

          CLI Example:

             salt '*' sys.state_doc
             salt '*' sys.state_doc service
             salt '*' sys.state_doc service.running
             salt '*' sys.state_doc service.running ipables.append

          State names can be specified as globs.

          New in version 2015.5.0.

             salt '*' sys.state_doc 'service.*' 'iptables.*'

   salt.modules.sysmod.state_schema(module='')
          Return a JSON Schema for the given state function(s)

          New in version 2016.3.0.

          CLI Example:

             salt '*' sys.state_schema
             salt '*' sys.state_schema pkg.installed

   salt.modules.sysrc
   sysrc module for FreeBSD

   salt.modules.sysrc.get(**kwargs)
          Return system rc configuration variables

          CLI Example:

                 salt '*' sysrc.get includeDefaults=True

   salt.modules.sysrc.remove(name, **kwargs)
          Remove system rc configuration variables

          CLI Example:

                 salt '*' sysrc.remove name=sshd_enable

   salt.modules.sysrc.set(name, value, **kwargs)
          Set system rc configuration variables

          CLI Example:

                 salt '*' sysrc.set name=sshd_flags value="-p 2222"

   salt.modules.system
   Support for reboot, shutdown, etc

   salt.modules.system.get_computer_desc()
          Get  PRETTY_HOSTNAME  value  stored in /etc/machine-info If this
          file doesn't exist or the variable doesn't exist return False.

          Returns
                 Value of PRETTY_HOSTNAME if this does not exist False.

          Return type
                 str

          CLI Example:

             salt '*' system.get_computer_desc

   salt.modules.system.get_system_date(utc_offset=None)
          Get the system date

          Parameters
                 utc_offset (str) -- The utc offset  in  4  digit  (+0600)
                 format with an

          optional  sign  (+/-).   Will default to None which will use the
          local timezone. To set the time based off of UTC use  "'+0000'".
          Note:  if  being passed through the command line will need to be
          quoted twice to allow negative offsets.   :return:  Returns  the
          system date.  :rtype: str

          CLI Example:

             salt '*' system.get_system_date

   salt.modules.system.get_system_date_time(utc_offset=None)
          Get the system date/time.

          Parameters
                 utc_offset  (str)  --  The  utc offset in 4 digit (+0600)
                 format with an

          optional sign (+/-).  Will default to None which  will  use  the
          local  timezone. To set the time based off of UTC use "'+0000'".
          Note: if being passed through the command line will need  to  be
          quoted  twice  to  allow negative offsets.  :return: Returns the
          system time in YYYY-MM-DD hh:mm:ss format.  :rtype: str

          CLI Example:

             salt '*' system.get_system_date_time "'-0500'"

   salt.modules.system.get_system_time(utc_offset=None)
          Get the system time.

          Parameters
                 utc_offset (str) -- The utc offset  in  4  digit  (+0600)
                 format with an

          optional  sign  (+/-).   Will default to None which will use the
          local timezone. To set the time based off of UTC use  "'+0000'".
          Note:  if  being passed through the command line will need to be
          quoted twice to allow negative offsets.   :return:  Returns  the
          system time in HH:MM AM/PM format.  :rtype: str

          CLI Example:

             salt '*' system.get_system_time

   salt.modules.system.halt()
          Halt a running system

          CLI Example:

             salt '*' system.halt

   salt.modules.system.init(runlevel)
          Change the system runlevel on sysV compatible systems

          CLI Example:

             salt '*' system.init 3

   salt.modules.system.poweroff()
          Poweroff a running system

          CLI Example:

             salt '*' system.poweroff

   salt.modules.system.reboot(at_time=None)
          Reboot the system

          at_time
                 The  wait  time  in  minutes  before  the  system will be
                 rebooted.

          CLI Example:

             salt '*' system.reboot

   salt.modules.system.set_computer_desc(desc)
          Set PRETTY_HOSTNAME value stored in /etc/machine-info This  will
          create  the file if it does not exist. If it is unable to create
          or modify this file returns False.

          Parameters
                 desc (str) -- The computer description

          Returns
                 False on failure. True if successful.

          CLI Example:

             salt '*' system.set_computer_desc "Michael's laptop"

   salt.modules.system.set_system_date(newdate, utc_offset=None)
          Set the Windows system date. Use <mm-dd-yy> format for the date.

          Parameters
                 newdate (str) -- The date to  set.  Can  be  any  of  the
                 following  formats - YYYY-MM-DD - MM-DD-YYYY - MM-DD-YY -
                 MM/DD/YYYY - MM/DD/YY - YYYY/MM/DD

          CLI Example:

             salt '*' system.set_system_date '03-28-13'

   salt.modules.system.set_system_date_time(years=None,       months=None,
   days=None, hours=None, minutes=None, seconds=None, utc_offset=None)
          Set the system date and time. Each argument is an element of the
          date, but not required. If an element is not passed, the current
          system  value for that element will be used. For example, if you
          don't pass the year, the current system year will be used. (Used
          by set_system_date and set_system_time)

          Parameters

                 * years (int) -- Years digit, ie: 2015

                 * months (int) -- Months digit: 1 - 12

                 * days (int) -- Days digit: 1 - 31

                 * hours (int) -- Hours digit: 0 - 23

                 * minutes (int) -- Minutes digit: 0 - 59

                 * seconds (int) -- Seconds digit: 0 - 59

                 * utc_offset  (str)  -- The utc offset in 4 digit (+0600)
                   format with an

          optional sign (+/-).  Will default to None which  will  use  the
          local  timezone. To set the time based off of UTC use "'+0000'".
          Note: if being passed through the command line will need  to  be
          quoted  twice  to  allow  negative  offsets.   :return:  True if
          successful. Otherwise False.  :rtype: bool

          CLI Example:

             salt '*' system.set_system_date_time 2015 5 12 11 37 53 "'-0500'"

   salt.modules.system.set_system_time(newtime, utc_offset=None)
          Set the system time.

          Parameters

                 * newtime (str) --

                   The time to set. Can be any of the  following  formats.
                   -  HH:MM:SS  AM/PM - HH:MM AM/PM - HH:MM:SS (24 hour) -
                   HH:MM (24 hour)

                   Note that the  salt  command  line  parser  parses  the
                   date/time  before we obtain the argument (preventing us
                   from doing utc) Therefore the argument must  be  passed
                   in as a string.  Meaning you may have to quote the text
                   twice from the command line.

                 * utc_offset (str) -- The utc offset in 4  digit  (+0600)
                   format with an

          optional  sign  (+/-).   Will default to None which will use the
          local timezone. To set the time based off of UTC use  "'+0000'".
          Note:  if  being passed through the command line will need to be
          quoted twice to allow negative offsets.  :return:  Returns  True
          if successful. Otherwise False.  :rtype: bool

          CLI Example:

             salt '*' system.set_system_time "'11:20'"

   salt.modules.system.shutdown(at_time=None)
          Shutdown a running system

          at_time
                 The  wait  time  in  minutes  before  the  system will be
                 shutdown.

          CLI Example:

             salt '*' system.shutdown 5

   salt.modules.system_profiler
   System Profiler Module

   Interface with Mac OSX's command-line System Profiler  utility  to  get
   information about package receipts and installed applications.

   New in version 2015.5.0.

   salt.modules.system_profiler.applications()
          Return  the  results  of  a call to system_profiler -xml -detail
          full SPApplicationsDataType as a dictionary.  Top-level keys  of
          the  dictionary  are  the names of each set of install receipts,
          since there  can  be  multiple  receipts  with  the  same  name.
          Contents of each key are a list of dictionaries.

          Note  that  this  can  take  a  long  time depending on how many
          applications are installed on the target Mac.

          CLI Example:

             salt '*' systemprofiler.applications

   salt.modules.system_profiler.receipts()
          Return the results of a call  to  system_profiler  -xml  -detail
          full  SPInstallHistoryDataType  as a dictionary.  Top-level keys
          of the dictionary are the names of each set of install receipts,
          since  there  can  be  multiple  receipts  with  the  same name.
          Contents of each key are a list of dictionaries.

          CLI Example:

             salt '*' systemprofiler.receipts

   salt.modules.systemd
   Provides the service module for systemd

   New in version 0.10.0.

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on  a  minion, and it is using a different module (or gives an error
      similar to 'service.start' is not available), see here.

   salt.modules.systemd.available(name)
          New in version 0.10.4.

          Check that the given service is available  taking  into  account
          template units.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.systemd.disable(name, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  run  by  this  function  from the salt-minion daemon's
          control group. This is done to avoid a race condition  in  cases
          where  the  salt-minion  service is restarted while a service is
          being modified. If  desired,  usage  of  systemd-run(1)  can  be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Disable the named service to not start when the system boots

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.systemd.disabled(name)
          Return if the named service is disabled from starting on boot

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.systemd.enable(name, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands run by this  function  from  the  salt-minion  daemon's
          control  group.  This is done to avoid a race condition in cases
          where the salt-minion service is restarted while  a  service  is
          being  modified.  If  desired,  usage  of  systemd-run(1) can be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Enable the named service to start when the system boots

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.systemd.enabled(name, **kwargs)
          Return if the named service is enabled to start on boot

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.systemd.execs()
          New in version 2014.7.0.

          Return  a  list  of  all  files  specified  as ExecStart for all
          services.

          CLI Example:
             salt '*' service.execs

   salt.modules.systemd.force_reload(name)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands run by this  function  from  the  salt-minion  daemon's
          control  group.  This is done to avoid a race condition in cases
          where the salt-minion service is restarted while  a  service  is
          being  modified.  If  desired,  usage  of  systemd-run(1) can be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          New in version 0.12.0.

          Force-reload the specified service with systemd

          CLI Example:

             salt '*' service.force_reload <service name>

   salt.modules.systemd.get_all()
          Return a list of all available services

          CLI Example:

             salt '*' service.get_all

   salt.modules.systemd.get_disabled()
          Return a list of all disabled services

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.systemd.get_enabled()
          Return a list of all enabled services

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.systemd.get_running()
          Return  a  list  of  all  running services, so far as systemd is
          concerned

          CLI Example:

             salt '*' service.get_running

   salt.modules.systemd.get_static()
          New in version 2015.8.5.

          Return a list of all static services

          CLI Example:

             salt '*' service.get_static

   salt.modules.systemd.mask(name, runtime=False)
          New in version 2015.5.0.

          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands run by this  function  from  the  salt-minion  daemon's
          control  group.  This is done to avoid a race condition in cases
          where the salt-minion service is restarted while  a  service  is
          being  modified.  If  desired,  usage  of  systemd-run(1) can be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Mask the specified service with systemd

          runtime
                 False  Set  to  True  to mask this service only until the
                 next reboot

                 New in version 2015.8.5.

          CLI Example:

             salt '*' service.mask <service name>

   salt.modules.systemd.masked(name)
          New in version 2015.8.0.

          Changed in version 2015.8.5: The return data for  this  function
          has changed. If the service is masked, the return value will now
          be the output of the systemctl is-enabled  command  (so  that  a
          persistent  mask  can  be distinguished from a runtime mask). If
          the service is not masked, then False will be returned.

          Check whether or not a service is masked

          CLI Example:

             salt '*' service.masked <service name>

   salt.modules.systemd.missing(name)
          New in version 2014.1.0.

          The inverse of service.available. Returns True if the  specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.systemd.reload(name)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  run  by  this  function  from the salt-minion daemon's
          control group. This is done to avoid a race condition  in  cases
          where  the  salt-minion  service is restarted while a service is
          being modified. If  desired,  usage  of  systemd-run(1)  can  be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Reload the specified service with systemd

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.systemd.restart(name)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands run by this  function  from  the  salt-minion  daemon's
          control  group.  This is done to avoid a race condition in cases
          where the salt-minion service is restarted while  a  service  is
          being  modified.  If  desired,  usage  of  systemd-run(1) can be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Restart the specified service with systemd

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.systemd.show(name)
          New in version 2014.7.0.

          Show properties of one or more units/jobs or the manager

          CLI Example:
             salt '*' service.show <service name>

   salt.modules.systemd.start(name)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  run  by  this  function  from the salt-minion daemon's
          control group. This is done to avoid a race condition  in  cases
          where  the  salt-minion  service is restarted while a service is
          being modified. If  desired,  usage  of  systemd-run(1)  can  be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Start the specified service with systemd

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.systemd.status(name, sig=None)
          Return the status for a service via systemd, returns True if the
          service is running and False if it is not.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.systemd.stop(name)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  run  by  this  function  from the salt-minion daemon's
          control group. This is done to avoid a race condition  in  cases
          where  the  salt-minion  service is restarted while a service is
          being modified. If  desired,  usage  of  systemd-run(1)  can  be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Stop the specified service with systemd

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.systemd.systemctl_reload()
          New in version 0.15.0.

          Reloads systemctl, an action  needed  whenever  unit  files  are
          updated.

          CLI Example:

             salt '*' service.systemctl_reload

   salt.modules.systemd.unmask(name)
          New in version 2015.5.0.

          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  run  by  this  function  from the salt-minion daemon's
          control group. This is done to avoid a race condition  in  cases
          where  the  salt-minion  service is restarted while a service is
          being modified. If  desired,  usage  of  systemd-run(1)  can  be
          suppressed by setting a config option called systemd.scope, with
          a value of False (no quotes).

          Unmask the specified service with systemd

          CLI Example:

             salt '*' service.unmask <service name>

   salt.modules.telemetry
   Connection module for Telemetry

   New in version 2016.3.0.

   https://github.com/mongolab/mongolab-telemetry-api-docs/blob/master/alerts.md

   configuration
          This  module  accepts explicit telemetry credentials or can also
          read  api  key  credentials  from  a  pillar.  More  Information
          available at:

          https://github.com/mongolab/mongolab-telemetry-api-docs/blob/master/alerts.md

          In the minion's config file:

             telemetry.telemetry_api_keys:
               - abc123  # Key 1
               - efg321  # Backup Key 1
             telemetry_api_base_url: https://telemetry-api.mongolab.com/v0

   depends
          requests

   salt.modules.telemetry.create_alarm(deployment_id,  metric_name,  data,
   api_key=None, profile='telemetry')
          create an telemetry alarms.

          data is a dict of alert configuration data.

          Returns (bool success, str message) tuple.

          CLI Example:
             salt    myminion    telemetry.create_alarm   rs-ds033197   {}
             profile=telemetry

   salt.modules.telemetry.delete_alarms(deployment_id,      alert_id=None,
   metric_name=None, api_key=None, profile='telemetry')

          delete  an alert specified by alert_id or if not specified blows
          away all the alerts
                 in the current deployment.

          Returns (bool success, str message) tuple.

          CLI Example:
             salt     myminion     telemetry.delete_alarms     rs-ds033197
             profile=telemetry

   salt.modules.telemetry.get_alarms(deployment_id, profile='telemetry')
          get all the alarms set up against the current deployment

          Returns dictionary of alarm information

          CLI Example:
             salt      myminion      telemetry.get_alarms      rs-ds033197
             profile=telemetry

   salt.modules.telemetry.get_alert_config(deployment_id,
   metric_name=None, api_key=None, profile='telemetry')
          Get  all alert definitions associated with a given deployment or
          if metric_name is specified, obtain the specific alert config

          Returns dictionary or list of dictionaries.

          CLI Example:
             salt    myminion    telemetry.get_alert_config    rs-ds033197
             currentConnections     profile=telemetry     salt    myminion
             telemetry.get_alert_config rs-ds033197 profile=telemetry

   salt.modules.telemetry.get_notification_channel_id(notify_channel,
   profile='telemetry')
          Given  an  email address, creates a notification-channels if one
          is not found and also  returns  the  corresponding  notification
          channel id.

          notify_channel
                 Email escalation policy

          profile
                 A dict of telemetry config information.

          CLI Example:
             salt      myminion      telemetry.get_notification_channel_id
             [email protected] profile=telemetry

   salt.modules.telemetry.update_alarm(deployment_id,  metric_name,  data,
   api_key=None, profile='telemetry')
          update   an   telemetry   alarms.   data  is  a  dict  of  alert
          configuration data.

          Returns (bool success, str message) tuple.

          CLI Example:
             salt   myminion   telemetry.update_alarm    rs-ds033197    {}
             profile=telemetry

   salt.modules.temp
   Simple module for creating temporary directories and files

   This is a thin wrapper around Pythons tempfile module

   New in version 2015.8.0.

   salt.modules.temp.dir(suffix='', prefix='tmp', parent=None)
          Create a temporary directory

          CLI Example:

             salt '*' temp.dir
             salt '*' temp.dir prefix='mytemp-' parent='/var/run/'

   salt.modules.temp.file(suffix='', prefix='tmp', parent=None)
          Create a temporary file

          CLI Example:

             salt '*' temp.file
             salt '*' temp.file prefix='mytemp-' parent='/var/run/'

   salt.modules.test
   Module for running arbitrary tests

   salt.modules.test.arg(*args, **kwargs)
          Print  out  the data passed into the function *args and `kwargs,
          this is used to both test the publication data and cli  argument
          passing,  but  also  to display the information available within
          the publication data.  Returns {"args": args, "kwargs": kwargs}.

          CLI Example:

             salt '*' test.arg 1 "two" 3.1 txt="hello" wow='{a: 1, b: "hello"}'

   salt.modules.test.arg_repr(*args, **kwargs)
          Print out the data passed into the function *args  and  `kwargs,
          this  is used to both test the publication data and cli argument
          passing, but also to display the  information  available  within
          the  publication  data.   Returns {"args": repr(args), "kwargs":
          repr(kwargs)}.

          CLI Example:

             salt '*' test.arg_repr 1 "two" 3.1 txt="hello" wow='{a: 1, b: "hello"}'

   salt.modules.test.arg_type(*args, **kwargs)
          Print out the types of the args and kwargs. This is used to test
          the types of the args and kwargs passed down to the minion

          CLI Example:

             salt '*' test.arg_type 1 'int'

   salt.modules.test.assertion(assertion)
          Assert the given argument

          CLI Example:

             salt '*' test.assertion False

   salt.modules.test.attr_call()
          Call grains.items via the attribute

          CLI Example:

             salt '*' test.attr_call

   salt.modules.test.collatz(start)
          Execute  the collatz conjecture from the passed starting number,
          returns the sequence and the time it took to compute.  Used  for
          performance tests.

          CLI Example:

             salt '*' test.collatz 3

   salt.modules.test.conf_test()
          Return  the value for test.foo in the minion configuration file,
          or return the default value

          CLI Example:

             salt '*' test.conf_test

   salt.modules.test.cross_test(func, args=None)
          Execute a minion function via the __salt__ object  in  the  test
          module,  used  to verify that the minion functions can be called
          via the __salt__ module.

          CLI Example:

             salt '*' test.cross_test file.gid_to_group 0

   salt.modules.test.echo(text)
          Return a string - used for testing the connection

          CLI Example:

             salt '*' test.echo 'foo bar baz quo qux'

   salt.modules.test.exception(message='Test Exception')
          Raise an exception

          Optionally provide an error message or output the full stack.

          CLI Example:

             salt '*' test.exception 'Oh noes!'

   salt.modules.test.false()
          Always return False

          CLI Example:

             salt '*' test.false

   salt.modules.test.fib(num)
          Return the num-th Fibonacci number, and  the  time  it  took  to
          compute in seconds. Used for performance tests.

          This function is designed to have terrible performance.

          CLI Example:

             salt '*' test.fib 3

   salt.modules.test.get_opts()
          Return the configuration options passed to this minion

          CLI Example:

             salt '*' test.get_opts

   salt.modules.test.kwarg(**kwargs)
          Print  out  the  data passed into the function **kwargs, this is
          used to both test the publication data and  cli  kwarg  passing,
          but  also  to  display  the  information  available  within  the
          publication data.

          CLI Example:

             salt '*' test.kwarg num=1 txt="two" env='{a: 1, b: "hello"}'

   salt.modules.test.module_report()
          Return a dict containing all of the  execution  modules  with  a
          report on the overall availability via different references

          CLI Example:

             salt '*' test.module_report

   salt.modules.test.not_loaded()
          List the modules that were not loaded by the salt loader system

          CLI Example:

             salt '*' test.not_loaded

   salt.modules.test.opts_pkg()
          Return an opts package with the grains and opts for this minion.
          This is primarily used to create the  options  used  for  master
          side state compiling routines

          CLI Example:

             salt '*' test.opts_pkg

   salt.modules.test.outputter(data)
          Test the outputter, pass in data to return

          CLI Example:

             salt '*' test.outputter foobar

   salt.modules.test.ping()
          Used  to  make sure the minion is up and responding. Not an ICMP
          ping.

          Returns True.

          CLI Example:

             salt '*' test.ping

   salt.modules.test.provider(module)
          Pass in a function name to discover what provider is being used

          CLI Example:

             salt '*' test.provider service

   salt.modules.test.providers()
          Return a dict of the provider names and the files that  provided
          them

          CLI Example:

             salt '*' test.providers

   salt.modules.test.rand_sleep(max=60)
          Sleep  for a random number of seconds, used to test long-running
          commands and minions returning at differing intervals

          CLI Example:

             salt '*' test.rand_sleep 60

   salt.modules.test.rand_str(size=9999999999, hash_type=None)
          Return a random string

             size   size of the string to generate

             hash_type
                    hash type to use

                    New in version 2015.5.2.

          CLI Example:

             salt '*' test.rand_str

   salt.modules.test.retcode(code=42)
          Test that the returncode system is functioning correctly

          CLI Example:

             salt '*' test.retcode 42

   salt.modules.test.sleep(length)
          Instruct the minion to initiate a process that will sleep for  a
          given period of time.

          CLI Example:

             salt '*' test.sleep 20

   salt.modules.test.stack()
          Return the current stack trace

          CLI Example:

             salt '*' test.stack

   salt.modules.test.true()
          Always return True

          CLI Example:

             salt '*' test.true

   salt.modules.test.try_(module, return_try_exception=False, **kwargs)
          Try  to  run  a module command. On an exception return None.  If
          return_try_exception is set True return the exception.  This can
          be  helpful  in  templates  where running a module might fail as
          expected.

          CLI Example:

             <pre>
             {% for i in range(0,230) %}
                 {{ salt['test.try'](module='ipmi.get_users', bmc_host='172.2.2.'+i)|yaml(False) }}
             {% endfor %}
             </pre>

   salt.modules.test.tty(*args, **kwargs)
          Deprecated! Moved to cmdmod.

          CLI Example:

             salt '*' test.tty tty0 'This is a test'
             salt '*' test.tty pts3 'This is a test'

   salt.modules.test.version()
          Return the version of salt on the minion

          CLI Example:

             salt '*' test.version

   salt.modules.test.versions()
          This function is an alias of versions_report.
             Returns versions of components used by salt

             CLI Example:

                 salt '*' test.versions_report

   salt.modules.test.versions_information()
          Report the versions of dependent and system software

          CLI Example:

             salt '*' test.versions_information

   salt.modules.test.versions_report()
          Returns versions of components used by salt

          CLI Example:

             salt '*' test.versions_report

   salt.modules.test_virtual
   Module for running arbitrary tests with a __virtual__ function

   salt.modules.timezone
   Module for managing timezone on POSIX-like systems.

   salt.modules.timezone.get_hwclock()
          Get current hardware clock setting (UTC or localtime)

          CLI Example:

             salt '*' timezone.get_hwclock

   salt.modules.timezone.get_offset()
          Get current numeric timezone offset from UCT (i.e. -0700)

          CLI Example:

             salt '*' timezone.get_offset

   salt.modules.timezone.get_zone()
          Get current timezone (i.e. America/Denver)

          CLI Example:

             salt '*' timezone.get_zone

   salt.modules.timezone.get_zonecode()
          Get current timezone (i.e. PST, MDT, etc)

          CLI Example:

             salt '*' timezone.get_zonecode

   salt.modules.timezone.set_hwclock(clock)
          Sets the hardware clock to be either UTC or localtime

          CLI Example:

             salt '*' timezone.set_hwclock UTC

   salt.modules.timezone.set_zone(timezone)
          Unlinks, then symlinks /etc/localtime to the set timezone.

          The timezone is crucial to several  system  processes,  each  of
          which  SHOULD  be  restarted  (for instance, whatever you system
          uses  as  its  cron  and  syslog  daemons).  This  will  not  be
          automagically done and must be done manually!

          CLI Example:

             salt '*' timezone.set_zone 'America/Denver'

   salt.modules.timezone.zone_compare(timezone)
          Compares  the given timezone name with the system timezone name.
          Checks the hash sum between the given timezone, and the one  set
          in  /etc/localtime.  Returns  True if names and hash sums match,
          and False if not.  Mostly useful for running state checks.

          Changed in version 2016.3.0.

          NOTE:
             On Solaris-link operating systems only a string comparison is
             done.

          CLI Example:

             salt '*' timezone.zone_compare 'America/Denver'

   salt.modules.tls
   A  salt module for SSL/TLS.  Can create a Certificate Authority (CA) or
   use Self-Signed certificates.

   depends

          * PyOpenSSL Python module (0.10 or later, 0.14 or later for

          X509 extension support)

   configuration
          Add the following values in /etc/salt/minion for the  CA  module
          to function properly:

             ca.cert_base_path: '/etc/pki'

   CLI  Example  #1  Creating  a  CA,  a  server  request  and  its signed
   certificate:

      # salt-call tls.create_ca my_little \
      days=5 \
      CN='My Little CA' \
      C=US \
      ST=Utah \
      L=Salt Lake City \
      O=Saltstack \
      emailAddress=[email protected]

      Created Private Key: "/etc/pki/my_little/my_little_ca_cert.key"
      Created CA "my_little_ca": "/etc/pki/my_little_ca/my_little_ca_cert.crt"

      # salt-call tls.create_csr my_little CN=www.example.com
      Created Private Key: "/etc/pki/my_little/certs/www.example.com.key
      Created CSR for "www.example.com": "/etc/pki/my_little/certs/www.example.com.csr"

      # salt-call tls.create_ca_signed_cert my_little CN=www.example.com
      Created Certificate for "www.example.com": /etc/pki/my_little/certs/www.example.com.crt"

   CLI Example #2: Creating a client request and its signed certificate

      # salt-call tls.create_csr my_little CN=DBReplica_No.1 cert_type=client
      Created Private Key: "/etc/pki/my_little/certs//DBReplica_No.1.key."
      Created CSR for "DBReplica_No.1": "/etc/pki/my_little/certs/DBReplica_No.1.csr."

      # salt-call tls.create_ca_signed_cert my_little CN=DBReplica_No.1
      Created Certificate for "DBReplica_No.1": "/etc/pki/my_little/certs/DBReplica_No.1.crt"

   CLI Example #3: Creating both a server and client req +  cert  for  the
   same CN

      # salt-call tls.create_csr my_little CN=MasterDBReplica_No.2  \
          cert_type=client
      Created Private Key: "/etc/pki/my_little/certs/MasterDBReplica_No.2.key."
      Created CSR for "DBReplica_No.1": "/etc/pki/my_little/certs/MasterDBReplica_No.2.csr."

      # salt-call tls.create_ca_signed_cert my_little CN=MasterDBReplica_No.2
      Created Certificate for "DBReplica_No.1": "/etc/pki/my_little/certs/DBReplica_No.1.crt"

      # salt-call tls.create_csr my_little CN=MasterDBReplica_No.2 \
          cert_type=server
      Certificate "MasterDBReplica_No.2" already exists

      (doh!)

      # salt-call tls.create_csr my_little CN=MasterDBReplica_No.2 \
          cert_type=server type_ext=True
      Created Private Key: "/etc/pki/my_little/certs/DBReplica_No.1_client.key."
      Created CSR for "DBReplica_No.1": "/etc/pki/my_little/certs/DBReplica_No.1_client.csr."

      # salt-call tls.create_ca_signed_cert my_little CN=MasterDBReplica_No.2
      Certificate "MasterDBReplica_No.2" already exists

      (DOH!)

      # salt-call tls.create_ca_signed_cert my_little CN=MasterDBReplica_No.2 \
          cert_type=server type_ext=True
      Created Certificate for "MasterDBReplica_No.2": "/etc/pki/my_little/certs/MasterDBReplica_No.2_server.crt"

   CLI Example #4: Create a server req + cert with non-CN filename for the
   cert

      # salt-call tls.create_csr my_little CN=www.anothersometh.ing \
          cert_type=server type_ext=True
      Created Private Key: "/etc/pki/my_little/certs/www.anothersometh.ing_server.key."
      Created CSR for "DBReplica_No.1": "/etc/pki/my_little/certs/www.anothersometh.ing_server.csr."

      # salt-call tls_create_ca_signed_cert my_little CN=www.anothersometh.ing \
          cert_type=server cert_filename="something_completely_different"
      Created Certificate for "www.anothersometh.ing": /etc/pki/my_little/certs/something_completely_different.crt

   salt.modules.tls.ca_exists(ca_name, cacert_path=None, ca_filename=None)
          Verify whether a Certificate Authority (CA) already exists

          ca_name
                 name of the CA

          cacert_path
                 absolute path to ca certificates root directory

          ca_filename
                 alternative filename for the CA

                 New in version 2015.5.3.

          CLI Example:

             salt '*' tls.ca_exists test_ca /etc/certs

   salt.modules.tls.cert_base_path(cacert_path=None)
          Return the base path for certs from CLI or from options

          cacert_path
                 absolute path to ca certificates root directory

          CLI Example:

             salt '*' tls.cert_base_path

   salt.modules.tls.cert_info(cert_path, digest='sha256')
          Return information for a particular certificate

          cert_path
                 path to the cert file

          digest what digest to use for fingerprinting

          CLI Example:

             salt '*' tls.cert_info /dir/for/certs/cert.pem

   salt.modules.tls.create_ca(ca_name,        bits=2048,         days=365,
   CN='localhost',  C='US',  ST='Utah', L='Salt Lake City', O='SaltStack',
   OU=None, emailAddress='[email protected]',  fixmode=False,  cacert_path=None,
   ca_filename=None,     digest='sha256',     onlyif=None,    unless=None,
   replace=False)
          Create a Certificate Authority (CA)

          ca_name
                 name of the CA

          bits   number of RSA key bits, default is 2048

          days   number of days the CA will be valid, default is 365

          CN     common name in the request, default is "localhost"

          C      country, default is "US"

          ST     state, default is "Utah"

          L      locality,  default  is  "Centerville",  the  city   where
                 SaltStack originated

          O      organization, default is "SaltStack"

          OU     organizational unit, default is None

          emailAddress
                 email address for the CA owner, default is '[email protected]'

          cacert_path
                 absolute path to ca certificates root directory

          ca_filename
                 alternative filename for the CA

                 New in version 2015.5.3.

          digest The message digest algorithm. Must be a string describing
                 a   digest   algorithm   supported   by    OpenSSL    (by
                 EVP_get_digestbyname,  specifically).  For example, "md5"
                 or "sha1". Default: 'sha256'

          replace
                 Replace this certificate even if it exists

                 New in version 2015.5.1.

          Writes out a CA certificate based upon defined config values. If
          the  file already exists, the function just returns assuming the
          CA certificate already exists.

          If the following values were set:

             ca.cert_base_path='/etc/pki'
             ca_name='koji'

          the resulting CA, and corresponding key, would be written in the
          following location:

             /etc/pki/koji/koji_ca_cert.crt
             /etc/pki/koji/koji_ca_cert.key

          CLI Example:

             salt '*' tls.create_ca test_ca

   salt.modules.tls.create_ca_signed_cert(ca_name,      CN,      days=365,
   cacert_path=None, ca_filename=None, cert_path=None, cert_filename=None,
   digest='sha256', cert_type=None, type_ext=False, replace=False)
          Create  a  Certificate  (CERT)  signed  by  a  named Certificate
          Authority (CA)

          If the  certificate  file  already  exists,  the  function  just
          returns assuming the CERT already exists.

          The CN must match an existing CSR generated by create_csr. If it
          does not, this method does nothing.

          ca_name
                 name of the CA

          CN     common name matching the certificate signing request

          days   number of days certificate is valid, default  is  365  (1
                 year)

          cacert_path
                 absolute path to ca certificates root directory

          ca_filename
                 alternative filename for the CA

                 New in version 2015.5.3.

          cert_path
                 full path to the certificates directory

          cert_filename
                 alternative  filename  for  the  certificate, useful when
                 using special characters in the CN. If this option is set
                 it  will override the certificate filename output effects
                 of cert_type.  type_ext will be completely overridden.

                 New in version 2015.5.3.

          digest The message digest algorithm. Must be a string describing
                 a    digest    algorithm   supported   by   OpenSSL   (by
                 EVP_get_digestbyname, specifically).  For example,  "md5"
                 or "sha1". Default: 'sha256'

          replace
                 Replace this certificate even if it exists

                 New in version 2015.5.1.

          cert_type
                 string. Either 'server' or 'client' (see create_csr() for
                 details).

                 If create_csr(type_ext=True) this function must be called
                 with the same cert_type so it can find the CSR file.

          NOTE:
             create_csr() defaults to cert_type='server'; therefore, if it
             was also called with type_ext, cert_type becomes  a  required
             argument for create_ca_signed_cert()

          type_ext
                 bool.  If  set True, use cert_type as an extension to the
                 CN when formatting the filename.

                 e.g.:            some_subject_CN_server.crt            or
                 some_subject_CN_client.crt

                 This   facilitates  the  context  where  both  types  are
                 required for the same subject

                 If cert_filename is not None,  setting  type_ext  has  no
                 effect

          If the following values were set:

             ca.cert_base_path='/etc/pki'
             ca_name='koji'
             CN='test.egavas.org'

          the  resulting  signed  certificate  would  be  written  in  the
          following location:

             /etc/pki/koji/certs/test.egavas.org.crt

          CLI Example:

             salt '*' tls.create_ca_signed_cert test localhost

   salt.modules.tls.create_csr(ca_name, bits=2048, CN='localhost', C='US',
   ST='Utah',     L='Salt     Lake    City',    O='SaltStack',    OU=None,
   emailAddress='[email protected]',   subjectAltName=None,    cacert_path=None,
   ca_filename=None,  csr_path=None,  csr_filename=None,  digest='sha256',
   type_ext=False, cert_type='server', replace=False)
          Create a Certificate Signing  Request  (CSR)  for  a  particular
          Certificate Authority (CA)

          ca_name
                 name of the CA

          bits   number of RSA key bits, default is 2048

          CN     common name in the request, default is "localhost"

          C      country, default is "US"

          ST     state, default is "Utah"

          L      locality,   default  is  "Centerville",  the  city  where
                 SaltStack originated

          O      organization, default is "SaltStack" NOTE: Must the  same
                 as CA certificate or an error will be raised

          OU     organizational unit, default is None

          emailAddress
                 email address for the request, default is '[email protected]'

          subjectAltName
                 valid subjectAltNames in full form, e.g. to add DNS entry
                 you would call this function with this value:

                 examples: ['DNS:somednsname.com',
                        'DNS:1.2.3.4',                       'IP:1.2.3.4',
                        'IP:2001:4801:7821:77:be76:4eff:fe11:e51',
                        'email:[email protected]']

          NOTE:
             some libraries do not properly query  IP:  prefixes,  instead
             looking  for  the given req. source with a DNS: prefix. To be
             thorough, you may want to include both DNS: and  IP:  entries
             if  you  are  using subjectAltNames for destinations for your
             TLS connections.  e.g.: requests to https://1.2.3.4 will fail
             from  python's requests library w/out the second entry in the
             above list

          New in version 2015.8.0.

          cert_type
                 Specify the  general  certificate  type.  Can  be  either
                 server  or client. Indicates the set of common extensions
                 added to the CSR.

                    server: {
                       'basicConstraints': 'CA:FALSE',
                       'extendedKeyUsage': 'serverAuth',
                       'keyUsage': 'digitalSignature, keyEncipherment'
                    }

                    client: {
                       'basicConstraints': 'CA:FALSE',
                       'extendedKeyUsage': 'clientAuth',
                       'keyUsage': 'nonRepudiation, digitalSignature, keyEncipherment'
                    }

          type_ext
                 boolean.  Whether or not  to  extend  the  filename  with
                 CN_[cert_type]  This can be useful if a server and client
                 certificate are needed for the same CN. Defaults to False
                 to avoid introducing an unexpected file naming pattern

                 The   files   normally   named   some_subject_CN.csr  and
                 some_subject_CN.key will then be saved

          replace
                 Replace this signing request even if it exists

                 New in version 2015.5.1.

          Writes out a Certificate  Signing  Request  (CSR)  If  the  file
          already  exists,  the  function  just  returns  assuming the CSR
          already exists.

          If the following values were set:

             ca.cert_base_path='/etc/pki'
             ca_name='koji'
             CN='test.egavas.org'

          the resulting CSR, and corresponding key, would  be  written  in
          the following location:

             /etc/pki/koji/certs/test.egavas.org.csr
             /etc/pki/koji/certs/test.egavas.org.key

          CLI Example:

             salt '*' tls.create_csr test

   salt.modules.tls.create_empty_crl(ca_name,            cacert_path=None,
   ca_filename=None, crl_file=None)
          Create an empty Certificate Revocation List.

          New in version 2015.8.0.

          ca_name
                 name of the CA

          cacert_path
                 absolute path to ca certificates root directory

          ca_filename
                 alternative filename for the CA

                 New in version 2015.5.3.

          crl_file
                 full path to the CRL file

          CLI Example:

             salt '*' tls.create_empty_crl ca_name='koji'                 ca_filename='ca'                 crl_file='/etc/openvpn/team1/crl.pem'

   salt.modules.tls.create_pkcs12(ca_name,       CN,        passphrase='',
   cacert_path=None, replace=False)
          Create   a   PKCS#12   browser   certificate  for  a  particular
          Certificate (CN)

          ca_name
                 name of the CA

          CN     common name matching the certificate signing request

          passphrase
                 used to unlock the PKCS#12 certificate when  loaded  into
                 the browser

          cacert_path
                 absolute path to ca certificates root directory

          replace
                 Replace this certificate even if it exists

                 New in version 2015.5.1.

          If the following values were set:

             ca.cert_base_path='/etc/pki'
             ca_name='koji'
             CN='test.egavas.org'

          the  resulting  signed  certificate  would  be  written  in  the
          following location:

             /etc/pki/koji/certs/test.egavas.org.p12

          CLI Example:

             salt '*' tls.create_pkcs12 test localhost

   salt.modules.tls.create_self_signed_cert(tls_dir='tls',      bits=2048,
   days=365,   CN='localhost',  C='US',  ST='Utah',  L='Salt  Lake  City',
   O='SaltStack', OU=None,  emailAddress='[email protected]',  cacert_path=None,
   cert_filename=None, digest='sha256', replace=False)
          Create a Self-Signed Certificate (CERT)

          tls_dir
                 location  appended  to  the ca.cert_base_path, default is
                 'tls'

          bits   number of RSA key bits, default is 2048

          CN     common name in the request, default is "localhost"

          C      country, default is "US"

          ST     state, default is "Utah"

          L      locality,  default  is  "Centerville",  the  city   where
                 SaltStack originated

          O      organization,  default is "SaltStack" NOTE: Must the same
                 as CA certificate or an error will be raised

          OU     organizational unit, default is None

          emailAddress
                 email address for the request, default is '[email protected]'

          cacert_path
                 absolute path to ca certificates root directory

          digest The message digest algorithm. Must be a string describing
                 a    digest    algorithm   supported   by   OpenSSL   (by
                 EVP_get_digestbyname, specifically).  For example,  "md5"
                 or "sha1". Default: 'sha256'

          replace
                 Replace this certificate even if it exists

                 New in version 2015.5.1.

          Writes out a Self-Signed Certificate (CERT). If the file already
          exists, the function just returns.

          If the following values were set:

             ca.cert_base_path='/etc/pki'
             tls_dir='koji'
             CN='test.egavas.org'

          the resulting CERT, and corresponding key, would be  written  in
          the following location:

             /etc/pki/koji/certs/test.egavas.org.crt
             /etc/pki/koji/certs/test.egavas.org.key

          CLI Example:

             salt '*' tls.create_self_signed_cert

          Passing options from the command line:

             salt 'minion' tls.create_self_signed_cert CN='test.mysite.org'

   salt.modules.tls.get_ca(ca_name, as_text=False, cacert_path=None)
          Get the certificate path or content

          ca_name
                 name of the CA

          as_text
                 if  true,  return  the certificate content instead of the
                 path

          cacert_path
                 absolute path to ca certificates root directory

          CLI Example:

             salt '*' tls.get_ca test_ca as_text=False cacert_path=/etc/certs

   salt.modules.tls.get_ca_signed_cert(ca_name,            CN='localhost',
   as_text=False, cacert_path=None, cert_filename=None)
          Get the certificate path or content

          ca_name
                 name of the CA

          CN     common name of the certificate

          as_text
                 if  true,  return  the certificate content instead of the
                 path

          cacert_path
                 absolute path to certificates root directory

          cert_filename
                 alternative filename for  the  certificate,  useful  when
                 using special characters in the CN

                 New in version 2015.5.3.

          CLI Example:

             salt '*' tls.get_ca_signed_cert test_ca CN=localhost as_text=False cacert_path=/etc/certs

   salt.modules.tls.get_ca_signed_key(ca_name,             CN='localhost',
   as_text=False, cacert_path=None, key_filename=None)
          Get the certificate path or content

          ca_name
                 name of the CA

          CN     common name of the certificate

          as_text
                 if true, return the certificate content  instead  of  the
                 path

          cacert_path
                 absolute path to certificates root directory

          key_filename
                 alternative  filename  for  the  key,  useful  when using
                 special characters

                 New in version 2015.5.3.

                 in the CN

          CLI Example:

             salt '*' tls.get_ca_signed_key                 test_ca CN=localhost                 as_text=False                 cacert_path=/etc/certs

   salt.modules.tls.get_extensions(cert_type)
          Fetch X509 and CSR extension  definitions  from  tls:extensions:
          (common|server|client) or set them to standard defaults.

          New in version 2015.8.0.

          cert_type:
                 The type of certificate such as server or client.

          CLI Example:

             salt '*' tls.get_extensions client

   salt.modules.tls.maybe_fix_ssl_version(ca_name,       cacert_path=None,
   ca_filename=None)
          Check that the X509 version is correct (was incorrectly  set  in
          previous salt versions).  This will fix the version if needed.

          ca_name
                 ca authority name

          cacert_path
                 absolute path to ca certificates root directory

          ca_filename
                 alternative filename for the CA

                 New in version 2015.5.3.

          CLI Example:

             salt '*' tls.maybe_fix_ssl_version test_ca /etc/certs

   salt.modules.tls.revoke_cert(ca_name,       CN,       cacert_path=None,
   ca_filename=None, cert_path=None, cert_filename=None, crl_file=None)
          Revoke a certificate.

          New in version 2015.8.0.

          ca_name
                 Name of the CA.

          CN     Common name matching the certificate signing request.

          cacert_path
                 Absolute path to ca certificates root directory.

          ca_filename
                 Alternative filename for the CA.

          cert_path
                 Path to the cert file.

          cert_filename
                 Alternative filename for  the  certificate,  useful  when
                 using special characters in the CN.

          crl_file
                 Full path to the CRL file.

          CLI Example:

             salt '*' tls.revoke_cert ca_name='koji'                 ca_filename='ca'                 crl_file='/etc/openvpn/team1/crl.pem'

   salt.modules.tls.set_ca_path(cacert_path)
          If wanted, store the aforementioned cacert_path in context to be
          used as the basepath for further operations

          CLI Example:

             salt '*' tls.set_ca_path /etc/certs

   salt.modules.tomcat
   Support for Tomcat

   This module uses the manager webapp to manage  Apache  tomcat  webapps.
   If  the  manager  webapp  is not configured some of the functions won't
   work.

   configuration

          * Java bin path should be in default path

          * If ipv6 is enabled make sure you permit manager access to ipv6
            interface "0:0:0:0:0:0:0:1"

          * If  you  are  using  tomcat.tar.gz  it  has to be installed or
            symlinked under /opt, preferably using name tomcat

          * "tomcat.signal start/stop" works  but  it  does  not  use  the
            startup scripts

   The following grains/pillar should be set:

      tomcat-manager:
        user: <username>
        passwd: <password>

   or the old format:

      tomcat-manager.user: <username>
      tomcat-manager.passwd: <password>

   Also configure a user in the conf/tomcat-users.xml file:

      <?xml version='1.0' encoding='utf-8'?>
      <tomcat-users>
          <role rolename="manager-script"/>
          <user username="tomcat" password="tomcat" roles="manager-script"/>
      </tomcat-users>

   NOTE:

      * More        information        about        tomcat        manager:
        http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html

      * if you use only this module for deployments you've might  want  to
        strict  access  to  the manager only from localhost for more info:
        http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access

      * Tested on:

        JVM Vendor:
               Sun Microsystems Inc.

        JVM Version:
               1.6.0_43-b01

        OS Architecture:
               amd64

        OS Name:
               Linux

        OS Version:
               2.6.32-358.el6.x86_64

        Tomcat Version:
               Apache Tomcat/7.0.37

   salt.modules.tomcat.deploy_war(war,         context,        force='no',
   url='http://localhost:8080/manager',    saltenv='base',    timeout=180,
   temp_war_location=None, version='')
          Deploy a WAR file

          war    absolute  path  to  WAR file (should be accessible by the
                 user  running  tomcat)  or  a  path  supported   by   the
                 salt.modules.cp.get_file function

          context
                 the context path to deploy

          force  False  set True to deploy the webapp even one is deployed
                 in the context

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          saltenv
                 base   the   environment   for   WAR   file  in  used  by
                 salt.modules.cp.get_url function

          timeout
                 180 timeout for HTTP request

          temp_war_location
                 None use another location to temporarily copy to war file
                 by default the system's temp directory is used

          version
                 ''   Specify  the  war  version.   If  this  argument  is
                 provided, it overrides the version  encoded  in  the  war
                 file name, if one is present.

                 Examples:

                    salt '*' tomcat.deploy_war salt://salt-2015.8.6.war version=2015.08.r6

                 New in version 2015.8.6.

          CLI Examples:

          cp module

             salt '*' tomcat.deploy_war salt://application.war /api
             salt '*' tomcat.deploy_war salt://application.war /api no
             salt '*' tomcat.deploy_war salt://application.war /api yes http://localhost:8080/manager

          minion local file system

             salt '*' tomcat.deploy_war /tmp/application.war /api
             salt '*' tomcat.deploy_war /tmp/application.war /api no
             salt '*' tomcat.deploy_war /tmp/application.war /api yes http://localhost:8080/manager

   salt.modules.tomcat.fullversion()
          Return all server information from catalina.sh version

          CLI Example:

             salt '*' tomcat.fullversion

   salt.modules.tomcat.leaks(url='http://localhost:8080/manager',
   timeout=180)
          Find memory leaks in tomcat

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.leaks

   salt.modules.tomcat.ls(url='http://localhost:8080/manager',
   timeout=180)
          list all the deployed webapps

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.ls
             salt '*' tomcat.ls http://localhost:8080/manager

   salt.modules.tomcat.passwd(passwd, user='', alg='sha1', realm=None)
          This  function  replaces the $CATALINA_HOME/bin/digest.sh script
          convert      a      clear-text       password       to       the
          $CATALINA_BASE/conf/tomcat-users.xml format

          CLI Examples:

             salt '*' tomcat.passwd secret
             salt '*' tomcat.passwd secret tomcat sha1
             salt '*' tomcat.passwd secret tomcat sha1 'Protected Realm'

   salt.modules.tomcat.reload(app,    url='http://localhost:8080/manager',
   timeout=180)
          Reload the webapp

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.reload /jenkins
             salt '*' tomcat.reload /jenkins http://localhost:8080/manager

   salt.modules.tomcat.serverinfo(url='http://localhost:8080/manager',
   timeout=180)
          return details about the server

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.serverinfo
             salt '*' tomcat.serverinfo http://localhost:8080/manager

   salt.modules.tomcat.sessions(app,  url='http://localhost:8080/manager',
   timeout=180)
          return the status of the webapp sessions

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.sessions /jenkins
             salt '*' tomcat.sessions /jenkins http://localhost:8080/manager

   salt.modules.tomcat.signal(signal=None)
          Signals catalina to start, stop, securestart, forcestop.

          CLI Example:

             salt '*' tomcat.signal start

   salt.modules.tomcat.start(app,     url='http://localhost:8080/manager',
   timeout=180)
          Start the webapp

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.start /jenkins
             salt '*' tomcat.start /jenkins http://localhost:8080/manager

   salt.modules.tomcat.status(url='http://localhost:8080/manager',
   timeout=180)
          Used to test if the tomcat manager is up

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.status
             salt '*' tomcat.status http://localhost:8080/manager

   salt.modules.tomcat.status_webapp(app,
   url='http://localhost:8080/manager', timeout=180)
          return the status of the webapp (stopped | running | missing)

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.status_webapp /jenkins
             salt '*' tomcat.status_webapp /jenkins http://localhost:8080/manager

   salt.modules.tomcat.stop(app,      url='http://localhost:8080/manager',
   timeout=180)
          Stop the webapp

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.stop /jenkins
             salt '*' tomcat.stop /jenkins http://localhost:8080/manager

   salt.modules.tomcat.undeploy(app,  url='http://localhost:8080/manager',
   timeout=180)
          Undeploy a webapp

          app    the webapp context path

          url    http://localhost:8080/manager  the  URL  of  the   server
                 manager webapp

          timeout
                 180 timeout for HTTP request

          CLI Examples:

             salt '*' tomcat.undeploy /jenkins
             salt '*' tomcat.undeploy /jenkins http://localhost:8080/manager

   salt.modules.tomcat.version()
          Return server version from catalina.sh version

          CLI Example:

             salt '*' tomcat.version

   salt.modules.trafficserver
   Apache Traffic Server execution module.

   New in version 2015.8.0.

   traffic_ctl  is  used to execute individual Traffic Server commands and
   to script multiple commands in a shell.

   salt.modules.trafficserver.alarms()
          List all alarm events that have not been acknowledged (cleared).

             salt '*' trafficserver.alarms

   salt.modules.trafficserver.bounce_cluster()
          Bounce all Traffic Server nodes in the cluster. Bouncing Traffic
          Server  shuts  down  and  immediately  restarts  Traffic Server,
          node-by-node.

             salt '*' trafficserver.bounce_cluster

   salt.modules.trafficserver.bounce_local(drain=False)
          Bounce Traffic Server on the local node. Bouncing Traffic Server
          shuts down and immediately restarts the Traffic Server node.

          drain  This  option  modifies  the  restart  behavior  such that
                 traffic_server is not  shut  down  until  the  number  of
                 active  client  connections  drops to the number given by
                 the          proxy.config.restart.active_client_threshold
                 configuration variable.

             salt '*' trafficserver.bounce_local
             salt '*' trafficserver.bounce_local drain=True

   salt.modules.trafficserver.clear_alarms(alarm)
          Clear  (acknowledge) an alarm event. The arguments are "all" for
          all current alarms, a specific alarm number (e.g. ''1''), or  an
          alarm             string             identifier            (e.g.
          ''MGMT_ALARM_PROXY_CONFIG_ERROR'').

             salt '*' trafficserver.clear_alarms [all | #event | name]

   salt.modules.trafficserver.clear_cluster()
          Clears accumulated statistics on all nodes in the cluster.

             salt '*' trafficserver.clear_cluster

   salt.modules.trafficserver.clear_node()
          Clears accumulated statistics on the local node.

             salt '*' trafficserver.clear_node

   salt.modules.trafficserver.match_config(regex)
          Display the current values of all configuration variables  whose
          names match the given regular expression.

          New in version 2016.11.0.

             salt '*' trafficserver.match_config regex

   salt.modules.trafficserver.match_metric(regex)
          Display  the current values of all metrics whose names match the
          given regular expression.

          New in version 2016.11.0.

             salt '*' trafficserver.match_metric regex

   salt.modules.trafficserver.match_var(regex)
          Display the current values  of  all  performance  statistics  or
          configuration  variables  whose  names  match  the given regular
          expression.

          Deprecated   since   version   Oxygen:   Use   match_metric   or
          match_config instead.

             salt '*' trafficserver.match_var regex

   salt.modules.trafficserver.offline(path)
          Mark   a  cache  storage  device  as  offline.  The  storage  is
          identified by a path which must match exactly a  path  specified
          in  storage.config.  This removes the storage from the cache and
          redirects requests that would have used this  storage  to  other
          storage.  This has exactly the same effect as a disk failure for
          that storage. This does  not  persist  across  restarts  of  the
          traffic_server process.

             salt '*' trafficserver.offline /path/to/cache

   salt.modules.trafficserver.read_config(*args)
          Read Traffic Server configuration variable definitions.

          New in version 2016.11.0.

             salt '*' trafficserver.read_config proxy.config.http.keep_alive_post_out

   salt.modules.trafficserver.read_metric(*args)
          Read Traffic Server one or more metrics.

          New in version 2016.11.0.

             salt '*' trafficserver.read_metric proxy.process.http.tcp_hit_count_stat

   salt.modules.trafficserver.read_var(*args)
          Read variable definitions from the traffic_line command.

          Deprecated  since version Oxygen: Use read_metric or read_config
          instead. Note that this  function  does  not  work  for  Traffic
          Server versions >= 7.0.

             salt '*' trafficserver.read_var proxy.process.http.tcp_hit_count_stat

   salt.modules.trafficserver.refresh()
          Initiate  a  Traffic  Server configuration file reread. Use this
          command  to  update  the   running   configuration   after   any
          configuration file modification.

          The  timestamp  of  the  last  reconfiguration event (in seconds
          since       epoch)       is       published        in        the
          proxy.node.config.reconfigure_time metric.

             salt '*' trafficserver.refresh

   salt.modules.trafficserver.restart_cluster()
          Restart  the  traffic_manager  process  and  the  traffic_server
          process on all the nodes in a cluster.

             salt '*' trafficserver.restart_cluster

   salt.modules.trafficserver.restart_local(drain=False)
          Restart the traffic_manager and traffic_server processes on  the
          local node.

          drain  This  option  modifies  the  restart  behavior  such that
                 traffic_server is not  shut  down  until  the  number  of
                 active  client  connections  drops to the number given by
                 the          proxy.config.restart.active_client_threshold
                 configuration variable.

             salt '*' trafficserver.restart_local
             salt '*' trafficserver.restart_local drain=True

   salt.modules.trafficserver.set_config(variable, value)
          Set the value of a Traffic Server configuration variable.

          variable
                 Name of a Traffic Server configuration variable.

          value  The new value to set.

          New in version 2016.11.0.

             salt '*' trafficserver.set_config proxy.config.http.keep_alive_post_out 0

   salt.modules.trafficserver.set_var(variable, value)

          Deprecated  since  version  Oxygen: Use set_config instead. Note
          that this function does not work for Traffic Server versions  >=
          7.0.

          salt '*' trafficserver.set_var proxy.config.http.server_ports

   salt.modules.trafficserver.shutdown()
          Shut down Traffic Server on the local node.

             salt '*' trafficserver.shutdown

   salt.modules.trafficserver.startup()
          Start Traffic Server on the local node.

             salt '*' trafficserver.start

   salt.modules.trafficserver.status()
          Show  the  current  proxy  server  status,  indicating  if we're
          running or not.

             salt '*' trafficserver.status

   salt.modules.trafficserver.zero_cluster()
          Reset performance statistics to zero across the cluster.

             salt '*' trafficserver.zero_cluster

   salt.modules.trafficserver.zero_node()
          Reset performance statistics to zero on the local node.

             salt '*' trafficserver.zero_cluster

   salt.modules.tuned
   Interface to Red Hat tuned-adm module

   maintainer
          Syed Ali <[email protected]>

   maturity
          new

   depends
          tuned-adm

   platform
          Linux

   salt.modules.tuned.active()
          Return current active profile

          CLI Example:

             salt '*' tuned.active

   salt.modules.tuned.list()
          List the profiles available

          CLI Example:

             salt '*' tuned.list

   salt.modules.tuned.off()
          Turn off all profiles

          CLI Example:

             salt '*' tuned.off

   salt.modules.tuned.profile(profile_name)
          Activate specified profile

          CLI Example:

             salt '*' tuned.profile virtual-guest

   salt.modules.twilio_notify
   Module for notifications via Twilio

   New in version 2014.7.0.

   depends

          * twilio python module

   configuration
          Configure this module by specifying the name of a  configuration
          profile in the minion config, minion pillar, or master config.

          For example:

             my-twilio-account:
                 twilio.account_sid: AC32a3c83990934481addd5ce1659f04d2
                 twilio.auth_token: mytoken

   salt.modules.twilio_notify.send_sms(profile, body, to, from_)
          Send an sms

          CLI Example:
             twilio.send_sms   twilio-account  'Test  sms'  '+18019999999'
             '+18011111111'

   salt.modules.udev
   Manage and query udev info

   New in version 2015.8.0.

   salt.modules.udev.env(dev)
          Return all environment variables udev has for dev

          CLI Example:

             salt '*' udev.env /dev/sda
             salt '*' udev.env /sys/class/net/eth0

   salt.modules.udev.exportdb()
          Return all the udev database

          CLI Example:

   salt.modules.udev.info(dev)
          Extract all info delivered by udevadm

          CLI Example:

             salt '*' udev.info /dev/sda
             salt '*' udev.info /sys/class/net/eth0

   salt.modules.udev.links(dev)
          Return all udev-created device symlinks

          CLI Example:

             salt '*' udev.links /dev/sda
             salt '*' udev.links /sys/class/net/eth0

   salt.modules.udev.name(dev)
          Return the actual dev name(s?) according to udev for dev

          CLI Example:

             salt '*' udev.dev /dev/sda
             salt '*' udev.dev /sys/class/net/eth0

   salt.modules.udev.path(dev)
          Return the physical device path(s?) according to udev for dev

          CLI Example:

             salt '*' udev.path /dev/sda
             salt '*' udev.path /sys/class/net/eth0

   salt.modules.upstart
   Module for the management of upstart systems. The Upstart  system  only
   supports service starting, stopping and restarting.

   IMPORTANT:
      If you feel that Salt should be using this module to manage services
      on a minion, and it is using a different module (or gives  an  error
      similar to 'service.start' is not available), see here.

   Currently  (as  of  Ubuntu 12.04) there is no tool available to disable
   Upstart services (like update-rc.d). This[1] is the recommended way  to
   disable an Upstart service. So we assume that all Upstart services that
   have not been disabled in this manner are enabled.

   But this is broken because we do not check to see  that  the  dependent
   services  are  enabled.  Otherwise  we  would have to do something like
   parse the output of "initctl show-config" to determine if  all  service
   dependencies  are enabled to start on boot. For example, see the "start
   on" condition for the lightdm service below[2]. And this would  be  too
   hard. So we wait until the upstart developers have solved this problem.
   :) This is to say that an Upstart  service  that  is  enabled  may  not
   really be enabled.

   Also, when an Upstart service is enabled, should the dependent services
   be enabled too? Probably not. But there should be a notice about  this,
   at least.

   [1]
   http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting

   [2] example upstart configuration file:

      lightdm
      emits login-session-start
      emits desktop-session-start
      emits desktop-shutdown
      start on ((((filesystem and runlevel [!06]) and started dbus) and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics)) or runlevel PREVLEVEL=S)
      stop on runlevel [016]

   WARNING:
      This  module  should  not be used on Red Hat systems. For these, the
      rh_service  module  should  be  used,  as  it  supports  the  hybrid
      upstart/sysvinit system used in RHEL/CentOS 6.

   salt.modules.upstart.available(name)
          Returns  True  if  the specified service is available, otherwise
          returns False.

          CLI Example:

             salt '*' service.available sshd

   salt.modules.upstart.disable(name, **kwargs)
          Disable the named service from starting on boot

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.upstart.disabled(name)
          Check to see if the named service is disabled to start on boot

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.upstart.enable(name, **kwargs)
          Enable the named service to start at boot

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.upstart.enabled(name, **kwargs)
          Check to see if the named service is enabled to start on boot

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.upstart.force_reload(name)
          Force-reload the named service

          CLI Example:

             salt '*' service.force_reload <service name>

   salt.modules.upstart.full_restart(name)
          Do a full restart (stop/start) of the named service

          CLI Example:

             salt '*' service.full_restart <service name>

   salt.modules.upstart.get_all()
          Return all installed services

          CLI Example:

             salt '*' service.get_all

   salt.modules.upstart.get_disabled()
          Return the disabled services

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.upstart.get_enabled()
          Return the enabled services

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.upstart.missing(name)
          The inverse of service.available.  Returns True if the specified
          service is not available, otherwise returns False.

          CLI Example:

             salt '*' service.missing sshd

   salt.modules.upstart.reload(name)
          Reload the named service

          CLI Example:

             salt '*' service.reload <service name>

   salt.modules.upstart.restart(name)
          Restart the named service

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.upstart.start(name)
          Start the specified service

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.upstart.status(name, sig=None)
          Return  the  status  for  a  service, returns a bool whether the
          service is running.

          CLI Example:

             salt '*' service.status <service name>

   salt.modules.upstart.stop(name)
          Stop the specified service

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.uptime
   Wrapper around uptime API
   salt.modules.uptime.check_exists(name)
          Check if a given URL is in being monitored by uptime

          CLI Example:

             salt '*' uptime.check_exists http://example.org

   salt.modules.uptime.checks_list()
          List URL checked by uptime

          CLI Example:

             salt '*' uptime.checks_list

   salt.modules.uptime.create(name, **params)
          Create a check on a given URL.

          Additional parameters can be used and are  passed  to  API  (for
          example   interval,   maxTime,   etc).   See  the  documentation
          https://github.com/fzaninotto/uptime for  a  full  list  of  the
          parameters.

          CLI Example:

             salt '*' uptime.create http://example.org

   salt.modules.uptime.delete(name)
          Delete a check on a given URL

          CLI Example:

             salt '*' uptime.delete http://example.org

   salt.modules.useradd
   Manage users with the useradd command

   IMPORTANT:
      If you feel that Salt should be using this module to manage users on
      a minion, and it is using a different  module  (or  gives  an  error
      similar to 'user.info' is not available), see here.

   salt.modules.useradd.add(name,    uid=None,    gid=None,   groups=None,
   home=None,   shell=None,   unique=True,   system=False,    fullname='',
   roomnumber='',     workphone='',     homephone='',     createhome=True,
   loginclass=None, root=None)
          Add a user to the minion

          CLI Example:

             salt '*' user.add name <uid> <gid> <groups> <home> <shell>

   salt.modules.useradd.chfullname(name, fullname)
          Change the user's Full Name

          CLI Example:

             salt '*' user.chfullname foo "Foo Bar"

   salt.modules.useradd.chgid(name, gid, root=None)
          Change the default group of the user

          CLI Example:

             salt '*' user.chgid foo 4376

   salt.modules.useradd.chgroups(name, groups, append=False, root=None)
          Change the groups to which this user belongs

          name   User to modify

          groups Groups to set for the user

          append False If True, append the specified group(s).  Otherwise,
                 this  function  will  replace  the user's groups with the
                 specified group(s).

          CLI Examples:

             salt '*' user.chgroups foo wheel,root
             salt '*' user.chgroups foo wheel,root append=True

   salt.modules.useradd.chhome(name, home, persist=False, root=None)
          Change the home directory of the user, pass True for persist  to
          move  files  to the new home directory if the old home directory
          exist.

          CLI Example:

             salt '*' user.chhome foo /home/users/foo True

   salt.modules.useradd.chhomephone(name, homephone)
          Change the user's Home Phone

          CLI Example:

             salt '*' user.chhomephone foo 7735551234

   salt.modules.useradd.chloginclass(name, loginclass, root=None)
          Change the default login class of the user

          NOTE:
             This function only applies to OpenBSD systems.

          CLI Example:

             salt '*' user.chloginclass foo staff

   salt.modules.useradd.chroomnumber(name, roomnumber)
          Change the user's Room Number

          CLI Example:

             salt '*' user.chroomnumber foo 123

   salt.modules.useradd.chshell(name, shell, root=None)
          Change the default shell of the user

          CLI Example:

             salt '*' user.chshell foo /bin/zsh

   salt.modules.useradd.chuid(name, uid)
          Change the uid for a named user

          CLI Example:

             salt '*' user.chuid foo 4376

   salt.modules.useradd.chworkphone(name, workphone)
          Change the user's Work Phone

          CLI Example:

             salt '*' user.chworkphone foo 7735550123

   salt.modules.useradd.delete(name, remove=False, force=False, root=None)
          Remove a user from the minion

          CLI Example:

             salt '*' user.delete name remove=True force=True

   salt.modules.useradd.get_loginclass(name)
          Get the login class of the user

          NOTE:
             This function only applies to OpenBSD systems.

          CLI Example:

             salt '*' user.get_loginclass foo

   salt.modules.useradd.getent(refresh=False)
          Return the list of all info for all users

          CLI Example:

             salt '*' user.getent

   salt.modules.useradd.info(name)
          Return user information

          CLI Example:

             salt '*' user.info root

   salt.modules.useradd.list_groups(name)
          Return a list of groups the named user belongs to

          CLI Example:

             salt '*' user.list_groups foo

   salt.modules.useradd.list_users()
          Return a list of all users

          CLI Example:

             salt '*' user.list_users

   salt.modules.useradd.primary_group(name)
          Return the primary group of the named user

          New in version 2016.3.0.

          CLI Example:

             salt '*' user.primary_group saltadmin

   salt.modules.useradd.rename(name, new_name, root=None)
          Change the username for a named user

          CLI Example:

             salt '*' user.rename name new_name

   salt.modules.uwsgi
   uWSGI                           stats                            server
   https://uwsgi-docs.readthedocs.io/en/latest/StatsServer.html

   maintainer
          Peter Baumgartner <[email protected]>

   maturity
          new

   platform
          all

   salt.modules.uwsgi.stats(socket)
          Return the data from uwsgi --connect-and-read as a dictionary.

          socket The socket the uWSGI stats server is listening on

          CLI Example:

             salt '*' uwsgi.stats /var/run/mystatsserver.sock

             salt '*' uwsgi.stats 127.0.0.1:5050

   salt.modules.varnish
   Support for Varnish

   New in version 2014.7.0.

   NOTE:
      These  functions  are  designed  to work with all implementations of
      Varnish from 3.x onwards

   salt.modules.varnish.ban(ban_expression)
          Add ban to the varnish cache

          CLI Example:

             salt '*' varnish.ban ban_expression

   salt.modules.varnish.ban_list()
          List varnish cache current bans

          CLI Example:

             salt '*' varnish.ban_list

   salt.modules.varnish.param_set(param, value)
          Set a param in varnish cache

          CLI Example:

             salt '*' varnish.param_set param value

   salt.modules.varnish.param_show(param=None)
          Show params of varnish cache

          CLI Example:

             salt '*' varnish.param_show param

   salt.modules.varnish.purge()
          Purge the varnish cache

          CLI Example:

             salt '*' varnish.purge

   salt.modules.varnish.version()
          Return server version from varnishd -V

          CLI Example:

             salt '*' varnish.version

   salt.modules.vbox_guest
   VirtualBox Guest Additions installer

   salt.modules.vbox_guest.additions_install(*args, **kwargs)
          Install VirtualBox Guest Additions. Uses the  CD,  connected  by
          VirtualBox.

          To  connect  VirtualBox Guest Additions via VirtualBox graphical
          interface press 'Host+D' ('Host' is usually 'Right Ctrl').

          See https://www.virtualbox.org/manual/ch04.html#idp52733088  for
          more details.

          CLI Example:

             salt '*' vbox_guest.additions_install
             salt '*' vbox_guest.additions_install reboot=True
             salt '*' vbox_guest.additions_install upgrade_os=True

          Parameters

                 * reboot   (bool)   --   reboot   computer   to  complete
                   installation

                 * upgrade_os (bool) -- upgrade OS (to ensure the  latests
                   version of kernel and developer tools are installed)

          Returns
                 version  of  VirtualBox  Guest  Additions  or string with
                 error

   salt.modules.vbox_guest.additions_mount()
          Mount VirtualBox Guest Additions CD to the temp directory.

          To connect VirtualBox Guest Additions via  VirtualBox  graphical
          interface press 'Host+D' ('Host' is usually 'Right Ctrl').

          CLI Example:

             salt '*' vbox_guest.additions_mount

          Returns
                 True or OSError exception

   salt.modules.vbox_guest.additions_remove(**kwargs)
          Remove VirtualBox Guest Additions.

          Firstly    it   tries   to   uninstall   itself   by   executing
          '/opt/VBoxGuestAdditions-VERSION/uninstall.run  uninstall'.   It
          uses the CD, connected by VirtualBox if it failes.

          CLI Example:

             salt '*' vbox_guest.additions_remove
             salt '*' vbox_guest.additions_remove force=True

          Parameters
                 force (bool) -- force VirtualBox Guest Additions removing

          Returns
                 True   if   VirtualBox   Guest   Additions  were  removed
                 successfully else False

   salt.modules.vbox_guest.additions_umount(mount_point)
          Unmount VirtualBox Guest Additions CD from the temp directory.

          CLI Example:

             salt '*' vbox_guest.additions_umount

          Parameters
                 mount_point -- directory VirtualBox  Guest  Additions  is
                 mounted to

          Returns
                 True or an string with error

   salt.modules.vbox_guest.additions_version()
          Check VirtualBox Guest Additions version.

          CLI Example:

             salt '*' vbox_guest.additions_version

          Returns
                 version  of  VirtualBox  Guest Additions or False if they
                 are not installed

   salt.modules.vbox_guest.grant_access_to_shared_folders_to(name,
   users=None)
          Grant access to auto-mounted shared folders to the users.

          User  is  specified  by  it's  name. To grant access for several
          users use argument users.  Access will be denied  to  the  users
          not listed in users argument.

          See    https://www.virtualbox.org/manual/ch04.html#sf_mount_auto
          for more details.

          CLI Example:

             salt '*' vbox_guest.grant_access_to_shared_folders_to fred
             salt '*' vbox_guest.grant_access_to_shared_folders_to users ['fred', 'roman']

          Parameters

                 * name (str) -- name of  the  user  to  grant  access  to
                   auto-mounted shared folders to

                 * users  (list of str) -- list of names of users to grant
                   access to auto-mounted shared folders to (if specified,
                   name will not be taken into account)

          Returns
                 list  of  users  who  have  access to auto-mounted shared
                 folders

   salt.modules.vbox_guest.list_shared_folders_users()
          List users who have access to auto-mounted shared folders.

          See    https://www.virtualbox.org/manual/ch04.html#sf_mount_auto
          for more details.

          CLI Example:

             salt '*' vbox_guest.list_shared_folders_users

          Returns
                 list  of  users  who  have  access to auto-mounted shared
                 folders

   salt.modules.vboxmanage module
   Support for VirtualBox using the VBoxManage command

   New in version 2016.3.0.

   If  the  vboxdrv  kernel  module  is  not  loaded,  this   module   can
   automatically    load    it    by   configuring   autoload_vboxdrv   in
   /etc/salt/minion:

   The default for this setting is False.

   depends
          virtualbox

   salt.modules.vboxmanage.clonemedium(medium, uuid_in=None, file_in=None,
   uuid_out=None,      file_out=None,      mformat=None,     variant=None,
   existing=False, **kwargs)
          Clone a new VM from an existing VM

          CLI Example:

             salt 'hypervisor' vboxmanage.clonemedium <name> <new_name>

   salt.modules.vboxmanage.clonevm(name=None,  uuid=None,   new_name=None,
   snapshot_uuid=None,  snapshot_name=None,  mode='machine', options=None,
   basefolder=None, new_uuid=None, register=False, groups=None, **kwargs)
          Clone a new VM from an existing VM

          CLI Example:

             salt 'hypervisor' vboxmanage.clonevm <name> <new_name>

   salt.modules.vboxmanage.create(name,     groups=None,      ostype=None,
   register=True, basefolder=None, new_uuid=None, **kwargs)
          Create a new VM

          CLI Example:

             salt 'hypervisor' vboxmanage.create <name>

   salt.modules.vboxmanage.destroy(name)
          Unregister and destroy a VM

          CLI Example:

             salt '*' vboxmanage.destroy my_vm

   salt.modules.vboxmanage.list_items(item,                 details=False,
   group_by='UUID')
          Return a list of a specific type of item.  The  following  items
          are available:
             vms   runningvms   ostypes   hostdvds   hostfloppies  intnets
             bridgedifs   hostonlyifs   natnets    dhcpservers    hostinfo
             hostcpuids  hddbackends hdds dvds floppies usbhost usbfilters
             systemproperties extpacks groups webcams screenshotformats

          CLI Example:

             salt 'hypervisor' vboxmanage.items <item>
             salt 'hypervisor' vboxmanage.items <item> details=True
             salt 'hypervisor' vboxmanage.items <item> details=True group_by=Name

          Some items do not display well, or at all, unless details is set
          to  True.  By  default, items are grouped by the UUID field, but
          not all items contain that field. In those cases, another  field
          must be specified.

   salt.modules.vboxmanage.list_nodes()
          Return a list of registered VMs

          CLI Example:

             salt '*' vboxmanage.list_nodes

   salt.modules.vboxmanage.list_nodes_full()
          Return a list of registered VMs, with detailed information

          CLI Example:

             salt '*' vboxmanage.list_nodes_full

   salt.modules.vboxmanage.list_nodes_min()
          Return a list of registered VMs, with minimal information

          CLI Example:

             salt '*' vboxmanage.list_nodes_min

   salt.modules.vboxmanage.list_ostypes()
          List the available OS Types

          CLI Example:

             salt '*' vboxmanage.list_ostypes

   salt.modules.vboxmanage.register(filename)
          Register a VM

          CLI Example:

             salt '*' vboxmanage.register my_vm_filename

   salt.modules.vboxmanage.start(name)
          Start a VM

          CLI Example:

             salt '*' vboxmanage.start my_vm

   salt.modules.vboxmanage.stop(name)
          Stop a VM

          CLI Example:

             salt '*' vboxmanage.stop my_vm

   salt.modules.vboxmanage.unregister(name, delete=False)
          Unregister a VM

          CLI Example:

             salt '*' vboxmanage.unregister my_vm_filename

   salt.modules.vboxmanage.vboxcmd()
          Return the location of the VBoxManage command

          CLI Example:

             salt '*' vboxmanage.vboxcmd

   salt.modules.victorops
   Support for VictorOps

   New in version 2015.8.0.

   Requires an api_key in /etc/salt/minion:

   salt.modules.victorops.create_event(message_type=None,
   routing_key='everybody', **kwargs)
          Create an event in VictorOps. Designed for use in states.

          The following parameters are required:

          Parameters
                 message_type  --  One  of  the  following  values:  INFO,
                 WARNING, ACKNOWLEDGEMENT, CRITICAL, RECOVERY.

          The following parameters are optional:

          Parameters

                 * routing_key  --  The  key  for where messages should be
                   routed. By default, sent to 'everyone' route.

                 * entity_id --  The  name  of  alerting  entity.  If  not
                   provided, a random name will be assigned.

                 * timestamp  --  Timestamp  of the alert in seconds since
                   epoch. Defaults to the time the alert  is  received  at
                   VictorOps.

          :param   timestamp_fmt              The   date  format  for  the
          timestamp parameter.

          Parameters

                 * state_start_time -- The time this  entity  entered  its
                   current  state  (seconds  since epoch). Defaults to the
                   time alert is received.

                 * state_start_time_fmt  --  The  date  format   for   the
                   timestamp parameter.

                 * state_message -- Any additional status information from
                   the alert item.

                 * entity_is_host -- Used within VictorOps to  select  the
                   appropriate display format for the incident.

                 * entity_display_name -- Used within VictorOps to display
                   a human-readable name for the entity.

                 * ack_message  --  A  user  entered   comment   for   the
                   acknowledgment.

                 * ack_author -- The user that acknowledged the incident.

          Returns
                 A  dictionary  with  result,  entity_id,  and  message if
                 result was failure.

          CLI Example:

             salt myminion victorops.create_event message_type='CRITICAL' routing_key='everyone'                  entity_id='hostname/diskspace'

             salt myminion victorops.create_event message_type='ACKNOWLEDGEMENT' routing_key='everyone'                  entity_id='hostname/diskspace' ack_message='Acknowledged' ack_author='username'

             salt myminion victorops.create_event message_type='RECOVERY' routing_key='everyone'                  entity_id='hostname/diskspace'

          The following parameters are required:
                 message_type

   salt.modules.virt
   Work with virtual machines managed by libvirt

   depends
          libvirt Python module

   salt.modules.virt.cpu_baseline(full=False,            migratable=False,
   out='libvirt')
          Return the optimal 'custom' CPU baseline config for VM's on this
          minion

          New in version 2016.3.0.

          Parameters

                 * full -- Return all CPU features rather than the ones on
                   top of the closest CPU model

                 * migratable   --   Exclude   CPU   features   that   are
                   unmigratable (libvirt 2.13+)

                 * out --  'libvirt'  (default)  for  usable  libvirt  XML
                   definition, 'salt' for nice dict

          CLI Example:

             salt '*' virt.cpu_baseline

   salt.modules.virt.create(domain)
          Deprecated since version 2016.3.0: Use start() instead.

          Start a defined domain

          CLI Example:

             salt '*' virt.create <domain>

   salt.modules.virt.create_xml_path(path)
          Start a domain based on the XML-file path passed to the function

          CLI Example:

             salt '*' virt.create_xml_path <path to XML file on the node>

   salt.modules.virt.create_xml_str(xml)
          Start a domain based on the XML passed to the function

          CLI Example:

             salt '*' virt.create_xml_str <XML in string format>

   salt.modules.virt.ctrl_alt_del(vm_)
          Sends CTRL+ALT+DEL to a VM

          CLI Example:

             salt '*' virt.ctrl_alt_del <domain>

   salt.modules.virt.define_vol_xml_path(path)
          Define  a  volume  based  on  the  XML-file  path  passed to the
          function

          CLI Example:

             salt '*' virt.define_vol_xml_path <path to XML file on the node>

   salt.modules.virt.define_vol_xml_str(xml)
          Define a volume based on the XML passed to the function

          CLI Example:

             salt '*' virt.define_vol_xml_str <XML in string format>

   salt.modules.virt.define_xml_path(path)
          Define a domain  based  on  the  XML-file  path  passed  to  the
          function

          CLI Example:

             salt '*' virt.define_xml_path <path to XML file on the node>

   salt.modules.virt.define_xml_str(xml)
          Define a domain based on the XML passed to the function

          CLI Example:

             salt '*' virt.define_xml_str <XML in string format>

   salt.modules.virt.delete_snapshots(name, *names, **kwargs)
          Delete one or more snapshots of the given VM.

          Options:

          * all:  Remove  all  snapshots.  Values:  True or False (default
            False).

          New in version 2016.3.0.

          CLI Example:

             salt '*' virt.delete_snapshots <domain> all=True
             salt '*' virt.delete_snapshots <domain> <snapshot>
             salt '*' virt.delete_snapshots <domain> <snapshot1> <snapshot2> ...

   salt.modules.virt.destroy(domain)
          Deprecated since version 2016.3.0: Use stop() instead.

          Power off a defined domain

          CLI Example:

             salt '*' virt.destroy <domain>

   salt.modules.virt.freecpu()
          Return an int representing the number  of  unallocated  cpus  on
          this hypervisor

          CLI Example:

             salt '*' virt.freecpu

   salt.modules.virt.freemem()
          Return an int representing the amount of memory (in MB) that has
          not been given to virtual machines on this node

          CLI Example:

             salt '*' virt.freemem

   salt.modules.virt.full_info()
          Return the node_info, vm_info and freemem

          CLI Example:

             salt '*' virt.full_info

   salt.modules.virt.get_disks(vm_)
          Return the disks of a named vm

          CLI Example:

             salt '*' virt.get_disks <domain>

   salt.modules.virt.get_graphics(vm_)
          Returns the information on vnc for a given vm

          CLI Example:

             salt '*' virt.get_graphics <domain>

   salt.modules.virt.get_macs(vm_)
          Return a list off MAC addresses from the named vm

          CLI Example:

             salt '*' virt.get_macs <domain>

   salt.modules.virt.get_nics(vm_)
          Return info about the network interfaces of a named vm

          CLI Example:

             salt '*' virt.get_nics <domain>

   salt.modules.virt.get_profiles(hypervisor=None)
          Return the virt profiles for hypervisor.

          Currently there are profiles for:

             * nic

             * disk

          CLI Example:

             salt '*' virt.get_profiles
             salt '*' virt.get_profiles hypervisor=esxi

   salt.modules.virt.get_xml(vm_)
          Returns the XML for a given vm

          CLI Example:

             salt '*' virt.get_xml <domain>

   salt.modules.virt.init(name,  cpu,  mem,   image=None,   nic='default',
   hypervisor='kvm',     start=True,    disk='default',    saltenv='base',
   seed=True,       install=True,       pub_key=None,       priv_key=None,
   seed_cmd='seed.apply', enable_vnc=False, **kwargs)
          Initialize a new vm

          CLI Example:

             salt 'hypervisor' virt.init vm_name 4 512 salt://path/to/image.raw
             salt 'hypervisor' virt.init vm_name 4 512 nic=profile disk=profile

   salt.modules.virt.is_hyper()
          Returns  a  bool whether or not this node is a hypervisor of any
          kind

          CLI Example:

             salt '*' virt.is_hyper

   salt.modules.virt.is_kvm_hyper()
          Returns a bool whether or not this node is a KVM hypervisor

          CLI Example:

             salt '*' virt.is_kvm_hyper

   salt.modules.virt.is_xen_hyper()
          Returns a bool whether or not this node is a XEN hypervisor

          CLI Example:

             salt '*' virt.is_xen_hyper

   salt.modules.virt.list_active_vms()
          Return a list of names for active virtual machine on the minion

          CLI Example:

             salt '*' virt.list_active_vms

   salt.modules.virt.list_domains()
          Return a list of available domains.

          CLI Example:

             salt '*' virt.list_domains

   salt.modules.virt.list_inactive_vms()
          Return a list of names  for  inactive  virtual  machine  on  the
          minion

          CLI Example:

             salt '*' virt.list_inactive_vms

   salt.modules.virt.list_snapshots(domain=None)
          List available snapshots for certain vm or for all.

          New in version 2016.3.0.

          CLI Example:

             salt '*' virt.list_snapshots
             salt '*' virt.list_snapshots <domain>

   salt.modules.virt.list_vms()
          Deprecated since version 2016.3.0: Use list_domains() instead.

          List all virtual machines.

          CLI Example:

             salt '*' virt.list_vms <domain>

   salt.modules.virt.migrate(vm_, target, ssh=False)
          Shared storage migration

          CLI Example:

             salt '*' virt.migrate <domain> <target hypervisor>

   salt.modules.virt.migrate_non_shared(vm_, target, ssh=False)
          Attempt to execute non-shared storage "all" migration

          CLI Example:

             salt '*' virt.migrate_non_shared <vm name> <target hypervisor>

   salt.modules.virt.migrate_non_shared_inc(vm_, target, ssh=False)
          Attempt to execute non-shared storage "all" migration

          CLI Example:

             salt '*' virt.migrate_non_shared_inc <vm name> <target hypervisor>

   salt.modules.virt.node_info()
          Return a dict with information about this node

          CLI Example:

             salt '*' virt.node_info

   salt.modules.virt.pause(vm_)
          Pause the named vm

          CLI Example:

             salt '*' virt.pause <domain>

   salt.modules.virt.purge(vm_, dirs=False)
          Recursively  destroy and delete a virtual machine, pass True for
          dir's to also delete  the  directories  containing  the  virtual
          machine disk images - USE WITH EXTREME CAUTION!

          CLI Example:

             salt '*' virt.purge <domain>

   salt.modules.virt.reboot(name)
          Reboot a domain via ACPI request

          CLI Example:

             salt '*' virt.reboot <domain>

   salt.modules.virt.reset(vm_)
          Reset a VM by emulating the reset button on a physical machine

          CLI Example:

             salt '*' virt.reset <domain>

   salt.modules.virt.resume(vm_)
          Resume the named vm

          CLI Example:

             salt '*' virt.resume <domain>

   salt.modules.virt.revert_snapshot(name, snapshot=None, cleanup=False)
          Revert  snapshot  to the previous from current (if available) or
          to the specific.

          Options:

          * cleanup: Remove all newer  than  reverted  snapshots.  Values:
            True or False (default False).

          New in version 2016.3.0.

          CLI Example:

             salt '*' virt.revert <domain>
             salt '*' virt.revert <domain> <snapshot>

   salt.modules.virt.seed_non_shared_migrate(disks, force=False)
          Non  shared  migration requires that the disks be present on the
          migration destination,  pass  the  disks  information  via  this
          function,  to  the  migration  destination  before executing the
          migration.

          CLI Example:

             salt '*' virt.seed_non_shared_migrate <disks>

   salt.modules.virt.set_autostart(vm_, state='on')
          Set the autostart flag on a VM so that the VM  will  start  with
          the host system on reboot.

          CLI Example:

             salt "*" virt.set_autostart <domain> <on | off>

   salt.modules.virt.setmem(vm_, memory, config=False)
          Changes  the  amount  of  memory allocated to VM. The VM must be
          shutdown for this to work.

          memory is to be specified in MB If config is True  then  we  ask
          libvirt to modify the config as well

          CLI Example:

             salt '*' virt.setmem <domain> <size>
             salt '*' virt.setmem my_domain 768

   salt.modules.virt.setvcpus(vm_, vcpus, config=False)
          Changes  the  amount  of  vcpus  allocated to VM. The VM must be
          shutdown for this to work.

          vcpus is an int representing the number to be assigned If config
          is True then we ask libvirt to modify the config as well

          CLI Example:

             salt '*' virt.setvcpus <domain> <amount>
             salt '*' virt.setvcpus my_domain 4

   salt.modules.virt.shutdown(vm_)
          Send a soft shutdown signal to the named vm

          CLI Example:

             salt '*' virt.shutdown <domain>

   salt.modules.virt.snapshot(domain, name=None, suffix=None)
          Create a snapshot of a VM.

          Options:

          *

            name:  Name of the snapshot. If the name is omitted, then will
            be used original domain name with
                   ISO 8601 time as a suffix.

          *

            suffix: Add suffix for the new name. Useful in  states,  where
            such snapshots
                   can be distinguished from manually created.

          New in version 2016.3.0.

          CLI Example:

             salt '*' virt.snapshot <domain>

   salt.modules.virt.start(name)
          Start a defined domain

          CLI Example:

             salt '*' virt.start <domain>

   salt.modules.virt.stop(name)
          Hard  power  down  the  virtual  machine,  this is equivalent to
          pulling the power.

          CLI Example:

             salt '*' virt.stop <domain>

   salt.modules.virt.undefine(vm_)
          Remove a defined vm, this does not  purge  the  virtual  machine
          image, and this only works if the vm is powered down

          CLI Example:

             salt '*' virt.undefine <domain>

   salt.modules.virt.virt_type()
          Returns the virtual machine type as a string

          CLI Example:

             salt '*' virt.virt_type

   salt.modules.virt.vm_cputime(vm_=None)
          Return cputime used by the vms on this hyper in a list of dicts:

             [
                 'your-vm': {
                     'cputime' <int>
                     'cputime_percent' <int>
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_cputime

   salt.modules.virt.vm_diskstats(vm_=None)
          Return disk usage counters used by the vms on this  hyper  in  a
          list of dicts:

             [
                 'your-vm': {
                     'rd_req'   : 0,
                     'rd_bytes' : 0,
                     'wr_req'   : 0,
                     'wr_bytes' : 0,
                     'errs'     : 0
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_blockstats

   salt.modules.virt.vm_info(vm_=None)
          Return detailed information about the vms on  this  hyper  in  a
          list of dicts:

             [
                 'your-vm': {
                     'cpu': <int>,
                     'maxMem': <int>,
                     'mem': <int>,
                     'state': '<state>',
                     'cputime' <int>
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_info

   salt.modules.virt.vm_netstats(vm_=None)
          Return combined network counters used by the vms on  this  hyper
          in a list of dicts:

             [
                 'your-vm': {
                     'rx_bytes'   : 0,
                     'rx_packets' : 0,
                     'rx_errs'    : 0,
                     'rx_drop'    : 0,
                     'tx_bytes'   : 0,
                     'tx_packets' : 0,
                     'tx_errs'    : 0,
                     'tx_drop'    : 0
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_netstats

   salt.modules.virt.vm_state(vm_=None)
          Return list of all the vms and their state.

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_state <domain>

   salt.modules.virtualenv
   Create virtualenv environments.

   New in version 0.17.0.

   salt.modules.virtualenv_mod.create(path,                 venv_bin=None,
   system_site_packages=False, distribute=False, clear=False, python=None,
   extra_search_dir=None,   never_download=None,  prompt=None,  pip=False,
   symlinks=None, upgrade=None, user=None, use_vt=False, saltenv='base')
          Create a virtualenv

          path   The path to the virtualenv to be created

          venv_bin
                 The name (and optionally path) of the virtualenv command.
                 This  can  also be set globally in the minion config file
                 as virtualenv.venv_bin.  Defaults to virtualenv.

          system_site_packages
                 False Passthrough argument given to virtualenv or pyvenv

          distribute
                 False Passthrough argument given to virtualenv

          pip    False Install pip after creating a  virtual  environment.
                 Implies distribute=True

          clear  False Passthrough argument given to virtualenv or pyvenv

          python None (default) Passthrough argument given to virtualenv

          extra_search_dir
                 None (default) Passthrough argument given to virtualenv

          never_download
                 None  (default)  Passthrough argument given to virtualenv
                 if True

          prompt None (default) Passthrough argument given  to  virtualenv
                 if not None

          symlinks
                 None Passthrough argument given to pyvenv if True

          upgrade
                 None Passthrough argument given to pyvenv if True

          user   None Set ownership for the virtualenv

          runas  None Set ownership for the virtualenv

                 Deprecated  since  version  2014.1.0: user should be used
                 instead

          use_vt False  Use  VT  terminal  emulation  (see  output   while
                 installing)

                 New in version 2015.5.0.

          saltenv
                 'base'  Specify  a  different  environment.  The  default
                 environment is base.

                 New in version 2014.1.0.

          NOTE:
             The runas argument is deprecated as of 2014.1.0. user  should
             be used instead.

          CLI Example:

             salt '*' virtualenv.create /path/to/new/virtualenv

   salt.modules.virtualenv_mod.get_distribution_path(venv, distribution)
          Return the path to a distribution installed inside a virtualenv

          New in version 2016.3.0.

          venv   Path to the virtualenv.

          distribution
                 Name  of  the  distribution.  Note,  all non-alphanumeric
                 characters will be converted to dashes.

          CLI Example:

             salt '*' virtualenv.get_distribution_path /path/to/my/venv my_distribution

   salt.modules.virtualenv_mod.get_resource_content(venv,
   package_or_requirement=None,      resource_name=None,     package=None,
   resource=None)
          Return the content of a  package  resource  installed  inside  a
          virtualenv

          venv   Path to the virtualenv

          package
                 Name of the package in which the resource resides

                 New in version 2016.3.0.

          package_or_requirement
                 Name of the package in which the resource resides

                 Deprecated since version Nitrogen: Use package instead.

          resource
                 Name  of  the  resource  of  which  the  content is to be
                 returned

                 New in version 2016.3.0.

          resource_name
                 Name of the resource  of  which  the  content  is  to  be
                 returned

                 Deprecated since version Nitrogen.

          New in version 2015.5.0.

          venv   Path to the virtualenv.

          package_or_requirement
                 Name of the package where the resource resides in.

          resource_name
                 Name  of  the  resource  of  which  the  content is to be
                 returned.

          CLI Example:

             salt '*' virtualenv.get_resource_content /path/to/my/venv my_package my/resource.xml

   salt.modules.virtualenv_mod.get_resource_path(venv,
   package_or_requirement=None,      resource_name=None,     package=None,
   resource=None)
          Return the  path  to  a  package  resource  installed  inside  a
          virtualenv

          venv   Path to the virtualenv

          package
                 Name of the package in which the resource resides

                 New in version 2016.3.0.

          package_or_requirement
                 Name of the package in which the resource resides

                 Deprecated since version Nitrogen: Use package instead.

          resource
                 Name of the resource of which the path is to be returned

                 New in version 2016.3.0.

          resource_name
                 Name of the resource of which the path is to be returned

                 Deprecated since version Nitrogen.

          New in version 2015.5.0.

          venv   Path to the virtualenv.

          package_or_requirement
                 Name of the package where the resource resides in.

          resource_name
                 Name of the resource of which the path is to be returned.

          CLI Example:

             salt '*' virtualenv.get_resource_path /path/to/my/venv my_package my/resource.xml

   salt.modules.virtualenv_mod.get_site_packages(venv)
          Return the path to the site-packages directory of a virtualenv

          venv   Path to the virtualenv.

          CLI Example:

             salt '*' virtualenv.get_site_packages /path/to/my/venv

   salt.modules.vsphere
   Manage VMware vCenter servers and ESXi hosts.

   New in version 2015.8.4.

   Dependencies
   * pyVmomi Python Module

   * ESXCLI

   pyVmomi
   PyVmomi can be installed via pip:

      pip install pyVmomi

   NOTE:
      Version  6.0 of pyVmomi has some problems with SSL error handling on
      certain versions of Python. If using version 6.0 of pyVmomi,  Python
      2.6,  Python  2.7.9,  or  newer  must  be present. This is due to an
      upstream dependency in pyVmomi 6.0 that is not supported  in  Python
      versions  2.7  to  2.7.8.  If  the  version  of Python is not in the
      supported range, you will need to  install  an  earlier  version  of
      pyVmomi. See Issue #29537 for more information.

   Based  on the note above, to install an earlier version of pyVmomi than
   the version currently listed in PyPi, run the following:

      pip install pyVmomi==5.5.0.2014.1.1

   The 5.5.0.2014.1.1 is a known stable version that this original vSphere
   Execution Module was developed against.

   ESXCLI
   Currently, about a third of the functions used in the vSphere Execution
   Module require the ESXCLI package be installed on the  machine  running
   the Proxy Minion process.

   The  ESXCLI  package  is also referred to as the VMware vSphere CLI, or
   vCLI.  VMware  provides  vCLI  package  installation  instructions  for
   vSphere 5.5 and vSphere 6.0.

   Once all of the required dependencies are in place and the vCLI package
   is installed, you can check to see if you can connect to your ESXi host
   or vCenter server by running the following command:

      esxcli -s <host-location> -u <username> -p <password> system syslog config get

   If  the connection was successful, ESXCLI was successfully installed on
   your system.  You should see output related to the ESXi  host's  syslog
   configuration.

   NOTE:
      Be aware that some functionality in this execution module may depend
      on the type of license attached to a vCenter Server or ESXi host(s).

      For example, certain  services  are  only  available  to  manipulate
      service  state  or  policies  with  a  VMware  vSphere Enterprise or
      Enterprise Plus license, while others are available with a  Standard
      license.  The  ntpd  service  is  restricted  to  an Enterprise Plus
      license, while ssh is available via the Standard license.

      Please see the vSphere Comparison page for more information.

   About
   This execution module was designed to be  able  to  handle  connections
   both  to  a vCenter Server, as well as to an ESXi host. It utilizes the
   pyVmomi Python library and the ESXCLI package to run  remote  execution
   functions against either the defined vCenter server or the ESXi host.

   Whether  or  not  the function runs against a vCenter Server or an ESXi
   host depends entirely upon the arguments passed into the function. Each
   function  requires  a  host  location,  username,  and password. If the
   credentials provided apply to a vCenter Server, then the function  will
   be  run  against  the  vCenter  Server. For example, when listing hosts
   using vCenter credentials, you'll get a list of hosts  associated  with
   that vCenter Server:

      # salt my-minion vsphere.list_hosts <vcenter-ip> <vcenter-user> <vcenter-password>
      my-minion:
      - esxi-1.example.com
      - esxi-2.example.com

   However,  some functions should be used against ESXi hosts, not vCenter
   Servers.  Functionality such  as  getting  a  host's  coredump  network
   configuration  should  be  performed  against  a host and not a vCenter
   server. If the authentication information you're  using  is  against  a
   vCenter server and not an ESXi host, you can provide the host name that
   is associated with the vCenter server in the command, as a list,  using
   the host_names or esxi_host kwarg. For example:

      # salt my-minion vsphere.get_coredump_network_config <vcenter-ip> <vcenter-user>         <vcenter-password> esxi_hosts='[esxi-1.example.com, esxi-2.example.com]'
      my-minion:
      ----------
          esxi-1.example.com:
              ----------
              Coredump Config:
                  ----------
                  enabled:
                      False
          esxi-2.example.com:
              ----------
              Coredump Config:
                  ----------
                  enabled:
                      True
                  host_vnic:
                      vmk0
                  ip:
                      coredump-location.example.com
                  port:
                      6500

   You  can  also  use  these  functions  against an ESXi host directly by
   establishing a connection to an ESXi host using  the  host's  location,
   username, and password. If ESXi connection credentials are used instead
   of vCenter credentials, the host_names and esxi_hosts arguments are not
   needed.

      # salt my-minion vsphere.get_coredump_network_config esxi-1.example.com root <host-password>
      local:
      ----------
          10.4.28.150:
              ----------
              Coredump Config:
                  ----------
                  enabled:
                      True
                  host_vnic:
                      vmk0
                  ip:
                      coredump-location.example.com
                  port:
                      6500

   salt.modules.vsphere.add_host_to_dvs(host,      username,     password,
   vmknic_name,     vmnic_name,      dvs_name,      target_portgroup_name,
   uplink_portgroup_name, protocol=None, port=None, host_names=None)
          Adds  an  ESXi  host to a vSphere Distributed Virtual Switch and
          migrates the desired adapters  to  the  DVS  from  the  standard
          switch.

          host   The location of the vCenter server.

          username
                 The username used to login to the vCenter server.

          password
                 The password used to login to the vCenter server.

          vmknic_name
                 The name of the virtual NIC to migrate.

          vmnic_name
                 The name of the physical NIC to migrate.

          dvs_name
                 The name of the Distributed Virtual Switch.

          target_portgroup_name
                 The name of the distributed portgroup in which to migrate
                 the virtual NIC.

          uplink_portgroup_name
                 The name of the uplink portgroup in which to migrate  the
                 physical NIC.

          protocol
                 Optionally  set  to  alternate  protocol  if  the vCenter
                 server  or  ESX/ESXi  host  is  not  using  the   default
                 protocol. Default protocol is https.

          port   Optionally set to alternate port if the vCenter server or
                 ESX/ESXi host is not using the default port. Default port
                 is 443.

          host_names:
                 An array of VMware host names to migrate

          CLI Example:

             salt some_host vsphere.add_host_to_dvs host='vsphere.corp.com'
                 username='[email protected]' password='vsphere_password'
                 vmknic_name='vmk0' vmnic_name='vnmic0' dvs_name='DSwitch'
                 target_portgroup_name='DPortGroup' uplink_portgroup_name='DSwitch1-DVUplinks-181'
                 protocol='https' port='443', host_names="['esxi1.corp.com','esxi2.corp.com','esxi3.corp.com']"

          Return Example:

             somehost:
                 ----------
                 esxi1.corp.com:
                     ----------
                     dvs:
                         DSwitch
                     portgroup:
                         DPortGroup
                     status:
                         True
                     uplink:
                         DSwitch-DVUplinks-181
                     vmknic:
                         vmk0
                     vmnic:
                         vmnic0
                 esxi2.corp.com:
                     ----------
                     dvs:
                         DSwitch
                     portgroup:
                         DPortGroup
                     status:
                         True
                     uplink:
                         DSwitch-DVUplinks-181
                     vmknic:
                         vmk0
                     vmnic:
                         vmnic0
                 esxi3.corp.com:
                     ----------
                     dvs:
                         DSwitch
                     portgroup:
                         DPortGroup
                     status:
                         True
                     uplink:
                         DSwitch-DVUplinks-181
                     vmknic:
                         vmk0
                     vmnic:
                         vmnic0
                 message:
                 success:
                     True

          This  was  very  difficult  to  figure  out.   VMware's  PyVmomi
          documentation at

          https://github.com/vmware/pyvmomi/blob/master/docs/vim/DistributedVirtualSwitch.rst
          (which   is   a   copy   of  the  official  documentation  here:
          https://www.vmware.com/support/developer/converter-sdk/conv60_apireference/vim.DistributedVirtualSwitch.html)

          says  to create the DVS, create distributed portgroups, and then
          add the host to the DVS specifying which physical NIC to use  as
          the port backing.  However, if the physical NIC is in use as the
          only link from the host to  vSphere,  this  will  fail  with  an
          unhelpful "busy" error.

          There   is,   however,   a  Powershell  PowerCLI  cmdlet  called
          Add-VDSwitchPhysicalNetworkAdapter that does what  we  want.   I
          used  Onyx  (https://labs.vmware.com/flings/onyx)  to  sniff the
          SOAP stream from Powershell to our vSphere server and  got  this
          snippet out:

          <UpdateNetworkConfig xmlns="urn:vim25">
                 <_this type="HostNetworkSystem">networkSystem-187</_this>
                 <config>

                    <vswitch>
                           <changeOperation>edit</changeOperation>
                           <name>vSwitch0</name> <spec>
                               <numPorts>7812</numPorts>

                           </spec>

                    </vswitch> <proxySwitch>
                        <changeOperation>edit</changeOperation>   <uuid>73
                        a4 05 50 b0  d2  7e  b9-38  80  5d  24  65  8f  da
                        70</uuid>              <spec>             <backing
                        xsi:type="DistributedVirtualSwitchHostMemberPnicBacking">
                           <pnicSpec><pnicDevice>vmnic0</pnicDevice></pnicSpec>

                        </backing> </spec>

                    </proxySwitch> <portgroup>
                        <changeOperation>remove</changeOperation> <spec>
                           <name>Management
                           Network</name><vlanId>-1</vlanId><vswitchName
                           /><policy />

                        </spec>

                    </portgroup> <vnic>
                        <changeOperation>edit</changeOperation>
                        <device>vmk0</device> <portgroup /> <spec>

                           <distributedVirtualPort>
                                  <switchUuid>73  a4  05 50 b0 d2 7e b9-38
                                  80  5d  24  65  8f  da   70</switchUuid>
                                  <portgroupKey>dvportgroup-191</portgroupKey>

                           </distributedVirtualPort>

                        </spec>

                    </vnic>

                 </config> <changeMode>modify</changeMode>

          </UpdateNetworkConfig>

          The SOAP API maps closely to  PyVmomi,  so  from  there  it  was
          (relatively) easy to figure out what Python to write.

   salt.modules.vsphere.coredump_network_enable(host,  username, password,
   enabled, protocol=None, port=None, esxi_hosts=None)
          Enable or disable ESXi core dump  collection.  Returns  True  if
          coredump  is  enabled  and  returns  False  if  core dump is not
          enabled. If there was an error, the  error  will  be  the  value
          printed in the Error key dictionary for the given host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          enabled
                 Python True or False to enable or disable coredumps.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.coredump_network_enable my.esxi.host root bad-password True

             # Used for connecting to a vCenter Server
             salt '*' vsphere.coredump_network_enable my.vcenter.location root bad-password True             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.enable_firewall_ruleset(host, username,  password,
   ruleset_enable,       ruleset_name,      protocol=None,      port=None,
   esxi_hosts=None)
          Enable or disable an ESXi firewall rule set.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          ruleset_enable
                 True to enable the ruleset, false to disable.

          ruleset_name
                 Name of ruleset to target.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 A standard cmd.run_all dictionary, per host.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.enable_firewall_ruleset my.esxi.host root bad-password True 'syslog'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.enable_firewall_ruleset my.vcenter.location root bad-password True 'syslog'             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.esxcli_cmd(cmd_str,    host=None,   username=None,
   password=None, protocol=None, port=None, esxi_hosts=None)
          Run an ESXCLI command directly on the host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          cmd_str
                 The ESXCLI command to run. Note: This should not  include
                 the -s, -u, -p, -h, --protocol, or --portnumber arguments
                 that are frequently  passed  when  using  a  bare  ESXCLI
                 command  from  the  command  line.   Those  arguments are
                 handled by this function via the other args and kwargs.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.esxcli_cmd my.esxi.host root bad-password             'system coredump network get'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.esxcli_cmd my.vcenter.location root bad-password             'system coredump network get' esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_coredump_network_config(host,        username,
   password, protocol=None, port=None, esxi_hosts=None)
          Retrieve information on ESXi or vCenter network dump  collection
          and format it into a dictionary.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 A dictionary  with  the  network  configuration,  or,  if
                 getting  the  network  config  failed, a an error message
                 retrieved from the standard cmd.run_all  dictionary,  per
                 host.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.get_coredump_network_config my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_coredump_network_config my.vcenter.location root bad-password             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_firewall_status(host,    username,   password,
   protocol=None, port=None, esxi_hosts=None)
          Show status of all firewall rule sets.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 Nested  dictionary  with  two  toplevel keys rulesets and
                 success success will be True or False depending on  query
                 success   rulesets  will  list  the  rulesets  and  their
                 statuses if success was true, per host.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.get_firewall_status my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_firewall_status my.vcenter.location root bad-password             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_host_datetime(host,    username,     password,
   protocol=None, port=None, host_names=None)
          Get  the  date/time  information  for  a  given  host or list of
          host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to get date/time information.

                 If  host_names is not provided, the date/time information
                 will be retrieved for the host location instead. This  is
                 useful  for  when service instance connection information
                 is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_host_datetime my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_host_datetime my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_ntp_config(host,      username,      password,
   protocol=None, port=None, host_names=None)
          Get  the  NTP configuration information for a given host or list
          of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to get ntp configuration information.

                 If host_names is not provided, the NTP configuration will
                 be retrieved for  the  host  location  instead.  This  is
                 useful  for  when service instance connection information
                 is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_ntp_config my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_ntp_config my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_service_policy(host,    username,    password,
   service_name, protocol=None, port=None, host_names=None)
          Get the service name's policy for a given host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The name of the service for which to retrieve the policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to get service policy information.

                 If   host_names  is  not  provided,  the  service  policy
                 information will  be  retrieved  for  the  host  location
                 instead.   This  is  useful  for  when  service  instance
                 connection information is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_service_policy my.esxi.host root bad-password 'ssh'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_service_policy my.vcenter.location root bad-password 'ntpd'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_service_running(host,   username,    password,
   service_name, protocol=None, port=None, host_names=None)
          Get the service name's running state for a given host or list of
          hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The name of the service for which to retrieve the policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the  host_names  argument is required to tell vCenter the
                 hosts for which to get the service's running state.

                 If host_names is  not  provided,  the  service's  running
                 state  will  be  retrieved for the host location instead.
                 This is  useful  for  when  service  instance  connection
                 information is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_service_running my.esxi.host root bad-password 'ssh'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_service_running my.vcenter.location root bad-password 'ntpd'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_ssh_key(host,        username,       password,
   protocol=None, port=None, certificate_verify=False)
          Retrieve the authorized_keys entry for root.  This function only
          works for ESXi, not vCenter.

          Parameters

                 * host -- The location of the ESXi Host

                 * username -- Username to connect as

                 * password -- Password for the ESXi web endpoint

                 * protocol  --  defaults  to https, can be http if ssl is
                   disabled on ESXi

                 * port -- defaults to 443 for https

                 * certificate_verify -- If  true  require  that  the  SSL
                   connection present a valid certificate

          Returns
                 True if upload is successful

          CLI Example:

             salt '*' vsphere.get_ssh_key my.esxi.host root bad-password certificate_verify=True

   salt.modules.vsphere.get_syslog_config(host,     username,    password,
   protocol=None, port=None, esxi_hosts=None)
          Retrieve the syslog configuration.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 Dictionary  with  keys  and  values  corresponding to the
                 syslog configuration, per host.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.get_syslog_config my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_syslog_config my.vcenter.location root bad-password             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_vmotion_enabled(host,   username,    password,
   protocol=None, port=None, host_names=None)
          Get  the  VMotion  enabled  status for a given host or a list of
          host_names. Returns True if VMotion is enabled, False if  it  is
          not enabled.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the host_names argument is required to tell vCenter which
                 hosts to check if VMotion is enabled.

                 If host_names is not provided, the VMotion status will be
                 retrieved  for  the host location instead. This is useful
                 for when service instance connection information is  used
                 for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_vmotion_enabled my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_vmotion_enabled my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_vsan_eligible_disks(host,  username, password,
   protocol=None, port=None, host_names=None)
          Returns a list of VSAN-eligible disks for a given host  or  list
          of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the host_names argument is required to tell vCenter which
                 hosts to check if any VSAN-eligible disks are available.

                 If host_names is not provided,  the  VSAN-eligible  disks
                 will  be retrieved for the host location instead. This is
                 useful for when service instance  connection  information
                 is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_vsan_eligible_disks my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_vsan_eligible_disks my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.get_vsan_enabled(host,     username,     password,
   protocol=None, port=None, host_names=None)
          Get the VSAN enabled status for  a  given  host  or  a  list  of
          host_names.  Returns True if VSAN is enabled, False if it is not
          enabled, and None if a VSAN Host Config is unset, per host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell vCenter which
                 hosts to check if VSAN enabled.

                 If  host_names  is  not provided, the VSAN status will be
                 retrieved for the host location instead. This  is  useful
                 for  when service instance connection information is used
                 for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.get_vsan_enabled my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.get_vsan_enabled my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.list_clusters(host,      username,       password,
   protocol=None, port=None)
          Returns a list of clusters for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_clusters 1.2.3.4 root bad-password

   salt.modules.vsphere.list_datacenters(host,     username,     password,
   protocol=None, port=None)
          Returns a list of datacenters for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_datacenters 1.2.3.4 root bad-password

   salt.modules.vsphere.list_datastore_clusters(host, username,  password,
   protocol=None, port=None)
          Returns a list of datastore clusters for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_datastore_clusters 1.2.3.4 root bad-password

   salt.modules.vsphere.list_datastores(host,      username,     password,
   protocol=None, port=None)
          Returns a list of datastores for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_datastores 1.2.3.4 root bad-password

   salt.modules.vsphere.list_dvs(host, username, password,  protocol=None,
   port=None)
          Returns  a  list  of  distributed  virtual  switches for the the
          specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_dvs 1.2.3.4 root bad-password

   salt.modules.vsphere.list_folders(host,       username,       password,
   protocol=None, port=None)
          Returns a list of folders for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_folders 1.2.3.4 root bad-password

   salt.modules.vsphere.list_hosts(host,        username,        password,
   protocol=None, port=None)
          Returns  a  list  of  hosts  for  the   the   specified   VMware
          environment.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_hosts 1.2.3.4 root bad-password

   salt.modules.vsphere.list_networks(host,       username,      password,
   protocol=None, port=None)
          Returns a list of networks for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_networks 1.2.3.4 root bad-password

   salt.modules.vsphere.list_non_ssds(host,      username,       password,
   protocol=None, port=None, host_names=None)
          Returns  a  list  of Non-SSD disks for the given host or list of
          host_names.

          NOTE:
             In the pyVmomi StorageSystem, ScsiDisks may, or may not  have
             an  ssd  attribute.  This attribute indicates if the ScsiDisk
             is SSD backed. As this option is optional, if a relevant disk
             in the StorageSystem does not have ssd = true, it will end up
             in the non_ssds list here.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to retrieve Non-SSD disks.

                 If  host_names  is  not  provided,  Non-SSD disks will be
                 retrieved for the host location instead. This  is  useful
                 for  when service instance connection information is used
                 for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.list_non_ssds my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.list_non_ssds my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.list_resourcepools(host,    username,    password,
   protocol=None, port=None)
          Returns a list of resource pools for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_resourcepools 1.2.3.4 root bad-password

   salt.modules.vsphere.list_ssds(host, username, password, protocol=None,
   port=None, host_names=None)
          Returns a list of SSDs for the given host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to retrieve SSDs.

                 If host_names is not provided, SSDs will be retrieved for
                 the host  location  instead.  This  is  useful  for  when
                 service  instance  connection  information  is used for a
                 single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.list_ssds my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.list_ssds my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.list_vapps(host,        username,        password,
   protocol=None, port=None)
          Returns a list of vApps for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_vapps 1.2.3.4 root bad-password

   salt.modules.vsphere.list_vms(host,  username, password, protocol=None,
   port=None)
          Returns a list of VMs for the the specified host.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

             salt '*' vsphere.list_vms 1.2.3.4 root bad-password

   salt.modules.vsphere.reset_syslog_config(host,   username,    password,
   protocol=None, port=None, syslog_config=None, esxi_hosts=None)
          Reset the syslog service to its default settings.

          Valid  syslog_config  values are logdir, loghost, logdir-unique,
          default-rotate, default-size, default-timeout, or all for all of
          these.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          syslog_config
                 List    of   parameters   to   reset,   provided   as   a
                 comma-delimited string, or  'all'  to  reset  all  syslog
                 configuration parameters. Required.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 Dictionary  with  a  top-level  key  of  'success'  which
                 indicates   if   all   the  parameters  were  reset,  and
                 individual  keys  for  each  parameter  indicating  which
                 succeeded or failed, per host.

          CLI Example:

          syslog_config can be passed as a quoted, comma-separated string,
          e.g.

             # Used for ESXi host connection information
             salt '*' vsphere.reset_syslog_config my.esxi.host root bad-password             syslog_config='logdir,loghost'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.reset_syslog_config my.vcenter.location root bad-password             syslog_config='logdir,loghost' esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.service_restart(host,     username,      password,
   service_name, protocol=None, port=None, host_names=None)
          Restart the named service for the given host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The  name  of  the  service  for which to set the policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to restart the service.

                 If  host_names  is  not  provided,  the  service  will be
                 restarted for the host location instead. This  is  useful
                 for  when service instance connection information is used
                 for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.service_restart my.esxi.host root bad-password 'ntpd'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.service_restart my.vcenter.location root bad-password 'ntpd'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.service_start(host,      username,       password,
   service_name, protocol=None, port=None, host_names=None)
          Start the named service for the given host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The  name  of  the  service  for which to set the policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to start the service.

                 If  host_names  is  not  provided,  the  service  will be
                 started for the host location instead. This is useful for
                 when  service instance connection information is used for
                 a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.service_start my.esxi.host root bad-password 'ntpd'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.service_start my.vcenter.location root bad-password 'ntpd'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.service_stop(host,       username,       password,
   service_name, protocol=None, port=None, host_names=None)
          Stop the named service for the given host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The  name  of  the  service  for which to set the policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to stop the service.

                 If  host_names  is  not  provided,  the  service  will be
                 stopped for the host location instead. This is useful for
                 when  service instance connection information is used for
                 a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.service_stop my.esxi.host root bad-password 'ssh'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.service_stop my.vcenter.location root bad-password 'ssh'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.set_coredump_network_config(host,        username,
   password,    dump_ip,   protocol=None,   port=None,   host_vnic='vmk0',
   dump_port=6500, esxi_hosts=None)
          Set the network parameters for a  network  coredump  collection.
          Note  that  ESXi  requires  that the dumps first be enabled (see
          coredump_network_enable) before these parameters may be set.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          dump_ip
                 IP address of host that will accept the dump.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          host_vnic
                 Host  VNic port through which to communicate. Defaults to
                 vmk0.

          dump_port
                 TCP port to use for the dump, defaults to 6500.

          Returns
                 A standard cmd.run_all  dictionary  with  a  success  key
                 added,  per  host.   success  will  be  True  if  the set
                 succeeded, False otherwise.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.set_coredump_network_config my.esxi.host root bad-password 'dump_ip.host.com'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.set_coredump_network_config my.vcenter.location root bad-password 'dump_ip.host.com'             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.set_ntp_config(host,      username,      password,
   ntp_servers, protocol=None, port=None, host_names=None)
          Set NTP configuration for a given host of list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          ntp_servers
                 A  list of servers that should be added to and configured
                 for the specified host's NTP configuration.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell vCenter which
                 hosts to configure ntp servers.

                 If  host_names  is  not provided, the NTP servers will be
                 configured for the host location instead. This is  useful
                 for  when service instance connection information is used
                 for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.ntp_configure my.esxi.host root bad-password '[192.174.1.100, 192.174.1.200]'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.ntp_configure my.vcenter.location root bad-password '[192.174.1.100, 192.174.1.200]'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.set_service_policy(host,    username,    password,
   service_name,       service_policy,      protocol=None,      port=None,
   host_names=None)
          Set the service name's policy for a given host or list of hosts.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          service_name

                 The name of the service for  which  to  set  the  policy.
                 Supported service names are:

                        * DCUI

                        * TSM

                        * SSH

                        * lbtd

                        * lsassd

                        * lwiod

                        * netlogond

                        * ntpd

                        * sfcbd-watchdog

                        * snmpd

                        * vprobed

                        * vpxa

                        * xorg

          service_policy
                 The   policy   to  set  for  the  service.  For  example,
                 'automatic'.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell  vCenter  the
                 hosts for which to set the service policy.

                 If   host_names  is  not  provided,  the  service  policy
                 information will  be  retrieved  for  the  host  location
                 instead.   This  is  useful  for  when  service  instance
                 connection information is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.set_service_policy my.esxi.host root bad-password 'ntpd' 'automatic'

             # Used for connecting to a vCenter Server
             salt '*' vsphere.set_service_policy my.vcenter.location root bad-password 'ntpd' 'automatic'         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.set_syslog_config(host,    username,     password,
   syslog_config,  config_value,  protocol=None, port=None, firewall=True,
   reset_service=True, esxi_hosts=None)
          Set the specified syslog configuration  parameter.  By  default,
          this   function   will   reset  the  syslog  service  after  the
          configuration is set.

          host   ESXi or vCenter host to connect to.

          username
                 User to connect as, usually root.

          password
                 Password to connect with.

          syslog_config
                 Name of parameter to set (corresponds to the command line
                 switch for esxcli without the double dashes (--))

                 Valid   syslog_config   values   are   logdir,   loghost,
                 default-rotate`,  ``default-size,  default-timeout,   and
                 logdir-unique.

          config_value
                 Value  for  the  above parameter. For loghost, URLs or IP
                 addresses to use for logging. Multiple log servers can be
                 specified  by  listing them, comma-separated, but without
                 spaces before or after commas.

                 (reference:
                 https://blogs.vmware.com/vsphere/2012/04/configuring-multiple-syslog-servers-for-esxi-5.html)

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          firewall
                 Enable the firewall rule  set  for  syslog.  Defaults  to
                 True.

          reset_service
                 After  a  successful  parameter  set,  reset the service.
                 Defaults to True.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 Dictionary  with  a  top-level  key  of  'success'  which
                 indicates  if  all  the  parameters   were   reset,   and
                 individual  keys  for  each  parameter  indicating  which
                 succeeded or failed, per host.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.set_syslog_config my.esxi.host root bad-password             loghost ssl://localhost:5432,tcp://10.1.0.1:1514

             # Used for connecting to a vCenter Server
             salt '*' vsphere.set_syslog_config my.vcenter.location root bad-password             loghost ssl://localhost:5432,tcp://10.1.0.1:1514             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.syslog_service_reload(host,  username,   password,
   protocol=None, port=None, esxi_hosts=None)
          Reload the syslog service so it will pick up any changes.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          esxi_hosts
                 If host is a vCenter host, then use esxi_hosts to execute
                 this function on a list of one or more ESXi machines.

          Returns
                 A standard cmd.run_all dictionary.  This dictionary  will
                 at least have a retcode key.  If retcode is 0 the command
                 was successful.

          CLI Example:

             # Used for ESXi host connection information
             salt '*' vsphere.syslog_service_reload my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.syslog_service_reload my.vcenter.location root bad-password             esxi_hosts='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.system_info(host,       username,        password,
   protocol=None, port=None)
          Return system information about a VMware environment.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          CLI Example:

             salt '*' vsphere.system_info 1.2.3.4 root bad-password

   salt.modules.vsphere.update_host_datetime(host,   username,   password,
   protocol=None, port=None, host_names=None)
          Update the date/time on the given host or  list  of  host_names.
          This  function  should be used with caution since network delays
          and execution delays can result in time skews.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell vCenter which
                 hosts should update their date/time.

                 If  host_names  is  not  provided,  the date/time will be
                 updated for the host location instead. This is useful for
                 when  service instance connection information is used for
                 a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.update_date_time my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.update_date_time my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.update_host_password(host,   username,   password,
   new_password, protocol=None, port=None)
          Update the password for a given host.

          NOTE:
             Currently only works with connections to ESXi hosts. Does not
             work with vCenter servers.

          host   The location of the ESXi host.

          username
                 The username used to login to  the  ESXi  host,  such  as
                 root.

          password
                 The password used to login to the ESXi host.

          new_password
                 The  new  password  that will be updated for the provided
                 username on the ESXi host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          CLI Example:

             salt '*' vsphere.update_host_password my.esxi.host root original-bad-password new-bad-password

   salt.modules.vsphere.upload_ssh_key(host,      username,      password,
   ssh_key=None,      ssh_key_file=None,     protocol=None,     port=None,
   certificate_verify=False)
          Upload an ssh key for root to an ESXi host via http  PUT.   This
          function only works for ESXi, not vCenter.  Only one ssh key can
          be uploaded for root.  Uploading a second key will  replace  any
          existing key.

          Parameters

                 * host -- The location of the ESXi Host

                 * username -- Username to connect as

                 * password -- Password for the ESXi web endpoint

                 * ssh_key   --   Public   SSH   key,  will  be  added  to
                   authorized_keys on ESXi

                 * ssh_key_file --  File  containing  the  SSH  key.   Use
                   'ssh_key' or ssh_key_file, but not both.

                 * protocol  --  defaults  to https, can be http if ssl is
                   disabled on ESXi

                 * port -- defaults to 443 for https

                 * certificate_verify -- If  true  require  that  the  SSL
                   connection present a valid certificate

          Returns
                 Dictionary  with  a  'status'  key,  True  if  upload  is
                 successful.  If upload is unsuccessful, 'status' key will
                 be  False  and  an  'Error'  key will have an informative
                 message.

          CLI Example:

             salt '*' vsphere.upload_ssh_key my.esxi.host root bad-password ssh_key_file='/etc/salt/my_keys/my_key.pub'

   salt.modules.vsphere.vmotion_disable(host,     username,      password,
   protocol=None, port=None, host_names=None)
          Disable vMotion for a given host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the host_names argument is required to tell vCenter which
                 hosts should disable VMotion.

                 If host_names is not provided, VMotion will  be  disabled
                 for  the  host  location instead. This is useful for when
                 service instance connection information  is  used  for  a
                 single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.vmotion_disable my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.vmotion_disable my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.vmotion_enable(host,      username,      password,
   protocol=None, port=None, host_names=None, device='vmk0')
          Enable vMotion for a given host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell vCenter which
                 hosts should enable VMotion.

                 If  host_names  is  not provided, VMotion will be enabled
                 for the host location instead. This is  useful  for  when
                 service  instance  connection  information  is used for a
                 single ESXi host.

          device The device that uniquely identifies the  VirtualNic  that
                 will be used for VMotion for each host. Defaults to vmk0.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.vmotion_enable my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.vmotion_enable my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.vsan_add_disks(host,      username,      password,
   protocol=None, port=None, host_names=None)
          Add any VSAN-eligible disks to the VSAN  System  for  the  given
          host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the host_names argument is required to tell vCenter which
                 hosts need to add any VSAN-eligible disks to  the  host's
                 VSAN system.

                 If  host_names  is not provided, VSAN-eligible disks will
                 be added to the hosts's VSAN system for the host location
                 instead.   This  is  useful  for  when  service  instance
                 connection information is used for a single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.vsan_add_disks my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.vsan_add_disks my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.vsan_disable(host,       username,       password,
   protocol=None, port=None, host_names=None)
          Disable VSAN for a given host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally  set  to alternate protocol if the host is not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List  of  ESXi  host  names. When the host, username, and
                 password credentials are provided for a  vCenter  Server,
                 the host_names argument is required to tell vCenter which
                 hosts should disable VSAN.

                 If host_names is not provided, VSAN will be disabled  for
                 the  host  location  instead.  This  is  useful  for when
                 service instance connection information  is  used  for  a
                 single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.vsan_disable my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.vsan_disable my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.vsphere.vsan_enable(host,        username,       password,
   protocol=None, port=None, host_names=None)
          Enable VSAN for a given host or list of host_names.

          host   The location of the host.

          username
                 The username used to login to the host, such as root.

          password
                 The password used to login to the host.

          protocol
                 Optionally set to alternate protocol if the host  is  not
                 using the default protocol. Default protocol is https.

          port   Optionally set to alternate port if the host is not using
                 the default port. Default port is 443.

          host_names
                 List of ESXi host names. When  the  host,  username,  and
                 password  credentials  are provided for a vCenter Server,
                 the host_names argument is required to tell vCenter which
                 hosts should enable VSAN.

                 If  host_names  is not provided, VSAN will be enabled for
                 the host  location  instead.  This  is  useful  for  when
                 service  instance  connection  information  is used for a
                 single ESXi host.

          CLI Example:

             # Used for single ESXi host connection information
             salt '*' vsphere.vsan_enable my.esxi.host root bad-password

             # Used for connecting to a vCenter Server
             salt '*' vsphere.vsan_enable my.vcenter.location root bad-password         host_names='[esxi-1.host.com, esxi-2.host.com]'

   salt.modules.win_autoruns
   Module for listing programs that automatically  run  on  startup  (very
   alpha...not tested on anything but my Win 7x64)

   salt.modules.win_autoruns.list()
          Get a list of automatically running programs

          CLI Example:

             salt '*' autoruns.list

   salt.modules.win_certutil module
   This  module  allows  you  to  install  certificates  into  the windows
   certificate manager.

      salt '*' certutil.add_store salt://cert.cer "TrustedPublisher"

   salt.modules.win_certutil.add_store(source, store, saltenv='base')
          Add the given cert into the given Certificate Store

          source The source certificate file  this  can  be  in  the  form
                 salt://path/to/file

          store  The certificate store to add the certificate to

          saltenv
                 The  salt  environment to use this is ignored if the path
                 is local

          CLI Example:

             salt '*' certutil.add_store salt://cert.cer TrustedPublisher

   salt.modules.win_certutil.del_store(source, store, saltenv='base')
          Delete the given cert into the given Certificate Store

          source The source certificate file  this  can  be  in  the  form
                 salt://path/to/file

          store  The certificate store to delete the certificate from

          saltenv
                 The  salt  environment to use this is ignored if the path
                 is local

          CLI Example:

             salt '*' certutil.del_store salt://cert.cer TrustedPublisher

   salt.modules.win_certutil.get_cert_serial(cert_file)
          Get the serial number of a certificate file

          cert_file
                 The certificate file to find the serial for

          CLI Example:

             salt '*' certutil.get_cert_serial <certificate name>

   salt.modules.win_certutil.get_stored_cert_serials(store)
          Get all of the certificate serials in the specified store

          store  The store to get all the certificate serials from

          CLI Example:

             salt '*' certutil.get_stored_cert_serials <store>

   salt.modules.win_dacl
   Manage DACLs on Windows

   depends

          * winreg Python module

   salt.modules.win_dacl.add_ace(path,   objectType,   user,   permission,
   acetype, propagation)
          add an ace to an object

          path:      path    to    the    object    (i.e.    c:\temp\file,
          HKEY_LOCAL_MACHINE\SOFTWARE\KEY,  etc)   user:   user   to   add
          permission:    permissions   for   the   user  acetype:   either
          allow/deny for each user/permission (ALLOW,  DENY)  propagation:
          how   the   ACE  applies  to  children  for  Registry  Keys  and
          Directories(KEY, KEY&SUBKEYS, SUBKEYS)

          CLI Example:

             allow domain\fakeuser full control on HKLM\\SOFTWARE\\somekey, propagate to this key and subkeys
                 salt 'myminion' win_dacl.add_ace 'HKEY_LOCAL_MACHINE\\SOFTWARE\\somekey' 'Registry' 'domain\fakeuser' 'FULLCONTROL' 'ALLOW' 'KEY&SUBKEYS'

   salt.modules.win_dacl.check_ace(path,         objectType,         user,
   permission=None,             acetype=None,            propagation=None,
   exactPermissionMatch=False)
          Checks a path to verify the ACE (access control entry) specified
          exists

          Parameters

                 * path -- path to the file/reg key

                 * objectType  --  The  type  of  object (FILE, DIRECTORY,
                   REGISTRY)

                 * user -- user that the ACL is for

                 * permission   --   permission   to   test   for   (READ,
                   FULLCONTROL, etc)

                 * acetype -- the type of ACE (ALLOW or DENY)

                 * propagation  -- the propagation type of the ACE (FILES,
                   FOLDERS, KEY, KEY&SUBKEYS, SUBKEYS, etc)

                 * exactPermissionMatch -- the ACL must match exactly,  IE
                   if  READ  is specified, the user must have READ exactly
                   and not FULLCONTROL (which also has the READ permission
                   obviously)

          Returns  (dict):  'Exists'  true  if the ACE exists, false if it
          does not

          CLI Example:

             salt 'minion-id' win_dacl.check_ace c:  emp directory <username> fullcontrol

   salt.modules.win_dacl.check_inheritance(path, objectType, user=None)
          Check a specified path to verify if inheritance is enabled

          Parameters

                 * path -- path of the registry key or file system  object
                   to check

                 * objectType  --  The  type  of  object (FILE, DIRECTORY,
                   REGISTRY)

                 * user -- if provided, will consider only  the  ACEs  for
                   that user

          Returns (bool): 'Inheritance' of True/False

          CLI Example:

             salt 'minion-id' win_dacl.check_inheritance c:  emp directory <username>

   class salt.modules.win_dacl.daclConstants
          DACL constants used throughout the module

          getAceTypeBit(t)
                 returns the acetype bit of a text value

          getAceTypeText(t)
                 returns the textual representation of a acetype bit

          getObjectTypeBit(t)
                 returns the bit value of the string object type

          getPermissionBit(t, m)
                 returns  a  permission bit of the string permission value
                 for the specified object type

          getPermissionText(t, m)
                 returns  the  permission  textual  representation  of   a
                 specified permission bit/object type

          getPropagationBit(t, p)
                 returns the propagation bit of a text value

          getPropagationText(t, p)
                 returns the textual representation of a propagation bit

          getSecurityHkey(s)
                 returns  the  necessary  string value for an HKEY for the
                 win32security module

          processPath(path, objectType)

                 processes a path/object type combo and returns:
                        registry  types  with  the   correct   HKEY   text
                        representation  files/directories with environment
                        variables expanded

   salt.modules.win_dacl.disable_inheritance(path, objectType, copy=True)
          Disable inheritance on an object

          Parameters

                 * path -- The path to the object

                 * objectType -- The  type  of  object  (FILE,  DIRECTORY,
                   REGISTRY)

                 * copy  --  True will copy the Inherited ACEs to the DACL
                   before disabling inheritance

          Returns (dict): A dictionary containing the results

          CLI Example:

             salt 'minion-id' win_dacl.disable_inheritance c:        emp directory

   salt.modules.win_dacl.enable_inheritance(path, objectType, clear=False)
          enable/disable inheritance on an object

          Parameters

                 * path -- The path to the object

                 * objectType -- The  type  of  object  (FILE,  DIRECTORY,
                   REGISTRY)

                 * clear  --  True will remove non-Inherited ACEs from the
                   ACL

          Returns (dict): A dictionary containing the results

          CLI Example:

             salt 'minion-id' win_dacl.enable_inheritance c: emp directory

   salt.modules.win_dacl.get(path, objectType, user=None)
          Get the ACL of  an  object.  Will  filter  by  user  if  one  is
          provided.

          Parameters

                 * path -- The path to the object

                 * objectType  --  The  type  of  object (FILE, DIRECTORY,
                   REGISTRY)

                 * user -- A user name to filter by

          Returns (dict): A dictionary containing the ACL

          CLI Example:

             salt 'minion-id' win_dacl.get c:        emp directory

   salt.modules.win_dacl.rm_ace(path, objectType,  user,  permission=None,
   acetype=None, propagation=None)
          remove an ace to an object

          path:      path    to    the    object    (i.e.    c:\temp\file,
          HKEY_LOCAL_MACHINE\SOFTWARE\KEY,  etc)  user:  user  to   remove
          permission:    permissions   for   the  user  acetypes:   either
          allow/deny for each user/permission (ALLOW,  DENY)  propagation:
          how   the   ACE  applies  to  children  for  Registry  Keys  and
          Directories(KEY, KEY&SUBKEYS, SUBKEYS)

          If any of the optional parameters are omitted (or set  to  None)
          they act as wildcards.

          CLI Example:

             remove allow domain\fakeuser full control on HKLM\\SOFTWARE\\somekey propagated to this key and subkeys
                 salt 'myminion' win_dacl.rm_ace 'Registry' 'HKEY_LOCAL_MACHINE\\SOFTWARE\\somekey' 'domain\fakeuser' 'FULLCONTROL' 'ALLOW' 'KEY&SUBKEYS'

   salt.modules.win_disk
   Module for gathering disk information on Windows

   depends

          * win32api Python module

   salt.modules.win_disk.usage()
          Return usage information for volumes mounted on this minion

          CLI Example:

             salt '*' disk.usage

   salt.modules.win_dism module
   Install  features/packages  for Windows using DISM, which is useful for
   minions not running server versions of Windows. Some functions are only
   available on Windows 10.

   salt.modules.win_dism.add_capability(capability,           source=None,
   limit_access=False, image=None, restart=False)
          Install a capability

          Parameters

                 * capability (str) -- The capability to install

                 * source (Optional[str]) -- The optional  source  of  the
                   capability.  Default  is set by group policy and can be
                   Windows Update.

                 * limit_access  (Optional[bool])  --  Prevent  DISM  from
                   contacting Windows Update for the source package

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Raises

                 * NotImplementedError -- For all versions of Windows that
                   are not Windows 10

                 * and later. Server editions of Windows use ServerManager
                   instead.

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism.add_capability Tools.Graphics.DirectX~~~~0.0.1.0

   salt.modules.win_dism.add_feature(feature,  package=None,  source=None,
   limit_access=False, enable_parent=False, image=None, restart=False)
          Install a feature using DISM

          Parameters

                 * feature (str) -- The feature to install

                 * package  (Optional[str])  -- The parent package for the
                   feature. You do not have to specify the package  if  it
                   is  the  Windows  Foundation  Package.   Otherwise, use
                   package to specify the parent package of the feature

                 * source (Optional[str]) -- The optional  source  of  the
                   capability.  Default  is set by group policy and can be
                   Windows Update

                 * limit_access  (Optional[bool])  --  Prevent  DISM  from
                   contacting Windows Update for the source package

                 * enable_parent  (Optional[bool]) -- True will enable all
                   parent features of the specified feature

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism.add_feature NetFx3

   salt.modules.win_dism.add_package(package,          ignore_check=False,
   prevent_pending=False, image=None, restart=False)
          Install a package using DISM

          Parameters

                 * package (str) -- The package to install. Can be a  .cab
                   file, a .msu file, or a folder

                 * ignore_check  (Optional[bool])  -- Skip installation of
                   the package if the applicability checks fail

                 * prevent_pending   (Optional[bool])    --    Skip    the
                   installation of the package if there are pending online
                   actions

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism.add_package C:\Packages\package.cab

   salt.modules.win_dism.available_capabilities(image=None)
          List the capabilities available on the system

          Parameters
                 image  (Optional[str])  -- The path to the root directory
                 of an offline Windows  image.  If  None  is  passed,  the
                 running operating system is targeted. Default is None.

          Raises

                 * NotImplementedError -- For all versions of Windows that
                   are not Windows 10

                 * and later. Server editions of Windows use ServerManager
                   instead.

          Returns
                 A list of available capabilities

          Return type
                 list

          CLI Example:

             salt '*' dism.installed_capabilities

   salt.modules.win_dism.available_features(image=None)
          List the features available on the system

          Parameters
                 image  (Optional[str])  -- The path to the root directory
                 of an offline Windows  image.  If  None  is  passed,  the
                 running operating system is targeted. Default is None.

          Returns
                 A list of available features

          Return type
                 list

          CLI Example:

             salt '*' dism.available_features

   salt.modules.win_dism.get_capabilities(image=None)
          List all capabilities on the system

          Parameters
                 image  (Optional[str])  -- The path to the root directory
                 of an offline Windows  image.  If  None  is  passed,  the
                 running operating system is targeted. Default is None.

          Raises

                 * NotImplementedError -- For all versions of Windows that
                   are not Windows 10

                 * and later. Server editions of Windows use ServerManager
                   instead.

          Returns
                 A list of capabilities

          Return type
                 list

          CLI Example:

             salt '*' dism.get_capabilities

   salt.modules.win_dism.get_features(package=None, image=None)
          List features on the system or in a package

          Parameters

                 * package (Optional[str]) --

                   The  full path to the package. Can be either a package,
                   not to where the file is installed. You cannot use this
                   command to get package information for .msu files

                   This  can  also  be  the name of a package as listed in
                   dism.installed_packages

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

          Returns
                 A list of features

          Return type
                 list

          CLI Example:

                 # Return all features on the system
                 salt '*' dism.get_features

                 # Return all features in package.cab
                 salt '*' dism.get_features C:\packages\package.cab

                 # Return all features in the calc package
                 salt '*' dism.get_features Microsoft.Windows.Calc.Demo~6595b6144ccf1df~x86~en~1.0.0.0

   salt.modules.win_dism.installed_capabilities(image=None)
          List the capabilities installed on the system

          Parameters
                 image (Optional[str]) -- The path to the  root  directory
                 of  an  offline  Windows  image.  If  None is passed, the
                 running operating system is targeted. Default is None.

          Raises

                 * NotImplementedError -- For all versions of Windows that
                   are not Windows 10

                 * and later. Server editions of Windows use ServerManager
                   instead.

          Returns
                 A list of installed capabilities

          Return type
                 list

          CLI Example:

             salt '*' dism.installed_capabilities

   salt.modules.win_dism.installed_features(image=None)
          List the features installed on the system

          Parameters
                 image (Optional[str]) -- The path to the  root  directory
                 of  an  offline  Windows  image.  If  None is passed, the
                 running operating system is targeted. Default is None.

          Returns
                 A list of installed features

          Return type
                 list

          CLI Example:

             salt '*' dism.installed_features

   salt.modules.win_dism.installed_packages(image=None)
          List the packages installed on the system

          Parameters
                 image (Optional[str]) -- The path to the  root  directory
                 of  an  offline  Windows  image.  If  None is passed, the
                 running operating system is targeted. Default is None.

          Returns
                 A list of installed packages

          Return type
                 list

          CLI Example:

             salt '*' dism.installed_packages

   salt.modules.win_dism.package_info(package, image=None)
          Display information about a package

          Parameters

                 * package (str) -- The full path to the package.  Can  be
                   either  a  .cab  file  or a folder. Should point to the
                   original source of the package, not to where  the  file
                   is  installed.  You  cannot  use  this  command  to get
                   package information for .msu files

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism. package_info C:\packages\package.cab

   salt.modules.win_dism.remove_capability(capability,         image=None,
   restart=False)
          Uninstall a capability

          Parameters

                 * capability (str) -- The capability to be removed

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Raises

                 * NotImplementedError -- For all versions of Windows that
                   are not Windows 10

                 * and later. Server editions of Windows use ServerManager
                   instead.

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism.remove_capability Tools.Graphics.DirectX~~~~0.0.1.0

   salt.modules.win_dism.remove_feature(feature,     remove_payload=False,
   image=None, restart=False)
          Disables the feature.

          Parameters

                 * feature (str) -- The feature to uninstall

                 * remove_payload (Optional[bool]) -- Remove the feature's
                   payload.  Must  supply  source  when  enabling  in  the
                   future.

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             salt '*' dism.remove_feature NetFx3

   salt.modules.win_dism.remove_package(package,               image=None,
   restart=False)
          Uninstall a package

          Parameters

                 * package  (str)  -- The full path to the package. Can be
                   either a .cab file or a folder.  Should  point  to  the
                   original  source  of the package, not to where the file
                   is installed. This can also be the name of a package as
                   listed in dism.installed_packages

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install

          Returns
                 A dictionary containing the results of the command

          Return type
                 dict

          CLI Example:

             # Remove the Calc Package
             salt '*' dism.remove_package Microsoft.Windows.Calc.Demo~6595b6144ccf1df~x86~en~1.0.0.0

             # Remove the package.cab (does not remove C:\packages\package.cab)
             salt '*' dism.remove_package C:\packages\package.cab

   salt.modules.win_dns_client
   Module for configuring DNS Client on Windows systems

   salt.modules.win_dns_client.add_dns(ip,      interface='Local      Area
   Connection', index=1)
          Add  the  DNS server to the network interface (index starts from
          1)

          Note: if the interface DNS is configured by DHCP,  all  the  DNS
          servers will be removed from the interface and the requested DNS
          will be the only one

          CLI Example:

             salt '*' win_dns_client.add_dns <ip> <interface> <index>

   salt.modules.win_dns_client.dns_dhcp(interface='Local Area Connection')
          Configure the interface to get its DNS  servers  from  the  DHCP
          server

          CLI Example:

             salt '*' win_dns_client.dns_dhcp <interface>

   salt.modules.win_dns_client.get_dns_config(interface='Local        Area
   Connection')
          Get the type of DNS configuration (dhcp / static)

          CLI Example:

             salt '*' win_dns_client.get_dns_config 'Local Area Connection'

   salt.modules.win_dns_client.get_dns_servers(interface='Local       Area
   Connection')
          Return  a  list  of  the configured DNS servers of the specified
          interface

          CLI Example:

             salt '*' win_dns_client.get_dns_servers 'Local Area Connection'

   salt.modules.win_dns_client.rm_dns(ip,      interface='Local       Area
   Connection')
          Remove the DNS server from the network interface

          CLI Example:

             salt '*' win_dns_client.rm_dns <ip> <interface>

   salt.modules.win_dsc
   Module for working with DSC (Alpha)

   depends

          * PowerShell 5.0

   salt.modules.win_dsc.apply_config(path, source=None, salt_env=u'base')
          Run  an  compiled  DSC configuration (a folder containing a .mof
          file). The folder can be cached from the salt master  using  the
          source option.

          Parameters
                 path  (str)  -- Local path to the directory that contains
                 the .mof

          configuration file to apply.  Required.

          Parameters
                 source (str) -- Path to the directory that  contains  the
                 .mof file on the

          file_roots.  The  source  directory  will  be copied to the path
          directory and then executed. If the path and source  directories
          differ,  the  source directory will be applied. If source is not
          passed, the config located at path will be applied.  Optional.

          Parameters
                 salt_env (str)  --  The  salt  environment  to  use  when
                 copying your source.

          Default is 'base'

          Returns
                 True if successful, otherwise False

          Return type
                 bool

          CLI Example:

          To apply a config that already exists on the the system

             salt '*' dsc.run_config C:\\DSC\\WebSiteConfiguration

          To cache a configuration from the master and apply it:

             salt '*' dsc.run_config C:\\DSC\\WebSiteConfiguration salt://dsc/configs/WebSiteConfiguration

   salt.modules.win_dsc.compile_config(path,   source=None,   config=None,
   salt_env=u'base')
          Compile a config from a powershell script (.ps1)

          Parameters
                 path (str) -- Path (local) to the script that will create
                 the .mof

          configuration  file. If no source is passed, the file must exist
          locally.  Required.

          Parameters
                 source (str) -- Path to the script on file_roots to cache
                 at the

          location  specified  by  path.  The  source  file will be cached
          locally and then executed. If source is not passed,  the  config
          script located at path will be compiled.  Optional.

          Parameters
                 config  (str) -- The name of the Configuration within the
                 script to apply.

          If the script contains multiple configurations within the file a
          config  must  be  specified. If the config is not specified, the
          name of the file will be used as the config to run.  Optional.

          Parameters
                 salt_env (str)  --  The  salt  environment  to  use  when
                 copying the source.

          Default is 'base'

          Returns
                 A dictionary containing the results of the compilation

          Return type
                 dict

          CLI Example:

          To  compile  a  config  from a script that already exists on the
          system:

             salt '*' dsc.compile_config C:\\DSC\\WebsiteConfig.ps1

          To cache a config script to  the  system  from  the  master  and
          compile it:

             salt '*' dsc.compile_config C:\\DSC\\WebsiteConfig.ps1 salt://dsc/configs/WebsiteConfig.ps1

   salt.modules.win_dsc.get_config()
          Get the current DSC Configuration

          Returns
                 A  dictionary  representing  the DSC Configuration on the
                 machine

          Return type
                 dict

          CLI Example:

             salt '*' dsc.get_config

   salt.modules.win_dsc.get_config_status()
          Get the status of the current DSC Configuration

          Returns
                 A dictionary representing the status of the current DSC

          Configuration on the machine :rtype: dict

          CLI Example:

             salt '*' dsc.get_config_status

   salt.modules.win_dsc.get_lcm_config()
          Get the current Local Configuration Manager settings

          Returns
                 A dictionary representing the Local Configuration Manager
                 settings on the machine

          Return type
                 dict

          CLI Example:

             salt '*' dsc.get_lcm_config

   salt.modules.win_dsc.run_config(path,     source=None,     config=None,
   salt_env=u'base')
          Compile a DSC Configuration in the form of a  powershell  script
          (.ps1)  and  apply  it. The powershell script can be cached from
          the master using the source option. If there is  more  than  one
          config  within  the powershell script, the desired configuration
          can be applied by passing the name in the config option.

          This   command   would   be   the    equivalent    of    running
          dsc.compile_config and dsc.apply_config separately.

          Parameters
                 path  (str)  --  The  local path to the powershell script
                 that contains the

          DSC Configuration.  Required.

          Parameters
                 source (str) -- The path to the script on  file_roots  to
                 cache at the

          location  specified  by  path.  The  source  file will be cached
          locally and then executed. If source is not passed,  the  config
          script located at path will be compiled.  Optional.

          Parameters
                 config  (str) -- The name of the Configuration within the
                 script to apply.

          If the script contains multiple configurations within the file a
          config  must  be  specified. If the config is not specified, the
          name of the file will be used as the config to run.  Optional.

          Parameters
                 salt_env (str)  --  The  salt  environment  to  use  when
                 copying the source.

          Default is 'base'

          Returns
                 True if successfully compiled and applied, False if not

          Return type
                 bool

          CLI Example:

          To  compile  a  config  from a script that already exists on the
          system:

             salt '*' dsc.compile_apply_config C:\\DSC\\WebsiteConfig.ps1

          To cache a config script to  the  system  from  the  master  and
          compile it:

             salt '*' dsc.compile_apply_config C:\\DSC\\WebsiteConfig.ps1 salt://dsc/configs/WebsiteConfig.ps1

   salt.modules.win_dsc.set_lcm_config(config_mode=None,
   config_mode_freq=None,    refresh_freq=None,     reboot_if_needed=None,
   action_after_reboot=None,    refresh_mode=None,    certificate_id=None,
   configuration_id=None,  allow_module_overwrite=None,  debug_mode=False,
   status_retention_days=None)
          For    detailed    descriptions    of    the   parameters   see:
          https://msdn.microsoft.com/en-us/PowerShell/DSC/metaConfig

          Parameters
                 config_mode  (str)   --   How   the   LCM   applies   the
                 configuration. Valid values

          are: - ApplyOnly - ApplyAndMonitor - ApplyAndAutoCorrect

          Parameters
                 config_mode_freq  (int)  --  How  often,  in minutes, the
                 current

          configuration is checked and applied. Ignored if config_mode  is
          set to ApplyOnly. Default is 15.

          Parameters
                 refresh_mode  (str)  --  How the LCM gets configurations.
                 Valid values are:

          * Disabled

          * Push

          * Pull

          Parameters
                 refresh_freq (int) -- How  often,  in  minutes,  the  LCM
                 checks for updated

          configurations. (pull mode only) Default is 30.

          NOTE:
             Either   config_mode_freq  or  refresh_freq  needs  to  be  a
             multiple

          of the other. See documentation on MSDN for more details.

          Parameters
                 reboot_if_needed (bool) -- Reboot the machine  if  needed
                 after a

          configuration is applied. Default is False.

          Parameters
                 action_after_reboot (str) -- Action to take after reboot.
                 Valid values

          are: - ContinueConfiguration - StopConfiguration

          Parameters
                 certificate_id  (guid)  --  A  GUID  that   specifies   a
                 certificate used to

          access the configuration: (pull mode)

          Parameters
                 configuration_id  (guid)  --  A  GUID that identifies the
                 config file to get

          from a pull server. (pull mode)

          Parameters
                 allow_module_overwrite (bool) -- New configs are  allowed
                 to overwrite old

          ones on the target node.

          Parameters
                 debug_mode  (str)  --  Sets the debug level. Valid values
                 are:

          * None

          * ForceModuleImport

          * All

          Parameters
                 status_retention_days (int) -- Number  of  days  to  keep
                 status of the

          current config.

          Returns (bool): True if successful, otherwise False

          CLI Example:

             salt '*' dsc.set_lcm_config ApplyOnly

   salt.modules.win_dsc.test_config()
          Tests the current applied DSC Configuration

          Returns
                 True if successfully applied, otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' dsc.test_config

   salt.modules.win_file
   Manage information about files on the minion, set/read user, group data

   depends

          * win32api

          * win32file

          * win32security

   salt.modules.win_file.chgrp(path, group)
          Change the group of a file

          Under Windows, this will do nothing.

          While a file in Windows does have a 'primary group', this rarely
          used attribute generally has no bearing  on  permissions  unless
          intentionally  configured  and  is  only  used  to  support Unix
          compatibility features (e.g.  Services For Unix, NFS services).

          Salt, therefore, remaps this function to do nothing while  still
          being  compatible  with  Unix  behavior.  When  managing Windows
          systems, this function is superfluous and will generate an  info
          level log entry if used directly.

          If  you  do  actually want to set the 'primary group' of a file,
          use file

          CLI Example:

             salt '*' file.chpgrp c:\temp\test.txt administrators

   salt.modules.win_file.chown(path,   user,   group=None,    pgroup=None,
   follow_symlinks=True)
          Chown a file, pass the file the desired user and group

          Under Windows, the group parameter will be ignored.

          This is because while files in Windows do have a 'primary group'
          property, this is rarely used.  It generally has no  bearing  on
          permissions unless intentionally configured and is most commonly
          used to provide Unix compatibility (e.g. Services For Unix,  NFS
          services).

          If  you  do  want  to  change  the  'primary group' property and
          understand the implications, pass the  Windows  only  parameter,
          pgroup, instead.

          To  set  the  primary  group  to 'None', it must be specified in
          quotes.  Otherwise Salt will interpret it as the Python value of
          None  and  no  primary group changes will occur. See the example
          below.

          CLI Example:

             salt '*' file.chown c:\temp\test.txt myusername
             salt '*' file.chown c:\temp\test.txt myusername pgroup=Administrators
             salt '*' file.chown c:\temp\test.txt myusername "pgroup='None'"

   salt.modules.win_file.chpgrp(path, group)
          Change the group of a file

          Under Windows, this will set the rarely used primary group of  a
          file.   This  generally  has  no  bearing  on permissions unless
          intentionally configured and is most commonly  used  to  provide
          Unix compatibility (e.g.  Services For Unix, NFS services).

          Ensure you know what you are doing before using this function.

          To  set  the  primary  group  to 'None', it must be specified in
          quotes.  Otherwise Salt will interpret it as the Python value of
          None  and  no  primary group changes will occur. See the example
          below.

          CLI Example:

             salt '*' file.chpgrp c:\temp\test.txt Administrators
             salt '*' file.chpgrp c:\temp\test.txt "'None'"

   salt.modules.win_file.get_attributes(path)
          Return a dictionary object with the Windows file attributes  for
          a file.

          CLI Example:

             salt '*' file.get_attributes c:\temp
.txt

   salt.modules.win_file.get_gid(path, follow_symlinks=True)
          Return the id of the group that owns a given file

          Under Windows, this will return the uid of the file.

          While a file in Windows does have a 'primary group', this rarely
          used attribute generally has no bearing  on  permissions  unless
          intentionally  configured  and  is  only  used  to  support Unix
          compatibility features (e.g.  Services For Unix, NFS services).

          Salt, therefore, remaps this function to  provide  functionality
          that  somewhat  resembles  Unix  behavior  for API compatibility
          reasons.  When  managing  Windows  systems,  this  function   is
          superfluous  and  will  generate an info level log entry if used
          directly.

          If you do actually want to access the 'primary group' of a file,
          use file.get_pgid.

          CLI Example:

             salt '*' file.get_gid c:\temp\test.txt

   salt.modules.win_file.get_group(path, follow_symlinks=True)
          Return the group that owns a given file

          Under Windows, this will return the user (owner) of the file.

          While a file in Windows does have a 'primary group', this rarely
          used attribute generally has no bearing  on  permissions  unless
          intentionally  configured  and  is  only  used  to  support Unix
          compatibility features (e.g.  Services For Unix, NFS services).

          Salt, therefore, remaps this function to  provide  functionality
          that  somewhat  resembles  Unix  behavior  for API compatibility
          reasons.  When  managing  Windows  systems,  this  function   is
          superfluous  and  will  generate an info level log entry if used
          directly.

          If you do actually want to access the 'primary group' of a file,
          use file.get_pgroup.

          CLI Example:

             salt '*' file.get_group c:\temp\test.txt

   salt.modules.win_file.get_mode(path)
          Return the mode of a file

          Right  now  we're  just  returning None because Windows' doesn't
          have a mode like Linux

          CLI Example:

             salt '*' file.get_mode /etc/passwd

   salt.modules.win_file.get_pgid(path, follow_symlinks=True)
          Return the id of the  primary  group  that  owns  a  given  file
          (Windows only)

          This  function  will  return  the rarely used primary group of a
          file. This  generally  has  no  bearing  on  permissions  unless
          intentionally  configured  and  is most commonly used to provide
          Unix compatibility (e.g. Services For Unix, NFS services).

          Ensure you know what you are doing before using this function.

          CLI Example:

             salt '*' file.get_pgid c:\temp\test.txt

   salt.modules.win_file.get_pgroup(path, follow_symlinks=True)
          Return the name of the primary group  that  owns  a  given  file
          (Windows only)

          This  function  will  return  the rarely used primary group of a
          file. This  generally  has  no  bearing  on  permissions  unless
          intentionally  configured  and  is most commonly used to provide
          Unix compatibility (e.g. Services For Unix, NFS services).

          Ensure you know what you are doing before using this function.

          The return value may be 'None', e.g. if the user  is  not  on  a
          domain.  This  is  a  valid group - do not confuse this with the
          Salt/Python value of None which means no value was returned.  To
          be certain, use the get_pgid function which will return the SID,
          including for the system 'None' group.

          CLI Example:

             salt '*' file.get_pgroup c:\temp\test.txt

   salt.modules.win_file.get_uid(path, follow_symlinks=True)
          Return the id of the user that owns a given file

          Symlinks are followed by default to mimic Unix behavior. Specify
          follow_symlinks=False to turn off this behavior.

          CLI Example:

             salt '*' file.get_uid c:\temp\test.txt
             salt '*' file.get_uid c:\temp\test.txt follow_symlinks=False

   salt.modules.win_file.get_user(path, follow_symlinks=True)
          Return the user that owns a given file

          Symlinks are followed by default to mimic Unix behavior. Specify
          follow_symlinks=False to turn off this behavior.

          CLI Example:

             salt '*' file.get_user c:\temp\test.txt
             salt '*' file.get_user c:\temp\test.txt follow_symlinks=False

   salt.modules.win_file.gid_to_group(gid)
          Convert the group id to the group name on this system

          Under Windows, because groups are just another ACL entity,  this
          function behaves the same as uid_to_user.

          For  maintaining  Windows  systems, this function is superfluous
          and only  exists  for  API  compatibility  with  Unix.  Use  the
          uid_to_user  function  instead;  an info level log entry will be
          generated if this function is used directly.

          CLI Example:

             salt '*' file.gid_to_group S-1-5-21-626487655-2533044672-482107328-1010

   salt.modules.win_file.group_to_gid(group)
          Convert the group to the gid on this system

          Under Windows, because groups are just another ACL entity,  this
          function  behaves  the  same  as  user_to_uid, except if None is
          given, '' is returned.

          For maintaining Windows systems, this  function  is  superfluous
          and  only  exists  for  API  compatibility  with  Unix.  Use the
          user_to_uid function instead; an info level log  entry  will  be
          generated if this function is used directly.

          CLI Example:

             salt '*' file.group_to_gid administrators

   salt.modules.win_file.is_link(path)
          Check if the path is a symlink

          This is only supported on Windows Vista or later.

          Inline  with Unix behavior, this function will raise an error if
          the path is not a symlink, however, the error raised will  be  a
          SaltInvocationError, not an OSError.

          CLI Example:

             salt '*' file.is_link /path/to/link

   salt.modules.win_file.lchown(path, user, group=None, pgroup=None)
          Chown  a  file, pass the file the desired user and group without
          following any symlinks.

          Under Windows, the group parameter will be ignored.

          This is because while files in Windows do have a 'primary group'
          property,  this  is rarely used.  It generally has no bearing on
          permissions unless intentionally configured and is most commonly
          used  to provide Unix compatibility (e.g. Services For Unix, NFS
          services).

          If you do want  to  change  the  'primary  group'  property  and
          understand  the  implications,  pass the Windows only parameter,
          pgroup, instead.

          To set the primary group to 'None',  it  must  be  specified  in
          quotes.  Otherwise Salt will interpret it as the Python value of
          None and no primary group changes will occur.  See  the  example
          below.

          CLI Example:

             salt '*' file.lchown c:\temp\test.txt myusername
             salt '*' file.lchown c:\temp\test.txt myusername pgroup=Administrators
             salt '*' file.lchown c:\temp\test.txt myusername "pgroup='None'"

   salt.modules.win_file.readlink(path)
          Return the path that a symlink points to

          This is only supported on Windows Vista or later.

          Inline  with Unix behavior, this function will raise an error if
          the path is not a symlink, however, the error raised will  be  a
          SaltInvocationError, not an OSError.

          CLI Example:

             salt '*' file.readlink /path/to/link

   salt.modules.win_file.remove(path, force=False)
          Remove the named file or directory

          Parameters

                 * path  (str)  --  The  path  to the file or directory to
                   remove.

                 * force (bool) -- Remove even if marked Read-Only

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt '*' file.remove C:\Temp

   salt.modules.win_file.set_attributes(path,  archive=None,  hidden=None,
   normal=None,      notIndexed=None,      readonly=None,     system=None,
   temporary=None)
          Set file attributes for a file.  Note that the normal  attribute
          means  that  all others are false.  So setting it will clear all
          others.

          CLI Example:

             salt '*' file.set_attributes c:\temp
.txt normal=True
             salt '*' file.set_attributes c:\temp
.txt readonly=True hidden=True

   salt.modules.win_file.set_mode(path, mode)
          Set the mode of a file

          This just calls get_mode, which returns None  because  we  don't
          use mode on Windows

          CLI Example:

             salt '*' file.set_mode /etc/passwd 0644

   salt.modules.win_file.stats(path,                   hash_type='sha256',
   follow_symlinks=True)
          Return a dict containing the stats for a given file

          Under Windows, gid will equal uid and group will equal user.

          While a file in Windows does have a 'primary group', this rarely
          used  attribute  generally  has no bearing on permissions unless
          intentionally configured  and  is  only  used  to  support  Unix
          compatibility features (e.g.  Services For Unix, NFS services).

          Salt,  therefore,  remaps  these properties to keep some kind of
          compatibility with Unix behavior.  If  the  'primary  group'  is
          required, it can be accessed in the pgroup and pgid properties.

          CLI Example:

             salt '*' file.stats /etc/passwd

   salt.modules.win_file.symlink(src, link)
          Create a symbolic link to a file

          This  is  only supported with Windows Vista or later and must be
          executed by a user with the SeCreateSymbolicLink privilege.

          The behavior of this function matches the Unix equivalent,  with
          one  exception  - invalid symlinks cannot be created. The source
          path must exist.  If it doesn't, an error will be raised.

          CLI Example:

             salt '*' file.symlink /path/to/file /path/to/link

   salt.modules.win_file.uid_to_user(uid)
          Convert a uid to a user name

          CLI Example:

             salt '*' file.uid_to_user S-1-5-21-626487655-2533044672-482107328-1010

   salt.modules.win_file.user_to_uid(user)
          Convert user name to a uid

          CLI Example:

             salt '*' file.user_to_uid myusername

   salt.modules.win_firewall
   Module for configuring Windows Firewall

   salt.modules.win_firewall.add_rule(name,   localport,   protocol='tcp',
   action='allow', dir='in', remoteip='any')
          New in version 2015.5.0.

          Add a new firewall rule

          CLI Example:

             salt '*' firewall.add_rule 'test' '8080' 'tcp'
             salt '*' firewall.add_rule 'test' '1' 'icmpv4'
             salt '*' firewall.add_rule 'test_remote_ip' '8000' 'tcp' 'allow' 'in' '192.168.0.1'

   salt.modules.win_firewall.delete_rule(name,  localport, protocol='tcp',
   dir='in', remoteip='any')
          New in version 2015.8.0.

          Delete an existing firewall rule

          CLI Example:

             salt '*' firewall.delete_rule 'test' '8080' 'tcp' 'in'
             salt '*' firewall.delete_rule 'test_remote_ip' '8000' 'tcp' 'in' '192.168.0.1'

   salt.modules.win_firewall.disable(profile='allprofiles')
          Disable firewall profile :param profile: (default: allprofiles)

          CLI Example:

             salt '*' firewall.disable

   salt.modules.win_firewall.enable(profile='allprofiles')
          Enable firewall profile :param profile: (default: allprofiles)

          New in version 2015.5.0.

          CLI Example:

             salt '*' firewall.enable

   salt.modules.win_firewall.get_config()
          Get the status of all the firewall profiles

          CLI Example:

             salt '*' firewall.get_config

   salt.modules.win_firewall.get_rule(name='all')
          New in version 2015.5.0.

          Get firewall rule(s) info

          CLI Example:

             salt '*' firewall.get_rule 'MyAppPort'

   salt.modules.win_groupadd
   Manage groups on Windows

   IMPORTANT:
      If you feel that Salt should be using this module to  manage  groups
      on  a  minion, and it is using a different module (or gives an error
      similar to 'group.info' is not available), see here.

   salt.modules.win_groupadd.add(name, gid=None, system=False)
          Add the specified group

          CLI Example:

             salt '*' group.add foo

   salt.modules.win_groupadd.adduser(name, username)
          add a user to a group

          CLI Example:

             salt '*' group.adduser foo username

   salt.modules.win_groupadd.delete(name)
          Remove the named group

          CLI Example:

             salt '*' group.delete foo

   salt.modules.win_groupadd.deluser(name, username)
          remove a user from a group

          CLI Example:

             salt '*' group.deluser foo username

   salt.modules.win_groupadd.getent(refresh=False)
          Return info on all groups

          CLI Example:

             salt '*' group.getent

   salt.modules.win_groupadd.info(name)
          Return information about a group

          CLI Example:

             salt '*' group.info foo

   salt.modules.win_groupadd.list_groups(refresh=False)
          Return a list of groups

          CLI Example:

             salt '*' group.getent

   salt.modules.win_groupadd.members(name, members_list)
          remove a user from a group

          CLI Example:

             salt '*' group.members foo 'user1,user2,user3'

   salt.modules.win_iis module
   Microsoft IIS site management via WebAdministration powershell module

   platform
          Windows

   New in version 2016.3.0.

   salt.modules.win_iis.create_app(name, site, sourcepath, apppool=None)
          Create an IIS application.

          Parameters

                 * name (str) -- The IIS application.

                 * site (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path.

                 * apppool (str) -- The name of the IIS application pool.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.create_app name='app0' site='site0' sourcepath='C:\site0' apppool='site0'

   salt.modules.win_iis.create_apppool(name)
          Create an IIS application pool.

          Parameters
                 name (str) -- The name of the IIS application pool.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.create_apppool name='MyTestPool'

   salt.modules.win_iis.create_binding(site, hostheader='', ipaddress='*',
   port=80, protocol='http', sslflags=0)
          Create an IIS binding.

          Parameters

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * protocol  (str)  --  The  application  protocol  of the
                   binding.

                 * sslflags (str) -- The  flags  representing  certificate
                   type and storage of the binding.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.create_binding site='site0' hostheader='example' ipaddress='*' port='80'

   salt.modules.win_iis.create_cert_binding(name,   site,   hostheader='',
   ipaddress='*', port=443, sslflags=0)
          Assign a certificate to an IIS binding.

          Parameters

                 * name (str) -- The thumbprint of the certificate.

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * sslflags (str) -- Flags representing  certificate  type
                   and certificate storage of the binding.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.create_cert_binding name='AAA000' site='site0' hostheader='example' ipaddress='*' port='443'

   salt.modules.win_iis.create_site(name,      sourcepath,     apppool='',
   hostheader='', ipaddress='*', port=80, protocol='http')
          Create a basic website in IIS.

          Parameters

                 * name (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path of the IIS site.

                 * apppool (str) -- The name of the IIS application pool.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * protocol (str)  --  The  application  protocol  of  the
                   binding.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.create_site name='My Test Site' sourcepath='c:\stage' apppool='TestPool'

   salt.modules.win_iis.create_vdir(name, site, sourcepath, app='/')
          Create an IIS virtual directory.

          Parameters

                 * name (str) -- The virtual directory name.

                 * site (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path.

                 * app (str) -- The IIS application.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.create_vdir name='vd0' site='site0' sourcepath='C:\inetpub\vdirs\vd0'

   salt.modules.win_iis.get_container_setting(name, container, settings)
          Get the value of the setting for the IIS container.

          Parameters

                 * name (str) -- The name of the IIS container.

                 * container  (str)  --  The  type  of  IIS container. The
                   container types are: AppPools, Sites, SslBindings

                 * settings (str) -- A dictionary of the setting names and
                   their values.

          Returns
                 A dictionary of the provided settings and their values.

          Return type
                 dict

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.get_container_setting name='MyTestPool' container='AppPools'
                 settings="['processModel.identityType']"

   salt.modules.win_iis.list_apppools()
          List all configured IIS application pools.

          Returns
                 A dictionary of IIS application pools and their details.

          Return type
                 dict

          CLI Example:

             salt '*' win_iis.list_apppools

   salt.modules.win_iis.list_apps(site)
          Get all configured IIS applications for the specified site.

          Parameters
                 site (str) -- The IIS site name.

          Returns
                 A dictionary of the application names and properties.

          Return type
                 dict

          CLI Example:

             salt '*' win_iis.list_apps site

   salt.modules.win_iis.list_bindings(site)
          Get all configured IIS bindings for the specified site.

          Parameters
                 site (str) -- The IIS site name.

          Returns
                 A dictionary of the binding names and properties.

          Return type
                 dict

          CLI Example:

             salt '*' win_iis.list_bindings site

   salt.modules.win_iis.list_cert_bindings(site)
          List certificate bindings for an IIS site.

          Parameters
                 site (str) -- The IIS site name.

          Returns
                 A dictionary of the binding names and properties.

          Return type
                 dict

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.list_bindings site

   salt.modules.win_iis.list_sites()
          List all the currently deployed websites.

          Returns
                 A dictionary of the IIS sites and their properties.

          Return type
                 dict

          CLI Example:

             salt '*' win_iis.list_sites

   salt.modules.win_iis.list_vdirs(site, app='/')
          Get  all  configured  IIS  virtual directories for the specified
          site, or for the combination of site and application.

          Parameters

                 * site (str) -- The IIS site name.

                 * app (str) -- The IIS application.

          Returns
                 A  dictionary  of  the  virtual   directory   names   and
                 properties.

          Return type
                 dict

          CLI Example:

             salt '*' win_iis.list_vdirs site

   salt.modules.win_iis.remove_app(name, site)
          Remove an IIS application.

          Parameters

                 * name (str) -- The application name.

                 * site (str) -- The IIS site name.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.remove_app name='app0' site='site0'

   salt.modules.win_iis.remove_apppool(name)
          Remove an IIS application pool.

          Parameters
                 name (str) -- The name of the IIS application pool.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.remove_apppool name='MyTestPool'

   salt.modules.win_iis.remove_binding(site, hostheader='', ipaddress='*',
   port=80)
          Remove an IIS binding.

          Parameters

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.remove_binding site='site0' hostheader='example' ipaddress='*' port='80'

   salt.modules.win_iis.remove_cert_binding(name,   site,   hostheader='',
   ipaddress='*', port=443)
          Remove a certificate from an IIS binding.

          Parameters

                 * name (str) -- The thumbprint of the certificate.

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.remove_cert_binding name='AAA000' site='site0' hostheader='example' ipaddress='*' port='443'

   salt.modules.win_iis.remove_site(name)
          Delete a website from IIS.

          Parameters
                 name (str) -- The IIS site name.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.remove_site name='My Test Site'

   salt.modules.win_iis.remove_vdir(name, site, app='/')
          Remove an IIS virtual directory.

          Parameters

                 * name (str) -- The virtual directory name.

                 * site (str) -- The IIS site name.

                 * app (str) -- The IIS application.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          CLI Example:

             salt '*' win_iis.remove_vdir name='vdir0' site='site0'

   salt.modules.win_iis.restart_apppool(name)
          Restart an IIS application pool.

          Parameters
                 name (str) -- The name of the IIS application pool.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.restart_apppool name='MyTestPool'

   salt.modules.win_iis.set_container_setting(name, container, settings)
          Set the value of the setting for an IIS container.

          Parameters

                 * name (str) -- The name of the IIS container.

                 * container  (str)  --  The  type  of  IIS container. The
                   container types are: AppPools, Sites, SslBindings

                 * settings (str) -- A dictionary of the setting names and
                   their values.

          Returns
                 A boolean representing whether all changes succeeded.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' win_iis.set_container_setting name='MyTestPool' container='AppPools'
                 settings="{'managedPipeLineMode': 'Integrated'}"

   salt.modules.win_ip
   The networking module for Windows based systems

   salt.modules.win_ip.disable(iface)
          Disable an interface

          CLI Example:

             salt -G 'os_family:Windows' ip.disable 'Local Area Connection #2'

   salt.modules.win_ip.enable(iface)
          Enable an interface

          CLI Example:

             salt -G 'os_family:Windows' ip.enable 'Local Area Connection #2'

   salt.modules.win_ip.get_all_interfaces()
          Return configs for all interfaces

          CLI Example:

             salt -G 'os_family:Windows' ip.get_all_interfaces

   salt.modules.win_ip.get_default_gateway()
          Set DNS source to DHCP on Windows

          CLI Example:

             salt -G 'os_family:Windows' ip.get_default_gateway

   salt.modules.win_ip.get_interface(iface)
          Return the configuration of a network interface

          CLI Example:

             salt -G 'os_family:Windows' ip.get_interface 'Local Area Connection'

   salt.modules.win_ip.get_subnet_length(mask)
          Convenience  function  to convert the netmask to the CIDR subnet
          length

          CLI Example:

             salt -G 'os_family:Windows' ip.get_subnet_length 255.255.255.0

   salt.modules.win_ip.is_disabled(iface)
          Returns True if interface is disabled, otherwise False

          CLI Example:

             salt -G 'os_family:Windows' ip.is_disabled 'Local Area Connection #2'

   salt.modules.win_ip.is_enabled(iface)
          Returns True if interface is enabled, otherwise False

          CLI Example:

             salt -G 'os_family:Windows' ip.is_enabled 'Local Area Connection #2'

   salt.modules.win_ip.raw_interface_configs()
          Return raw configs for all interfaces

          CLI Example:

             salt -G 'os_family:Windows' ip.raw_interface_configs

   salt.modules.win_ip.set_dhcp_all(iface)
          Set both IP Address and DNS to DHCP

          CLI Example:

             salt -G 'os_family:Windows' ip.set_dhcp_all 'Local Area Connection'

   salt.modules.win_ip.set_dhcp_dns(iface)
          Set DNS source to DHCP on Windows

          CLI Example:

             salt -G 'os_family:Windows' ip.set_dhcp_dns 'Local Area Connection'

   salt.modules.win_ip.set_dhcp_ip(iface)
          Set Windows NIC to get IP from DHCP

          CLI Example:

             salt -G 'os_family:Windows' ip.set_dhcp_ip 'Local Area Connection'

   salt.modules.win_ip.set_static_dns(iface, *addrs)
          Set static DNS configuration on a Windows NIC

          CLI Example:

             salt -G 'os_family:Windows' ip.set_static_dns 'Local Area Connection' '192.168.1.1'
             salt -G 'os_family:Windows' ip.set_static_dns 'Local Area Connection' '192.168.1.252' '192.168.1.253'

   salt.modules.win_ip.set_static_ip(iface,      addr,       gateway=None,
   append=False)
          Set static IP configuration on a Windows NIC

          iface  The name of the interface to manage

          addr   IP  address  with  subnet  length  (ex. 10.1.2.3/24). The
                 ip.get_subnet_length function can be  used  to  calculate
                 the subnet length from a netmask.

          gateway
                 None  If  specified,  the  default gateway will be set to
                 this value.

          append False If True, this IP  address  will  be  added  to  the
                 interface. Default is False, which overrides any existing
                 configuration for the interface and sets addr as the only
                 address on the interface.

          CLI Example:

             salt -G 'os_family:Windows' ip.set_static_ip 'Local Area Connection' 10.1.2.3/24 gateway=10.1.2.1
             salt -G 'os_family:Windows' ip.set_static_ip 'Local Area Connection' 10.1.2.4/24 append=True

   salt.modules.win_license module
   This module allows you to manage windows licensing via slmgr.vbs

      salt '*' license.install XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

   salt.modules.win_license.activate()
          Attempt to activate the current machine via Windows Activation

          CLI Example:

             salt '*' license.activate

   salt.modules.win_license.info()
          Return  information  about  the  license,  if the license is not
          correctly activated this will return None.

          CLI Example:

             salt '*' license.info

   salt.modules.win_license.install(product_key)
          Install the given product key

          CLI Example:

             salt '*' license.install XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

   salt.modules.win_license.installed(product_key)
          Check to see if the product key is already installed.

          Note: This is not 100% accurate as we can only see the last
                 5 digits of the license.

          CLI Example:

             salt '*' license.installed XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

   salt.modules.win_license.licensed()
          Return true if the current machine is licensed correctly

          CLI Example:

             salt '*' license.licensed

   salt.modules.win_license.uninstall()
          Uninstall the current product key

          CLI Example:

             salt '*' license.uninstall

   salt.modules.win_network
   Module for gathering and managing network information

   salt.modules.win_network.connect(host, port=None, **kwargs)
          Test connectivity to a host using a  particular  port  from  the
          minion.

          New in version 2016.3.0.

          CLI Example:

             salt '*' network.connect archlinux.org 80

             salt '*' network.connect archlinux.org 80 timeout=3

             salt '*' network.connect archlinux.org 80 timeout=3 family=ipv4

             salt '*' network.connect google-public-dns-a.google.com port=53 proto=udp timeout=3

   salt.modules.win_network.dig(host)
          Performs a DNS lookup with dig

          Note: dig must be installed on the Windows minion

          CLI Example:

             salt '*' network.dig archlinux.org

   salt.modules.win_network.hw_addr(iface)
          Return  the  hardware  address  (a.k.a. MAC address) for a given
          interface

          CLI Example:

             salt '*' network.hw_addr 'Wireless Connection #1'

   salt.modules.win_network.hwaddr(iface)
          This function is an alias of hw_addr.
             Return the hardware address (a.k.a. MAC address) for a  given
             interface

             CLI Example:

                 salt '*' network.hw_addr 'Wireless Connection #1'

   salt.modules.win_network.in_subnet(cidr)
          Returns True if host is within specified subnet, otherwise False

          CLI Example:

             salt '*' network.in_subnet 10.0.0.0/16

   salt.modules.win_network.interfaces()
          Return  a  dictionary of information about all the interfaces on
          the minion

          CLI Example:

             salt '*' network.interfaces

   salt.modules.win_network.interfaces_names()
          Return a list of all the interfaces names

          CLI Example:

             salt '*' network.interfaces_names

   salt.modules.win_network.ip_addrs(interface=None,
   include_loopback=False)
          Returns a list of IPv4 addresses assigned to the host. 127.0.0.1
          is ignored,  unless  'include_loopback=True'  is  indicated.  If
          'interface'  is  provided,  then  only  IP  addresses  from that
          interface will be returned.

          CLI Example:

             salt '*' network.ip_addrs

   salt.modules.win_network.ip_addrs6(interface=None,
   include_loopback=False)
          Returns  a  list  of IPv6 addresses assigned to the host. ::1 is
          ignored,  unless  'include_loopback=True'   is   indicated.   If
          'interface'  is  provided,  then  only  IP  addresses  from that
          interface will be returned.

          CLI Example:

             salt '*' network.ip_addrs6

   salt.modules.win_network.ipaddrs(interface=None,
   include_loopback=False)
          This function is an alias of ip_addrs.
             Returns  a  list  of  IPv4  addresses  assigned  to the host.
             127.0.0.1  is  ignored,  unless  'include_loopback=True'   is
             indicated. If 'interface' is provided, then only IP addresses
             from that interface will be returned.

             CLI Example:

                 salt '*' network.ip_addrs

   salt.modules.win_network.ipaddrs6(interface=None,
   include_loopback=False)
          This function is an alias of ip_addrs6.
             Returns a list of IPv6 addresses assigned to the host. ::1 is
             ignored,  unless  'include_loopback=True'  is  indicated.  If
             'interface'  is  provided,  then  only IP addresses from that
             interface will be returned.

             CLI Example:

                 salt '*' network.ip_addrs6

   salt.modules.win_network.netstat()
          Return information on open ports and states

          CLI Example:

             salt '*' network.netstat

   salt.modules.win_network.nslookup(host)
          Query DNS for information about a domain or ip address

          CLI Example:

             salt '*' network.nslookup archlinux.org

   salt.modules.win_network.ping(host,                      timeout=False,
   return_boolean=False)
          Performs a ping to a host

          CLI Example:

             salt '*' network.ping archlinux.org

          New in version 2016.11.0.

          Return a True or False instead of ping output.

             salt '*' network.ping archlinux.org return_boolean=True

          Set the time to wait for a response in seconds.

             salt '*' network.ping archlinux.org timeout=3

   salt.modules.win_network.subnets()
          Returns a list of subnets to which the host belongs

          CLI Example:

             salt '*' network.subnets

   salt.modules.win_network.traceroute(host)
          Performs a traceroute to a 3rd party host

          CLI Example:

             salt '*' network.traceroute archlinux.org

   salt.modules.win_ntp
   Management of NTP servers on Windows

   New in version 2014.1.0.

   salt.modules.win_ntp.get_servers()
          Get list of configured NTP servers

          CLI Example:

             salt '*' ntp.get_servers

   salt.modules.win_ntp.set_servers(*servers)
          Set Windows to use a list of NTP servers

          CLI Example:

             salt '*' ntp.set_servers 'pool.ntp.org' 'us.pool.ntp.org'

   salt.modules.win_path
   Manage the Windows System PATH

   Note that not all Windows applications will rehash the PATH environment
   variable, Only the ones that listen  to  the  WM_SETTINGCHANGE  message
   http://support.microsoft.com/kb/104011

   salt.modules.win_path.add(path, index=0)
          Add the directory to the SYSTEM path in the index location

          Returns
                 boolean True if successful, False if unsuccessful

          CLI Example:

             # Will add to the beginning of the path
             salt '*' win_path.add 'c:\python27' 0

             # Will add to the end of the path
             salt '*' win_path.add 'c:\python27' index='-1'

   salt.modules.win_path.exists(path)
          Check  if  the  directory  is  configured  in  the  SYSTEM  path
          Case-insensitive and ignores trailing backslash

          Returns
                 boolean True if path exists, False if not

          CLI Example:

             salt '*' win_path.exists 'c:\python27'
             salt '*' win_path.exists 'c:\python27\'
             salt '*' win_path.exists 'C:\pyThon27'

   salt.modules.win_path.get_path()
          Returns a list of items in the SYSTEM path

          CLI Example:

             salt '*' win_path.get_path

   salt.modules.win_path.rehash()
          Send a WM_SETTINGCHANGE Broadcast  to  Windows  to  refresh  the
          Environment variables

          CLI Example:

          ... code-block:: bash
             salt '*' win_path.rehash

   salt.modules.win_path.remove(path)
          Remove the directory from the SYSTEM path

          Returns
                 boolean True if successful, False if unsuccessful

          CLI Example:

             # Will remove C:\Python27 from the path
             salt '*' win_path.remove 'c:\\python27'

   salt.modules.win_pkg
   A module to manage software on Windows

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   The  following  functions require the existence of a windows repository
   metadata DB, typically created by running pkg.refresh_db:

   * pkg.get_repo_data

   * pkg.install

   * pkg.latest_version

   * pkg.list_available

   * pkg.list_pkgs

   * pkg.list_upgrades

   * pkg.remove

   If a metadata DB does not already exist and one of these  functions  is
   run, then one will be created from the repo SLS files that are present.

   As   the   creation   of   this   metadata  can  take  some  time,  the
   winrepo_cache_expire_min minion config option can be used  to  suppress
   refreshes when the metadata is less than a given number of seconds old.

   salt.modules.win_pkg.compare_versions(ver1=u'', oper=u'==', ver2=u'')
          Compare software package versions

          Parameters

                 * ver1 (str) -- A software version to compare

                 * oper (str) -- The operand to use to compare

                 * ver2 (str) -- A software version to compare

          Returns (bool): True if the comparison is valid, otherwise False

          CLI Example:

             salt '*' pkg.compare_versions 1.2 >= 1.3

   salt.modules.win_pkg.genrepo(**kwargs)
          Generate   package   metedata  db  based  on  files  within  the
          winrepo_source_dir

          CLI Example:

             salt-run pkg.genrepo
             salt -G 'os:windows' pkg.genrepo verbose=true failhard=false
             salt -G 'os:windows' pkg.genrepo saltenv=base

          Keyword Arguments (kwargs)

          Parameters

                 * saltenv (str) -- Salt environment. Default: base

                 * verbose (bool) -- Return verbose data  structure  which
                   includes  'success_list',  a  list of all sls files and
                   the package names contained within. Default 'False'

                 * failhard (bool) -- If True, an error will be raised  if
                   any repo SLS files failed to proess. If False, no error
                   will be raised, and a dictionary  containing  the  full
                   results will be returned.

   salt.modules.win_pkg.get_repo_data(saltenv=u'base')
          Returns  the  existing package meteadata db.  Will create it, if
          it does not exist, however will not refresh it.

          Parameters
                 saltenv (str) -- Salt environment. Default base

          Returns
                 Returns a dict containing contents of metadata db.

          Return type
                 dict

          CLI Example:

             salt '*' pkg.get_repo_data

   salt.modules.win_pkg.install(name=None,    refresh=False,    pkgs=None,
   **kwargs)
          Install the passed package(s) on the system using winrepo

          Parameters

                 * name  (str,  list,  or  None)  --  The name of a single
                   package, or  a  comma-separated  list  of  packages  to
                   install. (no spaces after the commas)

                 * refresh (bool) -- Boolean value representing whether or
                   not to refresh the winrepo db

                 * pkgs (list or None) -- A list of  packages  to  install
                   from  a software repository.  All packages listed under
                   pkgs will be installed via a single command.

          Keyword Arguments (kwargs)

          Parameters

                 * version (str) -- The specific version  to  install.  If
                   omitted,  the  latest  version  will  be  installed. If
                   passed with multiple install, the version will apply to
                   all packages. Recommended for single installation only.

                 * cache_file  (str) -- A single file to copy down for use
                   with the installer. Copied to the same location as  the
                   installer.  Use  this  over cache_dir if there are many
                   files in the directory and you  only  need  a  specific
                   file  and don't want to cache additional files that may
                   reside in the  installer  directory.  Only  applies  to
                   files on salt://

                 * cache_dir  (bool) -- True will copy the contents of the
                   installer directory. This is useful  for  installations
                   that are not a single file. Only applies to directories
                   on salt://

                 * saltenv (str) -- Salt environment. Default 'base'

                 * report_reboot_exit_codes (bool) --

                   If the installer exits  with  a  recognized  exit  code
                   indicating  that  a  reboot  is  required,  the  module
                   function
                      win_system.set_reboot_required_witnessed

                   will be called, preserving the knowledge of this  event
                   for  the remainder of the current boot session. For the
                   time being, 3010 is the only recognized exit code.  The
                   value of this param defaults to True.

                   New in version 2016.11.0.

          Returns
                 Return  a  dict  containing  the  new  package  names and
                 versions:

          Return type
                 dict

                 If the package is installed by pkg.install:

                    {'<package>': {'old': '<old-version>',
                                   'new': '<new-version>'}}

                 If the package is already installed:

                    {'<package>': {'current': '<current-version>'}}

          The following example will refresh the  winrepo  and  install  a
          single package, 7zip.

          CLI Example:

             salt '*' pkg.install 7zip refresh=True

          CLI Example:

             salt '*' pkg.install 7zip
             salt '*' pkg.install 7zip,filezilla
             salt '*' pkg.install pkgs='["7zip","filezilla"]'

          WinRepo Definition File Examples:

          The  following  example demonstrates the use of cache_file. This
          would be used if  you  have  multiple  installers  in  the  same
          directory  that use the same install.ini file and you don't want
          to download the additional installers.

             ntp:
               4.2.8:
                 installer: 'salt://win/repo/ntp/ntp-4.2.8-win32-setup.exe'
                 full_name: Meinberg NTP Windows Client
                 locale: en_US
                 reboot: False
                 cache_file: 'salt://win/repo/ntp/install.ini'
                 install_flags: '/USEFILE=C:\salt\var\cache\salt\minion\files	ase\win\repo\ntp\install.ini'
                 uninstaller: 'NTP/uninst.exe'

          The following example demonstrates  the  use  of  cache_dir.  It
          assumes  a  file named install.ini resides in the same directory
          as the installer.

             ntp:
               4.2.8:
                 installer: 'salt://win/repo/ntp/ntp-4.2.8-win32-setup.exe'
                 full_name: Meinberg NTP Windows Client
                 locale: en_US
                 reboot: False
                 cache_dir: True
                 install_flags: '/USEFILE=C:\salt\var\cache\salt\minion\files	ase\win\repo\ntp\install.ini'
                 uninstaller: 'NTP/uninst.exe'

   salt.modules.win_pkg.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

          Keyword Arguments (kwargs) :param str saltenv: Salt environment.
          Default base :param  bool  refresh:  Refresh  package  metadata.
          Default True

   salt.modules.win_pkg.list_available(*names, **kwargs)
          Return a list of available versions of the specified package.

          Parameters
                 name (str) -- One or more package names

          Returns
                 For multiple package names listed returns dict of package
                 names and versions For  single  package  name  returns  a
                 version string

          Return type
                 dict or string

          Keyword   Arguments   (kwargs)  :param  str  saltenv:  The  salt
          environment to use. Default base.  :param bool refresh:  Refresh
          package metadata. Default True.  :param bool return_dict_always:
          Default False dict when a single package name is queried.

          CLI Example:
             salt     '*'      pkg.list_available      <package      name>
             return_dict_always=True  salt '*' pkg.list_available <package
             name01> <package name02>

   salt.modules.win_pkg.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             *Keyword Arguments (kwargs)*

          Parameters

                 * saltenv (str) -- The salt environment to  use.  Default
                   base.

                 * refresh (bool) --

                   Refresh package metadata. Default
                   ``
                   False`.

                   {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs
             salt '*' pkg.list_pkgs versions_as_list=True

   salt.modules.win_pkg.list_upgrades(refresh=True, **kwargs)
          List all available package upgrades on this system

          Parameters
                 refresh (bool) -- Refresh package metadata. Default True

          Keyword Arguments (kwargs) :param str saltenv: Salt environment.
          Default base

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.win_pkg.purge(name=None,     pkgs=None,      version=None,
   **kwargs)
          Package  purges are not supported, this function is identical to
          remove().

          name   The name of the package to be deleted.

          version
                 The version of the package to be deleted. If this  option
                 is  used  in combination with the pkgs option below, then
                 this version will be applied to all targeted packages.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          Keyword Arguments (kwargs) :param str saltenv: Salt environment.
          Default  base  :param  bool  refresh:  Refresh package metadata.
          Default False

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.win_pkg.refresh_db(**kwargs)
          Fectches metadata files and calls pkg.genrepo to compile updated
          repository metadata.

          CLI Example:

             salt '*' pkg.refresh_db
             salt '*' pkg.refresh_db saltenv=base

   salt.modules.win_pkg.remove(name=None,     pkgs=None,     version=None,
   **kwargs)
          Remove the passed package(s) from the system using winrepo

          Parameters

                 * name (str, list, or None) -- The name of the package to
                   be uninstalled.

                 * version  (str)  --  The  version  of  the package to be
                   uninstalled. If this option is  used  to  to  uninstall
                   multiple packages, then this version will be applied to
                   all targeted  packages.  Recommended  using  only  when
                   uninstalling  a  single  package.  If this parameter is
                   omitted, the latest version will be uninstalled.

          Multiple Package Options:

          Parameters
                 pkgs (list or None) -- A list of packages to delete. Must
                 be  passed  as  a python list. The name parameter will be
                 ignored if this option is passed.

          New in version 0.16.0.

          Keyword Arguments (kwargs) :param str saltenv: Salt environment.
          Default  base  :param  bool  refresh:  Refresh package metadata.
          Default False

          Returns
                 Returns a dict containing the changes.

          Return type
                 dict

                 If the package is removed by pkg.remove:

                    {'<package>': {'old': '<old-version>',
                           'new': '<new-version>'}}

                 If the package is already uninstalled:
                    {'<package>': {'current': 'not installed'}}

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.win_pkg.upgrade(**kwargs)
          Upgrade all software. Currently not implemented

          Keyword  Arguments  (kwargs)  :param  str  saltenv:   The   salt
          environment  to use. Default base.  :param bool refresh: Refresh
          package metadata. Default True.

          NOTE:
             This feature is not yet implemented for Windows.

          CLI Example:

             salt '*' pkg.upgrade

   salt.modules.win_pkg.upgrade_available(name, **kwargs)
          Check whether or not an upgrade is available for a given package

          Parameters
                 name -- The name of a single package

          Returns
                 Return True if newer version available

          Return type
                 bool

          Keyword Arguments (kwargs) :param str saltenv: Salt  environment
          :param bool refresh: Refresh package metadata. Default True

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.win_pkg.version(*names, **kwargs)
          Returns  a  version if the package is installed, else returns an
          empty string

          Parameters
                 name (str) -- One or more package names

          Returns
                 For multiple package names listed returns dict of package
                 names and current version For single package name returns
                 a current version string

          Return type
                 dict or string

          Keyword  Arguments  (kwargs)  :param  str  saltenv:   The   salt
          environment  to use. Default base.  :param bool refresh: Refresh
          package metadata. Default False.

          CLI Example:
             salt '*' pkg.version  <package  name>  salt  '*'  pkg.version
             <package name01> <package name02>

   salt.modules.win_powercfg
   This  module  allows  you  to  control  the power settings of a windows
   minion via powercfg.

   New in version 2015.8.0.

      salt '*' powercfg.set_monitor_timeout 0 power=dc
      salt '*' powercfg.set_disk_timeout 120 power=ac

   salt.modules.win_powercfg.get_disk_timeout()
          Get the current disk timeout of the current scheme

          CLI Example:

             salt '*' powercfg.get_disk_timeout

   salt.modules.win_powercfg.get_hibernate_timeout()
          Get the current hibernate timeout of the current scheme

          CLI Example:

             salt '*' powercfg.get_hibernate_timeout

   salt.modules.win_powercfg.get_monitor_timeout()
          Get the current monitor timeout of the current scheme

          CLI Example:

             salt '*' powercfg.get_monitor_timeout

   salt.modules.win_powercfg.get_standby_timeout()
          Get the current standby timeout of the current scheme

          CLI Example:

             salt '*' powercfg.get_standby_timeout

   salt.modules.win_powercfg.set_disk_timeout(timeout, power='ac')
          Set the disk timeout in minutes for the current power scheme

          CLI Example:

             salt '*' powercfg.set_disk_timeout 30 power=dc

          timeout
                 The amount of  time  in  minutes  before  the  disk  will
                 timeout

          power  Should  we  set  the  value for AC or DC (battery)? Valid
                 options ac,dc.

   salt.modules.win_powercfg.set_hibernate_timeout(timeout, power='ac')
          Set the hibernate timeout  in  minutes  for  the  current  power
          scheme

          CLI Example:

             salt '*' powercfg.set_hibernate_timeout 30 power=pc

          timeout
                 The  amount  of  time  in  minutes  before  the  computer
                 hibernates

          power  Should we set the value for AC  or  DC  (battery)?  Valid
                 options ac,dc.

   salt.modules.win_powercfg.set_monitor_timeout(timeout, power='ac')
          Set the monitor timeout in minutes for the current power scheme

          CLI Example:

             salt '*' powercfg.set_monitor_timeout 30 power=ac

          timeout
                 The  amount  of  time  in minutes before the monitor will
                 timeout

          power  Should we set the value for AC  or  DC  (battery)?  Valid
                 options ac,dc.

   salt.modules.win_powercfg.set_standby_timeout(timeout, power='ac')
          Set the standby timeout in minutes for the current power scheme

          CLI Example:

             salt '*' powercfg.set_standby_timeout 30 power=dc

          timeout
                 The amount of time in minutes before the computer sleeps

          power  Should  we  set  the  value for AC or DC (battery)? Valid
                 options ac,dc.

   salt.modules.win_repo
   Module to manage Windows software repo on a Standalone Minion

   file_client: local must be set in the minion config file.

   For documentation on Salt's Windows Repo feature, see here.

   salt.modules.win_repo.genrepo()
          Generate winrepo_cachefile based on sls files in the winrepo_dir

          CLI Example:

             salt-call winrepo.genrepo

   salt.modules.win_repo.show_sls(name, saltenv='base')
          New in version 2015.8.0.

          Display the rendered software definition  from  a  specific  sls
          file  in the local winrepo cache. This will parse all Jinja. Run
          pkg.refresh_db to pull the latest software definitions from  the
          master.

          NOTE:
             This  function  does  not  ask  a  master  for an sls file to
             render. Instead it directly processes the file  specified  in
             name

          Parameters

                 * str  (saltenv) -- The name/path of the package you want
                   to view. This can be the

                 * path to a file on the minion file system or a  file  on
                   the local (full) --

                 * cache. (minion) --

                 * str -- The default environment is base

          Returns
                 Returns   a   dictionary  containing  the  rendered  data
                 structure

          Return type
                 dict

          NOTE:
             To use a file from the minion  cache  start  from  the  local
             winrepo                                                  root
             (C:\salt\var\cache\salt\minion\files	ase\win\repo-ng).    If
             you  have  .sls files organized in subdirectories you'll have
             to denote them with ..  For  example,  if  you  have  a  test
             directory  in  the  winrepo root with a gvim.sls file inside,
             would target that file like so: test.gvim. Directories can be
             targeted  as well as long as they contain an init.sls inside.
             For example, if you have a node directory  with  an  init.sls
             inside, target that like so: node.

          CLI Example:

             salt '*' winrepo.show_sls gvim
             salt '*' winrepo.show_sls test.npp
             salt '*' winrepo.show_sls C:\test\gvim.sls

   salt.modules.win_repo.update_git_repos(clean=False)
          Checkout   git   repos   containing   Windows  Software  Package
          Definitions.

          IMPORTANT:
             This function requires Git for Windows  to  be  installed  in
             order  to  work.  When  installing,  make  sure  to select an
             installation option which permits the git  executable  to  be
             run from the Command Prompt.

          clean  False Clean repo cachedirs which are not configured under
                 winrepo_remotes.

                 NOTE:
                    This option only applies if either pygit2 or GitPython
                    is installed into Salt's bundled Python.

                 WARNING:
                    This  argument  should  not be set to True if a mix of
                    git and non-git repo definitions are being used, as it
                    will  result  in  the  non-git  repo definitions being
                    removed.

                 New in version 2015.8.0.

          CLI Example:

             salt-call winrepo.update_git_repos

   salt.modules.win_servermanager
   Manage Windows features via the ServerManager powershell module

   salt.modules.win_servermanager.install(feature,          recurse=False,
   restart=False, source=None, exclude=None)
          Install a feature

          NOTE:
             Some  features  require  reboot  after un/installation, if so
             until the server is  restarted  other  features  can  not  be
             installed!

          NOTE:
             Some  features  take a long time to complete un/installation,
             set -t with a long timeout

          Parameters

                 * feature (str) -- The name of the feature to install

                 * recurse (bool) -- Install all sub-features. Default  is
                   False

                 * source  (str)  --  Path  to the source files if missing
                   from the target system. None means that the system will
                   use windows update services to find the required files.
                   Default is None

                 * restart  (bool)   --   Restarts   the   computer   when
                   installation   is   complete,   if   required   by  the
                   role/feature installed. Default is False

                 * exclude (str) --

                   The name of the feature to exclude when installing  the
                   named feature.

                   NOTE:
                      As    there   is   no   exclude   option   for   the
                      Add-WindowsFeature  command,  the  feature  will  be
                      installed  with  other sub-features and will then be
                      removed.

                 * restart -- Restarts the computer when  installation  is
                   complete, if required by the role feature installed.

          Returns
                 A dictionary containing the results of the install

          Return type
                 dict

          CLI Example:

             salt '*' win_servermanager.install Telnet-Client
             salt '*' win_servermanager.install SNMP-Service True
             salt '*' win_servermanager.install TFTP-Client source=d:\side-by-side

   salt.modules.win_servermanager.list_available()
          List available features to install

          Returns
                 A list of available features

          Return type
                 list

          CLI Example:

             salt '*' win_servermanager.list_available

   salt.modules.win_servermanager.list_installed()
          List  installed  features.  Supported on Windows Server 2008 and
          Windows 8 and newer.

          Returns
                 A list of installed features

          Return type
                 list

          CLI Example:

             salt '*' win_servermanager.list_installed

   salt.modules.win_servermanager.remove(feature,    remove_payload=False,
   restart=False)
          Remove an installed feature

          NOTE:
             Some      features      require      a      reboot      after
             installation/uninstallation. If one  of  these  features  are
             modified,  then  other features cannot be installed until the
             server is restarted. Additionally, some features take a while
             to complete installation/uninstallation, so it is a good idea
             to use the -t option to set a longer timeout.

          Parameters

                 * feature (str) -- The name of the feature to remove

                 * remove_payload (bool) -- True will cause the feature to
                   be     removed     from    the    side-by-side    store
                   (%SystemDrive%:\Windows\WinSxS). Default is False

                 * restart (bool) -- Restarts the computer when  uninstall
                   is  complete,  if required by the role/feature removed.
                   Default is False

          Returns
                 A dictionary containing the results of the uninstall

          Return type
                 dict

          CLI Example:

             salt -t 600 '*' win_servermanager.remove Telnet-Client

   salt.modules.win_service
   Windows Service module.

   Changed in version 2016.11.0: - Rewritten to use PyWin32

   salt.modules.win_service.available(name)
          Check if a service is available on the system.

          Parameters
                 name (str) -- The name of the service to check

          Returns
                 True if the service is available, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.available <service name>

   salt.modules.win_service.config(name, bin_path=None, display_name=None,
   svc_type=None,   start_type=None,   error=None,  group=None,  tag=None,
   depend=None, obj=None, password=None, **kwargs)
          Deprecated since version 2016.11.0: Use service.modify instead

          Modify the named service. Because this is deprecated it will use
          the passed parameters to run service.modify instead.

          Parameters

                 * name  (str)  -- Specifies the service name. This is not
                   the display_name

                 * bin_path (str) -- Specifies the  path  to  the  service
                   binary file.

                 * must     be     escaped,     eg     (Backslashes)    --
                   C:\path\to	inary.exe

                 * display_name (str) -- the name to be displayed  in  the
                   service manager

                 * svc_type  (str)  -- Specifies the service type. Default
                   is own.

                 * options are as follows (Valid) -- .INDENT 2.0

                 * kernel: Driver service

                 * filesystem: File system driver service

                 * adapter: Adapter driver service (reserved)

                 * recognizer: Recognizer driver service (reserved)

                 * own (default): Service runs in its own process

                 * share: Service shares a process with one or more  other
                   services

          * start_type  (str)  --  Specifies the service start type. Valid
            options are as follows: - boot: Device driver that  is  loaded
            by  the  boot  loader  - system: Device driver that is started
            during   kernel   initialization   -   auto:   Service    that
            automatically  starts  -  manual  (default):  Service  must be
            started manually - disabled: Service cannot be started

          * error (str) -- The severity of the error, and action taken, if
            this

          * fails  to  start.  Valid  options  are as follows (service) --
            .INDENT 2.0

          * normal  (normal):  Error  is  logged  and  a  message  box  is
            displayed

          * severe:  Error  is logged and computer attempts a restart with
            the last known good configuration

          * critical: Error is logged, computer attempts to  restart  with
            the last known good configuration, system halts on failure

          * ignore: Error is logged and startup continues, no notification
            is given to the user

   * group -- The name of the load  order  group  to  which  this  service
     belongs

   * depend (list) -- A list of services or load ordering groups that

   * start before this service (must) --

   * obj (str) -- The name of the account under which the service

   * run. For own type services this should be in the (should) --

   * format.    The    following    are   examples   of   valid   built-in
     (domain\username) --

   * accounts (service) -- .INDENT 2.0

   * NT Authority\LocalService

   * NT Authority\NetworkService

   * NT Authority\LocalSystem

   * .\LocalSystem

   * password (str) -- The password for the account name specified in

   * For the above built-in accounts, this can be None. (account_name.) --

   * a password must be specified. (Otherwise) --
             salt '*' service.config <service name> <path to exe> display_name='<display name>'

   salt.modules.win_service.create(name,     bin_path,      exe_args=None,
   display_name=None,         description=None,        service_type='own',
   start_type='manual',    start_delayed=False,    error_control='normal',
   load_order_group=None,                               dependencies=None,
   account_name='.\\LocalSystem',                   account_password=None,
   run_interactive=False, **kwargs)
          Create the named service.

          New in version 2015.8.0.

          Parameters

                 * name  (str)  -- Specifies the service name. This is not
                   the display_name

                 * bin_path (str) -- Specifies the  path  to  the  service
                   binary file.

                 * must     be     escaped,     eg     (Backslashes)    --
                   C:\path\to	inary.exe

                 * exe_args (str) -- Any additional arguments required  by
                   the service binary.

                 * display_name  (str)  -- the name to be displayed in the
                   service manager

                 * description (str) -- A description of the service

                 * service_type  (str)  --  Specifies  the  service  type.
                   Default is own.

                 * options are as follows (Valid) -- .INDENT 2.0

                 * kernel: Driver service

                 * filesystem: File system driver service

                 * adapter: Adapter driver service (reserved)

                 * recognizer: Recognizer driver service (reserved)

                 * own (default): Service runs in its own process

                 * share:  Service shares a process with one or more other
                   services

          * start_type (str) -- Specifies the service  start  type.  Valid
            options are as

          * follows -- .INDENT 2.0

          * boot: Device driver that is loaded by the boot loader

          * system:   Device   driver   that   is  started  during  kernel
            initialization

          * auto: Service that automatically starts

          * manual (default): Service must be started manually

          * disabled: Service cannot be started

   * start_delayed (bool) -- Set the service to Auto(Delayed Start).  Only
     valid

   * the  start_type  is  set  to Auto. If service_type is not passed, but
     (if) --

   * service is already set to Auto, then the flag will be set. (the) --

   * is False (Default) --

   * error_control (str) -- The severity of the error, and  action  taken,
     if

   * service  fails  to  start.  Valid  options  are  as follows (this) --
     .INDENT 2.0

   * normal (normal): Error is logged and a message box is displayed

   * severe: Error is logged and computer attempts a restart with the last
     known good configuration

   * critical: Error is logged, computer attempts to restart with the last
     known good configuration, system halts on failure

   * ignore: Error is logged and startup  continues,  no  notification  is
     given to the user

   * load_order_group  --  The  name of the load order group to which this
     service belongs

   * dependencies (list) -- A list of services  or  load  ordering  groups
     that

   * start before this service (must) --

   * account_name (str) -- The name of the account under which the service

   * run. For own type services this should be in the (should) --

   * format.    The    following    are   examples   of   valid   built-in
     (domain\username) --

   * accounts (service) -- .INDENT 2.0

   * NT Authority\LocalService

   * NT Authority\NetworkService

   * NT Authority\LocalSystem

   * .\LocalSystem

   * account_password (str) -- The password for the account name specified
     in

   * For the above built-in accounts, this can be None. (account_name.) --

   * a password must be specified. (Otherwise) --

   * run_interactive  (bool)  -- If this setting is True, the service will
     be

   * to interact with the user. Not  recommended  for  services  that  run
     (allowed) --

   * elevated privileges. (with) --

   Returns
          A dictionary containing information about the new service

   Return type
          dict
             salt '*' service.create <service name> <path to exe> display_name='<display name>'

   salt.modules.win_service.create_win_salt_restart_task()
          Create a task in Windows task scheduler to enable restarting the
          salt-minion

          CLI Example:

             salt '*' service.create_win_salt_restart_task()

   salt.modules.win_service.delete(name)
          Delete the named service

          Parameters
                 name (str) -- The name of the service to delete

          Returns
                 True if successful, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.delete <service name>

   salt.modules.win_service.disable(name, **kwargs)
          Disable the named service to start at boot

          Parameters
                 name (str) -- The name of the service to disable

          Returns
                 True if disabled, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.disable <service name>

   salt.modules.win_service.disabled(name)
          Check to see if the named service is disabled to start on boot

          Parameters
                 name (str) -- The name of the service to check

          Returns
                 True if the service is disabled

          Return type
                 bool

          CLI Example:

             salt '*' service.disabled <service name>

   salt.modules.win_service.enable(name, **kwargs)
          Enable the named service to start at boot

          Parameters
                 name (str) -- The name of the service to enable.

          Returns
                 True if successful, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.enable <service name>

   salt.modules.win_service.enabled(name, **kwargs)
          Check to see if the named service is enabled to start on boot

          Parameters
                 name (str) -- The name of the service to check

          Returns
                 True if the service is set to start

          Return type
                 bool

          CLI Example:

             salt '*' service.enabled <service name>

   salt.modules.win_service.execute_salt_restart_task()
          Run the Windows Salt restart task

          CLI Example:

             salt '*' service.execute_salt_restart_task()

   salt.modules.win_service.get_all()
          Return all installed services

          Returns
                 Returns a list of all services on the system.

          Return type
                 list

          CLI Example:

             salt '*' service.get_all

   salt.modules.win_service.get_disabled()
          Return a list of disabled services. Disabled  is  defined  as  a
          service that is marked 'Disabled' or 'Manual'.

          Returns
                 A list of disabled services.

          Return type
                 list

          CLI Example:

             salt '*' service.get_disabled

   salt.modules.win_service.get_enabled()
          Return  a  list  of  enabled  services.  Enabled is defined as a
          service that is marked to Auto Start.

          Returns
                 A list of enabled services

          Return type
                 list

          CLI Example:

             salt '*' service.get_enabled

   salt.modules.win_service.get_service_name(*args)
          The  Display  Name  is  what  is  displayed  in   Windows   when
          services.msc  is  executed.  Each Display Name has an associated
          Service Name which is the actual  name  of  the  service.   This
          function  allows you to discover the Service Name by returning a
          dictionary of Display Names and  Service  Names,  or  filter  by
          adding arguments of Display Names.

          If  no  args are passed, return a dict of all services where the
          keys are the service  Display  Names  and  the  values  are  the
          Service Names.

          If  arguments  are  passed,  create  a dict of Display Names and
          Service Names

          CLI Examples:

             salt '*' service.get_service_name
             salt '*' service.get_service_name 'Google Update Service (gupdate)' 'DHCP Client'

   salt.modules.win_service.getsid(name)
          Return the SID for this windows service

          Parameters
                 name (str) -- The name of the service for which to return
                 the SID

          Returns
                 A string representing the SID for the service

          Return type
                 str

          CLI Example:

             salt '*' service.getsid <service name>

   salt.modules.win_service.info(name)
          Get information about a service on the system

          Parameters

                 * name  (str) -- The name of the service. This is not the
                   display name. Use

                 * to find the service name. (get_service_name) --

          Returns
                 A dictionary containing information about the service.

          Return type
                 dict

          CLI Example:

             salt '*' service.info spooler

   salt.modules.win_service.missing(name)
          The inverse of service.available.

          Parameters
                 name (str) -- The name of the service to check

          Returns
                 True if the service is missing, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.missing <service name>

   salt.modules.win_service.modify(name,   bin_path=None,   exe_args=None,
   display_name=None,         description=None,         service_type=None,
   start_type=None,        start_delayed=None,         error_control=None,
   load_order_group=None,       dependencies=None,      account_name=None,
   account_password=None, run_interactive=None)
          Modify a service's parameters. Changes  will  not  be  made  for
          parameters that are not passed.

          New in version 2016.11.0.

          Parameters

                 * name  (str)  --  The  name of the service. Can be found
                   using the

                 * function (service.get_service_name) --

                 * bin_path (str) -- The path to the  service  executable.
                   Backslashes must be

                 * eg (escaped,) -- C:\path\to	inary.exe

                 * exe_args (str) -- Any arguments required by the service
                   executable

                 * display_name (str)  --  The  name  to  display  in  the
                   service manager

                 * description (str) -- The description to display for the
                   service

                 * service_type  (str)  --  Specifies  the  service  type.
                   Default is own.

                 * options are as follows (Valid) -- .INDENT 2.0

                 * kernel: Driver service

                 * filesystem: File system driver service

                 * adapter: Adapter driver service (reserved)

                 * recognizer: Recognizer driver service (reserved)

                 * own (default): Service runs in its own process

                 * share:  Service shares a process with one or more other
                   services

          * start_type (str) -- Specifies the service  start  type.  Valid
            options  are  as follows: - boot: Device driver that is loaded
            by the boot loader - system: Device  driver  that  is  started
            during    kernel   initialization   -   auto:   Service   that
            automatically  starts  -  manual:  Service  must  be   started
            manually - disabled: Service cannot be started

          * start_delayed  (bool)  --  Set  the  service  to  Auto(Delayed
            Start). Only valid

          * the start_type is set to Auto. If service_type is not  passed,
            but (if) --

          * service  is  already  set  to Auto, then the flag will be set.
            (the) --

          * error_control (str) -- The severity of the error,  and  action
            taken, if

          * service fails to start. Valid options are as follows (this) --
            .INDENT 2.0

          * normal: Error is logged and a message box is displayed

          * severe: Error is logged and computer attempts a  restart  with
            the last known good configuration

          * critical:  Error  is logged, computer attempts to restart with
            the last known good configuration, system halts on failure

          * ignore: Error is logged and startup continues, no notification
            is given to the user

   * load_order_group  --  The  name of the load order group to which this
     service belongs

   * dependencies (list) -- A list of services  or  load  ordering  groups
     that

   * start before this service (must) --

   * account_name (str) -- The name of the account under which the service

   * run. For own type services this should be in the (should) --

   * format.    The    following    are   examples   of   valid   built-in
     (domain\username) --

   * accounts (service) -- .INDENT 2.0

   * NT Authority\LocalService

   * NT Authority\NetworkService

   * NT Authority\LocalSystem

   * .LocalSystem

   * account_password (str) -- The password for the account name specified
     in

   * For the above built-in accounts, this can be None. (account_name.) --

   * a password must be specified. (Otherwise) --

   * run_interactive  (bool)  -- If this setting is True, the service will
     be

   * to interact with the user. Not  recommended  for  services  that  run
     (allowed) --

   * elevated privileges. (with) --
             salt '*' service.modify spooler start_type=disabled

   salt.modules.win_service.restart(name)
          Restart  the  named service. This issues a stop command followed
          by a start.

          Parameters
                 name -- The name of the service to restart.

          NOTE:
             If the name passed is salt-minion a scheduled task is created
             and executed to restart the salt-minion service.

          Returns
                 True if successful, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.restart <service name>

   salt.modules.win_service.start(name)
          Start the specified service.

          WARNING:
             You  cannot  start  a  disabled  service  in  Windows. If the
             service is disabled, it will be changed to Manual start.

          Parameters
                 name (str) -- The name of the service to start

          Returns
                 True if successful, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.start <service name>

   salt.modules.win_service.status(name, sig=None)
          Return the status for a service

          Parameters

                 * name (str) -- The name of the service to check

                 * sig (str) -- Not supported on Windows

          Returns
                 True if running, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.status <service name> [service signature]

   salt.modules.win_service.stop(name)
          Stop the specified service

          Parameters
                 name (str) -- The name of the service to stop

          Returns
                 True if successful, False otherwise

          Return type
                 bool

          CLI Example:

             salt '*' service.stop <service name>

   salt.modules.win_shadow
   Manage the shadow file

   IMPORTANT:
      If you feel  that  Salt  should  be  using  this  module  to  manage
      passwords  on a minion, and it is using a different module (or gives
      an error similar to 'shadow.info' is not available), see here.

   salt.modules.win_shadow.info(name)
          Return information for the specified user This is  just  returns
          dummy data so that salt states can work.

          Parameters
                 name (str) -- The name of the user account to show.

          CLI Example:

             salt '*' shadow.info root

   salt.modules.win_shadow.require_password_change(name)
          Require the user to change their password the next time they log
          in.

          Parameters
                 name -- The  name  of  the  user  account  to  require  a
                 password change.

          Returns
                 True if successful. False if unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.require_password_change <username>

   salt.modules.win_shadow.set_expire(name, expire)
          Set the expiration date for a user account.

          Parameters

                 * name -- The name of the user account to edit.

                 * expire -- The date the account will expire.

          Returns
                 True if successful. False if unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.set_expire <username> 2016/7/1

   salt.modules.win_shadow.set_password(name, password)
          Set the password for a named user.

          Parameters

                 * name (str) -- The name of the user account

                 * password (str) -- The new password

          Returns
                 True if successful. False if unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.set_password root mysecretpassword

   salt.modules.win_shadow.unlock_account(name)
          Unlocks a user account.

          Parameters
                 name -- The name of the user account to unlock.

          Returns
                 True if successful. False if unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' shadow.unlock_account <username>

   salt.modules.win_status
   Module  for  returning  various status data about a minion.  These data
   can be useful for compiling into stats later, or for problem solving if
   your minion is having problems.

   New in version 0.12.0.

   depends

          * pythoncom

          * wmi

   salt.modules.win_status.cpuload()
          New in version 2015.8.0.

          Return the processor load as a percentage

          CLI Example:

             salt '*' status.cpuload

   salt.modules.win_status.diskusage(human_readable=False, path=None)
          New in version 2015.8.0.

          Return the disk usage for this minion

          human_readable
                 False If True, usage will be in KB/MB/GB etc.

          CLI Example:

             salt '*' status.diskusage path=c:/salt

   salt.modules.win_status.master(master=None, connected=True)
          New in version 2015.5.0.

          Fire  an  event if the minion gets disconnected from its master.
          This function is meant to be run via a scheduled  job  from  the
          minion.  If master_ip is an FQDN/Hostname, is must be resolvable
          to a valid IPv4 address.

          CLI Example:

             salt '*' status.master

   salt.modules.win_status.procs(count=False)
          Return the process data

          count  False If True,  this  function  will  simply  return  the
                 number of processes.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' status.procs
             salt '*' status.procs count

   salt.modules.win_status.saltmem(human_readable=False)
          New in version 2015.8.0.

          Returns the amount of memory that salt is using

          human_readable
                 False return the value in a nicely formatted number

          CLI Example:

             salt '*' status.saltmem
             salt '*' status.saltmem human_readable=True

   salt.modules.win_status.uptime(human_readable=False)
          New in version 2015.8.0.

          Return the system uptime for this machine in seconds

          human_readable
                 False  If  True,  then  return uptime in years, days, and
                 seconds.

          CLI Example:

             salt '*' status.uptime
             salt '*' status.uptime human_readable=True

   salt.modules.win_system
   Module for managing windows systems.

   depends

          * win32net

   Support for reboot, shutdown, etc

   salt.modules.win_system.get_computer_desc()
          Get the Windows computer description :return:
             Returns the computer description if found. Otherwise  returns
             False

          CLI Example:

             salt 'minion-id' system.get_computer_desc

   salt.modules.win_system.get_computer_name()
          Get the Windows computer name

          Returns
                 Returns  the  computer  name  if found. Otherwise returns
                 False

          CLI Example:

             salt 'minion-id' system.get_computer_name

   salt.modules.win_system.get_domain_workgroup()
          Get the domain or workgroup the computer belongs to.

          New in version 2015.5.7.

          New in version 2015.8.2.

          Returns
                 The name of the domain or workgroup

          Return type
                 str

          CLI Example:

             salt 'minion-id' system.get_domain_workgroup

   salt.modules.win_system.get_hostname()
          New in version 2016.3.0.

          Get the hostname of the windows minion

          Returns
                 Returns the hostname of the windows minion

          CLI Example:

             salt 'minion-id' system.get_hostname

   salt.modules.win_system.get_pending_component_servicing()
          Determine whether there are pending  Component  Based  Servicing
          tasks that require a reboot.

          Returns
                 A   boolean   representing   whether  there  are  pending
                 Component Based Servicing tasks.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_component_servicing

   salt.modules.win_system.get_pending_computer_name()
          Get a pending computer name.  If  the  computer  name  has  been
          changed,  and  the  change  is  pending  a  system  reboot, this
          function will return the pending computer name. Otherwise,  None
          will  be  returned. If there was an error retrieving the pending
          computer name, False will be returned, and an error message will
          be logged to the minion log.

          Returns
                 Returns the pending name if pending restart. Returns none
                 if not pending restart.

          CLI Example:

             salt 'minion-id' system.get_pending_computer_name

   salt.modules.win_system.get_pending_domain_join()
          Determine whether there is a pending  domain  join  action  that
          requires a reboot.

          Returns
                 A  boolean representing whether there is a pending domain
                 join action.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_domain_join

   salt.modules.win_system.get_pending_file_rename()
          Determine whether there are pending file rename operations  that
          require a reboot.

          Returns
                 A  boolean  representing  whether  there are pending file
                 rename operations.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_file_rename

   salt.modules.win_system.get_pending_reboot()
          Determine whether there is a reboot pending.

          Returns
                 A boolean representing whether reboots are pending.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_reboot

   salt.modules.win_system.get_pending_servermanager()
          Determine whether there are pending Server  Manager  tasks  that
          require a reboot.

          Returns
                 A  boolean  representing whether there are pending Server
                 Manager tasks.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_servermanager

   salt.modules.win_system.get_pending_update()
          Determine whether there  are  pending  updates  that  require  a
          reboot.

          Returns
                 A boolean representing whether there are pending updates.

          Return type
                 bool

          New in version 2016.11.0.

          CLI Example:

             salt '*' system.get_pending_update

   salt.modules.win_system.get_reboot_required_witnessed()
          New in version 2016.11.0.

          This  tells  us  if, at any time during the current boot session
          the salt minion witnessed an event indicating that a  reboot  is
          required.   (For  the time being, this function will return True
          if an install completed with exit code 3010 during  the  current
          boot session and this usage can be extended where appropriate in
          the future)

          Returns
                 a boolean which will be True if the salt-minion  reported
                 a  required  reboot  during  the  current  boot  session,
                 otherwise False.

          Return type
                 bool

          CLI Example:

             salt '*' system.get_reboot_required_witnessed

   salt.modules.win_system.get_system_date()
          Get the Windows system date

          Returns
                 Returns the system date.

          Return type
                 str

          CLI Example:

             salt '*' system.get_system_date

   salt.modules.win_system.get_system_info()
          Get system information.

          Returns
                 Returns a Dictionary  containing  information  about  the
                 system to include name, description, version, etc...

          Return type
                 dict

          CLI Example:

             salt 'minion-id' system.get_info

   salt.modules.win_system.get_system_time()
          Get the system time.

          Returns
                 Returns the system time in HH:MM:SS AM/PM format.

          Return type
                 str

          CLI Example:

             salt 'minion-id' system.get_system_time

   salt.modules.win_system.halt(timeout=5, in_seconds=False)
          Halt a running system.

          Parameters
                 timeout  (int)  --  Number  of seconds before halting the
                 system.  Default is 5 seconds.

          Returns
                 True is successful.

          Return type
                 bool

          timeout
                 The wait time before the system will be shutdown.

          in_seconds
                 Whether to treat timeout as seconds or minutes.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' system.halt 5

   salt.modules.win_system.init(runlevel)
          Change the system runlevel on sysV compatible systems

          CLI Example:

             salt '*' system.init 3

   salt.modules.win_system.join_domain(domain,              username=None,
   password=None, account_ou=None, account_exists=False, restart=False)
          Join a computer to an Active Directory domain. Requires reboot.

          Parameters

                 * domain (str) -- The domain to which the computer should
                   be joined, e.g.  example.com

                 * username (str) --  Username  of  an  account  which  is
                   authorized  to  join computers to the specified domain.
                   Need to be either fully qualified like  [email protected]
                   or simply user

                 * password (str) -- Password of the specified user

                 * account_ou  (str)  --  The DN of the OU below which the
                   account  for  this  computer  should  be  created  when
                   joining            the           domain,           e.g.
                   ou=computers,ou=departm_432,dc=my-company,dc=com

                 * account_exists (bool) -- If set to  True  the  computer
                   will  only  join  the  domain  if  the  account already
                   exists. If set to False the computer  account  will  be
                   created if it does not exist, otherwise it will use the
                   existing account.  Default is False

                 * restart (bool) --

                   Restarts the computer after a successful join

                   New in version 2015.8.2/2015.5.7.

          Returns
                 Returns   a   dictionary   if   successful.   False    if
                 unsuccessful.

          Return type
                 dict, bool

          CLI Example:

             salt 'minion-id' system.join_domain domain='domain.tld' \
                              username='joinuser' password='joinpassword' \
                              account_ou='ou=clients,ou=org,dc=domain,dc=tld' \
                              account_exists=False, restart=True

   salt.modules.win_system.lock()
          Lock the workstation.

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' system.lock

   salt.modules.win_system.poweroff(timeout=5, in_seconds=False)
          Power off a running system.

          Parameters
                 timeout  (int)  --  Number of seconds before powering off
                 the system.  Default is 5 seconds.

          Returns
                 True if successful

          Return type
                 bool

          timeout
                 The wait time before the system will be shutdown.

          in_seconds
                 Whether to treat timeout as seconds or minutes.

                 New in version 2015.8.0.

          CLI Example:

             salt '*' system.poweroff 5

   salt.modules.win_system.reboot(timeout=5,             in_seconds=False,
   wait_for_reboot=False, only_on_pending_reboot=False)
          Reboot a running system.

          Parameters

                 * timeout  (int)  --  Number  of  minutes/seconds  before
                   rebooting the system. Minutes vs seconds depends on the
                   value of in_seconds.  Default is 5 minutes.

                 * in_seconds (bool) --

                   Whether to treat timeout as seconds or minutes.

                   New in version 2015.8.0.

                 * wait_for_reboot (bool) --

                   Sleeps  for  timeout + 30 seconds after reboot has been
                   initiated.  This is useful for use in a  highstate  for
                   example  where  you  have many states that could be ran
                   after this one. Which you don't  want  to  start  until
                   after  the  restart  i.e  You  could end up with a half
                   finished state.

                   New in version 2015.8.0.

                 * only_on_pending_reboot (bool) --  If  this  is  set  to
                   True,  then  then  the  reboot will only proceed if the
                   system reports a pending reboot. Setting this paramater
                   to True could be useful when calling this function from
                   a final housekeeping state intended to be  executed  at
                   the end of a state run (using order: last).

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt '*' system.reboot 5
             salt '*' system.reboot 5 True

          As  example  of  invoking  this  function  from  within  a final
          housekeeping state is as follows:

          Example:

             final housekeeping:
                module.run:
                   - name: system.reboot
                   - only_on_pending_reboot: True
                   - order: last

   salt.modules.win_system.set_computer_desc(desc=None)
          Set the Windows computer description

          Parameters
                 desc (str) -- The computer description

          Returns
                 False if it fails. Description if successful.

          CLI Example:

             salt 'minion-id' system.set_computer_desc 'This computer belongs to Dave!'

   salt.modules.win_system.set_computer_name(name)
          Set the Windows computer name

          Parameters
                 name (str) -- The new name to give the computer. Requires
                 a reboot to take effect.

          Returns
                 Returns  a dictionary containing the old and new names if
                 successful.  False if not.

          CLI Example:

             salt 'minion-id' system.set_computer_name 'DavesComputer'

   salt.modules.win_system.set_hostname(hostname)
          New in version 2016.3.0.

          Set the hostname of  the  windows  minion,  requires  a  restart
          before this will be updated.

          Parameters
                 hostname (str) -- The hostname to set

          CLI Example:

             salt 'minion-id' system.set_hostname newhostname

   salt.modules.win_system.set_reboot_required_witnessed()
          New in version 2016.11.0.

          This  function is used to remember that an event indicating that
          a reboot is required was witnessed.  This function relies on the
          salt-minion's  ability to create the following volatile registry
          key in the HKLM hive:
             SYSTEM\CurrentControlSet\Services\salt-minion\Volatile-Data

          Because this registry key  is  volatile,  it  will  not  persist
          beyond  the  current  boot  session.  Also, in the scope of this
          key, the name 'Reboot required' will be assigned the value of 1.

          (For the time being, this this function is being  used  whenever
          an  install  completes with exit code 3010 and this usage can be
          extended where appropriate in the future.)

          Returns
                 A boolean indicating whether or not the salt  minion  was
                 able to perform the necessary registry operations.

          Return type
                 bool

          CLI Example:

             salt '*' system.set_reboot_required_witnessed

   salt.modules.win_system.set_system_date(newdate)
          Set the Windows system date. Use <mm-dd-yy> format for the date.

          Parameters
                 newdate  (str)  --  The  date  to  set. Can be any of the
                 following formats - YYYY-MM-DD - MM-DD-YYYY - MM-DD-YY  -
                 MM/DD/YYYY - MM/DD/YY - YYYY/MM/DD

          CLI Example:

             salt '*' system.set_system_date '03-28-13'

   salt.modules.win_system.set_system_date_time(years=None,   months=None,
   days=None, hours=None, minutes=None, seconds=None)
          Set the system date and time. Each argument is an element of the
          date, but not required. If an element is not passed, the current
          system value for that element will be used. For example, if  you
          don't pass the year, the current system year will be used. (Used
          by set_system_date and set_system_time)

          Parameters

                 * years (int) -- Years digit, ie: 2015

                 * months (int) -- Months digit: 1 - 12

                 * days (int) -- Days digit: 1 - 31

                 * hours (int) -- Hours digit: 0 - 23

                 * minutes (int) -- Minutes digit: 0 - 59

                 * seconds (int) -- Seconds digit: 0 - 59

          Returns
                 True if successful. Otherwise False.

          Return type
                 bool

          CLI Example:

             salt '*' system.set_system_date_ time 2015 5 12 11 37 53

   salt.modules.win_system.set_system_time(newtime)
          Set the system time.

          Parameters
                 newtime (str) -- The time to  set.  Can  be  any  of  the
                 following  formats.   -  HH:MM:SS  AM/PM  - HH:MM AM/PM -
                 HH:MM:SS (24 hour) - HH:MM (24 hour)

          Returns
                 Returns True if successful. Otherwise False.

          Return type
                 bool

          CLI Example:

             salt 'minion-id' system.set_system_time 12:01

   salt.modules.win_system.shutdown(message=None,               timeout=5,
   force_close=True,            reboot=False,            in_seconds=False,
   only_on_pending_reboot=False)
          Shutdown a running system.

          Parameters

                 * message (str) -- A  message  to  display  to  the  user
                   before shutting down.

                 * timeout (int) --

                   The  length of time that the shutdown dialog box should
                   be displayed, in seconds.  While  this  dialog  box  is
                   displayed,   the   shutdown   can  be  stopped  by  the
                   shutdown_abort function.

                   If timeout is not zero, InitiateSystemShutdown displays
                   a  dialog box on the specified computer. The dialog box
                   displays the name of the user who called the  function,
                   displays   the   message  specified  by  the  lpMessage
                   parameter, and prompts the user to log off. The  dialog
                   box  beeps  when  it  is  created and remains on top of
                   other windows in the system.  The  dialog  box  can  be
                   moved but not closed. A timer counts down the remaining
                   time before a forced shutdown.

                   If timeout is zero, the  computer  shuts  down  without
                   displaying  the  dialog box, and the shutdown cannot be
                   stopped by shutdown_abort.

                   Default is 5 minutes

                 * in_seconds (bool) --

                   Whether to treat timeout as seconds or minutes.

                   New in version 2015.8.0.

                 * force_close (bool) -- True  to  force  close  all  open
                   applications.  False  displays a dialog box instructing
                   the user to close the applications.

                 * reboot (bool) -- True restarts the computer immediately
                   after shutdown.  False caches to disk and safely powers
                   down the system.

                 * only_on_pending_reboot (bool) --  If  this  is  set  to
                   True,  then  then  shutdown  will  only  proceed if the
                   system reports a pending reboot.

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt '*' system.shutdown 5

   salt.modules.win_system.shutdown_abort()
          Abort a shutdown. Only available while the dialog box  is  being
          displayed  to  the  user.  Once  the  shutdown has initiated, it
          cannot be aborted

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' system.shutdown_abort

   salt.modules.win_system.shutdown_hard()
          Shutdown a running system with no timeout or warning.

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt '*' system.shutdown_hard

   salt.modules.win_system.start_time_service()
          Start the Windows time service

          Returns
                 True if successful. Otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' system.start_time_service

   salt.modules.win_system.stop_time_service()
          Stop the Windows time service

          Returns
                 True if successful. Otherwise False

          Return type
                 bool

          CLI Example:

             salt '*' system.stop_time_service

   salt.modules.win_system.unjoin_domain(username=None,     password=None,
   domain=None, workgroup='WORKGROUP', disable=False, restart=False)
          Unjoin  a  computer  from  an  Active Directory Domain. Requires
          restart.

          Parameters

                 * username -- Username of an account which is  authorized
                   to  manage  computer accounts on the domain. Need to be
                   fully     qualified     like     [email protected]     or
                   domain.tld\user.  If  domain  not specified, the passed
                   domain will be used. If computer account  doesn't  need
                   to be disabled, can be None.

                 * password (str) -- Password of the specified user

                 * domain  (str)  --  The  domain from which to unjoin the
                   computer. Can be None

                 * workgroup (str) -- The workgroup to join  the  computer
                   to. Default is

          WORKGROUP
             New in version 2015.8.2/2015.5.7.

          Parameters

                 * disable  (bool)  --  Disable  the  computer  account in
                   Active Directory. True to disable.  Default is False

                 * restart (bool) --

                   Restart the computer after successful unjoin

                   New in version 2015.8.2/2015.5.7.

          Returns
                 Returns   a   dictionary   if   successful.   False    if
                 unsuccessful.

          Return type
                 dict, bool

          CLI Example:

             salt 'minion-id' system.unjoin_domain restart=True

             salt 'minion-id' system.unjoin_domain username='unjoinuser' \\
                              password='unjoinpassword' disable=True \\
                              restart=True

   salt.modules.win_task module
   Windows Task Scheduler Module

   A  module for working with the Windows Task Scheduler.  You can add and
   edit existing tasks.  You can add and clear triggers and actions.   You
   can list all tasks, folders, triggers, and actions.

   salt.modules.win_task.add_action(name=None,              location='\\',
   action_type='Execute', **kwargs)
          Add an action to a task.

          Parameters

                 * name (str) -- The name of the task to which to add  the
                   action.

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Parameters
                 action_type (str) -- The type of action to add. There are
                 three action

          types. Each one  requires  its  own  set  of  Keyword  Arguments
          (kwargs). Valid values are: - Execute - Email - Message

          kwargs

          Required kwargs for each value:

          Execute Execute a command or an executable.

          Parameters

                 * cmd  (str)  --  (required)  The command / executable to
                   run.

                 * arguments (str) -- (optional) Arguments to be passed to
                   the command /

          executable. To launch a script the first command will need to be
          the interpreter for the script. For example, to run  a  vbscript
          you  would  pass  cscript.exe  in the cmd parameter and pass the
          script in the arguments parameter as follows:

          * cmd='cscript.exe' arguments='c:\scripts\myscript.vbs'

          Batch files do not need an interpreter and may be passed to  the
          cmd parameter directly.

          Parameters
                 start_in   (str)   --   (optional)  The  current  working
                 directory for the

          command.

          Email Send and email. Requires server, from, and to or cc.

          Parameters

                 * from (str) -- The sender

                 * reply_to (str) -- Who to reply to

                 * to (str) -- The recipient

                 * cc (str) -- The CC recipient

                 * bcc (str) -- The BCC recipient

                 * subject (str) -- The subject of the email

                 * body (str) -- The Message Body of the email

                 * server (str) -- The server used to send the email

                 * attachments (list) -- A list of attachments. These will
                   be the paths to

          the   files  to  attach.  ie:  attachments=['C:attachment1.txt',
          'C:attachment2.txt']

          Message Display a dialog box. The task must be set to "Run  only
          when  user is logged on" in order for the dialog box to display.
          Both parameters are required.

          Parameters

                 * title (str) -- The dialog box title.

                 * message (str) -- The dialog box message body

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.add_action <task_name> cmd='del /Q /S C:\\Temp'

   salt.modules.win_task.add_trigger(name=None,             location='\\',
   trigger_type=None,        trigger_enabled=True,        start_date=None,
   start_time=None,   end_date=None,   end_time=None,   random_delay=None,
   repeat_interval=None,                             repeat_duration=None,
   repeat_stop_at_duration_end=False, execution_time_limit=None, **kwargs)

          Parameters

                 * name (str) -- The name of the task to which to add  the
                   trigger.

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Parameters
                 trigger_type (str) -- The type of trigger to create. This
                 is defined when

          the trigger is created and cannot be changed later. Options  are
          as  follows:  -  Event  -  Once  -  Daily  -  Weekly - Monthly -
          MonthlyDay - OnIdle  -  OnTaskCreation  -  OnBoot  -  OnLogon  -
          OnSessionChange

          Parameters
                 trigger_enabled  (bool)  --  Boolean value that indicates
                 whether the

          trigger is enabled.

          Parameters
                 start_date  (str)  --  The  date  when  the  trigger   is
                 activated. If no value

          is  passed,  the  current  date  will be used. Can be one of the
          following formats: - %Y-%m-%d - %m-%d-%y - %m-%d-%Y - %m/%d/%y -
          %m/%d/%Y - %Y/%m/%d

          Parameters
                 start_time   (str)  --  The  time  when  the  trigger  is
                 activated. If no value

          is passed, midnight will be used. Can be one  of  the  following
          formats: - %I:%M:%S %p - %I:%M %p - %H:%M:%S - %H:%M

          Parameters
                 end_date   (str)   --   The  date  when  the  trigger  is
                 deactivated. The trigger

          cannot start the task after it is deactivated. Can be one of the
          following formats: - %Y-%m-%d - %m-%d-%y - %m-%d-%Y - %m/%d/%y -
          %m/%d/%Y - %Y/%m/%d

          Parameters
                 end_time  (str)  --  The  time  when   the   trigger   is
                 deactivated. If the this

          is  not  passed with end_date it will be set to midnight. Can be
          one of the following  formats:  -  %I:%M:%S  %p  -  %I:%M  %p  -
          %H:%M:%S - %H:%M

          Parameters
                 random_delay  (str)  --  The  delay time that is randomly
                 added to the start

          time of the trigger. Valid values are: - 30 seconds = 1 minute -
          30 minutes = 1 hour - 8 hours - 1 day

          Parameters
                 repeat_interval  (str) -- The amount of time between each
                 restart of the

          task. Valid values are: - 5 minutes - 10 minutes - 15 minutes  -
          30 minutes - 1 hour

          Parameters
                 repeat_duration   (str)   --  How  long  the  pattern  is
                 repeated. Valid values

          are: - Indefinitely - 15 minutes - 30 minutes  -  1  hour  -  12
          hours - 1 day

          Parameters
                 repeat_stop_at_duration_end  (bool) -- Boolean value that
                 indicates if a

          running instance of the task  is  stopped  at  the  end  of  the
          repetition pattern duration.

          Parameters
                 execution_time_limit  (str) -- The maximum amount of time
                 that the task

          launched by the trigger is allowed to run. Valid values  are:  -
          30 minutes - 1 hour - 2 hours - 4 hours - 8 hours - 12 hours - 1
          day - 3 days (default)

          kwargs

          There are optional keyword arguments determined by the  type  of
          trigger being defined. They are as follows:

          Event :param str subscription: An event definition in xml format
          that fires the trigger. The easiest way to get this would is  to
          create  an event in windows task scheduler and then copy the xml
          text.

          Once No special parameters required.

          Daily :param int days_interval: The interval between days in the
          schedule.  An  interval  of  1  produces  a  daily  schedule. An
          interval of 2  produces  an  every-other  day  schedule.  If  no
          interval is specified, 1 is used. Valid entries are 1 - 999.

          Weekly  :param int weeks_interval: The interval between weeks in
          the schedule.  An interval of 1 produces a weekly  schedule.  An
          interval  of  2  produces  an  every-other  week schedule. If no
          interval is specified, 1 is used.  Valid entries are 1 - 52.

          param list days_of_week: Sets the days of the week on which  the
          task       runs.       Should      be      a      list.      ie:
          ['Monday','Wednesday','Friday']. Valid entries are the names  of
          the days of the week.

          Monthly  :param list months_of_year: Sets the months of the year
          during  which  the  task   runs.   Should   be   a   list.   ie:
          ['January','July'].  Valid entries are the full names of all the
          months.

          Parameters
                 days_of_month (list) -- Sets the days of the month during
                 which the

          task  runs.  Should  be a list. ie: [1, 15, 'Last']. Options are
          all days of the month 1 - 31 and the word 'Last' to indicate the
          last day of the month.

          Parameters
                 last_day_of_month  (bool) -- Boolean value that indicates
                 that the

          task runs on the last day of the month regardless of the  actual
          date of that day.

          You  can  set  the  task  to run on the last day of the month by
          either including the word 'Last' in the list of days, or setting
          the parameter 'last_day_of_month` equal to True.

          MonthlyDay  :param  list  months_of_year: Sets the months of the
          year  during  which  the  task  runs.  Should  be  a  list.  ie:
          ['January','July'].  Valid entries are the full names of all the
          months.

          Parameters
                 weeks_of_month (list) -- Sets  the  weeks  of  the  month
                 during which the

          task  runs.  Should  be  a  list.  ie:  ['First','Third']. Valid
          options are: - First - Second - Third - Fourth

          Parameters
                 last_week_of_month (bool) -- Boolean value that indicates
                 that the

          task runs on the last week of the month.

          Parameters
                 days_of_week  (list)  -- Sets the days of the week during
                 which the

          task      runs.      Should      be      a       list.       ie:
          ['Monday','Wednesday','Friday'].  Valid entries are the names of
          the days of the week.

          OnIdle No special parameters required.

          OnTaskCreation No special parameters required.

          OnBoot No special parameters required.

          OnLogon No special parameters required.

          OnSessionChange :param str session_user_name: Sets the user  for
          the  Terminal  Server  session.  When  a session state change is
          detected for this user, a task is  started.  To  detect  session
          status change for any user, do not pass this parameter.

          Parameters
                 state_change  (str)  --  Sets the kind of Terminal Server
                 session change

          that  would  trigger  a  task  launch.  Valid  options  are:   -
          ConsoleConnect:  When  you  connect  to  a  user session (switch
          users) - ConsoleDisconnect: When you disconnect a  user  session
          (switch  users) - RemoteConnect: When a user connects via Remote
          Desktop - RemoteDisconnect: When a user disconnects  via  Remote
          Desktop   -  SessionLock:  When  the  workstation  is  locked  -
          SessionUnlock: When the workstation is unlocked

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.add_trigger <task_name> trigger_type=Once trigger_enabled=True start_date=2016/12/1 start_time=12:01

   salt.modules.win_task.clear_triggers(name, location='\\')
          Remove all triggers from the task.

          Parameters

                 * name (str) -- The name of the task from which to  clear
                   all triggers.

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.clear_trigger <task_name>

   salt.modules.win_task.create_folder(name, location='\\')
          Create a folder in which to create tasks.

          Parameters
                 name  (str)  --  The  name  of  the  folder. This will be
                 displayed in the task

          scheduler.

          Parameters
                 location  (str)  --  A  string  value  representing   the
                 location in which to

          create the folder. Default is '\' which is the root for the task
          scheduler (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.create_folder <folder_name>

   salt.modules.win_task.create_task(name,                  location='\\',
   user_name='System', password=None, force=False, **kwargs)
          Create  a new task in the designated location. This function has
          many keyword arguments that are not listed here. For  additional
          arguments see:

          * py:function::edit_task

          * py:function::add_action

          * py:function::add_trigger

          Parameters
                 name  (str)  --  The  name  of  the  task.  This  will be
                 displayed in the task

          scheduler.

          Parameters
                 location  (str)  --  A  string  value  representing   the
                 location in which to

          create  the  task. Default is '\' which is the root for the task
          scheduler (C:WindowsSystem32tasks).

          Parameters
                 user_name (str) -- The user account under  which  to  run
                 the task. To

          specify the 'System' account, use 'System'. The password will be
          ignored.

          Parameters
                 password (str) -- The password to use for authentication.
                 This should set

          the  task  to  run  whether the user is logged in or not, but is
          currently not working.

          Parameters
                 force  (bool)  --  If  the  task  exists,  overwrite  the
                 existing task.

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.create_task <task_name> user_name=System force=True action_type=Execute cmd='del /Q /S C:\\Temp' trigger_type=Once start_date=2016-12-1 start_time=01:00

   salt.modules.win_task.create_task_from_xml(name,         location='\\',
   xml_text=None, xml_path=None, user_name='System', password=None)
          Create a task based on XML. Source can be a file or a string  of
          XML.

          Parameters
                 name  (str)  --  The  name  of  the  task.  This  will be
                 displayed in the task

          scheduler.

          Parameters
                 location  (str)  --  A  string  value  representing   the
                 location in which to

          create  the  task. Default is '\' which is the root for the task
          scheduler (C:WindowsSystem32tasks).

          Parameters
                 xml_text (str) -- A string of xml representing  the  task
                 to be created.

          This will be overridden by xml_path if passed.

          Parameters
                 xml_path  (str)  --  The path to an XML file on the local
                 system containing

          the xml that defines the task. This will override xml_text

          Parameters
                 user_name (str) -- The user account under  which  to  run
                 the task. To

          specify the 'System' account, use 'System'. The password will be
          ignored.

          Parameters
                 password (str) -- The password to use for authentication.
                 This should set

          the  task  to  run  whether the user is logged in or not, but is
          currently not working.

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.create_task_from_xml <task_name> xml_path=C:\task.xml

   salt.modules.win_task.delete_folder(name, location='\\')
          Delete a folder from the task scheduler.

          Parameters

                 * name (str) -- The name of the folder to delete.

                 * location (str)  --  A  string  value  representing  the
                   location of the folder.

          Default  is  '\'  which  is  the  root  for  the  task scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.delete_folder <folder_name>

   salt.modules.win_task.delete_task(name, location='\\')
          Delete a task from the task scheduler.

          Parameters

                 * name (str) -- The name of the task to delete.

                 * location (str)  --  A  string  value  representing  the
                   location of the task.

          Default  is  '\'  which  is  the  root  for  the  task scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.delete_task <task_name>

   salt.modules.win_task.edit_task(name=None,               location='\\',
   user_name=None,    password=None,    description=None,    enabled=None,
   hidden=None,           run_if_idle=None,            idle_duration=None,
   idle_wait_timeout=None,    idle_stop_on_end=None,    idle_restart=None,
   ac_only=None,       stop_if_on_batteries=None,        wake_to_run=None,
   run_if_network=None,         network_id=None,        network_name=None,
   allow_demand_start=None, start_when_available=None, restart_every=None,
   restart_count=3,       execution_time_limit=None,      force_stop=None,
   delete_after=None, multiple_instances=None, **kwargs)
          Edit the parameters of a task. Triggers and  Actions  cannot  be
          edited yet.

          Parameters
                 name  (str)  --  The  name  of  the  task.  This  will be
                 displayed in the task

          scheduler.

          Parameters
                 location  (str)  --  A  string  value  representing   the
                 location in which to

          create  the  task. Default is '\' which is the root for the task
          scheduler (C:WindowsSystem32tasks).

          Parameters
                 user_name (str) -- The user account under  which  to  run
                 the task. To

          specify the 'System' account, use 'System'. The password will be
          ignored.

          Parameters
                 password (str) -- The password to use for authentication.
                 This should set

          the  task  to  run  whether the user is logged in or not, but is
          currently not working.

          NOTE:
             The combination of user_name and password determine  how  the
             task

          runs.  For  example, if a username is passed without at password
          the task will only run when the user is logged in. If a password
          is  passed  as well the task will run whether the user is logged
          on or not. If you pass 'System' as the username  the  task  will
          run as the system account (the password parameter is ignored.

          Parameters
                 description  (str) -- A string representing the text that
                 will be

          displayed in the description field in the task scheduler.

          Parameters
                 enabled (bool) -- A boolean value representing whether or
                 not the task is

          enabled.

          Parameters
                 hidden  (bool) -- A boolean value representing whether or
                 not the task is

          hidden.

          Parameters
                 run_if_idle (bool) -- Boolean value that  indicates  that
                 the Task

          Scheduler  will  run the task only if the computer is in an idle
          state.

          Parameters
                 idle_duration (str) -- A value that indicates the  amount
                 of time that the

          computer  must be in an idle state before the task is run. Valid
          values are: - 1 minute - 5 minutes - 10 minutes - 15  minutes  -
          30 minutes - 1 hour

          Parameters
                 idle_wait_timeout  (str)  --  A  value that indicates the
                 amount of time that

          the Task Scheduler will wait for an  idle  condition  to  occur.
          Valid  values  are:  -  Do  not wait - 1 minute - 5 minutes - 10
          minutes - 15 minutes - 30 minutes - 1 hour - 2 hours

          Parameters
                 idle_stop_on_end (bool) -- Boolean value  that  indicates
                 that the Task

          Scheduler  will  terminate  the  task if the idle condition ends
          before the task is completed.

          Parameters
                 idle_restart  (bool)  --  Boolean  value  that  indicates
                 whether the task is

          restarted  when  the computer cycles into an idle condition more
          than once.

          Parameters
                 ac_only (bool) -- Boolean value that indicates  that  the
                 Task Scheduler

          will launch the task only while on AC power.

          Parameters
                 stop_if_on_batteries   (bool)   --   Boolean  value  that
                 indicates that the task

          will be stopped if the computer begins to run on battery power.

          Parameters
                 wake_to_run (bool) -- Boolean value that  indicates  that
                 the Task

          Scheduler  will  wake  the  computer  when it is time to run the
          task.

          Parameters
                 run_if_network (bool) --  Boolean  value  that  indicates
                 that the Task

          Scheduler will run the task only when a network is available.

          Parameters

                 * network_id  (guid)  --  GUID  value  that  identifies a
                   network profile.

                 * network_name (str)  --  Sets  the  name  of  a  network
                   profile. The name is

          used for display purposes.

          Parameters
                 allow_demand_start (bool) -- Boolean value that indicates
                 that the task

          can be started by using either the Run command  or  the  Context
          menu.

          Parameters
                 start_when_available   (bool)   --   Boolean  value  that
                 indicates that the Task

          Scheduler can start the task at any  time  after  its  scheduled
          time has passed.

          Parameters
                 restart_every  --  A  value  that  specifies the interval
                 between task

          restart attempts. Valid values are: :type: bool str - False  (to
          disable)  -  1 minute - 5 minutes - 10 minutes - 15 minutes - 30
          minutes - 1 hour - 2 hours

          Parameters
                 restart_count (int) --  The  number  of  times  the  Task
                 Scheduler will

          attempt to restart the task. Valid values are integers 1 - 999.

          Parameters
                 execution_time_limit  --  The  amount  of time allowed to
                 complete the

          task. Valid values are: :type: bool str - False (to disable) - 1
          hour - 2 hours - 4 hours - 8 hours - 12 hours - 1 day - 3 days

          Parameters
                 force_stop  (bool)  --  Boolean value that indicates that
                 the task may be

          terminated by using TerminateProcess.

          Parameters
                 delete_after  --  The  amount  of  time  that  the   Task
                 Scheduler will

          wait  before  deleting  the  task  after  it expires. Requires a
          trigger with an expiration date. Valid values are:  :type:  bool
          str - False (to disable) - Immediately - 30 days - 90 days - 180
          days - 365 days

          Parameters
                 multiple_instances (str) -- Sets the policy that  defines
                 how the Task

          Scheduler  deals  with  multiple  instances  of  the task. Valid
          values are: - Parallel - Queue - No New Instance - Stop Existing

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.edit_task <task_name> description='This task is awesome'

   salt.modules.win_task.info(name, location='\\')
          Get the details about a task in the task scheduler.

          Parameters

                 * name (str) -- The name of the task for which to  return
                   the status

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Returns

          Return type
                 dict

          CLI Example:

             salt 'minion-id' task.info <task_name>

   salt.modules.win_task.list_actions(name, location='\\')
          List  all  actions  that  pertain  to  a  task  in the specified
          location.

          Parameters

                 * name (str) -- The name  of  the  task  for  which  list
                   actions.

                 * location  (str)  --  A  string  value  representing the
                   location of the task

          from which to list actions. Default is '\' which is the root for
          the task scheduler (C:WindowsSystem32tasks).

          Returns
                 Returns a list of actions.

          Return type
                 list

          CLI Example:

             salt 'minion-id' task.list_actions <task_name>

   salt.modules.win_task.list_folders(location='\\')
          List  all  folders  located  in  a specific location in the task
          scheduler.

          Parameters
                 location (str) -- A string value representing the  folder
                 from which you

          want  to  list  tasks.  Default is '\' which is the root for the
          task scheduler (C:WindowsSystem32tasks).

          Returns
                 Returns a list of folders.

          Return type
                 list

          CLI Example:

             salt 'minion-id' task.list_folders

   salt.modules.win_task.list_tasks(location='\\')
          List all tasks located  in  a  specific  location  in  the  task
          scheduler.

          Parameters
                 location  (str) -- A string value representing the folder
                 from which you

          want to list tasks. Default is '\' which is  the  root  for  the
          task scheduler (C:WindowsSystem32tasks).

          Returns
                 Returns a list of tasks.

          Return type
                 list

          CLI Example:

             salt 'minion-id' task.list_tasks

   salt.modules.win_task.list_triggers(name, location='\\')
          List  all  triggers  that  pertain  to  a  task in the specified
          location.

          Parameters

                 * name (str) -- The name  of  the  task  for  which  list
                   triggers.

                 * location  (str)  --  A  string  value  representing the
                   location of the task

          from which to list triggers. Default is '\' which  is  the  root
          for the task scheduler (C:WindowsSystem32tasks).

          Returns
                 Returns a list of triggers.

          Return type
                 list

          CLI Example:

             salt 'minion-id' task.list_triggers <task_name>

   salt.modules.win_task.run(name, location='\\')
          Run a scheduled task manually.

          Parameters

                 * name (str) -- The name of the task to run.

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.list_run <task_name>

   salt.modules.win_task.run_wait(name, location='\\')
          Run a scheduled task and return when the task finishes

          Parameters

                 * name (str) -- The name of the task to run.

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.list_run_wait <task_name>

   salt.modules.win_task.status(name, location='\\')
          Determine  the  status  of a task. Is it Running, Queued, Ready,
          etc.

          Parameters

                 * name (str) -- The name of the task for which to  return
                   the status

                 * location  (str)  --  A  string  value  representing the
                   location of the task.

          Default is  '\'  which  is  the  root  for  the  task  scheduler
          (C:WindowsSystem32tasks).

          Returns
                 The  current  status  of  the  task.  Will  be one of the
                 following:

          * Unknown

          * Disabled

          * Queued

          * Ready

          * Running

          Return type
                 string

          CLI Example:

             salt 'minion-id' task.list_status <task_name>

   salt.modules.win_task.stop(name, location='\\')
          Stop a scheduled task.

          Parameters

                 * name (str) -- The name of the task to stop.

                 * location (str)  --  A  string  value  representing  the
                   location of the task.

          Default  is  '\'  which  is  the  root  for  the  task scheduler
          (C:WindowsSystem32tasks).

          Returns
                 True if successful, False if unsuccessful

          Return type
                 bool

          CLI Example:

             salt 'minion-id' task.list_stop <task_name>

   salt.modules.win_timezone
   Module for managing timezone on Windows systems.

   salt.modules.win_timezone.get_hwclock()
          Get current hardware clock setting (UTC or localtime)

          CLI Example:

             salt '*' timezone.get_hwclock

   salt.modules.win_timezone.get_offset()
          Get current numeric timezone offset from UCT (i.e. -0700)

          CLI Example:

             salt '*' timezone.get_offset

   salt.modules.win_timezone.get_zone()
          Get current timezone (i.e. America/Denver)

          CLI Example:

             salt '*' timezone.get_zone

   salt.modules.win_timezone.get_zonecode()
          Get current timezone (i.e. PST, MDT, etc)

          CLI Example:

             salt '*' timezone.get_zonecode

   salt.modules.win_timezone.set_hwclock(clock)
          Sets the hardware clock to be either UTC or localtime

          CLI Example:

             salt '*' timezone.set_hwclock UTC

   salt.modules.win_timezone.set_zone(timezone)
          Unlinks, then symlinks /etc/localtime to the set timezone.

          The timezone is crucial to several  system  processes,  each  of
          which  SHOULD  be  restarted  (for instance, whatever you system
          uses as its cron and syslog daemons). This will not be magically
          done for you!

          CLI Example:

             salt '*' timezone.set_zone 'America/Denver'

   salt.modules.win_timezone.zone_compare(timezone)
          Checks the md5sum between the given timezone, and the one set in
          /etc/localtime. Returns True if they match, and  False  if  not.
          Mostly useful for running state checks.

          Example:

             salt '*' timezone.zone_compare 'America/Denver'

   salt.modules.win_update
   Module for running windows updates.

   depends

          * win32com

          * win32con

          * win32api

          * pywintypes

   New in version 2014.7.0.

   Set  windows updates to run by category. Default behavior is to install
   all  updates  that  do  not  require  user  interaction  to   complete.
   Optionally  set categories to a category of your choice to only install
   certain updates. Default is to set to install all available but  driver
   updates.   The following example will install all Security and Critical
   Updates, and download but not install standard updates.

      salt '*' win_update.install_updates categories="['Critical Updates', 'Security Updates']"

   You can also specify a number of features about the update  to  have  a
   fine  grain  approach  to  specific  types  of  updates.  These are the
   following features/states of updates available for configuring:
      'UI' - User interaction required, skipped by default 'downloaded'  -
      Already  downloaded,  included  by  default  'present'  - Present on
      computer, included  by  default  'installed'  -  Already  installed,
      skipped  by  default 'reboot' - Reboot required, included by default
      'hidden' - Skip hidden updates,  skipped  by  default  'software'  -
      Software  updates,  included  by  default 'driver' - Driver updates,
      included by default

   The following example installs all updates that don't require a reboot:
      salt '*' win_update.install_updates skips="[{'reboot':True}]"

   Once installed Salt will return a similar output:

      2 : Windows Server 2012 Update (KB123456)
      4 : Internet Explorer Security Update (KB098765)
      2 : Malware Definition Update (KB321456)
      ...

   The number at the beginning of the line is an OperationResultCode  from
   the   Windows   Update  Agent,  it's  enumeration  is  described  here:
   https://msdn.microsoft.com/en-us/library/windows/desktop/aa387095(v=vs.85).aspx.
   The  result  code  is  then  followed  by  the  update  name and its KB
   identifier.

   salt.modules.win_update.download_updates(skips=None,         retries=5,
   categories=None)
          Downloads  all  available  updates,  skipping those that require
          user interaction.

          Various aspects of the updates can be included or excluded. this
          feature is still in development.

          retries
                 Number  of  retries  to  make  before  giving up. This is
                 total, not per step.

          categories
                 Specify the categories to update. Must  be  passed  as  a
                 list.

                    salt '*' win_update.download_updates categories="['Updates']"

                 Categories include the following:

                 * Updates

                 * Windows 7

                 * Critical Updates

                 * Security Updates

                 * Update Rollups

          CLI Examples:

             # Normal Usage
             salt '*' win_update.download_updates

             # Download critical updates only
             salt '*' win_update.download_updates categories="['Critical Updates']"

   salt.modules.win_update.install_updates(skips=None,          retries=5,
   categories=None)
          Downloads and installs all  available  updates,  skipping  those
          that require user interaction.

          Add cached to only install those updates which have already been
          downloaded.

          you can set the maximum number of retries to  n  in  the  search
          process by adding: retries=n

          various aspects of the updates can be included or excluded. This
          function is still under development.

          retries
                 Number of retries to  make  before  giving  up.  This  is
                 total, not per step.

          categories
                 Specify  the  categories  to install. Must be passed as a
                 list.

                    salt '*' win_update.install_updates categories="['Updates']"

                 Categories include the following:

                 * Updates

                 * Windows 7

                 * Critical Updates

                 * Security Updates

                 * Update Rollups

          CLI Examples:

             # Normal Usage
             salt '*' win_update.install_updates

             # Install all critical updates
             salt '*' win_update.install_updates categories="['Critical Updates']"

   salt.modules.win_update.list_updates(verbose=False,        fields=None,
   skips=None, retries=5, categories=None)
          Returns  a  summary  of  available  updates,  grouped into their
          non-mutually exclusive categories.

          verbose
                 Return full set of results, including several fields from
                 the COM.

          fields Return  a  list  of  specific fields for each update. The
                 optional values here are those at the root level  of  the
                 verbose list. This is superseded by the verbose option.

          retries
                 Number  of  retries  to  make  before  giving up. This is
                 total, not per step.

          categories
                 Specify the categories to list. Must be passed as a list.

                    salt '*' win_update.list_updates categories="['Updates']"

                 Categories  include,  but  are  not   limited   to,   the
                 following:

                 * Updates

                 * Windows 7

                 * Critical Updates

                 * Security Updates

                 * Update Rollups

          CLI Examples:

             # Normal Usage
             salt '*' win_update.list_updates

             # Specific Fields
             salt '*' win_update.list_updates fields="['Title', 'Description']"

             # List all critical updates list in verbose detail
             salt '*' win_update.list_updates categories="['Critical Updates']" verbose=True

   salt.modules.win_useradd
   Module for managing Windows Users

   IMPORTANT:
      If you feel that Salt should be using this module to manage users on
      a minion, and it is using a different  module  (or  gives  an  error
      similar to 'user.info' is not available), see here.

   depends

          * pywintypes

          * win32api

          * win32net

          * win32netcon

          * win32profile

          * win32security

          * win32ts

   NOTE:
      This  currently  only  works  with  local  user accounts, not domain
      accounts

   salt.modules.win_useradd.add(name,    password=None,    fullname=False,
   description=None, groups=None, home=None, homedrive=None, profile=None,
   logonscript=None)
          Add a user to the minion.

          Parameters

                 * name (str) -- User name

                 * password (str) -- User's password in plain text.

                 * fullname (str) -- The user's full name.

                 * description (str) -- A brief description  of  the  user
                   account.

                 * groups (list) -- A list of groups to add the user to.

                 * home (str) -- The path to the user's home directory.

                 * homedrive  (str)  --  The drive letter to assign to the
                   home directory. Must be the Drive Letter followed by  a
                   colon. ie: U:

                 * profile  (str) -- An explicit path to a profile. Can be
                   a UNC or a folder on the system. If left blank, windows
                   uses it's default profile directory.

                 * logonscript (str) -- Path to a login script to run when
                   the user logs on.

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.add name password

   salt.modules.win_useradd.addgroup(name, group)
          Add user to a group

          Parameters

                 * name (str) -- user name to add to the group

                 * group (str) -- name of the group to which  to  add  the
                   user

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.addgroup jsnuffy 'Power Users'

   salt.modules.win_useradd.chfullname(name, fullname)
          Change the full name of the user

          Parameters

                 * name  (str)  --  user name for which to change the full
                   name

                 * fullname (str) -- the new value for the full name

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.chfullname user 'First Last'

   salt.modules.win_useradd.chgroups(name, groups, append=True)
          Change the groups this user belongs to, add append=False to make
          the user a member of only the specified groups

          Parameters

                 * name (str) -- user name for which to change groups

                 * groups  (list,  str)  --  a  single  group or a list of
                   groups to assign to the user

                 * append (bool) -- True adds the  passed  groups  to  the
                   user's  current  groups False sets the user's groups to
                   the passed groups only

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.chgroups jsnuffy Administrators,Users True

   salt.modules.win_useradd.chhome(name, home, **kwargs)
          Change the home directory of the user, pass True for persist  to
          move  files  to the new home directory if the old home directory
          exist.

          Parameters

                 * name (str) -- name of the user whose home directory you
                   wish to change

                 * home (str) -- new location of the home directory

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.chhome foo \\fileserver\home\foo True

   salt.modules.win_useradd.chprofile(name, profile)
          Change the profile directory of the user

          Parameters

                 * name  (str)  -- name of the user whose profile you wish
                   to change

                 * profile (str) -- new location of the profile

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.chprofile foo \\fileserver\profiles\foo

   salt.modules.win_useradd.current(sam=False)
          Get  the  username  that  salt-minion  is  running   under.   If
          salt-minion  is  running as a service it should return the Local
          System account. If salt is running  from  a  command  prompt  it
          should return the username that started the command prompt.

          New in version 2015.5.6.

          Parameters
                 sam (bool) --

                 False  returns  just  the  username  without  any  domain
                 notation. True returns the domain with  the  username  in
                 the SAM format. Ie:

                 domain\username

          Returns
                 Returns   False  if  the  username  cannot  be  returned.
                 Otherwise returns the username.

          Return type
                 bool str

          CLI Example:

             salt '*' user.current

   salt.modules.win_useradd.delete(name, purge=False, force=False)
          Remove a user from the minion

          Parameters

                 * name (str) -- The name of the user to delete

                 * purge (bool) -- Boolean value indicating that the  user
                   profile should also be removed when the user account is
                   deleted. If set to True the profile will be removed.

                 * force (bool) -- Boolean value indicating that the  user
                   account  should  be  deleted even if the user is logged
                   in. True will log the user out and delete user.

          Returns
                 True if successful

          Return type
                 bool

          CLI Example:

             salt '*' user.delete name

   salt.modules.win_useradd.getUserSid(username)
          Get the Security ID for the user

          Parameters
                 username (str) -- user name for which to look up the SID

          Returns
                 Returns the user SID

          Return type
                 str

          CLI Example:

             salt '*' user.getUserSid jsnuffy

   salt.modules.win_useradd.getent(refresh=False)
          Return the list of all info for all users

          Parameters
                 refresh (bool) -- Refresh the  cached  user  information.
                 Default  is  False.  Useful when used from within a state
                 function.

          Returns
                 A dictionary containing information about  all  users  on
                 the system

          Return type
                 dict

          CLI Example:

             salt '*' user.getent

   salt.modules.win_useradd.info(name)
          Return user information

          Parameters
                 name (str) -- Username for which to display information

          Returns

                 A dictionary containing user information

                        * fullname

                        * username

                        * SID

                        * passwd (will always return None)

                        * comment  (same  as  description,  left  here for
                          backwards compatibility)

                        * description

                        * active

                        * logonscript

                        * profile

                        * home

                        * homedrive

                        * groups

                        * password_changed

                        * successful_logon_attempts

                        * failed_logon_attempts

                        * last_logon

                        * account_disabled

                        * account_locked

                        * password_never_expires

                        * disallow_change_password

                        * gid

          Return type
                 dict

          CLI Example:

             salt '*' user.info jsnuffy

   salt.modules.win_useradd.list_groups(name)
          Return a list of groups the named user belongs to

          Parameters
                 name (str) -- user name for which to list groups

          Returns
                 list of groups to which the user belongs

          Return type
                 list

          CLI Example:

             salt '*' user.list_groups foo

   salt.modules.win_useradd.list_users()
          Return a list of users on Windows

          Returns
                 list of users on the system

          Return type
                 list

          CLI Example:

             salt '*' user.list_users

   salt.modules.win_useradd.removegroup(name, group)
          Remove user from a group

          Parameters

                 * name (str) -- user name to remove from the group

                 * group (str) -- name of the group from which  to  remove
                   the user

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.removegroup jsnuffy 'Power Users'

   salt.modules.win_useradd.rename(name, new_name)
          Change the username for a named user

          Parameters

                 * name (str) -- user name to change

                 * new_name (str) -- the new name for the current user

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.rename jsnuffy jshmoe

   salt.modules.win_useradd.setpassword(name, password)
          Set the user's password

          Parameters

                 * name (str) -- user name for which to set the password

                 * password (str) -- the new password

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.setpassword jsnuffy sup3rs3cr3t

   salt.modules.win_useradd.update(name,   password=None,   fullname=None,
   description=None,    home=None,    homedrive=None,    logonscript=None,
   profile=None,            expiration_date=None,            expired=None,
   account_disabled=None,                             unlock_account=None,
   password_never_expires=None, disallow_change_password=None)
          Updates settings for the windows user. Name is the only required
          parameter.  Settings will only be changed if  the  parameter  is
          passed a value.

          New in version 2015.8.0.

          Parameters

                 * name (str) -- The user name to update.

                 * password (str) -- New user password in plain text.

                 * fullname (str) -- The user's full name.

                 * description  (str)  --  A brief description of the user
                   account.

                 * home (str) -- The path to the user's home directory.

                 * homedrive (str) -- The drive letter to  assign  to  the
                   home  directory. Must be the Drive Letter followed by a
                   colon. ie: U:

                 * logonscript (str) -- The path to the logon script.

                 * profile  (str)  --  The  path  to  the  user's  profile
                   directory.

                 * expiration_date  (date)  --  The date and time when the
                   account expires. Can be a valid  date/time  string.  To
                   set to never expire pass the string 'Never'.

                 * expired  (bool) -- Pass True to expire the account. The
                   user will be prompted to change their password  at  the
                   next  logon.  Pass  False  to  mark the account as 'not
                   expired'. You can't use this to negate  the  expiration
                   if  the  expiration was caused by the account expiring.
                   You'll have to change the expiration_date as well.

                 * account_disabled (bool) -- True disables  the  account.
                   False enables the account.

                 * unlock_account  (bool)  --  True  unlocks a locked user
                   account. False is ignored.

                 * password_never_expires (bool) -- True sets the password
                   to never expire.  False allows the password to expire.

                 * disallow_change_password (bool) -- True blocks the user
                   from changing the password. False allows  the  user  to
                   change the password.

          Returns
                 True if successful. False is unsuccessful.

          Return type
                 bool

          CLI Example:

             salt '*' user.update bob password=secret profile=C:\Users\Bob
                      home=\\server\homeshare	ob homedrive=U:

   salt.modules.win_wua
   Module for managing Windows Updates using the Windows Update Agent.

   New in version 2015.8.0.

   depends

          * win32com

          * pythoncom

   salt.modules.win_wua.download_update(guid=None)
          Downloads a single update

          Parameters
                 guid -- str A GUID for the update to be downloaded

          Returns
                 A dictionary containing the status, a message, and a list
                 of updates that were downloaded.

          CLI Examples:

             salt '*' win_wua.download_update 12345678-abcd-1234-abcd-1234567890ab

   salt.modules.win_wua.download_updates(guid=None)
          Downloads updates that match the  list  of  passed  GUIDs.  It's
          easier  to  use  this function by using list_updates and setting
          install=True.

          Parameters
                 guid -- A list of GUIDs to be downloaded

          Returns
                 A dictionary containing the status, a message, and a list
                 of updates that were downloaded.

          CLI Examples:

             # Normal Usage
             salt '*' win_wua.download_updates                 guid=['12345678-abcd-1234-abcd-1234567890ab',                      '87654321-dcba-4321-dcba-ba0987654321']

   salt.modules.win_wua.get_needs_reboot()
          Determines if the system needs to be rebooted.

          Returns
                 bool True if the system requires a reboot, False if not

          CLI Examples:

             salt '*' win_wua.get_needs_reboot

   salt.modules.win_wua.get_wu_settings()
          Get current Windows Update settings.

          Returns

                 Featured Updates:
                        Boolean  value  that  indicates whether to display
                        notifications for featured updates.

                 Group Policy Required (Read-only):
                        Boolean value that indicates whether Group  Policy
                        requires the Automatic Updates service.

                 Microsoft Update:
                        Boolean  value  that  indicates whether to turn on
                        Microsoft Update for other Microsoft Products

                 Needs Reboot:
                        Boolean value that indicates whether  the  machine
                        is in a reboot pending state.

                 Non Admins Elevated:
                        Boolean     value     that    indicates    whether
                        non-administrators can perform some update-related
                        actions without administrator approval.

                 Notification Level:

                        Number 1 to 4 indicating the update level:

                               1. Never check for updates

                               2. Check  for  updates  but  let  me choose
                                  whether to download and install them

                               3. Download  updates  but  let  me   choose
                                  whether to install them

                               4. Install updates automatically

                 Read Only (Read-only):
                        Boolean value that indicates whether the Automatic
                        Update settings are read-only.

                 Recommended Updates:
                        Boolean value that indicates  whether  to  include
                        optional  or recommended updates when a search for
                        updates and installation of updates is performed.

                 Scheduled Day:
                        Days  of  the  week  on  which  Automatic  Updates
                        installs or uninstalls updates.

                 Scheduled Time:
                        Time   at  which  Automatic  Updates  installs  or
                        uninstalls updates.

          CLI Examples:

             salt '*' win_wua.get_wu_settings

   salt.modules.win_wua.install_update(guid=None)
          Installs a single update

          Parameters
                 guid -- str A GUID for the update to be installed

          Returns
                 dict  A  dictionary  containing  the  details  about  the
                 installed update

          CLI Examples:

             salt '*' win_wua.install_update 12345678-abcd-1234-abcd-1234567890ab

   salt.modules.win_wua.install_updates(guid=None)
          Installs  updates  that  match  the  passed  criteria. It may be
          easier to use the list_updates function and set install=True.

          Parameters
                 guid -- list A list of GUIDs to be installed

          Returns
                 dict  A  dictionary  containing  the  details  about  the
                 installed updates

          CLI Examples:

             # Normal Usage
             salt '*' win_wua.install_updates
              guid=['12345678-abcd-1234-abcd-1234567890ab',
              '87654321-dcba-4321-dcba-ba0987654321']

   salt.modules.win_wua.list_update(name=None,             download=False,
   install=False)
          Returns details for all updates that match the search criteria

          Parameters

                 * name (str) -- The name of the update  you're  searching
                   for.  This can be the GUID (preferred), a KB number, or
                   the full name of the update. Run  list_updates  to  get
                   the GUID for the update you're looking for.

                 * download (bool) -- Download the update returned by this
                   function. Run this function first to see if the  update
                   exists, then set download=True to download the update.

                 * install  (bool)  -- Install the update returned by this
                   function. Run this function first to see if the  update
                   exists,  then  set  install=True to install the update.
                   This will override download=True

          Returns
                 Returns a dict containing a list of  updates  that  match
                 the  name  if download and install are both set to False.
                 Should  usually  be  a  single  update,  but  can  return
                 multiple  if  a  partial  name  is  given. If download or
                 install is set to true it  will  return  the  results  of
                 win_wua.download_updates:

                    List of Updates:
                    {'<GUID>': {'Title': <title>,
                                'KB': <KB>,
                                'GUID': <the globally unique identifier for the update>
                                'Description': <description>,
                                'Downloaded': <has the update been downloaded>,
                                'Installed': <has the update been installed>,
                                'Mandatory': <is the update mandatory>,
                                'UserInput': <is user input required>,
                                'EULAAccepted': <has the EULA been accepted>,
                                'Severity': <update severity>,
                                'NeedsReboot': <is the update installed and awaiting reboot>,
                                'RebootBehavior': <will the update require a reboot>,
                                'Categories': [ '<category 1>',
                                                '<category 2>',
                                                ...]
                                }
                    }

          Return type
                 dict

          CLI Examples:

             # Recommended Usage using GUID without braces
             # Use this to find the status of a specific update
             salt '*' win_wua.list_update 12345678-abcd-1234-abcd-1234567890ab

             # Use the following if you don't know the GUID:

             # Using a KB number (could possibly return multiple results)
             # Not all updates have an associated KB
             salt '*' win_wua.list_update KB3030298

             # Using part or all of the name of the update
             # Could possibly return multiple results
             # Not all updates have an associated KB
             salt '*' win_wua.list_update 'Microsoft Camera Codec Pack'

   salt.modules.win_wua.list_updates(software=True,         drivers=False,
   summary=False,   installed=False,   categories=None,   severities=None,
   download=False, install=False)
          Returns a detailed list of available updates or a summary

          Parameters

                 * software  (bool)  --  Include  software  updates in the
                   results (default is True)

                 * drivers (bool) -- Include driver updates in the results
                   (default is False)

                 * summary  (bool)  --  True:  Return a summary of updates
                   available for each  category.         False  (default):
                   Return a detailed list of available updates.

                 * installed  (bool)  --  Include installed updates in the
                   results (default if False)

                 * download (bool) -- (Overrides reporting  functionality)
                   Download the list of updates returned by this function.
                   Run this function first to see what will be  installed,
                   then set download=True to download the updates.

                 * install  (bool)  -- (Overrides reporting functionality)
                   Install the list of updates returned by this  function.
                   Run  this function first to see what will be installed,
                   then set install=True to install the updates. This will
                   override download=True

                 * categories (list) --

                   Specify  the  categories  to  list. Must be passed as a
                   list. All categories returned by default.

                   Categories include the following:

                   * Critical Updates

                   * Definition Updates

                   * Drivers (make sure you set drivers=True)

                   * Feature Packs

                   * Security Updates

                   * Update Rollups

                   * Updates

                   * Update Rollups

                   * Windows 7

                   * Windows 8.1

                   * Windows 8.1 drivers

                   * Windows 8.1 and later drivers

                   * Windows Defender

                 * severities (list) --

                   Specify the severities to include. Must be passed as  a
                   list. All severities returned by default.

                   Severities include the following:

                   * Critical

                   * Important

          Returns
                 Returns  a  dict containing either a summary or a list of
                 updates:

                    List of Updates:
                    {'<GUID>': {'Title': <title>,
                                'KB': <KB>,
                                'GUID': <the globally uinique identifier for the update>
                                'Description': <description>,
                                'Downloaded': <has the update been downloaded>,
                                'Installed': <has the update been installed>,
                                'Mandatory': <is the update mandatory>,
                                'UserInput': <is user input required>,
                                'EULAAccepted': <has the EULA been accepted>,
                                'Severity': <update severity>,
                                'NeedsReboot': <is the update installed and awaiting reboot>,
                                'RebootBehavior': <will the update require a reboot>,
                                'Categories': [ '<category 1>',
                                                '<category 2>',
                                                ...]
                                }
                    }

                    Summary of Updates:
                    {'Total': <total number of updates returned>,
                     'Available': <updates that are not downloaded or installed>,
                     'Downloaded': <updates that are downloaded but not installed>,
                     'Installed': <updates installed (usually 0 unless installed=True)>,
                     'Categories': { <category 1>: <total for that category>,
                                     <category 2>: <total for category 2>,
                                     ... }
                    }

          Return type
                 dict

          CLI Examples:

             # Normal Usage (list all software updates)
             salt '*' win_wua.list_updates

             # List all updates with categories of Critical Updates and Drivers
             salt '*' win_wua.list_updates categories=['Critical Updates','Drivers']

             # List all Critical Security Updates
             salt '*' win_wua.list_updates categories=['Security Updates'] severities=['Critical']

             # List all updates with a severity of Critical
             salt '*' win_wua.list_updates severities=['Critical']

             # A summary of all available updates
             salt '*' win_wua.list_updates summary=True

             # A summary of all Feature Packs and Windows 8.1 Updates
             salt '*' win_wua.list_updates categories=['Feature Packs','Windows 8.1'] summary=True

   salt.modules.win_wua.set_wu_settings(level=None,      recommended=None,
   featured=None, elevated=None, msupdate=None, day=None, time=None)
          Change Windows Update settings. If no parameters are passed, the
          current value will be returned.

          Parameters

                 * level (int) -- .INDENT 2.0

                 Number from 1 to 4 indicating the update level:

                        1. Never check for updates

                        2. Check for updates but let me choose whether  to
                           download and install them

                        3. Download  updates  but let me choose whether to
                           install them

                        4. Install updates automatically

          * recommended (bool) -- Boolean value that indicates whether  to
            include  optional  or  recommended  updates  when a search for
            updates and installation of updates is performed.

          * featured (bool) -- Boolean value  that  indicates  whether  to
            display notifications for featured updates.

          * elevated  (bool)  --  Boolean  value  that  indicates  whether
            non-administrators can  perform  some  update-related  actions
            without administrator approval.

          * msupdate  (bool)  --  Boolean  value that indicates whether to
            turn on Microsoft Update for other Microsoft products

          * day (str) --

            Days of the  week  on  which  Automatic  Updates  installs  or
            uninstalls updates.  Accepted values:

               * Everyday

               * Monday

               * Tuesday

               * Wednesday

               * Thursday

               * Friday

               * Saturday

          * time  (str)  --  Time  at  which Automatic Updates installs or
            uninstalls updates. Must be in the ##:## 24hr format, eg. 3:00
            PM would be 15:00

   Returns
          Returns a dictionary containing the results.

   CLI Examples:

             salt '*' win_wua.set_wu_settings level=4 recommended=True featured=False

   salt.modules.x509
   Manage X509 certificates

   New in version 2015.8.0.

   depends
          M2Crypto

   salt.modules.x509.create_certificate(path=None,             text=False,
   overwrite=True, ca_server=None, **kwargs)
          Create an X509 certificate.

          path:  Path to write the certificate to.

          text:  If True, return the PEM text without writing to  a  file.
                 Default False.

          overwrite:
                 If  True(default),  create_certificate will overwrite the
                 entire pem file. Set False to preserve  existing  private
                 keys and dh params that may exist in the pem file.

          kwargs:
                 Any of the properties below can be included as additional
                 keyword arguments.

          ca_server:
                 Request a remotely signed certificate from ca_server. For
                 this  to  work,  a  signing_policy must be specified, and
                 that same policy must be configured on the ca_server. See
                 signing_policy  for  details.  Also  the salt master must
                 permit  peers   to   call   the   sign_remote_certificate
                 function.

                 Example:

                 /etc/salt/master.d/peer.conf

                    peer:
                      .*:
                        - x509.sign_remote_certificate

          subject properties:
                 Any  of  the  values below can be included to set subject
                 properties Any  other  subject  properties  supported  by
                 OpenSSL should also work.

                 C:     2 letter Country code

                 CN:    Certificate common name, typically the FQDN.

                 Email: Email address

                 GN:    Given Name

                 L:     Locality

                 O:     Organization

                 OU:    Organization Unit

                 SN:    SurName

                 ST:    State or Province

          signing_private_key:
                 A  path  or  string of the private key in PEM format that
                 will  be  used  to  sign  this  certificate.  If  neither
                 signing_cert, public_key, or csr are included, it will be
                 assumed that this is a self-signed certificate,  and  the
                 public  key  matching signing_private_key will be used to
                 create the certificate.

          signing_cert:
                 A certificate matching the private key that will be  used
                 to  sign  this  certificate. This is used to populate the
                 issuer  values  in  the  resulting  certificate.  Do  not
                 include this value for self-signed certificates.

          public_key:
                 The  public  key to be included in this certificate. This
                 can be sourced from a public  key,  certificate,  csr  or
                 private  key.  If  a  private  key  is used, the matching
                 public key from the private key will be generated  before
                 any  processing  is  done.  This  means you can request a
                 certificate from a remote CA using a private key file  as
                 your  public_key  and  only  the  public key will be sent
                 across the network to the CA. If  neither  public_key  or
                 csr  are  specified,  it  will  be assumed that this is a
                 self-signed certificate, and the public key derived  from
                 signing_private_key   will   be   used.   Specify  either
                 public_key or csr, not both. Because you can input a  CSR
                 as  a  public  key  or  as  a  CSR,  it  is  important to
                 understand the difference.  If you  import  a  CSR  as  a
                 public  key,  only  the  public  key will be added to the
                 certificate, subject or extension information in the  CSR
                 will be lost.

          csr:   A  file  or  PEM  string containing a certificate signing
                 request.  This  will  be  used  to  supply  the  subject,
                 extensions  and  public key of a certificate. Any subject
                 or extensions specified explicitly will overwrite any  in
                 the CSR.

          basicConstraints:
                 X509v3 Basic Constraints extension.

          extensions:
                 The  following  arguments set X509v3 Extension values. If
                 the value starts with
                 ``
                 critical
                 ``
                 , the extension will be marked as critical.

                 Some  special  extensions  are  subjectKeyIdentifier  and
                 authorityKeyIdentifier.

                 subjectKeyIdentifier  can  be an explicit value or it can
                 be  the  special  string  hash.   hash   will   set   the
                 subjectKeyIdentifier  equal  to  the  SHA1  hash  of  the
                 modulus of the public key in this certificate. Note  that
                 this is not the exact same hashing method used by OpenSSL
                 when using the hash value.

                 authorityKeyIdentifier  Use  values  acceptable  to   the
                 openssl  CLI  tools.  This  will  automatically  populate
                 authorityKeyIdentifier with the  subjectKeyIdentifier  of
                 signing_cert.  If this is a self-signed cert these values
                 will be the same.

                 basicConstraints:
                        X509v3 Basic Constraints

                 keyUsage:
                        X509v3 Key Usage

                 extendedKeyUsage:
                        X509v3 Extended Key Usage

                 subjectKeyIdentifier:
                        X509v3 Subject Key Identifier

                 issuerAltName:
                        X509v3 Issuer Alternative Name

                 subjectAltName:
                        X509v3 Subject Alternative Name

                 crlDistributionPoints:
                        X509v3 CRL distribution points

                 issuingDistributionPoint:
                        X509v3 Issuing Distribution Point

                 certificatePolicies:
                        X509v3 Certificate Policies

                 policyConstraints:
                        X509v3 Policy Constraints

                 inhibitAnyPolicy:
                        X509v3 Inhibit Any Policy

                 nameConstraints:
                        X509v3 Name Constraints

                 noCheck:
                        X509v3 OCSP No Check

                 nsComment:
                        Netscape Comment

                 nsCertType:
                        Netscape Certificate Type

          days_valid:
                 The number of days this certificate should be valid. This
                 sets  the  notAfter property of the certificate. Defaults
                 to 365.

          version:
                 The version of the X509 certificate. Defaults to 3.  This
                 is  automatically  converted  to  the  version  value, so
                 version=3 sets the certificate version field to 0x2.

          serial_number:
                 The serial number  to  assign  to  this  certificate.  If
                 omitted  a  random  serial  number of size serial_bits is
                 generated.

          serial_bits:
                 The number of bits to  use  when  randomly  generating  a
                 serial number.  Defaults to 64.

          algorithm:
                 The  hashing  algorithm  to  be  used  for  signing  this
                 certificate.  Defaults to sha256.

          copypath:
                 An additional path to copy the resulting certificate  to.
                 Can be used to maintain a copy of all certificates issued
                 for revocation purposes.

          prepend_cn:
                 If set to True, the CN and a dash will  be  prepended  to
                 the copypath's filename.

                 Example:
                        /etc/pki/issued_certs/www.example.com-DE:CA:FB:AD:00:00:00:00.crt

          signing_policy:
                 A signing policy that  should  be  used  to  create  this
                 certificate.   Signing  policies should be defined in the
                 minion configuration, or in a minion pillar. It should be
                 a  yaml  formatted  list of arguments which will override
                 any arguments passed to this function. If the minions key
                 is  included in the signing policy, only minions matching
                 that  pattern  will  be  permitted  to  remotely  request
                 certificates from that policy.

                 Example:

                    x509_signing_policies:
                      www:
                        - minions: 'www*'
                        - signing_private_key: /etc/pki/ca.key
                        - signing_cert: /etc/pki/ca.crt
                        - C: US
                        - ST: Utah
                        - L: Salt Lake City
                        - basicConstraints: "critical CA:false"
                        - keyUsage: "critical cRLSign, keyCertSign"
                        - subjectKeyIdentifier: hash
                        - authorityKeyIdentifier: keyid,issuer:always
                        - days_valid: 90
                        - copypath: /etc/pki/issued_certs/

                 The   above   signing   policy   can   be   invoked  with
                 signing_policy=www

          CLI Example:

             salt '*' x509.create_certificate path=/etc/pki/myca.crt \
             signing_private_key='/etc/pki/myca.key' csr='/etc/pki/myca.csr'}

   salt.modules.x509.create_crl(path=None,                     text=False,
   signing_private_key=None,        signing_cert=None,       revoked=None,
   include_expired=False, days_valid=100, digest='')
          Create a CRL

          Depends

                 * PyOpenSSL Python module

          path:  Path to write the crl to.

          text:  If True, return the PEM text without writing to  a  file.
                 Default False.

          signing_private_key:
                 A  path  or  string of the private key in PEM format that
                 will be used to sign this crl. This is required.

          signing_cert:
                 A certificate matching the private key that will be  used
                 to sign this crl. This is required.

          revoked:
                 A  list  of  dicts  containing  all  the  certificates to
                 revoke. Each dict represents one certificate. A dict must
                 contain  either  the  key serial_number with the value of
                 the serial number to revoke, or certificate  with  either
                 the PEM encoded text of the certificate, or a path ot the
                 certificate to revoke.

                 The dict can optionally contain the revocation_date  key.
                 If this key is omitted the revocation date will be set to
                 now. If should  be  a  string  in  the  format  "%Y-%m-%d
                 %H:%M:%S".

                 The  dict  can also optionally contain the not_after key.
                 This is redundant if the certificate key is included.  If
                 the Certificate key is not included, this can be used for
                 the logic behind the include_expired parameter. If should
                 be a string in the format "%Y-%m-%d %H:%M:%S".

                 The dict can also optionally contain the reason key. This
                 is the reason code for the revocation. Available  choices
                 are     unspecified,     keyCompromise,     CACompromise,
                 affiliationChanged, superseded, cessationOfOperation  and
                 certificateHold.

          include_expired:
                 Include  expired  certificates  in  the  CRL.  Default is
                 False.

          days_valid:
                 The number of days that the CRL  should  be  valid.  This
                 sets the Next Update field in the CRL.

          digest:
                 The  digest  to  use  for  signing  the CRL.  This has no
                 effect on versions of pyOpenSSL less than 0.14

          CLI Example:

             salt '*' x509.create_crl path=/etc/pki/mykey.key \
                     signing_private_key=/etc/pki/ca.key \
                     signing_cert=/etc/pki/ca.crt \
                     revoked="{'compromized-web-key': \
                     {'certificate': '/etc/pki/certs/www1.crt', \
                     'revocation_date': '2015-03-01 00:00:00'}}"

   salt.modules.x509.create_csr(path=None, text=False, **kwargs)
          Create a certificate signing request.

          path:  Path to write the certificate to.

          text:  If True, return the PEM text without writing to  a  file.
                 Default False.

          algorithm:
                 The  hashing  algorithm  to  be  used  for  signing  this
                 request. Defaults to sha256.

          kwargs:
                 The  subject,  extension  and  version   arguments   from
                 x509.create_certificate can be used.

          CLI Example:

             salt '*' x509.create_csr path=/etc/pki/myca.csr \
                     public_key='/etc/pki/myca.key' CN='My Cert

   salt.modules.x509.create_private_key(path=None,  text=False, bits=2048,
   verbose=True)
          Creates a private key in PEM format.

          path:  The path to write the file to, either path  or  text  are
                 required.

          text:  If  True,  return the PEM text without writing to a file.
                 Default False.

          bits:  Length of the private key in bits. Default 2048

          verbose:
                 Provide visual feedback on stdout. Default True

                 New in version 2016.11.0.

          CLI Example:

             salt '*' x509.create_private_key path=/etc/pki/mykey.key

   salt.modules.x509.expired(certificate)
          Returns a dict containing limited details of a  certificate  and
          whether the certificate has expired.

          New in version 2016.11.0.

          certificate:
                 The   certificate  to  be  read.  Can  be  a  path  to  a
                 certificate  file,  or  a  string  containing   the   PEM
                 formatted text of the certificate.

          CLI Example:

             salt '*' x509.expired "/etc/pki/mycert.crt"

   salt.modules.x509.get_pem_entries(glob_path)
          Returns a dict containing PEM entries in files matching a glob

          glob_path:
                 A path to certificates to be read and returned.

          CLI Example:

             salt '*' x509.read_pem_entries "/etc/pki/*.crt"

   salt.modules.x509.get_pem_entry(text, pem_type=None)
          Returns  a  properly  formatted  PEM  string from the input text
          fixing any whitespace or line-break issues

          text:  Text containing the X509 PEM entry to be returned or path
                 to a file containing the text.

          pem_type:
                 If  specified,  this function will only return a pem of a
                 certain type, for example 'CERTIFICATE'  or  'CERTIFICATE
                 REQUEST'.

          CLI Example:

             salt '*' x509.get_pem_entry "-----BEGIN CERTIFICATE REQUEST-----\
                     MIICyzCC Ar8CAQI...-----END CERTIFICATE REQUEST"

   salt.modules.x509.get_private_key_size(private_key)
          Returns the bit length of a private key in PEM format.

          private_key:
                 A path or PEM encoded string containing a private key.

          CLI Example:

             salt '*' x509.get_private_key_size /etc/pki/mycert.key

   salt.modules.x509.get_public_key(key, asObj=False)
          Returns a string containing the public key in PEM format.

          key:   A   path   or   PEM  encoded  string  containing  a  CSR,
                 Certificate or Private Key from which a public key can be
                 retrieved.

          CLI Example:

             salt '*' x509.get_public_key /etc/pki/mycert.cer

   salt.modules.x509.get_signing_policy(signing_policy_name)
          Returns  the  details  of  a names signing policy, including the
          text of the public key that will be used to sign  it.  Does  not
          return the private key.

          CLI Example:

             salt '*' x509.get_signing_policy www

   salt.modules.x509.read_certificate(certificate)
          Returns a dict containing details of a certificate. Input can be
          a PEM string or file path.

          certificate:
                 The  certificate  to  be  read.  Can  be  a  path  to   a
                 certificate   file,   or  a  string  containing  the  PEM
                 formatted text of the certificate.

          CLI Example:

             salt '*' x509.read_certificate /etc/pki/mycert.crt

   salt.modules.x509.read_certificates(glob_path)
          Returns a dict containing details of a all certificates matching
          a glob

          glob_path:
                 A path to certificates to be read and returned.

          CLI Example:

             salt '*' x509.read_certificates "/etc/pki/*.crt"

   salt.modules.x509.read_crl(crl)
          Returns  a  dict  containing details of a certificate revocation
          list.  Input can be a PEM string or file path.

          Depends

                 * OpenSSL command line tool

          csl:   A path or PEM encoded string containing the CSL to read.

          CLI Example:

             salt '*' x509.read_crl /etc/pki/mycrl.crl

   salt.modules.x509.read_csr(csr)
          Returns a dict containing details of a certificate request.

          Depends

                 * OpenSSL command line tool

          csr:   A path or PEM encoded string containing the CSR to read.

          CLI Example:

             salt '*' x509.read_csr /etc/pki/mycert.csr

   salt.modules.x509.sign_remote_certificate(argdic, **kwargs)
          Request a certificate to  be  remotely  signed  according  to  a
          signing policy.

          argdic:
                 A dict containing all the arguments to be passed into the
                 create_certificate function. This will become kwargs when
                 passed to create_certificate.

          kwargs:
                 kwargs delivered from publish.publish

          CLI Example:

             salt '*' x509.sign_remote_certificate argdic="{'public_key': \
                     '/etc/pki/www.key', 'signing_policy': 'www'}" __pub_id='www1'

   salt.modules.x509.verify_crl(crl, cert)
          Validate  a  CRL  against a certificate.  Parses openssl command
          line output, this is a workaround for  M2Crypto's  inability  to
          get them from CSR objects.

          crl:   The CRL to verify

          cert:  The certificate to verify the CRL against

          CLI Example:

             salt '*' x509.verify_crl crl=/etc/pki/myca.crl cert=/etc/pki/myca.crt

   salt.modules.x509.verify_private_key(private_key, public_key)
          Verify that 'private_key' matches 'public_key'

          private_key:
                 The  private  key to verify, can be a string or path to a
                 private key in PEM format.

          public_key:
                 The public key to verify, can be a string or  path  to  a
                 PEM formatted certificate, csr, or another private key.

          CLI Example:

             salt '*' x509.verify_private_key private_key=/etc/pki/myca.key \
                     public_key=/etc/pki/myca.crt

   salt.modules.x509.verify_signature(certificate, signing_pub_key=None)
          Verify that certificate has been signed by signing_pub_key

          certificate:
                 The  certificate  to  verify.  Can  be  a  path or string
                 containing a PEM formatted certificate.

          signing_pub_key:
                 The public key to verify, can be a string or  path  to  a
                 PEM formatted certificate, csr, or private key.

          CLI Example:

             salt '*' x509.verify_signature /etc/pki/mycert.pem \
                     signing_pub_key=/etc/pki/myca.crt

   salt.modules.x509.will_expire(certificate, days)
          Returns  a  dict containing details of a certificate and whether
          the certificate will expire in the  specified  number  of  days.
          Input can be a PEM string or file path.

          New in version 2016.11.0.

          certificate:
                 The   certificate  to  be  read.  Can  be  a  path  to  a
                 certificate  file,  or  a  string  containing   the   PEM
                 formatted text of the certificate.

          CLI Example:

             salt '*' x509.will_expire "/etc/pki/mycert.crt" days=30

   salt.modules.x509.write_pem(text, path, overwrite=True, pem_type=None)
          Writes  out  a  PEM  string  fixing any formatting or whitespace
          issues before writing.

          text:  PEM string input to be written out.

          path:  Path of the file to write the pem out to.

          overwrite:
                 If True(default), write_pem will overwrite the entire pem
                 file.  Set False to preserve existing private keys and dh
                 params that may exist in the pem file.

          pem_type:
                 The PEM type to be  saved,  for  example  CERTIFICATE  or
                 PUBLIC  KEY.  Adding this will allow the function to take
                 input that may contain multiple pem types.

          CLI Example:

             salt '*' x509.write_pem \
                 "-----BEGIN CERTIFICATE-----MIIGMzCCBBugA..." \
                 path=/etc/pki/mycert.crt

   salt.modules.xapi
   This module (mostly) uses the XenAPI to manage Xen virtual machines.

   Big fat warning: the XenAPI used in this file is the one  bundled  with
   Xen  Source,  NOT XenServer nor Xen Cloud Platform. As a matter of fact
   it will fail under those platforms. From what I've read, little work is
   needed  to  adapt  this  code  to  XS/XCP,  mostly  playing with XenAPI
   version, but as XCP is not taking precedence  on  Xen  Source  on  many
   platforms, please keep compatibility in mind.

   Useful documentation:

   . http://downloads.xen.org/Wiki/XenAPI/xenapi-1.0.6.pdf

   salt.modules.xapi.create(domain)
          Deprecated since version Nitrogen: Use start() instead.

          Start a defined domain

          CLI Example:

             salt '*' virt.create <domain>

   salt.modules.xapi.destroy(domain)
          Deprecated since version Nitrogen: Use stop() instead.

          Power off a defined domain

          CLI Example:

             salt '*' virt.destroy <domain>

   salt.modules.xapi.freecpu()
          Return  an  int  representing  the number of unallocated cpus on
          this hypervisor

          CLI Example:

             salt '*' virt.freecpu

   salt.modules.xapi.freemem()
          Return an int representing the amount of  memory  that  has  not
          been given to virtual machines on this node

          CLI Example:

             salt '*' virt.freemem

   salt.modules.xapi.full_info()
          Return the node_info, vm_info and freemem

          CLI Example:

             salt '*' virt.full_info

   salt.modules.xapi.get_disks(vm_)
          Return the disks of a named vm

          CLI Example:

             salt '*' virt.get_disks <vm name>

   salt.modules.xapi.get_macs(vm_)
          Return a list off MAC addresses from the named vm

          CLI Example:

             salt '*' virt.get_macs <vm name>

   salt.modules.xapi.get_nics(vm_)
          Return info about the network interfaces of a named vm

          CLI Example:

             salt '*' virt.get_nics <vm name>

   salt.modules.xapi.is_hyper()
          Returns  a  bool whether or not this node is a hypervisor of any
          kind

          CLI Example:

             salt '*' virt.is_hyper

   salt.modules.xapi.list_domains()
          Return a list of virtual machine names on the minion

          CLI Example:

             salt '*' virt.list_domains

   salt.modules.xapi.list_vms()
          Deprecated since version Nitrogen: Use list_domains() instead.

          List all virtual machines.

          CLI Example:

             salt '*' virt.list_vms <domain>

   salt.modules.xapi.migrate(vm_,   target,   live=1,   port=0,   node=-1,
   ssl=None, change_home_server=0)
          Migrates the virtual machine to another hypervisor

          CLI Example:

             salt '*' virt.migrate <vm name> <target hypervisor> [live] [port] [node] [ssl] [change_home_server]

          Optional values:

          live   Use live migration

          port   Use a specified port

          node   Use specified NUMA node on target

          ssl    use ssl connection for migration

          change_home_server
                 change home server for managed domains

   salt.modules.xapi.node_info()
          Return a dict with information about this node

          CLI Example:

             salt '*' virt.node_info

   salt.modules.xapi.pause(vm_)
          Pause the named vm

          CLI Example:

             salt '*' virt.pause <vm name>

   salt.modules.xapi.reboot(vm_)
          Reboot a domain via ACPI request

          CLI Example:

             salt '*' virt.reboot <vm name>

   salt.modules.xapi.reset(vm_)
          Reset a VM by emulating the reset button on a physical machine

          CLI Example:

             salt '*' virt.reset <vm name>

   salt.modules.xapi.resume(vm_)
          Resume the named vm

          CLI Example:

             salt '*' virt.resume <vm name>

   salt.modules.xapi.setmem(vm_, memory)
          Changes the amount of memory allocated to VM.

          Memory is to be specified in MB

          CLI Example:

             salt '*' virt.setmem myvm 768

   salt.modules.xapi.setvcpus(vm_, vcpus)
          Changes the amount of vcpus allocated to VM.

          vcpus is an int representing the number to be assigned

          CLI Example:

             salt '*' virt.setvcpus myvm 2

   salt.modules.xapi.shutdown(vm_)
          Send a soft shutdown signal to the named vm

          CLI Example:

             salt '*' virt.shutdown <vm name>

   salt.modules.xapi.start(config_)
          Start a defined domain

          CLI Example:

             salt '*' virt.start <path to Xen cfg file>

   salt.modules.xapi.stop(vm_)
          Hard  power  down  the  virtual  machine,  this is equivalent to
          pulling the power

          CLI Example:

             salt '*' virt.stop <vm name>

   salt.modules.xapi.vcpu_pin(vm_, vcpu, cpus)
          Set which CPUs a VCPU can use.

          CLI Example:

             salt 'foo' virt.vcpu_pin domU-id 2 1
             salt 'foo' virt.vcpu_pin domU-id 2 2-6

   salt.modules.xapi.vm_cputime(vm_=None)
          Return cputime used by the vms on this hyper in a list of dicts:

             [
                 'your-vm': {
                     'cputime' <int>
                     'cputime_percent' <int>
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_cputime

   salt.modules.xapi.vm_diskstats(vm_=None)
          Return  disk  usage  counters used by the vms on this hyper in a
          list of dicts:

             [
                 'your-vm': {
                     'io_read_kbs'   : 0,
                     'io_write_kbs'  : 0
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_diskstats

   salt.modules.xapi.vm_info(vm_=None)
          Return detailed information about the vms.

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_info

   salt.modules.xapi.vm_netstats(vm_=None)
          Return combined network counters used by the vms on  this  hyper
          in a list of dicts:

             [
                 'your-vm': {
                     'io_read_kbs'           : 0,
                     'io_total_read_kbs'     : 0,
                     'io_total_write_kbs'    : 0,
                     'io_write_kbs'          : 0
                     },
                 ...
                 ]

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_netstats

   salt.modules.xapi.vm_state(vm_=None)
          Return list of all the vms and their state.

          If you pass a VM name in as an argument then it will return info
          for just the named VM, otherwise it will return all VMs.

          CLI Example:

             salt '*' virt.vm_state <vm name>

   salt.modules.xfs
   Module for managing XFS file systems.

   salt.modules.xfs.defragment(device)
          Defragment   mounted  XFS  filesystem.   In  order  to  mount  a
          filesystem, device should be properly mounted and writable.

          CLI Example:

             salt '*' xfs.defragment /dev/sda1

   salt.modules.xfs.devices()
          Get known XFS formatted devices on the system.

          CLI Example:

             salt '*' xfs.devices

   salt.modules.xfs.dump(device,   destination,    level=0,    label=None,
   noerase=None)
          Dump filesystem device to the media (file, tape etc).

          Required parameters:

          * device: XFS device, content of which to be dumped.

          * destination: Specifies a dump destination.

          Valid options are:

          * label:  Label  of  the dump. Otherwise automatically generated
            label is used.

          * level: Specifies a dump level of 0 to 9.

          * noerase: Pre-erase media.

          Other options are not used in  order  to  let  xfsdump  use  its
          default  values,  as  they  are most optimal. See the xfsdump(8)
          manpage for a more complete description of these options.

          CLI Example:

             salt '*' xfs.dump /dev/sda1 /detination/on/the/client
             salt '*' xfs.dump /dev/sda1 /detination/on/the/client label='Company accountancy'
             salt '*' xfs.dump /dev/sda1 /detination/on/the/client noerase=True

   salt.modules.xfs.estimate(path)
          Estimate the space that an XFS filesystem will take.   For  each
          directory  estimate  the  space  that directory would take if it
          were copied to an XFS filesystem.   Estimation  does  not  cross
          mount points.

          CLI Example:

             salt '*' xfs.estimate /path/to/file
             salt '*' xfs.estimate /path/to/dir/*

   salt.modules.xfs.info(device)
          Get filesystem geometry information.

          CLI Example:

             salt '*' xfs.info /dev/sda1

   salt.modules.xfs.inventory()
          Display XFS dump inventory without restoration.

          CLI Example:

             salt '*' xfs.inventory

   salt.modules.xfs.mkfs(device,   label=None,  ssize=None,  noforce=None,
   bso=None, gmo=None, ino=None, lso=None, rso=None, nmo=None, dso=None)
          Create a file system on the specified device. By  default  wipes
          out with force.

          General options:

          * label: Specify volume label.

          * ssize: Specify the fundamental sector size of the filesystem.

          * noforce:  Do  not  force create filesystem, if disk is already
            formatted.

          Filesystem geometry options:

          * bso: Block size options.

          * gmo: Global metadata options.

          *

            dso: Data section options. These options specify the location,
            size,
                   and  other  parameters  of  the  data  section  of  the
                   filesystem.

          * ino:  Inode  options  to  specify  the  inode  size   of   the
            filesystem, and other inode allocation parameters.

          * lso: Log section options.

          * nmo: Naming options.

          * rso: Realtime section options.

          See  the  mkfs.xfs(8) manpage for a more complete description of
          corresponding options description.

          CLI Example:

             salt '*' xfs.mkfs /dev/sda1
             salt '*' xfs.mkfs /dev/sda1 dso='su=32k,sw=6' noforce=True
             salt '*' xfs.mkfs /dev/sda1 dso='su=32k,sw=6' lso='logdev=/dev/sda2,size=10000b'

   salt.modules.xfs.modify(device,     label=None,     lazy_counting=None,
   uuid=None)
          Modify parameters of an XFS filesystem.

          CLI Example:

             salt '*' xfs.modify /dev/sda1 label='My backup' lazy_counting=False
             salt '*' xfs.modify /dev/sda1 uuid=False
             salt '*' xfs.modify /dev/sda1 uuid=True

   salt.modules.xfs.prune_dump(sessionid)
          Prunes the dump session identified by the given session id.

          CLI Example:

             salt '*' xfs.prune_dump b74a3586-e52e-4a4a-8775-c3334fa8ea2c

   salt.modules.xmpp
   Module for Sending Messages via XMPP (a.k.a. Jabber)

   New in version 2014.1.0.

   depends

          * sleekxmpp>=1.3.1

          * pyasn1

          * pyasn1-modules

          * dnspython

   configuration
          This  module  can  be  used by either passing a jid and password
          directly to  send_message,  or  by  specifying  the  name  of  a
          configuration  profile  in  the minion config, minion pillar, or
          master config.

          For example:

             my-xmpp-login:
                 xmpp.jid: [email protected]/resourcename
                 xmpp.password: verybadpass

          The resourcename refers to  the  resource  that  is  using  this
          account.  It  is  user-definable,  and  optional.  The following
          configurations are both valid:

             my-xmpp-login:
                 xmpp.jid: [email protected]/salt
                 xmpp.password: verybadpass

             my-xmpp-login:
                 xmpp.jid: [email protected]
                 xmpp.password: verybadpass

   salt.modules.xmpp.send_msg(recipient, message, jid=None, password=None,
   profile=None)
          Send a message to an XMPP recipient. Designed for use in states.

          CLI Examples:

             xmpp.send_msg '[email protected]' 'This is a salt module test'             profile='my-xmpp-account'
             xmpp.send_msg '[email protected]' 'This is a salt module test'             jid='[email protected]/salt' password='verybadpass'

   salt.modules.xmpp.send_msg_multi(message,  recipients=None, rooms=None,
   jid=None, password=None, nick='SaltStack Bot', profile=None)
          Send a message to an XMPP recipient,  support  send  message  to
          multiple recipients or chat room.

          CLI Examples:

             xmpp.send_msg recipients=['[email protected]']             rooms=['[email protected]']             'This is a salt module test'             profile='my-xmpp-account'
             xmpp.send_msg recipients=['[email protected]']             rooms=['[email protected]']            'This is a salt module test'             jid='[email protected]/salt' password='verybadpass'

   salt.modules.yumpkg
   Support for YUM/DNF

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   NOTE:
      DNF is fully supported as of version 2015.5.10 and 2015.8.4 (partial
      support for DNF was initially added in 2015.8.0), and  DNF  is  used
      automatically in place of YUM in Fedora 22 and newer.

   salt.modules.yumpkg.clean_metadata(**kwargs)
          New in version 2014.1.0.

          Cleans   local   yum   metadata.   Functionally   identical   to
          refresh_db().

          CLI Example:

             salt '*' pkg.clean_metadata

   salt.modules.yumpkg.del_repo(repo, basedir=None, **kwargs)
          Delete a repo from  <basedir>  (default  basedir:  all  dirs  in
          reposdir yum option).

          If  the .repo file in which the repo exists does not contain any
          other repo configuration, the file itself will be deleted.

          CLI Examples:

             salt '*' pkg.del_repo myrepo
             salt '*' pkg.del_repo myrepo basedir=/path/to/dir
             salt '*' pkg.del_repo myrepo basedir=/path/to/dir,/path/to/another/dir

   salt.modules.yumpkg.diff(*paths)
          Return a formatted diff between current files and original in  a
          package.   NOTE: this function includes all files (configuration
          and not), but does not work on binary content.

          Parameters
                 path -- Full path to the installed file

          Returns
                 Difference string or raises  and  exception  if  examined
                 file is binary.

          CLI example:

             salt '*' pkg.diff /etc/apache2/httpd.conf /etc/sudoers

   salt.modules.yumpkg.download(*packages)
          New in version 2015.5.0.

          Download packages to the local disk. Requires yumdownloader from
          yum-utils package.

          NOTE:
             yum-utils will already be installed  on  the  minion  if  the
             package was installed from the Fedora / EPEL repositories.

          CLI example:

             salt '*' pkg.download httpd
             salt '*' pkg.download httpd postfix

   salt.modules.yumpkg.file_dict(*packages)
          New in version 2014.1.0.

          List the files that belong to a package, grouped by package. Not
          specifying any packages will return a list of every file on  the
          system's rpm database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.yumpkg.file_list(*packages)
          New in version 2014.1.0.

          List  the  files  that  belong  to a package. Not specifying any
          packages will return a list of every file on  the  system's  rpm
          database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.yumpkg.get_repo(name, basedir=None, **kwargs)
          Display  a  repo  from  <basedir>  (default basedir: all dirs in
          reposdir yum option).

          CLI Examples:

             salt '*' pkg.get_repo myrepo
             salt '*' pkg.get_repo myrepo basedir=/path/to/dir
             salt '*' pkg.get_repo myrepo basedir=/path/to/dir,/path/to/another/dir

   salt.modules.yumpkg.group_diff(name)
          New in version 2014.1.0.

          Changed  in  version  2016.3.0,2015.8.4,2015.5.10:   Environment
          groups  are  now  supported.  The  key  names have been renamed,
          similar to the changes made in pkg.group_info.

          Lists which of a group's packages are installed  and  which  are
          not installed

          CLI Example:

             salt '*' pkg.group_diff 'Perl Support'

   salt.modules.yumpkg.group_info(name, expand=False)
          New in version 2014.1.0.

          Changed  in version 2016.3.0,2015.8.4,2015.5.10: The return data
          has changed. A new  key  type  has  been  added  to  distinguish
          environment groups from package groups. Also, keys for the group
          name and group ID  have  been  added.  The  mandatory  packages,
          optional  packages,  and default packages keys have been renamed
          to mandatory, optional, and default for accuracy, as environment
          groups  include  other  groups,  and not packages. Finally, this
          function now properly identifies conditional packages.

          Lists packages belonging to a certain group

          name   Name of the group to query

          expand False If the specified group  is  an  environment  group,
                 then  the group will be expanded and the return data will
                 include package names instead of group names.

                 New in version 2016.3.0.

          CLI Example:

             salt '*' pkg.group_info 'Perl Support'

   salt.modules.yumpkg.group_install(name, skip=(), include=(), **kwargs)
          New in version 2014.1.0.

          Install the passed package group(s). This is basically a wrapper
          around  pkg.install, which performs package group resolution for
          the user. This function is  currently  considered  experimental,
          and should be expected to undergo changes.

          name   Package group to install. To install more than one group,
                 either use a comma-separated list or pass the value as  a
                 python list.

                 CLI Examples:

                    salt '*' pkg.group_install 'Group 1'
                    salt '*' pkg.group_install 'Group 1,Group 2'
                    salt '*' pkg.group_install '["Group 1", "Group 2"]'

          skip   Packages  that would normally be installed by the package
                 group  ("default"  packages),   which   should   not   be
                 installed. Can be passed either as a comma-separated list
                 or a python list.

                 CLI Examples:

                    salt '*' pkg.group_install 'My Group' skip='foo,bar'
                    salt '*' pkg.group_install 'My Group' skip='["foo", "bar"]'

          include
                 Packages which are included in a group, which  would  not
                 normally  be  installed by a yum groupinstall ("optional"
                 packages).  Note  that  this  will  not   enforce   group
                 membership; if you include packages which are not members
                 of the specified groups, they will  still  be  installed.
                 Can  be  passed  either  as  a  comma-separated list or a
                 python list.

                 CLI Examples:

                    salt '*' pkg.group_install 'My Group' include='foo,bar'
                    salt '*' pkg.group_install 'My Group' include='["foo", "bar"]'

          NOTE:
             Because this is essentially a wrapper around pkg.install, any
             argument  which  can  be  passed  to  pkg.install may also be
             included here, and it will be passed along wholesale.

   salt.modules.yumpkg.group_list()
          New in version 2014.1.0.

          Lists all groups known by yum on this system

          CLI Example:

             salt '*' pkg.group_list

   salt.modules.yumpkg.hold(name=None,      pkgs=None,       sources=None,
   normalize=True, **kwargs)
          New in version 2014.7.0.

          Version-lock packages

          NOTE:
             Requires  the  appropriate  versionlock  plugin package to be
             installed:

             * On RHEL 5: yum-versionlock

             * On RHEL 6 & 7: yum-plugin-versionlock

             * On Fedora: python-dnf-plugins-extras-versionlock

          name   The name of the package to be held.

          Multiple Package Options:

          pkgs   A list of packages to hold. Must be passed  as  a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.hold <package name>
             salt '*' pkg.hold pkgs='["foo", "bar"]'

   salt.modules.yumpkg.info_installed(*names)
          New in version 2015.8.1.

          Return the information of the named package(s), installed on the
          system.

          CLI example:

             salt '*' pkg.info_installed <package1>
             salt '*' pkg.info_installed <package1> <package2> <package3> ...

   salt.modules.yumpkg.install(name=None,                   refresh=False,
   skip_verify=False,    pkgs=None,     sources=None,     reinstall=False,
   normalize=True, update_holds=False, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing   any   yum/dnf   commands  spawned  by  Salt  when  the
          salt-minion  service  is  restarted.  (see   KillMode   in   the
          systemd.kill(5) manpage for more information). If desired, usage
          of systemd-run(1) can be suppressed by setting a  config  option
          called systemd.scope, with a value of False (no quotes).

          Install the passed package(s), add refresh=True to clean the yum
          database before package is installed.

          name   The name of the package to be installed. Note  that  this
                 parameter  is  ignored  if  either "pkgs" or "sources" is
                 passed. Additionally, please note that  this  option  can
                 only   be  used  to  install  packages  from  a  software
                 repository. To install a package file manually,  use  the
                 "sources" option.

                 32-bit  packages  can  be  installed on 64-bit systems by
                 appending the  architecture  designation  (.i686,  .i586,
                 etc.) to the end of the package name.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 Whether   or  not  to  update  the  yum  database  before
                 executing.

          reinstall
                 Specifying reinstall=True will use yum  reinstall  rather
                 than  yum install for requested packages that are already
                 installed.

                 If a version is specified  with  the  requested  package,
                 then  yum  reinstall  will  only be used if the installed
                 version matches the requested version.

                 Works with sources when the package header of the  source
                 can  be  matched  to the name and version of an installed
                 package.

                 New in version 2014.7.0.

          skip_verify
                 Skip the GPG verification check (e.g., --nogpgcheck)

          version
                 Install  a  specific  version  of   the   package,   e.g.
                 1.2.3-4.el5. Ignored if "pkgs" or "sources" is passed.

          update_holds
                 False If True, and this function would update the package
                 version,   any   packages   held   using   the    yum/dnf
                 "versionlock"  plugin  will be unheld so that they can be
                 updated. Otherwise, if this function attempts to update a
                 held  package, the held package(s) will be skipped and an
                 error will be raised.

                 New in version 2016.11.0.

          Repository Options:

          fromrepo
                 Specify a package repository (or repositories) from which
                 to     install.      (e.g.,     yum     --disablerepo='*'
                 --enablerepo='somerepo')

          enablerepo (ignored if fromrepo is specified)
                 Specify a disabled package repository  (or  repositories)
                 to enable.  (e.g., yum --enablerepo='somerepo')

          disablerepo (ignored if fromrepo is specified)
                 Specify  an  enabled package repository (or repositories)
                 to disable.  (e.g., yum --disablerepo='somerepo')

          disableexcludes
                 Disable exclude from main, for a repo or for  everything.
                 (e.g., yum --disableexcludes='main')

                 New in version 2014.7.0.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must be passed as  a  python  list.  A  specific  version
                 number  can  be  specified by using a single-element dict
                 representing the package and its version.

                 CLI Examples:

                    salt '*' pkg.install pkgs='["foo", "bar"]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "1.2.3-4.el5"}]'

          sources
                 A list of RPM packages to install. Must be  passed  as  a
                 list of dicts, with the keys being package names, and the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.rpm"}, {"bar": "salt://bar.rpm"}]'

          normalize
                 True  Normalize  the  package  name   by   removing   the
                 architecture.  This is useful for poorly created packages
                 which might include the architecture as an actual part of
                 the  name  such  as kernel modules which match a specific
                 kernel version.

                    salt -G role:nsd pkg.install gpfs.gplbin-2.6.32-279.31.1.el6.x86_64 normalize=False

                 New in version 2014.7.0.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.yumpkg.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty string will be returned for that package.

          A  specific  repo  can  be  requested using the fromrepo keyword
          argument, and the disableexcludes option is also supported.

          New in version 2014.7.0: Support for the disableexcludes option

          CLI Example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package name> fromrepo=epel-testing
             salt '*' pkg.latest_version <package name> disableexcludes=main
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.yumpkg.list_holds(pattern='\\w+(?:[.-][^-]+)*', full=True)
          Changed in version 2016.3.0,2015.8.4,2015.5.10: Function renamed
          from pkg.get_locked_pkgs to pkg.list_holds.

          List information on locked packages

          NOTE:
             Requires  the  appropriate  versionlock  plugin package to be
             installed:

             * On RHEL 5: yum-versionlock

             * On RHEL 6 & 7: yum-plugin-versionlock

             * On Fedora: python-dnf-plugins-extras-versionlock

          pattern
                 \w+(?:[.-][^-]+)* Regular expression used  to  match  the
                 package name

          full   True  Show the full hold definition including version and
                 epoch. Set to False  to  return  just  the  name  of  the
                 package(s) being held.

          CLI Example:

             salt '*' pkg.list_holds
             salt '*' pkg.list_holds full=False

   salt.modules.yumpkg.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed in a dict:

             {'<package_name>': '<version>'}

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.yumpkg.list_repo_pkgs(*args, **kwargs)
          New in version 2014.1.0.

          Changed  in  version  2014.7.0:  All  available versions of each
          package are now returned. This required a slight modification to
          the  structure  of  the return dict. The return data shown below
          reflects the updated return dict structure. Note  that  packages
          which  are  version-locked  using  pkg.hold  will  only show the
          currently-installed version, as  locking  a  package  will  make
          other versions appear unavailable to yum/dnf.

          Returns  all  available packages. Optionally, package names (and
          name globs) can be passed and the results will  be  filtered  to
          packages  matching those names. This is recommended as it speeds
          up the function considerably.

          WARNING:
             Running this function on RHEL/CentOS 6 and  earlier  will  be
             more  resource-intensive,  as  the  version of yum that ships
             with older RHEL/CentOS has  no  yum  subcommand  for  listing
             packages  from  a  repository. Thus, a yum list installed and
             yum list available are run, which generates a lot of  output,
             which  must  then  be  analyzed  to  determine  which package
             information to include in the return data.

          This function can be helpful in discovering the version or  repo
          to specify in a pkg.installed state.

          The  return  data  is a dictionary of repo names, with each repo
          containing a dictionary in which the keys are package names, and
          the  values are a list of version numbers. Here is an example of
          the return data:

             {
                 'base': {
                     'bash': ['4.1.2-15.el6_4'],
                     'kernel': ['2.6.32-431.el6']
                 },
                 'updates': {
                     'bash': ['4.1.2-15.el6_5.2', '4.1.2-15.el6_5.1'],
                     'kernel': ['2.6.32-431.29.2.el6',
                                '2.6.32-431.23.3.el6',
                                '2.6.32-431.20.5.el6',
                                '2.6.32-431.20.3.el6',
                                '2.6.32-431.17.1.el6',
                                '2.6.32-431.11.2.el6',
                                '2.6.32-431.5.1.el6',
                                '2.6.32-431.3.1.el6',
                                '2.6.32-431.1.2.0.1.el6']
                 }
             }

          fromrepo
                 None Only include results  from  the  specified  repo(s).
                 Multiple repos can be specified, comma-separated.

          CLI Example:

             salt '*' pkg.list_repo_pkgs
             salt '*' pkg.list_repo_pkgs foo bar baz
             salt '*' pkg.list_repo_pkgs 'samba4*' fromrepo=base,updates

   salt.modules.yumpkg.list_repos(basedir=None)
          Lists  all repos in <basedir> (default: all dirs in reposdir yum
          option).

          CLI Example:

             salt '*' pkg.list_repos
             salt '*' pkg.list_repos basedir=/path/to/dir
             salt '*' pkg.list_repos basedir=/path/to/dir,/path/to/another/dir

   salt.modules.yumpkg.list_upgrades(refresh=True, **kwargs)
          Check whether or not an upgrade is available for all packages

          The  fromrepo,  enablerepo,  and   disablerepo   arguments   are
          supported, as used in pkg states, and the disableexcludes option
          is also supported.

          New in version 2014.7.0: Support for the disableexcludes option

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.yumpkg.mod_repo(repo, basedir=None, **kwargs)
          Modify one or more values for a  repo.  If  the  repo  does  not
          exist,  it  will be created, so long as the following values are
          specified:

          repo   name by which the yum refers to the repo

          name   a human-readable name for the repo

          baseurl
                 the URL for yum to reference

          mirrorlist
                 the URL for yum to reference

          Key/Value pairs may also be removed from a repo's  configuration
          by  setting  a  key  to  a blank value. Bear in mind that a name
          cannot be deleted, and a  baseurl  can  only  be  deleted  if  a
          mirrorlist is specified (or vice versa).

          CLI Examples:

             salt '*' pkg.mod_repo reponame enabled=1 gpgcheck=1
             salt '*' pkg.mod_repo reponame basedir=/path/to/dir enabled=1
             salt '*' pkg.mod_repo reponame baseurl= mirrorlist=http://host.com/

   salt.modules.yumpkg.modified(*packages, **flags)
          List the modified files that belong to a package. Not specifying
          any packages will return a list of _all_ modified files  on  the
          system's RPM database.

          New in version 2015.5.0.

          Filtering by flags (True or False):

          size   Include only files where size changed.

          mode   Include only files which file's mode has been changed.

          checksum
                 Include only files which MD5 checksum has been changed.

          device Include only files which major and minor numbers has been
                 changed.

          symlink
                 Include only files which are symbolic link contents.

          owner  Include only files where owner has been changed.

          group  Include only files where group has been changed.

          time   Include only files where modification time  of  the  file
                 has been changed.

          capabilities
                 Include  only  files  where  capabilities  differ or not.
                 Note: supported only on newer RPM versions.

          CLI Examples:

             salt '*' pkg.modified
             salt '*' pkg.modified httpd
             salt '*' pkg.modified httpd postfix
             salt '*' pkg.modified httpd owner=True group=False

   salt.modules.yumpkg.normalize_name(name)
          Strips the architecture from  the  specified  package  name,  if
          necessary.  Circumstances where this would be done include:

          * If  the  arch  is 32 bit and the package name ends in a 32-bit
            arch.

          * If the arch matches the OS arch, or is noarch.

          CLI Example:

             salt '*' pkg.normalize_name zsh.x86_64

   salt.modules.yumpkg.owner(*paths)
          New in version 2014.7.0.

          Return the name of the package that owns the file. Multiple file
          paths       can       be      passed.      Like      pkg.version
          <salt.modules.yumpkg.version, if a  single  path  is  passed,  a
          string  will  be  returned,  and if multiple paths are passed, a
          dictionary of file/package name pairs will be returned.

          If the file is not owned by a package, or is not present on  the
          minion, then an empty string will be returned for that path.

          CLI Examples:

             salt '*' pkg.owner /usr/bin/apachectl
             salt '*' pkg.owner /usr/bin/apachectl /etc/httpd/conf/httpd.conf

   salt.modules.yumpkg.purge(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing   any   yum/dnf   commands  spawned  by  Salt  when  the
          salt-minion  service  is  restarted.  (see   KillMode   in   the
          systemd.kill(5) manpage for more information). If desired, usage
          of systemd-run(1) can be suppressed by setting a  config  option
          called systemd.scope, with a value of False (no quotes).

          Package  purges  are  not  supported  by  yum,  this function is
          identical to pkg.remove.

          name   The name of the package to be purged

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.yumpkg.refresh_db(**kwargs)
          Check the yum repos for updated packages

          Returns:

          * True: Updates are available

          * False: An error occurred

          * None: No updates are available

          repo   Refresh just the specified repo

          disablerepo
                 Do not refresh the specified repo

          enablerepo
                 Refresh a disabled repo using this option

          branch Add the specified branch when refreshing

          disableexcludes
                 Disable the excludes defined in your config files.  Takes
                 one of three options: - all - disable all excludes - main
                 - disable excludes defined in [main] in yum.conf - repoid
                 - disable excludes defined for that repo

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.yumpkg.remove(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing   any   yum/dnf   commands  spawned  by  Salt  when  the
          salt-minion  service  is  restarted.  (see   KillMode   in   the
          systemd.kill(5) manpage for more information). If desired, usage
          of systemd-run(1) can be suppressed by setting a  config  option
          called systemd.scope, with a value of False (no quotes).

          Remove packages

          name   The name of the package to be removed

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.yumpkg.unhold(name=None,      pkgs=None,     sources=None,
   **kwargs)
          New in version 2014.7.0.

          Remove version locks

          NOTE:
             Requires the appropriate versionlock  plugin  package  to  be
             installed:

             * On RHEL 5: yum-versionlock

             * On RHEL 6 & 7: yum-plugin-versionlock

             * On Fedora: python-dnf-plugins-extras-versionlock

          name   The name of the package to be unheld

          Multiple Package Options:

          pkgs   A  list of packages to unhold. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.unhold <package name>
             salt '*' pkg.unhold pkgs='["foo", "bar"]'

   salt.modules.yumpkg.upgrade(name=None,     pkgs=None,     refresh=True,
   skip_verify=False, normalize=True, **kwargs)
          Run a full system upgrade (a yum upgrade  or  dnf  upgrade),  or
          upgrade  specified  packages.  If the packages aren't installed,
          they will not be installed.

          Changed in version 2014.7.0.

          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing  any  yum/dnf  commands  spawned  by   Salt   when   the
          salt-minion   service   is   restarted.  (see  KillMode  in  the
          systemd.kill(5) manpage for more information). If desired, usage
          of  systemd-run(1)  can be suppressed by setting a config option
          called systemd.scope, with a value of False (no quotes).

          Run a full system upgrade, a yum upgrade

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade
             salt '*' pkg.upgrade name=openssl

          Repository Options:

          fromrepo
                 Specify a package repository (or repositories) from which
                 to     install.      (e.g.,     yum     --disablerepo='*'
                 --enablerepo='somerepo')

          enablerepo (ignored if fromrepo is specified)
                 Specify a disabled package repository  (or  repositories)
                 to enable.  (e.g., yum --enablerepo='somerepo')

          disablerepo (ignored if fromrepo is specified)
                 Specify  an  enabled package repository (or repositories)
                 to disable.  (e.g., yum --disablerepo='somerepo')

          disableexcludes
                 Disable exclude from main, for a repo or for  everything.
                 (e.g., yum --disableexcludes='main')

                 New in version 2014.7.

          name   The  name  of  the package to be upgraded. Note that this
                 parameter is ignored if "pkgs" is passed.

                 32-bit packages can be  upgraded  on  64-bit  systems  by
                 appending  the  architecture  designation  (.i686, .i586,
                 etc.) to the end of the package name.

                 Warning:  if  you  forget  'name='  and  run  pkg.upgrade
                 openssl,   ALL   packages  are  upgraded.  This  will  be
                 addressed in next releases.

                 CLI Example:

                    salt '*' pkg.upgrade name=openssl

                 New in version 2016.3.0.

          pkgs   A list of packages to upgrade from a software repository.
                 Must  be  passed  as  a  python  list. A specific version
                 number can be specified by using  a  single-element  dict
                 representing  the package and its version. If the package
                 was not already installed on the system, it will  not  be
                 installed.

                 CLI Examples:

                    salt '*' pkg.upgrade pkgs='["foo", "bar"]'
                    salt '*' pkg.upgrade pkgs='["foo", {"bar": "1.2.3-4.el5"}]'

                 New in version 2016.3.0.

          normalize
                 True   Normalize   the   package  name  by  removing  the
                 architecture. This is useful for poorly created  packages
                 which might include the architecture as an actual part of
                 the name such as kernel modules which  match  a  specific
                 kernel version.

                    salt -G role:nsd pkg.upgrade gpfs.gplbin-2.6.32-279.31.1.el6.x86_64 normalize=False

                 New in version 2016.3.0.

   salt.modules.yumpkg.upgrade_available(name)
          Check whether or not an upgrade is available for a given package

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.yumpkg.verify(*names, **kwargs)
          New in version 2014.1.0.

          Runs an rpm -Va on a system, and returns the results in a dict

          Pass   options   to   modify   rpm  verify  behavior  using  the
          verify_options keyword argument

          Files with an attribute of config, doc, ghost, license or readme
          in  the  package  header  can  be ignored using the ignore_types
          keyword argument

          CLI Example:

             salt '*' pkg.verify
             salt '*' pkg.verify httpd
             salt '*' pkg.verify 'httpd postfix'
             salt '*' pkg.verify 'httpd postfix' ignore_types=['config','doc']
             salt '*' pkg.verify 'httpd postfix' verify_options=['nodeps','nosize']

   salt.modules.yumpkg.version(*names, **kwargs)
          Returns a string representing the package version  or  an  empty
          string  if  not  installed.  If  more  than  one package name is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.yumpkg.version_cmp(pkg1, pkg2, ignore_epoch=False)
          New in version 2015.5.4.

          Do a cmp-style comparison on two packages. Return -1 if  pkg1  <
          pkg2,  0  if  pkg1 == pkg2, and 1 if pkg1 > pkg2. Return None if
          there was a problem making the comparison.

          ignore_epoch
                 False Set to True to  ignore  the  epoch  when  comparing
                 versions

                 New in version 2015.8.10,2016.3.2.

          CLI Example:

             salt '*' pkg.version_cmp '0.2-001' '0.2.0.1-002'

   salt.modules.zabbix module
   Support for Zabbix

   optdepends

          * zabbix server

   configuration
          This  module  is  not  usable  until  the zabbix user and zabbix
          password are specified either in a pillar  or  in  the  minion's
          config file. Zabbix url should be also specified.

             zabbix.user: Admin
             zabbix.password: mypassword
             zabbix.url: http://127.0.0.1/zabbix/api_jsonrpc.php

          Connection   arguments  from  the  minion  config  file  can  be
          overridden on the  CLI  by  using  arguments  with  _connection_
          prefix.

             zabbix.apiinfo_version _connection_user=Admin _connection_password=zabbix _connection_url=http://host/zabbix/

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.modules.zabbix.apiinfo_version(**connection_args)
          Retrieve the version of the Zabbix API.

          New in version 2016.3.0.

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 On  success  string  with  Zabbix  API  version, False on
                 failure.

          CLI Example:
             salt '*' zabbix.apiinfo_version

   salt.modules.zabbix.host_create(host,        groups,        interfaces,
   **connection_args)
          Create  new host.  NOTE: This function accepts all standard host
          properties: keyword argument  names  differ  depending  on  your
          zabbix                       version,                       see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/host/object#host

          New in version 2016.3.0.

          Parameters

                 * host -- technical name of the host

                 * groups -- groupids of host groups to add the host to

                 * interfaces -- interfaces to be created for the host

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

                 * visible_name  --  string with visible name of the host,
                   use 'visible_name' instead of 'name' parameter

          to not mess with value supplied from Salt sls file.

          return: ID of the created host.

          CLI Example:

             salt '*' zabbix.host_create technicalname 4
             interfaces='{type: 1, main: 1, useip: 1, ip: "192.168.3.1", dns: "", port: 10050}'
             visible_name='Host Visible Name'

   salt.modules.zabbix.host_delete(hostids, **connection_args)
          Delete hosts.

          New in version 2016.3.0.

          Parameters

                 * hostids -- Hosts (hostids) to delete.

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 IDs of the deleted hosts.

          CLI Example:
             salt '*' zabbix.host_delete 10106

   salt.modules.zabbix.host_exists(host=None,   hostid=None,    name=None,
   node=None, nodeids=None, **connection_args)
          Checks  if  at  least  one  host  that  matches the given filter
          criteria exists.

          New in version 2016.3.0.

          Parameters

                 * host -- technical name of the host

                 * hostids -- Hosts (hostids) to delete.

                 * name -- visible name of the host

                 * node -- name of the  node  the  hosts  must  belong  to
                   (zabbix API < 2.4)

                 * nodeids  --  IDs  of  the node the hosts must belong to
                   (zabbix API < 2.4)

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 IDs of the deleted hosts, False on failure.

          CLI Example:
             salt '*' zabbix.host_exists 'Zabbix server'

   salt.modules.zabbix.host_get(host=None,    name=None,     hostids=None,
   **connection_args)
          Retrieve  hosts  according  to the given parameters.  NOTE: This
          function  accepts  all  optional  host.get  parameters:  keyword
          argument  names  differ  depending  on your zabbix version, see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/host/get

          New in version 2016.3.0.

          Parameters

                 * host -- technical name of the host

                 * name -- visible name of the host

                 * hostids -- ids of the hosts

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Array  with  convenient  hosts  details, False if no host
                 found or on failure.

          CLI Example:
             salt '*' zabbix.host_get 'Zabbix server'

   salt.modules.zabbix.host_list(**connection_args)
          Retrieve all hosts.

          New in version 2016.3.0.

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 Array with details about hosts, False on failure.

          CLI Example:
             salt '*' zabbix.host_list

   salt.modules.zabbix.host_update(hostid, **connection_args)
          Update existing hosts.  NOTE: This function accepts all standard
          host  and  host.update properties: keyword argument names differ
          depending      on      your      zabbix      version,       see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/host/update
          https://www.zabbix.com/documentation/2.4/manual/api/reference/host/object#host

          New in version 2016.3.0.

          Parameters

                 * hostid -- ID of the host to update

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

                 * visible_name  --  string with visible name of the host,
                   use 'visible_name' instead of 'name' parameter

          to not mess with value supplied from Salt sls file.

          Returns
                 ID of the updated host.

          CLI Example:
             salt '*' zabbix.host_update 10084 name='Zabbix server2'

   salt.modules.zabbix.hostgroup_create(name, **connection_args)
          Create a host group.  NOTE: This function accepts  all  standard
          host  group  properties: keyword argument names differ depending
          on          your          zabbix          version,          see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/hostgroup/object#host_group

          New in version 2016.3.0.

          Parameters

                 * name -- name of the host group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 ID of the created host group.

          CLI Example:
             salt '*' zabbix.hostgroup_create MyNewGroup

   salt.modules.zabbix.hostgroup_delete(hostgroupids, **connection_args)
          Delete the host group.

          New in version 2016.3.0.

          Parameters

                 * hostgroupids -- IDs of the host groups to delete

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 ID of the deleted host groups, False on failure.

          CLI Example:
             salt '*' zabbix.hostgroup_delete 23

   salt.modules.zabbix.hostgroup_exists(name=None,           groupid=None,
   node=None, nodeids=None, **connection_args)
          Checks  if at least one host group that matches the given filter
          criteria exists.

          New in version 2016.3.0.

          Parameters

                 * name -- names of the host groups

                 * groupid -- host group IDs

                 * node -- name of the node the host groups must belong to
                   (zabbix API < 2.4)

                 * nodeids -- IDs of the nodes the host groups must belong
                   to (zabbix API < 2.4)

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 True if at least one host group exists, False if  not  or
                 on failure.

          CLI Example:
             salt '*' zabbix.hostgroup_exists MyNewGroup

   salt.modules.zabbix.hostgroup_get(name=None,             groupids=None,
   hostids=None, **connection_args)
          Retrieve host groups according to the given  parameters.   NOTE:
          This  function  accepts  all standard hostgroup.get properities:
          keyword argument names differ depending on your zabbix  version,
          see:
          https://www.zabbix.com/documentation/2.2/manual/api/reference/hostgroup/get

          New in version 2016.3.0.

          Parameters

                 * name -- names of the host groups

                 * groupid -- host group IDs

                 * node -- name of the node the host groups must belong to

                 * nodeids -- IDs of the nodes the host groups must belong
                   to

                 * hostids -- return only host  groups  that  contain  the
                   given hosts

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Array  with  host  groups details, False if no convenient
                 host group found or on failure.

          CLI Example:
             salt '*' zabbix.hostgroup_get MyNewGroup

   salt.modules.zabbix.hostgroup_list(**connection_args)
          Retrieve all host groups.

          New in version 2016.3.0.

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 Array with details about host groups, False on failure.

          CLI Example:
             salt '*' zabbix.hostgroup_list

   salt.modules.zabbix.hostgroup_update(groupid,                name=None,
   **connection_args)
          Update  existing  hosts  group.  NOTE: This function accepts all
          standard host group properties: keyword  argument  names  differ
          depending       on      your      zabbix      version,      see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/hostgroup/object#host_group

          New in version 2016.3.0.

          Parameters

                 * groupid -- ID of the host group to update

                 * name -- name of the host group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 IDs of updated host groups.

          CLI Example:
             salt '*' zabbix.hostgroup_update 24 name='Renamed Name'

   salt.modules.zabbix.hostinterface_create(hostid,  ip,  dns='',  main=1,
   type=1, useip=1, port=None, **connection_args)
          Create new  host  interface  NOTE:  This  function  accepts  all
          standard  host  group  interface:  keyword argument names differ
          depending      on      your      zabbix      version,       see:
          https://www.zabbix.com/documentation/3.0/manual/api/reference/hostinterface/object

          New in version 2016.3.0.

          Parameters

                 * hostid -- ID of the host the interface belongs to

                 * ip -- IP address used by the interface

                 * dns -- DNS name used by the interface

                 * main -- whether the interface is used as default on the
                   host (0 - not default, 1 - default)

                 * port -- port number used by the interface

                 * type  -- Interface type (1 - agent; 2 - SNMP; 3 - IPMI;
                   4 - JMX)

                 * useip -- Whether the connection should be made  via  IP
                   (0 - connect using host DNS name; 1 - connect using

          host    IP    address    for   this   host   interface)   :param
          _connection_user: Optional - zabbix user (can  also  be  set  in
          opts    or    pillar,    see    module's    docstring)    :param
          _connection_password: Optional - zabbix password  (can  also  be
          set   in   opts   or  pillar,  see  module's  docstring)  :param
          _connection_url: Optional - url of zabbix frontend (can also  be
          set in opts, pillar, see module's docstring)

          Returns
                 ID of the created host interface, False on failure.

          CLI Example:
             salt '*' zabbix.hostinterface_create 10105 192.193.194.197

   salt.modules.zabbix.hostinterface_delete(interfaceids,
   **connection_args)
          Delete host interface

          New in version 2016.3.0.

          Parameters

                 * interfaceids -- IDs of the host interfaces to delete

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 ID of deleted host interfaces, False on failure.

          CLI Example:
             salt '*' zabbix.hostinterface_delete 50

   salt.modules.zabbix.hostinterface_get(hostids, **connection_args)
          Retrieve host groups according to the given  parameters.   NOTE:
          This    function    accepts   all   standard   hostinterface.get
          properities: keyword argument names  differ  depending  on  your
          zabbix                       version,                       see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/hostinterface/get

          New in version 2016.3.0.

          Parameters

                 * hostids  --  Return  only  host  interfaces used by the
                   given hosts.

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 Array  with  host  interfaces  details,   False   if   no
                 convenient host interfaces found or on failure.

          CLI Example:
             salt '*' zabbix.hostinterface_get 101054

   salt.modules.zabbix.hostinterface_update(interfaceid,
   **connection_args)
          Update host interface NOTE: This function accepts  all  standard
          hostinterface:  keyword  argument names differ depending on your
          zabbix                       version,                       see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/hostinterface/object#host_interface

          New in version 2016.3.0.

          Parameters

                 * interfaceid -- ID of the hostinterface to update

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 ID of the updated host interface, False on failure.

          CLI Example:
             salt '*' zabbix.hostinterface_update 6 ip=0.0.0.2

   salt.modules.zabbix.user_addmedia(userids, active, mediatypeid, period,
   sendto, severity, **connection_args)
          Add new media to multiple users.

          New in version 2016.3.0.

          Parameters

                 * userids -- ID of the user that uses the media

                 * active  --  Whether  the media is enabled (0 enabled, 1
                   disabled)

                 * mediatypeid -- ID of the media type used by the media

                 * period -- Time when the notifications can be sent as  a
                   time period

                 * sendto -- Address, user name or other identifier of the
                   recipient

                 * severity -- Trigger severities  to  send  notifications
                   about

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 IDs of the created media.

          CLI Example:
             salt   '*'   zabbix.user_addmedia  4  active=0  mediatypeid=1
             period='1-7,00:00-24:00'        sendto='[email protected]'
             severity=63

   salt.modules.zabbix.user_create(alias,         passwd,         usrgrps,
   **connection_args)
          Create  new  zabbix  user.   NOTE:  This  function  accepts  all
          standard   user   properties:   keyword  argument  names  differ
          depending      on      your      zabbix      version,       see:
          https://www.zabbix.com/documentation/2.0/manual/appendix/api/user/definitions#user

          New in version 2016.3.0.

          Parameters

                 * alias -- user alias

                 * passwd -- user's password

                 * usrgrps -- user groups to add the user to

                 * _connection_user -- zabbix user (can  also  be  set  in
                   opts or pillar, see module's docstring)

                 * _connection_password  --  zabbix  password (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_url -- url of zabbix frontend (can also  be
                   set in opts or pillar, see module's docstring)

                 * firstname  --  string  with  firstname of the user, use
                   'firstname' instead of 'name'  parameter  to  not  mess
                   with value supplied from Salt sls file.

          Returns
                 On success string with id of the created user.

          CLI Example:
             salt  '*'  zabbix.user_create  james  password007  '[7,  12]'
             firstname='James Bond'

   salt.modules.zabbix.user_delete(users, **connection_args)
          Delete zabbix users.

          New in version 2016.3.0.

          Parameters

                 * users -- array of users (userids) to delete

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 On success array with userids of deleted users.

          CLI Example:
             salt '*' zabbix.user_delete 15

   salt.modules.zabbix.user_deletemedia(mediaids, **connection_args)
          Delete media by id.

          New in version 2016.3.0.

          Parameters

                 * mediaids -- IDs of the media to delete

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 IDs of the deleted media, False on failure.

          CLI Example:
             salt '*' zabbix.user_deletemedia 27

   salt.modules.zabbix.user_exists(alias, **connection_args)
          Checks if user with given alias exists.

          New in version 2016.3.0.

          Parameters

                 * alias -- user alias

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 True if user exists, else False.

          CLI Example:
             salt '*' zabbix.user_exists james

   salt.modules.zabbix.user_get(alias=None,                  userids=None,
   **connection_args)
          Retrieve users according to the given parameters.

          New in version 2016.3.0.

          Parameters

                 * alias -- user alias

                 * userids -- return only users with the given IDs

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Array  with details of convenient users, False on failure
                 of if no user found.

          CLI Example:
             salt '*' zabbix.user_get james

   salt.modules.zabbix.user_getmedia(userids=None, **connection_args)
          Retrieve media according to  the  given  parameters  NOTE:  This
          function  accepts all standard usermedia.get properties: keyword
          argument names differ depending on  your  zabbix  version,  see:
          https://www.zabbix.com/documentation/3.2/manual/api/reference/usermedia/get

          New in version 2016.3.0.

          Parameters

                 * userids -- return only media that are used by the given
                   users

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 List of retreived media, False on failure.

          CLI Example:
             salt '*' zabbix.user_getmedia

   salt.modules.zabbix.user_list(**connection_args)
          Retrieve all of the configured users.

          New in version 2016.3.0.

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Array with user details.

          CLI Example:
             salt '*' zabbix.user_list

   salt.modules.zabbix.user_update(userid, **connection_args)
          Update  existing users. NOTE: This function accepts all standard
          user properties: keyword argument names differ depending on your
          zabbix                       version,                       see:
          https://www.zabbix.com/documentation/2.0/manual/appendix/api/user/definitions#user

          New in version 2016.3.0.

          Parameters

                 * userid -- id of the user to update

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Id of the updated user on success.

          CLI Example:
             salt '*' zabbix.user_update 16 visible_name='James Brown'

   salt.modules.zabbix.usergroup_create(name, **connection_args)
          Create new user group.  NOTE: This function accepts all standard
          user group properties: keyword argument names  differ  depending
          on          your          zabbix          version,          see:
          https://www.zabbix.com/documentation/2.0/manual/appendix/api/usergroup/definitions#user_group

          New in version 2016.3.0.

          Parameters

                 * name -- name of the user group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 IDs of the created user groups.

          CLI Example:
             salt '*' zabbix.usergroup_create GroupName

   salt.modules.zabbix.usergroup_delete(usergroupids, **connection_args)
          New in version 2016.3.0.

          Parameters

                 * usergroupids -- IDs of the user groups to delete

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 IDs of the deleted user groups.

          CLI Example:
             salt '*' zabbix.usergroup_delete 28

   salt.modules.zabbix.usergroup_exists(name=None,              node=None,
   nodeids=None, **connection_args)
          Checks if at least one user group that matches the given  filter
          criteria exists

          New in version 2016.3.0.

          Parameters

                 * name -- names of the user groups

                 * node -- name of the node the user groups must belong to
                   (This will override the nodeids parameter.)

                 * nodeids -- IDs of the nodes the user groups must belong
                   to

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 True  if  at  least one user group that matches the given
                 filter criteria exists, else False.

          CLI Example:
             salt '*' zabbix.usergroup_exists Guests

   salt.modules.zabbix.usergroup_get(name=None,            usrgrpids=None,
   userids=None, **connection_args)
          Retrieve  user  groups according to the given parameters.  NOTE:
          This function  accepts  all  usergroup_get  properties:  keyword
          argument  names  differ  depending  on your zabbix version, see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/usergroup/get

          New in version 2016.3.0.

          Parameters

                 * name -- names of the user groups

                 * usrgrpids -- return only user groups with the given IDs

                 * userids  --  return  only  user groups that contain the
                   given users

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

          Returns
                 Array with convenient user groups details,  False  if  no
                 user group found or on failure.

          CLI Example:
             salt '*' zabbix.usergroup_get Guests

   salt.modules.zabbix.usergroup_list(**connection_args)
          Retrieve all enabled user groups.

          New in version 2016.3.0.

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 Array with enabled user groups details, False on failure.

          CLI Example:
             salt '*' zabbix.usergroup_list

   salt.modules.zabbix.usergroup_update(usrgrpid, **connection_args)
          Update  existing  user  group.   NOTE: This function accepts all
          standard user group properties: keyword  argument  names  differ
          depending       on      your      zabbix      version,      see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/usergroup/object#user_group

          New in version 2016.3.0.

          Parameters

                 * usrgrpid -- ID of the user group to update.

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

          Returns
                 IDs of the updated user group, False on failure.

          CLI Example:
             salt '*' zabbix.usergroup_update 8 name=guestsRenamed

   salt.modules.zcbuildout
   Management of zc.buildout

   New in version 2014.1.0.

   This module is inspired by minitage's buildout maker

   NOTE:
      The  zc.buildout integration is still in beta; the API is subject to
      change

   General notes
   You have those following methods:

   * upgrade_bootstrap

   * bootstrap

   * run_buildout

   * buildout

   salt.modules.zcbuildout.bootstrap(*a, **kw)
          Run the buildout bootstrap dance (python bootstrap.py).

          directory
                 directory to execute in

          config alternative buildout configuration file to use

          runas  User used to run buildout as

          env    environment variables to set when running

          buildout_ver
                 force a specific buildout version (1 | 2)

          test_release
                 buildout accept test release

          offline
                 are we executing buildout in offline mode

          distribute
                 Forcing use of distribute

          new_st Forcing use of setuptools >= 0.7

          python path to a python executable to use in  place  of  default
                 (salt one)

          onlyif Only execute cmd if statement on the host return 0

          unless Do not execute cmd if statement on the host return 0

          use_vt Use the new salt VT to stream output [experimental]

          CLI Example:

             salt '*' buildout.bootstrap /srv/mybuildout

   salt.modules.zcbuildout.buildout(*a, **kw)
          Run buildout in a directory.

          directory
                 directory to execute in

          config buildout config to use

          parts  specific buildout parts to run

          runas  user used to run buildout as

          env    environment variables to set when running

          buildout_ver
                 force a specific buildout version (1 | 2)

          test_release
                 buildout accept test release

          new_st Forcing use of setuptools >= 0.7

          distribute
                 use distribute over setuptools if possible

          offline
                 does buildout run offline

          python python to use

          debug  run buildout with -D debug flag

          onlyif Only execute cmd if statement on the host return 0

          unless Do not execute cmd if statement on the host return 0

          newest run buildout in newest mode

          verbose
                 run buildout in verbose mode (-vvvvv)

          use_vt Use the new salt VT to stream output [experimental]

          CLI Example:

             salt '*' buildout.buildout /srv/mybuildout

   salt.modules.zcbuildout.run_buildout(*a, **kw)
          Run a buildout in a directory.

          directory
                 directory to execute in

          config alternative buildout configuration file to use

          offline
                 are we executing buildout in offline mode

          runas  user used to run buildout as

          env    environment variables to set when running

          onlyif Only execute cmd if statement on the host return 0

          unless Do not execute cmd if statement on the host return 0

          newest run buildout in newest mode

          force  run buildout unconditionally

          verbose
                 run buildout in verbose mode (-vvvvv)

          use_vt Use the new salt VT to stream output [experimental]

          CLI Example:

             salt '*' buildout.run_buildout /srv/mybuildout

   salt.modules.zcbuildout.upgrade_bootstrap(*a, **kw)
          Upgrade current bootstrap.py with the last released one.

          Indeed, when we first run a buildout, a common source of problem
          is to have a locally stale bootstrap, we just try to grab a  new
          copy

          directory
                 directory to execute in

          offline
                 are we executing buildout in offline mode

          buildout_ver
                 forcing to use a specific buildout version (1 | 2)

          onlyif Only execute cmd if statement on the host return 0

          unless Do not execute cmd if statement on the host return 0

          CLI Example:

             salt '*' buildout.upgrade_bootstrap /srv/mybuildout

   salt.modules.zenoss
   Module for working with the Zenoss API

   New in version 2016.3.0.

   depends
          requests

   configuration
          This  module  requires  a  'zenoss'  entry  in the master/minion
          config.

          For example:

             zenoss:
               hostname: https://zenoss.example.com
               username: admin
               password: admin123

   salt.modules.zenoss.add_device(device=None,          device_class=None,
   collector='localhost', prod_state=1000)
          A  function  to  connect to a zenoss server and add a new device
          entry.

          Parameters

                 * device -- (Optional)  Will  use  the  grain  'fqdn'  by
                   default.

                 * device_class  -- (Optional) The device class to use. If
                   none, will determine based on kernel grain.

                 * collector -- (Optional) The collector to use  for  this
                   device. Defaults to 'localhost'.

                 * prod_state  --  (Optional)  The prodState to set on the
                   device. If none, defaults to 1000 ( production )

          CLI Example:
                 salt '*' zenoss.add_device

   salt.modules.zenoss.device_exists(device=None)
          Check to see if a device already exists in Zenoss.

          Parameters
                 device -- (Optional) Will use the grain 'fqdn' by default

          CLI Example:
                 salt '*' zenoss.device_exists

   salt.modules.zenoss.find_device(device=None)
          Find a device in Zenoss. If device not found, returns None.

          Parameters
                 device -- (Optional) Will use the grain 'fqdn' by default

          CLI Example:
                 salt '*' zenoss.find_device

   salt.modules.zenoss.set_prod_state(prod_state, device=None)
          A function to set the prod_state in zenoss.

          Parameters

                 * prod_state -- (Required) Integer value of the state

                 * device -- (Optional)  Will  use  the  grain  'fqdn'  by
                   default.

          CLI Example:
                 salt zenoss.set_prod_state 1000 hostname

   salt.modules.zfs
   Salt interface to ZFS commands

   codeauthor
          Nitin Madhok <[email protected]>

   salt.modules.zfs.bookmark(snapshot, bookmark)
          New in version 2016.3.0.

          Creates a bookmark of the given snapshot

          NOTE:
             Bookmarks  mark  the  point  in  time  when  the snapshot was
             created, and can be used as the incremental source for a  zfs
             send command.

             This    feature   must   be   enabled   to   be   used.   See
             zpool-features(5) for details on ZFS feature  flags  and  the
             bookmarks feature.

          snapshot
                 string name of snapshot to bookmark

          bookmark
                 string name of bookmark

          CLI Example:

             salt '*' zfs.bookmark myzpool/mydataset@yesterday myzpool/mydataset#complete

   salt.modules.zfs.clone(name_a, name_b, **kwargs)
          New in version 2016.3.0.

          Creates a clone of the given snapshot.

          name_a string name of snapshot

          name_b string name of filesystem or volume

          create_parent
                 boolean creates all the non-existing parent datasets. any
                 property specified on  the  command  line  using  the  -o
                 option is ignored.

          properties
                 dict additional zfs properties (-o)

          NOTE:
             ZFS  properties  can  be specified at the time of creation of
             the filesystem  by  passing  an  additional  argument  called
             "properties"   and   specifying  the  properties  with  their
             respective values in the form of a python dictionary:

                 properties="{'property1': 'value1', 'property2': 'value2'}"

          CLI Example:

             salt '*' zfs.clone myzpool/mydataset@yesterday myzpool/mydataset_yesterday

   salt.modules.zfs.create(name, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Create a ZFS File System.

          name   string name of dataset or volume

          volume_size
                 string if specified, a zvol will be created instead of  a
                 dataset

          sparse boolean create sparse volume

          create_parent
                 boolean creates all the non-existing parent datasets. any
                 property specified on  the  command  line  using  the  -o
                 option is ignored.

          properties
                 dict additional zfs properties (-o)

          NOTE:
             ZFS  properties  can  be specified at the time of creation of
             the filesystem  by  passing  an  additional  argument  called
             "properties"   and   specifying  the  properties  with  their
             respective values in the form of a python dictionary:

                 properties="{'property1': 'value1', 'property2': 'value2'}"

          CLI Example:

             salt '*' zfs.create myzpool/mydataset [create_parent=True|False]
             salt '*' zfs.create myzpool/mydataset properties="{'mountpoint': '/export/zfs', 'sharenfs': 'on'}"
             salt '*' zfs.create myzpool/volume volume_size=1G [sparse=True|False]`
             salt '*' zfs.create myzpool/volume volume_size=1G properties="{'volblocksize': '512'}" [sparse=True|False]

   salt.modules.zfs.destroy(name, **kwargs)
          New in version 2015.5.0.

          Destroy a ZFS File System.

          name   string name of dataset, volume, or snapshot

          force  boolean force an unmount of any file  systems  using  the
                 unmount -f command.

          recursive
                 boolean recursively destroy all children. (-r)

          recursive_all
                 boolean  recursively  destroy  all  dependents, including
                 cloned file systems outside the target hierarchy. (-R)

          WARNING:
             watch out when using recursive and recursive_all

          CLI Example:

             salt '*' zfs.destroy myzpool/mydataset [force=True|False]

   salt.modules.zfs.diff(name_a, name_b, **kwargs)
          New in version 2016.3.0.

          Display the difference between a snapshot of a given  filesystem
          and another snapshot of that filesystem from a later time or the
          current contents of the filesystem.

          name_a string name of snapshot

          name_b string name of snapshot or filesystem

          show_changetime
                 boolean display the path's inode change time as the first
                 column of output. (default = False)

          show_indication
                 boolean  display  an  indication  of  the  type  of file.
                 (default = True)

          CLI Example:

             salt '*' zfs.diff myzpool/mydataset@yesterday myzpool/mydataset

   salt.modules.zfs.exists(name, **kwargs)
          New in version 2015.5.0.

          Check if a ZFS filesystem or volume or snapshot exists.

          name   string name of dataset

          type   string also check if dataset is of a certain type,  valid
                 choices  are:  filesystem, snapshot, volume, bookmark, or
                 all.

          CLI Example:

             salt '*' zfs.exists myzpool/mydataset
             salt '*' zfs.exists myzpool/myvolume type=volume

   salt.modules.zfs.get(*dataset, **kwargs)
          New in version 2016.3.0.

          Displays properties for the given datasets.

          *
                 dataset string name  of  snapshot(s),  filesystem(s),  or
                 volume(s)

          properties
                 string   comma-separated  list  of  properties  to  list,
                 defaults to all

          recursive
                 boolean recursively list children

          depth  int recursively list children to depth

          fields string comma-separated list of  fields  to  include,  the
                 name and property field will always be added

          type   string  comma-separated  list  of types to display, where
                 type is one of filesystem, snapshot, volume, bookmark, or
                 all.

          source string  comma-separated  list of sources to display. Must
                 be one  of  the  following:  local,  default,  inherited,
                 temporary, and none. The default value is all sources.

          NOTE:
             If  no  datasets  are  specified,  then  the command displays
             properties for all datasets on the system.

          CLI Example:

             salt '*' zfs.get
             salt '*' zfs.get myzpool/mydataset [recursive=True|False]
             salt '*' zfs.get myzpool/mydataset properties="sharenfs,mountpoint" [recursive=True|False]
             salt '*' zfs.get myzpool/mydataset myzpool/myotherdataset properties=available fields=value depth=1

   salt.modules.zfs.hold(tag, *snapshot, **kwargs)
          New in version 2016.3.0.

          Adds a single reference, named with the  tag  argument,  to  the
          specified snapshot or snapshots.

          NOTE:
             Each  snapshot  has  its  own tag namespace, and tags must be
             unique within that space.

             If a hold exists on a  snapshot,  attempts  to  destroy  that
             snapshot by using the zfs destroy command return EBUSY.

          tag    string name of tag

          *
                 snapshot string name of snapshot(s)

          recursive
                 boolean  specifies  that  a  hold  with  the given tag is
                 applied recursively to the snapshots  of  all  descendent
                 file systems.

          NOTE:
             A  comma-separated list can be provided for the tag parameter
             to hold multiple tags.

          CLI Example:

             salt '*' zfs.hold mytag myzpool/mydataset@mysnapshot [recursive=True]
             salt '*' zfs.hold mytag,myothertag myzpool/mydataset@mysnapshot
             salt '*' zfs.hold mytag myzpool/mydataset@mysnapshot myzpool/mydataset@myothersnapshot

   salt.modules.zfs.holds(snapshot, **kwargs)
          New in version 2016.3.0.

          Lists all existing user references for  the  given  snapshot  or
          snapshots.

          snapshot
                 string name of snapshot

          recursive
                 boolean  lists  the  holds  that  are  set  on  the named
                 descendent snapshots also.

          CLI Example:

             salt '*' zfs.holds myzpool/mydataset@baseline

   salt.modules.zfs.inherit(prop, name, **kwargs)
          New in version 2016.3.0.

          Clears the specified property

          prop   string name of property

          name   string name of the filesystem, volume, or snapshot

          recursive
                 boolean recursively inherit the given  property  for  all
                 children.

          revert boolean  revert the property to the received value if one
                 exists; otherwise operate as if the  -S  option  was  not
                 specified.

          CLI Example:

             salt '*' zfs.inherit canmount myzpool/mydataset [recursive=True|False]

   salt.modules.zfs.list(name=None, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Return  a  list  of  all  datasets or a specified dataset on the
          system and the values of their used, available, referenced,  and
          mountpoint properties.

          name   string name of dataset, volume, or snapshot

          recursive
                 boolean recursively list children

          depth  int limit recursion to depth

          properties
                 string  comma-separated  list  of properties to list, the
                 name property will always be added

          type   string comma-separated list of types  to  display,  where
                 type is one of filesystem, snapshot, volume, bookmark, or
                 all.

          sort   string property to sort on (default = name)

          order  string  [ascending|descending]  sort  order  (default   =
                 ascending)

          CLI Example:

             salt '*' zfs.list
             salt '*' zfs.list myzpool/mydataset [recursive=True|False]
             salt '*' zfs.list myzpool/mydataset properties="sharenfs,mountpoint"

   salt.modules.zfs.mount(name='-a', **kwargs)
          New in version 2016.3.0.

          Mounts ZFS file systems

          name   string  name of the filesystem, you can use '-a' to mount
                 all unmounted filesystems. (this is the default)

          overlay
                 boolean perform an overlay mount.

          options
                 string optional comma-separated list of mount options  to
                 use temporarily for the duration of the mount.

          CLI Example:

             salt '*' zfs.mount
             salt '*' zfs.mount myzpool/mydataset
             salt '*' zfs.mount myzpool/mydataset options=ro

   salt.modules.zfs.promote(name)
          New in version 2016.3.0.

          Promotes  a  clone  file system to no longer be dependent on its
          "origin" snapshot.

          NOTE:
             This makes it possible to destroy the file  system  that  the
             clone  was  created  from.  The clone parent-child dependency
             relationship is reversed, so  that  the  origin  file  system
             becomes a clone of the specified file system.

             The  snapshot  that was cloned, and any snapshots previous to
             this snapshot, are now owned by the promoted clone. The space
             they  use  moves  from the origin file system to the promoted
             clone, so enough space must be available to accommodate these
             snapshots.  No  new  space is consumed by this operation, but
             the space accounting is adjusted. The promoted clone must not
             have  any  conflicting  snapshot names of its own. The rename
             subcommand can be used to rename any conflicting snapshots.

          name   string name of clone-filesystem

          CLI Example:

             salt '*' zfs.promote myzpool/myclone

   salt.modules.zfs.release(tag, *snapshot, **kwargs)
          New in version 2016.3.0.

          Removes a single reference, named with the  tag  argument,  from
          the specified snapshot or snapshots.

          NOTE:
             The  tag  must  already  exist  for each snapshot.  If a hold
             exists on a snapshot, attempts to destroy  that  snapshot  by
             using the zfs destroy command return EBUSY.

          tag    string name of tag

          *
                 snapshot string name of snapshot(s)

          recursive
                 boolean recursively releases a hold with the given tag on
                 the snapshots of all descendent file systems.

          NOTE:
             A comma-separated list can be provided for the tag  parameter
             to release multiple tags.

          CLI Example:

             salt '*' zfs.release mytag myzpool/mydataset@mysnapshot [recursive=True]
             salt '*' zfs.release mytag myzpool/mydataset@mysnapshot myzpool/mydataset@myothersnapshot

   salt.modules.zfs.rename(name, new_name, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Rename or Relocate a ZFS File System.

          name   string name of dataset, volume, or snapshot

          new_name
                 string new name of dataset, volume, or snapshot

          force  boolean  force  unmount  any  filesystems that need to be
                 unmounted in the process.

          create_parent
                 boolean creates  all  the  nonexistent  parent  datasets.
                 Datasets created in this manner are automatically mounted
                 according to the mountpoint property inherited from their
                 parent.

          recursive
                 boolean   recursively   rename   the   snapshots  of  all
                 descendent datasets.  snapshots are the only dataset that
                 can be renamed recursively.

          CLI Example:

             salt '*' zfs.rename myzpool/mydataset myzpool/renameddataset

   salt.modules.zfs.rollback(name, **kwargs)
          New in version 2016.3.0.

          Roll back the given dataset to a previous snapshot.

          WARNING:
             When  a  dataset  is  rolled  back, all data that has changed
             since the snapshot is discarded, and the dataset  reverts  to
             the  state  at  the  time  of  the  snapshot. By default, the
             command refuses to roll back to a  snapshot  other  than  the
             most recent one.

             In  order  to do so, all intermediate snapshots and bookmarks
             must be destroyed by specifying the -r option.

          name   string name of snapshot

          recursive
                 boolean destroy any snapshots and bookmarks  more  recent
                 than the one specified.

          recursive_all
                 boolean  destroy any more recent snapshots and bookmarks,
                 as well as any clones of those snapshots.

          force  boolean used with the -R option to force  an  unmount  of
                 any clone file systems that are to be destroyed.

          CLI Example:

             salt '*' zfs.rollback myzpool/mydataset@yesterday

   salt.modules.zfs.set(*dataset, **kwargs)
          New in version 2016.3.0.

          Sets  the  property  or list of properties to the given value(s)
          for each dataset.

          *
                 dataset string name  of  snapshot(s),  filesystem(s),  or
                 volume(s)

          *
                 properties string additional zfs properties pairs

          NOTE:
             properties are passed as key-value pairs. e.g.
                 compression=off

          NOTE:
             Only some properties can be edited.

             See  the  Properties  section  for  more  information on what
             properties can be set and acceptable values.

             Numeric values can be specified as  exact  values,  or  in  a
             human-readable  form  with a suffix of B, K, M, G, T, P, E, Z
             (for  bytes,  kilobytes,  megabytes,  gigabytes,   terabytes,
             petabytes, exabytes, or zettabytes, respectively).

          CLI Example:

             salt '*' zfs.set myzpool/mydataset compression=off
             salt '*' zfs.set myzpool/mydataset myzpool/myotherdataset compression=off
             salt '*' zfs.set myzpool/mydataset myzpool/myotherdataset compression=lz4 canmount=off

   salt.modules.zfs.snapshot(*snapshot, **kwargs)
          New in version 2016.3.0.

          Creates snapshots with the given names.

          *
                 snapshot string name of snapshot(s)

          recursive
                 boolean  recursively  create  snapshots of all descendent
                 datasets.

          properties
                 dict additional zfs properties (-o)

          NOTE:
             ZFS properties can be specified at the time  of  creation  of
             the  filesystem  by  passing  an  additional  argument called
             "properties"  and  specifying  the  properties   with   their
             respective values in the form of a python dictionary:

                 properties="{'property1': 'value1', 'property2': 'value2'}"

          CLI Example:

             salt '*' zfs.snapshot myzpool/mydataset@yesterday [recursive=True]
             salt '*' zfs.snapshot myzpool/mydataset@yesterday myzpool/myotherdataset@yesterday [recursive=True]

   salt.modules.zfs.unmount(name, **kwargs)
          New in version 2016.3.0.

          Unmounts ZFS file systems

          name   string  name  of  the  filesystem,  you  can  use '-a' to
                 unmount all mounted filesystems.

          force  boolean forcefully unmount the file system, even if it is
                 currently in use.

          WARNING:
             Using  -a  for  the  name  parameter will probably break your
             system, unless your rootfs is not on zfs.

          CLI Example:

             salt '*' zfs.unmount myzpool/mydataset [force=True|False]

   salt.modules.zk_concurrency
   Concurrency controls in zookeeper
   This module allows you to acquire and release a slot. This is primarily
   useful  for  ensureing that no more than N hosts take a specific action
   at once. This can also be used to coordinate between masters.

   salt.modules.zk_concurrency.lock(path,    zk_hosts,    identifier=None,
   max_concurrency=1, timeout=None, ephemeral_lease=False, force=False)
          Get lock (with optional timeout)

          path   The path in zookeeper where the lock is

          zk_hosts
                 zookeeper connect string

          identifier
                 Name  to identify this minion, if unspecified defaults to
                 the hostname

          max_concurrency
                 Maximum number of lock holders

          timeout
                 timeout to wait for the lock. A None timeout  will  block
                 forever

          ephemeral_lease
                 Whether the locks in zookeper should be ephemeral

          force  Forcibly acquire the lock regardless of available slots

          Example:

          ... code-block: bash
             salt        minion       zk_concurrency.lock       /lock/path
             host1:1234,host2:1234

   salt.modules.zk_concurrency.lock_holders(path,                zk_hosts,
   identifier=None,            max_concurrency=1,            timeout=None,
   ephemeral_lease=False)
          Return an un-ordered list of lock holders

          path   The path in zookeeper where the lock is

          zk_hosts
                 zookeeper connect string

          identifier
                 Name to identify this minion, if unspecified defaults  to
                 hostname

          max_concurrency
                 Maximum number of lock holders

          timeout
                 timeout  to  wait for the lock. A None timeout will block
                 forever

          ephemeral_lease
                 Whether the locks in zookeper should be ephemeral

          Example:

          ... code-block: bash
             salt    minion     zk_concurrency.lock_holders     /lock/path
             host1:1234,host2:1234

   salt.modules.zk_concurrency.party_members(path,  zk_hosts, min_nodes=1,
   blocking=False)
          Get the List of identifiers in a  particular  party,  optionally
          waiting for the specified minimum number of nodes (min_nodes) to
          appear

          path   The path in zookeeper where the lock is

          zk_hosts
                 zookeeper connect string

          min_nodes
                 The minimum number of nodes expected to be present in the
                 party

          blocking
                 The   boolean  indicating  if  we  need  to  block  until
                 min_nodes are available

          Example:

          ... code-block: bash
             salt    minion    zk_concurrency.party_members     /lock/path
             host1:1234,host2:1234               salt               minion
             zk_concurrency.party_members /lock/path host1:1234,host2:1234
             min_nodes=3 blocking=True

   salt.modules.zk_concurrency.unlock(path,                 zk_hosts=None,
   identifier=None, max_concurrency=1, ephemeral_lease=False)
          Remove lease from semaphore

          path   The path in zookeeper where the lock is

          zk_hosts
                 zookeeper connect string

          identifier
                 Name to identify this minion, if unspecified defaults  to
                 hostname

          max_concurrency
                 Maximum number of lock holders

          timeout
                 timeout  to  wait for the lock. A None timeout will block
                 forever

          ephemeral_lease
                 Whether the locks in zookeper should be ephemeral

          Example:

          ... code-block: bash
             salt      minion       zk_concurrency.unlock       /lock/path
             host1:1234,host2:1234

   salt.modules.znc
   znc - An advanced IRC bouncer

   New in version 2014.7.0.

   Provides an interface to basic ZNC functionality

   salt.modules.znc.buildmod(*modules)
          Build module using znc-buildmod

          CLI Example:

             salt '*' znc.buildmod module.cpp [...]

   salt.modules.znc.dumpconf()
          Write the active configuration state to config file

          CLI Example:

             salt '*' znc.dumpconf

   salt.modules.znc.rehashconf()
          Rehash the active configuration state from config file

          CLI Example:

             salt '*' znc.rehashconf

   salt.modules.znc.version()
          Return server version from znc --version

          CLI Example:

             salt '*' znc.version

   salt.modules.zpool
   Module for running ZFS zpool command

   codeauthor
          Nitin Madhok <[email protected]>

   salt.modules.zpool.add(zpool, *vdevs, **kwargs)
          Changed in version 2016.3.0.

          Add the specified vdev's to the given storage pool

          zpool  string name of storage pool

          *
                 vdevs string one or more devices

          force  boolean forces use of device

          CLI Example:

             salt '*' zpool.add myzpool /path/to/vdev1 /path/to/vdev2 [...]

   salt.modules.zpool.attach(zpool, device, new_device, force=False)
          Changed in version 2016.3.0.

          Attach specified device to zpool

          zpool  string name of storage pool

          device string device to attach too

          new_device
                 string device to attach

          force  boolean forces use of device

          CLI Example:

             salt '*' zpool.attach myzpool /path/to/vdev1 /path/to/vdev2 [...]

   salt.modules.zpool.create(zpool, *vdevs, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Create  a  simple zpool, a mirrored zpool, a zpool having nested
          VDEVs, a hybrid zpool with cache, spare  and  log  drives  or  a
          zpool with RAIDZ-1, RAIDZ-2 or RAIDZ-3

          zpool  string name of storage pool

          *
                 vdevs string one or move devices

          force  boolean  forces  use of vdevs, even if they appear in use
                 or specify a conflicting replication level.

          mountpoint
                 string sets the mount point for the root dataset

          altroot
                 string equivalent to "-o cachefile=none,altroot=root"

          properties
                 dict additional pool properties

          filesystem_properties
                 dict additional filesystem properties

          CLI Example:

             salt '*' zpool.create myzpool /path/to/vdev1 [...] [force=True|False]
             salt '*' zpool.create myzpool mirror /path/to/vdev1 /path/to/vdev2 [...] [force=True|False]
             salt '*' zpool.create myzpool raidz1 /path/to/vdev1 /path/to/vdev2 raidz2 /path/to/vdev3 /path/to/vdev4 /path/to/vdev5 [...] [force=True|False]
             salt '*' zpool.create myzpool mirror /path/to/vdev1 [...] mirror /path/to/vdev2 /path/to/vdev3 [...] [force=True|False]
             salt '*' zpool.create myhybridzpool mirror /tmp/file1 [...] log mirror /path/to/vdev1 [...] cache /path/to/vdev2 [...] spare /path/to/vdev3 [...] [force=True|False]

          NOTE:
             Zpool properties can be specified at the time of creation  of
             the   pool   by   passing   an   additional  argument  called
             "properties"  and  specifying  the  properties   with   their
             respective values in the form of a python dictionary:

                 properties="{'property1': 'value1', 'property2': 'value2'}"

             Filesystem  properties  can  be  specified  at  the  time  of
             creation of the pool by passing an additional argument called
             "filesystem_properties"  and  specifying  the properties with
             their respective values in the form of a python dictionary:

                 filesystem_properties="{'property1': 'value1', 'property2': 'value2'}"

             Example:

                 salt '*' zpool.create myzpool /path/to/vdev1 [...] properties="{'property1': 'value1', 'property2': 'value2'}"

   salt.modules.zpool.create_file_vdev(size, *vdevs)
          Changed in version 2016.3.0.

          Creates file based virtual devices for a zpool

          *vdevs is a list of full paths for mkfile to create

          CLI Example:

             salt '*' zpool.create_file_vdev 7g /path/to/vdev1 [/path/to/vdev2] [...]

          NOTE:
             Depending on file size, the above command may take a while to
             return.

   salt.modules.zpool.destroy(zpool, force=False)
          Changed in version 2016.3.0.

          Destroys a storage pool

          zpool  string name of storage pool

          force  boolean force destroy of pool

          CLI Example:

             salt '*' zpool.destroy myzpool

   salt.modules.zpool.detach(zpool, device)
          Changed in version 2016.3.0.

          Detach specified device to zpool

          zpool  string name of storage pool

          device string device to detach

          CLI Example:

             salt '*' zpool.detach myzpool /path/to/vdev1

   salt.modules.zpool.exists(zpool)
          Check if a ZFS storage pool is active

          zpool  string name of storage pool

          CLI Example:

             salt '*' zpool.exists myzpool

   salt.modules.zpool.export(*pools, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Export storage pools

          *
                 pools string one or more storage pools to export

          force  boolean force export of storage pools

          CLI Example:

             salt '*' zpool.export myzpool ... [force=True|False]
             salt '*' zpool.export myzpool2 myzpool2 ... [force=True|False]

   salt.modules.zpool.get(zpool, prop=None, show_source=False)
          New in version 2016.3.0.

          Retrieves the given list of properties

          zpool  string name of storage pool

          prop   string optional name of property to retrieve

          show_source
                 boolean show source of property

          CLI Example:

             salt '*' zpool.get myzpool

   salt.modules.zpool.healthy()
          New in version 2016.3.0.

          Check if all zpools are healthy

          CLI Example:

             salt '*' zpool.healthy

   salt.modules.zpool.history(zpool=None, internal=False, verbose=False)
          New in version 2016.3.0.

          Displays the command history of the specified pools or all pools
          if no pool is specified

          zpool  string optional storage pool

          internal
                 boolean toggle display of internally logged ZFS events

          verbose
                 boolean toggle display of the user  name,  the  hostname,
                 and the zone in which the operation was performed

          CLI Example:

             salt '*' zpool.upgrade myzpool

   salt.modules.zpool.import(zpool=None, new_name=None, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Import storage pools or list pools available for import

          zpool  string optional name of storage pool

          new_name
                 string optional new name for the storage pool

          mntopts
                 string  comma-separated list of mount options to use when
                 mounting datasets within the pool.

          force  boolean forces import, even if the  pool  appears  to  be
                 potentially active.

          altroot
                 string equivalent to "-o cachefile=none,altroot=root"

          dir    string  searches  for  devices  or files in dir, multiple
                 dirs can be specified as follows:: dir="dir1,dir2"

          no_mount
                 boolean  import  the  pool  without  mounting  any   file
                 systems.

          only_destroyed
                 boolean  imports  destroyed  pools  only.  this also sets
                 force=True.

          properties
                 dict additional pool properties

          NOTE:
             Zpool properties can be specified at the time of creation  of
             the   pool   by   passing   an   additional  argument  called
             "properties"  and  specifying  the  properties   with   their
             respective values in the form of a python dictionary:

                 properties="{'property1': 'value1', 'property2': 'value2'}"

          CLI Example:

             salt '*' zpool.import [force=True|False]
             salt '*' zpool.import myzpool [mynewzpool] [force=True|False]
             salt '*' zpool.import myzpool dir='/tmp'

   salt.modules.zpool.iostat(zpool=None, sample_time=0)
          Changed in version 2016.3.0.

          Display I/O statistics for the given pools

          zpool  string optional name of storage pool

          sample_time
                 int seconds to capture data before output

          CLI Example:

             salt '*' zpool.iostat myzpool

   salt.modules.zpool.list(properties='size,   alloc,   free,  cap,  frag,
   health', zpool=None)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Return information about (all) storage pools

          zpool  string optional name of storage pool

          properties
                 string comma-separated list of properties to list

          NOTE:
             the 'name' property  will  always  be  included,  the  'frag'
             property will get removed if not available

          zpool  string optional zpool

          NOTE:
             multiple  storage  pool  can  be provded as a space separated
             list

          CLI Example:

             salt '*' zpool.list

   salt.modules.zpool.offline(zpool, *vdevs, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Ensure that the specified devices are offline

          WARNING:
             By default, the  OFFLINE  state  is  persistent.  The  device
             remains  offline  when the system is rebooted. To temporarily
             take a device offline, use temporary=True.

          zpool  string name of storage pool

          *
                 vdevs string one or more devices

          temporary
                 boolean enable temporarily offline

          CLI Example:

             salt '*' zpool.offline myzpool /path/to/vdev1 [...] [temporary=True|False]

   salt.modules.zpool.online(zpool, *vdevs, **kwargs)
          New in version 2015.5.0.

          Changed in version 2016.3.0.

          Ensure that the specified devices are online

          zpool  string name of storage pool

          *
                 vdevs string one or more devices

          expand boolean Expand the device to use all available space.

                 NOTE:
                    If the device is part of a mirror or  raidz  then  all
                    devices  must  be  expanded  before the new space will
                    become available to the pool.

          CLI Example:

             salt '*' zpool.online myzpool /path/to/vdev1 [...]

   salt.modules.zpool.reguid(zpool)
          New in version 2016.3.0.

          Generates a new unique identifier for the pool

          WARNING:
             You must ensure that all devices in this pool are online  and
             healthy before performing this action.

          zpool  string name of storage pool

          CLI Example:

             salt '*' zpool.reguid myzpool

   salt.modules.zpool.reopen(zpool)
          New in version 2016.3.0.

          Reopen all the vdevs associated with the pool

          zpool  string name of storage pool

          CLI Example:

             salt '*' zpool.reopen myzpool

   salt.modules.zpool.replace(zpool,      old_device,     new_device=None,
   force=False)
          Changed in version 2016.3.0.

          Replaces old_device with new_device.

          NOTE:
             This is equivalent to attaching new_device, waiting for it to
             resilver, and then detaching old_device.

             The  size  of new_device must be greater than or equal to the
             minimum size  of  all  the  devices  in  a  mirror  or  raidz
             configuration.

          zpool  string name of storage pool

          old_device
                 string old device to replace

          new_device
                 string optional new device

          force  boolean  Forces use of new_device, even if its appears to
                 be in use.

          CLI Example:

             salt '*' zpool.replace myzpool /path/to/vdev1 /path/to/vdev2

   salt.modules.zpool.scrub(zpool, stop=False)
          Changed in version 2016.3.0.

          Scrub a storage pool

          zpool  string name of storage pool

          stop   boolean if true, cancel ongoing scrub

          CLI Example:

             salt '*' zpool.scrub myzpool

   salt.modules.zpool.set(zpool, prop, value)
          New in version 2016.3.0.

          Sets the given property on the specified pool

          zpool  string name of storage pool

          prop   string name of property

          value  string value to set property to

          CLI Example:

             salt '*' zpool.set myzpool readonly yes

   salt.modules.zpool.status(zpool=None)
          Changed in version 2016.3.0.

          Return the status of the named zpool

          zpool  string optional name of storage pool

          CLI Example:

             salt '*' zpool.status myzpool

   salt.modules.zpool.upgrade(zpool=None, version=None)
          New in version 2016.3.0.

          Enables all supported features on the given pool

          WARNING:
             Once this is done, the pool will no longer be  accessible  on
             systems    that   do   not   support   feature   flags.   See
             zpool-features(5) for details on compatibility  with  systems
             that  support  feature flags, but do not support all features
             enabled on the pool.

          zpool  string optional storage pool, applies to all otherwize

          version
                 int version to upgrade to, if unspecified upgrade to  the
                 highest possible

          CLI Example:

             salt '*' zpool.upgrade myzpool

   salt.modules.zypper
   Package support for openSUSE via the zypper package manager

   depends

          * rpm Python module.  Install with zypper install rpm-python

   IMPORTANT:
      If you feel that Salt should be using this module to manage packages
      on a minion, and it is using a different module (or gives  an  error
      similar to 'pkg.install' is not available), see here.

   salt.modules.zypper.add_lock(packages, **kwargs)
          Add a package lock. Specify packages to lock by exact name.

          CLI Example:

             salt '*' pkg.add_lock <package name>
             salt '*' pkg.add_lock <package1>,<package2>,<package3>
             salt '*' pkg.add_lock pkgs='["foo", "bar"]'

   salt.modules.zypper.clean_locks()
          Remove  unused  locks  that  do  not  currently  (with regard to
          repositories used) lock any package.

          CLI Example:

             salt '*' pkg.clean_locks

   salt.modules.zypper.del_repo(repo)
          Delete a repo.

          CLI Examples:

             salt '*' pkg.del_repo alias

   salt.modules.zypper.diff(*paths)
          Return a formatted diff between current files and original in  a
          package.   NOTE: this function includes all files (configuration
          and not), but does not work on binary content.

          Parameters
                 path -- Full path to the installed file

          Returns
                 Difference string or raises  and  exception  if  examined
                 file is binary.

          CLI example:

             salt '*' pkg.diff /etc/apache2/httpd.conf /etc/sudoers

   salt.modules.zypper.download(*packages, **kwargs)
          Download packages to the local disk.

          refresh
                 force  a  refresh  if  set  to  True.   If  set  to False
                 (default) it depends on zypper if a refresh is executed.

          CLI example:

             salt '*' pkg.download httpd
             salt '*' pkg.download httpd postfix

   salt.modules.zypper.file_dict(*packages)
          List the files that belong to a package, grouped by package. Not
          specifying  any packages will return a list of every file on the
          system's rpm database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.zypper.file_list(*packages)
          List the files that belong to  a  package.  Not  specifying  any
          packages  will  return  a list of every file on the system's rpm
          database (not generally recommended).

          CLI Examples:

             salt '*' pkg.file_list httpd
             salt '*' pkg.file_list httpd postfix
             salt '*' pkg.file_list

   salt.modules.zypper.get_repo(repo, **kwargs)
          Display a repo.

          CLI Example:

             salt '*' pkg.get_repo alias

   salt.modules.zypper.info(*names, **kwargs)
          Deprecated since version Nitrogen: Use info_available() instead.

          Return the information of the named package  available  for  the
          system.

          CLI example:

             salt '*' pkg.info <package1>
             salt '*' pkg.info <package1> <package2> <package3> ...

   salt.modules.zypper.info_available(*names, **kwargs)
          Return  the  information  of the named package available for the
          system.

          refresh
                 force a refresh if set to  True  (default).   If  set  to
                 False  it  depends  on zypper if a refresh is executed or
                 not.

          CLI example:

             salt '*' pkg.info_available <package1>
             salt '*' pkg.info_available <package1> <package2> <package3> ...

   salt.modules.zypper.info_installed(*names, **kwargs)
          Return the information of the named package(s), installed on the
          system.

          Parameters

                 * names  --  Names  of  the  packages  to get information
                   about.

                 * attr --

                   Comma-separated package attributes.  If  no  'attr'  is
                   specified, all available attributes returned.

                   Valid attributes are:
                          version,     vendor,     release,    build_date,
                          build_date_time_t,                 install_date,
                          install_date_time_t,      build_host,     group,
                          source_rpm,   arch,   epoch,   size,    license,
                          signature, packager, url, summary, description.

                 * errors --

                   Handle  RPM  field  errors  (true|false).  By  default,
                   various mistakes  in  the  textual  fields  are  simply
                   ignored  and  omitted  from the data. Otherwise a field
                   with a mistake is not returned,  instead  a  'N/A  (bad
                   UTF-8)' (not available, broken) text is returned.

                   Valid attributes are:
                          ignore, report

          CLI example:

             salt '*' pkg.info_installed <package1>
             salt '*' pkg.info_installed <package1> <package2> <package3> ...
             salt '*' pkg.info_installed <package1> attr=version,vendor
             salt '*' pkg.info_installed <package1> <package2> <package3> ... attr=version,vendor
             salt '*' pkg.info_installed <package1> <package2> <package3> ... attr=version,vendor errors=true

   salt.modules.zypper.install(name=None,   refresh=False,  fromrepo=None,
   pkgs=None,    sources=None,    downloadonly=None,    skip_verify=False,
   version=None, ignore_repo_failure=False, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any zypper commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Install  the  passed  package(s),  add  refresh=True  to force a
          'zypper refresh' before package is installed.

          name   The name of the package to be installed. Note  that  this
                 parameter is ignored if either pkgs or sources is passed.
                 Additionally, please note that this option  can  only  be
                 used  to  install packages from a software repository. To
                 install a package file manually, use the sources option.

                 CLI Example:

                    salt '*' pkg.install <package name>

          refresh
                 force a  refresh  if  set  to  True.   If  set  to  False
                 (default) it depends on zypper if a refresh is executed.

          fromrepo
                 Specify a package repository to install from.

          downloadonly
                 Only download the packages, do not install.

          skip_verify
                 Skip the GPG verification check (e.g., --no-gpg-checks)

          version
                 Can  be  either a version number, or the combination of a
                 comparison operator (<, >,  <=,  >=,  =)  and  a  version
                 number  (ex.  '>1.2.3-4').   This parameter is ignored if
                 pkgs or sources is passed.

          Multiple Package Installation Options:

          pkgs   A list of packages to install from a software repository.
                 Must  be  passed  as  a  python  list. A specific version
                 number can be specified by using  a  single-element  dict
                 representing  the  package  and  its version. As with the
                 version parameter above, comparison operators can be used
                 to target a specific version of a package.

                 CLI Examples:

                    salt '*' pkg.install pkgs='["foo", "bar"]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "1.2.3-4"}]'
                    salt '*' pkg.install pkgs='["foo", {"bar": "<1.2.3-4"}]'

          sources
                 A  list  of  RPM packages to install. Must be passed as a
                 list of dicts, with the keys being package names, and the
                 values being the source URI or local path to the package.

                 CLI Example:

                    salt '*' pkg.install sources='[{"foo": "salt://foo.rpm"},{"bar": "salt://bar.rpm"}]'

          ignore_repo_failure
                 Zypper  returns error code 106 if one of the repositories
                 are not available for various reasons.  In  case  to  set
                 strict  check,  this  parameter  needs to be set to True.
                 Default: False.

          Returns a dict containing the new package names and versions:

             {'<package>': {'old': '<old-version>',
                            'new': '<new-version>'}}

   salt.modules.zypper.latest_version(*names, **kwargs)
          Return the latest version of the  named  package  available  for
          upgrade  or  installation.  If  more  than  one  package name is
          specified, a dict of name/version pairs is returned.

          If the latest version of a given package is  already  installed,
          an empty dict will be returned for that package.

          refresh
                 force  a  refresh  if  set  to True (default).  If set to
                 False it depends on zypper if a refresh  is  executed  or
                 not.

          CLI example:

             salt '*' pkg.latest_version <package name>
             salt '*' pkg.latest_version <package1> <package2> <package3> ...

   salt.modules.zypper.list_installed_patterns()
          List installed patterns on the system.

          CLI Examples:

             salt '*' pkg.list_installed_patterns

   salt.modules.zypper.list_locks()
          List current package locks.

          Return a dict containing the locked package with attributes:

             {'<package>': {'case_sensitive': '<case_sensitive>',
                            'match_type': '<match_type>'
                            'type': '<type>'}}

          CLI Example:

             salt '*' pkg.list_locks

   salt.modules.zypper.list_patterns(refresh=False)
          List all known patterns from available repos.

          refresh
                 force  a  refresh  if  set  to  True.   If  set  to False
                 (default) it depends on zypper if a refresh is executed.

          CLI Examples:

             salt '*' pkg.list_patterns

   salt.modules.zypper.list_pkgs(versions_as_list=False, **kwargs)
          List the packages currently installed as a dict with versions as
          a comma separated string:

             {'<package_name>': '<version>[,<version>...]'}

          versions_as_list:
                 If set to true, the versions are provided as a list

                 {'<package_name>': ['<version>', '<version>']}

          removed:
                 not supported

          purge_desired:
                 not supported

          CLI Example:

             salt '*' pkg.list_pkgs

   salt.modules.zypper.list_products(all=False, refresh=False)
          List all available or installed SUSE products.

          all    List all products available or only installed. Default is
                 False.

          refresh
                 force a  refresh  if  set  to  True.   If  set  to  False
                 (default) it depends on zypper if a refresh is executed.

          Includes   handling   for  OEM  products,  which  read  the  OEM
          productline file and overwrite the release value.

          CLI Examples:

             salt '*' pkg.list_products
             salt '*' pkg.list_products all=True

   salt.modules.zypper.list_repos()
          Lists all repos.

          CLI Example:

             salt '*' pkg.list_repos

   salt.modules.zypper.list_upgrades(refresh=True, **kwargs)
          List all available package upgrades on this system

          refresh
                 force a refresh if set to  True  (default).   If  set  to
                 False it depends on zypper if a refresh is executed.

          CLI Example:

             salt '*' pkg.list_upgrades

   salt.modules.zypper.mod_repo(repo, **kwargs)
          Modify  one  or  more  values  for  a repo. If the repo does not
          exist, it will be created, so long as the following  values  are
          specified:

          repo or alias
                 alias by which the zypper refers to the repo

          url, mirrorlist or baseurl
                 the URL for zypper to reference

          enabled
                 enable  or disable (True or False) repository, but do not
                 remove if disabled.

          refresh
                 enable or disable (True or  False)  auto-refresh  of  the
                 repository.

          cache  Enable or disable (True or False) RPM files caching.

          gpgcheck
                 Enable  or  disable  (True  or  False) GOG check for this
                 repository.

          gpgautoimport
                 Automatically trust and import new repository.

          Key/Value pairs may also be removed from a repo's  configuration
          by  setting  a  key  to  a blank value. Bear in mind that a name
          cannot be deleted, and a url can only be deleted if a mirrorlist
          is specified (or vice versa).

          CLI Examples:

             salt '*' pkg.mod_repo alias alias=new_alias
             salt '*' pkg.mod_repo alias url= mirrorlist=http://host.com/

   salt.modules.zypper.modified(*packages, **flags)
          List the modified files that belong to a package. Not specifying
          any packages will return a list of _all_ modified files  on  the
          system's RPM database.

          New in version 2015.5.0.

          Filtering by flags (True or False):

          size   Include only files where size changed.

          mode   Include only files which file's mode has been changed.

          checksum
                 Include only files which MD5 checksum has been changed.

          device Include only files which major and minor numbers has been
                 changed.

          symlink
                 Include only files which are symbolic link contents.

          owner  Include only files where owner has been changed.

          group  Include only files where group has been changed.

          time   Include only files where modification time  of  the  file
                 has been changed.

          capabilities
                 Include  only  files  where  capabilities  differ or not.
                 Note: supported only on newer RPM versions.

          CLI Examples:

             salt '*' pkg.modified
             salt '*' pkg.modified httpd
             salt '*' pkg.modified httpd postfix
             salt '*' pkg.modified httpd owner=True group=False

   salt.modules.zypper.owner(*paths)
          Return the name of the package that owns the file. Multiple file
          paths  can  be passed. If a single path is passed, a string will
          be returned, and if multiple paths are passed, a  dictionary  of
          file/package name pairs will be returned.

          If  the file is not owned by a package, or is not present on the
          minion, then an empty string will be returned for that path.

          CLI Examples:

             salt '*' pkg.owner /usr/bin/apachectl
             salt '*' pkg.owner /usr/bin/apachectl /etc/httpd/conf/httpd.conf

   salt.modules.zypper.purge(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any zypper commands spawned by Salt when the salt-minion
          service  is  restarted.  (see  KillMode  in  the systemd.kill(5)
          manpage  for   more   information).   If   desired,   usage   of
          systemd-run(1)  can  be  suppressed  by  setting a config option
          called systemd.scope, with a value of False (no quotes).

          Recursively remove a package and  all  dependencies  which  were
          installed with it, this will call a zypper -n remove -u

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A  list of packages to delete. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.purge <package name>
             salt '*' pkg.purge <package1>,<package2>,<package3>
             salt '*' pkg.purge pkgs='["foo", "bar"]'

   salt.modules.zypper.refresh_db()
          Force  a  repository  refresh by calling zypper refresh --force,
          return a dict:

             {'<database name>': Bool}

          CLI Example:

             salt '*' pkg.refresh_db

   salt.modules.zypper.remove(name=None, pkgs=None, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running  systemd>=205,  systemd-run(1)  is  now  used to isolate
          commands which modify installed packages  from  the  salt-minion
          daemon's  control  group.  This  is  done  to  keep systemd from
          killing any zypper commands spawned by Salt when the salt-minion
          service  is  restarted.  (see  KillMode  in  the systemd.kill(5)
          manpage  for   more   information).   If   desired,   usage   of
          systemd-run(1)  can  be  suppressed  by  setting a config option
          called systemd.scope, with a value of False (no quotes).

          Remove packages with zypper -n remove

          name   The name of the package to be deleted.

          Multiple Package Options:

          pkgs   A list of packages to delete. Must be passed as a  python
                 list.  The  name parameter will be ignored if this option
                 is passed.

          New in version 0.16.0.

          Returns a dict containing the changes.

          CLI Example:

             salt '*' pkg.remove <package name>
             salt '*' pkg.remove <package1>,<package2>,<package3>
             salt '*' pkg.remove pkgs='["foo", "bar"]'

   salt.modules.zypper.remove_lock(packages, **kwargs)
          Remove specified package lock.

          CLI Example:

             salt '*' pkg.remove_lock <package name>
             salt '*' pkg.remove_lock <package1>,<package2>,<package3>
             salt '*' pkg.remove_lock pkgs='["foo", "bar"]'

   salt.modules.zypper.search(criteria, refresh=False)
          List known packags, available to the system.

          refresh
                 force a  refresh  if  set  to  True.   If  set  to  False
                 (default) it depends on zypper if a refresh is executed.

          CLI Examples:

             salt '*' pkg.search <criteria>

   salt.modules.zypper.upgrade(refresh=True,                 dryrun=False,
   dist_upgrade=False,        fromrepo=None,         novendorchange=False,
   skip_verify=False, **kwargs)
          Changed  in  version  2015.8.12,2016.3.3,2016.11.0:  On  minions
          running systemd>=205, systemd-run(1)  is  now  used  to  isolate
          commands  which  modify  installed packages from the salt-minion
          daemon's control group.  This  is  done  to  keep  systemd  from
          killing any zypper commands spawned by Salt when the salt-minion
          service is  restarted.  (see  KillMode  in  the  systemd.kill(5)
          manpage   for   more   information).   If   desired,   usage  of
          systemd-run(1) can be suppressed  by  setting  a  config  option
          called systemd.scope, with a value of False (no quotes).

          Run a full system upgrade, a zypper upgrade

          refresh
                 force  a  refresh  if  set  to True (default).  If set to
                 False it depends on zypper if a refresh is executed.

          dryrun If set to True, it creates a debug solver  log  file  and
                 then  perform  a  dry-run  upgrade (no changes are made).
                 Default: False

          dist_upgrade
                 Perform a system dist-upgrade. Default: False

          fromrepo
                 Specify a list of package repositories to  upgrade  from.
                 Default: None

          novendorchange
                 If set to True, no allow vendor changes. Default: False

          skip_verify
                 Skip the GPG verification check (e.g., --no-gpg-checks)

          Returns a dictionary containing the changes:

             {'<package>':  {'old': '<old-version>',
                             'new': '<new-version>'}}

          CLI Example:

             salt '*' pkg.upgrade
             salt '*' pkg.upgrade dist-upgrade=True fromrepo='["MyRepoName"]' novendorchange=True
             salt '*' pkg.upgrade dist-upgrade=True dryrun=True

   salt.modules.zypper.upgrade_available(name, **kwargs)
          Check whether or not an upgrade is available for a given package

          refresh
                 force  a  refresh  if  set  to True (default).  If set to
                 False it depends on zypper if a refresh  is  executed  or
                 not.

          CLI Example:

             salt '*' pkg.upgrade_available <package name>

   salt.modules.zypper.verify(*names, **kwargs)
          Runs an rpm -Va on a system, and returns the results in a dict

          Files with an attribute of config, doc, ghost, license or readme
          in the package header can  be  ignored  using  the  ignore_types
          keyword argument

          CLI Example:

             salt '*' pkg.verify
             salt '*' pkg.verify httpd
             salt '*' pkg.verify 'httpd postfix'
             salt '*' pkg.verify 'httpd postfix' ignore_types=['config','doc']

   salt.modules.zypper.version(*names, **kwargs)
          Returns  a  string  representing the package version or an empty
          dict if  not  installed.  If  more  than  one  package  name  is
          specified, a dict of name/version pairs is returned.

          CLI Example:

             salt '*' pkg.version <package name>
             salt '*' pkg.version <package1> <package2> <package3> ...

   salt.modules.zypper.version_cmp(ver1, ver2, ignore_epoch=False)
          New in version 2015.5.4.

          Do  a  cmp-style comparison on two packages. Return -1 if ver1 <
          ver2, 0 if ver1 == ver2, and 1 if ver1 > ver2.  Return  None  if
          there was a problem making the comparison.

          ignore_epoch
                 False  Set  to  True  to  ignore the epoch when comparing
                 versions

                 New in version 2015.8.10,2016.3.2.

          CLI Example:

             salt '*' pkg.version_cmp '0.2-001' '0.2.0.1-002'

   netapi modules
   rest_cherrypy
   A REST API for Salt
   New in version 2014.7.0.

   depends

          * CherryPy Python module. Version 3.2.3 is currently recommended
            when  SSL  is enabled, since this version worked the best with
            SSL in internal testing. Versions 3.2.3 - 4.x can be  used  if
            SSL  is not enabled.  Be aware that there is a known SSL error
            introduced in version 3.2.5. The issue was reportedly resolved
            with  CherryPy  milestone 3.3, but the patch was committed for
            version 3.6.1.

   optdepends

          * ws4py Python module for websockets support.

   client_libraries

          * Java: https://github.com/SUSE/salt-netapi-client

          * Python: https://github.com/saltstack/pepper

   setup  All steps below are performed on the machine  running  the  Salt
          Master  daemon. Configuration goes into the Master configuration
          file.

          1. Install salt-api. (This step  varies  between  OS  and  Linux
             distros.   Some  package systems have a split package, others
             include  salt-api  in  the  main  Salt  package.  Ensure  the
             salt-api --version output matches the salt --version output.)

          2. Install  CherryPy.  (Read  the  version caveat in the section
             above.)

          3. Optional: generate self-signed SSL certificates.

             Using a secure HTTPS connection is strongly recommended since
             Salt  eauth  authentication credentials will be sent over the
             wire.

             1. Install the PyOpenSSL package.

             2. Generate   a    self-signed    certificate    using    the
                create_self_signed_cert() execution function.

                   salt-call --local tls.create_self_signed_cert

          4. Edit  the  master config to create at least one external auth
             user or group following the full external auth instructions.

          5. Edit the master config with  the  following  production-ready
             example  to  enable  the  rest_cherrypy  module. (Adjust cert
             paths as needed, or disable SSL (not recommended!).)

                rest_cherrypy:
                  port: 8000
                  ssl_crt: /etc/pki/tls/certs/localhost.crt
                  ssl_key: /etc/pki/tls/certs/localhost.key

          6. Restart the salt-master daemon.

          7. Start the salt-api daemon.

   configuration
          All available configuration options are  detailed  below.  These
          settings  configure  the  CherryPy  HTTP server and do not apply
          when using an external server such as Apache or Nginx.

          port   Required

                 The port for the webserver to listen on.

          host   0.0.0.0 The socket  interface  for  the  HTTP  server  to
                 listen on.

          debug  False  Starts the web server in development mode. It will
                 reload itself when the underlying  code  is  changed  and
                 will output more debugging info.

          log_access_file
                 Path to a file to write HTTP access logs.

          log_error_file
                 Path to a file to write HTTP error logs.

          ssl_crt
                 The path to a SSL certificate. (See below)

          ssl_key
                 The  path  to  the  private key for your SSL certificate.
                 (See below)

          ssl_chain
                 (Optional when using PyOpenSSL) the certificate chain  to
                 pass to Context.load_verify_locations.

          disable_ssl
                 A  flag to disable SSL. Warning: your Salt authentication
                 credentials will be sent in the clear!

          webhook_disable_auth
                 False The Webhook URL requires authentication by  default
                 but external services cannot always be configured to send
                 authentication.   See  the  Webhook   documentation   for
                 suggestions on securing this interface.

          webhook_url
                 /hook  Configure  the  URL endpoint for the Webhook entry
                 point.

          thread_pool
                 100 The number of worker threads to start up in the pool.

          socket_queue_size
                 30 Specify the maximum  number  of  HTTP  connections  to
                 queue.

          expire_responses
                 True  Whether  to  check for and kill HTTP responses that
                 have exceeded the default timeout.

          max_request_body_size
                 1048576 Maximum size for the HTTP request body.

          collect_stats
                 False Collect and report statistics  about  the  CherryPy
                 server

                 Reports are available via the Stats URL.

          static A  filesystem  path  to  static HTML/JavaScript/CSS/image
                 assets.

          static_path
                 /static The URL prefix to use when serving static  assets
                 out of the directory specified in the static setting.

          app    A  filesystem path to an HTML file that will be served as
                 a static  file.   This  is  useful  for  bootstrapping  a
                 single-page JavaScript app.

          app_path
                 /app  The  URL  prefix  to  use for serving the HTML file
                 specified in the app setting. This  should  be  a  simple
                 name containing no slashes.

                 Any path information after the specified path is ignored;
                 this is useful for apps that utilize  the  HTML5  history
                 API.

          root_prefix
                 / A URL path to the main entry point for the application.
                 This is useful for serving multiple applications from the
                 same URL.

   Authentication
   Authentication  is  performed  by  passing  a  session  token with each
   request.  Tokens are generated via the Login URL.

   The token may be sent in one of two ways: as a custom header  or  as  a
   session  cookie.  The  latter  is  far more convenient for clients that
   support cookies.

   * Include a custom header named X-Auth-Token.

     For example, using curl:

        curl -sSk https://localhost:8000/login \
            -H 'Accept: application/x-yaml' \
            -d username=saltdev \
            -d password=saltdev \
            -d eauth=auto

     Copy the token value from the output and  include  it  in  subsequent
     requests:

        curl -sSk https://localhost:8000 \
            -H 'Accept: application/x-yaml' \
            -H 'X-Auth-Token: 697adbdc8fe971d09ae4c2a3add7248859c87079'\
            -d client=local \
            -d tgt='*' \
            -d fun=test.ping

   * Sent via a cookie. This option is a convenience for HTTP clients that
     automatically handle cookie support (such as browsers).

     For example, using curl:

        # Write the cookie file:
        curl -sSk https://localhost:8000/login \
              -c ~/cookies.txt \
              -H 'Accept: application/x-yaml' \
              -d username=saltdev \
              -d password=saltdev \
              -d eauth=auto

        # Read the cookie file:
        curl -sSk https://localhost:8000 \
              -b ~/cookies.txt \
              -H 'Accept: application/x-yaml' \
              -d client=local \
              -d tgt='*' \
              -d fun=test.ping

     Another example using the requests library in Python:

        >>> import requests
        >>> session = requests.Session()
        >>> session.post('http://localhost:8000/login', json={
            'username': 'saltdev',
            'password': 'saltdev',
            'eauth': 'auto',
        })
        <Response [200]>
        >>> resp = session.post('http://localhost:8000', json=[{
            'client': 'local',
            'tgt': '*',
            'fun': 'test.arg',
            'arg': ['foo', 'bar'],
            'kwarg': {'baz': 'Baz!'},
        }])
        >>> resp.json()
        {u'return': [{
            ...snip...
        }]}

   SEE ALSO:
      You can bypass the session handling via the Run URL.

   Usage
   This interface directly exposes Salt's Python API.  Everything possible
   at the CLI is possible through the Python API. Commands are executed on
   the Salt Master.

   The root URL (/) is RPC-like in that it  accepts  instructions  in  the
   request  body  for  what  Salt  functions  to execute, and the response
   contains the result of those function calls.

   For example:

      % curl -sSi https://localhost:8000         -H 'Content-type: application/json'         -d '[{
              "client": "local",
              "tgt": "*",
              "fun": "test.ping"
          }]'
      HTTP/1.1 200 OK
      Content-Type: application/json
      [...snip...]

      {"return": [{"jerry": true}]}

   The request body must be an array of commands.  Use  this  workflow  to
   build a command:

   1. Choose a client interface.

   2. Choose a function.

   3. Fill out the remaining parameters needed for the chosen client.

   The  client  field  is  a  reference to the main Python classes used in
   Salt's Python API. Read the full client interfaces  documentation,  but
   in short:

   * "local"  uses LocalClient which sends commands to Minions. Equivalent
     to the salt CLI command.

   * "runner" uses  RunnerClient  which  invokes  runner  modules  on  the
     Master. Equivalent to the salt-run CLI command.

   * "wheel"  uses  WheelClient which invokes wheel modules on the Master.
     Wheel modules do not have a direct CLI equivalent but they  typically
     manage  Master-side  resources such as state files, pillar files, the
     Salt  config  files,  and  the  key  wheel  module  exposes   similar
     functionality as the salt-key CLI command.

   Most  clients  have variants like synchronous or asynchronous execution
   as well as others like batch execution. See the  full  list  of  client
   interfaces.

   Each  client  requires  different arguments and sometimes has different
   syntax.  For example, LocalClient requires the tgt argument because  it
   forwards the command to Minions and the other client interfaces do not.
   LocalClient also takes arg (array)  and  kwarg  (dictionary)  arguments
   because  these  values  are sent to the Minions and used to execute the
   requested function there. RunnerClient  and  WheelClient  are  executed
   directly on the Master and thus do not need or accept those arguments.

   Read  the  method  signatures in the client documentation linked above,
   but hopefully an example will help illustrate the concept. This example
   causes Salt to execute two functions -- the test.arg execution function
   using LocalClient and the test.arg runner function using  RunnerClient;
   note the different structure for each command. The results for both are
   combined and returned as one response.

      % curl -b ~/cookies.txt -sSi localhost:8000         -H 'Content-type: application/json'         -d '
      [
          {
              "client": "local",
              "tgt": "*",
              "fun": "test.arg",
              "arg": ["positional arg one", "positional arg two"],
              "kwarg": {
                  "keyword arg one": "Hello from a minion",
                  "keyword arg two": "Hello again from a minion"
              }
          },
          {
              "client": "runner",
              "fun": "test.arg",
              "keyword arg one": "Hello from a master",
              "keyword arg two": "Runners do not support positional args"
          }
      ]
      '
      HTTP/1.1 200 OK
      [...snip...]
      {
        "return": [
          {
            "jerry": {
              "args": [
                "positional arg one",
                "positional arg two"
              ],
              "kwargs": {
                "keyword arg one": "Hello from a minion",
                "keyword arg two": "Hello again from a minion",
                [...snip...]
              }
            },
            [...snip; other minion returns here...]
          },
          {
            "args": [],
            "kwargs": {
              "keyword arg two": "Runners do not support positional args",
              "keyword arg one": "Hello from a master"
            }
          }
        ]
      }

   One more example, this time with more commonly used functions:

      curl -b /tmp/cookies.txt -sSi localhost:8000         -H 'Content-type: application/json'         -d '
      [
          {
              "client": "local",
              "tgt": "*",
              "fun": "state.sls",
              "kwarg": {
                  "mods": "apache",
                  "pillar": {
                      "lookup": {
                          "wwwdir": "/srv/httpd/htdocs"
                      }
                  }
              }
          },
          {
              "client": "runner",
              "fun": "cloud.create",
              "provider": "my-ec2-provider",
              "instances": "my-centos-6",
              "image": "ami-1624987f",
              "delvol_on_destroy", true
          }
      ]
      '
      HTTP/1.1 200 OK
      [...snip...]
      {
        "return": [
          {
            "jerry": {
              "pkg_|-install_apache_|-httpd_|-installed": {
                  [...snip full state return here...]
              }
            }
            [...snip other minion returns here...]
          },
          {
              [...snip full salt-cloud output here...]
          }
        ]
      }

   Content negotiation
   This REST interface is flexible in what data formats it will accept  as
   well as what formats it will return (e.g., JSON, YAML, urlencoded).

   * Specify  the  format  of  data  in  the request body by including the
     Content-Type header.

   * Specify the desired data format for the response body with the Accept
     header.

   We recommend the JSON format for most HTTP requests. urlencoded data is
   simple and cannot express complex data structures -- and that is  often
   required for some Salt commands, such as starting a state run that uses
   Pillar data. Salt's CLI tool can reformat strings passed in at the  CLI
   into  complex  data  structures,  and  that  behavior  also  works  via
   salt-api, but that can be brittle and since salt-api can accept JSON it
   is best just to send JSON.

   Here is an example of sending urlencoded data:

      curl -sSik https://localhost:8000 \
          -b ~/cookies.txt \
          -d client=runner \
          -d fun='jobs.lookup_jid' \
          -d jid='20150129182456704682'

      urlencoded data caveats

      * Only a single command may be sent per HTTP request.

      * Repeating  the  arg  parameter  multiple  times  will  cause those
        parameters to be combined into a single list.

        Note, some popular frameworks and languages (notably jQuery,  PHP,
        and  Ruby  on Rails) will automatically append empty brackets onto
        repeated       query        string        parameters.        E.g.,
        ?foo[]=fooone&foo[]=footwo.    This   is   not   supported;   send
        ?foo=fooone&foo=footwo instead, or send JSON or YAML.

      A note about curl

      The -d flag to curl does not automatically urlencode data which  can
      affect  passwords  and other data that contains characters that must
      be encoded. Use the --data-urlencode flag instead. E.g.:

          curl -ksi http://localhost:8000/login \
          -H "Accept: application/json" \
          -d username='myapiuser' \
          --data-urlencode password='1234+' \
          -d eauth='pam'

   Deployment
   The rest_cherrypy netapi module is a standard Python WSGI app.  It  can
   be deployed one of two ways.

   salt-api using the CherryPy server
   The default configuration is to run this module using salt-api to start
   the  Python-based  CherryPy  server.  This   server   is   lightweight,
   multi-threaded,   encrypted   with   SSL,   and  should  be  considered
   production-ready.

   Using a WSGI-compliant web server
   This module may be deployed on any WSGI-compliant server such as Apache
   with mod_wsgi or Nginx with FastCGI, to name just two (there are many).

   Note, external WSGI servers handle URLs, paths, and SSL certs directly.
   The rest_cherrypy configuration options are ignored  and  the  salt-api
   daemon does not need to be running at all. Remember Salt authentication
   credentials are sent in the clear unless SSL is being enforced!

   An example Apache virtual host configuration:

      <VirtualHost *:80>
          ServerName example.com
          ServerAlias *.example.com

          ServerAdmin [email protected]

          LogLevel warn
          ErrorLog /var/www/example.com/logs/error.log
          CustomLog /var/www/example.com/logs/access.log combined

          DocumentRoot /var/www/example.com/htdocs

          WSGIScriptAlias / /path/to/salt/netapi/rest_cherrypy/wsgi.py
      </VirtualHost>

   REST URI Reference
   * /

   * /login

   * /logout

   * /minions

   * /jobs

   * /run

   * /events

   * /hook

   * /keys

   * /ws

   * /stats

   /
   class salt.netapi.rest_cherrypy.app.LowDataAdapter
          The primary entry point to Salt's REST API

          GET()  An explanation of the API with links of where to go next

                 GET /

                        Request Headers

                               * Accept -- the desired response format.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -i localhost:8000

                    GET / HTTP/1.1
                    Host: localhost:8000
                    Accept: application/json

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Type: application/json

   /login
   class salt.netapi.rest_cherrypy.app.Login(*args, **kwargs)
          Log in to receive a session token

          Authentication information.

          GET()  Present the login interface

                 GET /login
                        An explanation of how to log in.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -i localhost:8000/login

                    GET /login HTTP/1.1
                    Host: localhost:8000
                    Accept: text/html

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Type: text/html

          POST(**kwargs)
                 Authenticate against Salt's eauth system

                 POST /login

                        Request Headers

                               * X-Auth-Token  --  a  session  token  from
                                 Login.

                               * Accept -- the desired response format.

                               * Content-Type -- the format of the request
                                 body.

                        Form Parameters

                               * eauth -- the eauth backend configured for
                                 the user

                               * username -- username

                               * password -- password

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -si localhost:8000/login \
                        -c ~/cookies.txt \
                        -H "Accept: application/json" \
                        -H "Content-type: application/json" \
                        -d '{
                            "username": "saltuser",
                            "password": "saltuser",
                            "eauth": "auto"
                        }'

                    POST / HTTP/1.1
                    Host: localhost:8000
                    Content-Length: 42
                    Content-Type: application/json
                    Accept: application/json

                    {"username": "saltuser", "password": "saltuser", "eauth": "auto"}

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Type: application/json
                    Content-Length: 206
                    X-Auth-Token: 6d1b722e
                    Set-Cookie: session_id=6d1b722e; expires=Sat, 17 Nov 2012 03:23:52 GMT; Path=/

                    {"return": {
                        "token": "6d1b722e",
                        "start": 1363805943.776223,
                        "expire": 1363849143.776224,
                        "user": "saltuser",
                        "eauth": "pam",
                        "perms": [
                            "grains.*",
                            "status.*",
                            "sys.*",
                            "test.*"
                        ]
                    }}

   /logout
   class salt.netapi.rest_cherrypy.app.Logout
          Class to remove or invalidate sessions

          POST() Destroy the  currently  active  session  and  expire  the
                 session cookie

   /minions
   class salt.netapi.rest_cherrypy.app.Minions
          Convenience URLs for working with minions

          GET(mid=None)
                 A convenience URL for getting lists of minions or getting
                 minion details

                 GET /minions/(mid)

                        Request Headers

                               * X-Auth-Token  --  a  session  token  from
                                 Login.

                               * Accept -- the desired response format.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -i localhost:8000/minions/ms-3

                    GET /minions/ms-3 HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 129005
                    Content-Type: application/x-yaml

                    return:
                    - ms-3:
                        grains.items:
                            ...

          POST(**kwargs)
                 Start an execution command and immediately return the job
                 id

                 POST /minions

                        Request Headers

                               * X-Auth-Token  --  a  session  token  from
                                 Login.

                               * Accept -- the desired response format.

                               * Content-Type -- the format of the request
                                 body.

                        Response Headers

                               * Content-Type   --   the   format  of  the
                                 response  body;  depends  on  the  Accept
                                 request header.

                        Status Codes

                               * 200 -- success

                               * 400 -- bad or malformed request

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                        lowstate data describing  Salt  commands  must  be
                        sent  in  the request body. The client option will
                        be set to local_async().

                 Example request:

                    curl -sSi localhost:8000/minions \
                        -b ~/cookies.txt \
                        -H "Accept: application/x-yaml" \
                        -d '[{"tgt": "*", "fun": "status.diskusage"}]'

                    POST /minions HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml
                    Content-Type: application/json

                    tgt=*&fun=status.diskusage

                 Example response:

                    HTTP/1.1 202 Accepted
                    Content-Length: 86
                    Content-Type: application/x-yaml

                    return:
                    - jid: '20130603122505459265'
                      minions: [ms-4, ms-3, ms-2, ms-1, ms-0]
                    _links:
                      jobs:
                        - href: /jobs/20130603122505459265

   /jobs
   class salt.netapi.rest_cherrypy.app.Jobs

          GET(jid=None, timeout='')
                 A convenience URL for getting  lists  of  previously  run
                 jobs or getting the return from a single job

                 GET /jobs/(jid)
                        List jobs or show a single job from the job cache.

                        Request Headers

                               * X-Auth-Token  --  a  session  token  from
                                 Login.

                               * Accept -- the desired response format.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -i localhost:8000/jobs

                    GET /jobs HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 165
                    Content-Type: application/x-yaml

                    return:
                    - '20121130104633606931':
                        Arguments:
                        - '3'
                        Function: test.fib
                        Start Time: 2012, Nov 30 10:46:33.606931
                        Target: jerry
                        Target-type: glob

                 Example request:

                    curl -i localhost:8000/jobs/20121130104633606931

                    GET /jobs/20121130104633606931 HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 73
                    Content-Type: application/x-yaml

                    info:
                    - Arguments:
                        - '3'
                        Function: test.fib
                        Minions:
                        - jerry
                        Start Time: 2012, Nov 30 10:46:33.606931
                        Target: '*'
                        Target-type: glob
                        User: saltdev
                        jid: '20121130104633606931'
                    return:
                    - jerry:
                        - - 0
                        - 1
                        - 1
                        - 2
                        - 6.9141387939453125e-06

   /run
   class salt.netapi.rest_cherrypy.app.Run
          Class to run commands without normal session handling

          POST(**kwargs)
                 Run commands bypassing the normal session handling

                 POST /run
                        This   entry  point  is  primarily  for  "one-off"
                        commands.  Each  request  must  pass   full   Salt
                        authentication  credentials. Otherwise this URL is
                        identical to the root URL (/).

                        lowstate data describing  Salt  commands  must  be
                        sent in the request body.

                        Status Codes

                               * 200 -- success

                               * 400 -- bad or malformed request

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -sS localhost:8000/run \
                        -H 'Accept: application/x-yaml' \
                        -H 'Content-type: application/json' \
                        -d '[{
                            "client": "local",
                            "tgt": "*",
                            "fun": "test.ping",
                            "username": "saltdev",
                            "password": "saltdev",
                            "eauth": "auto"
                        }]'

                    POST /run HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml
                    Content-Length: 75
                    Content-Type: application/json

                    [{"client": "local", "tgt": "*", "fun": "test.ping", "username": "saltdev", "password": "saltdev", "eauth": "auto"}]

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 73
                    Content-Type: application/x-yaml

                    return:
                    - ms-0: true
                      ms-1: true
                      ms-2: true
                      ms-3: true
                      ms-4: true

                 The /run enpoint can also be used to issue commands using
                 the salt-ssh subsystem.

                 When  using  salt-ssh,  eauth  credentials  should not be
                 supplied. Instad, authentication should be handled by the
                 SSH layer itself. The use of the salt-ssh client does not
                 require a salt master to be  running.   Instead,  only  a
                 roster  file  must  be  present in the salt configuration
                 directory.

                 All SSH client requests are synchronous.

                 Example SSH client request:

                    curl -sS localhost:8000/run \
                        -H 'Accept: application/x-yaml' \
                        -d client='ssh' \
                        -d tgt='*' \
                        -d fun='test.ping'

                    POST /run HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml
                    Content-Length: 75
                    Content-Type: application/x-www-form-urlencoded

                    client=ssh&tgt=*&fun=test.ping

                 Example SSH response:

                    return:
                    - silver:
                      fun: test.ping
                      fun_args: []
                      id: silver
                      jid: '20141203103525666185'
                      retcode: 0
                      return: true
                      success: true

   /events
   class salt.netapi.rest_cherrypy.app.Events
          Expose the Salt event bus

          The event bus on the Salt master  exposes  a  large  variety  of
          things,  notably  when  executions are started on the master and
          also when minions ultimately  return  their  results.  This  URL
          provides a real-time window into a running Salt infrastructure.

          SEE ALSO:
             events

          GET(token=None, salt_token=None)
                 An HTTP stream of the Salt master event bus

                 This stream is formatted per the Server Sent Events (SSE)
                 spec. Each event is formatted as JSON.

                 GET /events

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                        Query Parameters

                               * token  --  optional  parameter containing
                                 the token  ordinarily  supplied  via  the
                                 X-Auth-Token  header  in  order  to allow
                                 cross-domain requests in browsers that do
                                 not   include   CORS   support   in   the
                                 EventSource   API.   E.g.,   curl    -NsS
                                 localhost:8000/events?token=308650d

                               * salt_token    --    optional    parameter
                                 containing a raw Salt eauth token (not to
                                 be  confused with the token returned from
                                 the  /login   URL).   E.g.,   curl   -NsS
                                 localhost:8000/events?salt_token=30742765

                 Example request:

                    curl -NsS localhost:8000/events

                    GET /events HTTP/1.1
                    Host: localhost:8000

                 Example response:

                 Note,  the  tag  field  is  not  part  of  the  spec. SSE
                 compliant clients  should  ignore  unknown  fields.  This
                 addition  allows  non-compliant clients to only watch for
                 certain tags without having to deserialze the JSON object
                 each time.

                    HTTP/1.1 200 OK
                    Connection: keep-alive
                    Cache-Control: no-cache
                    Content-Type: text/event-stream;charset=utf-8

                    retry: 400

                    tag: salt/job/20130802115730568475/new
                    data: {'tag': 'salt/job/20130802115730568475/new', 'data': {'minions': ['ms-4', 'ms-3', 'ms-2', 'ms-1', 'ms-0']}}

                    tag: salt/job/20130802115730568475/ret/jerry
                    data: {'tag': 'salt/job/20130802115730568475/ret/jerry', 'data': {'jid': '20130802115730568475', 'return': True, 'retcode': 0, 'success': True, 'cmd': '_return', 'fun': 'test.ping', 'id': 'ms-1'}}

                 The event stream can be easily consumed via JavaScript:

                    var source = new EventSource('/events');
                    source.onopen = function() { console.info('Listening ...') };
                    source.onerror = function(err) { console.error(err) };
                    source.onmessage = function(message) {
                      var saltEvent = JSON.parse(message.data);
                      console.info(saltEvent.tag)
                      console.debug(saltEvent.data)
                    };

                 Or using CORS:

                    var source = new EventSource('/events?token=ecd589e4e01912cf3c4035afad73426dbb8dba75', {withCredentials: true});

                 It is also possible to consume the stream via the shell.

                 Records  are separated by blank lines; the data: and tag:
                 prefixes  will  need  to  be  removed   manually   before
                 attempting to unserialize the JSON.

                 curl's  -N  flag  turns  off  input  buffering  which  is
                 required to process the stream incrementally.

                 Here is a basic example of  printing  each  event  as  it
                 comes in:

                    curl -NsS localhost:8000/events |\
                            while IFS= read -r line ; do
                                echo $line
                            done

                 Here is an example of using awk to filter events based on
                 tag:

                    curl -NsS localhost:8000/events |\
                            awk '
                                BEGIN { RS=""; FS="\\n" }
                                $1 ~ /^tag: salt\/job\/[0-9]+\/new$/ { print $0 }
                            '
                    tag: salt/job/20140112010149808995/new
                    data: {"tag": "salt/job/20140112010149808995/new", "data": {"tgt_type": "glob", "jid": "20140112010149808995", "tgt": "jerry", "_stamp": "2014-01-12_01:01:49.809617", "user": "shouse", "arg": [], "fun": "test.ping", "minions": ["jerry"]}}
                    tag: 20140112010149808995
                    data: {"tag": "20140112010149808995", "data": {"fun_args": [], "jid": "20140112010149808995", "return": true, "retcode": 0, "success": true, "cmd": "_return", "_stamp": "2014-01-12_01:01:49.819316", "fun": "test.ping", "id": "jerry"}}

   /hook
   class salt.netapi.rest_cherrypy.app.Webhook
          A generic web hook entry point that fires  an  event  on  Salt's
          event bus

          External  services can POST data to this URL to trigger an event
          in Salt.  For example, Amazon SNS, Jenkins-CI or  Travis-CI,  or
          GitHub web hooks.

          NOTE:
             Be mindful of security

             Salt's  Reactor can run any code. A Reactor SLS that responds
             to a hook event is responsible for validating that the  event
             came from a trusted source and contains valid data.

             This is a generic interface and securing it is up to you!

             This  URL  requires  authentication  however not all external
             services can be configured to authenticate. For  this  reason
             authentication  can  be  selectively  disabled  for this URL.
             Follow best practices -- always use SSL, pass a  secret  key,
             configure  the  firewall  to  only allow traffic from a known
             source, etc.

          The event data is taken from the request body. The  Content-Type
          header is respected for the payload.

          The event tag is prefixed with salt/netapi/hook and the URL path
          is appended to the end. For example,  a  POST  request  sent  to
          /hook/mycompany/myapp/mydata  will produce a Salt event with the
          tag salt/netapi/hook/mycompany/myapp/mydata.

          The  following  is  an  example   .travis.yml   file   to   send
          notifications to Salt of successful test runs:

             language: python
             script: python -m unittest tests
             after_success:
                 - |
                     curl -sSk https://saltapi-url.example.com:8000/hook/travis/build/success                         -d branch="${TRAVIS_BRANCH}"                         -d commit="${TRAVIS_COMMIT}"

          SEE ALSO:
             events, reactor

          POST(*args, **kwargs)
                 Fire an event in Salt with a custom event tag and data

                 POST /hook

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                               * 413 -- request body is too large

                 Example request:

                    curl -sS localhost:8000/hook \
                        -H 'Content-type: application/json' \
                        -d '{"foo": "Foo!", "bar": "Bar!"}'

                    POST /hook HTTP/1.1
                    Host: localhost:8000
                    Content-Length: 16
                    Content-Type: application/json

                    {"foo": "Foo!", "bar": "Bar!"}

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 14
                    Content-Type: application/json

                    {"success": true}

                 As     a     practical     example,      an      internal
                 continuous-integration  build  server  could send an HTTP
                 POST         request         to          the          URL
                 https://localhost:8000/hook/mycompany/build/success which
                 contains the result of a build and the SHA of the version
                 that  was  built  as  JSON.  That  would then produce the
                 following event in Salt that could be used to kick off  a
                 deployment via Salt's Reactor:

                    Event fired at Fri Feb 14 17:40:11 2014
                    *************************
                    Tag: salt/netapi/hook/mycompany/build/success
                    Data:
                    {'_stamp': '2014-02-14_17:40:11.440996',
                        'headers': {
                            'X-My-Secret-Key': 'F0fAgoQjIT@W',
                            'Content-Length': '37',
                            'Content-Type': 'application/json',
                            'Host': 'localhost:8000',
                            'Remote-Addr': '127.0.0.1'},
                        'post': {'revision': 'aa22a3c4b2e7', 'result': True}}

                 Salt's Reactor could listen for the event:

                    reactor:
                      - 'salt/netapi/hook/mycompany/build/*':
                        - /srv/reactor/react_ci_builds.sls

                 And finally deploy the new build:

                    {% set secret_key = data.get('headers', {}).get('X-My-Secret-Key') %}
                    {% set build = data.get('post', {}) %}

                    {% if secret_key == 'F0fAgoQjIT@W' and build.result == True %}
                    deploy_my_app:
                      cmd.state.sls:
                        - tgt: 'application*'
                        - arg:
                          - myapp.deploy
                        - kwarg:
                            pillar:
                              revision: {{ revision }}
                    {% endif %}

   /keys
   class salt.netapi.rest_cherrypy.app.Keys
          Convenience URLs for working with minion keys

          New in version 2014.7.0.

          These  URLs  wrap  the  functionality  provided by the key wheel
          module functions.

          GET(mid=None)
                 Show the list of minion keys or detail on a specific key

                 New in version 2014.7.0.

                 GET /keys/(mid)
                        List all keys or show a specific key

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -i localhost:8000/keys

                    GET /keys HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 165
                    Content-Type: application/x-yaml

                    return:
                      local:
                      - master.pem
                      - master.pub
                      minions:
                      - jerry
                      minions_pre: []
                      minions_rejected: []

                 Example request:

                    curl -i localhost:8000/keys/jerry

                    GET /keys/jerry HTTP/1.1
                    Host: localhost:8000
                    Accept: application/x-yaml

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 73
                    Content-Type: application/x-yaml

                    return:
                      minions:
                        jerry: 51:93:b3:d0:9f:3a:6d:e5:28:67:c2:4b:27:d6:cd:2b

          POST(**kwargs)
                 Easily generate keys for a minion and auto-accept the new
                 key

                 Accepts all the same parameters as the key.gen_accept.

                 Example partial  kickstart  script  to  bootstrap  a  new
                 minion:

                    %post
                    mkdir -p /etc/salt/pki/minion
                    curl -sSk https://localhost:8000/keys \
                            -d mid=jerry \
                            -d username=kickstart \
                            -d password=kickstart \
                            -d eauth=pam \
                        | tar -C /etc/salt/pki/minion -xf -

                    mkdir -p /etc/salt/minion.d
                    printf 'master: 10.0.0.5\nid: jerry' > /etc/salt/minion.d/id.conf
                    %end

                 POST /keys
                        Generate  a public and private key and return both
                        as a tarball

                        Authentication credentials must be passed  in  the
                        request.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

                 Example request:

                    curl -sSk https://localhost:8000/keys \
                            -d mid=jerry \
                            -d username=kickstart \
                            -d password=kickstart \
                            -d eauth=pam \
                            -o jerry-salt-keys.tar

                    POST /keys HTTP/1.1
                    Host: localhost:8000

                 Example response:

                    HTTP/1.1 200 OK
                    Content-Length: 10240
                    Content-Disposition: attachment; filename="saltkeys-jerry.tar"
                    Content-Type: application/x-tar

                    jerry.pub0000644000000000000000000000070300000000000010730 0ustar  00000000000000

   /ws
   class salt.netapi.rest_cherrypy.app.WebsocketEndpoint
          Open a WebSocket connection to Salt's event bus

          The event bus on the Salt master  exposes  a  large  variety  of
          things,  notably  when  executions are started on the master and
          also when minions ultimately  return  their  results.  This  URL
          provides  a real-time window into a running Salt infrastructure.
          Uses websocket as the transport mechanism.

          SEE ALSO:
             events

          GET(token=None, **kwargs)
                 Return a websocket connection of Salt's event stream

                 GET /ws/(token)

                 Query format_events
                        The  event   stream   will   undergo   server-side
                        formatting  if  the format_events URL parameter is
                        included in the request. This  can  be  useful  to
                        avoid formatting on the client-side:

                           curl -NsS <...snip...> localhost:8000/ws?format_events

                 Reqheader X-Auth-Token
                        an authentication token from Login.

                 Status 101
                        switching to the websockets protocol

                 Status 401
                        authentication required

                 Status 406
                        requested Content-Type not available

                 Example request:

                    curl -NsSk \
                        -H 'X-Auth-Token: ffedf49d' \
                        -H 'Host: localhost:8000' \
                        -H 'Connection: Upgrade' \
                        -H 'Upgrade: websocket' \
                        -H 'Origin: https://localhost:8000' \
                        -H 'Sec-WebSocket-Version: 13' \
                        -H 'Sec-WebSocket-Key: '"$(echo -n $RANDOM | base64)" \
                        localhost:8000/ws

                    GET /ws HTTP/1.1
                    Connection: Upgrade
                    Upgrade: websocket
                    Host: localhost:8000
                    Origin: https://localhost:8000
                    Sec-WebSocket-Version: 13
                    Sec-WebSocket-Key: s65VsgHigh7v/Jcf4nXHnA==
                    X-Auth-Token: ffedf49d

                 Example response:

                    HTTP/1.1 101 Switching Protocols
                    Upgrade: websocket
                    Connection: Upgrade
                    Sec-WebSocket-Accept: mWZjBV9FCglzn1rIKJAxrTFlnJE=
                    Sec-WebSocket-Version: 13

                 An  authentication token may optionally be passed as part
                 of the URL for browsers that cannot be configured to send
                 the authentication header or cookie:

                    curl -NsS <...snip...> localhost:8000/ws/ffedf49d

                 The event stream can be easily consumed via JavaScript:

                    // Note, you must be authenticated!
                    var source = new Websocket('ws://localhost:8000/ws/d0ce6c1a');
                    source.onerror = function(e) { console.debug('error!', e); };
                    source.onmessage = function(e) { console.debug(e.data); };

                    source.send('websocket client ready')

                    source.close();

                 Or  via  Python, using the Python module websocket-client
                 for example.

                    # Note, you must be authenticated!

                    from websocket import create_connection

                    ws = create_connection('ws://localhost:8000/ws/d0ce6c1a')
                    ws.send('websocket client ready')

                    # Look at https://pypi.python.org/pypi/websocket-client/ for more
                    # examples.
                    while listening_to_events:
                        print ws.recv()

                    ws.close()

                 Above  examples  show  how  to  establish   a   websocket
                 connection  to Salt and activating real time updates from
                 Salt's event stream by signaling websocket client ready.

   /stats
   class salt.netapi.rest_cherrypy.app.Stats
          Expose statistics on the running CherryPy server

          GET()  Return a dump of statistics collected from  the  CherryPy
                 server

                 GET /stats

                        Request Headers

                               * X-Auth-Token  --  a  session  token  from
                                 Login.

                               * Accept -- the desired response format.

                        Response Headers

                               * Content-Type  --  the   format   of   the
                                 response  body;  depends  on  the  Accept
                                 request header.

                        Status Codes

                               * 200 -- success

                               * 401 -- authentication required

                               * 406   --   requested   Content-Type   not
                                 available

   rest_tornado
   A Websockets add-on to saltnado
   depends

          * tornado Python module

   In order to enable saltnado_websockets you must add websockets: True to
   your saltnado config block.

      rest_tornado:
          # can be any port
          port: 8000
          ssl_crt: /etc/pki/api/certs/server.crt
          # no need to specify ssl_key if cert and key
          # are in one single file
          ssl_key: /etc/pki/api/certs/server.key
          debug: False
          disable_ssl: False
          websockets: True

   All Events
   Exposes all "real-time" events from Salt's event  bus  on  a  websocket
   connection.   It  should  be  noted  that  "Real-time" here means these
   events are made available to the server as soon  as  any  salt  related
   action (changes to minions, new jobs etc) happens.  Clients are however
   assumed to be able to tolerate any network transport related latencies.
   Functionality  provided  by this endpoint is similar to the /events end
   point.

   The event bus on the Salt master exposes a  large  variety  of  things,
   notably when executions are started on the master and also when minions
   ultimately return their results. This URL provides a  real-time  window
   into  a  running  Salt  infrastructure. Uses websocket as the transport
   mechanism.

   Exposes GET method  to  return  websocket  connections.   All  requests
   should  include  an  auth token.  A way to obtain obtain authentication
   tokens is shown below.

      % curl -si localhost:8000/login \
          -H "Accept: application/json" \
          -d username='salt' \
          -d password='salt' \
          -d eauth='pam'

   Which results in the response

      {
          "return": [{
              "perms": [".*", "@runner", "@wheel"],
              "start": 1400556492.277421,
              "token": "d0ce6c1a37e99dcc0374392f272fe19c0090cca7",
              "expire": 1400599692.277422,
              "user": "salt",
              "eauth": "pam"
          }]
      }

   In      this      example       the       token       returned       is
   d0ce6c1a37e99dcc0374392f272fe19c0090cca7   and   can   be  included  in
   subsequent websocket requests (as part of the URL).

   The event stream can be easily consumed via JavaScript:

      // Note, you must be authenticated!

      // Get the Websocket connection to Salt
      var source = new Websocket('wss://localhost:8000/all_events/d0ce6c1a37e99dcc0374392f272fe19c0090cca7');

      // Get Salt's "real time" event stream.
      source.onopen = function() { source.send('websocket client ready'); };

      // Other handlers
      source.onerror = function(e) { console.debug('error!', e); };

      // e.data represents Salt's "real time" event data as serialized JSON.
      source.onmessage = function(e) { console.debug(e.data); };

      // Terminates websocket connection and Salt's "real time" event stream on the server.
      source.close();

   Or via Python, using the Python module  websocket-client  for  example.
   Or the tornado client.

      # Note, you must be authenticated!

      from websocket import create_connection

      # Get the Websocket connection to Salt
      ws = create_connection('wss://localhost:8000/all_events/d0ce6c1a37e99dcc0374392f272fe19c0090cca7')

      # Get Salt's "real time" event stream.
      ws.send('websocket client ready')

      # Simple listener to print results of Salt's "real time" event stream.
      # Look at https://pypi.python.org/pypi/websocket-client/ for more examples.
      while listening_to_events:
          print ws.recv()       #  Salt's "real time" event data as serialized JSON.

      # Terminates websocket connection and Salt's "real time" event stream on the server.
      ws.close()

      # Please refer to https://github.com/liris/websocket-client/issues/81 when using a self signed cert

   Above examples show how to establish a websocket connection to Salt and
   activating real time updates from  Salt's  event  stream  by  signaling
   websocket client ready.

   Formatted Events
   Exposes  formatted  "real-time"  events  from  Salt's  event  bus  on a
   websocket connection.  It should be noted that "Real-time"  here  means
   these  events  are  made  available  to  the server as soon as any salt
   related action (changes to minions, new jobs etc) happens.  Clients are
   however  assumed  to  be able to tolerate any network transport related
   latencies.  Functionality provided by this endpoint is similar  to  the
   /events end point.

   The  event  bus  on  the Salt master exposes a large variety of things,
   notably when executions are started on the master and also when minions
   ultimately  return  their results. This URL provides a real-time window
   into a running Salt infrastructure. Uses  websocket  as  the  transport
   mechanism.

   Formatted  events parses the raw "real time" event stream and maintains
   a current view of the following:

   * minions

   * jobs

   A change  to  the  minions  (such  as  addition,  removal  of  keys  or
   connection  drops) or jobs is processed and clients are updated.  Since
   we  use  salt's  presence  events  to  track  minions,  please   enable
   presence_events and set a small value for the loop_interval in the salt
   master config file.

   Exposes GET method  to  return  websocket  connections.   All  requests
   should  include  an  auth token.  A way to obtain obtain authentication
   tokens is shown below.

      % curl -si localhost:8000/login \
          -H "Accept: application/json" \
          -d username='salt' \
          -d password='salt' \
          -d eauth='pam'

   Which results in the response

      {
          "return": [{
              "perms": [".*", "@runner", "@wheel"],
              "start": 1400556492.277421,
              "token": "d0ce6c1a37e99dcc0374392f272fe19c0090cca7",
              "expire": 1400599692.277422,
              "user": "salt",
              "eauth": "pam"
          }]
      }

   In      this      example       the       token       returned       is
   d0ce6c1a37e99dcc0374392f272fe19c0090cca7   and   can   be  included  in
   subsequent websocket requests (as part of the URL).

   The event stream can be easily consumed via JavaScript:

      // Note, you must be authenticated!

      // Get the Websocket connection to Salt
      var source = new Websocket('wss://localhost:8000/formatted_events/d0ce6c1a37e99dcc0374392f272fe19c0090cca7');

      // Get Salt's "real time" event stream.
      source.onopen = function() { source.send('websocket client ready'); };

      // Other handlers
      source.onerror = function(e) { console.debug('error!', e); };

      // e.data represents Salt's "real time" event data as serialized JSON.
      source.onmessage = function(e) { console.debug(e.data); };

      // Terminates websocket connection and Salt's "real time" event stream on the server.
      source.close();

   Or via Python, using the Python module  websocket-client  for  example.
   Or the tornado client.

      # Note, you must be authenticated!

      from websocket import create_connection

      # Get the Websocket connection to Salt
      ws = create_connection('wss://localhost:8000/formatted_events/d0ce6c1a37e99dcc0374392f272fe19c0090cca7')

      # Get Salt's "real time" event stream.
      ws.send('websocket client ready')

      # Simple listener to print results of Salt's "real time" event stream.
      # Look at https://pypi.python.org/pypi/websocket-client/ for more examples.
      while listening_to_events:
          print ws.recv()       #  Salt's "real time" event data as serialized JSON.

      # Terminates websocket connection and Salt's "real time" event stream on the server.
      ws.close()

      # Please refer to https://github.com/liris/websocket-client/issues/81 when using a self signed cert

   Above examples show how to establish a websocket connection to Salt and
   activating real time updates from  Salt's  event  stream  by  signaling
   websocket client ready.

   Example responses
   Minion  information is a dictionary keyed by each connected minion's id
   (mid), grains information for each minion is also included.

   Minion information is sent in response to the following minion events:

   *

     connection drops

            * requires   running   manage.present    periodically    every
              loop_interval seconds

   * minion addition

   * minon removal

      # Not all grains are shown
      data: {
          "minions": {
              "minion1": {
                  "id": "minion1",
                  "grains": {
                      "kernel": "Darwin",
                      "domain": "local",
                      "zmqversion": "4.0.3",
                      "kernelrelease": "13.2.0"
                  }
              }
          }
      }

   Job information is also tracked and delivered.

   Job information is also a dictionary in which each job's information is
   keyed by salt's jid.

      data: {
          "jobs": {
              "20140609153646699137": {
                  "tgt_type": "glob",
                  "jid": "20140609153646699137",
                  "tgt": "*",
                  "start_time": "2014-06-09T15:36:46.700315",
                  "state": "complete",
                  "fun": "test.ping",
                  "minions": {
                      "minion1": {
                          "return": true,
                          "retcode": 0,
                          "success": true
                      }
                  }
              }
          }
      }

   Setup
   REST URI Reference
   * /

   * /login

   * /minions

   * /jobs

   * /run

   * /events

   * /hook

   /
   salt.netapi.rest_tornado.saltnado.SaltAPIHandler
          alias of <Mock object at 0x7f211b5df450>

   /login
   salt.netapi.rest_tornado.saltnado.SaltAuthHandler
          alias of <Mock object at 0x7f211b5df950>

   /minions
   salt.netapi.rest_tornado.saltnado.MinionSaltAPIHandler
          alias of <Mock object at 0x7f211b5dff10>

   /jobs
   salt.netapi.rest_tornado.saltnado.JobsSaltAPIHandler
          alias of <Mock object at 0x7f211b6ea090>

   /run
   salt.netapi.rest_tornado.saltnado.RunSaltAPIHandler
          alias of <Mock object at 0x7f211b6ea850>

   /events
   salt.netapi.rest_tornado.saltnado.EventsSaltAPIHandler
          alias of <Mock object at 0x7f211b6ea490>

   /hook
   salt.netapi.rest_tornado.saltnado.WebhookSaltAPIHandler
          alias of <Mock object at 0x7f211b5df910>

   rest_wsgi
   A minimalist REST API for Salt
   This rest_wsgi module provides a no-frills REST interface  for  sending
   commands to the Salt master. There are no dependencies.

   Extra  care  must  be taken when deploying this module into production.
   Please read this documentation in entirety.

   All authentication is done through Salt's external auth system.

   Usage
   * All requests must be sent to the root URL (/).

   * All requests must be sent as a POST request with JSON content in  the
     request body.

   * All responses are in JSON.

   SEE ALSO:
      rest_cherrypy

      The  rest_cherrypy  module  is more full-featured, production-ready,
      and has builtin security features.

   Deployment
   The rest_wsgi netapi module is a standard Python WSGI app.  It  can  be
   deployed one of two ways.

   Using a WSGI-compliant web server
   This module may be run via any WSGI-compliant production server such as
   Apache with mod_wsgi or Nginx with FastCGI.

   It is strongly recommended that this app be used  with  a  server  that
   supports  HTTPS  encryption  since  raw Salt authentication credentials
   must be sent with every request. Any apps that access Salt through this
   interface  will  need  to  manually  manage  authentication credentials
   (either username and password or a Salt token). Tread carefully.

   salt-api using a development-only server
   If   run   directly   via   the   salt-api   daemon   it    uses    the
   wsgiref.simple_server() that ships in the Python standard library. This
   is  a  single-threaded  server  that  is  intended  for   testing   and
   development.  This server does not use encryption; please note that raw
   Salt authentication credentials must be sent with every HTTP request.

   Running this module via salt-api is not recommended!

   In order to start this module via the  salt-api  daemon  the  following
   must be put into the Salt master config:

      rest_wsgi:
          port: 8001

   Usage examples
   POST / Example request for a basic test.ping:

             % curl -sS -i \
                     -H 'Content-Type: application/json' \
                     -d '[{"eauth":"pam","username":"saltdev","password":"saltdev","client":"local","tgt":"*","fun":"test.ping"}]' localhost:8001

          Example response:

             HTTP/1.0 200 OK
             Content-Length: 89
             Content-Type: application/json

             {"return": [{"ms--4": true, "ms--3": true, "ms--2": true, "ms--1": true, "ms--0": true}]}

          Example request for an asynchronous test.ping:

             % curl -sS -i \
                     -H 'Content-Type: application/json' \
                     -d '[{"eauth":"pam","username":"saltdev","password":"saltdev","client":"local_async","tgt":"*","fun":"test.ping"}]' localhost:8001

          Example response:

             HTTP/1.0 200 OK
             Content-Length: 103
             Content-Type: application/json

             {"return": [{"jid": "20130412192112593739", "minions": ["ms--4", "ms--3", "ms--2", "ms--1", "ms--0"]}]}

          Example request for looking up a job ID:

             % curl -sS -i \
                     -H 'Content-Type: application/json' \
                     -d '[{"eauth":"pam","username":"saltdev","password":"saltdev","client":"runner","fun":"jobs.lookup_jid","jid":"20130412192112593739"}]' localhost:8001

          Example response:

             HTTP/1.0 200 OK
             Content-Length: 89
             Content-Type: application/json

             {"return": [{"ms--4": true, "ms--3": true, "ms--2": true, "ms--1": true, "ms--0": true}]}

   form lowstate
          A list of lowstate data appropriate for the client interface you
          are calling.

   status 200
          success

   status 401
          authentication required

   output modules
   Follow one of the below links for further information and examples

             
             highstate            Outputter  for  displaying 
                                  results of state runs      
             
             json_out             Display   return  data  in 
                                  JSON format                
             
             key                  Display salt-key output    
             
             nested               Recursively display nested 
                                  data                       
             
             newline_values_only  Display    values    only, 
                                  separated by newlines      
             
             no_out               Display no output          
             
             no_return            Display output for minions 
                                  that did not return        
             
             overstatestage       Display clean output of an 
                                  overstate stage            
             

             pprint_out           Python        pretty-print 
                                  (pprint)                   
             
             progress             Display  return  data as a 
                                  progress bar               
             
             raw                  Display  raw  output  data 
                                  structure                  
             
             txt                  Simple text outputter      
             
             virt_query           virt.query outputter       
             
             yaml_out             Display   return  data  in 
                                  YAML format                
             

   salt.output.highstate
   Outputter for displaying results of state runs
   The return data from the Highstate command is a standard data structure
   which  is  parsed  by  the  highstate  outputter to deliver a clean and
   readable set of information about the HighState run on minions.

   Two configurations can be set to modify the highstate outputter.  These
   values can be set in the master config to change the output of the salt
   command or set in the  minion  config  to  change  the  output  of  the
   salt-call command.

   state_verbose:
          By  default  state_verbose is set to True, setting this to False
          will  instruct  the  highstate  outputter  to  omit   displaying
          anything in green, this means that nothing with a result of True
          and no changes will not be printed

   state_output:
          The highstate outputter  has  six  output  modes,  full,  terse,
          mixed, mixed_id, changes and filter.

          * The  default  is set to full, which will display many lines of
            detailed information for each executed chunk.

          * If terse is used, then the output is  greatly  simplified  and
            shown in only one line.

          * If  mixed  is  used,  then  terse output will be used unless a
            state failed, in which case full output will be used.

          * If mixed_id is used, then the mixed form will be used, but the
            value for name will be drawn from the state ID. This is useful
            for cases where the name value might be very long and hard  to
            read.

          * If  changes  is  used, then terse output will be used if there
            was no error and no changes, otherwise  full  output  will  be
            used.

          * If  filter  is  used,  then  either  or  both of two different
            filters can  be  used:  exclude  or  terse.   *  for  exclude,
            state.highstate expects a list of states to be excluded
               (or  None)  followed  by True for terse output or False for
               regular output.  Because of parsing nuances, if only one of
               these is used, it must still contain a comma. For instance:
               exclude=True,.

            * for terse, state.highstate expects simply True or False.

            These can be set as such from the command line, or in the Salt
            config    as   state_output_exclude   or   state_output_terse,
            respectively.

   state_tabular:
          If state_output uses the terse output, set this to True  for  an
          aligned output format.  If you wish to use a custom format, this
          can be set to a string.

   Example usage:

   If state_output: filter is set in the configuration file:

      salt '*' state.highstate exclude=None,True

   means to exclude no states from the highstate and turn on terse output.

      salt twd state.highstate exclude=problemstate1,problemstate2,False

   means to  exclude  states  problemstate1  and  problemstate2  from  the
   highstate, and use regular output.

   Example  output  for the above highstate call when top.sls defines only
   one other state to apply to minion twd:

      twd:

      Summary for twd
      ------------
      Succeeded: 1 (changed=1)
      Failed:    0
      ------------
      Total states run:     1

   Example output with no special settings in configuration files:

      myminion:
      ----------
                ID: test.ping
          Function: module.run
            Result: True
           Comment: Module function test.ping executed
           Changes:
                    ----------
                    ret:
                        True

      Summary for myminion
      ------------
      Succeeded: 1
      Failed:    0
      ------------
      Total:     0

   salt.output.highstate.output(data, **kwargs)
          The HighState Outputter is  only  meant  to  be  used  with  the
          state.highstate  function,  or a function that returns highstate
          return data.

   salt.output.json_out
   Display return data in JSON format
   configuration
          The output format can be  configured  in  two  ways:  Using  the
          --out-indent  CLI  flag  and  specifying a positive integer or a
          negative integer to group JSON from  each  minion  to  a  single
          line.

          Or  setting  the  output_indent  setting in the Master or Minion
          configuration file with one of the following values:

          * Null: put each minion return on a single line.

          * pretty: use four-space indents and sort the keys.

          * An integer: specify the indentation level.

   Salt's outputters operate on a per-minion  basis.  Each  minion  return
   will be output as a single JSON object once it comes in to the master.

   Some  JSON  parsers  can guess when an object ends and a new one begins
   but many can not. A good  way  to  differentiate  between  each  minion
   return  is  to use the single-line output format and to parse each line
   individually. Example output (truncated):

      {"dave": {"en0": {"hwaddr": "02:b0:26:32:4c:69", ...}}}
      {"jerry": {"en0": {"hwaddr": "02:26:ab:0d:b9:0d", ...}}}
      {"kevin": {"en0": {"hwaddr": "02:6d:7f:ce:9f:ee", ...}}}
      {"mike": {"en0": {"hwaddr": "02:48:a2:4b:70:a0", ...}}}
      {"phill": {"en0": {"hwaddr": "02:1d:cc:a2:33:55", ...}}}
      {"stuart": {"en0": {"hwaddr": "02:9a:e0:ea:9e:3c", ...}}}

   salt.output.json_out.output(data, **kwargs)
          Print the output data in JSON

   salt.output.key
   Display salt-key output
   The salt-key command makes use of this outputter to format its output.

   salt.output.key.output(data, **kwargs)
          Read in the dict structure generated by the salt key API methods
          and print the structure.

   salt.output.nested
   Recursively display nested data
   This is the default outputter for most execution functions.

   Example output:

      myminion:
          ----------
          foo:
              ----------
              bar:
                  baz
              dictionary:
                  ----------
                  abc:
                      123
                  def:
                      456
              list:
                  - Hello
                  - World

   class salt.output.nested.NestDisplay
          Manage the nested display contents

          display(ret, indent, prefix, out)
                 Recursively  iterate  down  through  data  structures  to
                 determine output

   salt.output.nested.output(ret, **kwargs)
          Display ret data

   salt.output.newline_values_only
   Display values only, separated by newlines
   New in version 2015.5.0.

   This outputter is designed for Salt CLI return data.  It  will  do  the
   following to the return dict:

   1. Get just the values (ignoring the minion IDs).

   2. Each value, if it is iterable, is split a separate line.

   3. Each minion's values are separated by newlines.

   This  results  in  a  single  string  of return data containing all the
   values from the various minions.

   WARNING:
      As noted above, this outputter will discard the minion  ID.  If  the
      minion  ID  is  important,  then  an outputter that returns the full
      return dictionary in a parsable format (such as  json,  pprint,,  or
      yaml) may be more suitable.

   Example 1
   Input
      {
          'myminion': ['127.0.0.1', '10.0.0.1'],
          'second-minion': ['127.0.0.1', '10.0.0.2']
      }

   Output
      127.0.0.1
      10.0.0.1
      127.0.0.1
      10.0.0.2

   Example 2
   Input
      {
          'myminion': 8,
          'second-minion': 10
      }

   Output
      8
      10

   salt.output.newline_values_only.output(data, **kwargs)
          Display modified ret data

   salt.output.no_out
   Display no output
   No output is produced when this outputter is selected

   salt.output.no_out.output(ret, **kwargs)
          Don't  display  data.  Used  when you only are interested in the
          return.

   salt.output.no_return
   Display output for minions that did not return
   This outputter is used to display notices about which minions failed to
   return  when a salt function is run with -v or --verbose. It should not
   be called directly from the CLI.

   Example output:

      virtucentos:
          Minion did not return

   class salt.output.no_return.NestDisplay
          Create generator for nested output

          display(ret, indent, prefix, out)
                 Recursively  iterate  down  through  data  structures  to
                 determine output

   salt.output.no_return.output(ret, **kwargs)
          Display ret data

   salt.output.overstatestage
   Display clean output of an overstate stage
   This  outputter  is used to display OverState stages, and should not be
   called directly.

   salt.output.overstatestage.output(data, **kwargs)
          Format  the  data  for  printing  stage  information  from   the
          overstate system

   salt.output.pprint_out
   Python pretty-print (pprint)
   The  python  pretty-print  system  was  once  the default outputter. It
   simply passes the return data through to pprint.pformat and prints  the
   results.

   Example output:

      {'saltmine': {'foo': {'bar': 'baz',
                            'dictionary': {'abc': 123, 'def': 456},
                            'list': ['Hello', 'World']}}}

   salt.output.pprint_out.output(data, **kwargs)
          Print out via pretty print

   salt.output.progress
   Display return data as a progress bar

   salt.output.progress.output(ret, bar, **kwargs)
          Update the progress bar

   salt.output.progress.progress_iter(progress)
          Initialize and return a progress bar iter

   salt.output.raw
   Display raw output data structure
   This  outputter  simply displays the output as a python data structure,
   by printing a string representation of it. It is similar to the  pprint
   outputter, only the data is not nicely formatted/indented.

   This  was  the  original  outputter  used  by Salt before the outputter
   system was developed.

   Example output:

      {'myminion': {'foo': {'list': ['Hello', 'World'], 'bar': 'baz', 'dictionary': {'abc': 123, 'def': 456}}}}

   salt.output.raw.output(data, **kwargs)
          Rather basic....

   salt.output.txt
   Simple text outputter
   The txt outputter has been developed to  make  the  output  from  shell
   commands  on  minions appear as they do when the command is executed on
   the minion.

   salt.output.txt.output(data, **kwargs)
          Output the data in lines, very nice for running commands

   salt.output.virt_query
   virt.query outputter
   Used to display the output from the virt.query runner.

   salt.output.virt_query.output(data, **kwargs)
          Display output for the salt-run virt.query function

   salt.output.yaml_out
   Display return data in YAML format
   This outputter defaults to printing  in  YAML  block  mode  for  better
   readability.

   Example output:

      saltmine:
        foo:
          bar: baz
          dictionary:
            abc: 123
            def: 456
          list:
            - Hello
            - World

   salt.output.yaml_out.output(data, **kwargs)
          Print out YAML using the block mode

   pillar modules
               
               cmd_json         Execute a command and read 
                                the output as JSON.        
               
               cmd_yaml         Execute a command and read 
                                the output as YAML.        
               
               cmd_yamlex       Execute a command and read 
                                the output as YAMLEX.      
               
               cobbler          A module to pull data from 
                                Cobbler  via  its API into 
                                the Pillar dictionary      
               
               confidant        An external pillar  module 
                                for   getting  credentials 
                                from confidant.            
               
               consul_pillar    Use Consul K/V as a Pillar 
                                source  with values parsed 
                                as YAML                    
               
               django_orm       Generate Pillar data  from 
                                Django  models through the 
                                Django ORM                 
               
               ec2_pillar       Retrieve EC2 instance data 
                                for minions.               
               
               etcd_pillar      Use  etcd data as a Pillar 
                                source                     
               
               file_tree        Recursively  iterate  over 
                                directories  and  add  all 
                                files as Pillar data       
               
               foreman          A module to pull data from 
                                Foreman  via  its API into 
                                the Pillar dictionary      
               
               git_pillar       Use a git repository as  a 
                                Pillar source              
               
               hg_pillar        Use    remote    Mercurial 
                                repository  as  a   Pillar 
                                source.                    
               
               hiera            Use hiera data as a Pillar 
                                source                     
               
               http_yaml        A module that adds data to 
                                the    Pillar    structure 
                                retrieved   by   an   http 
                                request                    
               
               libvirt          Load  up  the libvirt keys 
                                into Pillar  for  a  given 
                                minion  if  said keys have 
                                been                       
               
               mongo            Read Pillar  data  from  a 
                                mongodb collection         
               
               mysql            Retrieve  Pillar  data  by 
                                doing a MySQL query        
               
               neutron          Use Openstack Neutron data 
                                as a Pillar source.        
               
               nodegroups                                  
               
               pepa             Pepa                       
               
               pillar_ldap      Use  LDAP data as a Pillar 
                                source                     
               
               puppet           Execute   an    unmodified 
                                puppet_node_classifier and 
                                read the output as YAML.   
               
               reclass_adapter  Use the "reclass" database 
                                as a Pillar source         
               
               redismod         Read  pillar  data  from a 
                                Redis backend              
               
               s3               Copy pillar  data  from  a 
                                bucket in Amazon S3        
               
               sql_base         Retrieve  Pillar  data  by 
                                doing a SQL query          
               
               sqlcipher        Retrieve  Pillar  data  by 
                                running a SQLCipher query  
               
               sqlite3          Retrieve  Pillar  data  by 
                                doing a SQLite3 query      
               
               stack            Simple and  flexible  YAML 
                                ext_pillar  which can read 
                                pillar from within pillar. 
               
               svn_pillar       Clone   a    remote    SVN 
                                repository   and  use  the 
                                filesystem  as  a   Pillar 
                                source                     
               
               varstack_pillar  Use  Varstack  data  as  a 
                                Pillar source              
               
               vault            Vault Pillar Module        
               
               virtkey          Accept  a   key   from   a 
                                hypervisor   if  the  virt 
                                runner     has     already 
                                submitted an authorization 
                                request                    
               

   salt.pillar.cmd_json
   Execute a command and read the output as JSON. The JSON  data  is  then
   directly overlaid onto the minion's Pillar data.

   salt.pillar.cmd_json.ext_pillar(minion_id, pillar, command)
          Execute a command and read the output as JSON

   salt.pillar.cmd_yaml
   Execute  a  command  and read the output as YAML. The YAML data is then
   directly overlaid onto the minion's Pillar data

   salt.pillar.cmd_yaml.ext_pillar(minion_id, pillar, command)
          Execute a command and read the output as YAML

   salt.pillar.cmd_yamlex
   Execute a command and read the output as YAMLEX.  The  YAMLEX  data  is
   then directly overlaid onto the minion's Pillar data

   salt.pillar.cmd_yamlex.ext_pillar(minion_id, pillar, command)
          Execute a command and read the output as YAMLEX

   salt.pillar.cobbler
   A  module  to  pull  data  from  Cobbler  via  its  API into the Pillar
   dictionary

   Configuring the Cobbler ext_pillar
   The same cobbler.* parameters are used for both the  Cobbler  tops  and
   Cobbler pillar modules.

      ext_pillar:
      - cobbler:
          key: cobbler # Nest results within this key. By default, values are not nested.
          only: [parameters] # Add only these keys to pillar.

      cobbler.url: https://example.com/cobbler_api #default is http://localhost/cobbler_api
      cobbler.user: username # default is no username
      cobbler.password: password # default is no password

   Module Documentation
   salt.pillar.cobbler.ext_pillar(minion_id, pillar, key=None, only=())
          Read pillar data from Cobbler via its API.

   salt.pillar.confidant
   An external pillar module for getting credentials from confidant.

   Configuring the Confidant module
   The module can be configured via ext_pillar in the minion config:

   ext_pillar:

          *

            confidant:

                   profile:
                          #  The  URL of the confidant web service url: '
                          https://confidant-production.example.com' #  The
                          context    to   use   for   KMS   authentication
                          auth_context: from:  example-production-iad  to:
                          confidant-production-iad  user_type:  service  #
                          The KMS master key  to  use  for  authentication
                          auth_key:  "alias/authnz"  #  Cache file for KMS
                          auth           token           token_cache_file:
                          /run/confidant/confidant_token # The duration of
                          the   validity   of   a   token,   in    minutes
                          token_duration:  60  # key, keyid and region can
                          be defined in the profile, but it's #  generally
                          best  to  use IAM roles or environment variables
                          for AWS # auth.  keyid: 98nh9h9h908h09kjjk  key:
                          jhf908gyeghehe0he0g8h9u0j0n0n09hj09h0    region:
                          us-east-1

   depends
          confidant-common, confidant-client

   Module Documentation
   salt.pillar.confidant.ext_pillar(minion_id, pillar, profile=None)
          Read pillar data from Confidant via its API.

   salt.pillar.consul_pillar module
   Use Consul K/V as a Pillar source with values parsed as YAML

   depends

          * python-consul

   In order to use an consul server, a profile  must  be  created  in  the
   master configuration file:

      my_consul_config:
        consul.host: 127.0.0.1
        consul.port: 8500
        consul.token: b6376760-a8bb-edd5-fcda-33bc13bfc556
        consul.scheme: http
        consul.consistency: default
        consul.dc: dev
        consul.verify: True

   All parameters are optional.

   The consul.token requires python-consul >= 0.4.7.

   If  you  have  a  multi-datacenter  Consul  cluster  you  can  map your
   pillarenv``s to your data centers by providing a dictionary of mappings
   in ``consul.dc field:

      my_consul_config:
        consul.dc:
          dev: us-east-1
          prod: us-west-1

   In  the  example  above  we  specifying  static  mapping between Pillar
   environments and data  centers:  the  data  for  dev  and  prod  Pillar
   environments  will  be  fetched from us-east-1 and us-west-1 datacenter
   respectively.

   In fact when consul.dc is set  to  dictionary  keys  are  processed  as
   regular  expressions (that can capture named parameters) and values are
   processed as string templates as per PEP 3101.

      my_consul_config:
        consul.dc:
          ^dev-.*$: dev-datacenter
          ^(?P<region>.*)-prod$: prod-datacenter-{region}

   This example  maps  all  Pillar  environments  starting  with  dev-  to
   dev-datacenter  whereas  Pillar environment like eu-prod will be mapped
   to prod-datacenter-eu.

   Before evaluation patterns are sorted by length in descending order.

   If Pillar environment names correspond to data center  names  a  single
   pattern can be used:

      my_consul_config:
        consul.dc:
          ^(?P<env>.*)$: '{env}'

   After  the  profile is created, configure the external pillar system to
   use it.  Optionally, a root may be specified.

      ext_pillar:
        - consul: my_consul_config

      ext_pillar:
        - consul: my_consul_config root=/salt

   Using these configuration profiles, multiple consul sources may also be
   used:

      ext_pillar:
        - consul: my_consul_config
        - consul: my_other_consul_config

   Either  the  minion_id,  or  the role, or the environment grain  may be
   used in the root path to expose minion-specific information  stored  in
   consul.

      ext_pillar:
        - consul: my_consul_config root=/salt/%(minion_id)s
        - consul: my_consul_config root=/salt/%(role)s
        - consul: my_consul_config root=/salt/%(environment)s

   Minion-specific   values   may   override   shared   values   when  the
   minion-specific root appears after the shared root:

      ext_pillar:
        - consul: my_consul_config root=/salt-shared
        - consul: my_other_consul_config root=/salt-private/%(minion_id)s

   If using the role or environment grain in the consul key path, be  sure
   to define it using /etc/salt/grains, or similar:

      role: my-minion-role
      environment: dev

   It's  possible  to lock down where the pillar values are shared through
   minion targeting. Note that double quotes "  are  required  around  the
   target  value and cannot be used inside the matching statement. See the
   section on Compound Matchers for more examples.

      ext_pillar:
        - consul: my_consul_config root=salt target="[email protected] and G@osarch:x86_64"

   salt.pillar.consul_pillar.consul_fetch(client, path)
          Query consul for all keys/values within base path

   salt.pillar.consul_pillar.ext_pillar(minion_id, pillar, conf)
          Check consul for all data

   salt.pillar.consul_pillar.fetch_tree(client, path)
          Grab data from consul, trim base path and remove any keys  which
          are folders. Take the remaining data and send it to be formatted
          in such a way as to be used as pillar data.

   salt.pillar.consul_pillar.get_conn(opts, profile)
          Return a client object for accessing consul

   salt.pillar.consul_pillar.pillar_format(ret, keys, value)
          Perform data formatting to be used as pillar data and  merge  it
          with the current pillar data

   salt.pillar.django_orm
   Generate Pillar data from Django models through the Django ORM

   maintainer
          Micah Hausler <[email protected]>

   maturity
          new

   Configuring the django_orm ext_pillar
   To  use  this  module,  your  Django project must be on the salt master
   server with database access. This assumes you are using virtualenv with
   all the project's requirements installed.

      ext_pillar:
        - django_orm:
            pillar_name: my_application
            project_path: /path/to/project/
            settings_module: my_application.settings
            env_file: /path/to/env/file.sh
            # Optional: If your project is not using the system python,
            # add your virtualenv path below.
            env: /path/to/virtualenv/

            django_app:

              # Required: the app that is included in INSTALLED_APPS
              my_application.clients:

                # Required: the model name
                Client:

                  # Required: model field to use as the key in the rendered
                  # Pillar. Must be unique; must also be included in the
                  # ``fields`` list below.
                  name: shortname

                  # Optional:
                  # See Django's QuerySet documentation for how to use .filter()
                  filter:  {'kw': 'args'}

                  # Required: a list of field names
                  # List items will be used as arguments to the .values() method.
                  # See Django's QuerySet documentation for how to use .values()
                  fields:
                    - field_1
                    - field_2

   This would return pillar data that would look like

      my_application:
        my_application.clients:
          Client:
            client_1:
              field_1: data_from_field_1
              field_2: data_from_field_2
            client_2:
              field_1: data_from_field_1
              field_2: data_from_field_2

   As  another  example, data from multiple database tables can be fetched
   using Django's regular lookup syntax. Note, using ManyToManyFields will
   not  currently  work  since  the  return  from  values()  changes  if a
   ManyToMany is present.

      ext_pillar:
        - django_orm:
            pillar_name: djangotutorial
            project_path: /path/to/mysite
            settings_module: mysite.settings

            django_app:
              mysite.polls:
                Choices:
                  name: poll__question
                  fields:
                    - poll__question
                    - poll__id
                    - choice_text
                    - votes

   Module Documentation
   salt.pillar.django_orm.ext_pillar(minion_id,    pillar,    pillar_name,
   project_path,  settings_module,  django_app,  env=None,  env_file=None,
   *args, **kwargs)
          Connect to a Django database through the ORM and retrieve  model
          fields

          Parameters

                 * pillar_name  (str)  --  The  name  of  the pillar to be
                   returned

                 * project_path (str) -- The  full  path  to  your  Django
                   project (the directory manage.py is in)

                 * settings_module  (str)  -- The settings module for your
                   project. This can be found in your manage.py file

                 * django_app (str) -- A dictionary containing your  apps,
                   models, and fields

                 * env  (str)  -- The full path to the virtualenv for your
                   Django project

                 * env_file (str) -- An optional bash file  that  sets  up
                   your  environment.  The file is run in a subprocess and
                   the changed variables are then added

   salt.pillar.ec2_pillar
   Retrieve EC2 instance data for minions.

   The minion id must be  the  instance-id  retrieved  from  AWS.   As  an
   option,  use_grain  can  be  set  to  True.   This allows the use of an
   instance-id grain instead of the minion-id.  Since this is a  potential
   security  risk,  the configuration can be further expanded to include a
   list of minions that are trusted to only allow the alternate id of  the
   instances to specific hosts.  There is no glob matching at this time.

      ext_pillar:
        - ec2_pillar:
            use_grain: True
            minion_ids:
              - trusted-minion-1
              - trusted-minion-2
              - trusted-minion-3

   This  is  a  very simple pillar that simply retrieves the instance data
   from AWS.  Currently the only portion implemented are EC2  tags,  which
   returns  a  list of key/value pairs for all of the EC2 tags assigned to
   the instance.

   salt.pillar.ec2_pillar.ext_pillar(minion_id,  pillar,  use_grain=False,
   minion_ids=None)
          Execute a command and read the output as YAML

   salt.pillar.etcd_pillar
   Use etcd data as a Pillar source

   New in version 2014.7.0.

   depends

          * python-etcd

   In order to use an etcd server, a profile must be created in the master
   configuration file:

      my_etcd_config:
        etcd.host: 127.0.0.1
        etcd.port: 4001

   After the profile is created, configure the external pillar  system  to
   use it.  Optionally, a root may be specified.

      ext_pillar:
        - etcd: my_etcd_config

      ext_pillar:
        - etcd: my_etcd_config root=/salt

   Using  these  configuration profiles, multiple etcd sources may also be
   used:

      ext_pillar:
        - etcd: my_etcd_config
        - etcd: my_other_etcd_config

   The minion_id may be used in the root path  to  expose  minion-specific
   information stored in etcd.

      ext_pillar:
        - etcd: my_etcd_config root=/salt/%(minion_id)s

   Minion-specific   values   may   override   shared   values   when  the
   minion-specific root appears after the shared root:

      ext_pillar:
        - etcd: my_etcd_config root=/salt-shared
        - etcd: my_other_etcd_config root=/salt-private/%(minion_id)s

   Using the configuration above, the following commands could be used  to
   share  a  key  with  all  minions but override its value for a specific
   minion:

      etcdctl set /salt-shared/mykey my_value
      etcdctl set /salt-private/special_minion_id/mykey my_other_value

   salt.pillar.etcd_pillar.ext_pillar(minion_id, pillar, conf)
          Check etcd for all data

   salt.pillar.file_tree
   Recursively iterate over directories and add all files as Pillar data

   New in version 2015.5.0.

   Example Configuration
      ext_pillar:
        - file_tree:
            root_dir: /path/to/root/directory
            follow_dir_links: False
            keep_newline: True

   The root_dir parameter is required and points to  the  directory  where
   files  for  each  host  are  stored.  The follow_dir_links parameter is
   optional and defaults to False. If follow_dir_links  is  set  to  True,
   this external pillar will follow symbolic links to other directories.

   WARNING:
      Be careful when using follow_dir_links, as a recursive symlink chain
      will result in unexpected results.

   If keep_newline is set to True, then the pillar values for files ending
   in  newlines  will keep that newline. The default behavior is to remove
   the end-of-file newline. keep_newline should be turned on if the pillar
   data is intended to be used to deploy a file using contents_pillar with
   a file.managed state.

   Changed in version 2015.8.4: The raw_data parameter has been renamed to
   keep_newline.  In  earlier  releases, raw_data must be used. Also, this
   parameter can now be a  list  of  globs,  allowing  for  more  granular
   control  over  which  pillar values keep their end-of-file newline. The
   globs match paths relative to the directories named for minion IDs  and
   nodegroups  underneath  the  root_dir  (see  the layout examples in the
   below sections).

      ext_pillar:
        - file_tree:
            root_dir: /path/to/root/directory
            keep_newline:
              - files/testdir/*

   NOTE:
      In earlier releases,  this  documentation  incorrectly  stated  that
      binary  files  would not affected by the keep_newline configuration.
      However, this module does not actually  distinguish  between  binary
      and text files.

   Assigning Pillar Data to Individual Hosts
   To  configure  pillar  data  for  each  host, this external pillar will
   recursively iterate over root_dir/hosts/id (where id is a  minion  ID),
   and  compile pillar data with each subdirectory as a dictionary key and
   each file as a value.

   For example, the following root_dir tree:

      ./hosts/
      ./hosts/test-host/
      ./hosts/test-host/files/
      ./hosts/test-host/files/testdir/
      ./hosts/test-host/files/testdir/file1.txt
      ./hosts/test-host/files/testdir/file2.txt
      ./hosts/test-host/files/another-testdir/
      ./hosts/test-host/files/another-testdir/symlink-to-file1.txt

   will result in the following pillar tree for minion with ID test-host:

      test-host:
          ----------
          files:
              ----------
              another-testdir:
                  ----------
                  symlink-to-file1.txt:
                      Contents of file #1.

              testdir:
                  ----------
                  file1.txt:
                      Contents of file #1.

                  file2.txt:
                      Contents of file #2.

   NOTE:
      Subdirectories   underneath    root_dir/hosts/id    become    nested
      dictionaries, as shown above.

   Assigning Pillar Data to Entire Nodegroups
   To  assign  Pillar  data  to  all  minions  in  a given nodegroup, this
   external pillar recursively iterates over root_dir/nodegroups/nodegroup
   (where  nodegroup  is the name of a nodegroup), and like for individual
   hosts, compiles pillar data with each subdirectory as a dictionary  key
   and each file as a value.

   IMPORTANT:
      If  the same Pillar key is set for a minion both by nodegroup and by
      individual host, then the value set for  the  individual  host  will
      take precedence.

   For example, the following root_dir tree:

      ./nodegroups/
      ./nodegroups/test-group/
      ./nodegroups/test-group/files/
      ./nodegroups/test-group/files/testdir/
      ./nodegroups/test-group/files/testdir/file1.txt
      ./nodegroups/test-group/files/testdir/file2.txt
      ./nodegroups/test-group/files/another-testdir/
      ./nodegroups/test-group/files/another-testdir/symlink-to-file1.txt

   will  result in the following pillar data for minions in the node group
   test-group:

      test-host:
          ----------
          files:
              ----------
              another-testdir:
                  ----------
                  symlink-to-file1.txt:
                      Contents of file #1.

              testdir:
                  ----------
                  file1.txt:
                      Contents of file #1.

                  file2.txt:
                      Contents of file #2.

   salt.pillar.file_tree.ext_pillar(minion_id,   pillar,    root_dir=None,
   follow_dir_links=False, debug=False, raw_data=None, keep_newline=False)
          Compile pillar data for the specified minion ID

   salt.pillar.foreman
   A  module  to  pull  data  from  Foreman  via  its  API into the Pillar
   dictionary

   Configuring the Foreman ext_pillar
   Set the following Salt config  to  setup  Foreman  as  external  pillar
   source:

      ext_pillar:
        - foreman:
            key: foreman # Nest results within this key
            only: ['hostgroup_name', 'parameters'] # Add only these keys to pillar

      foreman.url: https://example.com/foreman_api
      foreman.user: username # default is admin
      foreman.password: password # default is changeme

   The following options are optional:

      foreman.api: apiversion # default is 2 (1 is not supported yet)
      foreman.verifyssl: False # default is True
      foreman.certfile: /etc/ssl/certs/mycert.pem # default is None
      foreman.keyfile: /etc/ssl/private/mykey.pem # default is None
      foreman.cafile: /etc/ssl/certs/mycert.ca.pem # default is None
      foreman.lookup_parameters: True # default is True

   An  alternative  would  be  to use the Foreman modules integrating Salt
   features in the Smart Proxy and the webinterface.

   Further information can be found on GitHub.

   Module Documentation
   salt.pillar.foreman.ext_pillar(minion_id, pillar, key=None, only=())
          Read pillar data from Foreman via its API.

   salt.pillar.git_pillar
   Use a git repository as a Pillar source
   NOTE:
      This external pillar has been rewritten for  the  2015.8.0  release.
      The   old  method  of  configuring  this  external  pillar  will  be
      maintained for a couple releases, allowing time  for  configurations
      to be updated to reflect the new usage.

   This  external pillar allows for a Pillar top file and Pillar SLS files
   to be sourced from a git repository.

   However,  since  git_pillar  does  not  have  an  equivalent   to   the
   pillar_roots  parameter,  configuration is slightly different. A Pillar
   top file is required to be in the git repository and must still contain
   the relevant environment, like so:

      base:
        '*':
          - foo

   The  branch/tag  which  maps to that environment must then be specified
   along with the repo's URL. Configuration details can be found below.

   IMPORTANT:
      Each branch/tag used for git_pillar must have its own top file. This
      is  different  from  how the top file works when configuring States.
      The reason for this is that each git_pillar branch/tag is  processed
      separately  from the rest. Therefore, if the qa branch is to be used
      for git_pillar, it would need to have its own top file, with the  qa
      environment defined within it, like this:

          qa:
            'dev-*':
              - bar

      Additionally,  while  git_pillar  allows  for  the  branch/tag to be
      overridden (see here, or here for Salt  releases  before  2015.8.0),
      keep in mind that the top file must reference the actual environment
      name. It is common practice to make the environment in a  git_pillar
      top  file  match  the  branch/tag  name,  but  when  remapping,  the
      environment of course no longer matches the branch/tag, and the  top
      file  needs to be adjusted accordingly.  When expected Pillar values
      configured  in  git_pillar   are   missing,   this   is   a   common
      misconfiguration  that  may be to blame, and is a good first step in
      troubleshooting.

   Configuring git_pillar for Salt releases before 2015.8.0
   For  Salt  releases  earlier  than  2015.8.0,  GitPython  is  the  only
   supported  provider  for  git_pillar.  Individual  repositories  can be
   configured under the ext_pillar configuration parameter like so:

      ext_pillar:
        - git: master https://gitserver/git-pillar.git root=subdirectory

   The repository is specified in the format <branch> <repo_url>, with  an
   optional  root  parameter  (added in the 2014.7.0 release) which allows
   the pillar SLS files to be served up from a  subdirectory  (similar  to
   gitfs_root in gitfs).

   To  use more than one branch from the same repo, multiple lines must be
   specified under ext_pillar:

      ext_pillar:
        - git: master https://gitserver/git-pillar.git
        - git: dev https://gitserver/git-pillar.git

   To remap a specific branch to a specific Pillar  environment,  use  the
   format <branch>:<env>:

      ext_pillar:
        - git: develop:dev https://gitserver/git-pillar.git
        - git: master:prod https://gitserver/git-pillar.git

   In  this case, the develop branch would need its own top.sls with a dev
   section in it, like this:

      dev:
        '*':
          - bar

   The master branch would need its own top.sls with a prod section in it:

      prod:
        '*':
          - bar

   If __env__ is specified as the branch name, then git_pillar will  first
   look at the minion's environment option. If unset, it will fall back to
   using branch specified by the master's gitfs_base:

      ext_pillar:
        - git: __env__ https://gitserver/git-pillar.git root=pillar

   The corresponding Pillar top file would look like this:

      {{env}}:
        '*':
          - bar

   NOTE:
      This  feature  was  unintentionally  omitted  when  git_pillar   was
      rewritten  for  the  2015.8.0  release.  It  was  added again in the
      2016.3.4 release, but it has changed slightly in  that  release.  On
      Salt  masters  running  2015.8.0  through 2016.3.3, this feature can
      only be accessed  using  the  legacy  config  described  above.  For
      2016.3.4 and later, refer to explanation of the __env__ parameter in
      the below section.

      Versions 2016.3.0 through 2016.3.4 incorrectly  check  the  master's
      environment  config  option (instead of the minion's) before falling
      back to  gitfs_base.  This  has  been  fixed  in  the  2016.3.5  and
      2016.11.1 releases (2016.11.0 contains the incorrect behavior).

   Configuring git_pillar for Salt releases 2015.8.0 and later
   NOTE:
      In  version 2015.8.0, the method of configuring git external pillars
      has changed,  and  now  more  closely  resembles  that  of  the  Git
      Fileserver Backend. If Salt detects the old configuration schema, it
      will use the pre-2015.8.0 code to compile  the  external  pillar.  A
      warning will also be logged.

   Beginning  with  Salt  version  2015.8.0,  pygit2  is  now supported in
   addition  to  GitPython  (Dulwich  will  not  be  supported   for   the
   foreseeable  future). The requirements for GitPython and pygit2 are the
   same as for gitfs, as described here.

   IMPORTANT:
      git_pillar has its own set of global configuration parameters. While
      it  may  seem  intuitive  to  use  the  global  gitfs  configuration
      parameters (gitfs_base, etc.) to manage git_pillar,  this  will  not
      work.   The  main difference for this is the fact that the different
      components which use Salt's git backend code  do  not  all  function
      identically.  For instance, in git_pillar it is necessary to specify
      which branch/tag to be used for  git_pillar  remotes.  This  is  the
      reverse  behavior  from  gitfs,  where  branches/tags  make  up your
      environments.

      See here for documentation on the git_pillar  configuration  options
      and their usage.

   Here is an example git_pillar configuration:

      ext_pillar:
        - git:
          # Use 'prod' instead of the branch name 'production' as the environment
          - production https://gitserver/git-pillar.git:
            - env: prod
          # Use 'dev' instead of the branch name 'develop' as the environment
          - develop https://gitserver/git-pillar.git:
            - env: dev
          # No per-remote config parameters (and no trailing colon), 'qa' will
          # be used as the environment
          - qa https://gitserver/git-pillar.git
          # SSH key authentication
          - master git@other-git-server:pillardata-ssh.git:
            # Pillar SLS files will be read from the 'pillar' subdirectory in
            # this repository
            - root: pillar
            - privkey: /path/to/key
            - pubkey: /path/to/key.pub
            - passphrase: CorrectHorseBatteryStaple
          # HTTPS authentication
          - master https://other-git-server/pillardata-https.git:
            - user: git
            - password: CorrectHorseBatteryStaple

   The  main  difference  between  this  and  the  old  way of configuring
   git_pillar is that multiple remotes can be  configured  under  one  git
   section under ext_pillar. More than one git section can be used, but it
   is not necessary. Remotes will be evaluated sequentially.

   Per-remote configuration parameters are supported (similar  to  gitfs),
   and global versions of the git_pillar configuration parameters can also
   be set.

   To remap a specific branch to a specific Pillar  environment,  use  the
   env per-remote parameter:

      ext_pillar:
        - git:
          - production https://gitserver/git-pillar.git:
            - env: prod

   If  __env__  is  specified as the branch name, then git_pillar will use
   the branch specified by git_pillar_base:

      ext_pillar:
        - git:
          - __env__ https://gitserver/git-pillar.git:
            - root: pillar

   The corresponding Pillar top file would look like this:

      {{env}}:
        '*':
          - bar

   NOTE:
      This  feature  was  unintentionally  omitted  when  git_pillar   was
      rewritten  for  the  2015.8.0  release.  It  was  added again in the
      2016.3.4 release, but it has changed slightly in that  release.  The
      fallback   value   replaced   by   {{env}}   is   :conf_master:   is
      git_pillar_base, while the legacy config's version of  this  feature
      replaces {{env}} with gitfs_base.

      On  Salt masters running 2015.8.0 through 2016.3.3, this feature can
      only be accessed using the legacy config in the previous section  of
      this page.

      The   same  issue  which  affected  the  behavior  of  the  minion's
      environment config value using the legacy configuration syntax  (see
      the  documentation  in the pre-2015.8.0 section above for the legacy
      support of this  feature)  also  affects  the  new-style  git_pillar
      syntax  in  version  2016.3.4.  This  has  been corrected in version
      2016.3.5 and 2016.11.1 (2016.11.0 contains the incorrect behavior).

      2016.3.4 incorrectly checks the master's environment  config  option
      (instead  of  the  minion's)  before  falling  back  to the master's
      git_pillar_base.

   With the addition of pygit2 support, git_pillar can now  interact  with
   authenticated  remotes.  Authentication  works  just  like in gitfs (as
   outlined in the Git Fileserver  Backend  Walkthrough),  only  with  the
   global  authenication  parameter names prefixed with git_pillar instead
   of     gitfs     (e.g.      git_pillar_pubkey,      git_pillar_privkey,
   git_pillar_passphrase, etc.).

   NOTE:
      The  name parameter can be used to further differentiate between two
      remotes with the same URL and branch. When using  two  remotes  with
      the same URL, the name option is required.

   salt.pillar.git_pillar.ext_pillar(minion_id, repo, pillar_dirs)
          Checkout the ext_pillar sources and compile the resulting pillar
          SLS

   salt.pillar.hg_pillar
   Use remote Mercurial repository as a Pillar source.

   New in version 2015.8.0.

   The module depends on the hglib python module being available.  This is
   the same requirement as for hgfs_ so should not pose any extra hurdles.

   This external Pillar source can be configured in the master config file
   as such:

      ext_pillar:
        - hg: ssh://[email protected]/user/repo

   class salt.pillar.hg_pillar.Repo(repo_uri)
          Deal with remote hg (mercurial) repository for Pillar

          close()
                 Cleanup mercurial command server

          update(branch='default')
                 Ensure we  are  using  the  latest  revision  in  the  hg
                 repository

   salt.pillar.hg_pillar.ext_pillar(minion_id,        pillar,        repo,
   branch='default', root=None)
          Extract pillar from an hg repository

   salt.pillar.hg_pillar.update(repo_uri)
          Execute an hg pull on all the repos

   salt.pillar.hiera
   Use hiera data as a Pillar source

   salt.pillar.hiera.ext_pillar(minion_id, pillar, conf)
          Execute hiera and return the data

   salt.pillar.http_yaml module
   A module that adds data to the Pillar structure retrieved  by  an  http
   request

   Configuring the HTTP_YAML ext_pillar
   Set the following Salt config to setup an http endpoint as the external
   pillar source:

      ext_pillar:
        - http_yaml:
            url: http://example.com/api/minion_id
            ::TODO::
            username: username
            password: password

   Module Documentation
   salt.pillar.http_yaml.ext_pillar(minion_id, pillar, url)
          Read pillar data from HTTP response.

          :param url String to make request :returns dict with pillar data
          to add :returns empty if error

   salt.pillar.libvirt
   Load  up  the  libvirt keys into Pillar for a given minion if said keys
   have been generated using the libvirt key runner

   depends
          certtool

   salt.pillar.libvirt.ext_pillar(minion_id, pillar, command)
          Read in the generated libvirt keys

   salt.pillar.libvirt.gen_hyper_keys(minion_id,             country='US',
   state='Utah', locality='Salt Lake City', organization='Salted')
          Generate  the  keys  to  be  used  by  libvirt hypervisors, this
          routine gens the keys and applies them to  the  pillar  for  the
          hypervisor minions

   salt.pillar.mongo
   Read Pillar data from a mongodb collection

   depends
          pymongo (for salt-master)

   This  module  will  load a node-specific pillar dictionary from a mongo
   collection. It uses the node's id for lookups and can load  either  the
   whole  document,  or  just  a  specific field from that document as the
   pillar dictionary.

   Salt Master Mongo Configuration
   The  module  shares  the  same  base  mongo  connection  variables   as
   salt.returners.mongo_return.  These  variables go in your master config
   file.

      * mongo.db - The mongo database to connect to. Defaults to 'salt'.

      * mongo.host - The mongo host to connect to. Supports  replica  sets
        by  specifying  all hosts in the set, comma-delimited. Defaults to
        'salt'.

      * mongo.port - The port that  the  mongo  database  is  running  on.
        Defaults to 27017.

      * mongo.user  -  The username for connecting to mongo. Only required
        if you are using mongo authentication. Defaults to ''.

      * mongo.password -  The  password  for  connecting  to  mongo.  Only
        required if you are using mongo authentication. Defaults to ''.

   Configuring the Mongo ext_pillar
   The  Mongo  ext_pillar takes advantage of the fact that the Salt Master
   configuration file is yaml. It  uses  a  sub-dictionary  of  values  to
   adjust   specific   features  of  the  pillar.  This  is  the  explicit
   single-line dictionary notation for yaml. One may be able  to  get  the
   easier-to-read   multi-line   dict   to   work   correctly   with  some
   experimentation.

      ext_pillar:
        - mongo: {collection: vm, id_field: name, re_pattern: \.example\.com, fields: [customer_id, software, apache_vhosts]}

   In the example above, we've decided to use the  vm  collection  in  the
   database  to store the data. Minion ids are stored in the name field on
   documents in that collection. And, since minion ids are FQDNs  in  most
   cases,  we'll  need to trim the domain name in order to find the minion
   by hostname in the collection. When we find a minion, return  only  the
   customer_id,  software,  and apache_vhosts fields, as that will contain
   the data we want for a given node.  They  will  be  available  directly
   inside the pillar dict in your SLS templates.

   Module Documentation
   salt.pillar.mongo.ext_pillar(minion_id,   pillar,  collection='pillar',
   id_field='_id', re_pattern=None, re_replace='', fields=None)
          Connect  to  a  mongo  database   and   read   per-node   pillar
          information.

          Parameters

                 * collection  (*)  -- The mongodb collection to read data
                   from. Defaults to 'pillar'.

                 * id_field (*)  --  The  field  in  the  collection  that
                   represents an individual minion id. Defaults to '_id'.

                 * re_pattern  (*)  --  If  your  naming convention in the
                   collection is shorter than the minion id, you  can  use
                   this  to  trim  the  name.   re_pattern will be used to
                   match the name, and re_replace will be used to  replace
                   it.  Backrefs  are  supported as they are in the Python
                   standard library. If None, no mangling of the name will
                   be performed - the collection will be searched with the
                   entire minion id. Defaults to None.

                 * re_replace (*) -- Use as the replacement value in  node
                   ids  matched with re_pattern. Defaults to ''. Feel free
                   to use backreferences here.

                 * fields (*) -- The specific fields in  the  document  to
                   use  for  the pillar data. If None, will use the entire
                   document. If using the entire document, the  _id  field
                   will  be  converted  to  string.  Be careful with other
                   fields  in  the  document  as  they  must   be   string
                   serializable. Defaults to None.

   salt.pillar.mysql
   Retrieve Pillar data by doing a MySQL query

   MariaDB  provides  Python  support  through  the  MySQL Python package.
   Therefore, you may use this module with both MySQL or MariaDB.

   This module is a concrete implementation of the sql_base ext_pillar for
   MySQL.

   maturity
          new

   depends
          python-mysqldb

   platform
          all

   Configuring the mysql ext_pillar
   Use the 'mysql' key under ext_pillar for configuration of queries.

   MySQL  configuration  of  the  MySQL  returner is being used (mysql.db,
   mysql.user, mysql.pass, mysql.port, mysql.host) for database connection
   info.

   Required python modules: MySQLdb

   Complete example
      mysql:
        user: 'salt'
        pass: 'super_secret_password'
        db: 'salt_db'

      ext_pillar:
        - mysql:
            fromdb:
              query: 'SELECT col1,col2,col3,col4,col5,col6,col7
                        FROM some_random_table
                       WHERE minion_pattern LIKE %s'
              depth: 5
              as_list: True
              with_lists: [1,3]

   class salt.pillar.mysql.MySQLExtPillar
          This class receives and processes the database rows from MySQL.

          extract_queries(args, kwargs)
                 This  function  normalizes the config block into a set of
                 queries we can use.  The return is a list of consistently
                 laid out dicts.

   salt.pillar.mysql.ext_pillar(minion_id, pillar, *args, **kwargs)
          Execute queries against MySQL, merge and return as a dict

   salt.pillar.neutron module
   Use  Openstack  Neutron data as a Pillar source. Will list all networks
   listed inside of Neutron, to all minions.

   New in version 2015.5.1.

   depends

          * python-neutronclient

   A keystone profile must be used for the  pillar  to  work  (no  generic
   keystone configuration here). For example:

      my openstack_config:
        keystone.user: 'admin'
        keystone.password: 'password'
        keystone.tenant: 'admin'
        keystone.auth_url: 'http://127.0.0.1:5000/v2.0/'
        keystone.region_name: 'RegionOne'
        keystone.service_type: 'network'

   After  the  profile is created, configure the external pillar system to
   use it.

      ext_pillar:
        - neutron: my_openstack_config

   Using these configuration profiles, multiple neutron sources  may  also
   be used:

      ext_pillar:
        - neutron: my_openstack_config
        - neutron: my_other_openstack_config

   By  default,  these  networks  will be returned as a pillar item called
   networks. In order to have them returned under a  different  name,  add
   the name after the Keystone profile name:

      ext_pillar:

             * neutron: my_openstack_config neutron_networks

   salt.pillar.neutron.ext_pillar(minion_id, pillar, conf)
          Check neutron for all data

   salt.pillar.nodegroups
   Nodegroups Pillar
   Introspection:  to  which nodegroups does my minion belong?  Provides a
   pillar with the default name of nodegroups which  contains  a  list  of
   nodegroups which match for a given minion.

   New in version 2016.11.0.

   Command Line
   Configuring Nodegroups Pillar
      extension_modules: /srv/salt/ext
      ext_pillar:
        - nodegroups:
            pillar_name: 'nodegroups'

   salt.pillar.nodegroups.ext_pillar(minion_id, pillar, pillar_name=None)
          A  salt external pillar which provides the list of nodegroups of
          which the minion is a memeber.

          Parameters

                 * minion_id  --  provided  by  salt,  but  not  used   by
                   nodegroups ext_pillar

                 * pillar  -- provided by salt, but not used by nodegroups
                   ext_pillar

                 * pillar_name -- optional name to  use  for  the  pillar,
                   defaults to 'nodegroups'

          Returns
                 a  dictionary which is included by the salt master in the
                 pillars returned to the minion

   salt.pillar.pepa
   Pepa
   Configuration templating for SaltStack using Hierarchical  substitution
   and Jinja.

   Configuring Pepa
      extension_modules: /srv/salt/ext

      ext_pillar:
        - pepa:
            resource: host                # Name of resource directory and sub-key in pillars
            sequence:                     # Sequence used for hierarchical substitution
              - hostname:                 # Name of key
                  name: input             # Alias used for template directory
                  base_only: True         # Only use templates from Base environment, i.e. no staging
              - default:
              - environment:
              - location..region:
                  name: region
              - location..country:
                  name: country
              - location..datacenter:
                  name: datacenter
              - roles:
              - osfinger:
                  name: os
              - hostname:
                  name: override
                  base_only: True
            subkey: True                  # Create a sub-key in pillars, named after the resource in this case [host]
            subkey_only: True             # Only create a sub-key, and leave the top level untouched

      pepa_roots:                         # Base directory for each environment
        base: /srv/pepa/base              # Path for base environment
        dev: /srv/pepa/base               # Associate dev with base
        qa: /srv/pepa/qa
        prod: /srv/pepa/prod

      # Use a different delimiter for nested dictionaries, defaults to '..' since some keys may use '.' in the name
      #pepa_delimiter: ..

      # Supply Grains for Pepa, this should **ONLY** be used for testing or validation
      #pepa_grains:
      #  environment: dev

      # Supply Pillar for Pepa, this should **ONLY** be used for testing or validation
      #pepa_pillars:
      #  saltversion: 0.17.4

      # Enable debug for Pepa, and keep Salt on warning
      #log_level: debug

      #log_granular_levels:
      #  salt: warning
      #  salt.loaded.ext.pillar.pepa: debug

   Pepa can also be used in Master-less SaltStack setup.

   Command line
      usage: pepa.py [-h] [-c CONFIG] [-d] [-g GRAINS] [-p PILLAR] [-n] [-v]
                     hostname

      positional arguments:
        hostname              Hostname

      optional arguments:
        -h, --help            show this help message and exit
        -c CONFIG, --config CONFIG
                              Configuration file
        -d, --debug           Print debug info
        -g GRAINS, --grains GRAINS
                              Input Grains as YAML
        -p PILLAR, --pillar PILLAR
                              Input Pillar as YAML
        -n, --no-color        No color output
        -v, --validate        Validate output

   Templates
   Templates  is  configuration  for  a  host  or  software,  that can use
   information from  Grains  or  Pillars.  These  can  then  be  used  for
   hierarchically substitution.

   Example File: host/input/test_example_com.yaml

      location..region: emea
      location..country: nl
      location..datacenter: foobar
      environment: dev
      roles:
        - salt.master
      network..gateway: 10.0.0.254
      network..interfaces..eth0..hwaddr: 00:20:26:a1:12:12
      network..interfaces..eth0..dhcp: False
      network..interfaces..eth0..ipv4: 10.0.0.3
      network..interfaces..eth0..netmask: 255.255.255.0
      network..interfaces..eth0..fqdn: {{ hostname }}
      cobbler..profile: fedora-19-x86_64

   As  you  see  in  this  example  you  can use Jinja directly inside the
   template.

   Example File: host/region/amer.yaml

      network..dns..servers:
        - 10.0.0.1
        - 10.0.0.2
      time..ntp..servers:
        - ntp1.amer.example.com
        - ntp2.amer.example.com
        - ntp3.amer.example.com
      time..timezone: America/Chihuahua
      yum..mirror: yum.amer.example.com

   Each template is named after the value of the key using  lowercase  and
   all extended characters are replaced with underscore.

   Example:

   osfinger: Fedora-19

   Would become:

   fedora_19.yaml

   Nested dictionaries
   In order to create nested dictionaries as output you can use double dot
   ".." as a delimiter. You can  change  this  using  "pepa_delimiter"  we
   choose double dot since single dot is already used by key names in some
   modules, and using ":" requires quoting in the YAML.

   Example:

      network..dns..servers:
        - 10.0.0.1
        - 10.0.0.2
      network..dns..options:
        - timeout:2
        - attempts:1
        - ndots:1
      network..dns..search:
        - example.com

   Would become:

      network:
        dns:
          servers:
            - 10.0.0.1
            - 10.0.0.2
          options:
            - timeout:2
            - attempts:1
            - ndots:1
          search:
            - example.com

   Operators
   Operators can be used to merge/unset a list/hash  or  set  the  key  as
   immutable, so it can't be changed.

                 
                 Operator     Description                
                 
                 merge()      Merge list or hash         
                 
                 unset()      Unset key                  
                 
                 immutable()  Set  the key as immutable, 
                              so it can't be changed     
                 
                 imerge()     Set immutable and merge    
                 
                 iunset()     Set immutable and unset    
                 

   Example:

      network..dns..search..merge():
        - foobar.com
        - dummy.nl
      owner..immutable(): Operations
      host..printers..unset():

   Validation
   Since it's very hard to test Jinja as is, the best approach is  to  run
   all  the  permutations  of  input  and  validate  the output, i.e. Unit
   Testing.

   To facilitate  this  in  Pepa  we  use  YAML,  Jinja  and  Cerberus  <
   https://github.com/nicolaiarocci/cerberus>.

   Schema
   So this is a validation schema for network configuration, as you see it
   can be customized with Jinja just as Pepa templates.

   This was designed to be run as a build job in Jenkins or similar  tool.
   You  can  provide  Grains/Pillar  input using either the config file or
   command line arguments.

   File Example: host/validation/network.yaml

      network..dns..search:
        type: list
        allowed:
          - example.com

      network..dns..options:
        type: list
        allowed: ['timeout:2', 'attempts:1', 'ndots:1']

      network..dns..servers:
        type: list
        schema:
          regex: ^([0-9]{1,3}\.){3}[0-9]{1,3}$

      network..gateway:
        type: string
        regex: ^([0-9]{1,3}\.){3}[0-9]{1,3}$

      {% if network.interfaces is defined %}
      {% for interface in network.interfaces %}

      network..interfaces..{{ interface }}..dhcp:
        type: boolean

      network..interfaces..{{ interface }}..fqdn:
        type: string
        regex: ^([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\.)+[a-zA-Z]{2,6}$

      network..interfaces..{{ interface }}..hwaddr:
        type: string
        regex: ^([0-9a-f]{1,2}\:){5}[0-9a-f]{1,2}$

      network..interfaces..{{ interface }}..ipv4:
        type: string
        regex: ^([0-9]{1,3}\.){3}[0-9]{1,3}$

      network..interfaces..{{ interface }}..netmask:
        type: string
        regex: ^([0-9]{1,3}\.){3}[0-9]{1,3}$

      {% endfor %}
      {% endif %}

   Links
   For      more      examples      and      information      see       <
   https://github.com/mickep76/pepa>.

   salt.pillar.pepa.ext_pillar(minion_id,   pillar,   resource,  sequence,
   subkey=False, subkey_only=False)
          Evaluate Pepa templates

   salt.pillar.pepa.key_value_to_tree(data)
          Convert key/value to tree

   salt.pillar.pepa.validate(output, resource)
          Validate Pepa templates

   salt.pillar.pillar_ldap
   Use LDAP data as a Pillar source

   This pillar module executes a series of LDAP searches.   Data  returned
   by  these  searches  are  aggregated,  whereby  data  returned by later
   searches override data by previous searches with the same key.

   The final result is merged with existing pillar data.

   The configuration of  this  external  pillar  module  is  done  via  an
   external  file  which  provides  the  actual configuration for the LDAP
   searches.

   Configuring the LDAP ext_pillar
   The basic configuration is part of the master configuration.

      ext_pillar:
        - pillar_ldap: /etc/salt/master.d/pillar_ldap.yaml

   NOTE:
      When placing the file in the master.d directory, make sure its  name
      doesn't end in .conf, otherwise the salt-master process will attempt
      to parse its content.

   WARNING:
      Make sure this file has very restrictive  permissions,  as  it  will
      contain possibly sensitive LDAP credentials!

   The  only  required  key  in  the  master  configuration is pillar_ldap
   pointing to a file containing the actual configuration.

   Configuring the LDAP searches
   The file is processed using Salt's Renderers <renderers> which makes it
   possible to reference grains within the configuration.

   WARNING:
      When  using  Jinja  in  this file, make sure to do it in a way which
      prevents leaking sensitive information. A rogue  minion  could  send
      arbitrary  grains  to  trick  the master into returning secret data.
      Use only the 'id' grain  which  is  verified  through  the  minion's
      key/cert.

   Map Mode
   The it-admins configuration below returns the Pillar it-admins by:

   *

     filtering for:

            * members of the group it-admins

            * objects with objectclass=user

   * returning  the  data  of  users  (mode:  map),  where  each user is a
     dictionary containing the configured string or list attributes.

     Configuration:

        salt-users:
            server:    ldap.company.tld
            port:      389
            tls:       true
            dn:        'dc=company,dc=tld
            binddn:    'cn=salt-pillars,ou=users,dc=company,dc=tld'
            bindpw:    bi7ieBai5Ano
            referrals: false
            anonymous: false
            mode:      map
            dn:        'ou=users,dc=company,dc=tld'
            filter:    '(&(memberof=cn=it-admins,ou=groups,dc=company,dc=tld)(objectclass=user))'
            attrs:
                - cn
                - displayName
                - givenName
                - sn
            lists:
                - memberOf

      **Result:**

      salt-users:
          - cn: cn=johndoe,ou=users,dc=company,dc=tld
            displayName: John Doe
            givenName:   John
            sn:          Doe
            memberOf:
                - cn=it-admins,ou=groups,dc=company,dc=tld
                - cn=team01,ou=groups,dc=company
          - cn: cn=janedoe,ou=users,dc=company,dc=tld
            displayName: Jane Doe
            givenName:   Jane
            sn:          Doe
            memberOf:
                - cn=it-admins,ou=groups,dc=company,dc=tld
                - cn=team02,ou=groups,dc=company

   List Mode
   TODO: see also _result_to_dict() documentation

   salt.pillar.pillar_ldap.ext_pillar(minion_id, pillar, config_file)
          Execute LDAP searches and return the aggregated data

   salt.pillar.puppet
   Execute an unmodified puppet_node_classifier and  read  the  output  as
   YAML.  The YAML data is then directly overlaid onto the minion's Pillar
   data.

   salt.pillar.puppet.ext_pillar(minion_id, pillar, command)
          Execute an unmodified puppet_node_classifier and read the output
          as YAML

   salt.pillar.reclass_adapter
   Use the "reclass" database as a Pillar source

   This  ext_pillar  plugin  provides access to the reclass database, such
   that Pillar data for a specific minion are fetched using reclass.

   You    can    find    more     information     about     reclass     at
   http://reclass.pantsfullofunix.net.

   To  use  the  plugin,  add it to the ext_pillar list in the Salt master
   config and tell reclass by way of a few options how and where  to  find
   the inventory:

      ext_pillar:
          - reclass:
              storage_type: yaml_fs
              inventory_base_uri: /srv/salt

   This  would  cause  reclass  to  read  the inventory from YAML files in
   /srv/salt/nodes and /srv/salt/classes.

   If you are also using reclass as master_tops plugin, and  you  want  to
   avoid having to specify the same information for both, use YAML anchors
   (take note of the differing data types for ext_pillar and master_tops):

      reclass: &reclass
          storage_type: yaml_fs
          inventory_base_uri: /srv/salt
          reclass_source_path: ~/code/reclass

      ext_pillar:
          - reclass: *reclass

      master_tops:
          reclass: *reclass

   If you want to run reclass from source, rather than installing it,  you
   can either let the master know via the PYTHONPATH environment variable,
   or by setting the configuration option, like in the example above.

   salt.pillar.reclass_adapter.ext_pillar(minion_id, pillar, **kwargs)
          Obtain the Pillar data from reclass for the given minion_id.

   salt.pillar.redismod
   Read pillar data from a Redis backend
   New in version 2014.7.0.

   depends

          * redis Python module (on master)

   Salt Master Redis Configuration
   The  module  shares  the  same  base  Redis  connection  variables   as
   salt.returners.redis_return.  These  variables go in your master config
   file.

   * redis.db - The Redis database to use. Defaults to 0.

   * redis.host - The Redis host to connect to. Defaults to 'salt'.

   * redis.port - The port  that  the  Redis  database  is  listening  on.
     Defaults to 6379.

   * redis.password  -  The  password  for authenticating with Redis. Only
     required if you are using master auth. Defaults to None.

   Configuring the Redis ext_pillar
          ext_pillar:
            - redis: {function: key_value}

   salt.pillar.redismod.ext_pillar(minion_id, pillar, function, **kwargs)
          Grabs external pillar data based on configured function

   salt.pillar.redismod.key_json(minion_id, pillar, pillar_key=None)
          Pulls a  string  from  redis  and  deserializes  it  from  json.
          Deserialized  dictionary  data loaded directly into top level if
          pillar_key is not set.

          pillar_key
                 Pillar key to return data into

   salt.pillar.redismod.key_value(minion_id,                       pillar,
   pillar_key='redis_pillar')
          Looks  for  key in redis matching minion_id, returns a structure
          based on the data type of the redis key. String for string type,
          dict for hash type and lists for lists, sets and sorted sets.

          pillar_key
                 Pillar key to return data into

   salt.pillar.s3
   Copy pillar data from a bucket in Amazon S3

   The  S3  pillar  can  be  configured in the master config file with the
   following options

      ext_pillar:
        - s3:
            bucket: my.fancy.pillar.bucket
            keyid: KASKFJWAKJASJKDAJKSD
            key: ksladfDLKDALSFKSD93q032sdDasdfasdflsadkf
            multiple_env: False
            environment: base
            prefix: somewhere/overthere
            verify_ssl: True
            service_url: s3.amazonaws.com
            kms_keyid: 01234567-89ab-cdef-0123-4567890abcde
            s3_cache_expire: 30
            s3_sync_on_update: True

   The bucket parameter specifies the target S3 bucket. It is required.

   The keyid parameter specifies the key id to  use  when  access  the  S3
   bucket.   If  it  is  not  provided,  an  attempt  to fetch it from EC2
   instance meta-data will be made.

   The key parameter specifies the key to use when access the  S3  bucket.
   If  it  is  not  provided,  an  attempt  to  fetch it from EC2 instance
   meta-data will be made.

   The multiple_env defaults to False. It  specifies  whether  the  pillar
   should  interpret  top  level  folders as pillar environments (see mode
   section below).

   The environment defaults to 'base'. It specifies which environment  the
   bucket  represents  when  in single environments mode (see mode section
   below). It is ignored if multiple_env is True.

   The prefix defaults to ''. It  specifies  a  key  prefix  to  use  when
   searching  for  data  in  the  bucket  for  the  pillar.  It works when
   multiple_env is True or False.  Essentially it tells ext_pillar to look
   for your pillar data in a 'subdirectory' of your S3 bucket

   The  verify_ssl  parameter  defaults  to  True. It specifies whether to
   check for valid S3 SSL certificates. NOTE If you use bucket names  with
   periods,  this  must  be set to False else an invalid certificate error
   will be thrown (issue #12200).

   The service_url parameter defaults to 's3.amazonaws.com'. It  specifies
   the base url to use for accessing S3.

   The  kms_keyid  parameter  is  optional. It specifies the ID of the Key
   Management Service (KMS) master  key  that  was  used  to  encrypt  the
   object.

   The  s3_cache_expire parameter defaults to 30s. It specifies expiration
   time of S3 metadata cache file.

   The s3_sync_on_update parameter defaults to True. It specifies if cache
   is synced on update rather than jit.

   This  pillar can operate in two modes, single environment per bucket or
   multiple environments per bucket.

   Single environment mode must have this bucket structure:

      s3://<bucket name>/<prefix>/<files>

   Multiple environment mode must have this bucket structure:

      s3://<bucket name>/<prefix>/<environment>/<files>

   If you wish  to  define  your  pillar  data  entirely  within  S3  it's
   recommended that you use the prefix= parameter and specify one entry in
   ext_pillar for each environment rather  than  specifying  multiple_env.
   This        is        due        to        issue        #22471       (
   https://github.com/saltstack/salt/issues/22471)

   salt.pillar.s3.ext_pillar(minion_id,    pillar,    bucket,    key=None,
   keyid=None,    verify_ssl=True,    location=None,   multiple_env=False,
   environment='base',   prefix='',   service_url=None,    kms_keyid=None,
   s3_cache_expire=30, s3_sync_on_update=True)
          Execute a command and read the output as YAML

   salt.pillar.sql_base module
   Retrieve Pillar data by doing a SQL query

   This module is not meant to be used directly as an ext_pillar.  It is a
   place to put code common to PEP 249 compliant  SQL  database  adapters.
   It  exposes  a  python  ABC  that  can  be  subclassed for new database
   providers.

   maturity
          new

   platform
          all

   Theory of sql_base ext_pillar
   Ok, here's the theory for how this works...

   * First, any non-keyword args are processed in order.

   * Then, remaining keywords are processed.

   We do this  so  that  it's  backward  compatible  with  older  configs.
   Keyword  arguments  are  sorted  before being appended, so that they're
   predictable, but they will always be applied last so overall it's moot.

   For each of those items we process, it depends on the object type:

   * Strings are executed as is and the pillar depth is determined by  the
     number of fields returned.

   * A  list  has  the  first  entry  used as the query, the second as the
     pillar depth.

   * A mapping uses the keys "query" and "depth" as the tuple

   You can retrieve as many fields as you like, how they get used  depends
   on the exact settings.

   Configuring a sql_base ext_pillar
   The  sql_base  ext_pillar  cannot  be  used  directly, but shares query
   configuration with its  implementations.  These  examples  use  a  fake
   'sql_base'  adapter,  which  should  be  replaced  with the name of the
   adapter you are using.

   A list of queries can be passed in

      ext_pillar:
        - sql_base:
            - "SELECT pillar,value FROM pillars WHERE minion_id = %s"
            - "SELECT pillar,value FROM more_pillars WHERE minion_id = %s"

   Or you can pass in a mapping

      ext_pillar:
        - sql_base:
            main: "SELECT pillar,value FROM pillars WHERE minion_id = %s"
            extras: "SELECT pillar,value FROM more_pillars WHERE minion_id = %s"

   The query can be provided as a string as we have just shown,  but  they
   can be provided as lists

      ext_pillar:
        - sql_base:
            - "SELECT pillar,value FROM pillars WHERE minion_id = %s"
              2

   Or as a mapping

      ext_pillar:
        - sql_base:
            - query: "SELECT pillar,value FROM pillars WHERE minion_id = %s"
              depth: 2

   The  depth  defines  how the dicts are constructed.  Essentially if you
   query for fields a,b,c,d for each row you'll get:

   * With depth 1: {a: {"b": b, "c": c, "d": d}}

   * With depth 2: {a: {b: {"c": c, "d": d}}}

   * With depth 3: {a: {b: {c: d}}}

   Depth greater than 3 wouldn't be different from 3 itself.  Depth  of  0
   translates  to the largest depth needed, so 3 in this case.  (max depth
   == key count - 1)

   Then they are merged in a similar way to  plain  pillar  data,  in  the
   order returned by the SQL database.

   Thus subsequent results overwrite previous ones when they collide.

   The  ignore_null option can be used to change the overwrite behavior so
   that only non-NULL values in subsequent results will  overwrite.   This
   can be used to selectively overwrite default values.

      ext_pillar:
        - sql_base:
            - query: "SELECT pillar,value FROM pillars WHERE minion_id = 'default' and minion_id != %s"
              depth: 2
            - query: "SELECT pillar,value FROM pillars WHERE minion_id = %s"
              depth: 2
              ignore_null: True

   If  you specify as_list: True in the mapping expression it will convert
   collisions to lists.

   If you specify with_lists: '...' in  the  mapping  expression  it  will
   convert  the  specified  depths  to  list.   The  string  provided is a
   sequence numbers that are  comma  separated.   The  string  '1,3'  will
   result in:

      a,b,c,d,e,1  # field 1 same, field 3 differs
      a,b,c,f,g,2  # ^^^^
      a,z,h,y,j,3  # field 1 same, field 3 same
      a,z,h,y,k,4  # ^^^^
        ^   ^

   These columns define list grouping

      {a: [
            {c: [
                {e: 1},
                {g: 2}
                ]
            },
            {h: [
                {j: 3, k: 4 }
                ]
            }
      ]}

   The  range for with_lists is 1 to number_of_fields, inclusive.  Numbers
   outside this range are ignored.

   Finally, if you pass the queries in via a mapping, the key will be  the
   first  level name where as passing them in as a list will place them in
   the root.  This isolates the query results  into  their  own  subtrees.
   This may be a help or hindrance to your aims and can be used as such.

   You  can  basically use any SELECT query that gets you the information,
   you could even do joins or subqueries in case your minion_id is  stored
   elsewhere.   It is capable of handling single rows or multiple rows per
   minion.

   Configuration of the connection depends on the adapter in use.

   More complete example for MySQL (to also show configuration)
      mysql:
        user: 'salt'
        pass: 'super_secret_password'
        db: 'salt_db'

      ext_pillar:
        - mysql:
            fromdb:
              query: 'SELECT col1,col2,col3,col4,col5,col6,col7
                        FROM some_random_table
                       WHERE minion_pattern LIKE %s'
              depth: 5
              as_list: True
              with_lists: [1,3]

   class salt.pillar.sql_base.SqlBaseExtPillar
          This class  receives  and  processes  the  database  rows  in  a
          database agnostic way.

          enter_root(root)
                 Set self.focus for kwarg queries

          extract_queries(args, kwargs)
                 This  function  normalizes the config block into a set of
                 queries we can use.  The return is a list of consistently
                 laid out dicts.

          fetch(minion_id, pillar, *args, **kwargs)
                 Execute queries, merge and return as a dict.

          process_fields(field_names, depth)
                 The  primary purpose of this function is to store the sql
                 field list and the depth to which we process.

          process_results(rows)
                 This function  takes  a  list  of  database  results  and
                 iterates over, merging them into a dict form.

   salt.pillar.sqlcipher module
   Retrieve Pillar data by running a SQLCipher query

   New in version 2016.3.0.

   Python SQLCipher support is provided by the pysqlcipher Python package.
   You need this module installed to query Pillar data  from  a  SQLCipher
   database.

   This module is a concrete implementation of the sql_base ext_pillar for
   SQLCipher.

   maturity
          new

   depends
          pysqlcipher (for py2) or pysqlcipher3 (for py3)

   platform
          all

   Configuring the sqlcipher ext_pillar
   Use the 'sqlcipher' key under ext_pillar for configuration of queries.

   SQLCipher database  connection  configuration  requires  the  following
   values configured in the master config:

      * sqlcipher.database   -  The  SQLCipher  database  to  connect  to.
        Defaults to '/var/lib/salt/pillar-sqlcipher.db'.

      * sqlcipher.pass - The SQLCipher database decryption password.

      * sqlcipher.timeout - The connection timeout in seconds.

   Example configuration

      sqlcipher:
        database: /var/lib/salt/pillar-sqlcipher.db
        pass: strong_pass_phrase
        timeout: 5.0

   Complete example
      sqlcipher:
        database: '/var/lib/salt/pillar-sqlcipher.db'
        pass: strong_pass_phrase
        timeout: 5.0

      ext_pillar:
        - sqlcipher:
            fromdb:
              query: 'SELECT col1,col2,col3,col4,col5,col6,col7
                        FROM some_random_table
                       WHERE minion_pattern LIKE ?'
              depth: 5
              as_list: True
              with_lists: [1,3]

   class salt.pillar.sqlcipher.SQLCipherExtPillar
          This  class  receives  and  processes  the  database  rows  from
          SQLCipher.

   salt.pillar.sqlcipher.ext_pillar(minion_id, pillar, *args, **kwargs)
          Execute queries against SQLCipher, merge and return as a dict

   salt.pillar.sqlite3 module
   Retrieve Pillar data by doing a SQLite3 query

   New in version 2015.8.0.

   sqlite3 is included in the stdlib since Python 2.5.

   This module is a concrete implementation of the sql_base ext_pillar for
   SQLite3.

   platform
          all

   Configuring the sqlite3 ext_pillar
   Use the 'sqlite3' key under ext_pillar for configuration of queries.

   SQLite3 database connection configuration requires the following values
   configured in the master config:

   Note, timeout is in seconds.

      sqlite3.database: /var/lib/salt/pillar.db
      sqlite3.timeout: 5.0

   Legacy Compatibility
   SQLite3  database  connection  configuration  previously had keys under
   pillar.

      pillar.sqlite3.database: /var/lib/salt/pillar.db
      pillar.sqlite3.timeout: 5.0

   This has been deprecated in  2016.3.0  and  will  be  removed  in  Salt
   Nitrogen.

   Complete Example
      sqlite3:
        database: '/var/lib/salt/pillar.db'
        timeout: 5.0

      ext_pillar:
        - sqlite3:
            fromdb:
              query: 'SELECT col1,col2,col3,col4,col5,col6,col7
                        FROM some_random_table
                       WHERE minion_pattern LIKE ?'
              depth: 5
              as_list: True
              with_lists: [1,3]

   class salt.pillar.sqlite3.SQLite3ExtPillar
          This  class  receives  and  processes  the  database  rows  from
          SQLite3.

   salt.pillar.sqlite3.ext_pillar(minion_id, pillar, *args, **kwargs)
          Execute queries against SQLite3, merge and return as a dict

   salt.pillar.stack
   Simple and flexible YAML ext_pillar which can read pillar  from  within
   pillar.

   New in version 2016.3.0.

   PillarStack  is  a  custom  saltstack  ext_pillar which was inspired by
   varstack but is heavily based on Jinja2 for maximum flexibility.

   Any  issue  should  be   reported   to   the   upstream   project   at:
   https://github.com/bbinet/pillarstack/issues

   It supports the following features:

   * multiple  config  files  that  are  jinja2 templates with support for
     pillar, __grains__, __salt__, __opts__ objects

   * a config file renders as an ordered list of  files  (paths  of  these
     files are relative to the current config file)

   * this  list  of  files  are  read  in ordered as jinja2 templates with
     support for stack, pillar, __grains__, __salt__, __opts__ objects

   * all these rendered files are then parsed as yaml

   * then all yaml  dicts  are  merged  in  order  with  support  for  the
     following  merging  strategies:  merge-first, merge-last, remove, and
     overwrite

   * stack config files can be matched based on pillar,  grains,  or  opts
     values,  which  make  it  possible  to support kind of self-contained
     environments

   Installation
   PillarStack is already bundled with  Salt  since  2016.3.0  version  so
   there is nothing to install from version 2016.3.0.

   If  you  use  an older Salt version or you want to override PillarStack
   with a more recent one, follow the installation procedure below.

   Installing the PillarStack ext_pillar is  as  simple  as  dropping  the
   stack.py  file in the <extension_modules>/pillar directory (no external
   python module required), given that extension_modules is  set  in  your
   salt-master                     configuration,                     see:
   http://docs.saltstack.com/en/latest/ref/configuration/master.html#extension-modules

   Configuration in Salt
   Like  any  other external pillar, its configuration takes place through
   the ext_pillar key in the master config file.

   However, you can configure PillarStack in 3 different ways:

   Single config file
   This is the simplest option, you just need to  set  the  path  to  your
   single PillarStack config file like below:

      ext_pillar:
        - stack: /path/to/stack.cfg

   List of config files
   You can also provide a list of config files:

      ext_pillar:
        - stack:
            - /path/to/stack1.cfg
            - /path/to/stack2.cfg

   Select config files through grains|pillar|opts matching
   You  can  also  opt for a much more flexible configuration: PillarStack
   allows one to select the config files for the current minion  based  on
   matching values from either grains, or pillar, or opts objects.

   Here  is  an  example  of  such  a configuration, which should speak by
   itself:

      ext_pillar:
        - stack:
            pillar:environment:
              dev: /path/to/dev/stack.cfg
              prod: /path/to/prod/stack.cfg
            grains:custom:grain:
              value:
                - /path/to/stack1.cfg
                - /path/to/stack2.cfg
            opts:custom:opt:
              value: /path/to/stack0.cfg

   PillarStack configuration files
   The  config  files  that  are  referenced  in  the   above   ext_pillar
   configuration  are  jinja2  templates  which  must  render  as a simple
   ordered list of yaml files that will then be  merged  to  build  pillar
   data.

   The  path  of these yaml files must be relative to the directory of the
   PillarStack config file.

   The  following  variables  are  available  in  jinja2   templating   of
   PillarStack configuration files:

   * pillar:  the  pillar  data  (as  passed  by  Salt  to  our ext_pillar
     function)

   * minion_id: the minion id ;-)

   * __opts__: a dictionary of mostly Salt configuration options

   * __grains__: a dictionary of the grains  of  the  minion  making  this
     pillar call

   * __salt__:  a dictionary of Salt module functions, useful so you don't
     have to duplicate functions that already exist  (note:  runs  on  the
     master)

   So you can use all the power of jinja2 to build your list of yaml files
   that will be merged in pillar data.

   For example, you could have a PillarStack config file which looks like:

      $ cat /path/to/stack/config.cfg
      core.yml
      osarchs/{{ __grains__['osarch'] }}.yml
      oscodenames/{{ __grains__['oscodename'] }}.yml
      {%- for role in pillar.get('roles', []) %}
      roles/{{ role }}.yml
      {%- endfor %}
      minions/{{ minion_id }}.yml

   And the whole directory structure could look like:

      $ tree /path/to/stack/
      /path/to/stack/
       config.cfg
       core.yml
       osarchs/
          amd64.yml
          armhf.yml
       oscodenames/
          wheezy.yml
          jessie.yml
       roles/
          web.yml
          db.yml
       minions/
           test-1-dev.yml
           test-2-dev.yml

   Overall process
   In the above PillarStack configuration, given that test-1-dev minion is
   an  amd64  platform  running  Debian  Jessie, and which pillar roles is
   ["db"], the following yaml files would be merged in order:

   * core.yml

   * osarchs/amd64.yml

   * oscodenames/jessie.yml

   * roles/db.yml

   * minions/test-1-dev.yml

   Before merging, every  files  above  will  be  preprocessed  as  Jinja2
   templates.   The following variables are available in Jinja2 templating
   of yaml files:

   * stack: the PillarStack pillar data object  that  has  currently  been
     merged (data from previous yaml files in PillarStack configuration)

   * pillar:  the  pillar  data  (as  passed  by  Salt  to  our ext_pillar
     function)

   * minion_id: the minion id ;-)

   * __opts__: a dictionary of mostly Salt configuration options

   * __grains__: a dictionary of the grains  of  the  minion  making  this
     pillar call

   * __salt__:  a dictionary of Salt module functions, useful so you don't
     have to duplicate functions that already exist  (note:  runs  on  the
     master)

   So  you  can use all the power of jinja2 to build your pillar data, and
   even  use  other  pillar  values  that  has  already  been  merged   by
   PillarStack  (from  previous  yaml  files in PillarStack configuration)
   through the stack variable.

   Once a yaml file has been preprocessed by Jinja2, we  obtain  a  Python
   dict  -  let's  call  it  yml_data  - then, PillarStack will merge this
   yml_data dict in the main stack dict  (which  contains  already  merged
   PillarStack  pillar  data).   By default, PillarStack will deeply merge
   yml_data    in    stack    (similarly    to    the     recurse     salt
   pillar_source_merging_strategy), but 3 merging strategies are currently
   available for you to choose (see next section).

   Once every yaml files have been processed, the stack dict will  contain
   your  whole  own  pillar  data,  merged  in  order  by PillarStack.  So
   PillarStack ext_pillar returns the stack dict, the  contents  of  which
   Salt  takes  care to merge in with all of the other pillars and finally
   return the whole pillar to the minion.

   Merging strategies
   The way the data from a new yaml_data dict is merged with the  existing
   stack  data  can  be controlled by specifying a merging strategy. Right
   now this strategy can either be merge-last (the default),  merge-first,
   remove, or overwrite.

   Note  that  scalar  values  like  strings, integers, booleans, etc. are
   always evaluated using the overwrite strategy (other  strategies  don't
   make sense in that case).

   The merging strategy can be set by including a dict in the form of:

      __: <merging strategy>

   as  the  first  item  of  the  dict  or list.  This allows fine grained
   control over the merging process.

   merge-last (default) strategy
   If the merge-last strategy is selected (the default), then  content  of
   dict  or list variables is merged recursively with previous definitions
   of    this    variable    (similarly    to     the     recurse     salt
   pillar_source_merging_strategy).   This allows for extending previously
   defined data.

   merge-first strategy
   If the merge-first strategy is selected, then the content  of  dict  or
   list  variables  are  swapped  between  the yaml_data and stack objects
   before being merged recursively with the merge-last previous strategy.

   remove strategy
   If the remove strategy is  selected,  then  content  of  dict  or  list
   variables  in  stack  are  removed  only  if  the corresponding item is
   present in the yaml_data dict.  This allows  for  removing  items  from
   previously defined data.

   overwrite strategy
   If the overwrite strategy is selected, then the content of dict or list
   variables in stack is overwritten by the content of yaml_data dict.  So
   this allows one to overwrite variables from previous definitions.

   Merging examples
   Let's  go  through  small  examples that should clarify what's going on
   when a yaml_data dict is merged in the stack dict.

   When you don't specify any strategy, the default merge-last strategy is
   selected:


stack                       yaml_data                    stack (after merge)         



   Then  you  can  select  a custom merging strategy using the __ key in a
   dict:


stack                       yaml_data                    stack (after merge)         






   You can also select a custom merging strategy using a __  object  in  a
   list:

      
      stack               yaml_data                      stack (after merge) 
      
                                                                         
            users:              users:                         users:    
              - tom               - __: merge-last               - tom   
              - root              - mat                          - root  
                                                                 - mat   
      

                                                                         
            users:              users:                         users:    
              - tom               - __: merge-first              - mat   
              - root              - mat                          - tom   
                                                                 - root  
      
                                                                         
            users:              users:                         users:    
              - tom               - __: remove                   - root  
              - root              - mat                                  
                                  - tom                                  
      
                                                                         
            users:              users:                         users:    
              - tom               - __: overwrite                - mat   
              - root              - mat                                  
      

   salt.pillar.svn_pillar
   Clone a remote SVN repository and use the filesystem as a Pillar source

   This external Pillar source can be configured in the master config file
   like so:

      ext_pillar:
        - svn: trunk svn://svnserver/repo root=subdirectory

   The root= parameter is optional and used to set the  subdirectory  from
   where to look for Pillar files (such as top.sls).

   Changed in version 2014.7.0: The optional root parameter will be added.

   Note  that  this is not the same thing as configuring pillar data using
   the pillar_roots parameter. The branch  referenced  in  the  ext_pillar
   entry  above  (master), would evaluate to the base environment, so this
   branch needs to contain a top.sls with a base section in it, like this:

      base:
        '*':
          - foo

   To use other environments from the same SVN repo as svn_pillar sources,
   just add additional lines, like so:

      ext_pillar:
        - svn: trunk svn://svnserver/repo
        - svn: dev svn://svnserver/repo

   In  this  case,  the  dev  branch would need its own top.sls with a dev
   section in it, like this:

      dev:
        '*':
          - bar

   class  salt.pillar.svn_pillar.SvnPillar(branch,  repo_location,   root,
   opts)
          Deal with the remote SVN repository for Pillar

          pillar_dir()
                 Returns the directory of the pillars (repo cache + branch
                 + root)

   salt.pillar.svn_pillar.ext_pillar(minion_id, pillar, repo_string)
          Execute a command and read the output as YAML

   salt.pillar.varstack_pillar
   Use Varstack data as a Pillar source

   Configuring Varstack
   Using varstack in Salt is fairly simple. Just put  the  following  into
   the config file of your master:

      ext_pillar:
        - varstack: /etc/varstack.yaml

   Varstack   will   then   use   /etc/varstack.yaml  to  determine  which
   configuration data to return as pillar information. From there you  can
   take a look at the README of varstack on how this file is evaluated.

   salt.pillar.varstack_pillar.ext_pillar(minion_id, pillar, conf)
          Parse varstack data and return the result

   salt.pillar.vault module
   Vault Pillar Module

   maintainer
          SaltStack

   maturity
          New

   platform
          all

   New in version 2016.11.0.

   This module allows pillar data to be stored in Hashicorp Vault.

   The  vault  module requires a configuration profile to be configured in
   either the minion or master configuration file. This  profile  requires
   very little. In the example:

      myvault:
        vault.host: 127.0.0.1
        vault.port: 8200
        vault.scheme: http  # Optional; default is https
        vault.token: 012356789abcdef  # Required, unless set in environment

   vault.host  refers  to  the  host  that is hosting vault and vault.port
   refers to the port on that host. A vault token is also required. It may
   be set statically, as above, or as an environment variable:

      $ export VAULT_TOKEN=0123456789abcdef

   After  the  profile is created, configure the external pillar system to
   use it.  A path must also be specified so that  vault  knows  where  to
   look.

      ext_pillar:
        - vault: my_vault_config path=secret/salt

   Using  these configuration profiles, multiple vault sources may also be
   used:

      ext_pillar:
        - vault: my_vault_config
        - vault: my_other_vault_config

   salt.pillar.vault.ext_pillar(minion_id, pillar, conf)
          Check vault for all data

   salt.pillar.virtkey
   Accept a key from a hypervisor if the virt runner has already submitted
   an authorization request

   salt.pillar.virtkey.ext_pillar(hyper_id, pillar, name, key)
          Accept the key for the VM on the hyper, if authorized.

   proxy modules
                 
                 chronos      Chronos                    
                 
                 esxi         Proxy   Minion   interface 
                              module for managing VMware 
                              ESXi hosts.                
                 
                 fx2          Dell FX2 chassis           
                 
                 junos        Interface   with  a  Junos 
                              device via proxy-minion.   
                 
                 marathon     Marathon                   
                 
                 napalm       NAPALM: Network Automation 
                              and        Programmability 
                              Abstraction   Layer   with 
                              Multivendor support        
                 
                 nxos         Proxy  Minion for Cisco NX 
                              OS Switches                
                 
                 philips_hue  Philips HUE  lamps  module 
                              for proxy.                 
                 
                 rest_sample  This     is    a    simple 
                              proxy-minion  designed  to 
                              connect to and communicate 
                              with                       
                 
                 ssh_sample   This    is    a     simple 
                              proxy-minion  designed  to 
                              connect to and communicate 
                              with a server that exposes 
                              functionality via SSH.     
                 

   salt.proxy.chronos module
   Chronos
   Proxy minion for managing a Chronos cluster.

   Dependencies
   * chronos execution module (salt.modules.chronos)

   Pillar
   The chronos proxy configuration requires  a  'base_url'  property  that
   points to the chronos endpoint:

      proxy:
        proxytype: chronos
        base_url: http://my-chronos-master.mydomain.com:4400

   New in version 2015.8.2.

   salt.proxy.chronos.init(opts)
          Perform any needed setup.

   salt.proxy.chronos.ping()
          Is the chronos api responding?

   salt.proxy.chronos.shutdown(opts)
          For this proxy shutdown is a no-op

   salt.proxy.esxi
   Proxy Minion interface module for managing VMware ESXi hosts.

   New in version 2015.8.4.

   Special  Note:  SaltStack thanks Adobe Corporation for their support in
   creating this Proxy Minion integration.

   This proxy minion enables VMware ESXi (hereafter referred to as  simply
   'ESXi') hosts to be treated individually like a Salt Minion.

   Since the ESXi host may not necessarily run on an OS capable of hosting
   a Python stack, the ESXi host can't run a Salt Minion directly.  Salt's
   "Proxy  Minion"  functionality enables you to designate another machine
   to host a minion process that "proxies"  communication  from  the  Salt
   Master.  The  master  does  not  know nor care that the target is not a
   "real" Salt Minion.

   More in-depth conceptual reading on Proxy Minions can be found  in  the
   Proxy Minion section of Salt's documentation.

   Dependencies
   * pyVmomi Python Module

   * ESXCLI

   pyVmomi
   PyVmomi can be installed via pip:

      pip install pyVmomi

   NOTE:
      Version  6.0 of pyVmomi has some problems with SSL error handling on
      certain versions of Python. If using version 6.0 of pyVmomi,  Python
      2.6,  Python  2.7.9,  or  newer  must  be present. This is due to an
      upstream dependency in pyVmomi 6.0 that is not supported  in  Python
      versions  2.7  to  2.7.8.  If  the  version  of Python is not in the
      supported range, you will need to  install  an  earlier  version  of
      pyVmomi. See Issue #29537 for more information.

   Based  on the note above, to install an earlier version of pyVmomi than
   the version currently listed in PyPi, run the following:

      pip install pyVmomi==5.5.0.2014.1.1

   The 5.5.0.2014.1.1 is a known stable version that  this  original  ESXi
   State Module was developed against.

   ESXCLI
   Currently, about a third of the functions used in the vSphere Execution
   Module require the ESXCLI package be installed on the  machine  running
   the Proxy Minion process.

   The  ESXCLI  package  is also referred to as the VMware vSphere CLI, or
   vCLI.  VMware  provides  vCLI  package  installation  instructions  for
   vSphere 5.5 and vSphere 6.0.

   Once all of the required dependencies are in place and the vCLI package
   is installed, you can check to see if you can connect to your ESXi host
   or vCenter server by running the following command:

      esxcli -s <host-location> -u <username> -p <password> system syslog config get

   If  the connection was successful, ESXCLI was successfully installed on
   your system.  You should see output related to the ESXi  host's  syslog
   configuration.

   Configuration
   To use this integration proxy module, please configure the following:

   Pillar
   Proxy  minions  get their configuration from Salt's Pillar. Every proxy
   must have a stanza in Pillar and a reference  in  the  Pillar  top-file
   that matches the ID. At a minimum for communication with the ESXi host,
   the pillar should look like this:

      proxy:
        proxytype: esxi
        host: <ip or dns name of esxi host>
        username: <ESXi username>
        passwords:
          - first_password
          - second_password
          - third_password

   proxytype
   The proxytype key and value pair is critical, as it  tells  Salt  which
   interface to load from the proxy directory in Salt's install hierarchy,
   or from /srv/salt/_proxy on the Salt Master (if you have  created  your
   own proxy module, for example). To use this ESXi Proxy Module, set this
   to esxi.

   host
   The location, or ip/dns, of the ESXi host. Required.

   username
   The username used to login to the ESXi host, such as root. Required.

   passwords
   A list of passwords to be used to try and login to the  ESXi  host.  At
   least one password in this list is required.

   The  proxy  integration  will  try the passwords listed in order. It is
   configured this way so you can have a regular password and the password
   you   may   be   updating   for   an   ESXi   host   either   via   the
   vsphere.update_host_password  execution  module  function  or  via  the
   esxi.password_present  state  function. This way, after the password is
   changed, you should not need to restart  the  proxy  minion--it  should
   just  pick  up  the the new password provided in the list. You can then
   change pillar at will to move that password to the front and retire the
   unused ones.

   This also allows you to use any number of potential fallback passwords.

   NOTE:
      When  a  password  is  changed  on  the  host  to one in the list of
      possible passwords, the further down on the list  the  password  is,
      the  longer  individual commands will take to return. This is due to
      the nature of pyVmomi's login system. We have to wait for the  first
      attempt to fail before trying the next password on the list.

      This  scenario  is  especially true, and even slower, when the proxy
      minion first starts. If  the  correct  password  is  not  the  first
      password  on  the  list, it may take up to a minute for test.ping to
      respond with a  True  result.  Once  the  initial  authorization  is
      complete, the responses for commands will be a little faster.

      To  avoid  these longer waiting periods, SaltStack recommends moving
      the correct password to the top of the list and restarting the proxy
      minion at your earliest convenience.

   protocol
   If  the  ESXi host is not using the default protocol, set this value to
   an alternate protocol. Default is https.

   port
   If the ESXi host is not using the default port, set this  value  to  an
   alternate port. Default is 443.

   Salt Proxy
   After  your  pillar  is in place, you can test the proxy. The proxy can
   run on any machine that has network connectivity to  your  Salt  Master
   and to the ESXi host in question. SaltStack recommends that the machine
   running the salt-proxy process also run a regular minion, though it  is
   not strictly necessary.

   On  the  machine  that  will  run  the  proxy,  make  sure  there is an
   /etc/salt/proxy file with at least the following in it:

      master: <ip or hostname of salt-master>

   You can then start the salt-proxy process with:

      salt-proxy --proxyid <id you want to give the host>

   You may want to add -l debug to run the  above  in  the  foreground  in
   debug mode just to make sure everything is OK.

   Next,  accept  the key for the proxy on your salt-master, just like you
   would for a regular minion:

      salt-key -a <id you gave the esxi host>

   You can confirm that the pillar data is in place for the proxy:

      salt <id> pillar.items

   And now you should be able to ping the ESXi host to  make  sure  it  is
   responding:

      salt <id> test.ping

   At  this  point  you can execute one-off commands against the host. For
   example, you can get the ESXi host's system information:

      salt <id> esxi.cmd system_info

   Note that you don't need to provide credentials or an ip/hostname. Salt
   knows to use the credentials you stored in Pillar.

   It's   important   to  understand  how  this  particular  proxy  works.
   Salt.modules.vsphere is a standard Salt execution module. If  you  pull
   up  the docs for it you'll see that almost every function in the module
   takes credentials and a target host. When credentials and a host aren't
   passed,  Salt  runs commands through pyVmomi against the local machine.
   If you wanted, you could run functions from this  module  on  any  host
   where  an  appropriate  version  of pyVmomi is installed, and that host
   would reach out over the network and communicate with the ESXi host.

   esxi.cmd acts as a "shim" between the execution module and  the  proxy.
   Its  first  parameter is always the function from salt.modules.vsphere.
   If the function takes more positional  or  keyword  arguments  you  can
   append  them  to  the call. It's this shim that speaks to the ESXi host
   through the proxy, arranging for the credentials  and  hostname  to  be
   pulled from the Pillar section for this Proxy Minion.

   Because  of  the presence of the shim, to lookup documentation for what
   functions you can use to interface with the ESXi host, you'll  want  to
   look in salt.modules.vsphere instead of salt.modules.esxi.

   States
   Associated  states  are thoroughly documented in salt.states.esxi. Look
   there to find an example structure for Pillar as  well  as  an  example
   .sls file for standing up an ESXi host from scratch.

   salt.proxy.esxi.ch_config(cmd, *args, **kwargs)
          This  function  is called by the salt.modules.esxi.cmd shim.  It
          then   calls   whatever   is   passed   in   cmd   inside    the
          salt.modules.vsphere module.  Passes the return through from the
          vsphere module.

          cmd    The command to call inside salt.modules.vsphere

          args   Arguments that need to be passed to that command.

          kwargs Keyword arguments that need to be passed to that command.

   salt.proxy.esxi.find_credentials(host)
          Cycle through all the possible credentials and return the  first
          one that works.

   salt.proxy.esxi.grains()
          Get the grains from the proxy device.

   salt.proxy.esxi.grains_refresh()
          Refresh the grains from the proxy device.

   salt.proxy.esxi.init(opts)
          This  function  gets  called  when the proxy starts up. For ESXi
          devices, the host, login credentials, and,  if  configured,  the
          protocol and port are cached.

   salt.proxy.esxi.ping()
          Check  to  see  if  the host is responding. Returns False if the
          host didn't respond, True otherwise.

          CLI Example:

             salt esxi-host test.ping

   salt.proxy.esxi.shutdown()
          Shutdown the connection to the proxy  device.  For  this  proxy,
          shutdown is a no-op.

   salt.proxy.fx2
   Dell FX2 chassis
   New in version 2015.8.2.

   Proxy  minion  interface  module  for  managing  Dell FX2 chassis (Dell
   Chassis Management Controller version 1.2  and  above,  iDRAC8  version
   2.00 and above)

   Dependencies
   * iDRAC Remote execution module (salt.modules.dracr)

   * Chassis command shim (salt.modules.chassis)

   * Dell Chassis States (salt.states.dellchassis)

   * Dell's racadm command line interface to CMC and iDRAC devices.

   Special  Note:  SaltStack thanks Adobe Corporation for their support in
   creating this proxy minion integration.

   This proxy minion enables Dell FX2 and FX2s (hereafter referred  to  as
   simply  "chassis",  "CMC", or "FX2") chassis to be treated individually
   like a salt-minion.

   Since the CMC embedded in the chassis does not run  an  OS  capable  of
   hosting  a  Python  stack,  the  chassis  can't  run a minion directly.
   Salt's "Proxy Minion" functionality enables you  to  designate  another
   machine  to host a minion process that "proxies" communication from the
   salt-master.  The master does not know nor care that the target is  not
   a real minion.

   More  in-depth  conceptual reading on Proxy Minions can be found in the
   Proxy Minion section of Salt's documentation.

   To configure this integration, follow these steps:

   Pillar
   Proxy minions get their configuration from Salt's Pillar.  Every  proxy
   must  have  a  stanza  in Pillar, and a reference in the Pillar topfile
   that matches the ID.  At a minimum for communication with  the  chassis
   the pillar should look like this:

      proxy:
        host: <ip or dns name of chassis controller>
        admin_username: <iDRAC username for the CMC, usually 'root'>
        fallback_admin_username: <username to try if the first fails>
        passwords:
          - first_password
          - second_password
          - third-password
        proxytype: fx2

   The  proxytype line above is critical, it tells Salt which interface to
   load from the proxy directory in  Salt's  install  hierarchy,  or  from
   /srv/salt/_proxy on the salt-master (if you have created your own proxy
   module, for example).

   The proxy integration will try the passwords listed in  order.   It  is
   configured  this  way  so  you can have a regular password, a potential
   fallback password, and the third password can be the one you intend  to
   change  the  chassis to use.  This way, after it is changed, you should
   not need to restart the proxy minion--it should just pick up the  third
   password  in the list.  You can then change pillar at will to move that
   password to the front and retire the unused ones.

   Beware, many Dell CMC and iDRAC units  are  configured  to  lockout  IP
   addresses  or  users after too many failed password attempts.  This can
   generate user panic in the form of "I no longer know what the  password
   is!!!".   To  mitigate panic try the web interface from a different IP,
   or setup a emergency administrator user  in  the  CMC  before  doing  a
   wholesale password rotation.

   The automatic lockout can be disabled via Salt with the following:

      salt <cmc> chassis.cmd set_general cfgRacTuning cfgRacTuneIpBlkEnable 0

   and then verified with

      salt <cmc> chassis.cmd get_general cfgRacTuning cfgRacTuneIpBlkEnable

   salt-proxy
   After  your  pillar is in place, you can test the proxy.  The proxy can
   run on any machine that has network connectivity  to  your  salt-master
   and to the chassis in question.  SaltStack recommends that this machine
   also run a regular minion, though it is not strictly necessary.

   On the machine  that  will  run  the  proxy,  make  sure  there  is  an
   /etc/salt/proxy file with at least the following in it:

      master: <ip or hostname of salt-master>

   You can start the proxy with

      salt-proxy --proxyid <id you want to give the chassis>

   You  may  want  to  add  -l debug to run the above in the foreground in
   debug mode just to make sure everything is OK.

   Next, accept the key for the proxy on your salt-master, just  like  you
   would for a regular minion:

      salt-key -a <id you want to give the chassis>

   You can confirm that the pillar data is in place for the proxy:

      salt <id> pillar.items

   And  now  you  should  be  able  to ping the chassis to make sure it is
   responding:

      salt <id> test.ping

   At this point you can execute one-off  commands  against  the  chassis.
   For example, you can get the chassis inventory:

      salt <id> chassis.cmd inventory

   Note  that  you  don't  need  to provide credentials or an ip/hostname.
   Salt knows to use the credentials you stored in Pillar.

   It's  important  to  understand  how  this  particular   proxy   works.
   Salt.modules.dracr is a standard Salt execution module.  If you pull up
   the docs for it you'll see that almost every  function  in  the  module
   takes  credentials  and  a  target  host.   When credentials and a host
   aren't passed, Salt runs racadm against  the  local  machine.   If  you
   wanted  you  could  run functions from this module on any host where an
   appropriate version of racadm is installed, and that host  would  reach
   out over the network and communicate with the chassis.

   Chassis.cmd  acts  as  a  "shim"  between  the execution module and the
   proxy.   It's   first   parameter   is   always   the   function   from
   salt.modules.dracr  to  execute.  If the function takes more positional
   or keyword arguments you can append them to the call.  It's  this  shim
   that  speaks  to  the  chassis  through  the  proxy,  arranging for the
   credentials and hostname to be pulled from the pillar section for  this
   proxy minion.

   Because  of  the presence of the shim, to lookup documentation for what
   functions you can use to interface with the  chassis,  you'll  want  to
   look in salt.modules.dracr instead of salt.modules.chassis.

   States
   Associated states are thoroughly documented in salt.states.dellchassis.
   Look there to find an example  structure  for  pillar  as  well  as  an
   example .sls file for standing up a Dell Chassis from scratch.

   salt.proxy.fx2.admin_password()
          Return the admin_password in the DETAILS dictionary, or 'calvin'
          (the Dell default) if there is none present

   salt.proxy.fx2.admin_username()
          Return the admin_username in the DETAILS dictionary, or root  if
          there is none present

   salt.proxy.fx2.chconfig(cmd, *args, **kwargs)
          This  function  is  called by the salt.modules.chassis.cmd shim.
          It  then  calls  whatever  is   passed   in   cmd   inside   the
          salt.modules.dracr module.

          Parameters

                 * cmd -- The command to call inside salt.modules.dracr

                 * args  --  Arguments  that  need  to  be  passed to that
                   command

                 * kwargs -- Keyword arguments that need to be  passed  to
                   that command

          Returns
                 Passthrough the return from the dracr module.

   salt.proxy.fx2.find_credentials()
          Cycle  through all the possible credentials and return the first
          one that works

   salt.proxy.fx2.grains()
          Get the grains from the proxied device

   salt.proxy.fx2.grains_refresh()
          Refresh the grains from the proxied device

   salt.proxy.fx2.init(opts)
          This function gets called when the proxy starts  up.   We  check
          opts  to  see  if a fallback user and password are supplied.  If
          they are present, and the primary credentials don't  work,  then
          we try the backup before failing.

          Whichever  set  of credentials works is placed in the persistent
          DETAILS dictionary and will be used  for  further  communication
          with the chassis.

   salt.proxy.fx2.ping()
          Is the chassis responding?

          Returns
                 Returns   False  if  the  chassis  didn't  respond,  True
                 otherwise.

   salt.proxy.fx2.shutdown(opts)
          Shutdown the connection to the proxied device.  For  this  proxy
          shutdown is a no-op.

   salt.proxy.junos
   Interface with a Junos device via proxy-minion.

   salt.proxy.junos.init(opts)
          Open  the connection to the Junos device, login, and bind to the
          Resource class

   salt.proxy.junos.ping()
          Ping?  Pong!

   salt.proxy.junos.proxytype()
          Returns the name of this proxy

   salt.proxy.junos.shutdown(opts)
          This is called when the proxy-minion is exiting to make sure the
          connection to the device is closed cleanly.

   salt.proxy.marathon module
   Marathon
   Proxy minion for managing a Marathon cluster.

   Dependencies
   * marathon execution module (salt.modules.marathon)

   Pillar
   The  marathon  proxy  configuration requires a 'base_url' property that
   points to the marathon endpoint:

      proxy:
        proxytype: marathon
        base_url: http://my-marathon-master.mydomain.com:8080

   New in version 2015.8.2.

   salt.proxy.marathon.init(opts)
          Perform any needed setup.

   salt.proxy.marathon.ping()
          Is the marathon api responding?

   salt.proxy.marathon.shutdown(opts)
          For this proxy shutdown is a no-op

   salt.proxy.napalm
   NAPALM: Network  Automation  and  Programmability  Abstraction  Layer  with
   Multivendor support
   Proxy minion for managing network devices via NAPALM library.

   codeauthor
          Mircea   Ulinic   <[email protected]>  &  Jerome  Fleury  <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   The napalm proxy module requires NAPALM library to be  installed:   pip
   install napalm Please check Installation for complete details.

   Pillar
   The  napalm  proxy  configuration requires four mandatory parameters in
   order to connect to the network device:

   * driver: specifies the network device operating system. For a complete
     list  of  the  supported operating systems please refer to the NAPALM
     Read the Docs page.

   * host: hostname

   * username: username to be used when connecting to the device

   * passwd: the password needed to establish the connection

   * optional_args: dictionary with  the  optional  arguments.  Check  the
     complete list of supported optional arguments

   Example:

      proxy:
          proxytype: napalm
          driver: junos
          host: core05.nrt02
          username: my_username
          passwd: my_password
          optional_args:
              port: 12201
              config_format: set

   SEE ALSO:

      * NAPALM   grains:   select   network   devices   based   on   their
        characteristics

      * NET module: network basic features

      * NTP operational and configuration management module

      * BGP operational and configuration management module

      * Routes details

      * SNMP configuration module

      * Users configuration management

   New in version 2016.11.0.

   salt.proxy.napalm.call(method, **params)
          Calls a  specific  method  from  the  network  driver  instance.
          Please  check  the  readthedocs  page  for  the  updated list of
          getters.

          Parameters

                 * method -- specifies the name of the method to be called

                 * params -- contains the mapping between the name and the
                   values of the parameters needed to call the method

          Returns
                 A dictionary with three keys:

                 * result (True/False): if the operation succeeded

                 * out (object): returns the object as-is from the call

                 * comment  (string):  provides  more  details in case the
                   call failed

                 * traceback  (string):  complete  traceback  in  case  of
                   exeception.  Please  submit  an  issue  including  this
                   traceback

                 on the correct driver repo and make sure to read the
                 FAQ_

          Example:

             __proxy__['napalm.call']('cli'
                                      **{
                                         'commands': [
                                             'show version',
                                             'show chassis fan'
                                         ]
                                      })

   salt.proxy.napalm.fns()
          Method called by NAPALM grains module.

   salt.proxy.napalm.grains()
          Retrieve facts from the network device.

   salt.proxy.napalm.grains_refresh()
          Refresh the grains.

   salt.proxy.napalm.init(opts)
          Opens the connection with the network device.

   salt.proxy.napalm.initialized()
          Connection finished initializing?

   salt.proxy.napalm.ping()
          Connection open successfully?

   salt.proxy.napalm.shutdown(opts)
          Closes connection with the device.

   salt.proxy.nxos module
   Proxy Minion for Cisco NX OS Switches

   The Cisco NX OS Proxy Minion uses the built in SSHConnection module  in
   salt.utils.vt_helper

   To configure the proxy minion:

      proxy:
        proxytype: nxos
        host: 192.168.187.100
        username: admin
        password: admin
        prompt_name: switch
        ssh_args: '-o PubkeyAuthentication=no'
        key_accept: True

   proxytype
          (REQUIRED) Use this proxy minion nxos

   host   (REQUIRED) ip address or hostname to connect to

   username
          (REQUIRED) username to login with

   password
          (REQUIRED) password to use to login with

   prompt_name
          (REQUIRED)  The  name  in the prompt on the switch.  By default,
          use your devices hostname.

   ssh_args
          Any extra args to use to connect to the switch.

   key_accept
          Whether or not to accept a the host key of the switch on initial
          login.  Defaults to False.

   The  functions  from  the  proxy  minion  can  be  run  from  the  salt
   commandline using the salt.modules.nxos execution module.

   NOTE:
      The option proxy_merge_grains_in_module: True is  required  to  have
      the  NXOS  grains  be  available  from  the  proxy  minion,  for the
      2016.11.0 release.  For  Nitrogen,  the  setting  will  be  True  by
      default.

   salt.proxy.nxos.add_config(lines)
          Add one or more config lines to the switch running config

             salt '*' nxos.cmd add_config 'snmp-server community TESTSTRINGHERE group network-operator'

          NOTE:
             For more than one config added per command, lines should be a
             list.

   salt.proxy.nxos.check_password(username, password, encrypted=False)
          Check if passed password is the one assigned to user

   salt.proxy.nxos.check_role(username, role)
          Check if user is assigned a specific role on switch

             salt '*' nxos.cmd check_role username=admin role=network-admin

   salt.proxy.nxos.delete_config(lines)
          Delete one or more config lines to the switch running config

             salt '*' nxos.cmd delete_config 'snmp-server community TESTSTRINGHERE group network-operator'

          NOTE:
             For more than one config deleted per command, lines should be
             a list.

   salt.proxy.nxos.find(pattern)
          Find all instances where the pattern is in the running command

             salt '*' nxos.cmd find '^snmp-server.*$'

          NOTE:
             This  uses the re.MULTILINE regex format for python, and runs
             the regex against the whole show_run output.

   salt.proxy.nxos.get_roles(username)
          Get roles that the username is assigned from switch

   salt.proxy.nxos.get_user(username)
          Get username line from switch

   salt.proxy.nxos.grains()
          Get grains for proxy minion

   salt.proxy.nxos.grains_refresh()
          Refresh the grains from the proxy device.

   salt.proxy.nxos.init(opts=None)
          Required.  Can be used to initialize the server connection.

   salt.proxy.nxos.ping()
          Ping the device on the other end of the connection

   salt.proxy.nxos.remove_user(username)
          Remove user from switch

             salt '*' nxos.cmd remove_user username=daniel

   salt.proxy.nxos.replace(old_value, new_value, full_match=False)
          Replace string or full line matches in switch's running config

          If full_match is set to True, then the whole line will  need  to
          be matched as part of the old value.

             salt '*' nxos.cmd replace 'TESTSTRINGHERE' 'NEWTESTSTRINGHERE'

   salt.proxy.nxos.sendline(command)
          Run command through switch's cli

   salt.proxy.nxos.set_password(username,    password,    encrypted=False,
   role=None, crypt_salt=None, algorithm='sha256')
          Set users password on switch

             salt '*' nxos.cmd set_password admin TestPass
             salt '*' nxos.cmd set_password admin \
                 password='$5$2fWwO2vK$s7.Hr3YltMNHuhywQQ3nfOd.gAPHgs3SOBYYdGT3E.A' \
                 encrypted=True

   salt.proxy.nxos.set_role(username, role)
          Assign role to username

             salt '*' nxos.cmd set_role username=daniel role=vdc-admin

   salt.proxy.nxos.show_run()
          Shortcut to run show run on switch

             salt '*' nxos.cmd show_run

   salt.proxy.nxos.show_ver()
          Shortcut to run show ver on switch

             salt '*' nxos.cmd show_ver

   salt.proxy.nxos.shutdown(opts)
          Disconnect

   salt.proxy.nxos.system_info()
          Return system information for grains of the NX OS proxy minion

             salt '*' nxos.system_info

   salt.proxy.nxos.unset_role(username, role)
          Remove role from username

             salt '*' nxos.cmd unset_role username=daniel role=vdc-admin

   salt.proxy.philips_hue module
   Philips HUE lamps module for proxy.

   New in version 2015.8.3.

   class salt.proxy.philips_hue.Const
          Constants for the lamp operations.

   salt.proxy.philips_hue.call_alert(*args, **kwargs)
          Lamp alert

          Options:

          * id: Specifies a device ID. Can be  a  comma-separated  values.
            All, if omitted.

          * on: Turns on or off an alert. Default is True.

          CLI Example:

             salt '*' hue.alert
             salt '*' hue.alert id=1
             salt '*' hue.alert id=1,2,3 on=false

   salt.proxy.philips_hue.call_blink(*args, **kwargs)
          Blink  a  lamp.  If  lamp is ON, then blink ON-OFF-ON, otherwise
          OFF-ON-OFF.

          Options:

          * id: Specifies a device ID. Can be  a  comma-separated  values.
            All, if omitted.

          * pause: Time in seconds. Can be less than 1, i.e. 0.7, 0.5 sec.

          CLI Example:

             salt '*' hue.blink id=1
             salt '*' hue.blink id=1,2,3

   salt.proxy.philips_hue.call_brightness(*args, **kwargs)
          Set an effect to the lamp.

          Arguments:

          * value: 0~255 brightness of the lamp.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          * transition: Transition 0~200. Default 0.

          CLI Example:

             salt '*' hue.brightness value=100
             salt '*' hue.brightness id=1 value=150
             salt '*' hue.brightness id=1,2,3 value=255

   salt.proxy.philips_hue.call_color(*args, **kwargs)
          Set a color to the lamp.

          Options:

          * id: Specifies a device ID. Can be  a  comma-separated  values.
            All, if omitted.

          *

            color:  Fixed  color.  Values  are:  red, green, blue, orange,
            pink, white,
                   yellow, daylight, purple. Default white.

          * transition: Transition 0~200.

          Advanced:

          *

            gamut: XY coordinates. Use gamut according to the Philips  HUE
            devices documentation.
                   More:
                   http://www.developers.meethue.com/documentation/hue-xy-values

          CLI Example:

             salt '*' hue.color
             salt '*' hue.color id=1
             salt '*' hue.color id=1,2,3 oolor=red transition=30
             salt '*' hue.color id=1 gamut=0.3,0.5

   salt.proxy.philips_hue.call_effect(*args, **kwargs)
          Set an effect to the lamp.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          * type: Type of  the  effect.  Possible  values  are  "none"  or
            "colorloop". Default "none".

          CLI Example:

             salt '*' hue.effect
             salt '*' hue.effect id=1
             salt '*' hue.effect id=1,2,3 type=colorloop

   salt.proxy.philips_hue.call_lights(*args, **kwargs)
          Get info about all available lamps.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          CLI Example:

             salt '*' hue.lights
             salt '*' hue.lights id=1
             salt '*' hue.lights id=1,2,3

   salt.proxy.philips_hue.call_ping(*args, **kwargs)
          Ping the lamps  by  issuing  a  short  inversion  blink  to  all
          available devices.

          CLI Example:

             salt '*' hue.ping

   salt.proxy.philips_hue.call_rename(*args, **kwargs)
          Rename a device.

          Options:

          * id: Specifies a device ID. Only one device at a time.

          * title: Title of the device.

          CLI Example:

             salt '*' hue.rename id=1 title='WC for cats'

   salt.proxy.philips_hue.call_status(*args, **kwargs)
          Return the status of the lamps.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          CLI Example:

             salt '*' hue.status
             salt '*' hue.status id=1
             salt '*' hue.status id=1,2,3

   salt.proxy.philips_hue.call_switch(*args, **kwargs)
          Switch lamp ON/OFF.

          If no particular state is passed, then lamp will be switched  to
          the opposite state.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          * on: True or False. Inverted current, if omitted

          CLI Example:

             salt '*' hue.switch
             salt '*' hue.switch id=1
             salt '*' hue.switch id=1,2,3 on=True

   salt.proxy.philips_hue.call_temperature(*args, **kwargs)
          Set      the      mired      color      temperature.       More:
          http://en.wikipedia.org/wiki/Mired

          Arguments:

          * value: 150~500.

          Options:

          * id:  Specifies  a  device ID. Can be a comma-separated values.
            All, if omitted.

          CLI Example:

             salt '*' hue.temperature value=150
             salt '*' hue.temperature value=150 id=1
             salt '*' hue.temperature value=150 id=1,2,3

   salt.proxy.philips_hue.init(cnf)
          Initialize the module.

   salt.proxy.philips_hue.ping(*args, **kw)
          Ping the lamps.

   salt.proxy.philips_hue.shutdown(opts, *args, **kw)
          Shuts down the service.

   salt.proxy.rest_sample
   This is a simple proxy-minion designed to connect  to  and  communicate
   with      the     bottle-based     web     service     contained     in
   https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example

   salt.proxy.rest_sample.grains()
          Get the grains from the proxied device

   salt.proxy.rest_sample.grains_refresh()
          Refresh the grains from the proxied device

   salt.proxy.rest_sample.id(opts)
          Return  a  unique  ID  for  this proxy minion.  This ID MUST NOT
          CHANGE.   If  it  changes  while  the  proxy  is   running   the
          salt-master  will  get  really  confused and may stop talking to
          this minion

   salt.proxy.rest_sample.initialized()
          Since grains are loaded in many different  places  and  some  of
          those  places  occur before the proxy can be initialized, return
          whether our init() function has been called

   salt.proxy.rest_sample.package_install(name, **kwargs)
          Install a "package" on the REST server

   salt.proxy.rest_sample.package_list()
          List "packages" installed on the REST server

   salt.proxy.rest_sample.package_remove(name)
          Remove a "package" on the REST server

   salt.proxy.rest_sample.package_status(name)
          Check the installation status of a package on the REST server

   salt.proxy.rest_sample.ping()
          Is the REST server up?

   salt.proxy.rest_sample.service_list()
          List "services" on the REST server

   salt.proxy.rest_sample.service_restart(name)
          Restart a "service" on the REST server

   salt.proxy.rest_sample.service_start(name)
          Start a "service" on the REST server

   salt.proxy.rest_sample.service_status(name)
          Check if a service is running on the REST server

   salt.proxy.rest_sample.service_stop(name)
          Stop a "service" on the REST server

   salt.proxy.rest_sample.shutdown(opts)
          For this proxy shutdown is a no-op

   salt.proxy.rest_sample.uptodate(name)
          Call the REST endpoint to see if the packages  on  the  "server"
          are up to date.

   salt.proxy.ssh_sample
   This  is  a  simple proxy-minion designed to connect to and communicate
   with a server that exposes functionality via SSH.  This can be used  as
   an option when the device does not provide an api over HTTP and doesn't
   have the python stack to run a minion.

   salt.proxy.ssh_sample.grains()
          Get the grains from the proxied device

   salt.proxy.ssh_sample.grains_refresh()
          Refresh the grains from the proxied device

   salt.proxy.ssh_sample.init(opts)
          Required.  Can be used to initialize the server connection.

   salt.proxy.ssh_sample.initialized()
          Since grains are loaded in many different  places  and  some  of
          those  places  occur before the proxy can be initialized, return
          whether our init() function has been called

   salt.proxy.ssh_sample.package_install(name, **kwargs)
          Install a "package" on the ssh server

   salt.proxy.ssh_sample.package_list()
          List "packages" by executing a command via ssh This function  is
          called in response to the salt command

          ..code-block::bash
                 salt target_minion pkg.list_pkgs

   salt.proxy.ssh_sample.package_remove(name)
          Remove a "package" on the ssh server

   salt.proxy.ssh_sample.parse(out)
          Extract json from out.

          Parameter
                 out: Type string. The data returned by the ssh command.

   salt.proxy.ssh_sample.ping()
          Required.  Ping the device on the other end of the connection

   salt.proxy.ssh_sample.service_list()
          Start a "service" on the ssh server

          New in version 2015.8.2.

   salt.proxy.ssh_sample.service_restart(name)
          Restart a "service" on the ssh server

          New in version 2015.8.2.

   salt.proxy.ssh_sample.service_start(name)
          Start a "service" on the ssh server

          New in version 2015.8.2.

   salt.proxy.ssh_sample.service_stop(name)
          Stop a "service" on the ssh server

          New in version 2015.8.2.

   salt.proxy.ssh_sample.shutdown(opts)
          Disconnect

   queue modules
                 
                 pgjsonb_queue  New in version 2016.3.0. 
                 
                 sqlite_queue   New in version 2014.7.0. 
                 

   salt.queues.pgjsonb_queue module
   New in version 2016.3.0.

   This  is a queue with postgres as the backend.  It uses the jsonb store
   to store information for queues.

   depends
          python-psycopg2

   To enable this queue, the following needs  to  be  configured  in  your
   master config. These are the defaults:

      queue.pgjsonb.host: 'salt'
      queue.pgjsonb.user: 'salt'
      queue.pgjsonb.pass: 'salt'
      queue.pgjsonb.db: 'salt'
      queue.pgjsonb.port: 5432

   Use the following Pg database schema:

      CREATE DATABASE  salt WITH ENCODING 'utf-8';

      --
      -- Table structure for table `salt`
      --
      DROP TABLE IF EXISTS salt;
      CREATE OR REPLACE TABLE salt(
         id SERIAL PRIMARY KEY,
         data jsonb NOT NULL
      );

      salt-run queue.insert test '{"name": "redis", "host": "172.16.0.8", "port": 6379}' backend=pgjsonb
      salt-run queue.process_queue test all backend=pgjsonb

   salt.queues.pgjsonb_queue.delete(queue, items)
          Delete an item or items from a queue

   salt.queues.pgjsonb_queue.insert(queue, items)
          Add an item or items to a queue

   salt.queues.pgjsonb_queue.list_items(queue)
          List contents of a queue

   salt.queues.pgjsonb_queue.list_length(queue)
          Provide the number of items in a queue

   salt.queues.pgjsonb_queue.list_queues()
          Return a list of Salt Queues on the Salt Master

   salt.queues.pgjsonb_queue.pop(queue, quantity=1)
          Pop one or more or all items from the queue return them.

   salt.queues.sqlite_queue module
   New in version 2014.7.0.

   This  is  the  default  local  master  event queue built on sqlite.  By
   default, an sqlite3 database file is created  in  the  sqlite_queue_dir
   which is found at:

      /var/cache/salt/master/queues

   It's   possible   to  store  the  sqlite3  database  files  by  setting
   sqlite_queue_dir to another location:

      sqlite_queue_dir: /home/myuser/salt/master/queues

   salt.queues.sqlite_queue.delete(queue, items)
          Delete an item or items from a queue

   salt.queues.sqlite_queue.insert(queue, items)
          Add an item or items to a queue

   salt.queues.sqlite_queue.list_items(queue)
          List contents of a queue

   salt.queues.sqlite_queue.list_length(queue)
          Provide the number of items in a queue

   salt.queues.sqlite_queue.list_queues()
          Return a list of Salt Queues on the Salt Master

   salt.queues.sqlite_queue.pop(queue, quantity=1)
          Pop one or more or all items from the queue return them.

   roster modules
                 
                 ansible       Read   in    an    Ansible 
                               inventory file or script   
                 
                 cache         Use  the  minion  cache on 
                               the master  to  derive  IP 
                               addresses  based on minion 
                               ID.                        
                 
                 cloud         Use the cloud cache on the 
                               master   to   derive  IPv4 
                               addresses based on  minion 
                               ID.                        
                 
                 clustershell  This    roster    resolves 
                               hostname       in        a 
                               pdsh/clustershell style.   
                 
                 flat          Read  in the roster from a 
                               flat   file   using    the 
                               renderer system            
                 
                 range         This    roster    resolves 
                               targets   from   a   range 
                               server.                    
                 
                 scan          Scan  a  netmask or ipaddr 
                               for open ssh ports         
                 

   salt.roster.ansible
   Read in an Ansible inventory file or script

   Flat inventory files should be in the regular ansible inventory format.

      [servers]
      salt.gtmanfred.com ansible_ssh_user=gtmanfred ansible_ssh_host=127.0.0.1 ansible_ssh_port=22 ansible_ssh_pass='password'

      [desktop]
      home ansible_ssh_user=gtmanfred ansible_ssh_host=12.34.56.78 ansible_ssh_port=23 ansible_ssh_pass='password'

      [computers:children]
      desktop
      servers

      [names:vars]
      http_port=80

   then salt-ssh can be used to hit any of them

      [~]# salt-ssh all test.ping
      salt.gtmanfred.com:
          True
      home:
          True
      [~]# salt-ssh desktop test.ping
      home:
          True
      [~]# salt-ssh computers test.ping
      salt.gtmanfred.com:
          True
      home:
          True
      [~]# salt-ssh salt.gtmanfred.com test.ping
      salt.gtmanfred.com:
          True

   There is also  the  option  of  specifying  a  dynamic  inventory,  and
   generating it on the fly

      #!/bin/bash
      echo '{
        "servers": {
          "hosts": [
            "salt.gtmanfred.com"
          ]
        },
        "desktop": {
          "hosts": [
            "home"
          ]
        },
        "computers": {
          "hosts":{},
          "children": [
            "desktop",
            "servers"
          ]
        },
        "_meta": {
          "hostvars": {
            "salt.gtmanfred.com": {
              "ansible_ssh_user": "gtmanfred",
              "ansible_ssh_host": "127.0.0.1",
              "ansible_sudo_pass": "password",
              "ansible_ssh_port": 22
            },
            "home": {
              "ansible_ssh_user": "gtmanfred",
              "ansible_ssh_host": "12.34.56.78",
              "ansible_sudo_pass": "password",
              "ansible_ssh_port": 23
            }
          }
        }
      }'

   This  is  the  format  that an inventory script needs to output to work
   with ansible, and thus here.

      [~]# salt-ssh --roster-file /etc/salt/hosts salt.gtmanfred.com test.ping
      salt.gtmanfred.com:
              True

   Any of the [groups] or direct hostnames  will  return.   The  'all'  is
   special, and returns everything.

   class        salt.roster.ansible.Inventory(tgt,        tgt_type='glob',
   inventory_file='/etc/salt/roster')
          Matcher for static inventory files

   class         salt.roster.ansible.Script(tgt,          tgt_type='glob',
   inventory_file='/etc/salt/roster')
          Matcher for Inventory scripts

   salt.roster.ansible.targets(tgt, tgt_type='glob', **kwargs)
          Return  the  targets  from  the  ansible inventory_file Default:
          /etc/salt/roster

   salt.roster.cache
   Use the minion cache on the master to  derive  IP  addresses  based  on
   minion ID.

   Currently  only  contains  logic  to  return  an IPv4 address; does not
   handle IPv6, or authentication (passwords, keys, etc).

   It is possible to configure this roster to prefer a particular type  of
   IP  over  another.  To configure the order, set the roster_order in the
   master config file. The default for this is:

      roster_order:
        - public
        - private
        - local

   salt.roster.cache.extract_ipv4(roster_order, ipv4)
          Extract the preferred IP address from the ipv4 grain

   salt.roster.cache.targets(tgt, tgt_type='glob', **kwargs)
          Return the targets from the flat  yaml  file,  checks  opts  for
          location but defaults to /etc/salt/roster

   salt.roster.cloud
   Use  the  cloud  cache  on the master to derive IPv4 addresses based on
   minion ID.

   This roster requires that the minion in question was created  using  at
   least  the  2015.5.0  version of Salt Cloud. Starting with the 2015.5.0
   release, Salt Cloud maintains an index of minions that it  creates  and
   deletes.  This index tracks the provider and profile configuration used
   to provision the minion, including authentication information. So  long
   as  this  configuration  remains current, it can be used by Salt SSH to
   log into any minion in the index.

   To connect as a user other than root, modify  the  cloud  configuration
   file   usually   located  at  /etc/salt/cloud.  For  example,  add  the
   following:

      ssh_username: my_user
      sudo: True

   salt.roster.cloud.extract_ipv4(roster_order, ipv4)
          Extract the preferred IP address from the ipv4 grain

   salt.roster.cloud.targets(tgt, tgt_type='glob', **kwargs)
          Return the targets from the flat  yaml  file,  checks  opts  for
          location but defaults to /etc/salt/roster

   salt.roster.clustershell
   This roster resolves hostname in a pdsh/clustershell style.

   depends
          clustershell, https://github.com/cea-hpc/clustershell

   When  you  want  to  use  host  globs for target matching, use --roster
   clustershell. For example:

      salt-ssh --roster clustershell 'server_[1-10,21-30],test_server[5,7,9]' test.ping

   salt.roster.clustershell.targets(tgt, tgt_type='glob', **kwargs)
          Return the targets

   salt.roster.flat
   Read in the roster from a flat file using the renderer system

   class salt.roster.flat.RosterMatcher(raw, tgt, tgt_type, ipv='ipv4')
          Matcher for the roster data structure

          get_data(minion)
                 Return the configured ip

          ret_glob_minions()
                 Return minions that match via glob

          ret_list_minions()
                 Return minions that match via list

          ret_nodegroup_minions()
                 Return minions which match the special  list-only  groups
                 defined by ssh_list_nodegroups

          ret_pcre_minions()
                 Return minions that match via pcre

          ret_range_minions()
                 Return minions that are returned by a range query

          targets()
                 Execute the correct tgt_type routine and return

   salt.roster.flat.targets(tgt, tgt_type='glob', **kwargs)
          Return  the  targets  from  the  flat yaml file, checks opts for
          location but defaults to /etc/salt/roster

   salt.roster.range module
   This roster resolves targets from a range server.

   depends
          seco.range, https://github.com/ytoolshed/range

   When you want to use a range query for target  matching,  use  --roster
   range. For example:

      salt-ssh --roster range '%%%example.range.cluster' test.ping

   salt.roster.range.targets(tgt, tgt_type='range', **kwargs)
          Return the targets from a range query

   salt.roster.scan
   Scan a netmask or ipaddr for open ssh ports

   class salt.roster.scan.RosterMatcher(tgt, tgt_type)
          Matcher for the roster data structure

          targets()
                 Return  ip  addrs based on netmask, sitting in the "glob"
                 spot because it is the default

   salt.roster.scan.targets(tgt, tgt_type='glob', **kwargs)
          Return the targets from the flat  yaml  file,  checks  opts  for
          location but defaults to /etc/salt/roster

   runner modules
                  
                  asam        Novell ASAM Runner         
                  
                  cache       Return  cached  data  from 
                              minions                    
                  
                  cloud       The Salt Cloud Runner      
                  
                  ddns        Dynamic DNS Runner         
                  
                  doc         A runner module to collect 
                              and   display  the  inline 
                              documentation from the     
                  
                  drac        Manage Dell DRAC from  the 
                              Master                     
                  
                  error       Error  generator to enable 
                              integration   testing   of 
                              salt runner error handling 
                  
                  f5          Runner  to provide F5 Load 
                              Balancer functionality     
                  
                  fileserver  Directly manage  the  Salt 
                              fileserver plugins         
                  
                  git_pillar  Runner  module to directly 
                              manage  the  git  external 
                              pillar                     
                  
                  http        Module  for making various 
                              web calls.                 
                  
                  jobs        A  convenience  system  to 
                              manage  jobs,  both active 
                              and already run            
                  
                  launchd     Manage launchd plist files 
                  
                  lxc         Control  Linux  Containers 
                              via Salt                   
                  
                  manage      General         management 
                              functions for salt,  tools 
                              like seeing what hosts are 
                              up                         
                  
                  mine        A runner  to  access  data 
                              from the salt mine         
                  
                  nacl        This  runner  helps create 
                              encrypted  passwords  that 
                              can    be    included   in 
                              pillars.                   
                  
                  network     Network tools to run  from 
                              the Master                 
                  
                  pagerduty   Runner  Module  for Firing 
                              Events via PagerDuty       
                  
                  pillar      Functions to interact with 
                              the pillar compiler on the 
                              master                     
                  
                  pkg         Package  helper  functions 
                              using salt.modules.pkg     
                  
                  queue       General   management   and 
                              processing of queues.      
                  
                  reactor     A  convenience  system  to 
                              manage reactors            
                  
                  salt        New in version 2016.11.0.  
                  
                  saltutil    Sync  custom  types to the 
                              Master                     
                  
                  sdb         Runner  for  setting   and 
                              querying  data via the sdb 
                              API on the master          
                  
                  search      Runner frontend to  search 
                              system                     
                  
                  spacewalk   Spacewalk Runner           
                  
                  ssh         A  Runner module interface 
                              on  top  of  the  salt-ssh 
                              Python API.                
                  
                  state       Execute      orchestration 
                              functions                  
                  
                  survey      A general map/reduce style 
                              salt       runner      for 
                              aggregating        results 
                              returned     by    several 
                              different minions.         
                  
                  test        This runner is  used  only 
                              for   test   purposes  and 
                              servers   no    production 
                              purpose                    
                  
                  thin        The thin runner is used to 
                              manage   the   salt   thin 
                              systems.                   
                  
                  virt        Control  virtual  machines 
                              via Salt                   
                  
                  winrepo     Runner to  manage  Windows 
                              software repo              
                  

   salt.runners.asam
   Novell ASAM Runner
   New in version Beryllium.

   Runner to interact with Novell ASAM Fan-Out Driver

   codeauthor
          Nitin Madhok <[email protected]>

   To  use this runner, set up the Novell Fan-Out Driver URL, username and
   password  in  the   master   configuration   at   /etc/salt/master   or
   /etc/salt/master.d/asam.conf:

      asam:
        prov1.domain.com
          username: "testuser"
          password: "verybadpass"
        prov2.domain.com
          username: "testuser"
          password: "verybadpass"

   NOTE:
      Optionally, protocol and port can be specified if the Fan-Out Driver
      server is not using the defaults. Default  is  protocol:  https  and
      port: 3451.

   salt.runners.asam.add_platform(name, platform_set, server_url)
          To add an ASAM platform using the specified ASAM platform set on
          the Novell Fan-Out Driver

          CLI Example:

             salt-run asam.add_platform my-test-vm test-platform-set prov1.domain.com

   salt.runners.asam.list_platform_sets(server_url)
          To list all ASAM platform sets present  on  the  Novell  Fan-Out
          Driver

          CLI Example:

             salt-run asam.list_platform_sets prov1.domain.com

   salt.runners.asam.list_platforms(server_url)
          To list all ASAM platforms present on the Novell Fan-Out Driver

          CLI Example:

             salt-run asam.list_platforms prov1.domain.com

   salt.runners.asam.remove_platform(name, server_url)
          To remove specified ASAM platform from the Novell Fan-Out Driver

          CLI Example:

             salt-run asam.remove_platform my-test-vm prov1.domain.com

   salt.runners.cache
   Return cached data from minions

   salt.runners.cache.clear_all(tgt=None, expr_form='glob')
          Clear  the  cached pillar, grains, and mine data of the targeted
          minions

          CLI Example:

             salt-run cache.clear_all

   salt.runners.cache.clear_git_lock(role, remote=None, **kwargs)
          New in version 2015.8.2.

          Remove the update locks for Salt components (gitfs,  git_pillar,
          winrepo) which use gitfs backend code from salt.utils.gitfs.

          NOTE:
             Running  cache.clear_all will not include this function as it
             does for pillar, grains, and mine.

             Additionally, executing this function with a role of gitfs is
             equivalent    to   running   salt-run   fileserver.clear_lock
             backend=git.

          role   Which type of  lock  to  remove  (gitfs,  git_pillar,  or
                 winrepo)

          remote If  specified,  then any remotes which contain the passed
                 string will have  their  lock  cleared.  For  example,  a
                 remote  value  of  github  will  remove the lock from all
                 github.com remotes.

          type   update,checkout The  types  of  lock  to  clear.  Can  be
                 update, checkout, or both of

          et (either comma-separated or as a Python list).
             New in version 2015.8.8.

          CLI Example:

             salt-run cache.clear_git_lock git_pillar

   salt.runners.cache.clear_grains(tgt=None, expr_form='glob')
          Clear the cached grains data of the targeted minions

          CLI Example:

             salt-run cache.clear_grains

   salt.runners.cache.clear_mine(tgt=None, expr_form='glob')
          Clear the cached mine data of the targeted minions

          CLI Example:

             salt-run cache.clear_mine

   salt.runners.cache.clear_mine_func(tgt=None,          expr_form='glob',
   clear_mine_func_flag=None)
          Clear the cached mine function data of the targeted minions

          CLI Example:

             salt-run cache.clear_mine_func tgt='*' clear_mine_func_flag='network.interfaces'

   salt.runners.cache.clear_pillar(tgt=None, expr_form='glob')
          Clear the cached pillar data of the targeted minions

          CLI Example:

             salt-run cache.clear_pillar

   salt.runners.cache.grains(tgt=None, expr_form='glob', **kwargs)
          Return cached grains of the targeted minions

          CLI Example:

             salt-run cache.grains

   salt.runners.cache.mine(tgt=None, expr_form='glob', **kwargs)
          Return cached mine data of the targeted minions

          CLI Example:

             salt-run cache.mine

   salt.runners.cache.pillar(tgt=None, expr_form='glob', **kwargs)
          Return cached pillars of the targeted minions

          CLI Example:

             salt-run cache.pillar

   salt.runners.cloud
   The Salt Cloud Runner
   This runner wraps the functionality of salt  cloud  making  salt  cloud
   routines available to all internal apis via the runner system

   salt.runners.cloud.action(func=None,   cloudmap=None,   instances=None,
   provider=None, instance=None, **kwargs)
          Execute a single action on the given map/provider/instance

          CLI Example:

             salt-run cloud.action start my-salt-vm

   salt.runners.cloud.create(provider, instances, opts=None, **kwargs)
          Create an instance using Salt Cloud

          CLI Example:

             salt-run cloud.create my-ec2-config myinstance             image=ami-1624987f size='t1.micro' ssh_username=ec2-user             securitygroup=default delvol_on_destroy=True

   salt.runners.cloud.destroy(instances)
          Destroy the named vm(s)

   salt.runners.cloud.full_query(query_type='list_nodes_full')
          List all available cloud provider data

   salt.runners.cloud.list_images(provider='all')
          List cloud provider images for the given providers

   salt.runners.cloud.list_locations(provider='all')
          List cloud provider sizes for the given providers

   salt.runners.cloud.list_sizes(provider='all')
          List cloud provider sizes for the given providers

   salt.runners.cloud.map_run(path, **kwargs)
          Execute a salt cloud map file

   salt.runners.cloud.profile(prof=None,    instances=None,     opts=None,
   **kwargs)
          Create  a  cloud  vm  with  the  given  profile  and  instances,
          instances can be a list or comma-delimited string

          CLI Example:

             salt-run cloud.profile prof=my-ec2 instances=node1,node2,node3

   salt.runners.cloud.query(query_type='list_nodes')
          List cloud provider data for all providers

   salt.runners.cloud.select_query(query_type='list_nodes_select')
          List selected nodes

   salt.runners.ddns
   Dynamic DNS Runner
   New in version Beryllium.

   Runner to interact with DNS server and create/delete/update DNS records

   codeauthor
          Nitin Madhok <[email protected]>

   salt.runners.ddns.add_host(zone,  name,  ttl,  ip,  keyname,   keyfile,
   nameserver, timeout, port=53, keyalgorithm='hmac-md5')
          Create both A and PTR (reverse) records for a host.

          CLI Example:

             salt-run ddns.add_host domain.com my-test-vm 3600 10.20.30.40 my-tsig-key /etc/salt/tsig.keyring 10.0.0.1 5

   salt.runners.ddns.create(zone,   name,   ttl,  rdtype,  data,  keyname,
   keyfile, nameserver, timeout, port=53, keyalgorithm='hmac-md5')
          Create a DNS record. The nameserver must be an  IP  address  and
          the  master  running  this runner must have create privileges on
          that server.

          CLI Example:

             salt-run ddns.create domain.com my-test-vm 3600 A 10.20.30.40 my-tsig-key /etc/salt/tsig.keyring 10.0.0.1 5

   salt.runners.ddns.delete(zone,  name,  keyname,  keyfile,   nameserver,
   timeout, rdtype=None, data=None, port=53, keyalgorithm='hmac-md5')
          Delete a DNS record.

          CLI Example:

             salt-run ddns.delete domain.com my-test-vm my-tsig-key /etc/salt/tsig.keyring 10.0.0.1 5 A

   salt.runners.ddns.delete_host(zone, name, keyname, keyfile, nameserver,
   timeout, port=53, keyalgorithm='hmac-md5')
          Delete both forward (A) and reverse (PTR)  records  for  a  host
          only if the forward (A) record exists.

          CLI Example:

             salt-run ddns.delete_host domain.com my-test-vm my-tsig-key /etc/salt/tsig.keyring 10.0.0.1 5

   salt.runners.ddns.update(zone,   name,   ttl,  rdtype,  data,  keyname,
   keyfile,     nameserver,     timeout,      replace=False,      port=53,
   keyalgorithm='hmac-md5')
          Replace,  or  update  a DNS record. The nameserver must be an IP
          address and the master running  this  runner  must  have  update
          privileges on that server.

          NOTE:
             If replace is set to True, all records for this name and type
             will  first  be  deleted  and  then  recreated.  Default   is
             replace=False.

          CLI Example:

             salt-run ddns.update domain.com my-test-vm 3600 A 10.20.30.40 my-tsig-key /etc/salt/tsig.keyring 10.0.0.1 5

   salt.runners.doc
   A  runner  module  to collect and display the inline documentation from
   the various module types

   salt.runners.doc.execution()
          Collect all the sys.doc output from each minion and  return  the
          aggregate

          CLI Example:

             salt-run doc.execution

   salt.runners.doc.runner()
          Return all inline documentation for runner modules

          CLI Example:

             salt-run doc.runner

   salt.runners.doc.wheel()
          Return all inline documentation for wheel modules

          CLI Example:

             salt-run doc.wheel

   salt.runners.drac
   Manage Dell DRAC from the Master

   The  login  credentials  need  to  be  configured  in  the  Salt master
   configuration file.

   salt.runners.drac.poweroff(hostname,     timeout=20,     username=None,
   password=None)
          Power server off

          CLI Example:

             salt-run drac.poweroff example.com

   salt.runners.drac.poweron(hostname,      timeout=20,     username=None,
   password=None)
          Power server on

          CLI Example:

             salt-run drac.poweron example.com

   salt.runners.drac.pxe(hostname,       timeout=20,        username=None,
   password=None)
          Connect  to the Dell DRAC and have the boot order set to PXE and
          power cycle the system to PXE boot

          CLI Example:

             salt-run drac.pxe example.com

   salt.runners.drac.reboot(hostname,      timeout=20,      username=None,
   password=None)
          Reboot a server using the Dell DRAC

          CLI Example:

             salt-run drac.reboot example.com

   salt.runners.drac.version(hostname,      timeout=20,     username=None,
   password=None)
          Display the version of DRAC

          CLI Example:

             salt-run drac.version example.com

   salt.runners.error
   Error generator to enable integration  testing  of  salt  runner  error
   handling

   salt.runners.error.error(name=None, message='')
          If name is None Then return empty dict

          Otherwise  raise  an  exception with __name__ from name, message
          from message

          CLI Example:

             salt-run error
             salt-run error.error name="Exception" message="This is an error."

   salt.runners.f5
   Runner to provide F5 Load Balancer functionality

   depends

          * pycontrol Python module

   configuration
          In order to connect to a F5 Load Balancer, you must  specify  in
          the  Salt  master  configuration  the  currently  available load
          balancers

             load_balancers:
               bigip1.example.com
                 username: admin
                 password: secret
               bigip2.example.com:
                 username: admin
                 password: secret

   salt.runners.f5.add_pool_member(lb, name, port, pool_name)
          Add a node to a pool

          CLI Examples:

             salt-run f5.add_pool_member load_balancer 10.0.0.1 80 my_pool

   salt.runners.f5.check_member_pool(lb, member, pool_name)
          Check a pool member exists in a specific pool

          CLI Examples:

             salt-run f5.check_member_pool load_balancer 10.0.0.1 my_pool

   salt.runners.f5.check_pool(lb, name)
          Check to see if a pool exists

          CLI Examples:

             salt-run f5.check_pool load_balancer pool_name

   salt.runners.f5.check_virtualserver(lb, name)
          Check to see if a virtual server exists

          CLI Examples:

             salt-run f5.check_virtualserver load_balancer virtual_server

   salt.runners.f5.create_pool(lb, name, method='ROUND_ROBIN')
          Create a pool on the F5 load balancer

          CLI Examples:

             salt-run f5.create_pool load_balancer pool_name loadbalance_method
             salt-run f5.create_pool load_balancer my_pool ROUND_ROBIN

   salt.runners.f5.create_vs(lb,  name,  ip,  port,   protocol,   profile,
   pool_name)
          Create a virtual server

          CLI Examples:

             salt-run f5.create_vs lbalancer vs_name 10.0.0.1 80 tcp http poolname

   salt.runners.fileserver
   Directly manage the Salt fileserver plugins

   salt.runners.fileserver.clear_cache(backend=None)
          New in version 2015.5.0.

          Clear  the  fileserver  cache from VCS fileserver backends (git,
          hg, svn). Executing this runner with no arguments will clear the
          cache  for  all enabled VCS fileserver backends, but this can be
          narrowed using the backend argument.

          backend
                 Only clear the update lock for the specified  backend(s).
                 If  all passed backends start with a minus sign (-), then
                 these  backends  will  be  excluded  from   the   enabled
                 backends. However, if there is a mix of backends with and
                 without a minus sign (ex:  backend=-roots,git)  then  the
                 ones starting with a minus sign will be disregarded.

          CLI Example:

             salt-run fileserver.clear_cache
             salt-run fileserver.clear_cache backend=git,hg
             salt-run fileserver.clear_cache hg
             salt-run fileserver.clear_cache -roots

   salt.runners.fileserver.clear_file_list_cache(saltenv=None,
   backend=None)
          New in version 2016.11.0.

          The Salt fileserver caches  the  files/directories/symlinks  for
          each  fileserver  backend and environment as they are requested.
          This is done to help the fileserver scale better.  Without  this
          caching,  when  hundreds/thousands of minions simultaneously ask
          the master what  files  are  available,  this  would  cause  the
          master's  CPU  load  to spike as it obtains the same information
          separately for each minion.

          saltenv
                 By default, this runner will clear the file  list  caches
                 for  all environments. This argument allows for a list of
                 environments to be passed,  to  clear  more  selectively.
                 This  list  can  be  passed  either  as a comma-separated
                 string, or a Python list.

          backend
                 Similar to the  saltenv  parameter,  this  argument  will
                 restrict   the  cache  clearing  to  specific  fileserver
                 backends (the default  behavior  is  to  clear  from  all
                 enabled  fileserver  backends).  This  list can be passed
                 either as a comma-separated string, or a Python list.

          Since the ability to clear these caches  is  often  required  by
          users writing custom runners which add/remove files, this runner
          can easily be called from within a custom runner  using  any  of
          the following examples:

             # Clear all file list caches
             __salt__['fileserver.clear_file_list_cache']()
             # Clear just the 'base' saltenv file list caches
             __salt__['fileserver.clear_file_list_cache'](saltenv='base')
             # Clear just the 'base' saltenv file list caches from just the 'roots'
             # fileserver backend
             __salt__['fileserver.clear_file_list_cache'](saltenv='base', backend='roots')
             # Clear all file list caches from the 'roots' fileserver backend
             __salt__['fileserver.clear_file_list_cache'](backend='roots')

          NOTE:
             In runners, the __salt__ dictionary will likely be renamed to
             __runner__ in a future Salt  release  to  distinguish  runner
             functions  from  remote  execution functions. See this GitHub
             issue for discussion/updates on this.

          If using  Salt's  Python  API  (not  a  runner),  the  following
          examples are equivalent to the ones above:

             import salt.config
             import salt.runner

             opts = salt.config.master_config('/etc/salt/master')
             opts['fun'] = 'fileserver.clear_file_list_cache'

             # Clear all file list_caches
             opts['arg'] = []  # No arguments
             runner = salt.runner.Runner(opts)
             cleared = runner.run()

             # Clear just the 'base' saltenv file list caches
             opts['arg'] = ['base', None]
             runner = salt.runner.Runner(opts)
             cleared = runner.run()

             # Clear just the 'base' saltenv file list caches from just the 'roots'
             # fileserver backend
             opts['arg'] = ['base', 'roots']
             runner = salt.runner.Runner(opts)
             cleared = runner.run()

             # Clear all file list caches from the 'roots' fileserver backend
             opts['arg'] = [None, 'roots']
             runner = salt.runner.Runner(opts)
             cleared = runner.run()

          This  function  will  return  a  dictionary  showing  a  list of
          environments which were  cleared  for  each  backend.  An  empty
          return dictionary means that no changes were made.

          CLI Examples:

             # Clear all file list caches
             salt-run fileserver.clear_file_list_cache
             # Clear just the 'base' saltenv file list caches
             salt-run fileserver.clear_file_list_cache saltenv=base
             # Clear just the 'base' saltenv file list caches from just the 'roots'
             # fileserver backend
             salt-run fileserver.clear_file_list_cache saltenv=base backend=roots
             # Clear all file list caches from the 'roots' fileserver backend
             salt-run fileserver.clear_file_list_cache backend=roots

   salt.runners.fileserver.clear_lock(backend=None, remote=None)
          New in version 2015.5.0.

          Clear  the  fileserver  update lock from VCS fileserver backends
          (git, hg, svn). This should only need to be done if a fileserver
          update  was interrupted and a remote is not updating (generating
          a warning in the Master's log file). Executing this runner  with
          no  arguments  will remove all update locks from all enabled VCS
          fileserver backends, but this  can  be  narrowed  by  using  the
          following arguments:

          backend
                 Only clear the update lock for the specified backend(s).

          remote If  specified,  then any remotes which contain the passed
                 string will have  their  lock  cleared.  For  example,  a
                 remote  value  of  github  will  remove the lock from all
                 github.com remotes.

          CLI Example:

             salt-run fileserver.clear_lock
             salt-run fileserver.clear_lock backend=git,hg
             salt-run fileserver.clear_lock backend=git remote=github
             salt-run fileserver.clear_lock remote=bitbucket

   salt.runners.fileserver.dir_list(saltenv='base', backend=None)
          Return a list of directories in the given environment

          saltenv
                 base The salt fileserver environment to be listed

          backend
                 Narrow fileserver backends to a  subset  of  the  enabled
                 ones. If all passed backends start with a minus sign (-),
                 then these backends will be  excluded  from  the  enabled
                 backends. However, if there is a mix of backends with and
                 without a minus sign (ex:  backend=-roots,git)  then  the
                 ones starting with a minus sign will be disregarded.

                 New in version 2015.5.0.

          CLI Example:

             salt-run fileserver.dir_list
             salt-run fileserver.dir_list saltenv=prod
             salt-run fileserver.dir_list saltenv=dev backend=git
             salt-run fileserver.dir_list base hg,roots
             salt-run fileserver.dir_list -git

   salt.runners.fileserver.empty_dir_list(saltenv='base', backend=None)
          New in version 2015.5.0.

          Return a list of empty directories in the given environment

          saltenv
                 base The salt fileserver environment to be listed

          backend
                 Narrow  fileserver  backends  to  a subset of the enabled
                 ones. If all passed backends start with a minus sign (-),
                 then  these  backends  will  be excluded from the enabled
                 backends. However, if there is a mix of backends with and
                 without  a  minus  sign (ex: backend=-roots,git) then the
                 ones starting with a minus sign will be disregarded.

                 NOTE:
                    Some backends (such as git  and  hg)  do  not  support
                    empty   directories.    So,   passing  backend=git  or
                    backend=hg  will  result  in  an  empty   list   being
                    returned.

          CLI Example:

             salt-run fileserver.empty_dir_list
             salt-run fileserver.empty_dir_list saltenv=prod
             salt-run fileserver.empty_dir_list backend=roots

   salt.runners.fileserver.envs(backend=None, sources=False)
          Return  the  available fileserver environments. If no backend is
          provided, then the environments for all configured backends will
          be returned.

          backend
                 Narrow  fileserver  backends  to  a subset of the enabled
                 ones.

                 Changed in version 2015.5.0: If all passed backends start
                 with  a  minus  sign  (-),  then  these  backends will be
                 excluded from the enabled backends. However, if there  is
                 a  mix  of  backends  with  and without a minus sign (ex:
                 backend=-roots,git) then the ones starting with  a  minus
                 sign will be disregarded.

                 Additionally,  fileserver backends can now be passed as a
                 comma-separated list. In earlier versions, they needed to
                 be  passed  as  a  python  list  (ex:  backend="['roots',
                 'git']")

          CLI Example:

             salt-run fileserver.envs
             salt-run fileserver.envs backend=roots,git
             salt-run fileserver.envs git

   salt.runners.fileserver.file_list(saltenv='base', backend=None)
          Return a list of files from the salt fileserver

          saltenv
                 base The salt fileserver environment to be listed

          backend
                 Narrow fileserver backends to a  subset  of  the  enabled
                 ones. If all passed backends start with a minus sign (-),
                 then these backends will be  excluded  from  the  enabled
                 backends. However, if there is a mix of backends with and
                 without a minus sign (ex:  backend=-roots,git)  then  the
                 ones starting with a minus sign will be disregarded.

                 New in version 2015.5.0.

          CLI Examples:

             salt-run fileserver.file_list
             salt-run fileserver.file_list saltenv=prod
             salt-run fileserver.file_list saltenv=dev backend=git
             salt-run fileserver.file_list base hg,roots
             salt-run fileserver.file_list -git

   salt.runners.fileserver.lock(backend=None, remote=None)
          New in version 2015.5.0.

          Set  a  fileserver update lock for VCS fileserver backends (git,
          hg, svn).

          NOTE:
             This will only operate on enabled backends (those  configured
             in fileserver_backend).

          backend
                 Only set the update lock for the specified backend(s).

          remote If  not  None,  then any remotes which contain the passed
                 string will have  their  lock  cleared.  For  example,  a
                 remote  value  of  *github.com* will remove the lock from
                 all github.com remotes.

          CLI Example:

             salt-run fileserver.lock
             salt-run fileserver.lock backend=git,hg
             salt-run fileserver.lock backend=git remote='*github.com*'
             salt-run fileserver.lock remote=bitbucket

   salt.runners.fileserver.symlink_list(saltenv='base', backend=None)
          Return a list of symlinked files and dirs

          saltenv
                 base The salt fileserver environment to be listed

          backend
                 Narrow fileserver backends to a  subset  of  the  enabled
                 ones. If all passed backends start with a minus sign (-),
                 then these backends will be  excluded  from  the  enabled
                 backends. However, if there is a mix of backends with and
                 without a minus sign (ex:  backend=-roots,git)  then  the
                 ones starting with a minus sign will be disregarded.

                 New in version 2015.5.0.

          CLI Example:

             salt-run fileserver.symlink_list
             salt-run fileserver.symlink_list saltenv=prod
             salt-run fileserver.symlink_list saltenv=dev backend=git
             salt-run fileserver.symlink_list base hg,roots
             salt-run fileserver.symlink_list -git

   salt.runners.fileserver.update(backend=None)
          Update the fileserver cache. If no backend is provided, then the
          cache for all configured backends will be updated.

          backend
                 Narrow fileserver backends to a  subset  of  the  enabled
                 ones.

                 Changed in version 2015.5.0: If all passed backends start
                 with a minus  sign  (-),  then  these  backends  will  be
                 excluded  from the enabled backends. However, if there is
                 a mix of backends with and  without  a  minus  sign  (ex:
                 backend=-roots,git)  then  the ones starting with a minus
                 sign will be disregarded.

                 Additionally, fileserver backends can now be passed as  a
                 comma-separated list. In earlier versions, they needed to
                 be  passed  as  a  python  list  (ex:  backend="['roots',
                 'git']")

          CLI Example:

             salt-run fileserver.update
             salt-run fileserver.update backend=roots,git

   salt.runners.git_pillar
   Runner module to directly manage the git external pillar

   salt.runners.git_pillar.update(branch=None, repo=None)
          New in version 2014.1.0.

          Changed  in  version 2015.8.4: This runner function now supports
          the new git_pillar configuration schema introduced in  2015.8.0.
          Additionally,  the  branch and repo can now be omitted to update
          all git_pillar remotes. The return data has  also  changed.  For
          releases  2015.8.3  and  earlier,  there  is  no value returned.
          Starting with 2015.8.4, the return  data  is  a  dictionary.  If
          using   the   old  git_pillar  configuration  schema,  then  the
          dictionary values will be True if the update  completed  without
          error,  and  False  if  an  error  occurred.  If  using  the new
          git_pillar configuration schema, the values will be True only if
          new  commits  were fetched, and False if there were errors or no
          new commits were fetched.

          Update one or all configured git_pillar remotes.

          CLI Example:

             # Update specific branch and repo
             salt-run git_pillar.update branch='branch' repo='https://foo.com/bar.git'
             # Update all repos (2015.8.4 and later)
             salt-run git_pillar.update
             # Run with debug logging
             salt-run git_pillar.update -l debug

   salt.runners.http
   Module for making various web calls. Primarily  designed  for  webhooks
   and the like, but also useful for basic http testing.

   New in version 2015.5.0.

   salt.runners.http.query(url, output=True, **kwargs)
          Query a resource, and decode the return data

          New in version 2015.5.0.

          CLI Example:

             salt-run http.query http://somelink.com/
             salt-run http.query http://somelink.com/ method=POST             params='key1=val1&key2=val2'
             salt-run http.query http://somelink.com/ method=POST             data='<xml>somecontent</xml>'

   salt.runners.http.update_ca_bundle(target=None,            source=None,
   merge_files=None)
          Update the local CA bundle file from a URL

          New in version 2015.5.0.

          CLI Example:

             salt-run http.update_ca_bundle
             salt-run http.update_ca_bundle target=/path/to/cacerts.pem
             salt-run http.update_ca_bundle source=https://example.com/cacerts.pem

          If the target is not specified,  it  will  be  pulled  from  the
          ca_cert  configuration  variable  available to the master. If it
          cannot   be   found   there,    it    will    be    placed    at
          <<FILE_ROOTS>>/cacerts.pem.

          If  the  source  is  not  specified,  it will be pulled from the
          ca_cert_url configuration variable available to the  master.  If
          it cannot be found, it will be downloaded from the cURL website,
          using an http (not https) URL. USING THE DEFAULT URL  SHOULD  BE
          AVOIDED!

          merge_files  may  also  be specified, which includes a string or
          list of strings representing a file or files to be  appended  to
          the end of the CA bundle, once it is downloaded.

          CLI Example:

             salt-run http.update_ca_bundle merge_files=/path/to/mycert.pem

   salt.runners.jobs
   A convenience system to manage jobs, both active and already run

   salt.runners.jobs.active(display_progress=False)
          Return  a  report  on  all  actively  running jobs from a job id
          centric perspective

          CLI Example:

             salt-run jobs.active

   salt.runners.jobs.exit_success(jid, ext_source=None)
          Check if a job has been executed and exit successfully

          jid    The jid to look up.

          ext_source
                 The external job cache to use. Default: None.

          CLI Example:
             salt-run jobs.exit_success 20160520145827701627

   salt.runners.jobs.last_run(ext_source=None,             outputter=None,
   metadata=None, function=None, target=None, display_progress=False)
          New in version 2015.8.0.

          List all detectable jobs and associated functions

          CLI Example:

             salt-run jobs.last_run
             salt-run jobs.last_run target=nodename
             salt-run jobs.last_run function='cmd.run'
             salt-run jobs.last_run metadata="{'foo': 'bar'}"

   salt.runners.jobs.list_job(jid,                        ext_source=None,
   display_progress=False)
          List a specific job given by its jid

          ext_source
                 If provided, specifies which external job cache to use.

          display_progress
                 False If True, fire progress events.

                 New in version 2015.8.8.

          CLI Example:

             salt-run jobs.list_job 20130916125524463507
             salt-run jobs.list_job 20130916125524463507 --out=pprint

   salt.runners.jobs.list_jobs(ext_source=None,            outputter=None,
   search_metadata=None,     search_function=None,     search_target=None,
   start_time=None, end_time=None, display_progress=False)
          List all detectable jobs and associated functions

          ext_source
                 If provided, specifies which external job cache to use.

          FILTER OPTIONS

          NOTE:
             If more than one of the below options  are  used,  only  jobs
             which match all of the filters will be returned.

          search_metadata
                 Specify  a  dictionary to match to the job's metadata. If
                 any of the key-value pairs in this dictionary match,  the
                 job will be returned.  Example:

                    salt-run jobs.list_jobs search_metadata='{"foo": "bar", "baz": "qux"}'

          search_function
                 Can  be  passed as a string or a list. Returns jobs which
                 match  the  specified  function.  Globbing  is   allowed.
                 Example:

                    salt-run jobs.list_jobs search_function='test.*'
                    salt-run jobs.list_jobs search_function='["test.*", "pkg.install"]'

                 Changed  in  version  2015.8.8:  Multiple targets can now
                 also be passed as a comma-separated list.  For example:

                    salt-run jobs.list_jobs search_function='test.*,pkg.install'

          search_target
                 Can be passed as a string or a list. Returns  jobs  which
                 match  the  specified  minion  name. Globbing is allowed.
                 Example:

                    salt-run jobs.list_jobs search_target='*.mydomain.tld'
                    salt-run jobs.list_jobs search_target='["db*", "myminion"]'

                 Changed in version 2015.8.8:  Multiple  targets  can  now
                 also be passed as a comma-separated list.  For example:

                    salt-run jobs.list_jobs search_target='db*,myminion'

          start_time
                 Accepts  any  timestamp  supported by the dateutil Python
                 module (if this module is not  installed,  this  argument
                 will  be  ignored). Returns jobs which started after this
                 timestamp.

          end_time
                 Accepts any timestamp supported by  the  dateutil  Python
                 module  (if  this  module is not installed, this argument
                 will be ignored). Returns jobs which started before  this
                 timestamp.

          CLI Example:

             salt-run jobs.list_jobs
             salt-run jobs.list_jobs search_function='test.*' search_target='localhost' search_metadata='{"bar": "foo"}'
             salt-run jobs.list_jobs start_time='2015, Mar 16 19:00' end_time='2015, Mar 18 22:00'

   salt.runners.jobs.list_jobs_filter(count,         filter_find_job=True,
   ext_source=None, outputter=None, display_progress=False)
          List all detectable jobs and associated functions

          ext_source
                 The external job cache to use. Default: None.

          CLI Example:

             salt-run jobs.list_jobs_filter 50
             salt-run jobs.list_jobs_filter 100 filter_find_job=False

   salt.runners.jobs.lookup_jid(jid,    ext_source=None,    returned=True,
   missing=False, display_progress=False)
          Return the printout from a previously executed job

          jid    The jid to look up.

          ext_source
                 The external job cache to use. Default: None.

          returned
                 True  If  True,  include the minions that did return from
                 the command.

                 New in version 2015.8.0.

          missing
                 False If True, include the minions that  did  not  return
                 from the command.

          display_progress
                 False If True, fire progress events.

                 New in version 2015.5.0.

          CLI Example:

             salt-run jobs.lookup_jid 20130916125524463507
             salt-run jobs.lookup_jid 20130916125524463507 --out=highstate

   salt.runners.jobs.print_job(jid, ext_source=None)
          Print  a  specific job's detail given by it's jid, including the
          return data.

          CLI Example:

             salt-run jobs.print_job 20130916125524463507

   salt.runners.launchd
   Manage launchd plist files

   salt.runners.launchd.write_launchd_plist(program)
          Write a launchd plist for managing salt-master or salt-minion

          CLI Example:

             salt-run launchd.write_launchd_plist salt-master

   salt.runners.lxc
   Control Linux Containers via Salt

   depends
          lxc execution module

   salt.runners.lxc.cloud_init(names, host=None, quiet=False, **kwargs)
          Wrapper for using lxc.init in saltcloud compatibility mode

          names  Name of the containers, supports a single name or a comma
                 delimited list of names.

          host   Minion to start the container on. Required.

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          saltcloud_mode
                 init the container with the saltcloud opts format instead

   salt.runners.lxc.find_guest(name, quiet=False, path=None)
          Returns the host for a container.

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.find_guest name

   salt.runners.lxc.find_guests(names, path=None)
          Return a dict of hosts and named guests

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

   salt.runners.lxc.freeze(name, quiet=False, path=None)
          Freeze the named container

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.freeze name

   salt.runners.lxc.info(name, quiet=False, path=None)
          Returns information about a container.

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.info name

   salt.runners.lxc.init(names,      host=None,      saltcloud_mode=False,
   quiet=False, **kwargs)
          Initialize a new container

             salt-run lxc.init name host=minion_id [cpuset=cgroups_cpuset] \
                     [cpushare=cgroups_cpushare] [memory=cgroups_memory] \
                     [template=lxc_template_name] [clone=original name] \
                     [profile=lxc_profile] [network_proflile=network_profile] \
                     [nic=network_profile] [nic_opts=nic_opts] \
                     [start=(true|false)] [seed=(true|false)] \
                     [install=(true|false)] [config=minion_config] \
                     [snapshot=(true|false)]

          names  Name of the containers, supports a single name or a comma
                 delimited list of names.

          host   Minion on which to initialize the container (required)

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          saltcloud_mode
                 init the container with the saltcloud opts format instead
                 See lxc.init_interface module documentation

          cpuset cgroups cpuset.

          cpushare
                 cgroups cpu shares.

          memory cgroups memory limit, in MB

                 Changed in version 2015.5.0: If no value  is  passed,  no
                 limit  is set. In earlier Salt versions, not passing this
                 value causes a 1024MB memory limit to be set, and it  was
                 necessary to pass memory=0 to set no limit.

          template
                 Name of LXC template on which to base this container

          clone  Clone this container from an existing container

          profile
                 A LXC profile (defined in config or pillar).

          network_profile
                 Network profile to use for the container

                 New in version 2015.5.2.

          nic    Deprecated  since  version  2015.5.0: Use network_profile
                 instead

          nic_opts
                 Extra options for network interfaces. E.g.:

                 {"eth0": {"mac": "aa:bb:cc:dd:ee:ff", "ipv4": "10.1.1.1",
                 "ipv6": "2001:db8::ff00:42:8329"}}

          start  Start the newly created container.

          seed   Seed  the  container  with the minion config and autosign
                 its key.  Default: true

          install
                 If salt-minion is  not  already  installed,  install  it.
                 Default: true

          config Optional  config parameters. By default, the id is set to
                 the name of the container.

   salt.runners.lxc.list(host=None, quiet=False, path=None)
          List defined containers (running, stopped, and frozen)  for  the
          named (or all) host(s).

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.list [host=minion_id]

   salt.runners.lxc.purge(name, delete_key=True, quiet=False, path=None)
          Purge the named container and delete its minion key if  present.
          WARNING: Destroys all data associated with the container.

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.purge name

   salt.runners.lxc.start(name, quiet=False, path=None)
          Start the named container.

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.start name

   salt.runners.lxc.stop(name, quiet=False, path=None)
          Stop the named container.

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.stop name

   salt.runners.lxc.unfreeze(name, quiet=False, path=None)
          Unfreeze the named container

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             salt-run lxc.unfreeze name

   salt.runners.manage
   General management functions for salt, tools like seeing what hosts are
   up and what hosts are down

   salt.runners.manage.alived(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print a list of all minions that  are  up  according  to  Salt's
          presence detection (no commands will be sent to minions)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          CLI Example:

             salt-run manage.alived

   salt.runners.manage.allowed(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print  a  list  of  all  minions that are up according to Salt's
          presence detection (no commands will be sent to minions)

          subset None Pass in  a  CIDR  range  to  filter  minions  by  IP
                 address.

          show_ipv4
                 False  Also show the IP address each minion is connecting
                 from.

          CLI Example:

             salt-run manage.allowed

   salt.runners.manage.bootstrap(version='develop', script=None, hosts='',
   root_user=False,    script_args='',    roster='flat',    ssh_user=None,
   ssh_password=None,    ssh_priv_key=None,     tmp_dir='/tmp/.bootstrap',
   http_backend='tornado')
          Bootstrap minions with salt-bootstrap

          version
                 develop Git tag of version to install

          script https://bootstrap.saltstack.com URL containing the script
                 to execute

          hosts  Comma-separated              hosts              [example:
                 hosts='host1.local,host2.local'].  These  hosts  need  to
                 exist in the specified roster.

          root_user
                 False Prepend root@ to each host. Default changed in Salt
                 2016.11.0 from True to False.

                 Changed in version 2016.11.0.

                 Deprecated since version 2016.11.0.

          script_args
                 Any  additional  arguments  that  you want to pass to the
                 script.

                 New in version 2016.11.0.

          roster flat The roster to use for  Salt  SSH.  More  information
                 about   roster  files  can  be  found  in  Salt's  Roster
                 Documentation.

                 A full list of  roster  types,  see  the  builtin  roster
                 modules documentation.

                 New in version 2016.11.0.

          ssh_user
                 If user isn't found in the roster, a default SSH user can
                 be set  here.   Keep  in  mind  that  ssh_user  will  not
                 override the roster user value if it is already defined.

                 New in version 2016.11.0.

          ssh_password
                 If  passwd  isn't  found  in  the  roster,  a default SSH
                 password can be set here. Keep in mind that  ssh_password
                 will  not  override  the  roster  passwd  value  if it is
                 already defined.

                 New in version 2016.11.0.

          ssh_privkey
                 If priv isn't found in the roster, a default SSH  private
                 key  can be set here. Keep in mind that ssh_password will
                 not override the roster passwd value  if  it  is  already
                 defined.

                 New in version 2016.11.0.

          tmp_dir
                 /tmp/.bootstrap  The  temporary directory to download the
                 bootstrap script in. This directory  will  have  -<uuid4>
                 appended         to        it.        For        example:
                 /tmp/.bootstrap-a19a728e-d40a-4801-aba9-d00655c143a7/

                 New in version 2016.11.0.

          http_backend
                 tornado The  backend  library  to  use  to  download  the
                 script.  If  you  need  to  use  a file:/// URL, then you
                 should set this to urllib2.

                 New in version 2016.11.0.

          CLI Example:

             salt-run manage.bootstrap hosts='host1,host2'
             salt-run manage.bootstrap hosts='host1,host2' version='v0.17'
             salt-run manage.bootstrap hosts='host1,host2' version='v0.17'             script='https://bootstrap.saltstack.com/develop'
             salt-run manage.bootstrap hosts='ec2-user@host1,ec2-user@host2'             root_user=False

   salt.runners.manage.bootstrap_psexec(hosts='',             master=None,
   version=None,    arch='win32',    installer_url=None,    username=None,
   password=None)
          Bootstrap Windows minions via PsExec.

          hosts  Comma separated list of hosts to deploy the Windows  Salt
                 minion.

          master Address  of  the Salt master passed as an argument to the
                 installer.

          version
                 Point release of installer to download. Defaults  to  the
                 most recent.

          arch   Architecture of installer to download. Defaults to win32.

          installer_url
                 URL  of  minion  installer  executable.  Defaults  to the
                 latest version from https://repo.saltstack.com/windows/

          username
                 Optional user name for login on remote computer.

          password
                 Password for optional username. If omitted,  PsExec  will
                 prompt for one to be entered for each host.

          CLI Example:

             salt-run manage.bootstrap_psexec hosts='host1,host2'
             salt-run manage.bootstrap_psexec hosts='host1,host2' version='0.17' username='DOMAIN\Administrator'
             salt-run manage.bootstrap_psexec hosts='host1,host2' installer_url='http://exampledomain/salt-installer.exe'

   salt.runners.manage.down(removekeys=False, tgt='*', expr_form='glob')
          Print  a  list  of  all  the  down  or unresponsive salt minions
          Optionally remove keys of down minions

          CLI Example:

             salt-run manage.down
             salt-run manage.down removekeys=True
             salt-run manage.down tgt="webservers" expr_form="nodegroup"

   salt.runners.manage.get_stats(estate=None, stack='road')
          Print the stack stats

          estate None The name of the target estate. Master stats would be
                 requested by default

          stack  'road'  Show  stats  on either road or lane stack Allowed
                 values are 'road' or 'lane'.

          CLI Example:

             salt-run manage.get_stats [estate=alpha_minion] [stack=lane]

   salt.runners.manage.joined(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print a list of all minions that  are  up  according  to  Salt's
          presence detection (no commands will be sent to minions)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          CLI Example:

             salt-run manage.joined

   salt.runners.manage.key_regen()
          This  routine  is used to regenerate all keys in an environment.
          This is invasive! ALL KEYS  IN  THE  SALT  ENVIRONMENT  WILL  BE
          REGENERATED!!

          The  key_regen  routine sends a command out to minions to revoke
          the master key and remove all minion keys, it then  removes  all
          keys from the master and prompts the user to restart the master.
          The minions will all  reconnect  and  keys  will  be  placed  in
          pending.

          After the master is restarted and minion keys are in the pending
          directory  execute  a  salt-key  -A  command   to   accept   the
          regenerated minion keys.

          The  master  must be restarted within 60 seconds of running this
          command or the minions will think there is something wrong  with
          the keys and abort.

          Only  Execute  this runner after upgrading minions and master to
          0.15.1 or higher!

          CLI Example:

             salt-run manage.key_regen

   salt.runners.manage.lane_stats(estate=None)
          Print the estate manor lane stack stats

          estate None The name of the target estate. Master stats would be
                 requested by default

          CLI Example:

             salt-run manage.lane_stats [estate=alpha_minion]

   salt.runners.manage.list_not_state(subset=None,        show_ipv4=False,
   state=None)
          New in version 2015.8.0.

          Print a list of all minions that are NOT up according to  Salt's
          presence detection (no commands will be sent to minions)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          state  'available'  Show minions being in specific state that is
                 one of  'available',  'joined',  'allowed',  'alived'  or
                 'reaped'.

          CLI Example:

             salt-run manage.list_not_state

   salt.runners.manage.list_state(subset=None,            show_ipv4=False,
   state=None)
          New in version 2015.8.0.

          Print a list of all minions that  are  up  according  to  Salt's
          presence detection (no commands will be sent to minions)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          state  'available'  Show minions being in specific state that is
                 one of  'available',  'joined',  'allowed',  'alived'  or
                 'reaped'.

          CLI Example:

             salt-run manage.list_state

   salt.runners.manage.not_alived(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print  a list of all minions that are NOT up according to Salt's
          presence detection (no commands will be sent)

          subset None Pass in  a  CIDR  range  to  filter  minions  by  IP
                 address.

          show_ipv4
                 False  Also show the IP address each minion is connecting
                 from.

          CLI Example:

             salt-run manage.not_alived

   salt.runners.manage.not_allowed(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print a list of all minions that are NOT up according to  Salt's
          presence detection (no commands will be sent)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          CLI Example:

             salt-run manage.not_allowed

   salt.runners.manage.not_joined(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print  a list of all minions that are NOT up according to Salt's
          presence detection (no commands will be sent)

          subset None Pass in  a  CIDR  range  to  filter  minions  by  IP
                 address.

          show_ipv4
                 False  Also show the IP address each minion is connecting
                 from.

          CLI Example:

             salt-run manage.not_joined

   salt.runners.manage.not_present(subset=None, show_ipv4=False)
          New in version 2015.5.0.

          Print a list of all minions that are NOT up according to  Salt's
          presence detection (no commands will be sent)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          CLI Example:

             salt-run manage.not_present

   salt.runners.manage.not_reaped(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print  a list of all minions that are NOT up according to Salt's
          presence detection (no commands will be sent)

          subset None Pass in  a  CIDR  range  to  filter  minions  by  IP
                 address.

          show_ipv4
                 False  Also show the IP address each minion is connecting
                 from.

          CLI Example:

             salt-run manage.not_reaped

   salt.runners.manage.present(subset=None, show_ipv4=False)
          Print a list of all minions that  are  up  according  to  Salt's
          presence detection (no commands will be sent to minions)

          subset None  Pass  in  a  CIDR  range  to  filter  minions by IP
                 address.

          show_ipv4
                 False Also show the IP address each minion is  connecting
                 from.

          CLI Example:

             salt-run manage.present

   salt.runners.manage.reaped(subset=None, show_ipv4=False)
          New in version 2015.8.0.

          Print  a  list  of  all  minions that are up according to Salt's
          presence detection (no commands will be sent to minions)

          subset None Pass in  a  CIDR  range  to  filter  minions  by  IP
                 address.

          show_ipv4
                 False  Also show the IP address each minion is connecting
                 from.

          CLI Example:

             salt-run manage.reaped

   salt.runners.manage.road_stats(estate=None)
          Print the estate road stack stats

          estate None The name of the target estate. Master stats would be
                 requested by default

          CLI Example:

             salt-run manage.road_stats [estate=alpha_minion]

   salt.runners.manage.safe_accept(target, expr_form='glob')
          Accept a minion's public key after checking the fingerprint over
          salt-ssh

          CLI Example:

             salt-run manage.safe_accept my_minion
             salt-run manage.safe_accept minion1,minion2 expr_form=list

   salt.runners.manage.status(output=True, tgt='*', expr_form='glob')
          Print the status of all known salt minions

          CLI Example:

             salt-run manage.status
             salt-run manage.status tgt="webservers" expr_form="nodegroup"

   salt.runners.manage.up(tgt='*', expr_form='glob')
          Print a list of all of the minions that are up

          CLI Example:

             salt-run manage.up
             salt-run manage.up tgt="webservers" expr_form="nodegroup"

   salt.runners.manage.versions()
          Check the version of active minions

          CLI Example:

             salt-run manage.versions

   salt.runners.mine
   A runner to access data from the salt mine

   salt.runners.mine.get(tgt, fun, tgt_type='glob')
          Gathers the data from the specified minions' mine, pass  in  the
          target, function to look up and the target type

          CLI Example:

             salt-run mine.get '*' network.interfaces

   salt.runners.nacl
   This  runner  helps  create encrypted passwords that can be included in
   pillars.

   depends
          libnacl, https://github.com/saltstack/libnacl

   This is often useful if you  wish  to  store  your  pillars  in  source
   control  or  share your pillar data with others that you trust. I don't
   advise making your pillars public regardless if they are  encrypted  or
   not.

   The  following  configurations  can  be defined in the master config so
   your users can create encrypted passwords using the runner nacl:

      cat /etc/salt/master.d/nacl.conf
      nacl.config:
          key: 'cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='
          keyfile: /root/.nacl

   Now with the config in the master you can use the runner nacl like:

      salt-run nacl.enc 'data'

   salt.runners.nacl.dec(data, **kwargs)
          Takes a key generated from nacl.keygen and decrypt some data.

          CLI Examples:

             salt-run nacl.dec pEXHQM6cuaF7A=
             salt-run nacl.dec data='pEXHQM6cuaF7A=' keyfile=/root/.nacl
             salt-run nacl.dec data='pEXHQM6cuaF7A=' key='cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='

   salt.runners.nacl.enc(data, **kwargs)
          Takes a key generated from nacl.keygen and encrypt some data.

          CLI Examples:

             salt-run nacl.enc datatoenc
             salt-run nacl.enc datatoenc keyfile=/root/.nacl
             salt-run nacl.enc datatoenc key='cKEzd4kXsbeCE7/nLTIqXwnUiD1ulg4NoeeYcCFpd9k='

   salt.runners.nacl.keygen(keyfile=None)
          Use libnacl to generate a private key

          CLI Examples:

             salt-run nacl.keygen
             salt-run nacl.keygen keyfile=/root/.nacl
             salt-run --out=newline_values_only nacl.keygen > /root/.nacl

   salt.runners.network
   Network tools to run from the Master

   salt.runners.network.wol(mac, bcast='255.255.255.255', destport=9)
          Send a "Magic Packet" to wake up a Minion

          CLI Example:

             salt-run network.wol 08-00-27-13-69-77
             salt-run network.wol 080027136977 255.255.255.255 7
             salt-run network.wol 08:00:27:13:69:77 255.255.255.255 7

   salt.runners.network.wollist(maclist,          bcast='255.255.255.255',
   destport=9)
          Send  a  "Magic Packet" to wake up a list of Minions.  This list
          must contain one MAC hardware address per line

          CLI Example:

             salt-run network.wollist '/path/to/maclist'
             salt-run network.wollist '/path/to/maclist' 255.255.255.255 7
             salt-run network.wollist '/path/to/maclist' 255.255.255.255 7

   salt.runners.pagerduty
   Runner Module for Firing Events via PagerDuty

   New in version 2014.1.0.

   configuration
          This  module  can  be  used  by  specifying  the   name   of   a
          configuration profile in the master config.

          For example:

             my-pagerduty-account:
                 pagerduty.api_key: F3Rbyjbve43rfFWf2214
                 pagerduty.subdomain: mysubdomain

   salt.runners.pagerduty.create_event(service_key=None, description=None,
   details=None, incident_key=None, profile=None)
          Create an event in PagerDuty. Designed for use in states.

          CLI Example:

             salt-run pagerduty.create_event <service_key> <description> <details>         profile=my-pagerduty-account

          The following parameters are required:

          service_key
                 This key can be found by using pagerduty.list_services.

          description
                 This is a short description of the event.

          details
                 This can be a more detailed description of the event.

          profile
                 This refers  to  the  configuration  profile  to  use  to
                 connect to the PagerDuty service.

   salt.runners.pagerduty.list_escalation_policies(profile=None,
   api_key=None)
          This function is an alias of list_policies.
             List escalation policies belonging to this account

             CLI Example:
                 salt-run   pagerduty.list_policies   my-pagerduty-account
                 salt-run               pagerduty.list_escalation_policies
                 my-pagerduty-account

   salt.runners.pagerduty.list_incidents(profile=None, api_key=None)
          List incidents belonging to this account

          CLI Example:
             salt-run pagerduty.list_incidents my-pagerduty-account

   salt.runners.pagerduty.list_maintenance_windows(profile=None,
   api_key=None)
          This function is an alias of list_windows.
             List maintenance windows belonging to this account

             CLI Example:
                 salt-run    pagerduty.list_windows   my-pagerduty-account
                 salt-run               pagerduty.list_maintenance_windows
                 my-pagerduty-account

   salt.runners.pagerduty.list_policies(profile=None, api_key=None)
          List escalation policies belonging to this account

          CLI Example:
             salt-run     pagerduty.list_policies     my-pagerduty-account
             salt-run                   pagerduty.list_escalation_policies
             my-pagerduty-account

   salt.runners.pagerduty.list_schedules(profile=None, api_key=None)
          List schedules belonging to this account

          CLI Example:
             salt-run pagerduty.list_schedules my-pagerduty-account

   salt.runners.pagerduty.list_services(profile=None, api_key=None)
          List services belonging to this account

          CLI Example:
             salt-run pagerduty.list_services my-pagerduty-account

   salt.runners.pagerduty.list_users(profile=None, api_key=None)
          List users belonging to this account

          CLI Example:
             salt-run pagerduty.list_users my-pagerduty-account

   salt.runners.pagerduty.list_windows(profile=None, api_key=None)
          List maintenance windows belonging to this account

          CLI Example:
             salt-run pagerduty.list_windows my-pagerduty-account salt-run
             pagerduty.list_maintenance_windows my-pagerduty-account

   salt.runners.pillar
   Functions to interact with the pillar compiler on the master

   salt.runners.pillar.show_pillar(minion='*', **kwargs)
          Returns the compiled pillar either of a specific minion or  just
          the  global  available  pillars.  This  function assumes that no
          minion has the id *.

          CLI Example:

          shows minion specific pillar:

             salt-run pillar.show_pillar 'www.example.com'

          shows global pillar:

             salt-run pillar.show_pillar

          shows global pillar for 'dev' pillar environment:

             salt-run pillar.show_pillar 'saltenv=dev'

          API Example:

             import salt.config
             import salt.runner
             opts = salt.config.master_config('/etc/salt/master')
             runner = salt.runner.RunnerClient(opts)
             pillar = runner.cmd('pillar.show_pillar', [])
             print(pillar)

   salt.runners.pillar.show_top(minion=None, saltenv='base')
          Returns the compiled top data for pillar for a specific  minion.
          If no minion is specified, we use the first minion we find.

          CLI Example:

             salt-run pillar.show_top

   salt.runners.pkg
   Package helper functions using salt.modules.pkg

   New in version 2015.8.0.

   salt.runners.pkg.list_upgrades(jid,  style='group', outputter='nested',
   ext_source=None)
          Show list of available pkg upgrades  using  a  specified  format
          style

          CLI Example:

             salt-run pkg.list_upgrades jid=20141120114114417719 style=group

   salt.runners.queue
   General management and processing of queues.

   This runner facilitates interacting with various queue backends such as
   the included sqlite3 queue or the planned AWS SQS and Redis queues

   The queue functions such as insert, delete, and pop  can  be  used  for
   typical management of the queue.

   The  process_queue function pops the requested number of items from the
   queue and creates a Salt Event that can then be processed by a Reactor.
   The process_queue function can be called manually, or can be configured
   to run on a schedule with the Salt Scheduler or regular system cron. It
   is  also  possible to use the peer system to allow a minion to call the
   runner.

   This runner, as well as the Queues system, is not api  stable  at  this
   time.

   There are many things that could potentially be done with queues within
   Salt.  For the time being the focus will be on queueing  infrastructure
   actions  on  specific  minions.  The queues generally will be populated
   with minion IDs.  When the  process_queue  runner  function  is  called
   events  are created on the Salt Event bus that indicate the queue and a
   list of one or more minion IDs. The reactor is set up to match on event
   tags for a specific queue and then take infrastructure actions on those
   minion IDs. These actions might be to delete the minion's key from  the
   master, use salt-cloud to destroy the vm, or some other custom action.

   salt.runners.queue.delete(queue, items, backend='sqlite')
          Delete an item or items from a queue

          CLI Example:

             salt-run queue.delete myqueue myitem
             salt-run queue.delete myqueue myitem backend=sqlite
             salt-run queue.delete myqueue "['item1', 'item2', 'item3']"

   salt.runners.queue.insert(queue, items, backend='sqlite')
          Add an item or items to a queue

          CLI Example:

             salt-run queue.insert myqueue myitem
             salt-run queue.insert myqueue "['item1', 'item2', 'item3']"
             salt-run queue.insert myqueue myitem backend=sqlite
             salt-run queue.insert myqueue "['item1', 'item2', 'item3']" backend=sqlite

   salt.runners.queue.list_items(queue, backend='sqlite')
          List contents of a queue

          CLI Example:

             salt-run queue.list_items myqueue
             salt-run queue.list_items myqueue backend=sqlite

   salt.runners.queue.list_length(queue, backend='sqlite')
          Provide the number of items in a queue

          CLI Example:

             salt-run queue.list_length myqueue
             salt-run queue.list_length myqueue backend=sqlite

   salt.runners.queue.list_queues(backend='sqlite')
          Return a list of Salt Queues on the backend

          CLI Example:

             salt-run queue.list_queues
             salt-run queue.list_queues backend=sqlite

   salt.runners.queue.pop(queue, quantity=1, backend='sqlite')
          Pop one or more or all items from a queue

          CLI Example:

             salt-run queue.pop myqueue
             salt-run queue.pop myqueue 6
             salt-run queue.pop myqueue all
             salt-run queue.pop myqueue 6 backend=sqlite
             salt-run queue.pop myqueue all backend=sqlite

   salt.runners.queue.process_queue(queue, quantity=1, backend='sqlite')
          Pop  items off a queue and create an event on the Salt event bus
          to be processed by a Reactor.

          CLI Example:

             salt-run queue.process_queue myqueue
             salt-run queue.process_queue myqueue 6
             salt-run queue.process_queue myqueue all backend=sqlite

   salt.runners.reactor
   A convenience system to manage reactors

   salt.runners.reactor.add(event, reactors, saltenv='base', test=None)
          Add a new reactor

          CLI Example:

             salt-run reactor.add 'salt/cloud/*/destroyed' reactors='/srv/reactor/destroy/*.sls'

   salt.runners.reactor.delete(event, saltenv='base', test=None)
          Delete a reactor

          CLI Example:

             salt-run reactor.delete 'salt/cloud/*/destroyed'

   salt.runners.reactor.list(saltenv='base', test=None)
          List currently configured reactors

          CLI Example:

             salt-run reactor.list

   salt.runners.salt
   New in version 2016.11.0.

   This runner makes  Salt's  execution  modules  available  on  the  salt
   master.

   Salt's execution modules are normally available on the salt minion. Use
   this runner to  call  execution  modules  on  the  salt  master.   Salt
   execution modules are the functions called by the salt command.

   Execution modules can be called with salt-run:

      salt-run salt.cmd test.ping
      # call functions with arguments and keyword arguments
      salt-run salt.cmd test.arg 1 2 3 key=value a=1

   Execution modules are also available to salt runners:

      __salt__['salt.cmd'](fun=fun, args=args, kwargs=kwargs)

   salt.runners.salt.cmd(fun, *args, **kwargs)
          Execute  fun  with  the  given  args  and kwargs.  Parameter fun
          should be the string name of the execution module to call.

          Note that execution modules  will  be  loaded  every  time  this
          function is called.

          CLI example:

             salt-run salt.cmd test.ping
             # call functions with arguments and keyword arguments
             salt-run salt.cmd test.arg 1 2 3 a=1

   salt.runners.saltutil
   Sync custom types to the Master

   New in version 2016.3.0.

   salt.runners.saltutil.sync_all(saltenv='base')
          Sync all custom types

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_all

   salt.runners.saltutil.sync_engines(saltenv='base')
          Sync engines from salt://_engines to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_engines

   salt.runners.saltutil.sync_grains(saltenv='base')
          Sync grains modules from salt://_grains to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_grains

   salt.runners.saltutil.sync_modules(saltenv='base')
          Sync execution modules from salt://_modules to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_modules

   salt.runners.saltutil.sync_output(saltenv='base')
          Sync output modules from salt://_output to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_output

   salt.runners.saltutil.sync_pillar(saltenv='base')
          Sync pillar modules from salt://_pillar to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_pillar

   salt.runners.saltutil.sync_proxymodules(saltenv='base')
          Sync proxy modules from salt://_proxy to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_proxy

   salt.runners.saltutil.sync_queues(saltenv='base')
          Sync queue modules from salt://_queues to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_queues

   salt.runners.saltutil.sync_renderers(saltenv='base')
          Sync renderer modules from from salt://_renderers to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_renderers

   salt.runners.saltutil.sync_returners(saltenv='base')
          Sync returner modules from salt://_returners to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_returners

   salt.runners.saltutil.sync_runners(saltenv='base')
          Sync runners from salt://_runners to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_runners

   salt.runners.saltutil.sync_states(saltenv='base')
          Sync state modules from salt://_states to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_states

   salt.runners.saltutil.sync_utils(saltenv='base')
          New in version 2016.11.0.

          Sync utils modules from salt://_utils to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_utils

   salt.runners.saltutil.sync_wheel(saltenv='base')
          Sync wheel modules from salt://_wheel to the master

          saltenv
                 base  The  fileserver  environment from which to sync. To
                 sync   from   more   than   one   environment,   pass   a
                 comma-separated list.

          CLI Example:

             salt-run saltutil.sync_wheel

   salt.runners.sdb
   Runner for setting and querying data via the sdb API on the master

   salt.runners.sdb.delete(uri)
          Delete  a  value  from  a  db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>.  If the uri provided does not start  with
          sdb:// or the value is not successfully deleted, return False.

          CLI Example:

             salt '*' sdb.delete sdb://mymemcached/foo

   salt.runners.sdb.get(uri)
          Get   a   value   from  a  db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>. If the uri provided does not  start  with
          sdb://, then it will be returned as-is.

          CLI Example:

             salt '*' sdb.get sdb://mymemcached/foo

   salt.runners.sdb.set(uri, value)
          Set   a   value   in   a   db,  using  a  uri  in  the  form  of
          sdb://<profile>/<key>.  If the uri provided does not start  with
          sdb:// or the value is not successfully set, return False.

          CLI Example:

             salt '*' sdb.set sdb://mymemcached/foo bar

   salt.runners.search
   Runner frontend to search system

   salt.runners.search.query(term)
          Query the search system

          CLI Example:

             salt-run search.query foo

   salt.runners.spacewalk
   Spacewalk Runner
   New in version 2016.3.0.

   Runner to interact with Spacewalk using Spacewalk API

   codeauthor
          Nitin Madhok <[email protected]>

   To  use this runner, set up the Spacewalk URL, username and password in
   the     master      configuration      at      /etc/salt/master      or
   /etc/salt/master.d/spacewalk.conf:

      spacewalk:
        spacewalk01.domain.com
          username: "testuser"
          password: "verybadpass"
        spacewalk02.domain.com
          username: "testuser"
          password: "verybadpass"

   NOTE:
      Optionally, protocol can be specified if the spacewalk server is not
      using the defaults. Default is protocol: https.

   salt.runners.spacewalk.unregister(name, server_url)
          To unregister specified server from Spacewalk

          CLI Example:

             salt-run spacewalk.unregister my-test-vm spacewalk01.domain.com

   salt.runners.ssh
   A Runner module interface on top of the salt-ssh Python API.

   This  allows  for  programmatic  use  from   salt-api,   the   Reactor,
   Orchestrate, etc.

   salt.runners.ssh.cmd(tgt,  fun, arg=(), timeout=None, expr_form='glob',
   kwarg=None)
          Execute a single command via the salt-ssh subsystem  and  return
          all routines at once

          New in version 2015.5.0.

          A wrapper around the SSHClient.cmd method.

   salt.runners.state
   Execute orchestration functions

   salt.runners.state.event(tagmatch='*',      count=-1,      quiet=False,
   sock_dir=None, pretty=False, node='master')
          Watch Salt's event bus and block until the given tag is matched

          New in version 2014.7.0.

          This is useful for utilizing Salt's event bus from shell scripts
          or for taking simple actions directly from the CLI.

          Enable debug logging to see ignored events.

          Parameters

                 * tagmatch -- the event is written to stdout for each tag
                   that matches  this  pattern;  uses  the  same  matching
                   semantics as Salt's Reactor.

                 * count -- this number is decremented for each event that
                   matches the  tagmatch  parameter;  pass  -1  to  listen
                   forever.

                 * quiet -- do not print to stdout; just block

                 * sock_dir  --  path  to  the  Salt master's event socket
                   file.

                 * pretty -- Output the JSON all on a single line if False
                   (useful  for shell tools); pretty-print the JSON output
                   if True.

                 * node -- Watch the minion-side or master-side event bus.

          CLI Examples:

             # Reboot a minion and run highstate when it comes back online
             salt 'jerry' system.reboot && \\
                 salt-run state.event 'salt/minion/jerry/start' count=1 quiet=True && \\
                 salt 'jerry' state.highstate

             # Reboot multiple minions and run highstate when all are back online
             salt -L 'kevin,stewart,dave' system.reboot && \\
                 salt-run state.event 'salt/minion/*/start' count=3 quiet=True && \\
                 salt -L 'kevin,stewart,dave' state.highstate

             # Watch the event bus forever in a shell while-loop.
             salt-run state.event | while read -r tag data; do
                 echo $tag
                 echo $data | jq -colour-output .
             done

          SEE ALSO:
             See
             https://github.com/saltstack/salt/blob/develop/tests/eventlisten.sh
             for an example of usage within a shell script.

   salt.runners.state.orchestrate(mods,     saltenv='base',     test=None,
   exclude=None, pillar=None, pillarenv=None, orchestration_jid=None)
          New in version 0.17.0.

          Execute  a  state  run  from  the  master,  used  as  a powerful
          orchestration system.

          SEE ALSO:
             More Orchestrate documentation

             * Full Orchestrate Tutorial

             * Docs for the master-side state module

          CLI Examples:

             salt-run state.orchestrate webserver
             salt-run state.orchestrate webserver saltenv=dev test=True
             salt-run state.orchestrate webserver saltenv=dev pillarenv=aws

          Changed in version 2014.1.1: Runner renamed  from  state.sls  to
          state.orchestrate

          Changed in version 2014.7.0: Runner uses the pillar variable

   salt.runners.state.orchestrate_high(data,    test=None,    queue=False,
   pillar=None, **kwargs)
          Execute a single state orchestration routine

          New in version 2015.5.0.

          CLI Example:

             salt-run state.orchestrate_high '{
                 stage_one:
                     {salt.state: [{tgt: "db*"}, {sls: postgres_setup}]},
                 stage_two:
                     {salt.state: [{tgt: "web*"}, {sls: apache_setup}, {
                         require: [{salt: stage_one}],
                     }]},
                 }'

   salt.runners.state.orchestrate_single(fun,       name,       test=None,
   queue=False, pillar=None, **kwargs)
          Execute a single state orchestration routine

          New in version 2015.5.0.

          CLI Example:

             salt-run state.orchestrate_single fun=salt.wheel name=key.list_all

   salt.runners.survey
   A general map/reduce style salt runner for aggregating results returned
   by several different minions.

   New in version 2014.7.0.

   Aggregated results are sorted by the size of  the  minion  pools  which
   returned matching results.

   Useful  for  playing  the  game: "some of these things are not like the
   others..."  when identifying discrepancies in  a  large  infrastructure
   managed by salt.

   salt.runners.survey.diff(*args, **kwargs)
          Return  the  DIFFERENCE  of  the  result  sets  returned by each
          matching minion pool

          New in version 2014.7.0.

          These pools  are  determined  from  the  aggregated  and  sorted
          results of a salt command.

          This   command  displays  the  "diffs"  as  a  series  of  2-way
          differences -- namely the difference between the FIRST displayed
          minion pool (according to sort order) and EACH SUBSEQUENT minion
          pool result set.

          Differences   are   displayed   according    to    the    Python
          difflib.unified_diff()  as  in  the  case  of the salt execution
          module file.get_diff.

          This command is submitted via a salt runner  using  the  general
          form:

             salt-run survey.diff [survey_sort=up/down] <target>
                          <salt-execution-module> <salt-execution-module parameters>

          Optionally    accept    a   survey_sort=   parameter.   Default:
          survey_sort=down

          CLI Example #1: (Example to display the "differences of files")

             salt-run survey.diff survey_sort=up "*" cp.get_file_str file:///etc/hosts

   salt.runners.survey.hash(*args, **kwargs)
          Return the MATCHING minion pools from the aggregated and  sorted
          results of a salt command

          New in version 2014.7.0.

          This  command  is  submitted via a salt runner using the general
          form:

             salt-run survey.hash [survey_sort=up/down] <target>
                       <salt-execution-module> <salt-execution-module parameters>

          Optionally   accept   a   survey_sort=    parameter.    Default:
          survey_sort=down

          CLI Example #1: (functionally equivalent to salt-run manage.up)

             salt-run survey.hash "*" test.ping

          CLI Example #2: (find an "outlier" minion config file)

             salt-run survey.hash "*" file.get_hash /etc/salt/minion survey_sort=up

   salt.runners.test
   This  runner  is  used only for test purposes and servers no production
   purpose

   salt.runners.test.arg(*args, **kwargs)
          Output the given args and kwargs

          Kwargs will be filtered for 'private' keynames.

   salt.runners.test.raw_arg(*args, **kwargs)
          Output the given args and kwargs

   salt.runners.test.sleep(s_time=10)
          Sleep t seconds, then return True

   salt.runners.test.stdout_print()
          Print 'foo' and return 'bar'

   salt.runners.test.stream()
          Return True

   salt.runners.thin
   The thin runner is used to manage the salt thin systems.

   Salt Thin is a transport-less version of Salt that can be used  to  run
   routines  in a standalone way. This runner has tools which generate the
   standalone salt system for easy consumption.

   salt.runners.thin.generate(extra_mods='', overwrite=False,  so_mods='',
   python2_bin='python2', python3_bin='python3')
          Generate  the  salt-thin  tarball  and print the location of the
          tarball Optional additional mods to include (e.g. mako)  can  be
          supplied  as  a  comma  delimited  string.   Permits  forcing an
          overwrite of the output file as well.

          CLI Example:

             salt-run thin.generate
             salt-run thin.generate mako
             salt-run thin.generate mako,wempy 1
             salt-run thin.generate overwrite=1

   salt.runners.thin.generate_min(extra_mods='',          overwrite=False,
   so_mods='', python2_bin='python2', python3_bin='python3')
          Generate  the  salt-thin  tarball  and print the location of the
          tarball Optional additional mods to include (e.g. mako)  can  be
          supplied  as  a  comma  delimited  string.   Permits  forcing an
          overwrite of the output file as well.

          CLI Example:

             salt-run thin.generate_min

   salt.runners.virt
   Control virtual machines via Salt

   salt.runners.virt.force_off(name)
          Force power down the named virtual machine

   salt.runners.virt.host_info(host=None)
          Return information about the host connected to this master

   salt.runners.virt.init(name,   cpu,   mem,   image,   hypervisor='kvm',
   host=None,    seed=True,   nic='default',   install=True,   start=True,
   disk='default', saltenv='base', enable_vnc=False)
          This routine is used to  create  a  new  virtual  machine.  This
          routines  takes  a number of options to determine what the newly
          created virtual machine will look like.

          name   The mandatory name of the new virtual machine.  The  name
                 option  is  also  the minion id, all minions must have an
                 id.

          cpu    The number of  cpus  to  allocate  to  this  new  virtual
                 machine.

          mem    The amount of memory to allocate tot his virtual machine.
                 The number is interpreted in megabytes.

          image  The  network  location  of  the  virtual  machine  image,
                 commonly  a  location  on  the salt fileserver, but http,
                 https and ftp can also be used.

          hypervisor
                 The hypervisor  to  use  for  the  new  virtual  machine.
                 Default is 'kvm'.

          host   The  host  to use for the new virtual machine, if this is
                 omitted Salt will automatically detect what host to use.

          seed   Set to False to prevent Salt from seeding the new virtual
                 machine.

          nic    The  nic  profile  to  use, defaults to the "default" nic
                 profile which assumes a single network interface  per  VM
                 associated with the "br0" bridge on the master.

          install
                 Set  to False to prevent Salt from installing a minion on
                 the new VM before it spins up.

          disk   The disk profile to use

          saltenv
                 The Salt environment to use

   salt.runners.virt.list(host=None, quiet=False, hyper=None)
          List the virtual machines on each host,  this  is  a  simplified
          query,  showing only the virtual machine names belonging to each
          host.  A single host can be passed in to specify  an  individual
          host to list.

   salt.runners.virt.migrate(name, target='')
          Migrate  a  VM  from one host to another. This routine will just
          start the migration and display information on how  to  look  up
          the progress.

   salt.runners.virt.next_host()
          Return  the  host  to  use  for  the  next autodeployed VM. This
          queries the available host and executes some math the  determine
          the most "available" next host.

   salt.runners.virt.pause(name)
          Pause the named VM

   salt.runners.virt.purge(name, delete_key=True)
          Destroy the named VM

   salt.runners.virt.query(host=None, quiet=False)
          Query  the  virtual  machines.  When  called without options all
          hosts are detected and a full query is returned. A  single  host
          can be passed in to specify an individual host to query.

   salt.runners.virt.reset(name)
          Force power down and restart an existing VM

   salt.runners.virt.resume(name)
          Resume a paused VM

   salt.runners.virt.start(name)
          Start a named virtual machine

   salt.runners.virt.vm_info(name, quiet=False)
          Return the information on the named VM

   salt.runners.winrepo
   Runner to manage Windows software repo

   salt.runners.winrepo.genrepo(opts=None, fire_event=True)
          Generate winrepo_cachefile based on sls files in the winrepo_dir

          opts   Specify an alternate opts dict. Should not be used unless
                 this function is imported into an execution module.

          fire_event
                 True Fire an event on  failure.  Only  supported  on  the
                 master.

          CLI Example:

             salt-run winrepo.genrepo

   salt.runners.winrepo.update_git_repos(opts=None,           clean=False,
   masterless=False)
          Checkout  git  repos   containing   Windows   Software   Package
          Definitions

          opts   Specify an alternate opts dict. Should not be used unless
                 this function is imported into an execution module.

          clean  False Clean repo cachedirs which are not configured under
                 winrepo_remotes.

                 WARNING:
                    This  argument  should  not be set to True if a mix of
                    git and non-git repo definitions are being used, as it
                    will  result  in  the  non-git  repo definitions being
                    removed.

                 New in version 2015.8.0.

          CLI Examples:

             salt-run winrepo.update_git_repos
             salt-run winrepo.update_git_repos clean=True

   sdb modules
                  
                  confidant   An SDB module for  getting 
                              credentials           from 
                              confidant.                 
                  
                  consul      Consul sdb Module          
                  
                  couchdb     CouchDB sdb Module         
                  
                  etcd_db     etcd Database Module       
                  
                  keyring_db  Keyring Database Module    
                  
                  memcached   Memcached sdb Module       
                  
                  rest        Generic   REST   API   SDB 
                              Module                     
                  
                  sqlite3     SQLite sdb Module          
                  
                  vault       Vault SDB Module           
                  

   salt.sdb.confidant
   An SDB module for getting credentials from confidant.

   Configuring the Confidant module
   The module can be configured via sdb in the minion config:

      confidant:
        driver: confidant
        # The URL of the confidant web service
        url: 'https://confidant-production.example.com'
        # The context to use for KMS authentication
        auth_context:
          from: example-production-iad
          to: confidant-production-iad
          user_type: service
        # The KMS master key to use for authentication
        auth_key: "alias/authnz"
        # Cache file for KMS auth token
        token_cache_file: /run/confidant/confidant_token
        # The duration of the validity of a token, in minutes
        token_duration: 60
        # key, keyid and region can be defined in the profile, but it's generally
        # best to use IAM roles or environment variables for AWS auth.
        keyid: 98nh9h9h908h09kjjk
        key: jhf908gyeghehe0he0g8h9u0j0n0n09hj09h0
        region: us-east-1

   depends
          confidant-common, confidant-client

   Module Documentation
   salt.sdb.confidant.get(key, profile=None)
          Read pillar data from Confidant via its API.

          CLI Example:
             salt myminion sdb.get 'sdb://confidant/credentials'

          Valid   keys  are:  credentials,  credentials_metadata,  result.
          credentials  returns  a   dict   of   joined   credential_pairs,
          credentials_metadata  returns a dict of metadata relevant to the
          credentials mapped to the confidant service, and result  returns
          a bool that can be used to determine if the sdb call succeded or
          failed to  fetch  credentials  from  confidant  (or  from  local
          cache).   If  result  is  false,  the  data  in  credentials  or
          credentials_metadata can't be trusted.

   salt.sdb.consul module
   Consul sdb Module

   maintainer
          SaltStack

   maturity
          New

   platform
          all

   This module allows access to Consul using an sdb:// URI

   Like all sdb  modules,  the  Consul  module  requires  a  configuration
   profile  to  be configured in either the minion or master configuration
   file. This profile requires very little. For example:

   The driver refers to the Consul module, all other options are optional.
   For                 option                 details                 see:
   https://python-consul.readthedocs.io/en/latest/#consul

   salt.sdb.consul.get_conn(profile)
          Return a client object for accessing consul

   salt.sdb.couchdb
   CouchDB sdb Module

   maintainer
          SaltStack

   maturity
          New

   depends
          python2-couchdb

   platform
          all

   This allow interaction between Salt and a CouchDB  [couchdb.apache.org]
   database.  It uses salt's sdb system to allow for inserts and retrevals
   using the sdb:// prefix in salt configuration files.

   To use the couchbase sdb module, it must first  be  configured  in  the
   salt master or minion config. The following arguments are required:

      couchdb_sdb:
        driver: couchdb
        host: localhost
        port: 5984
        database: salt_sdb

   One could then query the CouchDB instance via an sdb:// URI such as the
   following:

      password: sdb://couchdb_sdb/mykey

   To use this interface, you must track IDs on your own or  have  another
   source  to  do  the  map-reduce logic necessary to calculate the ID you
   wish to fetch.

   Additional contributions to build true  map-reduce  functionality  into
   this module would be welcome.

   salt.sdb.couchdb.get(key, profile=None)
          Get a value from couchdb by id

   salt.sdb.couchdb.set(key, value, profile=None)
          Set a key/value pair in couchdb

   salt.sdb.etcd_db
   etcd Database Module

   maintainer
          SaltStack

   maturity
          New

   depends
          python-etcd

   platform
          all

   New in version 2015.5.0.

   This  module  allows  access  to the etcd database using an sdb:// URI.
   This package is located at https://pypi.python.org/pypi/python-etcd.

   Like all sdb modules, the etcd module requires a configuration  profile
   to  be  configured  in  either the minion or master configuration file.
   This profile requires very little. In the example:

      myetcd:
        driver: etcd
        etcd.host: 127.0.0.1
        etcd.port: 4001

   The driver refers to the etcd module, etcd.host refers to the host that
   is  hosting  the etcd database and etcd.port refers to the port on that
   host.

      password: sdb://myetcd/mypassword

   salt.sdb.etcd_db.delete(key, service=None, profile=None)
          Get a value from the etcd service

   salt.sdb.etcd_db.get(key, service=None, profile=None)
          Get a value from the etcd service

   salt.sdb.etcd_db.set(key, value, service=None, profile=None)
          Set a key/value pair in the etcd service

   salt.sdb.keyring_db
   Keyring Database Module

   maintainer
          SaltStack

   maturity
          New

   depends
          keyring

   platform
          all

   This module allows access to the keyring package using an  sdb://  URI.
   This package is located at https://pypi.python.org/pypi/keyring.

   Care  must  be  taken  when  using keyring. Not all keyend backends are
   supported on all operating systems.  Also,  many  backends  require  an
   agent  to  be  running  in  order  to  work.  For instance, the "Secret
   Service"   backend   requires    a    compatible    agent    such    as
   gnome-keyring-daemon or kwallet to be running. The keyczar backend does
   not seem to enjoy the benefits of  an  agent,  and  so  using  it  will
   require  either  that  the  password  is  typed  in  manually (which is
   unreasonable for the salt-minion and salt-master daemons, especially in
   production) or an agent is written for it.

   Like  all  sdb  modules,  the  keyring  module requires a configuration
   profile to be configured in either the minion or  master  configuration
   file. This profile requires very little. In the example:

      mykeyring:
        driver: keyring
        service: system

   The  driver refers to the keyring module, service refers to the service
   that will be used inside of  keyring  (which  may  be  likened  unto  a
   database  table)  and  mykeyring refers to the name that will appear in
   the URI:

      password: sdb://mykeyring/mypassword

   The underlying backend configuration must  be  configured  via  keyring
   itself. For examples and documentation, see keyring:

   https://pypi.python.org/pypi/keyring

   New in version 2014.1.4.

   salt.sdb.keyring_db.get(key, service=None, profile=None)
          Get a value from a keyring service

   salt.sdb.keyring_db.set(key, value, service=None, profile=None)
          Set a key/value pair in a keyring service

   salt.sdb.memcached
   Memcached sdb Module

   maintainer
          SaltStack

   maturity
          New

   depends
          python-memcached

   platform
          all

   This  module  allows  access  to  memcached  using  an sdb:// URI. This
   package is located at https://pypi.python.org/pypi/python-memcached.

   Like all sdb modules, the memcached  module  requires  a  configuration
   profile  to  be configured in either the minion or master configuration
   file. This profile requires very little. In the example:

      mymemcache:
        driver: memcached
        host: localhost
        port: 11211

   The driver refers to the memcached module, host and port the  memcached
   server  to connect to (defaults to localhost and 11211, and mymemcached
   refers to the name that will appear in the URI:

      password: sdb://mymemcached/mykey

   salt.sdb.memcached.get(key, profile=None)
          Get a value from memcached

   salt.sdb.memcached.set(key, value, profile=None)
          Set a key/value pair in memcached

   salt.sdb.rest module
   Generic REST API SDB Module

   maintainer
          SaltStack

   maturity
          New

   platform
          all

   New in version 2015.8.0.

   This module allows access to a REST interface using an sdb:// URI.

   Like all REST modules, the REST module requires a configuration profile
   to  be  configured  in  either the minion or master configuration file.
   This profile requires very little. In the example:

      my-rest-api:
        driver: rest
        urls:
          url: https://api.github.com/
        keys:
          url: https://api.github.com/users/{{user}}/keys
          backend: requests

   The driver refers to the REST module, and must be set to rest in  order
   to use this driver. Each of the other items inside this block refers to
   a separate  set  of  HTTP  items,  including  a  URL  and  any  options
   associated  with  it.   The  options used here should match the options
   available in salt.utils.http.query().

   In order to call the urls item in the example, the following  reference
   can be made inside a configuration file:

      github_urls: sdb://my-rest-api/urls

   Key/Value  pairs may also be used with this driver, and merged into the
   URL using the configured renderer (jinja, by default). For instance, in
   order  to use the keys item in the example, the following reference can
   be made:

      github_urls: sdb://my-rest-api/keys?user=myuser

   This will cause the following URL to actually be called:

      https://api.github.com/users/myuser/keys

   Key/Value pairs will NOT be passed through as GET  data.  If  GET  data
   needs  to  be  sent to the URL, then it should be configured in the SDB
   configuration block.  For instance:

      another-rest-api:
        driver: rest
        user_data:
          url: https://api.example.com/users/
          params:
            user: myuser

   salt.sdb.rest.get(key, service=None, profile=None)
          Get a value from the REST interface

   salt.sdb.rest.query(key, value=None, service=None, profile=None)
          Get a value from the REST interface

   salt.sdb.rest.set(key, value, service=None, profile=None)
          Set a key/value pair in the REST interface

   salt.sdb.sqlite3
   SQLite sdb Module

   maintainer
          SaltStack

   maturity
          New

   platform
          all

   This module allows access to sqlite3 using an sdb:// URI

   Like all sdb modules,  the  sqlite3  module  requires  a  configuration
   profile  to  be configured in either the minion or master configuration
   file. This profile requires very little. For example:

      mysqlite:
        driver: sqlite3
        database: /tmp/sdb.sqlite
        table: sdb
        create_table: True

   The driver refers to the sqlite3 module, database refers to the sqlite3
   database file. table is the table within the db that will hold keys and
   values (defaults to sdb). The database and table  will  be  created  if
   they do not exist.

   Advanced Usage:
   Instead  of  a  table  name,  it  is  possible  to  provide  custom SQL
   statements to create the table(s) and get and set values.

   salt.sdb.sqlite3.get(key, profile=None)
          Get a value from sqlite3

   salt.sdb.sqlite3.set(key, value, profile=None)
          Set a key/value pair in sqlite3

   salt.sdb.vault module
   Vault SDB Module

   maintainer
          SaltStack

   maturity
          New

   platform
          all

   New in version 2016.11.0.

   This module allows access to Hashicorp Vault using an sdb:// URI.

   Like all sdb modules, the vault module requires a configuration profile
   to  be  configured  in  either the minion or master configuration file.
   This profile requires very little. In the example:

      myvault:
        driver: vault
        vault.host: 127.0.0.1
        vault.port: 8200
        vault.scheme: http  # Optional; default is https
        vault.token: 012356789abcdef  # Required, unless set in environment

   The driver refers to the vault module, vault.host refers  to  the  host
   that is hosting vault and vault.port refers to the port on that host. A
   vault token is also required. It may be set statically, as above, or as
   an environment variable:

      $ export VAULT_TOKEN=0123456789abcdef

   Once configured you can access data using a URL such as:

      password: sdb://myvault/secret/passwords?mypassword

   In   this   URL,   myvault   refers   to   the  configuration  profile,
   secret/passwords is the path where the data resides, and mypassword  is
   the key of the data to return.

   The above URI is analogous to running the following vault command:

      $ vault read -field=mypassword secret/passwords

   salt.sdb.vault.get(key, profile=None)
          Get a value from the vault service

   salt.sdb.vault.set(key, value, profile=None)
          Set a key/value pair in the vault service

   serializer modules
               
               configparser  salt.serializers.configparser 
               
               json          salt.serializers.json         
               
               msgpack       salt.serializers.msgpack      
               
               python        salt.serializers.python       
               
               yaml          salt.serializers.yaml         
               
               yamlex        salt.serializers.yamlex       
               

   salt.serializers.configparser module
   salt.serializers.configparser
   New in version 2016.3.0.

   Implements a configparser serializer.

   salt.serializers.configparser.deserialize(stream_or_string, **options)
          Deserialize any string or stream like object into a Python  data
          structure.

          Parameters

                 * stream_or_string -- stream or string to deserialize.

                 * options -- options given to lower configparser module.

   salt.serializers.configparser.serialize(obj, **options)
          Serialize  Python  data  to  a  configparser formatted string or
          file.

          Parameters

                 * obj -- the data structure to serialize

                 * options -- options given to lower configparser module.

   salt.serializers.json
   salt.serializers.json
   Implements JSON serializer.

   It's just a wrapper around json (or simplejson if available).

   salt.serializers.json.deserialize(stream_or_string, **options)
          Deserialize any string or stream like object into a Python  data
          structure.

          Parameters

                 * stream_or_string -- stream or string to deserialize.

                 * options  --  options  given  to  lower  json/simplejson
                   module.

   salt.serializers.json.serialize(obj, **options)
          Serialize Python data to JSON.

          Parameters

                 * obj -- the data structure to serialize

                 * options  --  options  given  to  lower  json/simplejson
                   module.

   salt.serializers.msgpack
   salt.serializers.msgpack
   Implements MsgPack serializer.

   salt.serializers.msgpack.deserialize(stream_or_string, **options)
          Deserialize  any string of stream like object into a Python data
          structure.

          Parameters

                 * stream_or_string -- stream or string to deserialize.

                 * options -- options given to lower msgpack module.

   salt.serializers.msgpack.serialize(obj, **options)
          Serialize Python data to MsgPack.

          Parameters

                 * obj -- the data structure to serialize

                 * options -- options given to lower msgpack module.

   salt.serializers.python module
   salt.serializers.python
   New in version 2016.3.0.

   Implements a Python serializer (via pprint.format)

   salt.serializers.python.serialize(obj, **options)
          Serialize Python data to a  Python  string  representation  (via
          pprint.format)

          Parameters

                 * obj -- the data structure to serialize

                 * options -- options given to pprint.format

   salt.serializers.yaml
   salt.serializers.yaml
   Implements YAML serializer.

   Underneath,  it  is based on pyyaml and use the safe dumper and loader.
   It also use C bindings if they are available.

   salt.serializers.yaml.deserialize(stream_or_string, **options)
          Deserialize any string of stream like object into a Python  data
          structure.

          Parameters

                 * stream_or_string -- stream or string to deserialize.

                 * options -- options given to lower yaml module.

   salt.serializers.yaml.serialize(obj, **options)
          Serialize Python data to YAML.

          Parameters

                 * obj -- the data structure to serialize

                 * options -- options given to lower yaml module.

   salt.serializers.yamlex
   salt.serializers.yamlex
   YAMLEX  is  a  format  that allows for things like sls files to be more
   intuitive.

   It's an extension of YAML that implements all  the  salt  magic:  -  it
   implies omap for any dict like.  - it implies that string like data are
   str, not unicode - ...

   For example, the file states.sls has this contents:

      foo:
        bar: 42
        baz: [1, 2, 3]

   The file can be parsed into Python like this

      from salt.serializers import yamlex

      with open('state.sls', 'r') as stream:
          obj = yamlex.deserialize(stream)

   Check that obj is an OrderedDict

      from salt.utils.odict import OrderedDict

      assert isinstance(obj, dict)
      assert isinstance(obj, OrderedDict)

   yamlex __repr__ and __str__ objects' methods render YAML understandable
   string. It means that they are template friendly.

      print '{0}'.format(obj)

   returns:

      {foo: {bar: 42, baz: [1, 2, 3]}}

   and they are still valid YAML:

      from salt.serializers import yaml
      yml_obj = yaml.deserialize(str(obj))
      assert yml_obj == obj

   yamlex implements also custom tags:

   !aggregate
          this tag allows structures aggregation.

      For example:

          placeholder: !aggregate foo
          placeholder: !aggregate bar
          placeholder: !aggregate baz

      is rendered as

          placeholder: [foo, bar, baz]

   !reset
          this tag flushes the computing value.

          placeholder: {!aggregate foo: {foo: 42}}
          placeholder: {!aggregate foo: {bar: null}}
          !reset placeholder: {!aggregate foo: {baz: inga}}

      is roughly equivalent to

          placeholder: {!aggregate foo: {baz: inga}}

   Document is defacto an aggregate mapping.

   salt.serializers.yamlex.deserialize(stream_or_string, **options)
          Deserialize  any string of stream like object into a Python data
          structure.

          Parameters

                 * stream_or_string -- stream or string to deserialize.

                 * options -- options given to lower yaml module.

   salt.serializers.yamlex.serialize(obj, **options)
          Serialize Python data to YAML.

          Parameters

                 * obj -- the data structure to serialize

                 * options -- options given to lower yaml module.

   state modules
         
         acme                          ACME   /   Let's   Encrypt 
                                       certificate     management 
                                       state                      
         
         alias                         Configuration   of   email 
                                       aliases                    
         
         alternatives                  Configuration    of    the 
                                       alternatives system        
         
         apache                        Apache state               
         
         apache_conf                   Manage Apache Confs        
         
         apache_module                 Manage Apache Modules      
         
         apache_site                   Manage Apache Sites        
         
         aptpkg                        Package         management 
                                       operations   specific   to 
                                       APT- and DEB-based systems 
         
         archive                       Extract an archive         
         
         artifactory                   This    state    downloads 
                                       artifacts             from 
                                       artifactory.               
         
         at                            Configuration   disposable 
                                       regularly  scheduled tasks 
                                       for at.                    
         
         augeas                        Configuration   management 
                                       using Augeas               
         
         aws_sqs                       Manage SQS Queues          
         
         beacon                        Management   of  the  Salt 
                                       beacons                    
         
         bigip                         A state module designed to 
                                       enforce     load-balancing 
                                       configurations   for    F5 
                                       Big-IP entities.           
         
         blockdev                      Management     of    Block 
                                       Devices                    
         
         boto_apigateway               Manage   Apigateway   Rest 
                                       APIs                       
         
         boto_asg                      Manage Autoscale Groups    
         
         boto_cfn                      Connection    module   for 
                                       Amazon Cloud Formation     
         
         boto_cloudtrail               Manage CloudTrail Objects  
         
         boto_cloudwatch_alarm         Manage Cloudwatch alarms   
         
         boto_cognitoidentity          Manage     CognitoIdentity 
                                       Functions                  
         
         boto_datapipeline             Manage Data Pipelines      
         
         boto_dynamodb                 Manage DynamoDB Tables     
         
         boto_ec2                      Manage EC2                 
         
         boto_elasticache              Manage Elasticache         
         
         boto_elasticsearch_domain     Manage       Elasticsearch 
                                       Domains                    
         
         boto_elb                      Manage ELBs                
         
         boto_iam                      Manage IAM objects         
         
         boto_iam_role                 Manage IAM roles           
         
         boto_iot                      Manage IoT Objects         
         
         boto_kms                      Manage   KMS   keys,   key 
                                       policies and grants.       
         
         boto_lambda                   Manage Lambda Functions    
         
         boto_lc                       Manage              Launch 
                                       Configurations             
         
         boto_rds                      Manage RDSs                
         
         boto_route53                  Manage Route53 records     
         
         boto_s3_bucket                Manage S3 Buckets          
         
         boto_secgroup                 Manage Security Groups     
         
         boto_sns                      Manage SNS Topics          
         
         boto_sqs                      Manage SQS Queues          
         
         boto_vpc                      Manage VPCs                
         
         bower                         Installation   of    Bower 
                                       Packages                   
         
         cabal                         Installation    of   Cabal 
                                       Packages                   
         
         chef                          Execute Chef client runs   
         
         chocolatey                    Manage Chocolatey  package 
                                       installs ..                
         
         chronos_job                   Configure Chronos jobs via 
                                       a salt proxy.              
         
         cloud                         Using  states  instead  of 
                                       maps to deploy clouds      
         
         cmd                           Execution   of   arbitrary 
                                       commands                   
         
         composer                      Installation  of  Composer 
                                       Packages                   
         
         cron                          Management  of  cron,  the 
                                       Unix command scheduler     
         
         cyg                           Installation   of   Cygwin 
                                       packages.                  
         
         ddns                          Dynamic DNS updates        
         

         debconfmod                    Management    of   debconf 
                                       selections                 
         
         dellchassis                   Manage  chassis  via  Salt 
                                       Proxies.                   
         
         disk                          Disk monitoring state      
         
         dockerio                      Manage Docker containers   
         
         dockerng                      Management    of    Docker 
                                       containers                 
         
         drac                          Management of Dell DRAC    
         
         elasticsearch_index           State  module  to   manage 
                                       Elasticsearch indices      
         
         elasticsearch_index_template  State  module  to   manage 
                                       Elasticsearch        index 
                                       templates                  
         
         environ                       Support  for  getting  and 
                                       setting   the  environment 
                                       variables of  the  current 
                                       salt process.              
         
         eselect                       Management    of    Gentoo 
                                       configuration        using 
                                       eselect                    
         
         etcd_mod                      Manage etcd Keys           
         
         esxi                          Manage VMware ESXi Hosts.  
         
         event                         Send events through Salt's 
                                       event system during  state 
                                       runs                       
         
         file                          Operations    on   regular 
                                       files,   special    files, 
                                       directories, and symlinks  
         
         firewall                      State  to  check  firewall 
                                       configurations ..          
         
         firewalld                     Management of firewalld    
         
         gem                           Installation    of    Ruby 
                                       modules packaged as gems   
         
         git                           States   to   manage   git 
                                       repositories    and    git 
                                       configuration              
         
         github                        Github User State Module   
         
         glance                        Managing     Images     in 
                                       OpenStack Glance           
         
         glusterfs                     Manage GlusterFS pool.     
         
         gnomedesktop                  Configuration of the GNOME 
                                       desktop                    
         
         gpg                           Management   of   the  GPG 
                                       keychains                  
         
         grafana                       Manage Grafana Dashboards  
         
         grafana_dashboard             Manage    Grafana     v2.0 
                                       Dashboards                 
         
         grafana_datasource            Manage  Grafana  v2.0 data 
                                       sources                    
         
         grains                        Manage   grains   on   the 
                                       minion                     
         
         group                         Management of user groups  
         
         hg                            Interaction with Mercurial 
                                       repositories               
         
         hipchat                       Send a message to Hipchat  
         
         host                          Management  of   addresses 
                                       and names in hosts file    
         
         htpasswd                      Support    for    htpasswd 
                                       module.                    
         
         http                          HTTP monitoring states     
         
         ifttt                         Trigger an event in IFTTT  
         
         incron                        Management of incron,  the 
                                       inotify cron               
         
         influxdb_database             Management   of   Influxdb 
                                       databases                  
         
         influxdb_user                 Management   of   InfluxDB 
                                       users                      
         
         infoblox                      states for infoblox stuff  
         
         ini_manage                    Manage ini files           
         
         ipmi                          Manage  IPMI  devices over 
                                       LAN                        
         
         ipset                         Management of ipsets       
         
         iptables                      Management of iptables     
         
         jboss7                        Manage JBoss 7 Application 
                                       Server via CLI interface   
         
         jenkins                       Management of Jenkins      
         
         junos                         State  modules to interact 
                                       with Junos devices.        
         
         k8s                           Manage Kubernetes          
         
         kapacitor                     Kapacitor state module.    
         
         keyboard                      Management   of   keyboard 
                                       layouts                    
         
         keystone                      Management   of   Keystone 
                                       users                      
         
         kmod                          Loading and  unloading  of 
                                       kernel modules             
         
         layman                        Management    of    Gentoo 
                                       Overlays using layman      
         
         ldap                          Manage entries in an  LDAP 
                                       database                   
         
         linux_acl                     Linux  File Access Control 
                                       Lists                      
         
         locale                        Management              of 
                                       languages/locales          
         
         lvm                           Management     of    Linux 
                                       logical volumes            
         
         lvs_server                    Management of  LVS  (Linux 
                                       Virtual    Server)    Real 
                                       Server                     
         
         lvs_service                   Management of  LVS  (Linux 
                                       Virtual Server) Service    
         
         lxc                           Manage Linux Containers    
         
         mac_assistive                 Allows   you   to   manage 
                                       assistive access on  OS  X 
                                       minions with 10.9+         
         
         mac_defaults                  Writing/reading   defaults 
                                       from an OS X minion        
         
         mac_keychain                  Installing of certificates 
                                       to the keychain            
         
         mac_package                   Installing   of   mac  pkg 
                                       files                      
         
         mac_xattr                     Allows   you   to   manage 
                                       extended   attributes   on 
                                       files or directories       
         
         makeconf                      Management    of    Gentoo 
                                       make.conf                  
         
         marathon_app                  Configure   Marathon  apps 
                                       via a salt proxy.          
         
         mdadm                         Managing   software   RAID 
                                       with mdadm                 
         
         memcached                     States  for  Management of 
                                       Memcached Keys             
         
         modjk                         State  to  control  Apache 
                                       modjk                      
         
         modjk_worker                  Manage modjk workers       
         
         module                        Execution  of Salt modules 
                                       from within states         
         
         mongodb_database              Management   of    Mongodb 
                                       databases                  
         
         mongodb_user                  Management    of   Mongodb 
                                       users                      
         
         monit                         Monit state                
         
         mount                         Mounting of filesystems    
         
         mysql_database                Management    of     MySQL 
                                       databases (schemas)        
         
         mysql_grants                  Management of MySQL grants 
                                       (user permissions)         
         
         mysql_query                   Execution of MySQL queries 
         
         mysql_user                    Management of MySQL users  
         
         netntp                        Network NTP                
         
         network                       Configuration  of  network 
                                       interfaces                 
         
         nftables                      Management of nftables     
         
         npm                           Installation     of    NPM 
                                       Packages                   
         
         ntp                           Management of NTP servers  
         
         nxos                          State module for Cisco  NX 
                                       OS Switches Proxy minions  
         
         openstack_config              Manage           OpenStack 
                                       configuration         file 
                                       settings.                  
         
         openvswitch_bridge            Management of Open vSwitch 
                                       bridges.                   
         
         openvswitch_port              Management of Open vSwitch 
                                       ports.                     
         
         pagerduty                     Create    an    Event   in 
                                       PagerDuty                  
         
         pagerduty_escalation_policy   Manage           PagerDuty 
                                       escalation policies.       
         
         pagerduty_schedule            Manage           PagerDuty 
                                       schedules.                 
         
         pagerduty_service             Manage PagerDuty services  
         
         pagerduty_user                Manage PagerDuty users.    
         
         pcs                           Management              of 
                                       Pacemaker/Corosync         
                                       clusters with PCS          
         
         pecl                          Installation    of     PHP 
                                       Extensions Using pecl      
         
         pip_state                     Installation   of   Python 
                                       Packages Using pip         
         
         pkg                           Installation  of  packages 
                                       using  OS package managers 
                                       such as yum or apt-get     
         
         pkgbuild                      The pkgbuild state is  the 
                                       front   of   Salt  package 
                                       building backend.          
         
         pkgng                         Manage package remote repo 
                                       using FreeBSD pkgng        
         
         pkgrepo                       Management    of   APT/YUM 
                                       package repos              
         
         portage_config                Management   of    Portage 
                                       package  configuration  on 
                                       Gentoo                     
         
         ports                         Manage    software    from 
                                       FreeBSD ports              
         
         postgres_cluster              Management  of  PostgreSQL 
                                       clusters                   
         
         postgres_database             Management  of  PostgreSQL 
                                       databases                  
         
         postgres_extension            Management  of  PostgreSQL 
                                       extensions                 
         
         postgres_group                Management  of  PostgreSQL 
                                       groups (roles)             
         
         postgres_initdb               Initialization          of 
                                       PostgreSQL data directory  
         
         postgres_language             Management  of  PostgreSQL 
                                       languages                  
         
         postgres_privileges           Management  of  PostgreSQL 
                                       Privileges                 
         
         postgres_schema               Management  of  PostgreSQL 
                                       schemas                    
         

         postgres_tablespace           Management  of  PostgreSQL 
                                       tablespace                 
         
         postgres_user                 Management  of  PostgreSQL 
                                       users (roles)              
         
         powerpath                     Powerpath    configuration 
                                       support                    
         
         probes                        Network Probes             
         
         process                       Process Management         
         
         pushover                      Send a message to PushOver 
         
         pyenv                         Managing            python 
                                       installations with pyenv   
         
         pyrax_queues                  Manage Rackspace Queues    
         
         quota                         Management of POSIX Quotas 
         
         rabbitmq_cluster              Manage RabbitMQ Clusters   
         
         rabbitmq_plugin               Manage RabbitMQ Plugins    
         
         rabbitmq_policy               Manage RabbitMQ Policies   
         
         rabbitmq_user                 Manage RabbitMQ Users      
         
         rabbitmq_vhost                Manage   RabbitMQ  Virtual 
                                       Hosts                      
         
         rbenv                         Managing              Ruby 
                                       installations with rbenv   
         
         rdp                           Manage   RDP   Service  on 
                                       Windows servers            
         
         redismod                      Management of Redis server 
         
         reg                                                      
         
         rsync                         State to synchronize files 
                                       and    directories    with 
                                       rsync.                     
         
         rvm                           Managing              Ruby 
                                       installations  and gemsets 
                                       with Ruby Version  Manager 
                                       (RVM)                      
         
         salt_proxy                    Salt proxy state           
         
         saltmod                       Control  the  Salt command 
                                       interface                  
         
         schedule                      Management  of  the   Salt 
                                       scheduler                  
         
         selinux                       Management    of   SELinux 
                                       rules                      
         
         serverdensity_device          Monitor Server with Server 
                                       Density                    
         
         service                       Starting  or restarting of 
                                       services and daemons       
         
         slack                         Send a message to Slack    
         
         smartos                       Management   of    SmartOS 
                                       Standalone Compute Nodes   
         
         smtp                          Sending Messages via SMTP  
         
         splunk                        Splunk User State Module   
         
         splunk_search                 Splunk Search State Module 
         
         sqlite3                       Management    of   SQLite3 
                                       databases                  
         
         ssh_auth                      Control of entries in  SSH 
                                       authorized_key files       
         
         ssh_known_hosts               Control of SSH known_hosts 
                                       entries                    
         
         stateconf                     Stateconf System           
         
         status                        Minion status monitoring   
         
         stormpath_account             Support for Stormpath.     
         
         supervisord                   Interaction    with    the 
                                       Supervisor daemon          
         
         svn                           Manage SVN repositories    
         
         sysctl                        Configuration of the Linux 
                                       kernel using sysctl        
         
         syslog_ng                     State module for syslog_ng 
         
         sysrc                                                    
         
         telemetry_alert               New in version 2016.3.0..  
         
         test                          Test States                
         
         timezone                      Management of timezones    
         
         tls                           Enforce state for SSL/TLS  
         
         tomcat                        Manage Apache  Tomcat  web 
                                       applications               
         
         trafficserver                 Control   Apache   Traffic 
                                       Server                     
         
         tuned                         Interface   to   Red   Hat 
                                       tuned-adm module           
         
         uptime                        Monitor  Web  Server  with 
                                       Uptime                     
         
         user                          Management     of     user 
                                       accounts                   
         
         vbox_guest                    VirtualBox Guest Additions 
                                       installer state            
         
         victorops                     Create   an    Event    in 
                                       VictorOps                  
         
         virt                          Manage virt                
         
         virtualenv_mod                Setup of Python virtualenv 
                                       sandboxes.                 
         
         win_certutil                  Installing of certificates 
                                       to the Windows Certificate 
                                       Manager                    
         
         win_dacl                      Windows   Object    Access 
                                       Control Lists              
         
         win_dism                      Installing    of   Windows 
                                       features using DISM        
         
         win_dns_client                Module for configuring DNS 
                                       Client on Windows systems  
         
         win_firewall                  State    for   configuring 
                                       Windows Firewall           
         
         win_iis                       Microsoft     IIS     site 
                                       management                 
         
         win_license                   Installation           and 
                                       activation   of    windows 
                                       licenses                   
         
         win_network                   Configuration  of  network 
                                       interfaces   on    Windows 
                                       hosts                      
         
         win_path                      Manage  the Windows System 
                                       PATH                       
         
         win_powercfg                  This module allows you  to 
                                       control the power settings 
                                       of a  windows  minion  via 
                                       powercfg.                  
         
         win_servermanager             Manage   Windows  features 
                                       via   the    ServerManager 
                                       powershell module          
         
         win_smtp_server               Module  for  managing  IIS 
                                       SMTP server  configuration 
                                       on Windows servers.        
         
         win_system                    Management    of   Windows 
                                       system information         
         
         win_update                    Management of the  windows 
                                       update agent               
         
         winrepo                       Manage   Windows   Package 
                                       Repository                 
         
         x509                          Manage X509 Certificates   
         
         xmpp                          Sending Messages over XMPP 
         
         zabbix_host                   Management    of    Zabbix 
                                       hosts.                     
         
         zabbix_hostgroup              Management  of Zabbix host 
                                       groups.                    
         
         zabbix_user                   Management    of    Zabbix 
                                       users.                     
         
         zabbix_usergroup              Management  of Zabbix user 
                                       groups.                    
         
         zcbuildout                    Management of zc.buildout  
         
         zenoss                        State to manage monitoring 
                                       in Zenoss.                 
         
         zk_concurrency                Control   concurrency   of 
                                       steps     within     state 
                                       execution using zookeeper  
         
         zfs                           Management zfs datasets    
         
         zpool                         Management zpool           
         

   salt.states.acme module
   ACME / Let's Encrypt certificate management state
   See also the module documentation

      reload-gitlab:
        cmd.run:
          - name: gitlab-ctl hup

      dev.example.com:
        acme.cert:
          - aliases:
            - gitlab.example.com
          - email: [email protected]
          - webroot: /opt/gitlab/embedded/service/gitlab-rails/public
          - renew: 14
          - fire_event: acme/dev.example.com
          - onchanges_in:
            - cmd: reload-gitlab

   salt.states.acme.cert(name,   aliases=None,  email=None,  webroot=None,
   test_cert=False, renew=None, keysize=None,  server=None,  owner='root',
   group='root')
          Obtain/renew  a  certificate  from  an  ACME  CA, probably Let's
          Encrypt.

          Parameters

                 * name -- Common Name of the  certificate  (DNS  name  of
                   certificate)

                 * aliases  --  subjectAltNames  (Additional  DNS names on
                   certificate)

                 * email --  e-mail  address  for  interaction  with  ACME
                   provider

                 * webroot  --  True  or  full  path  to  webroot used for
                   authentication

                 * test_cert --  Request  a  certificate  from  the  Happy
                   Hacker Fake CA (mutually exclusive with 'server')

                 * renew  --  True/'force' to force a renewal, or a window
                   of renewal before expiry in days

                 * keysize -- RSA key bits

                 * server -- API endpoint to talk to

                 * owner -- owner of private key

                 * group -- group of private key

   salt.states.alias
   Configuration of email aliases

   The mail aliases  file  can  be  managed  to  contain  definitions  for
   specific email aliases:

      username:
        alias.present:
          - target: [email protected]

      thomas:
        alias.present:
          - target: [email protected]

   The  default  alias  file  is set to /etc/aliases, as defined in Salt's
   config execution module. To change the  alias  file  from  the  default
   location, set the following in your minion config:

      aliases.file: /my/alias/file

   salt.states.alias.absent(name)
          Ensure that the named alias is absent

          name   The alias to remove

   salt.states.alias.present(name, target)
          Ensures that the named alias is present with the given target or
          list of targets. If the alias exists but the target differs from
          the  previous  entry,  the target(s) will be overwritten. If the
          alias does not exist, the alias will be created.

          name   The local user/address to assign an alias to

          target The forwarding address

   salt.states.alternatives
   Configuration of the alternatives system

   Control the alternatives system

      {% set my_hadoop_conf = '/opt/hadoop/conf' %}

      {{ my_hadoop_conf }}:
        file.directory

      hadoop-0.20-conf:
        alternatives.install:
          - name: hadoop-0.20-conf
          - link: /etc/hadoop-0.20/conf
          - path: {{ my_hadoop_conf }}
          - priority: 30
          - require:
            - file: {{ my_hadoop_conf }}

      hadoop-0.20-conf:
        alternatives.remove:
          - name: hadoop-0.20-conf
          - path: {{ my_hadoop_conf }}

   salt.states.alternatives.auto(name)
          New in version 0.17.0.

          Instruct alternatives to  use  the  highest  priority  path  for
          <name>

          name   is the master name for this link group (e.g. pager)

   salt.states.alternatives.install(name, link, path, priority)
          Install new alternative for defined <name>

          name   is the master name for this link group (e.g. pager)

          link   is  the  symlink  pointing  to  /etc/alternatives/<name>.
                 (e.g. /usr/bin/pager)

          path   is the location of the new alternative target.  NB:  This
                 file    /    directory   must   already   exist.    (e.g.
                 /usr/bin/less)

          priority
                 is an integer; options with higher  numbers  have  higher
                 priority in automatic mode.

   salt.states.alternatives.remove(name, path)
          Removes  installed  alternative for defined <name> and <path> or
          fallback to default alternative, if some defined before.

          name   is the master name for this link group (e.g. pager)

          path   is the location of one of the alternative  target  files.
                 (e.g. /usr/bin/less)

   salt.states.alternatives.set(name, path)
          New in version 0.17.0.

          Sets  alternative  for <name> to <path>, if <path> is defined as
          an alternative for <name>.

          name   is the master name for this link group (e.g. pager)

          path   is the location of one of the alternative  target  files.
                 (e.g. /usr/bin/less)

   salt.states.apache
   Apache state

   New in version 2014.7.0.

   Allows  for  inputting  a  yaml  dictionary  into  a  file  for  apache
   configuration files.

   The variable this is special and signifies what should be included with
   the above word between angle brackets (<>).

      /etc/httpd/conf.d/website.com.conf:
        apache.configfile:
          - config:
            - VirtualHost:
                this: '*:80'
                ServerName:
                  - website.com
                ServerAlias:
                  - www.website.com
                  - dev.website.com
                ErrorLog: logs/website.com-error_log
                CustomLog: logs/website.com-access_log combined
                DocumentRoot: /var/www/vhosts/website.com
                Directory:
                  this: /var/www/vhosts/website.com
                  Order: Deny,Allow
                  Deny from: all
                  Allow from:
                    - 127.0.0.1
                    - 192.168.100.0/24
                  Options:
                    - Indexes
                    - FollowSymlinks
                  AllowOverride: All

   salt.states.apache_conf module
   Manage Apache Confs

   New in version 2016.3.0.

   Enable and disable apache confs.

      Enable security conf:
        apache_conf.enabled:
          - name: security

      Disable security conf:
        apache_conf.disabled:
          - name: security

   salt.states.apache_conf.disable(name)
          Ensure an Apache conf is disabled.

          WARNING:
             This  function  is  deprecated  and  will  be removed in Salt
             Nitrogen.

          name   Name of the Apache conf

   salt.states.apache_conf.disabled(name)
          Ensure an Apache conf is disabled.

          name   Name of the Apache conf

   salt.states.apache_conf.enable(name)
          Ensure an Apache conf is enabled.

          WARNING:
             This function is deprecated  and  will  be  removed  in  Salt
             Nitrogen.

          name   Name of the Apache conf

   salt.states.apache_conf.enabled(name)
          Ensure an Apache conf is enabled.

          name   Name of the Apache conf

   salt.states.apache_module
   Manage Apache Modules

   New in version 2014.7.0.

   Enable and disable apache modules.

      Enable cgi module:
        apache_module.enabled:
          - name: cgi

      Disable cgi module:
        apache_module.disabled:
          - name: cgi

   salt.states.apache_module.disable(name)
          Ensure an Apache module is disabled.

          Deprecated since version 2016.3.0.

          name   Name of the Apache module

   salt.states.apache_module.disabled(name)
          Ensure an Apache module is disabled.

          New in version 2016.3.0.

          name   Name of the Apache module

   salt.states.apache_module.enable(name)
          Ensure  an Apache module is enabled. This function is deprecated
          and will be removed in Salt Nitrogen.  Please  use  the  enabled
          state function instead.

          Deprecated since version 2016.3.0.

          name   Name of the Apache module

   salt.states.apache_module.enabled(name)
          Ensure an Apache module is enabled.

          New in version 2016.3.0.

          name   Name of the Apache module

   salt.states.apache_site module
   Manage Apache Sites

   New in version 2016.3.0.

   Enable and disable apache sites.

      Enable default site:
        apache_site.enabled:
          - name: default

      Disable default site:
        apache_site.disabled:
          - name: default

   salt.states.apache_site.disable(name)
          Ensure an Apache site is disabled.

          WARNING:
             This  function  is  deprecated  and  will  be removed in Salt
             Nitrogen.

          name   Name of the Apache site

   salt.states.apache_site.disabled(name)
          Ensure an Apache site is disabled.

          name   Name of the Apache site

   salt.states.apache_site.enable(name)
          Ensure an Apache site is enabled.

          WARNING:
             This function is deprecated  and  will  be  removed  in  Salt
             Nitrogen.

          name   Name of the Apache site

   salt.states.apache_site.enabled(name)
          Ensure an Apache site is enabled.

          name   Name of the Apache site

   salt.states.aptpkg
   Package management operations specific to APT- and DEB-based systems
   salt.states.aptpkg.held(name)
          Set package in 'hold' state, meaning it will not be upgraded.

          name   The name of the package, e.g., 'tmux'

   salt.states.archive
   Extract an archive

   New in version 2014.1.0.

   salt.states.archive.extracted(name,      source,      source_hash=None,
   source_hash_name=None,   source_hash_update=False,   skip_verify=False,
   password=None,     options=None,     list_options=None,    force=False,
   overwrite=False, clean=False, user=None,  group=None,  if_missing=None,
   keep=False,  trim_output=False, use_cmd_unzip=None, extract_perms=True,
   enforce_toplevel=True, enforce_ownership_on=None,  archive_format=None,
   **kwargs)
          New in version 2014.1.0.

          Changed  in  version  2016.11.0:  This state has been rewritten.
          Some arguments are new to this release and will not be available
          in  the  2016.3  release cycle (and earlier).  Additionally, the
          ZIP Archive Handling section below applies specifically  to  the
          2016.11.0 release (and newer).

          Ensure that an archive is extracted to a specific directory.

          IMPORTANT:
             ZIP Archive Handling

             Salt has two different functions for extracting ZIP archives:

             1. archive.unzip,  which  uses  Python's  zipfile  module  to
                extract ZIP files.

             2. archive.cmd_unzip, which uses the  unzip  CLI  command  to
                extract ZIP files.

             Salt  will  prefer  the  use  of  archive.cmd_unzip  when CLI
             options are specified (via the options  argument),  and  will
             otherwise   prefer   the   archive.unzip   function.  Use  of
             archive.cmd_unzip  can  be  forced  however  by  setting  the
             use_cmd_unzip  argument  to  True.  By contrast, setting this
             argument to False will  force  usage  of  archive.unzip.  For
             example:

                 /var/www:
                   archive.extracted:
                     - source: salt://foo/bar/myapp.zip
                     - use_cmd_unzip: True

             When   use_cmd_unzip  is  omitted,  Salt  will  choose  which
             extraction function to use based on the  source  archive  and
             the  arguments  passed to the state. When in doubt, simply do
             not  set  this  argument;  it  is  provided  as  a  means  of
             overriding  the  logic  Salt uses to decide which function to
             use.

             There are differences  in  the  features  available  in  both
             extraction functions. These are detailed below.

             * Command-line  options (only supported by archive.cmd_unzip)
               - When the options argument is used,  archive.cmd_unzip  is
               the  only function that can be used to extract the archive.
               Therefore, if use_cmd_unzip is specified and set to  False,
               and options is also set, the state will not proceed.

             * Password-protected   ZIP   Archives   (only   supported  by
               archive.unzip) - archive.cmd_unzip is not be  permitted  to
               extract  password-protected  ZIP archives, as attempting to
               do so will cause the unzip command to block on user  input.
               The archive.is_encrypted function will be used to determine
               if the archive is password-protected. If it  is,  then  the
               password  argument  will  be  required  for  the  state  to
               proceed. If use_cmd_unzip is specified  and  set  to  True,
               then the state will not proceed.

             * Permissions - Due to an upstream bug in Python, permissions
               are not preserved  when  the  zipfile  module  is  used  to
               extract   an   archive.    As  of  the  2016.11.0  release,
               archive.unzip (as well as this state) has an  extract_perms
               argument  which,  when  set  to  True  (the  default), will
               attempt  to  match  the  permissions   of   the   extracted
               files/directories  to  those defined within the archive. To
               disable this functionality and have the state  not  attempt
               to  preserve  the  permissions  from  the  ZIP archive, set
               extract_perms to False:

                   /var/www:
                     archive.extracted:
                       - source: salt://foo/bar/myapp.zip
                       - extract_perms: False

          name   Directory into which the archive should be extracted

          source Archive to be extracted

                 NOTE:
                    This argument uses the same syntax as its  counterpart
                    in the file.managed state.

          source_hash
                 Hash  of  source  file, or file with list of hash-to-file
                 mappings

                 NOTE:
                    This argument uses the same syntax as its  counterpart
                    in the file.managed state.

                 Changed  in version 2016.11.0: If this argument specifies
                 the hash itself, instead of a URI to  a  file  containing
                 hashes,  the  hash  type can now be omitted and Salt will
                 determine the hash type based on the length of the  hash.
                 For  example,  both  of  the  below states are now valid,
                 while before only the second one would be:

                    foo_app:
                      archive.extracted:
                        - name: /var/www
                        - source: https://mydomain.tld/foo.tar.gz
                        - source_hash: 3360db35e682f1c5f9c58aa307de16d41361618c

                    bar_app:
                      archive.extracted:
                        - name: /var/www
                        - source: https://mydomain.tld/bar.tar.gz
                        - source_hash: sha1=5edb7d584b82ddcbf76e311601f5d4442974aaa5

          source_hash_name
                 When source_hash refers to a hash file, Salt will try  to
                 find  the  correct  hash by matching the filename part of
                 the source URI. When managing a file  with  a  source  of
                 salt://files/foo.tar.gz,  then  the  following  line in a
                 hash file would match:

                    acbd18db4cc2f85cedef654fccc4a4d8    foo.tar.gz

                 This line would also match:

                    acbd18db4cc2f85cedef654fccc4a4d8    ./dir1/foo.tar.gz

                 However, sometimes a  hash  file  will  include  multiple
                 similar paths:

                    37b51d194a7513e45b56f6524f2d51f2    ./dir1/foo.txt
                    acbd18db4cc2f85cedef654fccc4a4d8    ./dir2/foo.txt
                    73feffa4b7f6bb68e44cf984c85f6e88    ./dir3/foo.txt

                 In  cases  like  this, Salt may match the incorrect hash.
                 This argument can be used to tell Salt which filename  to
                 match, to ensure that the correct hash is identified. For
                 example:

                    /var/www:
                      archive.extracted:
                        - source: https://mydomain.tld/dir2/foo.tar.gz
                        - source_hash: https://mydomain.tld/hashes
                        - source_hash_name: ./dir2/foo.tar.gz

                 NOTE:
                    This argument must contain  the  full  filename  entry
                    from  the  checksum file, as this argument is meant to
                    disambiguate matches for multiple files that have  the
                    same  basename. So, in the example above, simply using
                    foo.txt would not match.

                 New in version 2016.11.0.

          source_hash_update
                 Set this to  True  if  archive  should  be  extracted  if
                 source_hash has changed. This would extract regardless of
                 the if_missing parameter.

                 New in version 2016.3.0.

          skip_verify
                 False If True, hash verification of remote  file  sources
                 (http://,  https://,  ftp://)  will  be  skipped, and the
                 source_hash argument will be ignored.

                 New in version 2016.3.4.

          password
                 For ZIP archives only. Password used for extraction.

                 New in version 2016.3.0.

          options
                 For tar and zip archives only.  This option can  be  used
                 to  specify  a  string of additional arguments to pass to
                 the tar/zip command.

                 If this argument  is  not  used,  then  the  minion  will
                 attempt to use Python's native tarfile/zipfile support to
                 extract it. For zip archives,  this  argument  is  mostly
                 used to overwrite exsiting files with o.

                 Using  this  argument means that the tar or unzip command
                 will be used, which is less platform-independent, so keep
                 this in mind when using this option; the CLI options must
                 be valid options for the tar/unzip implementation on  the
                 minion's OS.

                 New in version 2016.11.0: The tar_options and zip_options
                 parameters have been deprecated  in  favor  of  a  single
                 argument name.

                 Changed  in version 2015.8.11,2016.3.2: XZ-compressed tar
                 archives no longer require J to manually be  set  in  the
                 options,   they   are   now  detected  automatically  and
                 decompressed using the xz CLI command and extracted using
                 tar xvf. This is a more platform-independent solution, as
                 not all tar implementations support the  J  argument  for
                 extracting archives.

                 NOTE:
                    For  tar  archives, main operators like -x, --extract,
                    --get, -c and -f/--file should not be used here.

          tar_options
                 Deprecated since version 2016.11.0: Use options instead.

          zip_options
                 New in version 2016.3.1.

                 Deprecated since version 2016.11.0: Use options instead.

          list_options
                 For tar archives only. This state  uses  archive.list  to
                 discover  the  contents  of the source archive so that it
                 knows which file paths should exist on the minion if  the
                 archive has already been extracted. For the vast majority
                 of tar  archives,  archive.list  "just  works".  Archives
                 compressed  using gzip, bzip2, and xz/lzma (with the help
                 of the  xz  CLI  command)  are  supported  automatically.
                 However,  for archives compressed using other compression
                 types, CLI options must be passed to archive.list.

                 This argument will be passed through to  archive.list  as
                 its  options  argument,  to allow it to successfully list
                 the  archive's  contents.  For  the  vast   majority   of
                 archives,  this  argument  should not need to be used, it
                 should only be needed in cases where the state fails with
                 an error stating that the archive's contents could not be
                 listed.

                 New in version 2016.11.0.

          force  False If a path that should be occupied by a file in  the
                 extracted  result is instead a directory (or vice-versa),
                 the state will fail. Set this argument to True  to  force
                 these  paths  to be removed in order to allow the archive
                 to be extracted.

                 WARNING:
                    Use this option very carefully.

                 New in version 2016.11.0.

          overwrite
                 False Set this  to  True  to  force  the  archive  to  be
                 extracted.   This   is   useful   for   cases  where  the
                 filenames/directories have not changed, but  the  content
                 of the files have.

                 New in version 2016.11.1.

          clean  False  Set this to True to remove any top-level files and
                 recursively remove any top-level directory  paths  before
                 extracting.

                 NOTE:
                    Files  will  only  be  cleaned first if extracting the
                    archive is deemed necessary, either by  paths  missing
                    on the minion, or if overwrite is set to True.

                 New in version 2016.11.1.

          user   The  user  to  own  each extracted file. Not available on
                 Windows.

                 New in version 2015.8.0.

                 Changed in version 2016.3.0:  When  used  in  combination
                 with  if_missing,  ownership  will  only  be  enforced if
                 if_missing is a directory.

                 Changed in version 2016.11.0: Ownership will be  enforced
                 only   on  the  file/directory  paths  found  by  running
                 archive.list on the source archive. An  alternative  root
                 directory  on which to enforce ownership can be specified
                 using the enforce_ownership_on argument.

          group  The group to own each extracted file.  Not  available  on
                 Windows.

                 New in version 2015.8.0.

                 Changed  in  version  2016.3.0:  When used in combination
                 with if_missing,  ownership  will  only  be  enforced  if
                 if_missing is a directory.

                 Changed  in version 2016.11.0: Ownership will be enforced
                 only  on  the  file/directory  paths  found  by   running
                 archive.list  on  the source archive. An alternative root
                 directory on which to enforce ownership can be  specified
                 using the enforce_ownership_on argument.

          if_missing
                 If specified, this path will be checked, and if it exists
                 then the archive will not be extracted. This path can  be
                 either  a directory or a file, so this option can also be
                 used to check for a semaphore file and conditionally skip
                 extraction.

                 Changed  in  version  2016.3.0:  When used in combination
                 with  either  user  or  group,  ownership  will  only  be
                 enforced when if_missing is a directory.

                 Changed in version 2016.11.0: Ownership enforcement is no
                 longer tied to this argument, it is  simply  checked  for
                 existence  and  extraction  will  be  skipped  if  if  is
                 present.

          keep   False For source archives not local to the  minion  (i.e.
                 from  the  Salt  fileserver  or  a  remote source such as
                 http(s) or ftp), Salt will need to download  the  archive
                 to  the  minion cache before they can be extracted. After
                 extraction, these source archives will be removed  unless
                 this argument is set to True.

          trim_output
                 False  Useful  for archives with many files in them. This
                 can either be set to True (in which case only  the  first
                 100  files extracted will be in the state results), or it
                 can be set to an integer for more exact control over  the
                 max number of files to include in the state results.

                 New in version 2016.3.0.

          use_cmd_unzip
                 False  Set  to  True  for zip files to force usage of the
                 archive.cmd_unzip function to extract.

                 New in version 2016.11.0.

          extract_perms
                 True For ZIP archives only. When using  archive.unzip  to
                 extract  ZIP  archives, Salt works around an upstream bug
                 in  Python  to   set   the   permissions   on   extracted
                 files/directories  to  match  those  encoded into the ZIP
                 archive.  Set  this  argument  to  False  to  skip   this
                 workaround.

                 New in version 2016.11.0.

          enforce_toplevel
                 True  This  option will enforce a single directory at the
                 top level of the source archive, to prevent extracting  a
                 'tar-bomb'.  Set this argument to False to allow archives
                 with files (or multiple directories) at the top level  to
                 be extracted.

                 New in version 2016.11.0.

          enforce_ownership_on
                 When  user  or  group  is specified, Salt will default to
                 enforcing  permissions  on   the   file/directory   paths
                 detected  by  running archive.list on the source archive.
                 Use this argument to specify an  alternate  directory  on
                 which ownership should be enforced.

                 NOTE:
                    This  path  must  be  within the path specified by the
                    name argument.

                 New in version 2016.11.0.

          archive_format
                 One of tar, zip, or rar.

                 Changed in version 2016.11.0:  If  omitted,  the  archive
                 format  will  be guessed based on the value of the source
                 argument.

          Examples

          1. tar with lmza (i.e. xz) compression:

                graylog2-server:
                  archive.extracted:
                    - name: /opt/
                    - source: https://github.com/downloads/Graylog2/graylog2-server/graylog2-server-0.9.6p1.tar.lzma
                    - source_hash: md5=499ae16dcae71eeb7c3a30c75ea7a1a6

          2. tar archive with flag for verbose output, and enforcement  of
             user/group ownership:

                graylog2-server:
                  archive.extracted:
                    - name: /opt/
                    - source: https://github.com/downloads/Graylog2/graylog2-server/graylog2-server-0.9.6p1.tar.gz
                    - source_hash: md5=499ae16dcae71eeb7c3a30c75ea7a1a6
                    - tar_options: v
                    - user: foo
                    - group: foo

          3. tar  archive,  with source_hash_update set to True to prevent
             state  from  attempting  extraction  unless  the  source_hash
             differs from the previous time the archive was extracted:

                graylog2-server:
                  archive.extracted:
                    - name: /opt/
                    - source: https://github.com/downloads/Graylog2/graylog2-server/graylog2-server-0.9.6p1.tar.lzma
                    - source_hash: md5=499ae16dcae71eeb7c3a30c75ea7a1a6
                    - source_hash_update: True

   salt.states.artifactory
   This state downloads artifacts from artifactory.

   salt.states.artifactory.downloaded(name,  artifact,  target_dir='/tmp',
   target_file=None)
          Ensures that the  artifact  from  artifactory  exists  at  given
          location. If it doesn't exist, then it will be downloaded. It it
          already exists then the checksum of  existing  file  is  checked
          against  checksum  in  artifactory.  If it is different then the
          step will fail.

          artifact
                 Details  of  the   artifact   to   be   downloaded   from
                 artifactory. Various options are:

                 * artifactory_url: URL of the artifactory instance

                 * repository: Repository in artifactory

                 * artifact_id: Artifact ID

                 * group_id: Group ID

                 * packaging: Packaging

                 * classifier: Classifier

                 *

                   version: Version
                          One  of  the  following: - Version to download -
                          latest - Download the  latest  release  of  this
                          artifact - latest_snapshot - Download the latest
                          snapshot for this artifact

                 * username: Artifactory username

                 * password: Artifactory password

          target_dir
                 Directory where the artifact  should  be  downloaded.  By
                 default it is downloaded to /tmp directory.

          target_file
                 Target file to download artifact to. By default file name
                 is resolved by artifactory.

          An example to download an artifact to a specific file:

             jboss_module_downloaded:
               artifactory.downloaded:
                - artifact:
                    artifactory_url: http://artifactory.intranet.example.com/artifactory
                    repository: 'libs-release-local'
                    artifact_id: 'module'
                    group_id: 'com.company.module'
                    packaging: 'jar'
                    classifier: 'sources'
                    version: '1.0'
                - target_file: /opt/jboss7/modules/com/company/lib/module.jar

          Download artifact to the  folder  (automatically  resolves  file
          name):

             jboss_module_downloaded:
               artifactory.downloaded:
                - artifact:
                     artifactory_url: http://artifactory.intranet.example.com/artifactory
                     repository: 'libs-release-local'
                     artifact_id: 'module'
                     group_id: 'com.company.module'
                     packaging: 'jar'
                     classifier: 'sources'
                     version: '1.0'
                - target_dir: /opt/jboss7/modules/com/company/lib

   salt.states.at
   Configuration disposable regularly scheduled tasks for at.
   The  at  state can be add disposable regularly scheduled tasks for your
   system.

   salt.states.at.absent(name, jobid=None, **kwargs)
          Remove a job from queue The 'kwargs' can include  hour.  minute.
          day. month. year

          limit  Target range

          tag    Job's tag

          runas  Runs user-specified jobs

             example1:
               at.absent:
                 - limit: all

             example2:
               at.absent:
                 - limit: all
                 - year: 13

             example3:
               at.absent:
                 - limit: all
                 - tag: rose
                 - runas: jim

             example4:
               at.absent:
                 - limit: all
                 - tag: rose
                 - day: 13
                 - hour: 16

   salt.states.at.present(name, timespec, tag=None, user=None, job=None)
          Add a job to queue.

          job    Command to run.

          timespec
                 The 'timespec' follows the format documented in the at(1)
                 manpage.

          tag    Make a tag for the job.

          user   The user to run the at job

                 New in version 2014.1.4.

             rose:
               at.present:
                 - job: 'echo "I love saltstack" > love'
                 - timespec: '9:09 11/09/13'
                 - tag: love
                 - user: jam

   salt.states.augeas
   Configuration management using Augeas

   New in version 0.17.0.

   This state requires the augeas Python module.

   Augeas can be used to manage configuration files.

   WARNING:
      Minimal installations of Debian and Ubuntu have been  seen  to  have
      packaging bugs with python-augeas, causing the augeas module to fail
      to import. If the minion has the augeas module  installed,  and  the
      state  fails  with  a  comment saying that the state is unavailable,
      first restart the salt-minion service. If the problem persists  past
      that,  the following command can be run from the master to determine
      what is causing the import to fail:

          salt minion-id cmd.run 'python -c "from augeas import Augeas"'

      For affected Debian/Ubuntu hosts, installing libpython2.7  has  been
      known to resolve the issue.

   salt.states.augeas.change(name,  context=None, changes=None, lens=None,
   load_path=None, **kwargs)
          New in version 2014.7.0.

          This state replaces setvalue().

          Issue changes to Augeas, optionally for a specific context, with
          a specific lens.

          name   State name

          context
                 A  file  path,  prefixed  by /files. Should resolve to an
                 actual file (not an arbitrary augeas path). This is  used
                 to  avoid  duplicating the file name for each item in the
                 changes list  (for  example,  set  bind  0.0.0.0  in  the
                 example below operates on the file specified by context).
                 If context is not specified,  a  file  path  prefixed  by
                 /files should be included with the set command.

                 The  file  path is examined to determine if the specified
                 changes are already present.

                    redis-conf:
                      augeas.change:
                        - context: /files/etc/redis/redis.conf
                        - changes:
                          - set bind 0.0.0.0
                          - set maxmemory 1G

          changes
                 List of changes that  are  issued  to  Augeas.  Available
                 commands   are   set,   setm,  mv/move,  ins/insert,  and
                 rm/remove.

          lens   The lens to use, needs to be suffixed  with  .lns,  e.g.:
                 Nginx.lns.   See  the  list  of stock lenses shipped with
                 Augeas.

          New in version 2016.3.0.

          load_path
                 A list of directories that modules should be searched in.
                 This  is  in  addition  to the standard load path and the
                 directories in AUGEAS_LENS_LIB.

          Usage examples:

          Set the bind parameter in /etc/redis/redis.conf:

             redis-conf:
               augeas.change:
                 - changes:
                   - set /files/etc/redis/redis.conf/bind 0.0.0.0

          NOTE:
             Use the context parameter to specify the  file  you  want  to
             manipulate.  This  way  you don't have to include this in the
             changes every time:

                 redis-conf:
                   augeas.change:
                     - context: /files/etc/redis/redis.conf
                     - changes:
                       - set bind 0.0.0.0
                       - set databases 4
                       - set maxmemory 1G

          Augeas is aware of a lot of common configuration files and their
          syntax.   It  knows  the  difference between for example ini and
          yaml files, but also files with very specific syntax,  like  the
          hosts  file.  This  is  done with lenses, which provide mappings
          between the Augeas tree and the file.

          There are many preconfigured lenses that  come  with  Augeas  by
          default, and they specify the common locations for configuration
          files. So most of the time Augeas will know how to manipulate  a
          file.  In  the  event  that  you  need to manipulate a file that
          Augeas doesn't know about, you can specify the lens to use  like
          this:

             redis-conf:
               augeas.change:
                 - lens: redis
                 - context: /files/etc/redis/redis.conf
                 - changes:
                   - set bind 0.0.0.0

          NOTE:
             Even  though  Augeas  knows  that  /etc/redis/redis.conf is a
             Redis configuration file and knows how to  parse  it,  it  is
             recommended  to  specify  the lens anyway. This is because by
             default, Augeas loads all known lenses and  their  associated
             file paths. All these files are parsed when Augeas is loaded,
             which can take some time. When specifying a lens,  Augeas  is
             loaded  with  only  that lens, which speeds things up quite a
             bit.

          A more complex example, this adds an entry to the services  file
          for Zabbix, and removes an obsolete service:

             zabbix-service:
               augeas.change:
                 - lens: services
                 - context: /files/etc/services
                 - changes:
                   - ins service-name after service-name[last()]
                   - set service-name[last()] zabbix-agent
                   - set service-name[. = 'zabbix-agent']/#comment "Zabbix Agent service"
                   - set service-name[. = 'zabbix-agent']/port 10050
                   - set service-name[. = 'zabbix-agent']/protocol tcp
                   - rm service-name[. = 'im-obsolete']
                 - unless: grep "zabbix-agent" /etc/services

          WARNING:
             Don't  forget  the unless here, otherwise a new entry will be
             added every time this state is run.

   salt.states.aws_sqs
   Manage SQS Queues

   Create and destroy SQS  queues.  Be  aware  that  this  interacts  with
   Amazon's services, and so may incur charges.

   This  module  uses  the  awscli  tool  provided  by Amazon. This can be
   downloaded from pip.  Also  check  the  documentation  for  awscli  for
   configuration information.

      myqueue:
          aws_sqs.exists:
              - region: eu-west-1

   salt.states.aws_sqs.absent(name, region, user=None, opts=False)
          Remove the named SQS queue if it exists.

          name   Name of the SQS queue.

          region Region to remove the queue from

          user   Name of the user performing the SQS operations

          opts   Include  additional  arguments  and  options  to  the aws
                 command line

   salt.states.aws_sqs.exists(name, region, user=None, opts=False)
          Ensure the SQS queue exists.

          name   Name of the SQS queue.

          region Region to create the queue

          user   Name of the user performing the SQS operations

          opts   Include additional  arguments  and  options  to  the  aws
                 command line

   salt.states.beacon
   Management of the Salt beacons
   New in version 2015.8.0.

      ps:
        beacon.present:
          - enable: False
          - salt-master: running
          - apache2: stopped

      sh:
        beacon.present:

      load:
        beacon.present:
          - 1m:
              - 0.0
              - 2.0
          - 5m:
              - 0.0
              - 1.5
          - 15m:
              - 0.1
              - 1.0

   salt.states.beacon.absent(name, **kwargs)
          Ensure beacon is absent.

          name   The name of the beacon ensured absent.

   salt.states.beacon.disabled(name, **kwargs)
          Disable a beacon.

          name   The name of the beacon to enable.

   salt.states.beacon.enabled(name, **kwargs)
          Enable a beacon.

          name   The name of the beacon to enable.

   salt.states.beacon.present(name, **kwargs)
          Ensure beacon is configured with the included beacon data.

          name   The name of the beacon ensure is configured.

   salt.states.bigip
   A state module designed to enforce load-balancing configurations for F5
   Big-IP entities.

          maturity
                 develop

          platform
                 f5_bigip_11.6

   salt.states.bigip.add_pool_member(hostname, username,  password,  name,
   member)
          A  function to connect to a bigip device and add a new member to
          an existing pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          member The member to add to the pool

   salt.states.bigip.create_monitor(hostname,     username,      password,
   monitor_type, name, **kwargs)
          A function to connect to a bigip device and create a monitor.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to create

          name   The name of the monitor to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

   salt.states.bigip.create_node(hostname,   username,   password,   name,
   address)
          Create a new node if it does not already exist.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to create

          address
                 The address of the node

   salt.states.bigip.create_pool(hostname,   username,   password,   name,
   members=None,   allow_nat=None,   allow_snat=None,    description=None,
   gateway_failsafe_device=None,             ignore_persisted_weight=None,
   ip_tos_to_client=None, ip_tos_to_server=None,  link_qos_to_client=None,
   link_qos_to_server=None,                      load_balancing_mode=None,
   min_active_members=None,                           min_up_members=None,
   min_up_members_action=None, min_up_members_checking=None, monitor=None,
   profiles=None, queue_depth_limit=None,  queue_on_connection_limit=None,
   queue_time_limit=None,  reselect_tries=None,  service_down_action=None,
   slow_ramp_time=None)
          Create a new node if it does not already exist.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to create

          members
                 List of members to be added to the pool

          allow_nat
                 [yes | no]

          allow_snat
                 [yes | no]

          description
                 [string]

          gateway_failsafe_device
                 [string]

          ignore_persisted_weight
                 [enabled | disabled]

          ip_tos_to_client
                 [pass-through | [integer]]

          ip_tos_to_server
                 [pass-through | [integer]]

          link_qos_to_client
                 [pass-through | [integer]]

          link_qos_to_server
                 [pass-through | [integer]]

          load_balancing_mode
                 [dynamic-ratio-member     |     dynamic-ratio-node      |
                 fastest-app-response        |        fastest-node       |
                 least-connections-members  |   least-connections-node   |
                 least-sessions   |   observed-member  |  observed-node  |
                 predictive-member       |        predictive-node        |
                 ratio-least-connections-member                          |
                 ratio-least-connections-node | ratio-member |  ratio-node
                 |        ratio-session        |       round-robin       |
                 weighted-least-connections-member                       |
                 weighted-least-connections-node]

          min_active_members
                 [integer]

          min_up_members
                 [integer]

          min_up_members_action
                 [failover | reboot | restart-all]

          min_up_members_checking
                 [enabled | disabled]

          monitor
                 [name]

          profiles
                 [none | profile_name]

          queue_depth_limit
                 [integer]

          queue_on_connection_limit
                 [enabled | disabled]

          queue_time_limit
                 [integer]

          reselect_tries
                 [integer]

          service_down_action
                 [drop | none | reselect | reset]

          slow_ramp_time
                 [integer]

   salt.states.bigip.create_profile(hostname,      username,     password,
   profile_type, name, **kwargs)
          A function to connect to a bigip device and create a profile.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 profile type.  Typically, tmsh arg names are used.

          Special  Characters |, , and : must be escaped using \ when used
          within strings.

   salt.states.bigip.create_virtual(hostname,  username,  password,  name,
   destination,    pool=None,    address_status=None,   auto_lasthop=None,
   bwc_policy=None,        cmp_enabled=None,        connection_limit=None,
   dhcp_relay=None,      description=None,      fallback_persistence=None,
   flow_eviction_policy=None,       gtm_score=None,       ip_forward=None,
   ip_protocol=None,          internal=None,          twelve_forward=None,
   last_hop_pool=None, mask=None, mirror=None,  nat64=None,  persist=None,
   profiles=None,    policies=None,    rate_class=None,   rate_limit=None,
   rate_limit_mode=None,     rate_limit_dst=None,     rate_limit_src=None,
   rules=None,      related_rules=None,      reject=None,     source=None,
   source_address_translation=None, source_port=None,  virtual_state=None,
   traffic_classes=None,    translate_address=None,   translate_port=None,
   vlans=None)
          A function to connect to a bigip device  and  create  a  virtual
          server if it does not already exists.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to create

          destination
                 [ [virtual_address_name:port] | [ipv4:port] | [ipv6.port]
                 ]

          pool   [ [pool_name] | none]

          address_status
                 [yes | no]

          auto_lasthop
                 [default | enabled | disabled ]

          bwc_policy
                 [none] | string]

          cmp_enabled
                 [yes | no]

          dhcp_relay
                 [yes | no}

          connection_limit
                 [integer]

          description
                 [string]

          state  [disabled | enabled]

          fallback_persistence
                 [none | [profile name] ]

          flow_eviction_policy
                 [none | [eviction policy name] ]

          gtm_score
                 [integer]

          ip_forward
                 [yes | no]

          ip_protocol
                 [any | protocol]

          internal
                 [yes | no]

          twelve_forward(12-forward)
                 [yes | no]

          last_hop-pool
                 [ [pool_name] | none]

          mask   { [ipv4] | [ipv6] }

          mirror { [disabled | enabled | none] }

          nat64  [enabled | disabled]

          persist
                 [list]

          profiles
                 [none | default | list ]

          policies
                 [none | default | list ]

          rate_class
                 [name]

          rate_limit
                 [integer]

          rate_limit-mode
                 [destination   |   object    |    object-destination    |
                 object-source  |  object-source-destination  |  source  |
                 source-destination]

          rate_limit-dst
                 [integer]

          rate_limit-src
                 [integer]

          rules  [none | list ]

          related_rules
                 [none | list ]

          reject [yes | no]

          source { [ipv4[/prefixlen]] | [ipv6[/prefixlen]] }

          source_address_translation
                 [none | snat:pool_name | lsn | automap | dictionary ]

          source_port
                 [change | preserve | preserve-strict]

          state  [enabled | disabled]

          traffic_classes
                 [none | default | list ]

          translate_address
                 [enabled | disabled]

          translate_port
                 [enabled | disabled]

          vlans  [none | default | dictionary]

                 vlan_ids
                        [ list]

                 enabled
                        [ true | false ]

   salt.states.bigip.delete_monitor(hostname,     username,      password,
   monitor_type, name)
          Modify  an  existing  monitor.   If  it  does  exists,  only the
          parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to create

          name   The name of the monitor to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

   salt.states.bigip.delete_node(hostname, username, password, name)
          Delete an existing node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node which will be deleted.

   salt.states.bigip.delete_pool(hostname, username, password, name)
          Delete an existing pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool which will be deleted

   salt.states.bigip.delete_pool_member(hostname,    username,   password,
   name, member)
          Delete an existing pool member.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to be modified

          member The name of the member to delete from the pool

   salt.states.bigip.delete_profile(hostname,     username,      password,
   profile_type, name)
          Modify  an  existing  profile.   If  it  does  exists,  only the
          parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 profile type.  Typically, tmsh arg names are used.

   salt.states.bigip.delete_virtual(hostname, username, password, name)
          Delete an existing virtual.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual which will be deleted

   salt.states.bigip.list_monitor(hostname,       username,      password,
   monitor_type, name)
          A function to list an exsiting monitor.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to list

          name   The name of the monitor to list

   salt.states.bigip.list_node(hostname, username, password, name)
          A function to connect to a bigip  device  and  list  a  specific
          node.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to list.

   salt.states.bigip.list_pool(hostname, username, password, name)
          A  function  to  connect  to  a bigip device and list a specific
          pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to list.

   salt.states.bigip.list_profile(hostname,      username,       password,
   profile_type, name)
          A function to list an existing profile.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to list

          name   The name of the profile to list

   salt.states.bigip.list_virtual(hostname, username, password, name)
          A function to list a specific virtual.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to list

   salt.states.bigip.manage_monitor(hostname,      username,     password,
   monitor_type, name, **kwargs)
          Create a new monitor if a monitor of this type and name does not
          already   exists.   If  it  does  exists,  only  the  parameters
          specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to create

          name   The name of the monitor to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

   salt.states.bigip.manage_node(hostname,   username,   password,   name,
   address, connection_limit=None,  description=None,  dynamic_ratio=None,
   logging=None,  monitor=None, rate_limit=None, ratio=None, session=None,
   node_state=None)
          Manages a node of a given bigip device.  If the  node  does  not
          exist  it  will be created, otherwise, only the properties which
          are different than the existing will be updated.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to manage.

          address
                 The address of the node

          connection_limit
                 [integer]

          description
                 [string]

          dynam  c_ratio:        [integer]

          logging
                 [enabled | disabled]

          monitor
                 [[name] | none | default]

          rate_limit
                 [integer]

          ratio  [integer]

          session
                 [user-enabled | user-disabled]

          node_state (state)
                 [user-down | user-up ]

   salt.states.bigip.manage_pool(hostname,   username,   password,   name,
   allow_nat=None,            allow_snat=None,           description=None,
   gateway_failsafe_device=None,             ignore_persisted_weight=None,
   ip_tos_to_client=None,  ip_tos_to_server=None, link_qos_to_client=None,
   link_qos_to_server=None,                      load_balancing_mode=None,
   min_active_members=None,                           min_up_members=None,
   min_up_members_action=None, min_up_members_checking=None, monitor=None,
   profiles=None,  queue_depth_limit=None, queue_on_connection_limit=None,
   queue_time_limit=None,  reselect_tries=None,  service_down_action=None,
   slow_ramp_time=None)
          Create a new pool if it does not already exist. Pool members are
          managed separately. Only the parameters specified are enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to create

          allow_nat
                 [yes | no]

          allow_snat
                 [yes | no]

          description
                 [string]

          gateway_failsafe_device
                 [string]

          ignore_persisted_weight
                 [enabled | disabled]

          ip_tos_to_client
                 [pass-through | [integer]]

          ip_tos_to_server
                 [pass-through | [integer]]

          link_qos_to_client
                 [pass-through | [integer]]

          link_qos_to_server
                 [pass-through | [integer]]

          load_balancing_mode
                 [dynamic-ratio-member     |     dynamic-ratio-node      |
                 fastest-app-response        |        fastest-node       |
                 least-connections-members  |   least-connections-node   |
                 least-sessions   |   observed-member  |  observed-node  |
                 predictive-member       |        predictive-node        |
                 ratio-least-connections-member                          |
                 ratio-least-connections-node | ratio-member |  ratio-node
                 |        ratio-session        |       round-robin       |
                 weighted-least-connections-member                       |
                 weighted-least-connections-node]

          min_active_members
                 [integer]

          min_up_members
                 [integer]

          min_up_members_action
                 [failover | reboot | restart-all]

          min_up_members_checking
                 [enabled | disabled]

          monitor
                 [name]

          profiles
                 [none | profile_name]

          queue_depth_limit
                 [integer]

          queue_on_connection_limit
                 [enabled | disabled]

          queue_time_limit
                 [integer]

          reselect_tries
                 [integer]

          service_down_action
                 [drop | none | reselect | reset]

          slow_ramp_time
                 [integer]

   salt.states.bigip.manage_pool_members(hostname,   username,   password,
   name, members)
          Manage the members of an existing pool.  This function  replaces
          all  current  pool  members.   Only the parameters specified are
          enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          members
                 list of pool members to manage.

   salt.states.bigip.manage_profile(hostname,     username,      password,
   profile_type, name, **kwargs)
          Create a new profile if a monitor of this type and name does not
          already  exists.   If  it  does  exists,  only  the   parameters
          specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 profile type.  Typically, tmsh arg names are used.

   salt.states.bigip.manage_virtual(hostname,  username,  password,  name,
   destination,    pool=None,    address_status=None,   auto_lasthop=None,
   bwc_policy=None,        cmp_enabled=None,        connection_limit=None,
   dhcp_relay=None,      description=None,      fallback_persistence=None,
   flow_eviction_policy=None,       gtm_score=None,       ip_forward=None,
   ip_protocol=None,          internal=None,          twelve_forward=None,
   last_hop_pool=None, mask=None, mirror=None,  nat64=None,  persist=None,
   profiles=None,    policies=None,    rate_class=None,   rate_limit=None,
   rate_limit_mode=None,     rate_limit_dst=None,     rate_limit_src=None,
   rules=None,      related_rules=None,      reject=None,     source=None,
   source_address_translation=None, source_port=None,  virtual_state=None,
   traffic_classes=None,    translate_address=None,   translate_port=None,
   vlans=None)
          Manage a virtual server.  If a virtual does not exists  it  will
          be  created,  otherwise  only  the  parameters specified will be
          enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to create

          destination
                 [ [virtual_address_name:port] | [ipv4:port] | [ipv6.port]
                 ]

          pool   [ [pool_name] | none]

          address_status
                 [yes | no]

          auto_lasthop
                 [default | enabled | disabled ]

          bwc_policy
                 [none] | string]

          cmp_enabled
                 [yes | no]

          dhcp_relay
                 [yes | no}

          connection_limit
                 [integer]

          description
                 [string]

          state  [disabled | enabled]

          fallback_persistence
                 [none | [profile name] ]

          flow_eviction_policy
                 [none | [eviction policy name] ]

          gtm_score
                 [integer]

          ip_forward
                 [yes | no]

          ip_protocol
                 [any | protocol]

          internal
                 [yes | no]

          twelve_forward(12-forward)
                 [yes | no]

          last_hop-pool
                 [ [pool_name] | none]

          mask   { [ipv4] | [ipv6] }

          mirror { [disabled | enabled | none] }

          nat64  [enabled | disabled]

          persist
                 [list]

          profiles
                 [none | default | list ]

          policies
                 [none | default | list ]

          rate_class
                 [name]

          rate_limit
                 [integer]

          rate_limit-mode
                 [destination    |    object    |   object-destination   |
                 object-source  |  object-source-destination  |  source  |
                 source-destination]

          rate_limit-dst
                 [integer]

          rate_limit-src
                 [integer]

          rules  [none | list ]

          related_rules
                 [none | list ]

          reject [yes | no]

          source { [ipv4[/prefixlen]] | [ipv6[/prefixlen]] }

          source_address_translation
                 [none | snat:pool_name | lsn | automap | dictionary ]

          source_port
                 [change | preserve | preserve-strict]

          state  [enabled | disabled]

          traffic_classes
                 [none | default | list ]

          translate_address
                 [enabled | disabled]

          translate_port
                 [enabled | disabled]

          vlans  [none | default | dictionary]

                 vlan_ids
                        [ list]

                 enabled
                        [ true | false ]

   salt.states.bigip.modify_monitor(hostname,      username,     password,
   monitor_type, name, **kwargs)
          Modify an  existing  monitor.   If  it  does  exists,  only  the
          parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          monitor_type
                 The type of monitor to create

          name   The name of the monitor to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

   salt.states.bigip.modify_node(hostname,   username,   password,   name,
   connection_limit=None,       description=None,      dynamic_ratio=None,
   logging=None, monitor=None, rate_limit=None, ratio=None,  session=None,
   node_state=None)
          Modify  an  existing node. Only a node which already exists will
          be modified and only the parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the node to modify

          connection_limit
                 [integer]

          description
                 [string]

          dynamic_ratio
                 [integer]

          logging
                 [enabled | disabled]

          monitor
                 [[name] | none | default]

          rate_limit
                 [integer]

          ratio  [integer]

          session
                 [user-enabled | user-disabled]

          node_state (state)
                 [user-down | user-up ]

   salt.states.bigip.modify_pool(hostname,   username,   password,   name,
   allow_nat=None,            allow_snat=None,           description=None,
   gateway_failsafe_device=None,             ignore_persisted_weight=None,
   ip_tos_to_client=None,  ip_tos_to_server=None, link_qos_to_client=None,
   link_qos_to_server=None,                      load_balancing_mode=None,
   min_active_members=None,                           min_up_members=None,
   min_up_members_action=None, min_up_members_checking=None, monitor=None,
   profiles=None,  queue_depth_limit=None, queue_on_connection_limit=None,
   queue_time_limit=None,  reselect_tries=None,  service_down_action=None,
   slow_ramp_time=None)
          Modify  an  existing  pool. Pool members are managed separately.
          Only the parameters specified are enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to create

          allow_nat
                 [yes | no]

          allow_snat
                 [yes | no]

          description
                 [string]

          gateway_failsafe_device
                 [string]

          ignore_persisted_weight
                 [enabled | disabled]

          ip_tos_to_client
                 [pass-through | [integer]]

          ip_tos_to_server
                 [pass-through | [integer]]

          link_qos_to_client
                 [pass-through | [integer]]

          link_qos_to_server
                 [pass-through | [integer]]

          load_balancing_mode
                 [dynamic-ratio-member     |     dynamic-ratio-node      |
                 fastest-app-response        |        fastest-node       |
                 least-connections-members  |   least-connections-node   |
                 least-sessions   |   observed-member  |  observed-node  |
                 predictive-member       |        predictive-node        |
                 ratio-least-connections-member                          |
                 ratio-least-connections-node | ratio-member |  ratio-node
                 |        ratio-session        |       round-robin       |
                 weighted-least-connections-member                       |
                 weighted-least-connections-node]

          min_active_members
                 [integer]

          min_up_members
                 [integer]

          min_up_members_action
                 [failover | reboot | restart-all]

          min_up_members_checking
                 [enabled | disabled]

          monitor
                 [name]

          profiles
                 [none | profile_name]

          queue_depth_limit
                 [integer]

          queue_on_connection_limit
                 [enabled | disabled]

          queue_time_limit
                 [integer]

          reselect_tries
                 [integer]

          service_down_action
                 [drop | none | reselect | reset]

          slow_ramp_time
                 [integer]

   salt.states.bigip.modify_pool_member(hostname,    username,   password,
   name,      member,       connection_limit=None,       description=None,
   dynamic_ratio=None,  inherit_profile=None,  logging=None, monitor=None,
   priority_group=None,   profiles=None,   rate_limit=None,    ratio=None,
   session=None, member_state=None)
          A  function  to connect to a bigip device and modify a member of
          an existing pool.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the pool to modify

          member The member modify

          connection_limit
                 [integer]

          description
                 [string]

          dynamic_ratio
                 [integer]

          inherit_profile
                 [enabled | disabled]

          logging
                 [enabled | disabled]

          monitor
                 [name]

          priority_group
                 [integer]

          profiles
                 [none | profile_name]

          rate_limit
                 [integer]

          ratio  [integer]

          session
                 [user-enabled | user-disabled]

          member_state (state)
                 [ user-up | user-down ]

   salt.states.bigip.modify_profile(hostname,     username,      password,
   profile_type, name, **kwargs)
          Modify  an  existing  profile.   If  it  does  exists,  only the
          parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          profile_type
                 The type of profile to create

          name   The name of the profile to create

          kwargs [ arg=val ] ...

                 Consult F5 BIGIP user guide for specific options for each
                 monitor type.  Typically, tmsh arg names are used.

   salt.states.bigip.modify_virtual(hostname,  username,  password,  name,
   destination,   pool=None,    address_status=None,    auto_lasthop=None,
   bwc_policy=None,        cmp_enabled=None,        connection_limit=None,
   dhcp_relay=None,      description=None,      fallback_persistence=None,
   flow_eviction_policy=None,       gtm_score=None,       ip_forward=None,
   ip_protocol=None,          internal=None,          twelve_forward=None,
   last_hop_pool=None,  mask=None,  mirror=None, nat64=None, persist=None,
   profiles=None,   policies=None,    rate_class=None,    rate_limit=None,
   rate_limit_mode=None,     rate_limit_dst=None,     rate_limit_src=None,
   rules=None,     related_rules=None,      reject=None,      source=None,
   source_address_translation=None,  source_port=None, virtual_state=None,
   traffic_classes=None,   translate_address=None,    translate_port=None,
   vlans=None)
          Modify  an  virtual  server.   modify an existing virtual.  Only
          parameters specified will be enforced.

          hostname
                 The host/address of the bigip device

          username
                 The iControl REST username

          password
                 The iControl REST password

          name   The name of the virtual to create

          destination
                 [ [virtual_address_name:port] | [ipv4:port] | [ipv6.port]
                 ]

          pool   [ [pool_name] | none]

          address_status
                 [yes | no]

          auto_lasthop
                 [default | enabled | disabled ]

          bwc_policy
                 [none] | string]

          cmp_enabled
                 [yes | no]

          dhcp_relay
                 [yes | no}

          connection_limit
                 [integer]

          description
                 [string]

          state  [disabled | enabled]

          fallback_persistence
                 [none | [profile name] ]

          flow_eviction_policy
                 [none | [eviction policy name] ]

          gtm_score
                 [integer]

          ip_forward
                 [yes | no]

          ip_protocol
                 [any | protocol]

          internal
                 [yes | no]

          twelve_forward(12-forward)
                 [yes | no]

          last_hop-pool
                 [ [pool_name] | none]

          mask   { [ipv4] | [ipv6] }

          mirror { [disabled | enabled | none] }

          nat64  [enabled | disabled]

          persist
                 [list]

          profiles
                 [none | default | list ]

          policies
                 [none | default | list ]

          rate_class
                 [name]

          rate_limit
                 [integer]

          rate_limit-mode
                 [destination    |    object    |   object-destination   |
                 object-source  |  object-source-destination  |  source  |
                 source-destination]

          rate_limit_dst
                 [integer]

          rate_limit_src
                 [integer]

          rules  [none | list ]

          related_rules
                 [none | list ]

          reject [yes | no]

          source { [ipv4[/prefixlen]] | [ipv6[/prefixlen]] }

          source_address_translation
                 [none | snat:pool_name | lsn | automap | dictionary ]

          source_port
                 [change | preserve | preserve-strict]

          state  [enabled | disabled]

          traffic_classes
                 [none | default | list ]

          translate_address
                 [enabled | disabled]

          translate_port
                 [enabled | disabled]

          vlans  [none | default | dictionary ]

                 vlan_ids
                        [ list]

                 enabled
                        [ true | false ]

   salt.states.blockdev
   Management of Block Devices

   A state module to manage blockdevices

      /dev/sda:
        blockdev.tuned:
          - read-only: True

      master-data:
        blockdev.tuned:
          - name: /dev/vg/master-data
          - read-only: True
          - read-ahead: 1024

   New in version 2014.7.0.

   salt.states.blockdev.formatted(name,    fs_type='ext4',    force=False,
   **kwargs)
          Manage filesystems of partitions.

          name   The name of the block device

          fs_type
                 The filesystem it should be formatted as

          force  Force  mke2fs  to  create  a  filesystem,  even  if   the
                 specified  device  is  not a partition on a block special
                 device. This option is  only  enabled  for  ext  and  xfs
                 filesystems

                 This option is dangerous, use it with caution.

                 New in version 2016.11.0.

   salt.states.blockdev.tuned(name, **kwargs)
          Manage options of block device

          name   The name of the block device

          opts:

                 *

                   read-ahead
                          Read-ahead buffer size

                 *

                   filesystem-read-ahead
                          Filesystem Read-ahead buffer size

                 *

                   read-only
                          Set Read-Only

                 *

                   read-write
                          Set Read-Write

   salt.states.boto_apigateway module
   Manage Apigateway Rest APIs
   New in version 2016.11.0.

   Create  and  destroy  rest  apis  depending  on  a  swagger  version  2
   definition file.  Be aware that this interacts with Amazon's  services,
   and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure Apigateway API exists:
          boto_apigateway.present:
              - name: myfunction
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_apigateway.absent(name,      api_name,     stage_name,
   nuke_api=False, region=None, key=None, keyid=None, profile=None)
          Ensure  the  stage_name  associated  with  the  given   api_name
          deployed  by boto_apigateway's present state is removed.  If the
          currently associated deployment to the given stage_name  has  no
          other  stages  associated  with  it, the deployment will also be
          removed.

          name   Name of the swagger file in YAML format

          api_name
                 Name of the rest api  on  AWS  ApiGateway  to  ensure  is
                 absent.

          stage_name
                 Name  of  the  stage  to  be  removed irrespective of the
                 swagger  file  content.   If   the   current   deployment
                 associated  with  the  stage_name  has  no  other  stages
                 associated with it, the deployment will also be removed.

          nuke_api
                 If True, removes the API itself  only  if  there  are  no
                 other  stages  associated with any other deployments once
                 the given stage_name is removed.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_apigateway.present(name,    api_name,    swagger_file,
   stage_name,         api_key_required,          lambda_integration_role,
   lambda_region=None,    stage_variables=None,   region=None,   key=None,
   keyid=None,                                               profile=None,
   lambda_funcname_format='{stage}_{api}_{resource}_{method}',
   authorization_type='NONE')
          Ensure the spcified api_name with the corresponding  swaggerfile
          is deployed to the given stage_name in AWS ApiGateway.

          this  state  currently only supports ApiGateway integration with
          AWS  Lambda,  and  CORS  support  is  handled  through  a   Mock
          integration.

          There  may  be  multiple  deployments  for  the API object, each
          deployment is tagged with a description (i.e. unique  label)  in
          pretty   printed   json   format  consisting  of  the  following
          key/values.

             {      "api_name":         api_name,          "swagger_file":
                    basename_of_swagger_file        "swagger_file_md5sum":
                    md5sum_of_swagger_file,         "swagger_info_object":
                    info_object_content_in_swagger_file

             }

          Please  note  that  the  name  of  the  lambda  function  to  be
          integrated    will    be    derived     via     the     provided
          lambda_funcname_format parameters:
             the  default  lambda_funcname_format  is  a  string  with the
             following                 substitutable                 keys:
             "{stage}_{api}_{resource}_{method}".   The user can choose to
             reorder the known keys.

             the stage key corresponds to the stage_name passed  in.   the
             api  key corresponds to the api_name passed in.  the resource
             corresponds to  the  resource  path  defined  in  the  passed
             swagger  file.   the  method  corresponds to the method for a
             resource path defined in the passed swagger file.

             for the default lambda_funcname_format, given  the  following
             input:
                 api_name  =  '   Test     Service'  stage_name  = 'alpha'
                 basePath = '/api' path = '/a/{b}/c' method = 'POST'

             we will end up with the following Lambda Function  Name  that
             will be looked up:
                    'test_service_alpha_a_b_c_post'

             The  canconicalization  of  these input parameters is done in
             the following order:

                    1. lambda_funcname_format is formatted with the  input
                       parameters as passed,

                    2. resulting  string  is stripped for leading/trailing
                       spaces,

                    3. path paramter's curly braces are removed  from  the
                       resource path,

                    4. consecutive spaces and forward slashes in the paths
                       are replaced with '_'

                    5. consecutive '_' are replaced with '_'

          Please note that for error response handling, the  swagger  file
          must  have  an  error  response model with the following schema.
          The  lambda  functions  should  throw  exceptions  for  any  non
          successful   responses.    An  optional  pattern  field  can  be
          specified in errorMessage field to aid the response mapping from
          Lambda to the proper error return status codes.

          name   The name of the state definition

          api_name
                 The name of the rest api that we want to ensure exists in
                 AWS API Gateway

          swagger_file
                 Name of the location of the swagger rest  api  definition
                 file in YAML format.

          stage_name
                 Name of the stage we want to be associated with the given
                 api_name and swagger_file definition

          api_key_required
                 True or False - whether the API Key is required  to  call
                 API methods

          lambda_integration_role
                 The  name  or ARN of the IAM role that the AWS ApiGateway
                 assumes when it executes your lambda function  to  handle
                 incoming requests

          lambda_region
                 The  region where we expect to find the lambda functions.
                 This is used to determine the region where we should look
                 for  the  Lambda  Function for integration purposes.  The
                 region determination is based on the following priority:

                 1. lambda_region as passed in (is not None)

                 2) if lambda_region is None,  use  the  region  as  if  a
                 boto_lambda  function  were  executed  without explicitly
                 specifying lambda region.  3) if region determined in (2)
                 is  different  than  the  region  used by boto_apigateway
                 functions, a final lookup will  be  attempted  using  the
                 boto_apigateway region.

          stage_variables
                 A  dict  with variables and their values, or a pillar key
                 (string) that contains a dict with  variables  and  their
                 values.   key  and  values  in  the dict must be strings.
                 {'string': 'string'}

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          lambda_funcname_format
                 Please  review  the  earlier  example for the usage.  The
                 only  substituable  keys  in  the  funcname  format   are
                 {stage},  {api}, {resource}, {method}.  Any other keys or
                 positional subsitution parameters will be flagged  as  an
                 invalid input.

          authorization_type
                 This field can be either 'NONE', or 'AWS_IAM'.  This will
                 be applied to all methods in the given swagger spec file.
                 Default is set to 'NONE'

   salt.states.boto_asg
   Manage Autoscale Groups
   New in version 2014.7.0.

   Create  and destroy autoscale groups. Be aware that this interacts with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit autoscale credentials but can also utilize
   IAM  roles  assigned to the instance through Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More Information available at:

      http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

   If  IAM  roles are not used you need to specify them either in a pillar
   or in the minion's config file:

      asg.keyid: GKTADJGHEIQSXMKKRBJ08H
      asg.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  as  a  passed  in  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      Ensure myasg exists:
        boto_asg.present:
          - name: myasg
          - launch_config_name: mylc
          - availability_zones:
            - us-east-1a
            - us-east-1b
          - min_size: 1
          - max_size: 1
          - desired_capacity: 1
          - load_balancers:
            - myelb
          - suspended_processes:
              - AddToLoadBalancer
              - AlarmNotification
          - scaling_policies
              - adjustment_type: ChangeInCapacity
              - as_name: api-production-iad
              - cooldown: 1800
              - min_adjustment_step: None
              - name: ScaleDown
              - scaling_adjustment: -1
          - region: us-east-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars.
      Ensure myasg exists:
        boto_asg.present:
          - name: myasg
          - launch_config_name: mylc
          - availability_zones:
            - us-east-1a
            - us-east-1b
          - min_size: 1
          - max_size: 1
          - desired_capacity: 1
          - load_balancers:
            - myelb
          - profile: myprofile

      # Passing in a profile.
      Ensure myasg exists:
        boto_asg.present:
          - name: myasg
          - launch_config_name: mylc
          - availability_zones:
            - us-east-1a
            - us-east-1b
          - min_size: 1
          - max_size: 1
          - desired_capacity: 1
          - load_balancers:
            - myelb
          - profile:
              keyid: GKTADJGHEIQSXMKKRBJ08H
              key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      # Deleting an autoscale group with running instances.
      Ensure myasg is deleted:
        boto_asg.absent:
          - name: myasg
          # If instances exist, we must force the deletion of the asg.
          - force: True

   It's possible to specify cloudwatch alarms that  will  be  setup  along
   with  the  ASG. Note the alarm name will be the name attribute defined,
   plus the ASG resource name.

      Ensure myasg exists:
        boto_asg.present:
          - name: myasg
          - launch_config_name: mylc
          - availability_zones:
            - us-east-1a
            - us-east-1b
          - min_size: 1
          - max_size: 1
          - desired_capacity: 1
          - load_balancers:
            - myelb
          - profile: myprofile
          - alarms:
              CPU:
                name: 'ASG CPU **MANAGED BY SALT**'
                attributes:
                  metric: CPUUtilization
                  namespace: AWS/EC2
                  statistic: Average
                  comparison: '>='
                  threshold: 65.0
                  period: 60
                  evaluation_periods: 30
                  unit: null
                  description: 'ASG CPU'
                  alarm_actions: [ 'arn:aws:sns:us-east-1:12345:myalarm' ]
                  insufficient_data_actions: []
                  ok_actions: [ 'arn:aws:sns:us-east-1:12345:myalarm' ]

   You can also use alarms from pillars,  and  override  values  from  the
   pillar   alarms  by  setting  overrides  on  the  resource.  Note  that
   'boto_asg_alarms' will be used as a default value for all resources, if
   defined  and  can  be  used  to ensure alarms are always set for an ASG
   resource.

   Setting the alarms in a pillar:

      my_asg_alarm:
        CPU:
          name: 'ASG CPU **MANAGED BY SALT**'
          attributes:
            metric: CPUUtilization
            namespace: AWS/EC2
            statistic: Average
            comparison: '>='
            threshold: 65.0
            period: 60
            evaluation_periods: 30
            unit: null
            description: 'ASG CPU'
            alarm_actions: [ 'arn:aws:sns:us-east-1:12345:myalarm' ]
            insufficient_data_actions: []
            ok_actions: [ 'arn:aws:sns:us-east-1:12345:myalarm' ]

   Overriding the alarm values on the resource:

      Ensure myasg exists:
        boto_asg.present:
          - name: myasg
          - launch_config_name: mylc
          - availability_zones:
            - us-east-1a
            - us-east-1b
          - min_size: 1
          - max_size: 1
          - desired_capacity: 1
          - load_balancers:
            - myelb
          - profile: myprofile
          - alarms_from_pillar: my_asg_alarm
          # override CPU:attributes:threshold
          - alarms:
              CPU:
                attributes:
                  threshold: 50.0

   salt.states.boto_asg.absent(name, force=False,  region=None,  key=None,
   keyid=None, profile=None, remove_lc=False)
          Ensure the named autoscale group is deleted.

          name   Name of the autoscale group.

          force  Force deletion of autoscale group.

          remove_lc
                 Delete the launch config as well.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_asg.present(name,                  launch_config_name,
   availability_zones,     min_size,     max_size,     launch_config=None,
   desired_capacity=None,   load_balancers=None,    default_cooldown=None,
   health_check_type=None, health_check_period=None, placement_group=None,
   vpc_zone_identifier=None,         subnet_names=None,         tags=None,
   termination_policies=None,
   termination_policies_from_pillar='boto_asg_termination_policies',
   suspended_processes=None,                        scaling_policies=None,
   scaling_policies_from_pillar='boto_asg_scaling_policies',
   scheduled_actions=None,
   scheduled_actions_from_pillar='boto_asg_scheduled_actions',
   alarms=None,     alarms_from_pillar='boto_asg_alarms',     region=None,
   key=None,     keyid=None,     profile=None,      notification_arn=None,
   notification_arn_from_pillar='boto_asg_notification_arn',
   notification_types=None,
   notification_types_from_pillar='boto_asg_notification_types')
          Ensure the autoscale group exists.

          name   Name of the autoscale group.

          launch_config_name
                 Name  of  the launch config to use for the group.  Or, if
                 launch_config is  specified,  this  will  be  the  launch
                 config name's prefix.  (see below)

          launch_config
                 A  dictionary of launch config attributes.  If specified,
                 a launch config will be used or  created,  matching  this
                 set of attributes, and the autoscale group will be set to
                 use that launch config.  The launch config name  will  be
                 the launch_config_name followed by a hyphen followed by a
                 hash of the launch_config dict contents.  Example:

                    my_asg:
                      boto_asg.present:
                      - launch_config:
                        - ebs_optimized: false
                        - instance_profile_name: my_iam_profile
                        - kernel_id: ''
                        - ramdisk_id: ''
                        - key_name: my_ssh_key
                        - image_name: aws2015091-hvm
                        - instance_type: c3.xlarge
                        - instance_monitoring: false
                        - security_groups:
                          - my_sec_group_01
                          - my_sec_group_02

          availability_zones
                 List of availability zones for the group.

          min_size
                 Minimum size of the group.

          max_size
                 Maximum size of the group.

          desired_capacity
                 The desired capacity of the group.

          load_balancers
                 List of load balancers for the group. Once set  this  can
                 not be updated (Amazon restriction).

          default_cooldown
                 Number  of  seconds  after  a  Scaling Activity completes
                 before any further scaling activities can start.

          health_check_type
                 The service you want the health status from,  Amazon  EC2
                 or Elastic Load Balancer (EC2 or ELB).

          health_check_period
                 Length  of time in seconds after a new EC2 instance comes
                 into  service  that  Auto  Scaling  starts  checking  its
                 health.

          placement_group
                 Physical location of your cluster placement group created
                 in Amazon EC2. Once set this can not be  updated  (Amazon
                 restriction).

          vpc_zone_identifier
                 A  list  of the subnet identifiers of the Virtual Private
                 Cloud.

          subnet_names
                 For VPC, a list of  subnet  names  (NOT  subnet  IDs)  to
                 deploy into.  Exclusive with vpc_zone_identifier.

          tags   A list of tags. Example:

                    - key: 'key'
                      value: 'value'
                      propagate_at_launch: true

          termination_policies
                 A list of termination policies. Valid values are:

                 * OldestInstance

                 * NewestInstance

                 * OldestLaunchConfiguration

                 * ClosestToNextInstanceHour

                 * Default

                 If no value is specified, the Default value is used.

          termination_policies_from_pillar:
                 name  of  pillar  dict  that  contains termination policy
                 settings.    Termination  policies   defined   for   this
                 specific state will override those from pillar.

          suspended_processes
                 List     of    processes    to    be    suspended.    see
                 http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html

          scaling_policies
                 List  of  scaling  policies.   Each  policy  is a dict of
                 key-values                  described                  by
                 https://boto.readthedocs.io/en/latest/ref/autoscale.html#boto.ec2.autoscale.policy.ScalingPolicy

          scaling_policies_from_pillar:
                 name  of  pillar  dict  that  contains   scaling   policy
                 settings.    Scaling  policies  defined for this specific
                 state will override those from pillar.

          scheduled_actions:
                 a dictionary of scheduled actions. Each key is  the  name
                 of  scheduled  action  and  each  value  is dictionary of
                 options. For example:

                    - scheduled_actions:
                        scale_up_at_10:
                            desired_capacity: 4
                            min_size: 3
                            max_size: 5
                            recurrence: "0 9 * * 1-5"
                        scale_down_at_7:
                            desired_capacity: 1
                            min_size: 1
                            max_size: 1
                            recurrence: "0 19 * * 1-5"

          scheduled_actions_from_pillar:
                 name  of  pillar  dict  that  contains  scheduled_actions
                 settings.  Scheduled actions for this specific state will
                 override those from pillar.

          alarms:
                 a dictionary of name->boto_cloudwatch_alarm  sections  to
                 be  associated  with  this ASG.  All attributes should be
                 specified   except   for   dimension   which   will    be
                 automatically set to this ASG.

                 See   the   salt.states.boto_cloudwatch_alarm  state  for
                 information about these attributes.

                 If any alarm  actions  include   ":self:"  this  will  be
                 replaced  with  the asg name.  For example, alarm_actions
                 reading "['scaling_policy:self:ScaleUp']" will map to the
                 arn  for  this  asg's scaling policy named "ScaleUp".  In
                 addition, any alarms that  have  only  scaling_policy  as
                 actions  will be ignored if min_size is equal to max_size
                 for this ASG.

          alarms_from_pillar:
                 name  of  pillar  dict  that  contains  alarm   settings.
                 Alarms  defined  for  this  specific  state will override
                 those from pillar.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          notification_arn
                 The AWS arn that notifications will be sent to

          notification_arn_from_pillar
                 name  of  the  pillar  dict that contains notifcation_arn
                 settings.  A notification_arn defined for  this  specific
                 state will override the one from pillar.

          notification_types
                 A  list  of event names that will trigger a notification.
                 The list of valid notification types is:

                 * autoscaling:EC2_INSTANCE_LAUNCH

                 * autoscaling:EC2_INSTANCE_LAUNCH_ERROR

                 * autoscaling:EC2_INSTANCE_TERMINATE

                 * autoscaling:EC2_INSTANCE_TERMINATE_ERROR

                 * autoscaling:TEST_NOTIFICATION

          notification_types_from_pillar
                 name of the pillar dict that  contains  notifcation_types
                 settings.   notification_types  defined for this specific
                 state will override those from the pillar.

   salt.states.boto_cfn
   Connection module for Amazon Cloud Formation

   New in version 2015.8.0.

   depends
          boto

   configuration
          This module  accepts  explicit  AWS  credentials  but  can  also
          utilize  IAM  roles  assigned  to  the instance through Instance
          Profiles. Dynamic credentials are  then  automatically  obtained
          from  AWS  API  and  no further configuration is necessary. More
          Information                     available                     at
          http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

          If IAM roles are not used you need to specify them either  in  a
          pillar or in the minion's config file:

             keyid: GKTADJGHEIQSXMKKRBJ08H
             key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

             stack-present:
               boto_cfn.present:
                 - name: mystack
                 - template_body: salt://base/mytemplate.json
                 - disable_rollback: true
                 - region: eu-west-1
                 - keyid: 'AKIAJHTMIQ2ASDFLASDF'
                 - key: 'fdkjsafkljsASSADFalkfjasdf'

             stack-absent:
               boto_cfn.absent:
                 - name: mystack

   salt.states.boto_cfn.absent(name,  region=None,  key=None,  keyid=None,
   profile=None)
          Ensure cloud formation stack is absent.

          name (string) -- The name of the stack to delete.

          region (string) - Region to connect to.

          key (string) - Secret key to be used.

          keyid (string) - Access key to be used.

          profile (dict) - A dict with region, key and keyid, or a  pillar
          key (string) that contains a dict with region, key and keyid.

   salt.states.boto_cfn.present(name,                  template_body=None,
   template_url=None,       parameters=None,       notification_arns=None,
   disable_rollback=None,    timeout_in_minutes=None,   capabilities=None,
   tags=None,           on_failure=None,           stack_policy_body=None,
   stack_policy_url=None,                      use_previous_template=None,
   stack_policy_during_update_body=None,
   stack_policy_during_update_url=None, region=None, key=None, keyid=None,
   profile=None)
          Ensure cloud formation stack is present.

          name (string) - Name of the stack.

          template_body (string) -- Structure containing the template body.
          Can also be loaded from a file by using salt://.

          template_url (string) -- Location of file containing the template
          body. The URL must point to a template located in an  S3  bucket
          in the same region as the stack.

          parameters  (list)  --  A  list  of key/value tuples that specify
          input parameters for the stack. A 3-tuple (key, value, bool) may
          be used to specify the UsePreviousValue option.

          notification_arns (list) -- The Simple Notification Service (SNS)
          topic ARNs to publish stack related events.  You can  find  your
          SNS  topic  ARNs  using  the  SNS_console  or  your Command Line
          Interface (CLI).

          disable_rollback (bool) -- Indicates whether or not  to  rollback
          on failure.

          timeout_in_minutes  (integer) -- The amount of time that can pass
          before   the   stack   status    becomes    CREATE_FAILED;    if
          DisableRollback is not set or is set to False, the stack will be
          rolled back.

          capabilities (list) -- The list of capabilities you want to allow
          in   the   stack.   Currently,  the  only  valid  capability  is
          'CAPABILITY_IAM'.

          tags (dict) -- A set of user-defined Tags to associate with  this
          stack,  represented  by  key/value  pairs.  Tags defined for the
          stack are propagated to EC2 resources that are created  as  part
          of the stack. A maximum number of 10 tags can be specified.

          on_failure  (string)  --  Determines what action will be taken if
          stack creation fails. This must be one of: DO_NOTHING, ROLLBACK,
          or  DELETE. You can specify either OnFailure or DisableRollback,
          but not both.

          stack_policy_body (string)  --  Structure  containing  the  stack
          policy body. Can also be loaded from a file by using salt://.

          stack_policy_url  (string)  --  Location of a file containing the
          stack policy. The URL must point to a policy  (max  size:  16KB)
          located  in  an S3 bucket in the same region as the stack.If you
          pass StackPolicyBody and StackPolicyURL, only StackPolicyBody is
          used.

          use_previous_template  (boolean)  -- Used only when templates are
          not the same. Set to True to use the previous  template  instead
          of uploading a new one via TemplateBody or TemplateURL.

          stack_policy_during_update_body   (string)   --  Used  only  when
          templates are not the same. Structure containing  the  temporary
          overriding     stack     policy     body.     If     you    pass
          StackPolicyDuringUpdateBody and StackPolicyDuringUpdateURL, only
          StackPolicyDuringUpdateBody  is  used. Can also be loaded from a
          file by using salt://.

          stack_policy_during_update_url  (string)  --   Used   only   when
          templates  are  not  the same. Location of a file containing the
          temporary overriding stack policy.  The  URL  must  point  to  a
          policy  (max  size:  16KB)  located  in an S3 bucket in the same
          region as the stack. If you pass StackPolicyDuringUpdateBody and
          StackPolicyDuringUpdateURL,  only StackPolicyDuringUpdateBody is
          used.

          region (string) - Region to connect to.

          key (string) - Secret key to be used.

          keyid (string) - Access key to be used.

          profile (dict) - A dict with region, key and keyid, or a  pillar
          key (string) that contains a dict with region, key and keyid.

   salt.states.boto_cloudtrail module
   Manage CloudTrail Objects
   New in version 2016.3.0.

   Create  and  destroy  CloudTrail  objects. Be aware that this interacts
   with Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This module accepts explicit vpc credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure trail exists:
          boto_cloudtrail.present:
              - Name: mytrail
              - S3BucketName: mybucket
              - S3KeyPrefix: prefix
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_cloudtrail.absent(name, Name,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure trail with passed properties is absent.

          name   The name of the state definition.

          Name   Name of the trail.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_cloudtrail.present(name,      Name,      S3BucketName,
   S3KeyPrefix=None,  SnsTopicName=None,  IncludeGlobalServiceEvents=True,
   IsMultiRegionTrail=None,                 EnableLogFileValidation=False,
   CloudWatchLogsLogGroupArn=None,             CloudWatchLogsRoleArn=None,
   KmsKeyId=None, LoggingEnabled=True, Tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure trail exists.

          name   The name of the state definition

          Name   Name of the trail.

          S3BucketName
                 Specifies the name of the Amazon S3 bucket designated for
                 publishing log files.

          S3KeyPrefix
                 Specifies the Amazon S3 key prefix that comes  after  the
                 name  of  the  bucket  you  have  designated for log file
                 delivery.

          SnsTopicName
                 Specifies the name of the Amazon SNS  topic  defined  for
                 notification  of log file delivery. The maximum length is
                 256 characters.

          IncludeGlobalServiceEvents
                 Specifies whether the trail  is  publishing  events  from
                 global services such as IAM to the log files.

          EnableLogFileValidation
                 Specifies   whether  log  file  integrity  validation  is
                 enabled. The default is false.

          CloudWatchLogsLogGroupArn
                 Specifies a log group name using an Amazon Resource  Name
                 (ARN),  a unique identifier that represents the log group
                 to which CloudTrail logs will be delivered. Not  required
                 unless you specify CloudWatchLogsRoleArn.

          CloudWatchLogsRoleArn
                 Specifies  the  role  for the CloudWatch Logs endpoint to
                 assume to write to a user's log group.

          KmsKeyId
                 Specifies the KMS key ID  to  use  to  encrypt  the  logs
                 delivered by CloudTrail. The value can be a an alias name
                 prefixed by "alias/", a fully specified ARN to an  alias,
                 a  fully  specified  ARN  to  a key, or a globally unique
                 identifier.

          LoggingEnabled
                 Whether logging should be enabled for the trail

          Tags   A dictionary of tags that should be set on the trail

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_cloudwatch_alarm
   Manage Cloudwatch alarms

   New in version 2014.7.0.

   Create and destroy cloudwatch alarms. Be aware that this interacts with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit credentials but can also utilize IAM roles
   assigned to the instance through Instance Profiles. Dynamic credentials
   are  then  automatically  obtained  from  AWS  API   and   no   further
   configuration is necessary. More Information available at:

   http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

   If IAM roles are not used you need to specify them either in  a  pillar
   or in the minion's config file:

      cloudwatch.keyid: GKTADJGHEIQSXMKKRBJ08H
      cloudwatch.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either as a passed in dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
        keyid: GKTADJGHEIQSXMKKRBJ08H
        key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
        region: us-east-1

      my test alarm:
        boto_cloudwatch_alarm.present:
          - name: my test alarm
          - attributes:
              metric: ApproximateNumberOfMessagesVisible
              namespace: AWS/SQS
              statistic: Average
              comparison: ">="
              threshold: 20000.0
              period: 60
              evaluation_periods: 1
              description: test alarm via salt
              dimensions:
                QueueName:
                  - the-sqs-queue-name
              alarm_actions:
                - arn:aws:sns:us-east-1:1111111:myalerting-action

   salt.states.boto_cloudwatch_alarm.absent(name,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure the named cloudwatch alarm is deleted.

          name   Name of the alarm.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_cloudwatch_alarm.present(name,             attributes,
   region=None, key=None, keyid=None, profile=None)
          Ensure the cloudwatch alarm exists.

          name   Name of the alarm

          attributes
                 A dict of key/value cloudwatch alarm attributes.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_cognitoidentity module
   Manage CognitoIdentity Functions
   New in version 2016.11.0.

   Create  and  destroy CognitoIdentity identity pools. Be aware that this
   interacts with Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This module accepts explicit vpc credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure function exists:
          boto_cognitoidentity.pool_present:
              - PoolName: my_identity_pool
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_cognitoidentity.pool_absent(name,    IdentityPoolName,
   RemoveAllMatched=False,      region=None,     key=None,     keyid=None,
   profile=None)
          Ensure cognito identity pool with passed properties is absent.

          name   The name of the state definition.

          IdentityPoolName
                 Name of the Cognito Identity Pool.  Please note that this
                 may  match  multiple  pools  with the same given name, in
                 which case, all will be removed.

          RemoveAllMatched
                 If  True,  all   identity   pools   with   the   matching
                 IdentityPoolName will be removed.  If False and there are
                 more  than  one   identity   pool   with   the   matching
                 IdentityPoolName,  no action will be taken.  If False and
                 there  is  only  one  identity  pool  with  the  matching
                 IdentityPoolName, the identity pool will be removed.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_cognitoidentity.pool_present(name,   IdentityPoolName,
   AuthenticatedRole,                AllowUnauthenticatedIdentities=False,
   UnauthenticatedRole=None,                 SupportedLoginProviders=None,
   DeveloperProviderName=None,             OpenIdConnectProviderARNs=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure Cognito Identity Pool exists.

          name   The name of the state definition

          IdentityPoolName
                 Name of the Cognito Identity Pool

          AuthenticatedRole
                 An IAM role name or ARN  that  will  be  associated  with
                 temporary  AWS  credentials  for an authenticated cognito
                 identity.

          AllowUnauthenticatedIdentities
                 Whether to allow anonymous user identities

          UnauthenticatedRole
                 An IAM role name or ARN  that  will  be  associated  with
                 anonymous user identities

          SupportedLoginProviders
                 A  dictionary  or  pillar  that  contains key:value pairs
                 mapping provider names to provider app IDs.

          DeveloperProviderName
                 A string which is the domain by which Cognito will  refer
                 to  your  users.   This  name  acts as a placeholder that
                 allows  your  backend  and   the   Cognito   service   to
                 communicate  about the developer provider.  Once you have
                 set a developer provider  name,  you  cannot  change  it.
                 Please take care in setting this parameter.

          OpenIdConnectProviderARNs
                 A  list  or  pillar  name  that contains a list of OpenID
                 Connect provider ARNs.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_datapipeline module
   Manage Data Pipelines

   New in version 2016.3.0.

   Be  aware  that this interacts with Amazon's services, and so may incur
   charges.

   This module uses boto3, which can be installed via package, or pip.

   This module accepts explicit AWS credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      datapipeline.keyid: GKTADJGHEIQSXMKKRBJ08H
      datapipeline.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
        keyid: GKTADJGHEIQSXMKKRBJ08H
        key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
        region: us-east-1

      Ensure daily data pipeline exists:
        boto_datapipeline.present:
          - name: my-datapipeline
          - pipeline_objects:
              DefaultSchedule:
                name: Every 1 day
                fields:
                  period: 1 Day
                  type: Schedule
                  startAt: FIRST_ACTIVATION_DATE_TIME
          - parameter_values:
              myDDBTableName: my-dynamo-table

   salt.states.boto_datapipeline.absent(name,    region=None,    key=None,
   keyid=None, profile=None)
          Ensure a pipeline with the service_name does not exist

          name   Name  of  the  service to ensure a data pipeline does not
                 exist for.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_datapipeline.present(name,      pipeline_objects=None,
   pipeline_objects_from_pillars='boto_datapipeline_pipeline_objects',
   parameter_objects=None,
   parameter_objects_from_pillars='boto_datapipeline_parameter_objects',
   parameter_values=None,
   parameter_values_from_pillars='boto_datapipeline_parameter_values',
   region=None, key=None, keyid=None, profile=None)
          Ensure the data pipeline exists with matching definition.

          name   Name of the service to ensure a data pipeline exists for.

          pipeline_objects
                 Pipeline  objects to use. Will override objects read from
                 pillars.

          pipeline_objects_from_pillars
                 The pillar key to use for lookup.

          parameter_objects
                 Parameter objects to use. Will override objects read from
                 pillars.

          parameter_objects_from_pillars
                 The pillar key to use for lookup.

          parameter_values
                 Parameter  values  to use. Will override values read from
                 pillars.

          parameter_values_from_pillars
                 The pillar key to use for lookup.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_dynamodb
   Manage DynamoDB Tables
   New in version 2015.5.0.

   Create  and  destroy DynamoDB tables. Be aware that this interacts with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit DynamoDB credentials but can also  utilize
   IAM  roles  assigned to the instance through Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      keyid: GKTADJGHEIQSXMKKRBJ08H
      key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
      region: us-east-1

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure DynamoDB table does not exist:
        boto_dynamodb.absent:
          - table_name: new_table
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          - region: us-east-1

      Ensure DynamoDB table exists:
        boto_dynamodb.present:
          - table_name: new_table
          - read_capacity_units: 1
          - write_capacity_units: 2
          - hash_key: primary_id
          - hash_key_data_type: N
          - range_key: start_timestamp
          - range_key_data_type: N
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          - region: us-east-1
          - local_indexes:
              - index:
                  - name: "primary_id_end_timestamp_index"
                  - hash_key: primary_id
                  - hash_key_data_type: N
                  - range_key: end_timestamp
                  - range_key_data_type: N
          - global_indexes:
              - index:
                  - name: "name_end_timestamp_index"
                  - hash_key: name
                  - hash_key_data_type: S
                  - range_key: end_timestamp
                  - range_key_data_type: N
                  - read_capacity_units: 3
                  - write_capacity_units: 4

   It's possible to specify cloudwatch alarms that  will  be  setup  along
   with  the  DynamoDB  table.  Note the alarm name will be defined by the
   name attribute provided, plus the DynamoDB resource name.

      Ensure DynamoDB table exists:
        boto_dynamodb.present:
          - name: new_table
          - read_capacity_units: 1
          - write_capacity_units: 2
          - hash_key: primary_id
          - hash_key_data_type: N
          - range_key: start_timestamp
          - range_key_data_type: N
          - alarms:
               ConsumedWriteCapacityUnits:
                  name: 'DynamoDB ConsumedWriteCapacityUnits **MANAGED BY SALT**'
                  attributes:
                    metric: ConsumedWriteCapacityUnits
                    namespace: AWS/DynamoDB
                    statistic: Sum
                    comparison: '>='
                    # threshold_percent is used to calculate the actual threshold
                    # based on the provisioned capacity for the table.
                    threshold_percent: 0.75
                    period: 300
                    evaluation_periods: 2
                    unit: Count
                    description: 'DynamoDB ConsumedWriteCapacityUnits'
                    alarm_actions: [ 'arn:aws:sns:us-east-1:1234:my-alarm' ]
                    insufficient_data_actions: []
                    ok_actions: [ 'arn:aws:sns:us-east-1:1234:my-alarm' ]
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          - region: us-east-1

   You can also use alarms from pillars,  and  override  values  from  the
   pillar   alarms  by  setting  overrides  on  the  resource.  Note  that
   'boto_dynamodb_alarms'  will  be  used  as  a  default  value  for  all
   resources,  if  defined and can be used to ensure alarms are always set
   for a resource.

   Setting the alarms in a pillar:

      boto_dynamodb_alarms:
        ConsumedWriteCapacityUnits:
          name: 'DynamoDB ConsumedWriteCapacityUnits **MANAGED BY SALT**'
          attributes:
            metric: ConsumedWriteCapacityUnits
            namespace: AWS/DynamoDB
            statistic: Sum
            comparison: '>='
            # threshold_percent is used to calculate the actual threshold
            # based on the provisioned capacity for the table.
            threshold_percent: 0.75
            period: 300
            evaluation_periods: 2
            unit: Count
            description: 'DynamoDB ConsumedWriteCapacityUnits'
            alarm_actions: [ 'arn:aws:sns:us-east-1:1234:my-alarm' ]
            insufficient_data_actions: []
            ok_actions: [ 'arn:aws:sns:us-east-1:1234:my-alarm' ]

      Ensure DynamoDB table exists:
        boto_dynamodb.present:
          - name: new_table
          - read_capacity_units: 1
          - write_capacity_units: 2
          - hash_key: primary_id
          - hash_key_data_type: N
          - range_key: start_timestamp
          - range_key_data_type: N
          - alarms:
               ConsumedWriteCapacityUnits:
                  attributes:
                    threshold_percent: 0.90
                    period: 900

   salt.states.boto_dynamodb.absent(name,      region=None,      key=None,
   keyid=None, profile=None)
          Ensure the DynamoDB table does not exist.

          name   Name of the DynamoDB table.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_dynamodb.present(name=None,           table_name=None,
   region=None,         key=None,         keyid=None,        profile=None,
   read_capacity_units=None,    write_capacity_units=None,    alarms=None,
   alarms_from_pillar='boto_dynamodb_alarms',               hash_key=None,
   hash_key_data_type=None,   range_key=None,    range_key_data_type=None,
   local_indexes=None,                                global_indexes=None,
   backup_configs_from_pillars='boto_dynamodb_backup_configs')
          Ensure the DynamoDB table exists.  Note: all properties  of  the
          table can only be set during table creation.  Adding or changing
          indexes or key schema cannot be done after table creation

          name   Name of the DynamoDB table

          table_name
                 Name of the DynamoDB table (deprecated)

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          read_capacity_units
                 The read throughput for this table

          write_capacity_units
                 The write throughput for this table

          hash_key
                 The  name  of the attribute that will be used as the hash
                 key for this table

          hash_key_data_type
                 The DynamoDB datatype of the hash key

          range_key
                 The name of the attribute that will be used as the  range
                 key for this table

          range_key_data_type
                 The DynamoDB datatype of the range key

          local_indexes
                 The local indexes you would like to create

          global_indexes
                 The local indexes you would like to create

          backup_configs_from_pillars
                 Pillars to use to configure DataPipeline backups

   salt.states.boto_ec2
   Manage EC2

   New in version 2015.8.0.

   This  module  provides  an interface to the Elastic Compute Cloud (EC2)
   service from AWS.

   The below code creates a key pair:

      create-key-pair:
        boto_ec2.key_present:
          - name: mykeypair
          - save_private: /root/
          - region: eu-west-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      import-key-pair:
         boto_ec2.key_present:
          - name: mykeypair
          - upload_public: 'ssh-rsa AAAA'
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   You can also use salt:// in order to define the public key.

      import-key-pair:
         boto_ec2.key_present:
          - name: mykeypair
          - upload_public: salt://mybase/public_key.pub
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   The below code deletes a key pair:

      delete-key-pair:
        boto_ec2.key_absent:
          - name: mykeypair
          - region: eu-west-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_ec2.eni_absent(name,  release_eip=False,  region=None,
   key=None, keyid=None, profile=None)
          Ensure the EC2 ENI is absent.

          New in version 2016.3.0.

          name   Name tag associated with the ENI.

          release_eip
                 True/False - release any EIP associated with the ENI

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_ec2.eni_present(name,                  subnet_id=None,
   subnet_name=None,       private_ip_address=None,      description=None,
   groups=None, source_dest_check=True, allocate_eip=None,  arecords=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure the EC2 ENI exists.

          New in version 2016.3.0.

          name   Name tag associated with the ENI.

          subnet_id
                 The VPC subnet ID the ENI will exist within.

          subnet_name
                 The VPC subnet name the ENI will exist within.

          private_ip_address
                 The  private  ip  address to use for this ENI. If this is
                 not specified AWS will automatically assign a private  IP
                 address  to  the ENI. Must be specified at creation time;
                 will be ignored afterward.

          description
                 Description of the key.

          groups A list of security groups to apply to the ENI.

          source_dest_check
                 Boolean specifying whether source/destination checking is
                 enabled on the ENI.

          allocate_eip
                 allocate  and  associate  an  EIP  to  the  ENI. Could be
                 'standard' to allocate Elastic IP to EC2 region or  'vpc'
                 to get it for a particular VPC

                 Changed in version 2016.11.0.

          arecords
                 A  list  of  arecord dicts with attributes needed for the
                 DNS     add_record     state.      By     default     the
                 boto_route53.add_record   state   will   be  used,  which
                 requires: name,  zone,  ttl,  and  identifier.   See  the
                 boto_route53    state   for   information   about   these
                 attributes.   Other  DNS  modules  can   be   called   by
                 specifying the provider keyword.  By default, the private
                 ENI IP address will be used, set 'public:  True'  in  the
                 arecord dict to use the ENI's public IP address

                 New in version 2016.3.0.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_ec2.instance_absent(name,          instance_name=None,
   instance_id=None, release_eip=False, region=None, key=None, keyid=None,
   profile=None, filters=None)
          Ensure an EC2 instance does not exist (is stopped and removed).

          name   (string) - The name of the state definition.

          instance_name
                 (string) - The name of the instance.

          instance_id
                 (string) - The ID of the instance.

          release_eip
                 (bool)     -   Release   any   associated   EIPs   during
                 termination.

          region (string) - Region to connect to.

          key    (string) - Secret key to be used.

          keyid  (string) - Access key to be used.

          profile
                 (variable)  -  A  dict  with  region, key and keyid, or a
                 pillar key (string) that contains a dict with region, key
                 and keyid.

          filters
                 (dict)  - A dict of additional filters to use in matching
                 the instance to delete.

          YAML example fragment:

   salt.states.boto_ec2.instance_present(name,         instance_name=None,
   instance_id=None,     image_id=None,     image_name=None,    tags=None,
   key_name=None,          security_groups=None,           user_data=None,
   instance_type=None,  placement=None,  kernel_id=None,  ramdisk_id=None,
   vpc_id=None,  vpc_name=None,  monitoring_enabled=None,  subnet_id=None,
   subnet_name=None,    private_ip_address=None,    block_device_map=None,
   disable_api_termination=None,
   instance_initiated_shutdown_behavior=None,        placement_group=None,
   client_token=None, security_group_ids=None,  security_group_names=None,
   additional_info=None,      tenancy=None,     instance_profile_arn=None,
   instance_profile_name=None,                         ebs_optimized=None,
   network_interfaces=None,                   network_interface_name=None,
   network_interface_id=None,     attributes=None,      target_state=None,
   public_ip=None,  allocation_id=None,  allocate_eip=False,  region=None,
   key=None, keyid=None, profile=None)
          Ensure an EC2 instance is running with the given attributes  and
          state.

          name   (string) - The name of the state definition.  Recommended
                 that this match the  instance_name  attribute  (generally
                 the FQDN of the instance).

          instance_name
                 (string)  - The name of the instance, generally its FQDN.
                 Exclusive with 'instance_id'.

          instance_id
                 (string) - The ID of the instance (if known).   Exclusive
                 with 'instance_name'.

          image_id
                 (string) -- The ID of the AMI image to run.

          image_name
                 (string) -- The name of the AMI image to run.

          tags   (dict) - Tags to apply to the instance.

          key_name
                 (string)  -- The name of the key pair with which to launch
                 instances.

          security_groups
                 (list of strings) -- The names of the EC2 classic security
                 groups with which to associate instances

          user_data
                 (string)  --  The Base64-encoded MIME user data to be made
                 available to the instance(s) in this reservation.

          instance_type
                 (string) -- The EC2 instance size/type.   Note  that  only
                 certain types are compatible with HVM based AMIs.

          placement
                 (string)  --  The Availability Zone to launch the instance
                 into.

          kernel_id
                 (string) -- The ID of the kernel with which to launch  the
                 instances.

          ramdisk_id
                 (string)  --  The  ID of the RAM disk with which to launch
                 the instances.

          vpc_id (string) - The ID of a VPC to attach the instance to.

          vpc_name
                 (string) - The name of a VPC to attach the instance to.

          monitoring_enabled
                 (bool) -- Enable detailed  CloudWatch  monitoring  on  the
                 instance.

          subnet_id
                 (string)  --  The  ID of the subnet within which to launch
                 the instances for VPC.

          subnet_name
                 (string) -- The name of the subnet within which to  launch
                 the instances for VPC.

          private_ip_address
                 (string)  --  If  you're using VPC, you can optionally use
                 this  parameter  to  assign  the  instance   a   specific
                 available IP address from the subnet (e.g., 10.0.0.25).

          block_device_map
                 (boto.ec2.blockdevicemapping.BlockDeviceMapping)    --   A
                 BlockDeviceMapping  data  structure  describing  the  EBS
                 volumes associated with the Image.

          disable_api_termination
                 (bool)  --  If True, the instances will be locked and will
                 not be able to be terminated via the API.

          instance_initiated_shutdown_behavior
                 (string)  --  Specifies  whether  the  instance  stops  or
                 terminates  on  instance-initiated shutdown. Valid values
                 are:

                    * 'stop'

                    * 'terminate'

          placement_group
                 (string)  --  If  specified,  this  is  the  name  of  the
                 placement   group   in  which  the  instance(s)  will  be
                 launched.

          client_token
                 (string) -- Unique, case-sensitive identifier you  provide
                 to  ensure  idempotency  of the request. Maximum 64 ASCII
                 characters.

          security_group_ids
                 (list of strings) -- The IDs of the  VPC  security  groups
                 with which to associate instances.

          security_group_names
                 (list  of strings) -- The names of the VPC security groups
                 with which to associate instances.

          additional_info
                 (string)  --  Specifies  additional  information  to  make
                 available to the instance(s).

          tenancy
                 (string)  --  The  tenancy  of  the  instance  you want to
                 launch. An instance with a tenancy of 'dedicated' runs on
                 single-tenant  hardware  and  can only be launched into a
                 VPC. Valid values are:"default" or "dedicated".  NOTE: To
                 use dedicated tenancy you MUST specify a VPC subnet-ID as
                 well.

          instance_profile_arn
                 (string) -- The Amazon resource  name  (ARN)  of  the  IAM
                 Instance Profile (IIP) to associate with the instances.

          instance_profile_name
                 (string)  -- The name of the IAM Instance Profile (IIP) to
                 associate with the instances.

          ebs_optimized
                 (bool) -- Whether the instance is optimized for  EBS  I/O.
                 This optimization provides dedicated throughput to Amazon
                 EBS and a tuned configuration stack  to  provide  optimal
                 EBS  I/O  performance.  This optimization isn't available
                 with all instance types.

          network_interfaces
                 (boto.ec2.networkinterface.NetworkInterfaceCollection)  --
                 A  NetworkInterfaceCollection  data  structure containing
                 the ENI specifications for the instance.

          network_interface_name
                    (string) - The name of Elastic  Network  Interface  to
                    attach

                 New in version 2016.11.0.

          network_interface_id
                    (string)  -  The  id  of  Elastic Network Interface to
                    attach

                 New in version 2016.11.0.

          attributes
                 (dict) - Instance attributes and value to be  applied  to
                 the instance.  Available options are:

                    * instanceType - A valid instance type (m1.small)

                    * kernel - Kernel ID (None)

                    * ramdisk - Ramdisk ID (None)

                    * userData - Base64 encoded String (None)

                    * disableApiTermination - Boolean (true)

                    * instanceInitiatedShutdownBehavior - stop|terminate

                    * blockDeviceMapping   -   List   of   strings  -  ie:
                      ['/dev/sda=false']

                    * sourceDestCheck - Boolean (true)

                    * groupSet - Set of Security Groups or IDs

                    * ebsOptimized - Boolean (false)

                    * sriovNetSupport - String - ie: 'simple'

          target_state
                 (string) - The desired  target  state  of  the  instance.
                 Available options are:

                    * running

                    * stopped

                 Note that this option is currently UNIMPLEMENTED.

          public_ip:
                 (string)  - The IP of a previously allocated EIP address,
                 which will be attached  to  the  instance.   EC2  Classic
                 instances  ONLY  -  for  VCP  pass  in  an  allocation_id
                 instead.

          allocation_id:
                 (string) - The ID of a previously allocated EIP  address,
                 which  will  be  attached to the instance.  VPC instances
                 ONLY - for Classic pass in a public_ip instead.

          allocate_eip:
                 (bool) - Allocate and attach an EIP on-the-fly  for  this
                 instance.  Note you'll want to releaase this address when
                 terminating the instance,  either  manually  or  via  the
                 'release_eip' flag to 'instance_absent'.

          region (string) - Region to connect to.

          key    (string) - Secret key to be used.

          keyid  (string) - Access key to be used.

          profile
                 (variable)  -  A  dict  with  region, key and keyid, or a
                 pillar key (string) that contains a dict with region, key
                 and keyid.

          New in version 2016.3.0.

   salt.states.boto_ec2.key_absent(name,       region=None,      key=None,
   keyid=None, profile=None)
          Deletes a key pair

   salt.states.boto_ec2.key_present(name,               save_private=None,
   upload_public=None, region=None, key=None, keyid=None, profile=None)
          Ensure key pair is present.

   salt.states.boto_ec2.snapshot_created(name,   ami_name,  instance_name,
   wait_until_available=True, wait_timeout_seconds=300, **kwargs)
          Create a snapshot from the given instance

          New in version 2016.3.0.

   salt.states.boto_ec2.volume_absent(name,              volume_name=None,
   volume_id=None,   instance_name=None,   instance_id=None,  device=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure the EC2 volume is detached and absent.

          New in version 2016.11.0.

          name   State definition name.

          volume_name
                 Name tag associated with the volume.  For safety, if this
                 matches  more  than  one volume, the state will refuse to
                 apply.

          volume_id
                 Resource ID of the volume.

          instance_name
                 Only remove volume if it is  attached  to  instance  with
                 this  Name  tag.  Exclusive with 'instance_id'.  Requires
                 'device'.

          instance_id
                 Only remove volume if it is attached  to  this  instance.
                 Exclusive with 'instance_name'.  Requires 'device'.

          device Match   by  device  rather  than  ID.   Requires  one  of
                 'instance_name' or 'instance_id'.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_ec2.volumes_tagged(name,                     tag_maps,
   authoritative=False, region=None, key=None, keyid=None, profile=None)
          Ensure EC2 volume(s) matching the given filters have the defined
          tags.

          New in version 2016.11.0.

          name   State definition name.

          tag_maps
                 List  of  dicts of filters and tags, where 'filters' is a
                 dict suitable for passing to the  'filters'  argument  of
                 boto_ec2.get_all_volumes(),  and 'tags' is a dict of tags
                 to be set on volumes as matched  by  the  given  filters.
                 The  filter syntax is extended to permit passing either a
                 list   of   volume_ids   or   an   instance_name    (with
                 instance_name being the Name tag of the instance to which
                 the desired volumes are mapped).   Each  mapping  in  the
                 list  is  applied separately, so multiple sets of volumes
                 can be all tagged  differently  with  one  call  to  this
                 function.

          YAML example fragment:

          authoritative
                 Should  un-declared tags currently set on matched volumes
                 be deleted?  Boolean.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticache
   Manage Elasticache
   New in version 2014.7.0.

   Create,  destroy  and  update  Elasticache clusters. Be aware that this
   interacts with Amazon's services, and so may incur charges.

   Note: This module currently only  supports  creation  and  deletion  of
   elasticache   resources   and  will  not  modify  clusters  when  their
   configuration changes in your state files.

   This module uses boto, which can be installed via package, or pip.

   This module accepts  explicit  elasticache  credentials  but  can  also
   utilize  IAM  roles assigned to the instance through Instance Profiles.
   Dynamic credentials are then automatically obtained from AWS API and no
   further configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      elasticache.keyid: GKTADJGHEIQSXMKKRBJ08H
      elasticache.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
        keyid: GKTADJGHEIQSXMKKRBJ08H
        key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      Ensure myelasticache exists:
        boto_elasticache.present:
          - name: myelasticache
          - engine: redis
          - cache_node_type: cache.t1.micro
          - num_cache_nodes: 1
          - notification_topic_arn: arn:aws:sns:us-east-1:879879:my-sns-topic
          - region: us-east-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars
      Ensure myelasticache exists:
        boto_elasticache.present:
          - name: myelasticache
          - engine: redis
          - cache_node_type: cache.t1.micro
          - num_cache_nodes: 1
          - notification_topic_arn: arn:aws:sns:us-east-1:879879:my-sns-topic
          - region: us-east-1
          - profile: myprofile

      # Passing in a profile
      Ensure myelasticache exists:
        boto_elasticache.present:
          - name: myelasticache
          - engine: redis
          - cache_node_type: cache.t1.micro
          - num_cache_nodes: 1
          - notification_topic_arn: arn:aws:sns:us-east-1:879879:my-sns-topic
          - region: us-east-1
          - profile:
              keyid: GKTADJGHEIQSXMKKRBJ08H
              key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_elasticache.absent(name,    wait=True,    region=None,
   key=None, keyid=None, profile=None)
          Ensure the named elasticache cluster is deleted.

          name   Name of the cache cluster.

          wait   Boolean. Wait for confirmation from boto that the cluster
                 is in the deleting state.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticache.creategroup(name,      primary_cluster_id,
   replication_group_description,   wait=None,   region=None,    key=None,
   keyid=None, profile=None)
          Ensure the a replication group is create.

          name   Name of replication group

          wait   Waits for the group to be available

          primary_cluster_id
                 Name of the master cache node

          replication_group_description
                 Description for the group

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticache.present(name,                 engine=None,
   cache_node_type=None,                             num_cache_nodes=None,
   preferred_availability_zone=None,                            port=None,
   cache_parameter_group_name=None,       cache_security_group_names=None,
   replication_group_id=None,             auto_minor_version_upgrade=True,
   security_group_ids=None,                  cache_subnet_group_name=None,
   engine_version=None,                       notification_topic_arn=None,
   preferred_maintenance_window=None,  wait=None,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure the cache cluster exists.

          name   Name of the cache cluster (cache cluster id).

          engine The name of the cache engine to be used  for  this  cache
                 cluster. Valid values are memcached or redis.

          cache_node_type
                 The compute and memory capacity of the nodes in the cache
                 cluster.   cache.t1.micro,  cache.m1.small,   etc.   See:
                 https://boto.readthedocs.io/en/latest/ref/elasticache.html#boto.elasticache.layer1.ElastiCacheConnection.create_cache_cluster

          num_cache_nodes
                 The number of cache nodes that  the  cache  cluster  will
                 have.

          preferred_availability_zone
                 The EC2 Availability Zone in which the cache cluster will
                 be created.  All cache nodes belonging to a cache cluster
                 are placed in the preferred availability zone.

          port   The  port  number  on  which each of the cache nodes will
                 accept connections.

          cache_parameter_group_name
                 The name of the cache parameter group to  associate  with
                 this  cache  cluster.  If  this  argument is omitted, the
                 default cache parameter group for  the  specified  engine
                 will be used.

          cache_security_group_names
                 A  list  of  cache security group names to associate with
                 this cache cluster. Use this parameter only when you  are
                 creating a cluster outside of a VPC.

          replication_group_id
                 The  replication group to which this cache cluster should
                 belong. If this parameter is specified, the cache cluster
                 will  be  added  to  the specified replication group as a
                 read replica; otherwise, the  cache  cluster  will  be  a
                 standalone  primary  that  is not part of any replication
                 group.

          auto_minor_version_upgrade
                 Determines whether minor engine upgrades will be  applied
                 automatically to the cache cluster during the maintenance
                 window. A value of True allows these upgrades  to  occur;
                 False disables automatic upgrades.

          security_group_ids
                 One or more VPC security groups associated with the cache
                 cluster. Use this parameter only when you are creating  a
                 cluster in a VPC.

          cache_subnet_group_name
                 The  name  of  the  cache subnet group to be used for the
                 cache cluster.  Use this  parameter  only  when  you  are
                 creating a cluster in a VPC.

          engine_version
                 The  version  number  of  the cache engine to be used for
                 this cluster.

          notification_topic_arn
                 The Amazon Resource  Name  (ARN)  of  the  Amazon  Simple
                 Notification  Service  (SNS) topic to which notifications
                 will be sent. The Amazon SNS topic owner must be the same
                 as the cache cluster owner.

          preferred_maintenance_window
                 The  weekly  time  range  (in  UTC)  during  which system
                 maintenance can occur. Example: sun:05:00-sun:09:00

          wait   Boolean. Wait for confirmation from boto that the cluster
                 is in the available state.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticache.subnet_group_present(name,
   subnet_ids=None,    subnet_names=None,   description=None,   tags=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure ElastiCache subnet group exists.

          New in version 2015.8.0.

          name   The name for the ElastiCache subnet group. This value  is
                 stored as a lowercase string.

          subnet_ids
                 A  list  of  VPC  subnet  IDs for the cache subnet group.
                 Exclusive with subnet_names.

          subnet_names
                 A list of VPC subnet names for the  cache  subnet  group.
                 Exclusive with subnet_ids.

          description
                 Subnet group description.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticsearch_domain module
   Manage Elasticsearch Domains
   New in version 2016.11.0.

   Create and destroy Elasticsearch domains. Be aware that this  interacts
   with Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure domain exists:
          boto_elasticsearch_domain.present:
              - DomainName: mydomain
              - profile='user-credentials'
              - ElasticsearchClusterConfig:
                  InstanceType": "t2.micro.elasticsearch"
                  InstanceCount: 1
                  DedicatedMasterEnabled: False
                  ZoneAwarenessEnabled: False
              - EBSOptions:
                  EBSEnabled: True
                  VolumeType: "gp2"
                  VolumeSize: 10
                  Iops: 0
              - AccessPolicies:
                  Version: "2012-10-17"
                  Statement:
                    - Effect: "Allow"
                    - Principal:
                        AWS: "*"
                    - Action:
                      - "es:*"
                    - Resource: "arn:aws:es:*:111111111111:domain/mydomain/*
                    - Condition:
                        IpAddress:
                          "aws:SourceIp":
                            - "127.0.0.1",
                            - "127.0.0.2",
              - SnapshotOptions:
                  AutomatedSnapshotStartHour: 0
              - AdvancedOptions:
                  rest.action.multi.allow_explicit_index": "true"
              - Tags:
                  a: "b"
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_elasticsearch_domain.absent(name,          DomainName,
   region=None, key=None, keyid=None, profile=None)
          Ensure domain with passed properties is absent.

          name   The name of the state definition.

          DomainName
                 Name of the domain.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elasticsearch_domain.present(name,         DomainName,
   ElasticsearchClusterConfig=None, EBSOptions=None,  AccessPolicies=None,
   SnapshotOptions=None,   AdvancedOptions=None,  Tags=None,  region=None,
   key=None, keyid=None, profile=None)
          Ensure domain exists.

          name   The name of the state definition

          DomainName
                 Name of the domain.

          ElasticsearchClusterConfig
                 Configuration  options  for  an   Elasticsearch   domain.
                 Specifies  the  instance  type and number of instances in
                 the domain cluster.

                 InstanceType  (string)  --  The  instance  type  for   an
                 Elasticsearch cluster.

                 InstanceCount (integer) -- The number of instances in the
                 specified domain cluster.

                 DedicatedMasterEnabled (boolean) -- A  boolean  value  to
                 indicate whether a dedicated master node is enabled.  See
                 About Dedicated Master Nodes for more information.

                 ZoneAwarenessEnabled (boolean)  --  A  boolean  value  to
                 indicate  whether  zone  awareness  is enabled. See About
                 Zone Awareness for more information.

                 DedicatedMasterType (string) -- The instance type  for  a
                 dedicated master node.

                 DedicatedMasterCount   (integer)   --   Total  number  of
                 dedicated master nodes, active and on  standby,  for  the
                 cluster.

          EBSOptions
                 Options  to enable, disable and specify the type and size
                 of EBS storage volumes.

                 EBSEnabled  (boolean)  --  Specifies  whether   EBS-based
                 storage is enabled.

                 VolumeType  (string)  --  Specifies  the  volume type for
                 EBS-based storage.

                 VolumeSize (integer) -- Integer to specify the size of an
                 EBS volume.

                 Iops  (integer)  --  Specifies the IOPD for a Provisioned
                 IOPS EBS volume (SSD).

          AccessPolicies
                 IAM access policy

          SnapshotOptions
                 Option to set time, in UTC format, of the daily automated
                 snapshot.  Default value is 0 hours.

                 AutomatedSnapshotStartHour  (integer)  --  Specifies  the
                 time, in UTC format,  when  the  service  takes  a  daily
                 automated snapshot of the specified Elasticsearch domain.
                 Default value is 0 hours.

          AdvancedOptions
                 Option to allow references to indices in an HTTP  request
                 body. Must be false when configuring access to individual
                 sub-resources. By default, the value is true .

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_elb
   Manage ELBs

   New in version 2014.7.0.

   Create  and  destroy  ELBs.  Be aware that this interacts with Amazon's
   services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit elb credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      elb.keyid: GKTADJGHEIQSXMKKRBJ08H
      elb.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - availability_zones:
                  - us-east-1a
                  - us-east-1c
                  - us-east-1d
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              - listeners:
                  - elb_port: 443
                    instance_port: 80
                    elb_protocol: HTTPS
                    instance_protocol: HTTP
                    certificate: 'arn:aws:iam::1111111:server-certificate/mycert'
                    policies:
                        - my-ssl-policy
                        - cookie-policy
                  - elb_port: 8210
                    instance_port: 8210
                    elb_protocol: TCP
              - backends:
                  - instance_port: 80
                    policies:
                        - enable-proxy-protocol
              - health_check:
                  target: 'HTTP:80/'
              - attributes:
                  cross_zone_load_balancing:
                    enabled: true
                  access_log:
                    enabled: true
                    s3_bucket_name: 'mybucket'
                    s3_bucket_prefix: 'my-logs'
                    emit_interval: 5
                  connecting_settings:
                    idle_timeout: 60
              - cnames:
                  - name: mycname.example.com.
                    zone: example.com.
                    ttl: 60
                  - name: myothercname.example.com.
                    zone: example.com.
              - security_groups:
                  - my-security-group
              - policies:
                  - policy_name: my-ssl-policy
                    policy_type: SSLNegotiationPolicyType
                    policy:
                      Protocol-TLSv1.2: true
                      Protocol-SSLv3: false
                      Server-Defined-Cipher-Order: true
                      ECDHE-ECDSA-AES128-GCM-SHA256: true
                  - policy_name: cookie-policy
                    policy_type: LBCookieStickinessPolicyType
                    policy: {}  # no policy means this is a session cookie
                  - policy_name: enable-proxy-protocol
                    policy_type: ProxyProtocolPolicyType
                    policy:
                      ProxyProtocol: true

      # Using a profile from pillars
      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - profile: myelbprofile

      # Passing in a profile
      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - profile:
                  keyid: GKTADJGHEIQSXMKKRBJ08H
                  key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's possible to  specify  attributes  from  pillars  by  specifying  a
   pillar.  You  can override the values defined in the pillard by setting
   the attributes on the resource. The module will use the default  pillar
   key  'boto_elb_attributes',  which allows you to set default attributes
   for all ELB resources.

   Setting the attributes pillar:

      my_elb_attributes:
        cross_zone_load_balancing:
          enabled: true
        connection_draining:
          enabled: true
          timeout: 20
        access_log:
          enabled: true
          s3_bucket_name: 'mybucket'
          s3_bucket_prefix: 'my-logs'
          emit_interval: 5

   Overriding the attribute values on the resource:

      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - attributes_from_pillar: my_elb_attributes
              # override cross_zone_load_balancing:enabled
              - attributes:
                  cross_zone_load_balancing:
                    enabled: false
              - profile: myelbprofile

   It's possible to specify cloudwatch alarms that  will  be  setup  along
   with the ELB. Note the alarm name will be defined by the name attribute
   provided, plus the ELB resource name.

      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - profile: myelbprofile
              - alarms:
                  UnHealthyHostCount:
                    name: 'ELB UnHealthyHostCount **MANAGED BY SALT**'
                    attributes:
                      metric: UnHealthyHostCount
                      namespace: AWS/ELB
                      statistic: Average
                      comparison: '>='
                      threshold: 1.0
                      period: 600
                      evaluation_periods: 6
                      unit: null
                      description: ELB UnHealthyHostCount
                      alarm_actions: ['arn:aws:sns:us-east-1:12345:myalarm']
                      insufficient_data_actions: []
                      ok_actions: ['arn:aws:sns:us-east-1:12345:myalarm']

   You can also use alarms from pillars,  and  override  values  from  the
   pillar   alarms  by  setting  overrides  on  the  resource.  Note  that
   'boto_elb_alarms' will be used as a default value for all resources, if
   defined and can be used to ensure alarms are always set for a resource.

   Setting the alarms in a pillar:

      my_elb_alarm:
        UnHealthyHostCount:
          name: 'ELB UnHealthyHostCount **MANAGED BY SALT**'
          attributes:
            metric: UnHealthyHostCount
            namespace: AWS/ELB
            statistic: Average
            comparison: '>='
            threshold: 1.0
            period: 600
            evaluation_periods: 6
            unit: null
            description: ELB UnHealthyHostCount
            alarm_actions: ['arn:aws:sns:us-east-1:12345:myalarm']
            insufficient_data_actions: []
            ok_actions: ['arn:aws:sns:us-east-1:12345:myalarm']

   Overriding the alarm values on the resource:

      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - profile: myelbprofile
              - alarms_from_pillar: my_elb_alarm
              # override UnHealthyHostCount:attributes:threshold
              - alarms:
                  UnHealthyHostCount:
                    attributes:
                      threshold: 2.0

   Tags can also be set:

   New in version 2016.3.0.

      Ensure myelb ELB exists:
          boto_elb.present:
              - name: myelb
              - region: us-east-1
              - profile: myelbprofile
              - tags:
                  MyTag: 'My Tag Value'
                  OtherTag: 'My Other Value'

   salt.states.boto_elb.absent(name,  region=None,  key=None,  keyid=None,
   profile=None)
          Ensure an ELB does not exist

          name   name of the ELB

   salt.states.boto_elb.present(name, listeners,  availability_zones=None,
   subnets=None,          subnet_names=None,         security_groups=None,
   scheme='internet-facing',      health_check=None,      attributes=None,
   attributes_from_pillar='boto_elb_attributes', cnames=None, alarms=None,
   alarms_from_pillar='boto_elb_alarms',                    policies=None,
   policies_from_pillar='boto_elb_policies',  backends=None,  region=None,
   key=None,  keyid=None,  profile=None,  wait_for_sync=True,   tags=None,
   instance_ids=None, instance_names=None)
          Ensure the ELB exists.

          name   Name of the ELB.

          availability_zones
                 A list of availability zones for this ELB.

          listeners
                 A list of listener lists; example:

                    [
                        ['443', 'HTTPS', 'arn:aws:iam::1111111:server-certificate/mycert'],
                        ['8443', '80', 'HTTPS', 'HTTP', 'arn:aws:iam::1111111:server-certificate/mycert']
                    ]

          subnets
                 A  list  of  subnet  IDs  in  your  VPC to attach to your
                 LoadBalancer.

          subnet_names
                 A list of subnet names in your  VPC  to  attach  to  your
                 LoadBalancer.

          security_groups
                 The  security groups assigned to your LoadBalancer within
                 your  VPC.  Must  be  passed  either  as  a  list  or   a
                 comma-separated string.

                 For example, a list:

                    - security_groups:
                      - secgroup-one
                      - secgroup-two

                 Or as a comma-separated string:

                    - security_groups: secgroup-one,secgroup-two

          scheme The  type of a LoadBalancer, internet-facing or internal.
                 Once set, can not be modified.

          health_check
                 A dict defining the health check for this ELB.

          attributes
                 A dict defining  the  attributes  to  set  on  this  ELB.
                 Unknown keys will be silently ignored.

                 See the salt.modules.boto_elb.set_attributes function for
                 recognized attributes.

          attributes_from_pillar
                 name   of   pillar   dict   that   contains   attributes.
                 Attributes  defined for this specific state will override
                 those from pillar.

          cnames A list of cname dicts with attributes needed for the  DNS
                 add_record state.  By default the boto_route53.add_record
                 state will be used, which requires: name, zone, ttl,  and
                 identifier.   See  the boto_route53 state for information
                 about these attributes.  Other DNS modules can be  called
                 by specifying the provider keyword.  the cnames dict will
                 be passed to the state as kwargs.

                 See the salt.states.boto_route53  state  for  information
                 about these attributes.

          alarms:
                 a  dictionary  of name->boto_cloudwatch_alarm sections to
                 be associated with this ELB.  All  attributes  should  be
                 specified    except   for   dimension   which   will   be
                 automatically set to this ELB.

                 See  the  salt.states.boto_cloudwatch_alarm   state   for
                 information about these attributes.

          alarms_from_pillar:
                 name   of  pillar  dict  that  contains  alarm  settings.
                 Alarms defined for  this  specific  state  will  override
                 those from pillar.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          wait_for_sync
                 Wait for an INSYNC change status from Route53.

          tags   dict of tags

          instance_ids
                 list of instance ids.  The state will ensure that  these,
                 and  ONLY  these,  instances are registered with the ELB.
                 This is additive with instance_names.

          instance_names
                 list of instance  names.   The  state  will  ensure  that
                 these,  and ONLY these, instances are registered with the
                 ELB.  This is additive with instance_ids.

   salt.states.boto_elb.register_instances(name,  instances,  region=None,
   key=None, keyid=None, profile=None)
          Add  EC2  instance(s)  to  an Elastic Load Balancer. Removing an
          instance from the instances list does not  remove  it  from  the
          ELB.

          name   The  name  of  the  Elastic  Load  Balancer  to  add  EC2
                 instances to.

          instances
                 A list  of  EC2  instance  IDs  that  this  Elastic  Load
                 Balancer  should  distribute  traffic to. This state will
                 only ever append new instances to the ELB. EC2  instances
                 already  associated  with this ELB will not be removed if
                 they are not in the instances list.

          New in version 2015.8.0.

             add-instances:
               boto_elb.register_instances:
                 - name: myloadbalancer
                 - instances:
                   - instance-id1
                   - instance-id2

   salt.states.boto_iam
   Manage IAM objects
   New in version 2015.8.0.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit IAM credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      delete-user:
        boto_iam.user_absent:
          - name: myuser
          - delete_keys: true

      delete-keys:
        boto_iam.keys_absent:
          - access_keys:
            - 'AKIAJHTMIQ2ASDFLASDF'
            - 'PQIAJHTMIQ2ASRTLASFR'
          - user_name: myuser

      create-user:
        boto_iam.user_present:
          - name: myuser
          - policies:
              mypolicy: |
                  {
                      "Version": "2012-10-17",
                      "Statement": [{
                      "Effect": "Allow",
                      "Action": "*",
                      "Resource": "*"}]
                  }
          - password: NewPassword$$1
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'fdkjsafkljsASSADFalkfjasdf'

      create-group:
        boto_iam.group_present:
          - name: mygroup
          - users:
            - myuser
            - myuser1
          - policies:
              mypolicy: |
                  {
                      "Version": "2012-10-17",
                      "Statement": [{
                      "Effect": "Allow",
                      "Action": "*",
                      "Resource": "*"}]
                  }
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'safsdfsal;fdkjsafkljsASSADFalkfj'

      change-policy:
        boto_iam.account_policy:
          - change_password: True
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'safsdfsal;fdkjsafkljsASSADFalkfj'

      create server certificate:
        boto_iam.server_cert_present:
          - name: mycert
          - public_key: salt://base/mycert.crt
          - private_key: salt://base/mycert.key
          - cert_chain: salt://base/mycert_chain.crt
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'fdkjsafkljsASSADFalkfjasdf'

      delete server certificate:
        boto_iam.server_cert_absent:
          - name: mycert

      create keys for user:
        boto_iam.keys_present:
          - name: myusername
          - number: 2
          - save_dir: /root
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'fdkjsafkljsASSADFalkfjasdf'

      create policy:
        boto_iam.policy_present:
          - name: myname
          - policy_document: '{"MyPolicy": "Statement": [{"Action": ["sqs:*"], "Effect": "Allow", "Resource": ["arn:aws:sqs:*:*:*"], "Sid": "MyPolicySqs1"}]}'
          - region: eu-west-1
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'fdkjsafkljsASSADFalkfjasdf'

      add-saml-provider:
        boto_iam.saml_provider_present:
          - name: my_saml_provider
          - saml_metadata_document: salt://base/files/provider.xml
          - keyid: 'AKIAJHTMIQ2ASDFLASDF'
          - key: 'safsdfsal;fdkjsafkljsASSADFalkfj'

   salt.states.boto_iam.account_policy(name=None,
   allow_users_to_change_password=None,                  hard_expiry=None,
   max_password_age=None,                    minimum_password_length=None,
   password_reuse_prevention=None,      require_lowercase_characters=None,
   require_numbers=None,                             require_symbols=None,
   require_uppercase_characters=None, region=None,  key=None,  keyid=None,
   profile=None)
          Change account policy.

          New in version 2015.8.0.

          name (string)
                 The name of the account policy

          allow_users_to_change_password (bool)
                 Allows  all  IAM  users  in  your  account to use the AWS
                 Management Console to change their own passwords.

          hard_expiry (bool)
                 Prevents IAM users from  setting  a  new  password  after
                 their password has expired.

          max_password_age (int)
                 The number of days that an IAM user password is valid.

          minimum_password_length (int)
                 The  minimum  number of characters allowed in an IAM user
                 password.

          password_reuse_prevention (int)
                 Specifies the number of previous passwords that IAM users
                 are prevented from reusing.

          require_lowercase_characters (bool)
                 Specifies  whether  IAM  user  passwords  must contain at
                 least one lowercase character from the  ISO  basic  Latin
                 alphabet (a to z).

          require_numbers (bool)
                 Specifies  whether  IAM  user  passwords  must contain at
                 least one numeric character (0 to 9).

          require_symbols (bool)
                 Specifies whether IAM  user  passwords  must  contain  at
                 least one of the following non-alphanumeric characters: !
                 @ # $ % ^ & * ( ) _ + - = [ ] { } | '

          require_uppercase_characters (bool)
                 Specifies whether IAM  user  passwords  must  contain  at
                 least  one  uppercase  character from the ISO basic Latin
                 alphabet (A to Z).

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string)

   salt.states.boto_iam.group_absent(name,      region=None,     key=None,
   keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM group is absent.

          name (string)
                 The name of the group.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.group_present(name,                 policies=None,
   policies_from_pillars=None,     managed_policies=None,      users=None,
   path='/', region=None, key=None, keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM group is present

          name (string)
                 The name of the new group.

          path (string)
                 The path for the group, defaults to '/'

          policies (dict)
                 A dict of IAM group policy documents.

          policies_from_pillars (list)
                 A  list  of  pillars  that  contain  role  policy  dicts.
                 Policies in the pillars  will  be  merged  in  the  order
                 defined  in the list and key conflicts will be handled by
                 later defined keys overriding earlier defined  keys.  The
                 policies  defined  here  will be merged with the policies
                 defined in the policies argument. If keys  conflict,  the
                 keys  in  the  policies  argument  will override the keys
                 defined in policies_from_pillars.

          manaaged_policies (list)
                 A list of policy names or ARNs that should be attached to
                 this group.

          users (list)
                 A list of users to be added to the group.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.keys_absent(access_keys,  user_name,  region=None,
   key=None, keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM user access_key_id is absent.

          access_key_id (list)
                 A list of access key ids

          user_name (string)
                 The username of the user

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.keys_present(name, number, save_dir,  region=None,
   key=None, keyid=None, profile=None, save_format='{2}\n{0}\n{3}\n{1}\n')
             New in version 2015.8.0.

             Ensure the IAM access keys are present.

             name (string)
                    The name of the new user.

             number (int)
                    Number of keys that user should have.

             save_dir (string)
                    The  directory  that  the key/keys will be saved. Keys
                    are saved to a file named according  to  the  username
                    privided.

             region (string)
                    Region to connect to.

             key (string)
                    Secret key to be used.

             keyid (string)
                    Access key to be used.

             profile (dict)
                    A  dict  with  region,  key and keyid, or a pillar key
                    (string) that contains a dict  with  region,  key  and
                    keyid.

             save_format (dict)
                    Save  format  is repeated for each key. Default format
                    is "{2}

          {0} {3} {1} ",
             where {0} and {1} are placeholders for  new  key_id  and  key
             respectively,  whereas  {2} and {3} are "key_id-{number}" and
             'key-{number}' strings kept for compatibility.

   salt.states.boto_iam.policy_absent(name,     region=None,     key=None,
   keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM managed policy with the specified name is absent

          name (string)
                 The name of the new policy.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.policy_present(name,  policy_document,  path=None,
   description=None, region=None, key=None, keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM managed policy is present

          name (string)
                 The name of the new policy.

          policy_document (dict)
                 The document of the new policy

          path (string)
                 The  path in which the policy will be created. Default is
                 '/'.

          description (string)
                 Description

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.saml_provider_absent(name,  region=None, key=None,
   keyid=None, profile=None)
          Ensure the SAML provider with the specified name is absent.

          name (string)
                 The name of the SAML provider.

          saml_metadata_document (string)
                 The xml document of the SAML provider.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.saml_provider_present(name,
   saml_metadata_document,     region=None,     key=None,      keyid=None,
   profile=None)
          Ensure the SAML provider with the specified name is present.

          name (string)
                 The name of the SAML provider.

          saml_metadata_document (string)
                 The xml document of the SAML provider.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.server_cert_absent(name,  region=None,   key=None,
   keyid=None, profile=None)
          Deletes a server certificate.

          New in version 2015.8.0.

          name (string)
                 The  name  for the server certificate. Do not include the
                 path in this value.

          region (string)
                 The name of the region to connect to.

          key (string)
                 The key to be used in order to connect

          keyid (string)
                 The keyid to be used in order to connect

          profile (string)
                 The profile that contains a dict of region, key, keyid

   salt.states.boto_iam.server_cert_present(name, public_key, private_key,
   cert_chain=None,    path=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Crete server certificate.

          New in version 2015.8.0.

          name (string)
                 The name for the server certificate. Do not  include  the
                 path in this value.

          public_key (string)
                 The contents of the public key certificate in PEM-encoded
                 format.

          private_key (string)
                 The contents of the private key in PEM-encoded format.

          cert_chain (string)
                 The contents of the certificate chain. This is  typically
                 a   concatenation   of   the   PEM-encoded   public   key
                 certificates of the chain.

          path (string)
                 The path for the server certificate.

          region (string)
                 The name of the region to connect to.

          key (string)
                 The key to be used in order to connect

          keyid (string)
                 The keyid to be used in order to connect

          profile (string)
                 The profile that contains a dict of region, key, keyid

   salt.states.boto_iam.user_absent(name,                delete_keys=True,
   delete_mfa_devices=True,  delete_profile=True,  region=None,  key=None,
   keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM user is absent. User cannot be deleted if it  has
          keys.

          name (string)
                 The name of the new user.

          delete_keys (bool)
                 Delete all keys from user.

          delete_mfa_devices (bool)
                 Delete all mfa devices from user.

                 New in version 2016.3.0.

          delete_profile (bool)
                 Delete profile from user.

                 New in version 2016.3.0.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam.user_present(name,                  policies=None,
   policies_from_pillars=None,    managed_policies=None,    password=None,
   path=None, region=None, key=None, keyid=None, profile=None)
          New in version 2015.8.0.

          Ensure the IAM user is present

          name (string)
                 The name of the new user.

          policies (dict)
                 A dict of IAM group policy documents.

          policies_from_pillars (list)
                 A  list  of  pillars  that  contain  role  policy  dicts.
                 Policies  in  the  pillars  will  be  merged in the order
                 defined in the list and key conflicts will be handled  by
                 later  defined  keys overriding earlier defined keys. The
                 policies defined here will be merged  with  the  policies
                 defined  in  the policies argument. If keys conflict, the
                 keys in the policies  argument  will  override  the  keys
                 defined in policies_from_pillars.

          managed_policies (list)
                 A  list  of  managed  policy names or ARNs that should be
                 attached to this user.

          password (string)
                 The password for the new user. Must comply  with  account
                 policy.

          path (string)
                 The path of the user. Default is '/'.

                 New in version 2015.8.2.

          region (string)
                 Region to connect to.

          key (string)
                 Secret key to be used.

          keyid (string)
                 Access key to be used.

          profile (dict)
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam_role
   Manage IAM roles
   New in version 2014.7.0.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit IAM credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      iam.keyid: GKTADJGHEIQSXMKKRBJ08H
      iam.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

   Creating a role will  automatically  create  an  instance  profile  and
   associate  it  with  the  role. This is the default behavior of the AWS
   console.

      myrole:
          boto_iam_role.present:
              - region: us-east-1
              - key: GKTADJGHEIQSXMKKRBJ08H
              - keyid: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              - policies_from_pillars:
                  - shared_iam_bootstrap_policy
              - policies:
                  MySQSPolicy:
                      Statement:
                        - Action:
                              - sqs:*
                          Effect: Allow
                          Resource:
                              - arn:aws:sqs:*:*:*
                          Sid: MyPolicySQS1
                  MyS3Policy:
                      Statement:
                        - Action:
                              - s3:GetObject
                          Effect: Allow
                          Resource:
                              - arn:aws:s3:*:*:mybucket/*

      # Using a credentials profile from pillars
      myrole:
          boto_iam_role.present:
              - profile: myiamprofile

      # Passing in a credentials profile
      myrole:
          boto_iam_role.present:
              - profile:
                  key: GKTADJGHEIQSXMKKRBJ08H
                  keyid: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                  region: us-east-1

   If delete_policies: False is specified, existing policies that are  not
   in  the  given list of policies will not be deleted. This allows manual
   modifications on the IAM role to be persistent. This functionality  was
   added in 2015.8.0.

   NOTE:
      When  using  the  profile parameter and region is set outside of the
      profile group, region is ignored and a default region will be used.

      If region is missing from the profile data set,  us-east-1  will  be
      used as the default region.

   salt.states.boto_iam_role.absent(name,      region=None,      key=None,
   keyid=None, profile=None)
          Ensure the IAM role is deleted.

          name   Name of the IAM role.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iam_role.present(name,           policy_document=None,
   path=None,          policies=None,          policies_from_pillars=None,
   managed_policies=None,    create_instance_profile=True,    region=None,
   key=None, keyid=None, profile=None, delete_policies=True)
          Ensure the IAM role exists.

          name   Name of the IAM role.

          policy_document
                 The policy that grants an entity permission to assume the
                 role.                                                (See
                 https://boto.readthedocs.io/en/latest/ref/iam.html#boto.iam.connection.IAMConnection.create_role)

          path   The    path    to   the   role/instance   profile.   (See
                 https://boto.readthedocs.io/en/latest/ref/iam.html#boto.iam.connection.IAMConnection.create_role)

          policies
                 A dict of IAM role policies.

          policies_from_pillars
                 A  list  of  pillars  that  contain  role  policy  dicts.
                 Policies in the pillars  will  be  merged  in  the  order
                 defined  in the list and key conflicts will be handled by
                 later defined keys overriding earlier defined  keys.  The
                 policies  defined  here  will be merged with the policies
                 defined in the policies argument. If keys  conflict,  the
                 keys  in  the  policies  argument  will override the keys
                 defined in policies_from_pillars.

          managed_policies
                 A list of  (AWS  or  Customer)  managed  policies  to  be
                 attached to the role.

          create_instance_profile
                 A boolean of whether or not to create an instance profile
                 and associate it with this role.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          delete_policies
                 Deletes  existing policies that are not in the given list
                 of  policies.  Default  value  is  True.  If   False   is
                 specified, existing policies will not be deleted allowing
                 manual modifications on the IAM role to be persistent.

                 New in version 2015.8.0.

   salt.states.boto_iot module
   Manage IoT Objects
   New in version 2016.3.0.

   Create and destroy IoT objects.  Be  aware  that  this  interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure policy exists:
          boto_iot.policy_present:
              - policyName: mypolicy
              - policyDocument:
                  Version: "2012-10-17"
                  Statement:
                    Action:
                      - iot:Publish
                    Resource:
                      - "*"
                    Effect: "Allow"
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      Ensure topic rule exists:
          boto_iot.topic_rule_present:
              - ruleName: myrule
              - sql: "SELECT * FROM 'iot/test'"
              - description: 'test rule'
              - ruleDisabled: false
              - actions:
                - lambda:
                    functionArn: "arn:aws:us-east-1:1234:function/functionname"
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_iot.policy_absent(name,    policyName,    region=None,
   key=None, keyid=None, profile=None)
          Ensure policy with passed properties is absent.

          name   The name of the state definition.

          policyName
                 Name of the policy.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.policy_attached(name,    policyName,    principal,
   region=None, key=None, keyid=None, profile=None)
          Ensure policy is attached to the given principal.

          name   The name of the state definition

          policyName
                 Name of the policy.

          principal
                 The principal which can be a certificate ARN or a Cognito
                 ID.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.policy_detached(name,    policyName,    principal,
   region=None, key=None, keyid=None, profile=None)
          Ensure policy is attached to the given principal.

          name   The name of the state definition.

          policyName
                 Name of the policy.

          principal
                 The principal which can be a certificate ARN or a Cognito
                 ID.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.policy_present(name,  policyName,  policyDocument,
   region=None, key=None, keyid=None, profile=None)
          Ensure policy exists.

          name   The name of the state definition

          policyName
                 Name of the policy.

          policyDocument
                 The JSON document that describes the policy.  The  length
                 of the policyDocument must be a minimum length of 1, with
                 a maximum length of 2048, excluding whitespace.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.thing_type_absent(name,             thingTypeName,
   region=None, key=None, keyid=None, profile=None)
          Ensure thing type with passed properties is absent.

          New in version 2016.11.0.

          name   The name of the state definition.

          thingTypeName
                 Name of the thing type.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.thing_type_present(name,            thingTypeName,
   thingTypeDescription, searchableAttributesList, region=None,  key=None,
   keyid=None, profile=None)
          Ensure thing type exists.

          New in version 2016.11.0.

          name   The name of the state definition

          thingTypeName
                 Name of the thing type

          thingTypeDescription
                 Description of the thing type

          searchableAttributesList
                 List  of  string  attributes  that are searchable for the
                 thing type

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used

          profile
                 A dict with region, key, keyid, or a pillar key  (string)
                 that contains a dict with region, key, and keyid

   salt.states.boto_iot.topic_rule_absent(name,   ruleName,   region=None,
   key=None, keyid=None, profile=None)
          Ensure topic rule with passed properties is absent.

          name   The name of the state definition.

          ruleName
                 Name of the policy.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_iot.topic_rule_present(name,  ruleName,  sql, actions,
   description='', ruleDisabled=False, region=None, key=None,  keyid=None,
   profile=None)
          Ensure topic rule exists.

          name   The name of the state definition

          ruleName
                 Name of the rule.

          sql    The SQL statement used to query the topic.

          actions
                 The actions associated with the rule.

          description
                 The description of the rule.

          ruleDisable
                 Specifies whether the rule is disabled.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_kms
   Manage KMS keys, key policies and grants.

   New in version 2015.8.0.

   Be aware that this interacts with Amazon's services, and so  may  incur
   charges.

   This module uses boto, which can be installed via package, or pip.

   This  module  accepts explicit kms credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      elb.keyid: GKTADJGHEIQSXMKKRBJ08H
      elb.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      Ensure mykey key exists:
        boto_kms.key_present:
          - name: mykey
          - region: us-east-1

      # Using a profile from pillars
      Ensure mykey key exists:
        boto_kms.key_present:
          - name: mykey
          - region: us-east-1
          - profile: myprofile

      # Passing in a profile
      Ensure mykey key exists:
        boto_key.key_present:
          - name: mykey
          - region: us-east-1
          - profile:
              keyid: GKTADJGHEIQSXMKKRBJ08H
              key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_kms.key_present(name,     policy,    description=None,
   key_usage=None, grants=None,  manage_grants=False,  key_rotation=False,
   enabled=True, region=None, key=None, keyid=None, profile=None)
          Ensure  the KMS key exists. KMS keys can not be deleted, so this
          function must be used to ensure the key is enabled or disabled.

          name   Name of the key.

          policy Key usage policy.

          description
                 Description of the key.

          key_usage
                 Specifies the intended use of the key. Can only be set on
                 creation,  defaults to ENCRYPT_DECRYPT, which is also the
                 only supported option.

          grants A list of grants to  apply  to  the  key.  Not  currently
                 implemented.

          manage_grants
                 Whether  or not to manage grants. False by default, which
                 will not manage any grants.

          key_rotation
                 Whether or not key rotation is enabled for the key. False
                 by default.

          enabled
                 Whether or not the key is enabled. True by default.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda module
   Manage Lambda Functions
   New in version 2016.3.0.

   Create and destroy Lambda Functions. Be aware that this interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure function exists:
          boto_lambda.function_present:
              - FunctionName: myfunction
              - Runtime: python2.7
              - Role: iam_role_name
              - Handler: entry_function
              - ZipFile: code.zip
              - S3Bucket: bucketname
              - S3Key: keyname
              - S3ObjectVersion: version
              - Description: "My Lambda Function"
              - Timeout: 3
              - MemorySize: 128
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_lambda.alias_absent(name,      FunctionName,     Name,
   region=None, key=None, keyid=None, profile=None)
          Ensure alias with passed properties is absent.

          name   The name of the state definition.

          FunctionName
                 Name of the function.

          Name   Name of the alias.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda.alias_present(name,     FunctionName,     Name,
   FunctionVersion,  Description='',  region=None,  key=None,  keyid=None,
   profile=None)
          Ensure alias exists.

          name   The name of the state definition.

          FunctionName
                 Name  of  the  function  for  which you want to create an
                 alias.

          Name   The name of the alias to be created.

          FunctionVersion
                 Function version for which you are creating the alias.

          Description
                 A short, user-defined function description.  Lambda  does
                 not  use  this  value. Assign a meaningful description as
                 you see fit.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda.event_source_mapping_absent(name,
   EventSourceArn,  FunctionName,   region=None,   key=None,   keyid=None,
   profile=None)
          Ensure event source mapping with passed properties is absent.

          name   The name of the state definition.

          EventSourceArn
                 ARN of the event source.

          FunctionName
                 Name of the lambda function.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda.event_source_mapping_present(name,
   EventSourceArn,     FunctionName,    StartingPosition,    Enabled=True,
   BatchSize=100, region=None, key=None, keyid=None, profile=None)
          Ensure event source mapping exists.

          name   The name of the state definition.

          EventSourceArn
                 The Amazon Resource Name (ARN) of the Amazon  Kinesis  or
                 the Amazon DynamoDB stream that is the event source.

          FunctionName
                 The  Lambda function to invoke when AWS Lambda detects an
                 event on the stream.

                 You  can  specify  an  unqualified  function  name   (for
                 example,  "Thumbnail") or you can specify Amazon Resource
                 Name   (ARN)    of    the    function    (for    example,
                 "arn:aws:lambda:us-west-2:account-id:function:ThumbNail").
                 AWS Lambda also allows you to specify only the account ID
                 qualifier  (for  example,  "account-id:Thumbnail").  Note
                 that the length constraint applies only to  the  ARN.  If
                 you  specify  only the function name, it is limited to 64
                 character in length.

          StartingPosition
                 The position in the stream where AWS Lambda should  start
                 reading.  (TRIM_HORIZON | LATEST)

          Enabled
                 Indicates  whether  AWS  Lambda  should begin polling the
                 event source. By default, Enabled is true.

          BatchSize
                 The largest  number  of  records  that  AWS  Lambda  will
                 retrieve  from  your event source at the time of invoking
                 your function. Your function receives an event  with  all
                 the retrieved records. The default is 100 records.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda.function_absent(name,             FunctionName,
   region=None, key=None, keyid=None, profile=None)
          Ensure function with passed properties is absent.

          name   The name of the state definition.

          FunctionName
                 Name of the function.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lambda.function_present(name,  FunctionName,  Runtime,
   Role,     Handler,     ZipFile=None,     S3Bucket=None,     S3Key=None,
   S3ObjectVersion=None,   Description='',   Timeout=3,    MemorySize=128,
   Permissions=None,  RoleRetries=5,  region=None,  key=None,  keyid=None,
   profile=None, VpcConfig=None)
          Ensure function exists.

          name   The name of the state definition

          FunctionName
                 Name of the Function.

          Runtime
                 The  Runtime  environment  for  the  function.   One   of
                 'nodejs', 'java8', or 'python2.7'

          Role   The name or ARN of the IAM role that the function assumes
                 when it executes your function to access  any  other  AWS
                 resources.

          Handler
                 The  function within your code that Lambda calls to begin
                 execution. For Node.js  it  is  the  module-name.*export*
                 value   in   your   function.   For   Java,   it  can  be
                 package.classname::handler or package.class-name.

          ZipFile
                 A path to a .zip file containing your deployment package.
                 If  this  is  specified,  S3Bucket  and S3Key must not be
                 specified.

          S3Bucket
                 Amazon S3 bucket name where the .zip file containing your
                 package  is  stored.  If this is specified, S3Key must be
                 specified and ZipFile must NOT be specified.

          S3Key  The Amazon S3 object (the deployment  package)  key  name
                 you  want  to upload. If this is specified, S3Key must be
                 specified and ZipFile must NOT be specified.

          S3ObjectVersion
                 The version of S3 object to use. Optional, should only be
                 specified if S3Bucket and S3Key are specified.

          Description
                 A  short,  user-defined function description. Lambda does
                 not use this value. Assign a  meaningful  description  as
                 you see fit.

          Timeout
                 The  function  execution  time  at  which  Lambda  should
                 terminate this function. Because the execution  time  has
                 cost  implications, we recommend you set this value based
                 on your  expected  execution  time.   The  default  is  3
                 seconds.

          MemorySize
                 The  amount  of  memory,  in  MB, your function is given.
                 Lambda uses this memory size to infer the amount  of  CPU
                 and  memory  allocated  to  your  function. Your function
                 use-case determines your CPU and memory requirements. For
                 example,  a  database  operation  might  need less memory
                 compared to an image  processing  function.  The  default
                 value is 128 MB. The value must be a multiple of 64 MB.

          VpcConfig
                 If  your Lambda function accesses resources in a VPC, you
                 provide this parameter identifying the list  of  security
                 group  IDs and subnet IDs.  These must belong to the same
                 VPC. You must provide at least one security group and one
                 subnet ID.

                 New in version 2016.11.0.

          Permissions
                 A  list  of  permission  definitions  to  be added to the
                 function's policy

          RoleRetries
                 IAM Roles may take some time to propagate to all  regions
                 once  created.   During  that  time function creation may
                 fail; this state will atuomatically retry this number  of
                 times. The default is 5.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lc
   Manage Launch Configurations

   New in version 2014.7.0.

   Create and destroy Launch Configurations. Be aware that this  interacts
   with Amazon's services, and so may incur charges.

   A  limitation  of  this  module  is  that  you  can  not  modify launch
   configurations once they have been created. If a  launch  configuration
   with the specified name exists, this module will always report success,
   even if the specified configuration doesn't match. This  is  due  to  a
   limitation  in  Amazon's  launch  configuration  API, as it only allows
   launch configurations to be created and deleted.

   Also note that a launch configuration that's in  use  by  an  autoscale
   group  can  not be deleted until the autoscale group is no longer using
   it. This may affect the way in which you want to order your states.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit autoscale credentials but can also utilize
   IAM  roles  assigned to the instance through Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      asg.keyid: GKTADJGHEIQSXMKKRBJ08H
      asg.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

   Credential information  is  shared  with  autoscale  groups  as  launch
   configurations  and  autoscale  groups are completely dependent on each
   other.

      Ensure mylc exists:
        boto_lc.present:
          - name: mylc
          - image_id: ami-0b9c9f62
          - key_name: mykey
          - security_groups:
              - mygroup
          - instance_type: m1.small
          - instance_monitoring: true
          - block_device_mappings:
              - '/dev/sda1':
                  size: 20
                  volume_type: 'io1'
                  iops: 220
                  delete_on_termination: true
          - cloud_init:
              boothooks:
                'disable-master.sh': |
                  #!/bin/bash
                  echo "manual" > /etc/init/salt-master.override
              scripts:
                'run_salt.sh': |
                  #!/bin/bash

                  add-apt-repository -y ppa:saltstack/salt
                  apt-get update
                  apt-get install -y salt-minion
                  salt-call state.highstate
          - region: us-east-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars.
      Ensure mylc exists:
        boto_lc.present:
          - name: mylc
          - image_id: ami-0b9c9f62
          - profile: myprofile

      # Passing in a profile.
      Ensure mylc exists:
        boto_lc.present:
          - name: mylc
          - image_id: ami-0b9c9f62
          - profile:
              keyid: GKTADJGHEIQSXMKKRBJ08H
              key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

   salt.states.boto_lc.absent(name,  region=None,  key=None,   keyid=None,
   profile=None)
          Ensure the named launch configuration is deleted.

          name   Name of the launch configuration.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_lc.present(name,       image_id,        key_name=None,
   security_groups=None,          user_data=None,         cloud_init=None,
   instance_type='m1.small',       kernel_id=None,        ramdisk_id=None,
   block_device_mappings=None, instance_monitoring=False, spot_price=None,
   instance_profile_name=None,                        ebs_optimized=False,
   associate_public_ip_address=None,  region=None,  key=None,  keyid=None,
   profile=None)
          Ensure the launch configuration exists.

          name   Name of the launch configuration.

          image_id
                 AMI to use for instances. AMI must exist or  creation  of
                 the launch configuration will fail.

          key_name
                 Name  of  the EC2 key pair to use for instances. Key must
                 exist or creation of the launch configuration will fail.

          security_groups
                 List of Names or security  group  id's  of  the  security
                 groups  with  which to associate the EC2 instances or VPC
                 instances, respectively. Security groups must  exist,  or
                 creation of the launch configuration will fail.

          user_data
                 The user data available to launched EC2 instances.

          cloud_init
                 A  dict  of cloud_init configuration. Currently supported
                 values: scripts, cloud-config.  Mutually  exclusive  with
                 user_data.

          instance_type
                 The instance type. ex: m1.small.

          kernel_id
                 The kernel id for the instance.

          ramdisk_id
                 The RAM disk ID for the instance.

          block_device_mappings
                 A dict of block device mappings that contains a dict with
                 volume_type,    delete_on_termination,    iops,     size,
                 encrypted, snapshot_id.

                 volume_type
                        Indicates  what  volume  type to use. Valid values
                        are standard, io1, gp2.  Default is standard.

                 delete_on_termination
                        Indicates whether to delete the volume on instance
                        termination (true) or not (false).

                 iops   For  Provisioned  IOPS  (SSD)  volumes  only.  The
                        number of I/O  operations  per  second  (IOPS)  to
                        provision for the volume.

                 size   Desired volume size (in GiB).

                 encrypted
                        Indicates  whether the volume should be encrypted.
                        Encrypted  EBS  volumes  must   be   attached   to
                        instances  that  support  Amazon  EBS  encryption.
                        Volumes that are created from encrypted  snapshots
                        are  automatically  encrypted.  There is no way to
                        create an encrypted  volume  from  an  unencrypted
                        snapshot   or   an   unencrypted  volume  from  an
                        encrypted snapshot.

          instance_monitoring
                 Whether instances in group  are  launched  with  detailed
                 monitoring.

          spot_price
                 The  spot  price you are bidding. Only applies if you are
                 building an autoscaling group with spot instances.

          instance_profile_name
                 The name  or  the  Amazon  Resource  Name  (ARN)  of  the
                 instance  profile  associated  with  the IAM role for the
                 instance. Instance profile must exist or the creation  of
                 the launch configuration will fail.

          ebs_optimized
                 Specifies  whether  the instance is optimized for EBS I/O
                 (true) or not (false).

          associate_public_ip_address
                 Used for Auto Scaling groups that launch  instances  into
                 an  Amazon  Virtual  Private  Cloud. Specifies whether to
                 assign a public IP address to each instance launched in a
                 Amazon VPC.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_rds
   Manage RDSs
   New in version 2015.8.0.

   Create and destroy RDS instances. Be aware  that  this  interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This  module  accepts explicit rds credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      rds.keyid: GKTADJGHEIQSXMKKRBJ08H
      rds.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure myrds RDS exists:
        boto_rds.present:
          - name: myrds
          - allocated_storage: 5
          - storage_type: standard
          - db_instance_class: db.t2.micro
          - engine: MySQL
          - master_username: myuser
          - master_user_password: mypass
          - region: us-east-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          - tags:
            -
              - key1
              - value1
            -
              - key2
              - value2

      Ensure parameter group exists:
          create-parameter-group:
            boto_rds.parameter_present:
              - name: myparametergroup
              - db_parameter_group_family: mysql5.6
              - description: "parameter group family"
              - parameters:
                - binlog_cache_size: 32768
                - binlog_checksum: CRC32
              - region: eu-west-1

   depends
          boto3

   salt.states.boto_rds.absent(name,             skip_final_snapshot=None,
   final_db_snapshot_identifier=None,  tags=None,  region=None,  key=None,
   keyid=None, profile=None, wait_for_deletion=True, timeout=180)
          Ensure RDS instance is absent.

          name   Name of the RDS instance.

          skip_final_snapshot
                 Whether  a  final  db  snapshot  is  created  before  the
                 instance is deleted.  If True, no  snapshot  is  created.
                 If  False,  a  snapshot  is  created  before deleting the
                 instance.

          final_db_snapshot_identifier
                 If a final snapshot is requested, this is the  identifier
                 used for that snapshot.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          wait_for_deletion (bool)
                 Wait for the RDS instance to be deleted completely before
                 finishing the state.

          timeout (in seconds)
                 The  amount  of  time  that  can  pass  before raising an
                 Exception.

   salt.states.boto_rds.parameter_present(name, db_parameter_group_family,
   description, parameters=None, apply_method='pending-reboot', tags=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure DB parameter group exists and update parameters.

          name   The name for the parameter group.

          db_parameter_group_family
                 The DB parameter group family name. A DB parameter  group
                 can  be  associated  with  one  and only one DB parameter
                 group family, and can be applied only to  a  DB  instance
                 running  a  database engine and engine version compatible
                 with that DB parameter group family.

          description
                 Parameter group description.

          parameters
                 The DB  parameters  that  need  to  be  changed  of  type
                 dictionary.

          apply_method
                 The  apply-immediate  method can be used only for dynamic
                 parameters; the pending-reboot method can  be  used  with
                 MySQL  and  Oracle  DB  instances  for  either dynamic or
                 static parameters. For Microsoft SQL Server DB instances,
                 the  pending-reboot  method  can  be used only for static
                 parameters.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_rds.present(name,                   allocated_storage,
   db_instance_class,   engine,   master_username,   master_user_password,
   db_name=None,        storage_type=None,        db_security_groups=None,
   vpc_security_group_ids=None,                    availability_zone=None,
   db_subnet_group_name=None,           preferred_maintenance_window=None,
   db_parameter_group_name=None,               db_cluster_identifier=None,
   tde_credential_arn=None,                  tde_credential_password=None,
   storage_encrypted=None,  kms_keyid=None,  backup_retention_period=None,
   preferred_backup_window=None,         port=None,         multi_az=None,
   engine_version=None,                   auto_minor_version_upgrade=None,
   license_model=None,          iops=None,         option_group_name=None,
   character_set_name=None,  publicly_accessible=None,   wait_status=None,
   tags=None,    copy_tags_to_snapshot=None,   region=None,   domain=None,
   key=None,             keyid=None,             monitoring_interval=None,
   monitoring_role_arn=None,                    domain_iam_role_name=None,
   promotion_tier=None, profile=None)
          Ensure RDS instance exists.

          name   Name of the RDS state definition.

          allocated_storage
                 The amount of storage  (in  gigabytes)  to  be  initially
                 allocated for the database instance.

          db_instance_class
                 The  compute  and  memory  capacity  of the Amazon RDS DB
                 instance.

          engine The name of the database  engine  to  be  used  for  this
                 instance.  Supported  engine  types  are: MySQL, mariadb,
                 oracle-se1,    oracle-se,    oracle-ee,     sqlserver-ee,
                 sqlserver-se,  sqlserver-ex,  sqlserver-web, postgres and
                 aurora. For  more  information,  please  see  the  engine
                 argument    in    the    Boto3   RDS   create_db_instance
                 documentation.

          master_username
                 The name of master user for the client DB instance.

          master_user_password
                 The password for the master database  user.  Can  be  any
                 printable ASCII character except "/", '"', or "@".

          db_name
                 The  meaning  of  this parameter differs according to the
                 database engine you use.  See the Boto3 RDS documentation
                 to    determine    the   appropriate   value   for   your
                 configuration.
                 https://boto3.readthedocs.io/en/latest/reference/services/rds.html#RDS.Client.create_db_instance

          storage_type
                 Specifies the storage type to be associated with  the  DB
                 instance.   Options  are  standard,  gp2  and io1. If you
                 specify io1, you must also include a value for  the  Iops
                 parameter.

          db_security_groups
                 A  list  of  DB security groups to associate with this DB
                 instance.

          vpc_security_group_ids
                 A list of EC2 VPC security groups to associate with  this
                 DB instance.

          availability_zone
                 The EC2 Availability Zone that the database instance will
                 be created in.

          db_subnet_group_name
                 A DB subnet group to associate with this DB instance.

          preferred_maintenance_window
                 The weekly  time  range  (in  UTC)  during  which  system
                 maintenance can occur.

          db_parameter_group_name
                 A DB parameter group to associate with this DB instance.

          db_cluster_identifier
                 If  the DB instance is a member of a DB cluster, contains
                 the name of the DB cluster that  the  DB  instance  is  a
                 member of.

          tde_credential_arn
                 The  ARN  from  the  Key Store with which the instance is
                 associated for TDE encryption.

          tde_credential_password
                 The password to use for TDE encryption if  an  encryption
                 key is not used.

          storage_encrypted
                 Specifies whether the DB instance is encrypted.

          kms_keyid
                 If  storage_encrypted is true, the KMS key identifier for
                 the encrypted DB instance.

          backup_retention_period
                 The number  of  days  for  which  automated  backups  are
                 retained.

          preferred_backup_window
                 The  daily  time range during which automated backups are
                 created if automated backups are enabled.

          port   The  port  number   on   which   the   database   accepts
                 connections.

          multi_az
                 Specifies  if  the  DB instance is a Multi-AZ deployment.
                 You cannot set  the  AvailabilityZone  parameter  if  the
                 MultiAZ parameter is set to true.

          engine_version
                 The version number of the database engine to use.

          auto_minor_version_upgrade
                 Indicates  that  minor  engine  upgrades  will be applied
                 automatically to the DB instance during  the  maintenance
                 window.

          license_model
                 License model information for this DB instance.

          iops   The  amount  of Provisioned IOPS (input/output operations
                 per  second)  to  be  initially  allocated  for  the   DB
                 instance.

          option_group_name
                 Indicates  that the DB instance should be associated with
                 the specified option group.

          character_set_name
                 For supported engines, indicates  that  the  DB  instance
                 should be associated with the specified CharacterSet.

          publicly_accessible
                 Specifies  the accessibility options for the DB instance.
                 A value of true  specifies  an  Internet-facing  instance
                 with  a publicly resolvable DNS name, which resolves to a
                 public IP address. A value of false specifies an internal
                 instance  with  a  DNS name that resolves to a private IP
                 address.

          wait_status
                 Wait for the RDS  instance  to  reach  a  desired  status
                 before  finishing the state. Available states: available,
                 modifying, backing-up

          tags   A list of tags.

          copy_tags_to_snapshot
                 Specifies whether tags are copied from the DB instance to
                 snapshots of the DB instance.

          region Region to connect to.

          domain The identifier of the Active Directory Domain.

          key    AWS secret key to be used.

          keyid  AWS access key to be used.

          monitoring_interval
                 The  interval,  in  seconds, between points when Enhanced
                 Monitoring metrics are collected for the DB instance.

          monitoring_role_arn
                 The ARN for  the  IAM  role  that  permits  RDS  to  send
                 Enhanced Monitoring metrics to CloudWatch Logs.

          domain_iam_role_name
                 Specify  the  name of the IAM role to be used when making
                 API calls to the Directory Service.

          promotion_tier
                 A value that specifies  the  order  in  which  an  Aurora
                 Replica  is  promoted  to  the  primary  instance after a
                 failure  of  the  existing  primary  instance.  For  more
                 information, see Fault Tolerance for an Aurora DB Cluster
                 .

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_rds.replica_present(name,                      source,
   db_instance_class=None,       availability_zone=None,        port=None,
   auto_minor_version_upgrade=None,   iops=None,   option_group_name=None,
   publicly_accessible=None, tags=None, region=None, key=None, keyid=None,
   profile=None, db_parameter_group_name=None)
          Ensure RDS replica exists.

             Ensure myrds replica RDS exists:
               boto_rds.create_replica:
                 - name: myreplica
                 - source: mydb

   salt.states.boto_rds.subnet_group_present(name,            description,
   subnet_ids=None, subnet_names=None, tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure DB subnet group exists.

          name   The name for the DB subnet group. This value is stored as
                 a lowercase string.

          subnet_ids
                 A list of the EC2 Subnet IDs for  the  DB  subnet  group.
                 Either subnet_ids or subnet_names must be provided.

          subnet_names
                 A  list  of The EC2 Subnet names for the DB subnet group.
                 Either subnet_ids or subnet_names must be provided.

          description
                 Subnet group description.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_route53
   Manage Route53 records

   New in version 2014.7.0.

   Create  and  delete  Route53 records. Be aware that this interacts with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit route53 credentials but can  also  utilize
   IAM  roles  assigned to the instance through Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      route53.keyid: GKTADJGHEIQSXMKKRBJ08H
      route53.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
        keyid: GKTADJGHEIQSXMKKRBJ08H
        key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
        region: us-east-1

      mycnamerecord:
        boto_route53.present:
          - name: test.example.com.
          - value: my-elb.us-east-1.elb.amazonaws.com.
          - zone: example.com.
          - ttl: 60
          - record_type: CNAME
          - region: us-east-1
          - keyid: GKTADJGHEIQSXMKKRBJ08H
          - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars
      myarecord:
        boto_route53.present:
          - name: test.example.com.
          - value: 1.1.1.1
          - zone: example.com.
          - ttl: 60
          - record_type: A
          - region: us-east-1
          - profile: myprofile

      # Passing in a profile
      myarecord:
        boto_route53.present:
          - name: test.example.com.
          - value: 1.1.1.1
          - zone: example.com.
          - ttl: 60
          - record_type: A
          - region: us-east-1
          - profile:
              keyid: GKTADJGHEIQSXMKKRBJ08H
              key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_route53.absent(name,        zone,         record_type,
   identifier=None,   region=None,   key=None,  keyid=None,  profile=None,
   wait_for_sync=True, split_dns=False, private_zone=False)
          Ensure the Route53 record is deleted.

          name   Name of the record.

          zone   The zone to delete the record from.

          record_type
                 The record type (A, NS, MX, TXT, etc.)

          identifier
                 An identifier to match for deletion.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          wait_for_sync
                 Wait for an INSYNC change status from Route53.

          split_dns
                 Route53  supports  a public and private DNS zone with the
                 same names.

          private_zone
                 If using split_dns, specify if this is the private zone.

   salt.states.boto_route53.hosted_zone_absent(name,     domain_name=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure the Route53 Hostes Zone described is absent

          name   The name of the state definition.

          domain_name
                 The  FQDN  (including  final period) of the zone you wish
                 absent.  If not provided, the value of name will be used.

   salt.states.boto_route53.hosted_zone_present(name,    domain_name=None,
   private_zone=False,     comment='',     vpc_id=None,     vpc_name=None,
   vpc_region=None, region=None, key=None, keyid=None, profile=None)
          Ensure a hosted zone exists with  the  given  attributes.   Note
          that  most things cannot be modified once a zone is created - it
          must be deleted and re-spun to update these attributes:

             * private_zone (AWS API limitation).

             *

               comment (the appropriate call exists in the AWS API and  in
               boto3, but
                      has not, as of this writing, been added to boto2).

             * vpc_id  (same story - we really need to rewrite this module
               with boto3)

             * vpc_name (really just a pointer to vpc_id anyway).

             * vpc_region (again, supported in boto3 but not boto2).

          name   The name of the state definition.  This will be  used  as
                 the 'caller_ref' param if/when creating the hosted zone.

          domain_name
                 The  name of the domain. This should be a fully-specified
                 domain, and should terminate with a period. This  is  the
                 name  you  have registered with your DNS registrar. It is
                 also the name you will delegate from  your  registrar  to
                 the  Amazon  Route  53  delegation  servers  returned  in
                 response to this request.  Defaults to the value of  name
                 if not provided.

          comment
                 Any comments you want to include about the hosted zone.

          private_zone
                 Set True if creating a private hosted zone.

          vpc_id When creating a private hosted zone, either the VPC ID or
                 VPC Name to associate with is required.   Exclusive  with
                 vpe_name.  Ignored if passed for a non-private zone.

          vpc_name
                 When creating a private hosted zone, either the VPC ID or
                 VPC Name to associate with is required.   Exclusive  with
                 vpe_id.  Ignored if passed for a non-private zone.

          vpc_region
                 When  creating  a  private hosted zone, the region of the
                 associated VPC is required.  If not provided,  an  effort
                 will  be made to determine it from vpc_id or vpc_name, if
                 possible.  If this  fails,  you'll  need  to  provide  an
                 explicit  value for this option.  Ignored if passed for a
                 non-private zone.

   salt.states.boto_route53.present(name,   value,   zone,    record_type,
   ttl=None,    identifier=None,    region=None,   key=None,   keyid=None,
   profile=None, wait_for_sync=True, split_dns=False, private_zone=False)
          Ensure the Route53 record is present.

          name   Name of the record.

          value

                 Value of the record. As a special case, you can pass in:
                        private:<Name   tag>   to   have   the    function
                        autodetermine  the private IP public:<Name tag> to
                        have the function autodetermine the public IP

          zone   The zone to create the record in.

          record_type
                 The record type (A, NS, MX, TXT, etc.)

          ttl    The time to live for the record.

          identifier
                 The unique identifier to use for this record.

          region The region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          wait_for_sync
                 Wait for an INSYNC change status from Route53.

          split_dns
                 Route53  supports  a public and private DNS zone with the
                 same names.

          private_zone
                 If using split_dns, specify if this is the private zone.

   salt.states.boto_s3_bucket module
   Manage S3 Buckets
   New in version 2016.3.0.

   Create and destroy S3  buckets.  Be  aware  that  this  interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto3, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              region: us-east-1

      Ensure bucket exists:
          boto_s3_bucket.present:
              - Bucket: mybucket
              - LocationConstraint: EU
              - ACL:
                - GrantRead: "uri=http://acs.amazonaws.com/groups/global/AllUsers"
              - CORSRules:
                - AllowedHeaders: []
                  AllowedMethods: ["GET"]
                  AllowedOrigins: ["*"]
                  ExposeHeaders: []
                  MaxAgeSeconds: 123
              - LifecycleConfiguration:
                - Expiration:
                    Days: 123
                  ID: "idstring"
                  Prefix: "prefixstring"
                  Status: "enabled",
                  ID: "lc1"
                  Transitions:
                    - Days: 123
                      StorageClass: "GLACIER"
                  NoncurrentVersionTransitions:
                    - NoncurrentDays: 123
                      StorageClass: "GLACIER"
                  NoncurrentVersionExpiration:
                    NoncurrentDays: 123
              - Logging:
                  TargetBucket: log_bucket
                  TargetPrefix: prefix
                  TargetGrants:
                    - Grantee:
                        DisplayName: "string"
                        EmailAddress: "string"
                        ID: "string"
                        Type: "AmazonCustomerByEmail"
                        URI: "string"
                      Permission: "READ"
              - NotificationConfiguration:
                  LambdaFunctionConfiguration:
                    - Id: "string"
                      LambdaFunctionArn: "string"
                      Events:
                        - "s3:ObjectCreated:*"
                      Filter:
                        Key:
                          FilterRules:
                            - Name: "prefix"
                              Value: "string"
              - Policy:
                  Version: "2012-10-17"
                  Statement:
                    - Sid: "String"
                      Effect: "Allow"
                      Principal:
                        AWS: "arn:aws:iam::133434421342:root"
                      Action: "s3:PutObject"
                      Resource: "arn:aws:s3:::my-bucket/*"
              - Replication:
                  Role: myrole
                  Rules:
                    - ID: "string"
                      Prefix: "string"
                      Status: "Enabled"
                      Destination:
                        Bucket: "arn:aws:s3:::my-bucket"
              - RequestPayment:
                  Payer: Requester
              - Tagging:
                  tag_name: tag_value
                  tag_name_2: tag_value
              - Versioning:
                  Status: "Enabled"
              - Website:
                  ErrorDocument:
                    Key: "error.html"
                  IndexDocument:
                    Suffix: "index.html"
                  RedirectAllRequestsTo:
                    Hostname: "string"
                    Protocol: "http"
                  RoutingRules:
                    - Condition:
                        HttpErrorCodeReturnedEquals: "string"
                        KeyPrefixEquals: "string"
                      Redirect:
                        HostName: "string"
                        HttpRedirectCode: "string"
                        Protocol: "http"
                        ReplaceKeyPrefixWith: "string"
                        ReplaceKeyWith: "string"
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_s3_bucket.absent(name,       Bucket,      Force=False,
   region=None, key=None, keyid=None, profile=None)
          Ensure bucket with passed properties is absent.

          name   The name of the state definition.

          Bucket Name of the bucket.

          Force  Empty the bucket first if necessary - Boolean.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_s3_bucket.present(name,                        Bucket,
   LocationConstraint=None,           ACL=None,            CORSRules=None,
   LifecycleConfiguration=None,                              Logging=None,
   NotificationConfiguration=None,     Policy=None,      Replication=None,
   RequestPayment=None,   Tagging=None,   Versioning=None,   Website=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure bucket exists.

          name   The name of the state definition

          Bucket Name of the bucket.

          LocationConstraint
                 'EU'|'eu-west-1'|'us-west-1'|'us-west-2'|'ap-southeast-1'|'ap-southeast-2'|'ap-northeast-1'|'sa-east-1'|'cn-north-1'|'eu-central-1'

          ACL    The  permissions  on  a bucket using access control lists
                 (ACL).

          CORSRules
                 The cors configuration for a bucket.

          LifecycleConfiguration
                 Lifecycle configuration for your bucket

          Logging
                 The logging  parameters  for  a  bucket  and  to  specify
                 permissions  for  who  can  view  and  modify the logging
                 parameters.

          NotificationConfiguration
                 notifications of specified events for a bucket

          Policy Policy on the bucket

          Replication
                 Replication rules. You can add as many  as  1,000  rules.
                 Total replication configuration size can be up to 2 MB

          RequestPayment
                 The  request  payment  configuration  for  a  bucket.  By
                 default, the bucket owner pays  for  downloads  from  the
                 bucket.  This  configuration parameter enables the bucket
                 owner (only) to specify that the  person  requesting  the
                 download will be charged for the download

          Tagging
                 A dictionary of tags that should be set on the bucket

          Versioning
                 The versioning state of the bucket

          Website
                 The website configuration of the bucket

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_secgroup
   Manage Security Groups
   New in version 2014.7.0.

   Create and destroy Security Groups. Be aware that this  interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This  module  accepts explicit EC2 credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      secgroup.keyid: GKTADJGHEIQSXMKKRBJ08H
      secgroup.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      Ensure mysecgroup exists:
          boto_secgroup.present:
              - name: mysecgroup
              - description: My security group
              - rules:
                  - ip_protocol: tcp
                    from_port: 80
                    to_port: 80
                    cidr_ip:
                      - 10.0.0.0/0
                      - 192.168.0.0/0
                  - ip_protocol: icmp
                    from_port: -1
                    to_port: -1
                    source_group_name: mysecgroup
              - rules_egress:
                  - ip_protocol: all
                    from_port: -1
                    to_port: -1
                    cidr_ip:
                      - 10.0.0.0/0
                      - 192.168.0.0/0
              - tags:
                  SomeTag: 'My Tag Value'
                  SomeOtherTag: 'Other Tag Value'
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars
      Ensure mysecgroup exists:
          boto_secgroup.present:
              - name: mysecgroup
              - description: My security group
              - profile: myprofile

      # Passing in a profile
      Ensure mysecgroup exists:
          boto_secgroup.present:
              - name: mysecgroup
              - description: My security group
              - profile:
                  keyid: GKTADJGHEIQSXMKKRBJ08H
                  key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                  region: us-east-1

   NOTE:
      When  using  the  profile parameter and region is set outside of the
      profile group, region is ignored and a default region will be used.

      If region is missing from the profile data set,  us-east-1  will  be
      used as the default region.

   salt.states.boto_secgroup.absent(name,    vpc_id=None,   vpc_name=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure a security group with the specified name does not exist.

          name   Name of the security group.

          vpc_id The ID of the VPC to remove the security group  from,  if
                 any. Exclusive with vpc_name.

          vpc_name
                 The name of the VPC to remove the security group from, if
                 any. Exclusive with vpc_name.

                 New in version 2016.3.0.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

                 New in version 2016.3.0.

   salt.states.boto_secgroup.present(name,    description,    vpc_id=None,
   vpc_name=None, rules=None,  rules_egress=None,  region=None,  key=None,
   keyid=None, profile=None, tags=None)
          Ensure the security group exists with the specified rules.

          name   Name of the security group.

          description
                 A description of this security group.

          vpc_id The  ID  of  the  VPC to create the security group in, if
                 any. Exclusive with vpc_name.

          vpc_name
                 The name of the VPC to create the security group  in,  if
                 any. Exclusive with vpc_id.

                 New in version 2016.3.0.

                 New in version 2015.8.2.

          rules  A   list   of  ingress  rule  dicts.  If  not  specified,
                 rules=None, the ingress rules will be unmanaged.  If  set
                 to  an  empty  list,  [],  then all ingress rules will be
                 removed.

          rules_egress
                 A  list  of  egress  rule  dicts.   If   not   specified,
                 rules_egress=None, the egress rules will be unmanaged. If
                 set to an empty list, [], then all egress rules  will  be
                 removed.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains  a  dict  with  region,  key,  and
                 keyid.

          tags   List  of  key:value  pairs of tags to set on the security
                 group

                 New in version 2016.3.0.

   salt.states.boto_sns
   Manage SNS Topics

   Create and destroy SNS  topics.  Be  aware  that  this  interacts  with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This  module  accepts explicit AWS credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      sns.keyid: GKTADJGHEIQSXMKKRBJ08H
      sns.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      mytopic:
          boto_sns.present:
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      # Using a profile from pillars
      mytopic:
          boto_sns.present:
              - region: us-east-1
              - profile: mysnsprofile

      # Passing in a profile
      mytopic:
          boto_sns.present:
              - region: us-east-1
              - profile:
                  keyid: GKTADJGHEIQSXMKKRBJ08H
                  key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_sns.absent(name,  region=None,  key=None,  keyid=None,
   profile=None, unsubscribe=False)
          Ensure the named sns topic is deleted.

          name   Name of the SNS topic.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          unsubscribe
                 If  True,  unsubscribe  all subcriptions to the SNS topic
                 before deleting the SNS topic

                 New in version 2016.11.0.

   salt.states.boto_sns.present(name,   subscriptions=None,   region=None,
   key=None, keyid=None, profile=None)
          Ensure the SNS topic exists.

          name   Name of the SNS topic.

          subscriptions
                 List of SNS subscriptions.

                 Each  subscription  is  a  dictionary with a protocol and
                 endpoint key:

                    [
                    {'protocol': 'https', 'endpoint': 'https://www.example.com/sns-endpoint'},
                    {'protocol': 'sqs', 'endpoint': 'arn:aws:sqs:us-west-2:123456789012:MyQueue'}
                    ]

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_sqs
   Manage SQS Queues

   New in version 2014.7.0.

   Create  and  destroy  SQS  queues.  Be  aware  that this interacts with
   Amazon's services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This module accepts explicit SQS credentials but can also  utilize  IAM
   roles  assigned  to  the  instance  through  Instance Profiles. Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If  IAM  roles are not used you need to specify them either in a pillar
   file or in the minion's config file:

      sqs.keyid: GKTADJGHEIQSXMKKRBJ08H
      sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's also possible to specify key, keyid  and  region  via  a  profile,
   either  passed  in  as  a  dict, or as a string to pull from pillars or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      myqueue:
          boto_sqs.present:
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
              - attributes:
                  ReceiveMessageWaitTimeSeconds: 20

      # Using a profile from pillars
      myqueue:
          boto_sqs.present:
              - region: us-east-1
              - profile: mysqsprofile

      # Passing in a profile
      myqueue:
          boto_sqs.present:
              - region: us-east-1
              - profile:
                  keyid: GKTADJGHEIQSXMKKRBJ08H
                  key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   salt.states.boto_sqs.absent(name,  region=None,  key=None,  keyid=None,
   profile=None)
          Ensure the named sqs queue is deleted.

          name   Name of the SQS queue.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_sqs.present(name,    attributes=None,     region=None,
   key=None, keyid=None, profile=None)
          Ensure the SQS queue exists.

          name   Name of the SQS queue.

          attributes
                 A dict of key/value SQS attributes.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc
   Manage VPCs
   New in version 2015.8.0.

   Create and destroy VPCs. Be aware that  this  interacts  with  Amazon's
   services, and so may incur charges.

   This module uses boto, which can be installed via package, or pip.

   This  module  accepts explicit vpc credentials but can also utilize IAM
   roles assigned to  the  instance  through  Instance  Profiles.  Dynamic
   credentials are then automatically obtained from AWS API and no further
   configuration is necessary. More information available here.

   If IAM roles are not used you need to specify them either in  a  pillar
   file or in the minion's config file:

      vpc.keyid: GKTADJGHEIQSXMKKRBJ08H
      vpc.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   It's  also  possible  to  specify  key, keyid and region via a profile,
   either passed in as a dict, or as a string  to  pull  from  pillars  or
   minion config:

      myprofile:
          keyid: GKTADJGHEIQSXMKKRBJ08H
          key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
          region: us-east-1

      aws:
          region:
              us-east-1:
                  profile:
                      keyid: GKTADJGHEIQSXMKKRBJ08H
                      key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
                      region: us-east-1

      Ensure VPC exists:
          boto_vpc.present:
              - name: myvpc
              - cidr_block: 10.10.11.0/24
              - dns_hostnames: True
              - region: us-east-1
              - keyid: GKTADJGHEIQSXMKKRBJ08H
              - key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

      Ensure subnet exists:
          boto_vpc.subnet_present:
              - name: mysubnet
              - vpc_id: vpc-123456
              - cidr_block: 10.0.0.0/16
              - region: us-east-1
              - profile: myprofile

      {% set profile = salt['pillar.get']('aws:region:us-east-1:profile' ) %}
      Ensure internet gateway exists:
          boto_vpc.internet_gateway_present:
              - name: myigw
              - vpc_name: myvpc
              - profile: {{ profile }}

      Ensure route table exists:
          boto_vpc.route_table_present:
              - name: my_route_table
              - vpc_id: vpc-123456
              - routes:
                - destination_cidr_block: 0.0.0.0/0
                  instance_id: i-123456
              - subnet_names:
                - subnet1
                - subnet2
              - region: us-east-1
              - profile:
                  keyid: GKTADJGHEIQSXMKKRBJ08H
                  key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs

   New in version 2016.11.0.

   Request,  accept  and  delete  VPC  peering  connections.   VPC peering
   connections can be named allowing the name to be  used  throughout  the
   state  file.  Following  example  shows how to request and accept a VPC
   peering connection.

      accept the vpc peering connection:
        boto_vpc.accept_vpc_peering_connection:
          - conn_name: salt_vpc_peering
          - region: us-west-2
          - require:
            - boto_vpc: request a vpc peering connection

      request a vpc peering connection:
        boto_vpc.request_vpc_peering_connection:
          - requester_vpc_id: vpc-4a3d522e
          - peer_vpc_id: vpc-ae81e9ca
          - region: us-west-2
          - conn_name: salt_vpc_peering

   VPC peering connections need not be named. In this case the VPC peering
   connection ID should be used in the state file.

      accept the vpc peering connection:
        boto_vpc.accept_vpc_peering_connection:
          - conn_id: pcx-1873c371
          - region: us-west-2

   VPC peering connections can be deleted, as shown below.

      delete a named vpc peering connection:
        boto_vpc.delete_vpc_peering_connection:
          - conn_name: salt_vpc_peering

   Delete also accepts a VPC peering connection id.

      delete a vpc peering connection by id:
        boto_vpc.delete_vpc_peering_connection:
          - conn_id: pcx-1873c371

   salt.states.boto_vpc.absent(name,   tags=None,  region=None,  key=None,
   keyid=None, profile=None)
          Ensure VPC with passed properties is absent.

          name   Name of the VPC.

          tags   A list of tags. All tags must match.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.accept_vpc_peering_connection(name=None,
   conn_id=None,  conn_name=None,   region=None,   key=None,   keyid=None,
   profile=None)
          Accept  a  VPC  pending requested peering connection between two
          VPCs.

          name   Name of this state

          conn_id
                 The connection ID to accept.  Exclusive  with  conn_name.
                 String type.

          conn_name
                 The  name  of  the  VPC  peering  connection  to  accept.
                 Exclusive with conn_id. String type.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          New in version 2016.11.0.

          Example:

             boto_vpc.accept_vpc_peering_connection:
                 - conn_name: salt_peering_connection

             # usage with vpc peering connection id and region
             boto_vpc.accept_vpc_peering_connection:
                 - conn_id: pbx-1873d472
                 - region: us-west-2

   salt.states.boto_vpc.delete_vpc_peering_connection(name,  conn_id=None,
   conn_name=None, region=None, key=None, keyid=None, profile=None)

          name   Name of the state

          conn_id
                 ID of the peering connection to  delete.   Exlusive  with
                 conn_name.

          conn_name
                 The  name  of the peering connection to delete.  Exlusive
                 with conn_id.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          New in version 2016.11.0.

          Example:

             delete a vpc peering connection:
               boto_vpc.delete_vpc_peering_connection:
                 - region: us-west-2
                 - conn_id: pcx-4613b12e

          Connection  name  can  be specified (instead of ID).  Specifying
          both conn_name and conn_id will result in an error.

             delete a vpc peering connection:
               boto_vpc.delete_vpc_peering_connection:
                 - conn_name: salt_vpc_peering

   salt.states.boto_vpc.dhcp_options_absent(name=None,
   dhcp_options_id=None, region=None, key=None, keyid=None, profile=None)
          Ensure a set of DHCP options with the given settings exist.

          name   (string) Name of the DHCP options set.

          dhcp_options_id
                 (string) Id of the DHCP options set.

          region (string) Region to connect to.

          key    (string) Secret key to be used.

          keyid  (string) Access key to be used.

          profile
                 (various)  A dict with region, key and keyid, or a pillar
                 key (string) that contains a dict with  region,  key  and
                 keyid.

          New in version 2016.3.0.

   salt.states.boto_vpc.dhcp_options_present(name,   dhcp_options_id=None,
   vpc_name=None, vpc_id=None, domain_name=None, domain_name_servers=None,
   ntp_servers=None,   netbios_name_servers=None,  netbios_node_type=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Ensure a set of DHCP options  with  the  given  settings  exist.
          Note  that  the  current  implementation only SETS values during
          option set creation.  It is unable  to  update  option  sets  in
          place,  and  thus  merely  verifies the set exists via the given
          name and/or dhcp_options_id param.

          name   (string) Name of the DHCP options.

          vpc_name
                 (string) Name of a VPC to which  the  options  should  be
                 associated.  Either vpc_name or vpc_id must be provided.

          vpc_id (string)  Id  of  a  VPC  to  which the options should be
                 associated.  Either vpc_name or vpc_id must be provided.

          domain_name
                 (string) Domain name to be assiciated  with  this  option
                 set.

          domain_name_servers
                 (list of strings) The IP address(es) of up to four domain
                 name servers.

          ntp_servers
                 (list of strings)  The  IP  address(es)  of  up  to  four
                 desired NTP servers.

          netbios_name_servers
                 (list  of  strings)  The  IP  address(es)  of  up to four
                 NetBIOS name servers.

          netbios_node_type
                 (string) The NetBIOS node type (1, 2, 4, or 8).  For more
                 information  about the allowed values, see RFC 2132.  The
                 recommended is 2 at this time  (broadcast  and  multicast
                 are currently not supported).

          tags   (dict of key:value pairs) A set of tags to be added.

          region (string) Region to connect to.

          key    (string) Secret key to be used.

          keyid  (string) Access key to be used.

          profile
                 (various)  A dict with region, key and keyid, or a pillar
                 key (string) that contains a dict with  region,  key  and
                 keyid.

          New in version 2016.3.0.

   salt.states.boto_vpc.internet_gateway_absent(name,        detach=False,
   region=None, key=None, keyid=None, profile=None)
          Ensure the named internet gateway is absent.

          name   Name of the internet gateway.

          detach First  detach  the  internet  gateway  from  a  VPC,   if
                 attached.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.internet_gateway_present(name,      vpc_name=None,
   vpc_id=None,     tags=None,    region=None,    key=None,    keyid=None,
   profile=None)
          Ensure an internet gateway exists.

          name   Name of the internet gateway.

          vpc_name
                 Name of the VPC to which the internet gateway  should  be
                 attached.

          vpc_id Id  of  the  VPC  to which the internet_gateway should be
                 attached.   Only  one  of  vpc_name  or  vpc_id  may   be
                 provided.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.nat_gateway_absent(name=None,    subnet_name=None,
   subnet_id=None,   region=None,   key=None,   keyid=None,  profile=None,
   wait_for_delete_retries=0)
          Ensure the nat gateway in the named subnet is absent.

          This function requires boto3.

          New in version 2016.11.0.

          name   Name of the state.

          subnet_name
                 Name of the subnet within which the  nat  gateway  should
                 exist

          subnet_id
                 Id  of  the  subnet  within  which the nat gateway should
                 exist.  Either subnet_name or subnet_id must be provided.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          wait_for_delete_retries
                 NAT  gateway  may take some time to be go into deleted or
                 failed state.  During the  deletion  process,  subsequent
                 release   of  elastic  IPs  may  fail;  this  state  will
                 automatically retry this number of times  to  ensure  the
                 NAT   gateway  is  in  deleted  or  failed  state  before
                 proceeding.   Default  is   set   to   0   for   backward
                 compatibility.

   salt.states.boto_vpc.nat_gateway_present(name,        subnet_name=None,
   subnet_id=None, region=None, key=None, keyid=None, profile=None)
          Ensure a nat gateway exists within the specified subnet

          This function requires boto3.

          New in version 2016.11.0.

          Example:

             boto_vpc.nat_gateway_present:
                 - subnet_name: my-subnet

          name   Name of the state

          subnet_name
                 Name of the subnet within which the  nat  gateway  should
                 exist

          subnet_id
                 Id  of  the  subnet  within  which the nat gateway should
                 exist.  Either subnet_name or subnet_id must be provided.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.present(name,  cidr_block,  instance_tenancy=None,
   dns_support=None, dns_hostnames=None, tags=None, region=None, key=None,
   keyid=None, profile=None)
          Ensure VPC exists.

          name   Name of the VPC.

          cidr_block
                 The   range   of   IPs   in  CIDR  format,  for  example:
                 10.0.0.0/24. Block size  must  be  between  /16  and  /28
                 netmask.

          instance_tenancy
                 Instances  launched  in  this VPC will be ingle-tenant or
                 dedicated hardware.

          dns_support
                 Indicates whether the DNS resolution is supported for the
                 VPC.

          dns_hostnames
                 Indicates  whether  the instances launched in the VPC get
                 DNS hostnames.

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.request_vpc_peering_connection(name,
   requester_vpc_id=None,    requester_vpc_name=None,    peer_vpc_id=None,
   peer_vpc_name=None,  conn_name=None,  peer_owner_id=None,  region=None,
   key=None, keyid=None, profile=None)

          name   Name of the state

          requester_vpc_id
                 ID   of    the    requesting    VPC.    Exclusive    with
                 requester_vpc_name. String type.

          requester_vpc_name
                 Name   tag   of   the  requesting  VPC.   Exclusive  with
                 requester_vpc_id.  String type.

          peer_vpc_id
                 ID of the VPC tp crete VPC peering connection with.  This
                 can   be   a  VPC  in  another  account.  Exclusive  with
                 peer_vpc_name. String type.

          peer_vpc_name
                 Name tag of the VPC tp crete VPC peering connection with.
                 This  can  only be a VPC the same account. Exclusive with
                 peer_vpc_id.  String type.

          conn_name
                 The  (optional)  name  to  use  for  this   VPC   peering
                 connection. String type.

          peer_owner_id
                 ID  of  the  owner  of the peer VPC. String type. If this
                 isn't supplied AWS uses your  account  ID.   Required  if
                 peering to a different account.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

          New in version 2016.11.0.

          Example:

             request a vpc peering connection:
               boto_vpc.request_vpc_peering_connection:
                 - requester_vpc_id: vpc-4b3522e
                 - peer_vpc_id: vpc-ae83f9ca
                 - conn_name: salt_peering_connection

   salt.states.boto_vpc.route_table_absent(name,  region=None,   key=None,
   keyid=None, profile=None)
          Ensure the named route table is absent.

          name   Name of the route table.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.route_table_present(name,           vpc_name=None,
   vpc_id=None,     routes=None,    subnet_ids=None,    subnet_names=None,
   tags=None, region=None, key=None, keyid=None, profile=None)
          Ensure route table with routes exists and  is  associated  to  a
          VPC.

          This function requires boto3 to be installed if nat gatewyas are
          specified.

          Example:

             boto_vpc.route_table_present:
                 - name: my_route_table
                 - vpc_id: vpc-123456
                 - routes:
                   - destination_cidr_block: 0.0.0.0/0
                     internet_gateway_name: InternetGateway
                   - destination_cidr_block: 10.10.11.0/24
                     instance_id: i-123456
                   - destination_cidr_block: 10.10.12.0/24
                     interface_id: eni-123456
                   - destination_cidr_block: 10.10.13.0/24
                     instance_name: mygatewayserver
                 - subnet_names:
                   - subnet1
                   - subnet2

          name   Name of the route table.

          vpc_name
                 Name of the VPC with which  the  route  table  should  be
                 associated.

          vpc_id Id  of  the  VPC  with  which  the  route table should be
                 associated.  Either vpc_name or vpc_id must be provided.

          routes A list of routes.  Each route has a cidr and a target.

          subnet_ids
                 A list of subnet ids to associate

          subnet_names
                 A list of subnet names to associate

          tags   A list of tags.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.subnet_absent(name=None,           subnet_id=None,
   region=None, key=None, keyid=None, profile=None)
          Ensure subnet with passed properties is absent.

          name   Name of the subnet.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.subnet_present(name,   cidr_block,  vpc_name=None,
   vpc_id=None, availability_zone=None, tags=None, region=None,  key=None,
   keyid=None, profile=None, route_table_id=None, route_table_name=None)
          Ensure a subnet exists.

          name   Name of the subnet.

          cidr_block
                 The  range  if  IPs  for  the subnet, in CIDR format. For
                 example: 10.0.0.0/24. Block size must be between /16  and
                 /28 netmask.

          vpc_name
                 Name  of  the  VPC  in which the subnet should be placed.
                 Either vpc_name or vpc_id must be provided.

          vpc_id Id of the VPC in  which  the  subnet  should  be  placed.
                 Either vpc_name or vpc_id must be provided.

          availability_zone
                 AZ in which the subnet should be placed.

          tags   A list of tags.

          route_table_id
                 A route table ID to explicitly associate the subnet with.
                 If   both   route_table_id   and   route_table_name   are
                 specified, route_table_id will take precedence.

                 New in version 2016.11.0.

          route_table_name
                 A  route  table  name  to explicitly associate the subnet
                 with.  If both route_table_id  and  route_table_name  are
                 specified, route_table_id will take precedence.

                 New in version 2016.11.0.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A  dict  with  region,  key  and  keyid,  or a pillar key
                 (string) that contains a dict with region, key and keyid.

   salt.states.boto_vpc.vpc_peering_connection_present(name,
   requester_vpc_id=None,    requester_vpc_name=None,    peer_vpc_id=None,
   peer_vpc_name=None,  conn_name=None,  peer_owner_id=None,  region=None,
   key=None, keyid=None, profile=None)

          name   Name of the state

          requester_vpc_id
                 ID    of    the    requesting    VPC.    Exclusive   with
                 requester_vpc_name.

          requester_vpc_name
                 Name  tag  of  the  requesting   VPC.    Exclusive   with
                 requester_vpc_id.

          peer_vpc_id
                 ID  of the VPC tp crete VPC peering connection with. This
                 can  be  a  VPC  in  another  account.   Exclusive   with
                 peer_vpc_name.

          peer_vpc_name
                 Name tag of the VPC tp crete VPC peering connection with.
                 This can  only  be  a  VPC  in  the  same  account,  else
                 resolving  it  into  a  vpc ID will fail.  Exclusive with
                 peer_vpc_id.

          conn_name
                 The name to use for this VPC peering connection.

          peer_owner_id
                 ID of the owner of the peer VPC. Defaults to your account
                 ID,  so  a  value  is required if peering with a VPC in a
                 different account.

          region Region to connect to.

          key    Secret key to be used.

          keyid  Access key to be used.

          profile
                 A dict with region,  key  and  keyid,  or  a  pillar  key
                 (string) that contains a dict with region, key and keyid.

          New in version 2016.11.0.

          Example:

             ensure peering twixt local vpc and the other guys:
               boto_vpc.vpc_peering_connection_present:
                 - requester_vpc_name: my_local_vpc
                 - peer_vpc_name: some_other_guys_vpc
                 - conn_name: peering_from_here_to_there
                 - peer_owner_id: 012345654321

   salt.states.bower
   Installation of Bower Packages
   These states manage the installed packages using Bower.  Note that npm,
   git and bower must be installed for these states to  be  available,  so
   bower  states should include requisites to pkg.installed states for the
   packages which provide npm and git (simply npm and git in most  cases),
   and npm.installed state for the package which provides bower.

   Example:

      npm:
        pkg.installed
      git:
        pkg.installed
      bower:
        npm.installed
        require:
          - pkg: npm
          - pkg: git

      underscore:
        bower.installed:
          - dir: /path/to/project
          - require:
            - npm: bower

   salt.states.bower.bootstrap(name, user=None)
          Bootstraps a frontend distribution.

          Will execute 'bower install' on the specified directory.

          user   The user to run Bower with

   salt.states.bower.installed(name, dir, pkgs=None, user=None, env=None)
          Verify that the given package is installed and is at the correct
          version (if specified).

             underscore:
               bower.installed:
                 - dir: /path/to/project
                 - user: someuser

             jquery#2.0:
               bower.installed:
                 - dir: /path/to/project

          name   The package to install

          dir    The target directory in which to install the package

          pkgs   A list  of  packages  to  install  with  a  single  Bower
                 invocation; specifying this argument will ignore the name
                 argument

          user   The user to run Bower with

          env    A list of  environment  variables  to  be  set  prior  to
                 execution.  The format is the same as the cmd.run.  state
                 function.

   salt.states.bower.removed(name, dir, user=None)
          Verify that the given package is not installed.

          dir    The target directory in which to install the package

          user   The user to run Bower with

   salt.states.cabal
   Installation of Cabal Packages
   New in version 2015.8.0.

   These states manage the installed packages  for  Haskell  using  cabal.
   Note  that  cabal-install  must  be  installed  for  these states to be
   available,  so  cabal  states  should  include   a   requisite   to   a
   pkg.installed state for the package which provides cabal (cabal-install
   in case of Debian based distributions). Example:

      .. code-block:: yaml

      cabal-install:
             pkg.installed

      ShellCheck:

             cabal.installed:

                    * require: - pkg: cabal-install

   salt.states.cabal.installed(name,         pkgs=None,         user=None,
   install_global=False, env=None)
          Verify that the given package is installed and is at the correct
          version (if specified).

             ShellCheck-0.3.5:
               cabal:
                 - installed:

          name   The package to install

          user   The user to run cabal install with

          install_global
                 Install package globally instead of locally

          env    A list of  environment  variables  to  be  set  prior  to
                 execution.  The format is the same as the cmd.run.  state
                 function.

   salt.states.cabal.removed(name, user=None, env=None)
          Verify that given package is not installed.

   salt.states.chef
   Execute Chef client runs
   Run chef-client or chef-solo

      my-chef-run:
        chef.client:
          - override-runlist: 'demo1,demo2'
          - server: 'https://chef.domain.com'

      default-chef-run:
        chef.client: []

      my-solo-run:
        chef.solo:
          - environment: dev

   salt.states.chef.client(name, **kwargs)

          name   Unique identifier for the state. Does not affect the Chef
                 run.

          server The chef server URL

          client_key
                 Set the client key file location

          config The configuration file to use

          config-file-jail
                 Directory  under  which  config  files  are allowed to be
                 loaded (no client.rb or knife.rb outside this  path  will
                 be loaded).

          environment
                 Set the Chef Environment on the node

          group  Group to set privilege to

          json-attributes
                 Load attributes from a JSON file or URL

          localmode
                 Point chef-client at local repository if True

          log_level
                 Set the log level (debug, info, warn, error, fatal)

          logfile
                 Set the log file location

          node-name
                 The node name for this client

          override-runlist
                 Replace  current  run  list  with  specified  items for a
                 single run

          pid    Set    the    PID    file    location,    defaults     to
                 /tmp/chef-client.pid

          run-lock-timeout
                 Set  maximum  duration  to wait for another client run to
                 finish, default is indefinitely.

          runlist
                 Permanently replace current run list with specified items

          user   User to set privilege to

          validation_key
                 Set  the  validation  key   file   location,   used   for
                 registering new clients

   salt.states.chef.solo(name, **kwargs)

          name   Unique identifier for the state. Does not affect the Chef
                 run.

          config The configuration file to use

          environment
                 Set the Chef Environment on the node

          group  Group to set privilege to

          json-attributes
                 Load attributes from a JSON file or URL

          log_level
                 Set the log level (debug, info, warn, error, fatal)

          logfile
                 Set the log file location

          node-name
                 The node name for this client

          override-runlist
                 Replace current run  list  with  specified  items  for  a
                 single run

          recipe-url
                 Pull  down  a remote gzipped tarball of recipes and untar
                 it to the cookbook cache

          run-lock-timeout
                 Set maximum duration to wait for another  client  run  to
                 finish, default is indefinitely.

          user   User to set privilege to

   salt.states.chocolatey module
   Manage Chocolatey package installs

   salt.states.chocolatey.install(*args, **kwargs)
          Deprecated,  please  use  'installed'.  This  function  will  be
          removed in Salt Nitrogen.

   salt.states.chocolatey.installed(name,    version=None,    source=None,
   force=False,           pre_versions=False,           install_args=None,
   override_args=False, force_x86=False, package_args=None)
          Installs a package if not already installed

          name   The name of the package to be installed.

          version
                 Install a specific version of the  package.  Defaults  to
                 latest version.

          source Chocolatey  repository  (directory,  share or remote URL,
                 feed). Defaults to the official Chocolatey feed.

          force  Reinstall the current version  of  an  existing  package.
                 Default is false.

          pre_versions
                 Include pre-release packages. Default is False.

          install_args
                 A  list  of  install  arguments  you  want to pass to the
                 installation process i.e product key or feature list

          override_args
                 Set to true if you want to override the original  install
                 arguments  (  for the native installer)in the package and
                 use your own.  When this is  set  to  False  install_args
                 will be appended to the end of the default arguments

          force_x86
                 Force   x86  (32bit)  installation  on  64  bit  systems.
                 Defaults to false.

          package_args
                 A list of arguments you want to pass to the package

             Installsomepackage:
               chocolatey.installed:
                 - name: packagename
                 - version: '12.04'
                 - source: 'mychocolatey/source'
                 - force: True

   salt.states.chocolatey.uninstall(*args, **kwargs)
          Deprecated, please use  'uninstalled'.  This  function  will  be
          removed in Salt Nitrogen.

   salt.states.chocolatey.uninstalled(name,                  version=None,
   uninstall_args=None, override_args=False)
          Uninstalls a package

          name   The name of the package to be uninstalled

          version
                 Uninstalls a specific version of the package. Defaults to
                 latest version installed.

          uninstall_args
                 A  list  of  uninstall  arguments you want to pass to the
                 uninstallation process i.e product key or feature list

          override_args
                 Set  to  true  if  you  want  to  override  the  original
                 uninstall  arguments  ( for the native uninstaller)in the
                 package and use your own.  When  this  is  set  to  False
                 uninstall_args will be appended to the end of the default
                 arguments

   salt.states.chronos_job module
   Configure Chronos jobs via a salt proxy.

      my_job:
        chronos_job.config:
          - config:
              schedule: "R//PT2S"
              command: "echo 'hi'"
              owner: "[email protected]"

   New in version 2015.8.2.

   salt.states.chronos_job.absent(name)
          Ensure that the chronos job with the given name is not present.

          Parameters
                 name -- The app name

          Returns
                 A standard Salt changes dictionary

   salt.states.chronos_job.config(name, config)
          Ensure that the chronos job with the given name is  present  and
          is configured to match the given config values.

          Parameters

                 * name -- The job name

                 * config -- The configuration to apply (dict)

          Returns
                 A standard Salt changes dictionary

   salt.states.cloud
   Using states instead of maps to deploy clouds
   New in version 2014.1.0.

   Use this minion to spin up a cloud instance:

      my-ec2-instance:
        cloud.profile:
          my-ec2-config

   salt.states.cloud.absent(name, onlyif=None, unless=None)
          Ensure that no instances with the specified names exist.

          CAUTION:  This  is  a  destructive  state, which will search all
          configured cloud providers for the named instance,  and  destroy
          it.

          name   The name of the instance to destroy

          onlyif Do run the state only if is unless succeed

          unless Do not run the state at least unless succeed

   salt.states.cloud.present(name,       cloud_provider,      onlyif=None,
   unless=None, opts=None, **kwargs)
          Spin up a single instance on a cloud provider, using salt-cloud.
          This  state  does  not take a profile argument; rather, it takes
          the arguments that would normally be configured as part  of  the
          state.

          Note  that  while  this  function  does  take  any configuration
          argument that would normally be used to create an  instance,  it
          will  not  verify  the  state  of  any  of those arguments on an
          existing instance. Stateful properties of an instance should  be
          configured using their own individual state (i.e., cloud.tagged,
          cloud.untagged, etc).

          name   The name of the instance to create

          cloud_provider
                 The name of the cloud provider to use

          onlyif Do run the state only if is unless succeed

          unless Do not run the state at least unless succeed

          opts   Any extra opts that need to be used

   salt.states.cloud.profile(name,  profile,   onlyif=None,   unless=None,
   opts=None, **kwargs)
          Create a single instance on a cloud provider, using a salt-cloud
          profile.

          Note  that  while  profiles  used  this  function  do  take  any
          configuration  argument that would normally be used to create an
          instance using a profile, this state will not verify  the  state
          of  any  of  those  arguments  on an existing instance. Stateful
          properties of an instance should be configured using  their  own
          individual state (i.e., cloud.tagged, cloud.untagged, etc).

          name   The name of the instance to create

          profile
                 The name of the cloud profile to use

          onlyif Do run the state only if is unless succeed

          unless Do not run the state at least unless succeed

          kwargs Any profile override or addition

          opts   Any extra opts that need to be used

   salt.states.cloud.volume_absent(name, provider=None, **kwargs)
          Check that a block volume exists.

   salt.states.cloud.volume_attached(name,   server_name,   provider=None,
   **kwargs)
          Check if a block volume is attached.

   salt.states.cloud.volume_detached(name,               server_name=None,
   provider=None, **kwargs)
          Check if a block volume is attached.

          Returns True if server or Volume do not exist.

   salt.states.cloud.volume_present(name, provider=None, **kwargs)
          Check that a block volume exists.

   salt.states.cmd
   Execution of arbitrary commands
   The cmd state module manages the enforcement of executed commands, this
   state can tell a command to run under certain circumstances.

   A simple example to execute a command:

      # Store the current date in a file
      date > /tmp/salt-run:
        cmd.run

   Only run if another execution failed, in this case truncate  syslog  if
   there is no disk space:

      > /var/log/messages:
        cmd.run:
          - unless: echo 'foo' > /tmp/.test && rm -f /tmp/.test

   Only  run if the file specified by creates does not exist, in this case
   touch /tmp/foo if it does not exist:

      touch /tmp/foo:
        cmd.run:
          - creates: /tmp/foo

   creates also accepts a list of files:

      echo 'foo' | tee /tmp/bar > /tmp/baz:
        cmd.run:
          - creates:
            - /tmp/bar
            - /tmp/baz

   NOTE:
      The creates option was added to version 2014.7.0

   Salt determines whether the cmd state is successfully enforced based on
   the  exit  code  returned by the command. If the command returns a zero
   exit code,  then  salt  determines  that  the  state  was  successfully
   enforced.  If  the  script  returns  a  non-zero  exit  code, then salt
   determines that it failed to successfully  enforce  the  state.   If  a
   command  returns  a  non-zero exit code but you wish to treat this as a
   success, then you must place the command in a script and explicitly set
   the exit code of the script to zero.

   Please note that the success or failure of the state is not affected by
   whether a state change occurred nor the stateful argument.

   When executing a command or script, the state (i.e., changed or not) of
   the  command  is unknown to Salt's state system. Therefore, by default,
   the cmd state assumes that any command execution results in  a  changed
   state.

   This  means  that  if  a cmd state is watched by another state then the
   state that's watching will always be executed due to the changed  state
   in the cmd state.

   Using the Stateful Argument
   Many  state  functions  in  this  module  now  also  accept  a stateful
   argument.  If stateful is specified to be true then it is assumed  that
   the  command  or script will determine its own state and communicate it
   back by following a simple protocol described below:

   1. If there's nothing in the stdout of  the  command,  then  assume  no
      changes.  Otherwise,  the  stdout must be either in JSON or its last
      non-empty line must be a string  of  key=value  pairs  delimited  by
      spaces (no spaces on either side of =).

   2. If  it's  JSON  then  it  must  be a JSON object (e.g., {}). If it's
      key=value  pairs  then  quoting  may  be  used  to  include  spaces.
      (Python's shlex module is used to parse the key=value string)

      Two special keys or attributes are recognized in the output:

         changed: bool (i.e., 'yes', 'no', 'true', 'false', case-insensitive)
         comment: str  (i.e., any string)

      So,  only  if  changed is True then assume the command execution has
      changed the state, and any other key values  or  attributes  in  the
      output will be set as part of the changes.

   3. If  there's  a  comment  then  it will be used as the comment of the
      state.

      Here's an example of how one might write a shell script for use with
      a stateful command:

         #!/bin/bash
         #
         echo "Working hard..."

         # writing the state line
         echo  # an empty line here so the next line will be the last.
         echo "changed=yes comment='something has changed' whatever=123"

      And an example SLS file using this module:

         Run myscript:
           cmd.run:
             - name: /path/to/myscript
             - cwd: /
             - stateful: True

         Run only if myscript changed something:
           cmd.run:
             - name: echo hello
             - cwd: /
             - onchanges:
                 - cmd: Run myscript

      Note  that if the second cmd.run state also specifies stateful: True
      it can then be watched by some other states as well.

   4. The stateful argument can optionally include a test_name parameter.

      This is used to specify a command to run in test mode.  This command
      should  return  stateful  data for changes that would be made by the
      command in the name parameter.

      New in version 2015.2.0.

         Run myscript:
           cmd.run:
             - name: /path/to/myscript
             - cwd: /
             - stateful:
               - test_name: /path/to/myscript test

         Run masterscript:
           cmd.script:
             - name: masterscript
             - source: salt://path/to/masterscript
             - cwd: /
             - stateful:
               - test_name: masterscript test

   Should I use cmd.run or cmd.wait?
   NOTE:
      Use cmd.run together with onchanges instead of cmd.wait.

   These two states are often confused. The important  thing  to  remember
   about  them  is that cmd.run states are run each time the SLS file that
   contains them is applied. If it is more desirable  to  have  a  command
   that  only runs after some other state changes, then cmd.wait does just
   that. cmd.wait is designed to watch other states, and is executed  when
   the state it is watching changes. Example:

      /usr/local/bin/postinstall.sh:
        cmd.wait:
          - watch:
            - pkg: mycustompkg
        file.managed:
          - source: salt://utils/scripts/postinstall.sh

      mycustompkg:
        pkg.installed:
          - require:
            - file: /usr/local/bin/postinstall.sh

   cmd.wait  itself  does not do anything; all functionality is inside its
   mod_watch function, which is called by watch on changes.

   cmd.wait will be deprecated in future due to the confusion  it  causes.
   The  preferred  format is using the onchanges Requisite, which works on
   cmd.run as well as on any other state. The example would then  look  as
   follows:

      /usr/local/bin/postinstall.sh:
        cmd.run:
          - onchanges:
            - pkg: mycustompkg
        file.managed:
          - source: salt://utils/scripts/postinstall.sh

      mycustompkg:
        pkg.installed:
          - require:
            - file: /usr/local/bin/postinstall.sh

   How do I create an environment from a pillar map?
   The  map  that  comes from a pillar can be directly consumed by the env
   option!  To use it, one may pass it like this. Example:

      printenv:
        cmd.run:
          - env: {{ salt['pillar.get']('example:key', {}) }}

   salt.states.cmd.call(name,  func,   args=(),   kws=None,   onlyif=None,
   unless=None,   creates=None,   output_loglevel='debug',   use_vt=False,
   **kwargs)
          Invoke a pre-defined Python function with arguments specified in
          the  state  declaration.  This  function  is  mainly used by the
          salt.renderers.pydsl renderer.

          The interpretation of onlyif and unless arguments are  identical
          to  those  of  cmd.run, and all other arguments(cwd, runas, ...)
          allowed by cmd.run are allowed here, except that  their  effects
          apply only to the commands specified in onlyif and unless rather
          than to the function to be invoked.

          In addition, the stateful argument has no effects here.

          The return value of the invoked function will be interpreted  as
          follows.

          If it's a dictionary then it will be passed through to the state
          system, which expects it to have the usual structure returned by
          any salt state function.

          Otherwise,  the  return  value  (denoted  as  result in the code
          below) is expected to be a JSON serializable  object,  and  this
          dictionary is returned:

             {
                 'name': name
                 'changes': {'retval': result},
                 'result': True if result is None else bool(result),
                 'comment': result if isinstance(result, string_types) else ''
             }

   salt.states.cmd.mod_run_check(cmd_kwargs, onlyif, unless, creates)
          Execute the onlyif and unless logic.  Return a result dict if: *
          onlyif failed (onlyif != 0) * unless  succeeded  (unless  ==  0)
          else return True

   salt.states.cmd.mod_watch(name, **kwargs)
          Execute a cmd function based on a watch call

   salt.states.cmd.run(name,   onlyif=None,   unless=None,   creates=None,
   cwd=None, runas=None, shell=None, env=None, stateful=False, umask=None,
   output_loglevel='debug',           quiet=False,           timeout=None,
   ignore_timeout=False, use_vt=False, **kwargs)
          Run a command if certain circumstances are met.  Use cmd.wait if
          you want to use the watch requisite.

          name   The  command  to  execute, remember that the command will
                 execute with the path and permissions of the salt-minion.

          onlyif A command to run as a check, run the named  command  only
                 if the command passed to the onlyif option returns true

          unless A  command  to run as a check, only run the named command
                 if the command passed to the unless option returns false

          cwd    The current working directory to execute the command  in,
                 defaults to /root

          runas  The user name to run the command as

          shell  The  shell  to  use  for execution, defaults to the shell
                 grain

          env    A list of  environment  variables  to  be  set  prior  to
                 execution.  Example:

                    script-foo:
                      cmd.run:
                        - env:
                          - BATCH: 'yes'

                 WARNING:
                    The  above  illustrates  a common PyYAML pitfall, that
                    yes, no, on, off, true, and false are  all  loaded  as
                    boolean True and False values, and must be enclosed in
                    quotes to be used as strings. More info on  this  (and
                    other) PyYAML idiosyncrasies can be found here.

                 Variables  as  values  are not evaluated. So $PATH in the
                 following example is a literal '$PATH':

                    script-bar:
                      cmd.run:
                        - env: "PATH=/some/path:$PATH"

                 One can still use the existing $PATH by using  a  bit  of
                 Jinja:

                    {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                    mycommand:
                      cmd.run:
                        - name: ls -l /
                        - env:
                          - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

          stateful
                 The  command  being  executed  is expected to return data
                 about executing a state. For more  information,  see  the
                 Using the "Stateful" Argument section.

          umask  The umask (in octal) to use when running the command.

          output_loglevel
                 Control the loglevel at which the output from the command
                 is logged.  Note that the command being run will still be
                 logged (loglevel: DEBUG) regardless, unless quiet is used
                 for this value.

          quiet  The command will be  executed  quietly,  meaning  no  log
                 entries of the actual command or its return data. This is
                 deprecated as of  the  2014.1.0  release,  and  is  being
                 replaced with output_loglevel: quiet.

          timeout
                 If  the command has not terminated after timeout seconds,
                 send the subprocess sigterm, and if sigterm  is  ignored,
                 follow up with sigkill

          ignore_timeout
                 Ignore  the  timeout  of  commands,  which  is useful for
                 running nohup processes.

                 New in version 2015.8.0.

          creates
                 Only run if the file or files specified by creates do not
                 exist.

                 New in version 2014.7.0.

          use_vt Use  VT  utils  (saltstack)  to stream the command output
                 more interactively to the console and the logs.  This  is
                 experimental.

          NOTE:
             cmd.run   supports   the   usage   of   reload_modules.  This
             functionality allows you to force Salt to reload all modules.
             You  should only use reload_modules if your cmd.run does some
             sort of installation (such as pip), if you do not reload  the
             modules future items in your state which rely on the software
             being installed will fail.

                 getpip:
                   cmd.run:
                     - name: /usr/bin/python /usr/local/sbin/get-pip.py
                     - unless: which pip
                     - require:
                       - pkg: python
                       - file: /usr/local/sbin/get-pip.py
                     - reload_modules: True

   salt.states.cmd.script(name, source=None,  template=None,  onlyif=None,
   unless=None,  creates=None, cwd=None, runas=None, shell=None, env=None,
   stateful=False,      umask=None,      timeout=None,       use_vt=False,
   output_loglevel='debug', defaults=None, context=None, **kwargs)
          Download a script and execute it with specified arguments.

          source The  location  of  the script to download. If the file is
                 located on the master in the directory named spam, and is
                 called eggs, the source string is salt://spam/eggs

          template
                 If  this  setting  is  applied  then the named templating
                 engine will  be  used  to  render  the  downloaded  file.
                 Currently jinja, mako, and wempy are supported

          name   Either  "cmd  arg1  arg2  arg3..." (cmd is not used) or a
                 source "salt://...".

          onlyif Run the named command only if the command passed  to  the
                 onlyif option returns true

          unless Run  the  named command only if the command passed to the
                 unless option returns false

          cwd    The current working directory to execute the command  in,
                 defaults to /root

          runas  The name of the user to run the command as

          shell  The  shell  to  use  for execution. The default is set in
                 grains['shell']

          env    A list of  environment  variables  to  be  set  prior  to
                 execution.  Example:

                    salt://scripts/foo.sh:
                      cmd.script:
                        - env:
                          - BATCH: 'yes'

                 WARNING:
                    The  above  illustrates  a common PyYAML pitfall, that
                    yes, no, on, off, true, and false are  all  loaded  as
                    boolean True and False values, and must be enclosed in
                    quotes to be used as strings. More info on  this  (and
                    other) PyYAML idiosyncrasies can be found here.

                 Variables  as  values  are not evaluated. So $PATH in the
                 following example is a literal '$PATH':

                    salt://scripts/bar.sh:
                      cmd.script:
                        - env: "PATH=/some/path:$PATH"

                 One can still use the existing $PATH by using  a  bit  of
                 Jinja:

                    {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                    mycommand:
                      cmd.run:
                        - name: ls -l /
                        - env:
                          - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

          saltenv
                 base The Salt environment to use

          umask  The umask (in octal) to use when running the command.

          stateful
                 The  command  being  executed  is expected to return data
                 about executing a state. For more  information,  see  the
                 Using the "Stateful" Argument section.

          timeout
                 If  the command has not terminated after timeout seconds,
                 send the subprocess sigterm, and if sigterm  is  ignored,
                 follow up with sigkill

          args   String  of command line args to pass to the script.  Only
                 used if no  args  are  specified  as  part  of  the  name
                 argument. To pass a string containing spaces in YAML, you
                 will need to doubly-quote it:  "arg1 'arg two' arg3"

          creates
                 Only run if the file or files specified by creates do not
                 exist.

                 New in version 2014.7.0.

          use_vt Use  VT  utils  (saltstack)  to stream the command output
                 more interactively to the console and the logs.  This  is
                 experimental.

          context
                 New in version 2016.3.0.

                 Overrides   default   context  variables  passed  to  the
                 template.

          defaults
                 New in version 2016.3.0.

                 Default context passed to the template.

          output_loglevel
                 Control the loglevel at which the output from the command
                 is logged.  Note that the command being run will still be
                 logged (loglevel: DEBUG) regardless, unless quiet is used
                 for this value.

   salt.states.cmd.wait(name,   onlyif=None,   unless=None,  creates=None,
   cwd=None, runas=None, shell=None, env=(),  stateful=False,  umask=None,
   output_loglevel='debug', use_vt=False, **kwargs)
          Run the given command only if the watch statement calls it.

          NOTE:
             Use cmd.run with onchange instead.

          name   The  command  to  execute, remember that the command will
                 execute with the path and permissions of the salt-minion.

          onlyif A command to run as a check, run the named  command  only
                 if the command passed to the onlyif option returns true

          unless A  command  to run as a check, only run the named command
                 if the command passed to the unless option returns false

          cwd    The current working directory to execute the command  in,
                 defaults to /root

          runas  The user name to run the command as

          shell  The shell to use for execution, defaults to /bin/sh

          env    A  list  of  environment  variables  to  be  set prior to
                 execution.  Example:

                    script-foo:
                      cmd.wait:
                        - env:
                          - BATCH: 'yes'

                 WARNING:
                    The above illustrates a common  PyYAML  pitfall,  that
                    yes,  no,  on,  off, true, and false are all loaded as
                    boolean True and False values, and must be enclosed in
                    quotes  to  be used as strings. More info on this (and
                    other) PyYAML idiosyncrasies can be found here.

                 Variables as values are not evaluated. So  $PATH  in  the
                 following example is a literal '$PATH':

                    script-bar:
                      cmd.wait:
                        - env: "PATH=/some/path:$PATH"

                 One  can  still  use the existing $PATH by using a bit of
                 Jinja:

                    {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                    mycommand:
                      cmd.run:
                        - name: ls -l /
                        - env:
                          - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

          umask  The umask (in octal) to use when running the command.

          stateful
                 The command being executed is  expected  to  return  data
                 about  executing  a  state. For more information, see the
                 Using the "Stateful" Argument section.

          creates
                 Only run if the file or files specified by creates do not
                 exist.

                 New in version 2014.7.0.

          output_loglevel
                 Control the loglevel at which the output from the command
                 is logged.  Note that the command being run will still be
                 logged (loglevel: DEBUG) regardless, unless quiet is used
                 for this value.

          use_vt Use VT utils (saltstack) to  stream  the  command  output
                 more  interactively to the console and the logs.  This is
                 experimental.

   salt.states.cmd.wait_script(name,      source=None,      template=None,
   onlyif=None,  unless=None,  cwd=None, runas=None, shell=None, env=None,
   stateful=False,  umask=None,   use_vt=False,   output_loglevel='debug',
   **kwargs)
          Download  a script from a remote source and execute it only if a
          watch statement calls it.

          source The source script being downloaded to  the  minion,  this
                 source  script  is  hosted on the salt master server.  If
                 the file is located on the master in the directory  named
                 spam,   and   is   called  eggs,  the  source  string  is
                 salt://spam/eggs

          template
                 If this setting is  applied  then  the  named  templating
                 engine  will  be  used  to  render  the  downloaded file,
                 currently jinja, mako, and wempy are supported

          name   The command to execute, remember that  the  command  will
                 execute with the path and permissions of the salt-minion.

          onlyif A  command  to run as a check, run the named command only
                 if the command passed to the onlyif option returns true

          unless A command to run as a check, only run the  named  command
                 if the command passed to the unless option returns false

          cwd    The  current working directory to execute the command in,
                 defaults to /root

          runas  The user name to run the command as

          shell  The shell to use for execution,  defaults  to  the  shell
                 grain

          env    A  list  of  environment  variables  to  be  set prior to
                 execution.  Example:

                    salt://scripts/foo.sh:
                      cmd.wait_script:
                        - env:
                          - BATCH: 'yes'

                 WARNING:
                    The above illustrates a common  PyYAML  pitfall,  that
                    yes,  no,  on,  off, true, and false are all loaded as
                    boolean True and False values, and must be enclosed in
                    quotes  to  be used as strings. More info on this (and
                    other) PyYAML idiosyncrasies can be found here.

                 Variables as values are not evaluated. So  $PATH  in  the
                 following example is a literal '$PATH':

                    salt://scripts/bar.sh:
                      cmd.wait_script:
                        - env: "PATH=/some/path:$PATH"

                 One  can  still  use the existing $PATH by using a bit of
                 Jinja:

                    {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}

                    mycommand:
                      cmd.run:
                        - name: ls -l /
                        - env:
                          - PATH: {{ [current_path, '/my/special/bin']|join(':') }}

          umask  The umask (in octal) to use when running the command.

          stateful
                 The command being executed is  expected  to  return  data
                 about  executing  a  state. For more information, see the
                 Using the "Stateful" Argument section.

          use_vt
                    Use VT utils (saltstack) to stream the command  output
                    more  interactively to the console and the logs.  This
                    is experimental.

                 output_loglevel
                        Control the loglevel at which the output from  the
                        command  is  logged.   Note that the command being
                        run  will  still  be  logged   (loglevel:   DEBUG)
                        regardless, unless quiet is used for this value.

   salt.states.composer
   Installation of Composer Packages
   These  states  manage the installed packages for composer for PHP. Note
   that either composer is installed and accessible via a bin directory or
   you can pass the location of composer in the state.

      get-composer:
        cmd.run:
          - name: 'CURL=`which curl`; $CURL -sS https://getcomposer.org/installer | php'
          - unless: test -f /usr/local/bin/composer
          - cwd: /root/

      install-composer:
        cmd.wait:
          - name: mv /root/composer.phar /usr/local/bin/composer
          - cwd: /root/
          - watch:
            - cmd: get-composer

      /path/to/project:
        composer.installed:
          - no_dev: true
          - require:
            - cmd: install-composer

      # Without composer installed in your PATH
      # Note: composer.phar must be executable for state to work properly
      /path/to/project:
        composer.installed:
          - composer: /path/to/composer.phar
          - php: /usr/local/bin/php
          - no_dev: true

   salt.states.composer.installed(name,      composer=None,      php=None,
   user=None,   prefer_source=None,   prefer_dist=None,   no_scripts=None,
   no_plugins=None,      optimize=None,      no_dev=None,     quiet=False,
   composer_home='/root', always_check=True)
          Verify that the correct versions of  composer  dependencies  are
          present.

          dir    Directory location of the composer.json file.

          composer
                 Location  of  the composer.phar file. If not set composer
                 will just  execute  "composer"  as  if  it  is  installed
                 globally.  (i.e. /path/to/composer.phar)

          php    Location  of  the  php  executable  to use with composer.
                 (i.e. /usr/bin/php)

          user   Which system user to run composer as.

                 New in version 2014.1.4.

          prefer_source
                 --prefer-source option of composer.

          prefer_dist
                 --prefer-dist option of composer.

          no_scripts
                 --no-scripts option of composer.

          no_plugins
                 --no-plugins option of composer.

          optimize
                 --optimize-autoloader option of composer. Recommended for
                 production.

          no_dev --no-dev option for composer. Recommended for production.

          quiet  --quiet  option  for  composer.  Whether or not to return
                 output from composer.

          composer_home
                 $COMPOSER_HOME environment variable

          always_check
                 If True, _always_ run composer install in the  directory.
                 This  is  the  default  behavior.   If  False,  only  run
                 composer install if there is no vendor directory present.

   salt.states.composer.update(name, composer=None,  php=None,  user=None,
   prefer_source=None, prefer_dist=None, no_scripts=None, no_plugins=None,
   optimize=None, no_dev=None, quiet=False, composer_home='/root')
          Composer update the directory  to  ensure  we  have  the  latest
          versions of all project dependencies.

          dir    Directory location of the composer.json file.

          composer
                 Location  of  the composer.phar file. If not set composer
                 will just  execute  "composer"  as  if  it  is  installed
                 globally.  (i.e. /path/to/composer.phar)

          php    Location  of  the  php  executable  to use with composer.
                 (i.e. /usr/bin/php)

          user   Which system user to run composer as.

                 New in version 2014.1.4.

          prefer_source
                 --prefer-source option of composer.

          prefer_dist
                 --prefer-dist option of composer.

          no_scripts
                 --no-scripts option of composer.

          no_plugins
                 --no-plugins option of composer.

          optimize
                 --optimize-autoloader option of composer. Recommended for
                 production.

          no_dev --no-dev option for composer. Recommended for production.

          quiet  --quiet  option  for  composer.  Whether or not to return
                 output from composer.

          composer_home
                 $COMPOSER_HOME environment variable

   salt.states.cron
   Management of cron, the Unix command scheduler
   Cron declarations require a number of parameters. The following are the
   parameters  used by Salt to define the various timing values for a cron
   job:

   * minute

   * hour

   * daymonth

   * month

   * dayweek (0 to 6 are Sunday through Saturday, 7 can also be  used  for
     Sunday)

   WARNING:
      Any  timing  arguments  not  specified take a value of *. This means
      that setting hour to 5, while not defining the  minute  param,  will
      result in Salt adding a job that will execute every minute between 5
      and 6 A.M.!

      Additionally, the default user for these states is root.  Therefore,
      if the cron job is for another user, it is necessary to specify that
      user with the user parameter.

   A long time ago (before 2014.2), when making  changes  to  an  existing
   cron  job,  the  name  declaration  is  the  parameter used to uniquely
   identify the job, so if an existing cron that looks like this:

      date > /tmp/crontest:
        cron.present:
          - user: root
          - minute: 5

   Is changed to this:

      date > /tmp/crontest:
        cron.present:
          - user: root
          - minute: 7
          - hour: 2

   Then the existing cron will be updated, but  if  the  cron  command  is
   changed, then a new cron job will be added to the user's crontab.

   The  current  behavior  is still relying on that mechanism, but you can
   also specify an identifier to identify your crontabs:

      date > /tmp/crontest:
        cron.present:
          - identifier: SUPERCRON
          - user: root
          - minute: 7
          - hour: 2

   New in version 2014.1.2.

   And, some months later, you modify it:

      superscript > /tmp/crontest:
        cron.present:
          - identifier: SUPERCRON
          - user: root
          - minute: 3
          - hour: 4

   New in version 2014.1.2.

   The old  date  >  /tmp/crontest  will  be  replaced  by  superscript  >
   /tmp/crontest.

   Additionally,  Salt  also  supports running a cron every x minutes very
   similarly to the Unix convention of using */5 to have a job  run  every
   five minutes. In Salt, this looks like:

      date > /tmp/crontest:
        cron.present:
          - user: root
          - minute: '*/5'

   The job will now run every 5 minutes.

   Additionally,  the  temporal  parameters  (minute,  hour,  etc.) can be
   randomized by using random instead  of  using  a  specific  value.  For
   example,  by using the random keyword in the minute parameter of a cron
   state, the same cron job can be pushed  to  hundreds  or  thousands  of
   hosts, and they would each use a randomly-generated minute. This can be
   helpful when the cron job accesses a network resource, and  it  is  not
   desirable for all hosts to run the job concurrently.

      /path/to/cron/script:
        cron.present:
          - user: root
          - minute: random
          - hour: 2

   New in version 0.16.0.

   Since  Salt  assumes  a value of * for unspecified temporal parameters,
   adding a parameter to the state and setting it to  random  will  change
   that value from * to a randomized numeric value. However, if that field
   in the cron entry on the minion already contains a numeric value,  then
   using the random keyword will not modify it.

   Added  the  opportunity  to  set  a  job  with  a  special keyword like
   '@reboot' or '@hourly'.

      /path/to/cron/script:
        cron.present:
          - user: root
          - special: '@hourly'

   The script will be executed every reboot if cron  daemon  support  this
   option.

      /path/to/cron/otherscript:
        cron.absent:
          - user: root
          - special: '@daily'

   This  counter  part  definition  will  ensure than a job with a special
   keyword is not set.

   salt.states.cron.absent(name,      user='root',       identifier=False,
   special=None, **kwargs)
          Verifies that the specified cron job is absent for the specified
          user; only the name is matched when removing a cron job.

          name   The command that should be absent in the user crontab.

          user   The name of the user whose crontab needs to be  modified,
                 defaults to the root user

          identifier
                 Custom-defined  identifier for tracking the cron line for
                 future crontab edits. This defaults to the state id

          special
                 The  special  keyword  used  in  the  job  (eg.  @reboot,
                 @hourly...)

   salt.states.cron.env_absent(name, user='root')
          Verifies  that the specified environment variable is absent from
          the crontab for the specified user

          name   The name of the environment variable to remove  from  the
                 user crontab

          user   The  name of the user whose crontab needs to be modified,
                 defaults to the root user

   salt.states.cron.env_present(name, value=None, user='root')
          Verifies that the specified environment variable is  present  in
          the crontab for the specified user.

          name   The  name  of the environment variable to set in the user
                 crontab

          user   The name of the user whose crontab needs to be  modified,
                 defaults to the root user

          value  The value to set for the given environment variable

   salt.states.cron.file(name,    source_hash='',   source_hash_name=None,
   user='root', template=None, context=None, replace=True,  defaults=None,
   backup='', **kwargs)
          Provides  file.managed-like functionality (templating, etc.) for
          a pre-made crontab file, to be assigned to a given user.

          name   The source file to be used as the  crontab.  This  source
                 file  can  be hosted on either the salt master server, or
                 on an HTTP or FTP server.  For files hosted on  the  salt
                 file  server, if the file is located on the master in the
                 directory named spam, and  is  called  eggs,  the  source
                 string is salt://spam/eggs

                 If  the  file  is hosted on a HTTP or FTP server then the
                 source_hash argument is also required

          source_hash
                 This can be either a file which contains  a  source  hash
                 string  for  the  source,  or  a  source hash string. The
                 source hash string is the hash algorithm followed by  the
                 hash of the file: md5=e138491e9d5b97023cea823fe17bac22

          source_hash_name
                 When  source_hash refers to a hash file, Salt will try to
                 find  the  correct  hash  by  matching  the  filename/URI
                 associated with that hash. By default, Salt will look for
                 the filename being managed. When managing a file at  path
                 /tmp/foo.txt,  then  the  following  line  in a hash file
                 would match:

                    acbd18db4cc2f85cedef654fccc4a4d8    foo.txt

                 However, sometimes a  hash  file  will  include  multiple
                 similar paths:

                    37b51d194a7513e45b56f6524f2d51f2    ./dir1/foo.txt
                    acbd18db4cc2f85cedef654fccc4a4d8    ./dir2/foo.txt
                    73feffa4b7f6bb68e44cf984c85f6e88    ./dir3/foo.txt

                 In  cases  like  this, Salt may match the incorrect hash.
                 This argument can be used to tell Salt which filename  to
                 match, to ensure that the correct hash is identified. For
                 example:

                    foo_crontab:
                      cron.file:
                        - name: https://mydomain.tld/dir2/foo.txt
                        - source_hash: https://mydomain.tld/hashes
                        - source_hash_name: ./dir2/foo.txt

                 NOTE:
                    This argument must contain  the  full  filename  entry
                    from  the  checksum file, as this argument is meant to
                    disambiguate matches for multiple files that have  the
                    same  basename. So, in the example above, simply using
                    foo.txt would not match.

                 New in version 2016.3.5.

          user   The user to whom the crontab  should  be  assigned.  This
                 defaults to root.

          template
                 If  this  setting  is  applied  then the named templating
                 engine will  be  used  to  render  the  downloaded  file.
                 Currently, jinja and mako are supported.

          context
                 Overrides   default   context  variables  passed  to  the
                 template.

          replace
                 If the crontab should be replaced,  if  False  then  this
                 command  will  be  ignored  if  a  crontab exists for the
                 specified user. Default is True.

          defaults
                 Default context passed to the template.

          backup Overrides the default backup mode for the user's crontab.

   salt.states.cron.present(name,   user='root',   minute='*',   hour='*',
   daymonth='*',  month='*',  dayweek='*',  comment=None, commented=False,
   identifier=False, special=None)
          Verifies  that  the  specified  cron  job  is  present  for  the
          specified  user.   For  more  advanced  information  about  what
          exactly can be set in the cron  timing  parameters,  check  your
          cron   system's  documentation.  Most  Unix-like  systems'  cron
          documentation can be found via  the  crontab  man  page:  man  5
          crontab.

          name   The command that should be executed by the cron job.

          user   The  name of the user whose crontab needs to be modified,
                 defaults to the root user

          minute The information to be set into the minute  section,  this
                 can  be  any  string  supported by your cron system's the
                 minute field. Default is *

          hour   The information to be set in the hour section. Default is
                 *

          daymonth
                 The  information  to  be set in the day of month section.
                 Default is *

          month  The information to be set in the month  section.  Default
                 is *

          dayweek
                 The  information  to  be  set in the day of week section.
                 Default is *

          comment
                 User comment to be added on line previous the cron job

          commented
                 The cron job is set commented (prefixed with #DISABLED#).
                 Defaults to False.

                 New in version 2016.3.0.

          identifier
                 Custom-defined  identifier for tracking the cron line for
                 future crontab edits. This defaults to the state id

          special
                 A special keyword to specify  periodicity  (eg.  @reboot,
                 @hourly...)

                 New in version 2016.3.0.

   salt.states.cyg
   Installation of Cygwin packages.

   A  state module to manage cygwin packages. Packages can be installed or
   removed.

      dos2unix:
        cyg.installed

   class salt.states.cyg.DictDiffer(current_dict, past_dict)
          Calculate the difference between two dictionaries.

          1. items added

          2. items removed

          3. keys same in both but changed values

          4. keys same in both and unchanged values

          added()
                 Return a set of additions to past_dict.

          changed()
                 Return a set of the keys with changed values.

          removed()
                 Return a set of things removed from past_dict.

          same() True if the two dicts are the same.

          unchanged()
                 Return a set of the keys with unchanged values.

   salt.states.cyg.installed(name, cyg_arch='x86_64', mirrors=None)
          Make sure that a package is installed.

          name   The name of the package to install

          cyg_arch
                 x86_64 The cygwin architecture  to  install  the  package
                 into.  Current options are x86 and x86_64

          mirrors
                 None  List  of mirrors to check.  None will use a default
                 mirror (kernel.org)

          CLI Example:

             rsync:
               cyg.installed:
                 - mirrors:
                   - http://mirror/without/public/key: ""
                   - http://mirror/with/public/key: http://url/of/public/key

   salt.states.cyg.removed(name, cyg_arch='x86_64', mirrors=None)
          Make sure that a package is not installed.

          name   The name of the package to uninstall

          cyg_arch
                 x86_64 The cygwin  architecture  to  remove  the  package
                 from.  Current options are x86 and x86_64

          mirrors
                 None  List  of mirrors to check.  None will use a default
                 mirror (kernel.org)

          CLI Example:

             rsync:
               cyg.removed:
                 - mirrors:
                   - http://mirror/without/public/key: ""
                   - http://mirror/with/public/key: http://url/of/public/key

   salt.states.cyg.updated(name=None, cyg_arch='x86_64', mirrors=None)
          Make sure all packages are up to date.

          name   None  No  affect,  salt  fails  poorly  without  the  arg
                 available

          cyg_arch
                 x86_64   The  cygwin  architecture  to  update.   Current
                 options are x86 and x86_64

          mirrors
                 None List of mirrors to check.  None will use  a  default
                 mirror (kernel.org)

          CLI Example:

             rsync:
               cyg.updated:
                 - mirrors:
                   - http://mirror/without/public/key: ""
                   - http://mirror/with/public/key: http://url/of/public/key

   salt.states.ddns
   Dynamic DNS updates
   Ensure  a  DNS  record  is  present  or  absent utilizing RFC 2136 type
   dynamic updates.

   depends

          * dnspython

   NOTE:
      The dnspython module is required when managing  DDNS  using  a  TSIG
      key.  If you are not using a TSIG key, DDNS is allowed by ACLs based
      on IP address and the dnspython module is not required.

   Example:

      webserver:
        ddns.present:
          - zone: example.com
          - ttl: 60
          - data: 111.222.333.444
          - nameserver: 123.234.345.456
          - keyfile: /srv/salt/dnspy_tsig_key.txt

   salt.states.ddns.absent(name, zone, data=None, rdtype=None, **kwargs)
          Ensures that the named DNS record is absent.

          name   The host portion of the DNS  record,  e.g.,  'webserver'.
                 Name  and zone are concatenated when the entry is created
                 unless name includes a trailing dot, so  make  sure  that
                 information is not duplicated in these two arguments.

          zone   The zone to check

          data   Data  for  the  DNS record. E.g., the IP address for an A
                 record.  If  omitted,  all  records  matching  name  (and
                 rdtype, if provided) will be purged.

          rdtype DNS resource type. If omitted, all types will be purged.

          **kwargs
                 Additional  arguments  the  ddns.update function may need
                 (e.g.  nameserver,  keyfile,  keyname).   Note  that  the
                 nsupdate  key  file can't be reused by this function, the
                 keyfile and other arguments  must  follow  the  dnspython
                 spec.

   salt.states.ddns.present(name, zone, ttl, data, rdtype='A', **kwargs)
          Ensures that the named DNS record is present with the given ttl.

          name   The  host  portion  of the DNS record, e.g., 'webserver'.
                 Name and zone are concatenated when the entry is  created
                 unless  name  includes  a trailing dot, so make sure that
                 information is not duplicated in these two arguments.

          zone   The zone to check/update

          ttl    TTL for the record

          data   Data for the DNS record. E.g., the IP address  for  an  A
                 record.

          rdtype DNS resource type. Default 'A'.

          **kwargs
                 Additional  arguments  the  ddns.update function may need
                 (e.g.  nameserver,  keyfile,  keyname).   Note  that  the
                 nsupdate  key  file can't be reused by this function, the
                 keyfile and other arguments  must  follow  the  dnspython
                 spec.

   salt.states.debconfmod
   Management of debconf selections
   depends

          * debconf-utils package

   The   debconfmod  state  module  manages  the  enforcement  of  debconf
   selections, this state  can  set  those  selections  prior  to  package
   installation.

   Available Functions
   The debconfmod state has two functions, the set and set_file functions

   set    Set debconf selections from the state itself

   set_file
          Set debconf selections from a file

      nullmailer-debconf:
        debconf.set:
          - name: nullmailer
          - data:
              'shared/mailname': {'type': 'string', 'value': 'server.domain.tld'}
              'nullmailer/relayhost': {'type': 'string', 'value': 'mail.domain.tld'}
      ferm-debconf:
        debconf.set:
          - name: ferm
          - data:
              'ferm/enable': {'type': 'boolean', 'value': True}

   NOTE:
      Due to how PyYAML imports nested dicts (see here), the values in the
      data dict must be indented four spaces instead of two.

   salt.states.debconfmod.set(name, data, **kwargs)
          Set debconf selections

             <state_id>:
               debconf.set:
                 - name: <name>
                 - data:
                     <question>: {'type': <type>, 'value': <value>}
                     <question>: {'type': <type>, 'value': <value>}

             <state_id>:
               debconf.set:
                 - name: <name>
                 - data:
                     <question>: {'type': <type>, 'value': <value>}
                     <question>: {'type': <type>, 'value': <value>}

          name:  The package name to set answers for.

          data:  A  set  of  questions/answers  for  debconf.  Note   that
                 everything under this must be indented twice.

          question:
                 The question the is being pre-answered

          type:  The  type  of  question  that  is  being  asked  (string,
                 boolean, select, etc.)

          value: The answer to the question

   salt.states.debconfmod.set_file(name,      source,       template=None,
   context=None, defaults=None, **kwargs)
          Set debconf selections from a file or a template

             <state_id>:
               debconf.set_file:
                 - source: salt://pathto/pkg.selections

             <state_id>:
               debconf.set_file:
                 - source: salt://pathto/pkg.selections?saltenv=myenvironment

             <state_id>:
               debconf.set_file:
                 - source: salt://pathto/pkg.selections.jinja2
                 - template: jinja
                 - context:
                     some_value: "false"

          source:
                 The   location   of   the  file  containing  the  package
                 selections

          template
                 If this setting is  applied  then  the  named  templating
                 engine  will  be  used  to  render the package selections
                 file, currently jinja, mako, and wempy are supported

          context
                 Overrides  default  context  variables  passed   to   the
                 template.

          defaults
                 Default context passed to the template.

   salt.states.dellchassis
   Manage chassis via Salt Proxies.

   New in version 2015.8.2.

   Below is an example state that sets basic parameters:

      my-dell-chassis:
        dellchassis.chassis:
          - chassis_name: my-dell-chassis
          - datacenter: dc-1-us
          - location: my-location
          - mode: 2
          - idrac_launch: 1
          - slot_names:
            - server-1: my-slot-name
            - server-2: my-other-slot-name
          - blade_power_states:
            - server-1: on
            - server-2: off
            - server-3: powercycle

   However,   it   is   possible  to  place  the  entire  set  of  chassis
   configuration data in pillar. Here's an example pillar structure:

      proxy:
        host: 10.27.20.18
        admin_username: root
        fallback_admin_username: root
        passwords:
          - super-secret
          - old-secret
        proxytype: fx2

        chassis:
          name: fx2-1
          username: root
          password: saltstack1
          datacenter: london
          location: rack-1-shelf-3
          management_mode: 2
          idrac_launch: 0
          slot_names:
            - 'server-1': blade1
            - 'server-2': blade2

          servers:
            server-1:
              idrac_password: saltstack1
              ipmi_over_lan: True
              ip: 172.17.17.132
              netmask: 255.255.0.0
              gateway: 172.17.17.1
            server-2:
              idrac_password: saltstack1
              ipmi_over_lan: True
              ip: 172.17.17.2
              netmask: 255.255.0.0
              gateway: 172.17.17.1
            server-3:
              idrac_password: saltstack1
              ipmi_over_lan: True
              ip: 172.17.17.20
              netmask: 255.255.0.0
              gateway: 172.17.17.1
            server-4:
              idrac_password: saltstack1
              ipmi_over_lan: True
              ip: 172.17.17.2
              netmask: 255.255.0.0
              gateway: 172.17.17.1

          switches:
            switch-1:
              ip: 192.168.1.2
              netmask: 255.255.255.0
              gateway: 192.168.1.1
              snmp: nonpublic
              password: saltstack1
            switch-2:
              ip: 192.168.1.3
              netmask: 255.255.255.0
              gateway: 192.168.1.1
              snmp: nonpublic
              password: saltstack1

   And to go with it, here's an example state that pulls the data from the
   pillar stated above:

      {% set details = pillar.get('proxy:chassis', {}) %}
      standup-step1:
        dellchassis.chassis:
          - name: {{ details['name'] }}
          - location: {{ details['location'] }}
          - mode: {{ details['management_mode'] }}
          - idrac_launch: {{ details['idrac_launch'] }}
          - slot_names:
            {% for entry details['slot_names'] %}
              - {{ entry.keys()[0] }}: {{ entry[entry.keys()[0]]  }}
            {% endfor %}

      blade_powercycle:
        dellchassis.chassis:
          - blade_power_states:
            - server-1: powercycle
            - server-2: powercycle
            - server-3: powercycle
            - server-4: powercycle

      # Set idrac_passwords for blades.  racadm needs them to be called 'server-x'
      {% for k, v in details['servers'].iteritems() %}
      {{ k }}:
        dellchassis.blade_idrac:
          - idrac_password: {{ v['idrac_password'] }}
      {% endfor %}

      # Set management ip addresses, passwords, and snmp strings for switches
      {% for k, v in details['switches'].iteritems() %}
      {{ k }}-switch-setup:
        dellchassis.switch:
          - name: {{ k }}
          - ip: {{ v['ip'] }}
          - netmask: {{ v['netmask'] }}
          - gateway: {{ v['gateway'] }}
          - password: {{ v['password'] }}
          - snmp: {{ v['snmp'] }}
      {% endfor %}

   NOTE:
      This  state  module  relies  on the dracr.py execution module, which
      runs racadm commands on the chassis, blades, etc. The racadm command
      runs  very  slowly  and,  depending  on your state, the proxy minion
      return might timeout before the racadm commands have  completed.  If
      you  are repeatedly seeing minions timeout after state calls, please
      use the -t CLI argument to increase the timeout variable.

      For example:

          salt '*' state.sls my-dell-chasis-state-name -t 60

   NOTE:
      The  Dell  CMC  units  perform  adequately  but  many   iDRACs   are
      excruciatingly slow.  Some functions can take minutes to execute.

   salt.states.dellchassis.blade_idrac(name,          idrac_password=None,
   idrac_ipmi=None, idrac_ip=None, idrac_netmask=None, idrac_gateway=None,
   idrac_dnsname=None, idrac_dhcp=None)
          Set parameters for iDRAC in a blade.

          Parameters
                 idrac_password  --  Password  to  use  to  connect to the
                 iDRACs directly

          (idrac_ipmi and idrac_dnsname must be set directly on the iDRAC.
          They can't be set through the CMC.  If this password is present,
          use  it  instead  of  the  CMC  password)   :param   idrac_ipmi:
          Enable/Disable IPMI over LAN :param idrac_ip: Set IP address for
          iDRAC  :param  idrac_netmask:  Set  netmask  for  iDRAC   :param
          idrac_gateway:  Set gateway for iDRAC :param idrac_dhcp: Turn on
          DHCP for iDRAC (True turns on, False does nothing
             becaause setting a static IP will disable DHCP).

          Returns
                 A standard Salt changes dictionary

          NOTE: If any of the IP address settings is  configured,  all  of
          ip, netmask, and gateway must be present

   salt.states.dellchassis.chassis(name, chassis_name=None, password=None,
   datacenter=None,    location=None,    mode=None,     idrac_launch=None,
   slot_names=None, blade_power_states=None)
          Manage a Dell Chassis.

          chassis_name
                 The name of the chassis.

          datacenter
                 The datacenter in which the chassis is located

          location
                 The location of the chassis.

          password
                 Password  for  the chassis. Note: If this password is set
                 for the chassis, the current implementation of this state
                 will  set this password both on the chassis and the iDrac
                 passwords on any configured blades. If the  password  for
                 the  blades  should  be  distinct,  they  should  be  set
                 separately with the blade_idrac function.

          mode   The management mode of the chassis. Viable options are:

                 * 0: None

                 * 1: Monitor

                 * 2: Manage and Monitor

          idrac_launch
                 The iDRAC launch method of the  chassis.  Viable  options
                 are:

                 * 0: Disabled (launch iDRAC using IP address)

                 * 1: Enabled (launch iDRAC using DNS name)

          slot_names
                 The  names of the slots, provided as a list identified by
                 their slot numbers.

          blade_power_states
                 The power states of a blade server, provided  as  a  list
                 and  identified  by  their server numbers. Viable options
                 are:

                    * on: Ensure the blade server is powered on.

                    * off: Ensure the blade server is powered off.

                    * powercycle: Power cycle the blade server.

          Example:

             my-dell-chassis:
               dellchassis.chassis:
                 - chassis_name: my-dell-chassis
                 - location: my-location
                 - datacenter: london
                 - mode: 2
                 - idrac_launch: 1
                 - slot_names:
                   - 1: my-slot-name
                   - 2: my-other-slot-name
                 - blade_power_states:
                   - server-1: on
                   - server-2: off
                   - server-3: powercycle

   salt.states.dellchassis.firmware_update(hosts=None, directory='')
             State to update the firmware on host using the racadm command

             firmwarefile
                    filename (string) starting with salt://

             host   string  representing  the  hostname  supplied  to  the
                    racadm command

             directory
                    Directory name where firmwarefile will be downloaded

             dell-chassis-firmware-update:
               dellchassis.firmware_update:
                 hosts:
                   cmc:
                     salt://firmware_cmc.exe
                   server-1:
                     salt://firmware.exe
                 directory: /opt/firmwares

   salt.states.dellchassis.switch(name,       ip=None,       netmask=None,
   gateway=None, dhcp=None, password=None, snmp=None)
          Manage switches in a Dell Chassis.

          name   The switch designation (e.g. switch-1, switch-2)

          ip     The Static IP Address of the switch

          netmask
                 The netmask for the static IP

          gateway
                 The gateway for the static IP

          dhcp   True:  Enable  DHCP  False:  Do  not  change  DHCP  setup
                 (disabling DHCP is automatic when a static IP is set)

          password
                 The access (root) password for the switch

          snmp   The SNMP community string for the switch

          Example:

             my-dell-chassis:
               dellchassis.switch:
                 - switch: switch-1
                 - ip: 192.168.1.1
                 - netmask: 255.255.255.0
                 - gateway: 192.168.1.254
                 - dhcp: True
                 - password: secret
                 - snmp: public

   salt.states.disk
   Disk monitoring state

   Monitor the state of disk resources.

   The disk.status function can be used to report that the used space of a
   filesystem is within the specified limits.

      used_space:
        disk.status:
          - name: /dev/xda1
          - maximum: 79%
          - minimum: 11%

   It can  be  used  with  an  onfail  requisite,  for  example,  to  take
   additional action in response to or in preparation for other states.

      storage_threshold:
        disk.status:
          - name: /dev/xda1
          - maximum: 97%

      clear_cache:
        cmd.run:
          - name: rm -r /var/cache/app
          - onfail:
            - disk: storage_threshold

   To  use  kilobytes  (KB)  for minimum and maximum rather than percents,
   specify the absolute flag:

      used_space:
        disk.status:
          - name: /dev/xda1
          - minimum: 1024 KB
          - maximum: 1048576 KB
          - absolute: True

   salt.states.disk.status(name,        maximum=None,        minimum=None,
   absolute=False)
          Return the current disk usage stats for the named mount point

          name   Disk mount with which to check used space

          maximum
                 The maximum disk utilization

          minimum
                 The minimum disk utilization

          absolute
                 By  default,  the  utilization is measured in percentage.
                 Set the absolute flag to use kilobytes.

                 New in version 2016.11.0.

   salt.states.dockerio
   Manage Docker containers
   Deprecated since version 2015.8.0: Future feature development  will  be
   done  only  in  dockerng.  See  the  documentation  for this module for
   information on the deprecation path.

   Docker is a lightweight, portable, self-sufficient  software  container
   wrapper. The base supported wrapper type is LXC, cgroups, and the Linux
   Kernel.

   NOTE:
      This state module requires docker-py version >= 0.6.0 which supports
      Docker Remote API version 1.12.

   Available Functions
   * built

        corp/mysuperdocker_img:
          docker.built:
            - path: /path/to/dir/container

   * pulled

        ubuntu:
          docker.pulled:
            - tag: latest

   * pushed

        corp/mysuperdocker_img:
          docker.pushed

   * installed

        mysuperdocker-container:
          docker.installed:
            - name: mysuperdocker
            - hostname: superdocker
            - image: corp/mysuperdocker_img

   * loaded

        mysuperdocker-file:
          docker.loaded:
            - name: mysuperdocker
            - source: salt://_files/tmp/docker_image.tar

   * running

        my_service:
          docker.running:
            - container: mysuperdocker
            - image: corp/mysuperdocker_img
            - ports:
              - "5000/tcp":
                    HostIp: ""
                    HostPort: "5000"

     NOTE:
        The  ports  argument above is a dictionary. The double indentation
        is required for PyYAML to load the data structure  properly  as  a
        python dictionary. More information can be found here

   * absent

        mys_old_uperdocker:
          docker.absent

   * run

        /finish-install.sh:
          docker.run:
            - cid: mysuperdocker
            - unless: grep -q something /var/log/foo
            - docker_unless: grep -q done /install_log

   Use Cases
      Ensures the container is running with the latest image available

          my-service-image:
            docker.pulled:
              - name: registry/my-service:latest
              - force: true

          my-service-container:
            docker.installed:
              - image: registry/my-service:latest
              - watch:
                - docker: my-service-image

          my-service:
            docker.running:
              - container: my-service-container
              - watch:
                - docker: my-service-container

   NOTE:
      The  docker  modules  are  named  dockerio because the name 'docker'
      would conflict with the underlying docker-py library.

   salt.states.dockerio.absent(name)
          Ensure that the container is absent; if not,  it  will  will  be
          killed and destroyed. (docker inspect)

          name:  Either the container name or id

   salt.states.dockerio.built(name,  tag='latest', path=None, quiet=False,
   nocache=False, rm=True, force=False, timeout=None, *args, **kwargs)
          Build a docker image from a path or URL to a dockerfile. (docker
          build)

          name   Name of the image

          tag    tag of the image (defaults to 'latest')

          path   URL (e.g. url/branch/docker_dir/dockerfile) or filesystem
                 path to the dockerfile

   salt.states.dockerio.installed(name, image, tag='latest', command=None,
   hostname=None,  user=None,  detach=True,  stdin_open=False,  tty=False,
   mem_limit=None, ports=None, environment=None,  dns=None,  volumes=None,
   volumes_from=None, cpu_shares=None, cpuset=None, *args, **kwargs)
          Ensure  that  a  container  with  the given name exists; if not,
          build a new container from the specified image.  (docker run)

          name   Name for the container

          image  Image from which to build this container

          tag    tag of the image (defaults to 'latest')

          environment

                 Environment variables for the container, either

                        * a mapping of key, values

                        * a list of mappings of key, values

          ports

                 List of ports definitions, either:

                        * a port to map

                        * a    mapping    of    mapping    portInHost    :
                          PortInContainer

          volumes
                 List of volumes (see notes for the running function)

          For    other    parameters,    see    absolutely    first    the
          salt.modules.dockerio execution module and the docker-py  python
          bindings for docker documentation for docker.create_container.

          NOTE:
             This  command  does  not  verify  that the named container is
             running the specified image.

   salt.states.dockerio.loaded(name,      tag='latest',       source=None,
   source_hash='', force=False)
          Load an image into the local docker registry (docker load)

          name   Name of the docker image

          tag    tag of the image (defaults to 'latest')

          source The  source  .tar file to download to the minion, created
                 by docker save this source file can be hosted  on  either
                 the salt master server, or on an HTTP or FTP server.

                 If  the  file  is hosted on a HTTP or FTP server then the
                 source_hash argument is also required

                 NOTE:
                    See first the documentation for Salt file.managed

          source_hash

                 This can be one of the following:

                        1. a source hash string

                        2. the URI of a file  that  contains  source  hash
                           strings

          force  Load even if the image exists

   salt.states.dockerio.present(name,       image=None,      tag='latest',
   is_latest=False)
          If a container with the given name is not  present,  this  state
          will  fail.  Supports optionally checking for specific image/tag
          (docker inspect)

          name:  container id

          image: image the container should be running (defaults to any)

          tag:   tag of the image (defaults to 'latest')

          is_latest:
                 also check if the container runs the  latest  version  of
                 the  image ( latest defined as the latest pulled onto the
                 local machine)

   salt.states.dockerio.pulled(name,      tag='latest',       force=False,
   insecure_registry=False, *args, **kwargs)
          Pull an image from a docker registry. (docker pull)

          NOTE:
             See  first  the  documentation for docker login, docker pull,
             docker push, and docker.import_image (docker  import).   NOTE
             that  we  added  in  SaltStack a way to authenticate yourself
             with the Docker Hub Registry by  supplying  your  credentials
             (username,   email   &  password)  using  pillars.  For  more
             information, see salt.modules.dockerio execution module.

          name   Name of the image

          tag    Tag of the image

          force  Pull even if the image is already pulled

          insecure_registry
                 Set to True to allow connections to non-HTTPS registries.
                 Default False.

   salt.states.dockerio.pushed(name,                         tag='latest',
   insecure_registry=False)
          Push an image from a docker registry. (docker push)

          NOTE:
             See first the documentation for docker  login,  docker  pull,
             docker  push,  and docker.import_image (docker import).  NOTE
             that we added in SaltStack a  way  to  authenticate  yourself
             with  the  Docker  Hub Registry by supplying your credentials
             (username,  email  &  password)  using  pillars.   For   more
             information, see salt.modules.dockerio execution module.

          name   Name of the image

          tag    Tag of the image [Optional]

          insecure_registry
                 Set to True to allow connections to non-HTTPS registries.
                 Default False.

   salt.states.dockerio.run(name,  cid=None,  hostname=None,  onlyif=None,
   unless=None, docked_onlyif=None, docked_unless=None, *args, **kwargs)
          Run a command in a specific container

          You can match by either name or hostname

          name   command to run in the container

          cid    Container id or name

          state_id
                 state_id

          onlyif Only execute cmd if statement on the host returns 0

          unless Do not execute cmd if statement on the host returns 0

          docked_onlyif
                 Only execute cmd if statement in the container returns 0

          docked_unless
                 Do  not execute cmd if statement in the container returns
                 0

   salt.states.dockerio.running(name, image, tag='latest', container=None,
   command=None,  hostname=None, user=None, detach=True, stdin_open=False,
   tty=False,  mem_limit=None,  ports=None,  environment=None,   dns=None,
   volumes=None,      volumes_from=None,     start=True,     cap_add=None,
   cap_drop=None,   privileged=None,   lxc_conf=None,   network_mode=None,
   check_is_running=True,       publish_all_ports=False,       links=None,
   restart_policy=None,  cpu_shares=None,  cpuset=None,  kill_signal=None,
   *args, **kwargs)
          Ensure  that  a  container is running. If the container does not
          exist, it will be created from the specified image. (docker run)

          name / container
                 Name for the container

          image  Image from which to build this container

          tag    tag of the image (defaults to 'latest')

          environment

                 Environment variables for the container, either

                        * a mapping of key, values

                        * a list of mappings of key, values

          ports

                 List of ports definitions, either:

                        * a port to map

                        * a    mapping    of    mapping    portInHost    :
                          PortInContainer

                    - ports:
                      - "5000/tcp":
                            HostIp: ""
                            HostPort: "5000"

          publish_all_ports
                 Publish  all  ports from the port list (default is false,
                 only   meaningful    if    port    does    not    contain
                 portinhost:portincontainer mapping)

          volumes
                 List of volumes to mount or create in the container (like
                 -v of docker run  command),  mapping  host  directory  to
                 container directory.

                 To  specify  a  volume  in  the  container  in terse list
                 format:

                    - volumes:
                      - "/var/log/service" # container-only volume
                      - "/srv/timezone:/etc/timezone" # bound volume
                      - "/usr/local/etc/passwd:/etc/passwd:ro" # read-only bound volume

                 You can also use the short dictionary form (note that the
                 notion of source:target from docker is preserved):

                    - volumes:
                      - /var/log/service: /var/log/service # mandatory read-write implied

                 Or, alternatively, to specify read-only mounting, use the
                 extended form:

                    - volumes:
                      - /home/user1:
                          bind: /mnt/vol2
                          ro: True
                      - /var/www:
                          bind: /mnt/vol1
                          ro: False

                 Or (for backwards compatibility) another dict style:

                    - volumes:
                        /home/user1:
                          bind: /mnt/vol2
                          ro: True
                        /var/www:
                          bind: /mnt/vol1
                          ro: False

          volumes_from
                 List of containers to share volumes with

          dns    List of DNS servers.

                    - dns:
                        - 127.0.0.1

          network_mode

                 * 'bridge': creates a new network stack for the container
                   on the docker bridge

                 * 'none': no networking for this container

                 * 'container:[name|id]': reuses another container network
                   stack)

                 * 'host': use the host network stack inside the container

                    - network_mode: host

          restart_policy
                 Restart policy to  apply  when  a  container  exits  (no,
                 on-failure[:max-retry], always)

                    - restart_policy:
                        MaximumRetryCount: 5
                        Name: on-failure

          cap_add
                 List of capabilities to add in a container.

          cap_drop
                 List of capabilities to drop in a container.

          check_is_running
                 Enable checking if a container should run or not.  Useful
                 for data-only containers that must be linked  to  another
                 one.  e.g. nginx <- static-files

          cpu_shares
                 CPU shares (relative weight)

                    - cpu_shares: 2

          cpuset CPUs in which to allow execution ('0-3' or '0,1')

                    - cpuset: '0-3'

          kill_signal
                 If  defined,  its  value will be sent as a kill signal to
                 the    running    container.    i.e.    It    will    use
                 client.kill(signal=kill_signal)         instead        of
                 client.restart(),  when  the  state  is  triggered  by  a
                 watcher requisite.

                 possible use case: Soft reload of nginx

                    nginx:
                      docker.running:
                        - image: some-fictional-registry.com/nginx
                        - tag: latest
                        - kill_signal: SIGHUP
                        - watch:
                          - file: /etc/nginx/nginx.conf

                 This  state will ask nginx to reload (instead of restart)
                 each time the /etc/nginx/nginx.conf is modified.

                 New in version 2015.8.0.

          For other parameters, see salt.modules.dockerio execution module
          and  the  docker-py  python bindings for docker documentation <
          https://github.com/dotcloud/docker-py#api>`_                 for
          docker.create_container.

          NOTE:
             This  command  does  not  verify  that the named container is
             running the specified image.

   salt.states.dockerio.script(*args, **kw)
          Placeholder function for a cmd.script alike.

          NOTE:
             Not  yet  implemented.   Its  implementation  might  be  very
             similar from salt.states.dockerio.run

   salt.states.dockerng
   Management of Docker containers

   New in version 2015.8.0.

   This is the state module to accompany the dockerng execution module.

   Why Make a Second Docker State Module?
   We  have  received  a  lot  of  feedback  on our Docker support. In the
   process of implementing recommended  improvements,  it  became  obvious
   that  major changes needed to be made to the functions and return data.
   In the end, a complete rewrite was done.

   The changes being  too  significant,  it  was  decided  that  making  a
   separate  execution  module and state module (called dockerng) would be
   the best option. This will give users a couple release cycles to modify
   their  scripts,  SLS  files,  etc. to use the new functionality, rather
   than forcing users to change everything immediately.

   In the Nitrogen release of Salt (due in 2017),  this  execution  module
   will  take  the  place  of  the  default  Docker  execution module, and
   backwards-compatible naming will be maintained for  a  couple  releases
   after  that  to allow users time to replace references to dockerng with
   docker.

   NOTE:
      To pull from a Docker registry, authentication must  be  configured.
      See  here  for more information on how to configure access to docker
      registries in Pillar data.

   salt.states.dockerng.absent(name, force=False)
          Ensure that a container is absent

          name   Name of the container

          force  False Set to True to remove the container even if  it  is
                 running

          Usage Examples:

             mycontainer:
               dockerng.absent

             multiple_containers:
               dockerng.absent:
                 - names:
                   - foo
                   - bar
                   - baz

   salt.states.dockerng.image_absent(name=None, images=None, force=False)
          Ensure  that an image is absent from the Minion. Image names can
          be specified either using repo:tag notation, or  just  the  repo
          name (in which case a tag of latest is assumed).

          images Run  this  state  on  more  than one image at a time. The
                 following two examples accomplish the same thing:

                    remove_images:
                      dockerng.image_absent:
                        - names:
                          - busybox
                          - centos:6
                          - nginx

                    remove_images:
                      dockerng.image_absent:
                        - images:
                          - busybox
                          - centos:6
                          - nginx

                 However, the second example will be a bit  quicker  since
                 Salt  will  do  all the deletions in a single run, rather
                 than executing the state separately on each image (as  it
                 would in the first example).

          force  False  Salt  will  fail to remove any images currently in
                 use by a container.  Set this option to  true  to  remove
                 the image even if it is already present.

                 NOTE:
                    This  option can also be overridden by Pillar data. If
                    the   Minion   has    a    pillar    variable    named
                    dockerng.running.force  which  is set to True, it will
                    turn on this option. This pillar variable can even  be
                    set at runtime. For example:

                        salt myminion state.sls docker_stuff pillar="{dockerng.force: True}"

                    If  this  pillar variable is present and set to False,
                    then it will turn off this option.

                    For more granular control, setting a  pillar  variable
                    named  dockerng.force.image_name  will affect only the
                    named image.

   salt.states.dockerng.image_present(name,     build=None,     load=None,
   force=False,         insecure_registry=False,        client_timeout=60,
   dockerfile=None, **kwargs)
          Ensure that an image is present. The image can either be  pulled
          from  a Docker registry, built from a Dockerfile, or loaded from
          a saved image.   Image  names  can  be  specified  either  using
          repo:tag notation, or just the repo name (in which case a tag of
          latest is assumed).  Repo  identifier  is  mandatory,  we  don't
          assume the default repository is docker hub.

          If  neither  of  the build or load arguments are used, then Salt
          will pull from the configured registries. If the specified image
          already  exists,  it  will  not be pulled unless force is set to
          True. Here is an example of a state that will pull an image from
          the Docker Hub:

             myuser/myimage:mytag:
               dockerng.image_present

          build  Path to directory on the Minion containing a Dockerfile

                    myuser/myimage:mytag:
                      dockerng.image_present:
                        - build: /home/myuser/docker/myimage

                    myuser/myimage:mytag:
                      dockerng.image_present:
                        - build: /home/myuser/docker/myimage
                        - dockerfile: Dockerfile.alternative

                    .. versionadded:: develop

                 The  image  will  be  built  using dockerng.build and the
                 specified image name and tag will be applied to it.

          load   Loads a tar archive created with  dockerng.load  (or  the
                 docker  load  Docker  CLI  command),  and  assigns it the
                 specified repo and tag.

                    myuser/myimage:mytag:
                      dockerng.image_present:
                        - load: salt://path/to/image.tar

          force  False Set  this  parameter  to  True  to  force  Salt  to
                 pull/build/load the image even if it is already present.

          client_timeout
                 Timeout  in  seconds for the Docker client. This is not a
                 timeout for the state, but for receiving a response  from
                 the API.

          dockerfile
                 Allows  for  an  alternative  Dockerfile to be specified.
                 Path to alternative Dockefile is relative  to  the  build
                 path for the Docker container.

                 New in version develop.

   salt.states.dockerng.network_absent(name, driver=None)
          Ensure that a network is absent.

          name   Name of the network

          Usage Examples:

             network_foo:
               dockerng.network_absent

   salt.states.dockerng.network_present(name,                 driver=None,
   containers=None)
          Ensure that a network is present.

          name   Name of the network

          driver Type of driver for that network.

          containers:
                 List of container names  that  should  be  part  of  this
                 network

          Usage Examples:

             network_foo:
               dockerng.network_present

             network_bar:
               dockerng.network_present
                 - name: bar
                 - containers:
                     - cont1
                     - cont2

   salt.states.dockerng.running(name,       image=None,       force=False,
   stop_timeout=10,     validate_ip_addrs=True,      watch_action='force',
   client_timeout=60, start=True, **kwargs)
          Ensure that a container with a specific configuration is present
          and running

          name   Name of the container

          image  Image to use  for  the  container.  Image  names  can  be
                 specified  either  using  repo:tag  notation, or just the
                 repo name (in which case a tag of latest is assumed).

                 NOTE:
                    This state will pull the image if it is  not  present.
                    However,  if  the  image  needs  to  be  built  from a
                    Dockerfile or loaded from a saved  image,  or  if  you
                    would  like to use requisites to trigger a replacement
                    of the container when the image is updated,  then  the
                    dockerng.image_present  should  be  used to manage the
                    image.

          force  False Set  this  parameter  to  True  to  force  Salt  to
                 re-create the container irrespective of whether or not it
                 is configured as desired.

          stop_timeout
                 10 If the container needs to be replaced,  the  container
                 will  be  stopped  using dockerng.stop. The value of this
                 parameter will be passed to dockerng.stop as the  timeout
                 value,  telling  Docker  how  long to wait for a graceful
                 shutdown before killing the container.

          validate_ip_addrs
                 True For parameters which accept IP addresses  as  input,
                 IP  address validation will be performed. To disable, set
                 this to False

          watch_action
                 force Control what type of  action  is  taken  when  this
                 state watches another state that has changes. The default
                 action is force, which runs the state with force  set  to
                 True, triggering a rebuild of the container.

                 If  any other value is passed, it will be assumed to be a
                 kill signal.  If  the  container  matches  the  specified
                 configuration, and is running, then the action will be to
                 send that signal to the container. Kill  signals  can  be
                 either  strings  or  numbers,  and  are  defined  in  the
                 Standard Signals section of the  signal(7)  manpage.  Run
                 man  7 signal on a Linux host to browse this manpage. For
                 example:

                    mycontainer:
                      dockerng.running:
                        - image: busybox
                        - watch_action: SIGHUP
                        - watch:
                          - file: some_file

                 NOTE:
                    If  the   container   differs   from   the   specified
                    configuration,  or  is  not  running,  then instead of
                    sending a signal to the container, the container  will
                    be re-created/started and no signal will be sent.

          client_timeout
                 Timeout  in  seconds for the Docker client. This is not a
                 timeout for this function, but for receiving  a  response
                 from the API.

                 NOTE:
                    This  is only used if Salt needs to pull the requested
                    image.

          CONTAINER CONFIGURATION PARAMETERS

          command or cmd
                 Command to run in the container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - command: bash

                 OR

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cmd: bash

                 Changed in version 2015.8.1: cmd is now also accepted

          hostname
                 Hostname of the container. If not provided, and if a name
                 has  been provided, the hostname will default to the name
                 that was passed.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - hostname: web1

                 WARNING:
                    hostname cannot be set if network_mode is set to host.
                    The below example will result in an error:

                        foo:
                          dockerng.running:
                            - image: bar/baz:latest
                            - hostname: web1
                            - network_mode: host

          domainname
                 Domain name of the container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - hostname: domain.tld

          interactive
                 False Leave stdin open

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - interactive: True

          tty    False Attach TTYs

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - tty: True

          detach True   If  True,  run  the  container's  command  in  the
                 background (daemon mode)

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - detach: False

          user   User under which to run docker

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - user: foo

          memory 0 Memory limit.  Can  be  specified  in  bytes  or  using
                 single-letter  units  (i.e. 512M, 2G, etc.). A value of 0
                 (the default) means no memory limit.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - memory: 512M

          memory_swap
                 -1 Total memory limit (memory plus swap). Set  to  -1  to
                 disable swap. A value of 0 means no swap limit.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - memory_swap: 1G

          mac_address
                 MAC address to use for the container. If not specified, a
                 random MAC address will be used.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - mac_address: 01:23:45:67:89:0a

          network_disabled
                 False If True, networking will  be  disabled  within  the
                 container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - network_disabled: True

          working_dir
                 Working directory inside the container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - working_dir: /var/log/nginx

          entrypoint
                 Entrypoint for the container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - entrypoint: "mycmd --arg1 --arg2"

                 The  entrypoint  can  also  be  specified  as  a  list of
                 arguments:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - entrypoint:
                          - mycmd
                          - --arg1
                          - --arg2

          environment
                 Either a list of variable/value mappings, or  a  list  of
                 strings  in  the  format  VARNAME=value.  The  below  two
                 examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - environment:
                          - VAR1: value
                          - VAR2: value

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - environment:
                          - VAR1=value
                          - VAR2=value

                 NOTE:
                    Values  must  be  strings.  Otherwise   it   will   be
                    considered as an error.

          ports  A list of ports to expose on the container. Can either be
                 a comma-separated list or a YAML list. If the protocol is
                 omitted,  the  port will be assumed to be a TCP port. The
                 below two examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - ports: 1111,2222/udp

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - ports:
                          - 1111
                          - 2222/udp

          volumes
                 None List of directories to expose as volumes. Can either
                 be  a  comma-separated list or a YAML list. The below two
                 examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - volumes: /mnt/vol1,/mnt/vol2

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - volumes:
                          - /mnt/vol1
                          - /mnt/vol2

          cpu_shares
                 CPU shares (relative weight)

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cpu_shares: 0.5

          cpuset CPUs on which which to allow execution,  specified  as  a
                 string containing a range (e.g. 0-3) or a comma-separated
                 list of CPUs (e.g. 0,1).

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cpuset: "0,1"

          binds  Files/directories to bind mount. Each bind  mount  should
                 be          passed          in         the         format
                 <host_path>:<container_path>:<read_only>,           where
                 <read_only>  is  one  of rw (for read-write access) or ro
                 (for read-only access).

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - binds: /srv/www:/var/www:ro,/etc/foo.conf:/usr/local/etc/foo.conf:rw

                 Binds  can  be  passed  as  a  YAML  list  instead  of  a
                 comma-separated list:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - binds:
                          - /srv/www:/var/www:ro
                          - /home/myuser/conf/foo.conf:/etc/foo.conf:rw

                 Optionally, the read-only information can be left off the
                 end and the bind mount will be assumed to be  read-write.
                 The example below is equivalent to the one above:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - binds:
                          - /srv/www:/var/www:ro
                          - /home/myuser/conf/foo.conf:/etc/foo.conf

          port_bindings
                 Bind exposed ports. Port bindings should be passed in the
                 same way as the --publish argument to the docker run  CLI
                 command:

                 * ip:hostPort:containerPort - Bind a specific IP and port
                   on the host to a specific port within the container.

                 * ip::containerPort - Bind a specific IP and an ephemeral
                   port to a specific port within the container.

                 * hostPort:containerPort - Bind a specific port on all of
                   the host's interfaces to a  specific  port  within  the
                   container.

                 * containerPort  -  Bind  an ephemeral port on all of the
                   host's  interfaces  to  a  specific  port  within   the
                   container.

                 Multiple  bindings  can be separated by commas, or passed
                 as a Python list. The below two examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - port_bindings: "5000:5000,2123:2123/udp,8080"

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - port_bindings:
                          - 5000:5000
                          - 2123:2123/udp
                          - "8080"

                 NOTE:
                    When configuring bindings for UDP ports, the  protocol
                    must  be passed in the containerPort value, as seen in
                    the examples above.

          lxc_conf
                 Additional LXC configuration  parameters  to  set  before
                 starting the container.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - lxc_conf:
                          - lxc.utsname: docker

                 NOTE:
                    These  LXC configuration parameters will only have the
                    desired effect if  the  container  is  using  the  LXC
                    execution  driver,  which has not been the default for
                    some time.

          security_opt:
                 Security configuration for MLS systems  such  as  SELinux
                 and AppArmor.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - security_opts:
                          - 'apparmor:unconfined'

                 NOTE:
                    See    the    documentation    for   security_opt   at
                    https://docs.docker.com/engine/reference/run/#security-configuration

          publish_all_ports
                 False  Allocates a random host port for each port exposed
                 using the ports parameter

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - ports: 8080
                        - publish_all_ports: True

          links  Link this container to another. Links should be specified
                 in    the   format   <container_name_or_id>:<link_alias>.
                 Multiple links can be passed, either as a comma separated
                 list   or  a  YAML  list.  The  below  two  examples  are
                 equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - links: web1:link1,web2:link2

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - links:
                          - web1:link1
                          - web2:link2

          dns    List  of  DNS   nameservers.   Can   be   passed   as   a
                 comma-separated  list  or  a  YAML  list.  The  below two
                 examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - dns: 8.8.8.8,8.8.4.4

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - dns:
                          - 8.8.8.8
                          - 8.8.4.4

                 NOTE:
                    To     skip     IP     address     validation,     use
                    validate_ip_addrs=False

          dns_search
                 List   of   DNS  search  domains.  Can  be  passed  as  a
                 comma-separated list  or  a  YAML  list.  The  below  two
                 examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - dns_search: foo1.domain.tld,foo2.domain.tld

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - dns_search:
                          - foo1.domain.tld
                          - foo2.domain.tld

          volumes_from
                 Container  names or IDs from which the container will get
                 volumes. Can be passed as a  comma-separated  list  or  a
                 YAML list. The below two examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - volumes_from: foo

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - volumes_from:
                          - foo

          network_mode
                 bridge One of the following:

                 * bridge  - Creates a new network stack for the container
                   on the docker bridge

                 * null - No networking  (equivalent  of  the  Docker  CLI
                   argument --net=none)

                 * container:<name_or_id>  -  Reuses  another  container's
                   network stack

                 * host  -  Use  the  host's  network  stack  inside   the
                   container

                 * Any name that identifies an existing network that might
                   be created with dockerng.network_present.

                   WARNING:
                      Using host mode gives the container full  access  to
                      the  hosts system's services (such as D-bus), and is
                      therefore considered insecure.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - network_mode: null

          restart_policy
                 Set a restart policy for the container. Must be passed as
                 a  string in the format policy[:retry_count] where policy
                 is one of always or on-failure,  and  retry_count  is  an
                 optional  limit to the number of retries. The retry count
                 is ignored when using the always restart policy.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - restart_policy: on-failure:5

                    bar:
                      dockerng.running:
                        - image: bar/baz:latest
                        - restart_policy: always

          cap_add
                 List of capabilities to add within the container. Can  be
                 passed  as  a  comma-separated list or a Python list. The
                 below two examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cap_add: SYS_ADMIN,MKNOD

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cap_add:
                          - SYS_ADMIN
                          - MKNOD

                 NOTE:
                    This option requires Docker 1.2.0 or newer.

          cap_drop
                 List of capabilities to drop within the container. Can be
                 passed  as  a  comma-separated list or a Python list. The
                 below two examples are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cap_drop: SYS_ADMIN,MKNOD

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - cap_drop:
                          - SYS_ADMIN
                          - MKNOD

                 NOTE:
                    This option requires Docker 1.2.0 or newer.

          privileged
                 Give extended privileges to container.

          extra_hosts
                 Additional hosts to add  to  the  container's  /etc/hosts
                 file. Can be passed as a comma-separated list or a Python
                 list. The below two exampels are equivalent:

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - extra_hosts: web1:10.9.8.7,web2:10.9.8.8

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - extra_hosts:
                          - web1:10.9.8.7
                          - web2:10.9.8.8

                 NOTE:
                    To     skip     IP     address     validation,     use
                    validate_ip_addrs=False

                 NOTE:
                    This option requires Docker 1.3.0 or newer.

          pid_mode
                 Set  to  host  to  use the host container's PID namespace
                 within the container

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - pid_mode: host

                 NOTE:
                    This option requires Docker 1.5.0 or newer.

          labels Add  Metadata  to  the  container.  Can  be  a  list   of
                 strings/dictionaries or a dictionary of strings (keys and
                 values).

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - labels:
                            - LABEL1
                            - LABEL2

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - labels:
                            KEY1: VALUE1
                            KEY2: VALUE2

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - labels:
                          - KEY1: VALUE1
                          - KEY2: VALUE2

          start  True Set to False to suppress starting of  the  container
                 if  it  exists, matches the desired configuration, but is
                 not running. This is useful for data-only containers,  or
                 for  non-daemonized  container  processes,  such  as  the
                 django migrate and collectstatic commands.  In  instances
                 such  as this, the container only needs to be started the
                 first time.

          stop_signal
                 Specify the signal docker will send to the container when
                 stopping.   Useful  when  running systemd as PID 1 inside
                 the container.

                    foo:
                      dockerng.running:
                        - image: bar/baz:latest
                        - stop_signal: SIGRTMIN+3

                 NOTE:
                    This  option  requires  Docker  1.9.0  or  newer   and
                    docker-py 1.7.0 or newer.

                 New in version 2016.11.0.

   salt.states.dockerng.stopped(name=None,                containers=None,
   stop_timeout=10, unpause=False, error_on_absent=True)
          Ensure that a container (or containers) is stopped

          name   Name or ID of the container

          containers
                 Run this state on more than one container at a time.  The
                 following two examples accomplish the same thing:

                    stopped_containers:
                      dockerng.stopped:
                        - names:
                          - foo
                          - bar
                          - baz

                    stopped_containers:
                      dockerng.stopped:
                        - containers:
                          - foo
                          - bar
                          - baz

                 However,  the  second example will be a bit quicker since
                 Salt will stop all specified containers in a single  run,
                 rather  than executing the state separately on each image
                 (as it would in the first example).

          stop_timeout
                 10 Timeout for graceful shutdown  of  the  container.  If
                 this timeout is exceeded, the container will be killed.

          unpause
                 False Set to True to unpause any paused containers before
                 stopping. If unset, then an error will be raised for  any
                 container that was paused.

          error_on_absent
                 True  By  default, this state will return an error if any
                 of the specified containers are absent. Set this to False
                 to suppress that error.

   salt.states.dockerng.volume_absent(name, driver=None)
          Ensure that a volume is absent.

          New in version 2015.8.4.

          name   Name of the volume

          Usage Examples:

             volume_foo:
               dockerng.volume_absent

   salt.states.dockerng.volume_present(name,                  driver=None,
   driver_opts=None, force=False)
          Ensure that a volume is present.

          New in version 2015.8.4.

          Changed in version 2015.8.6: This function no longer deletes and
          re-creates  a  volume  if  the existing volume's driver does not
          match the driver parameter (unless the force parameter is set to
          True).

          name   Name of the volume

          driver Type  of  driver for that volume.  If None and the volume
                 does not yet exist, the  volume  will  be  created  using
                 Docker's  default  driver.   If  None and the volume does
                 exist, this function does nothing, even if  the  existing
                 volume's  driver  is  not the Docker default driver.  (To
                 ensure that  an  existing  volume's  driver  matches  the
                 Docker default, you must explicitly name Docker's default
                 driver here.)

          driver_opts
                 Options for the volume driver

          force  False If the  volume  already  exists  but  the  existing
                 volume's  driver  does  not match the driver specified by
                 the driver parameter, this parameter controls whether the
                 function  errors out (if False) or deletes and re-creates
                 the volume (if True).

                 New in version 2015.8.6.

          Usage Examples:

             volume_foo:
               dockerng.volume_present

             volume_bar:
               dockerng.volume_present
                 - name: bar
                 - driver: local
                 - driver_opts:
                     foo: bar

             volume_bar:
               dockerng.volume_present
                 - name: bar
                 - driver: local
                 - driver_opts:
                     - foo: bar
                     - option: value

   salt.states.drac
   Management of Dell DRAC

   The DRAC module is used to create and manage DRAC cards on Dell servers

   Ensure the user damian is present

          damian:
            drac.present:
              - name: damian
              - password: secret
              - permission: login,test_alerts,clear_logs

   Ensure the user damian does not exist

          damian:
            drac.absent:
              - name: damian

   Ensure DRAC network is in a consistent state

          my_network:
            drac.network:
              - ip: 10.225.108.29
              - netmask: 255.255.255.224
              - gateway: 10.225.108.1

   salt.states.drac.absent(name)
          Ensure a user does not exist on the Dell DRAC

          name:  The users username

   salt.states.drac.network(ip, netmask, gateway)
          Ensure the DRAC network settings are consistent

   salt.states.drac.present(name, password, permission)
          Ensure the user exists on the Dell DRAC

          name:  The users username

          password
                 The password used to authenticate

          permission
                 The permissions that should be assigned to a user

   salt.states.elasticsearch_index
   State module to manage Elasticsearch indices

   New in version 2015.8.0.

   salt.states.elasticsearch_index.absent(name)
          Ensure that the named index is absent

   salt.states.elasticsearch_index.present(name, definition)
          Ensure that the named index is present

   salt.states.elasticsearch_index_template
   State module to manage Elasticsearch index templates

   New in version 2015.8.0.

   salt.states.elasticsearch_index_template.absent(name)
          Ensure that the named index template is absent

   salt.states.elasticsearch_index_template.present(name, definition=None)
          Ensure that the named index template is present

   salt.states.environ
   Support for getting  and  setting  the  environment  variables  of  the
   current salt process.

   salt.states.environ.setenv(name,       value,       false_unsets=False,
   clear_all=False, update_minion=False, permanent=False)
          Set the salt process environment variables.

          name   The environment key to set. Must be a string.

          value  Either a string or dict. When  string,  it  will  be  the
                 value  set for the environment key of 'name' above.  When
                 a dict, each key/value  pair  represents  an  environment
                 variable to set.

          false_unsets
                 If  a key's value is False and false_unsets is True, then
                 the  key  will  be  removed  from  the   salt   processes
                 environment  dict entirely. If a key's value is False and
                 false_unsets is not True, then the key's  value  will  be
                 set to an empty string.  Default: False

          clear_all
                 USE  WITH  CAUTION!  This  option  can  unset environment
                 variables needed  for  salt  to  function  properly.   If
                 clear_all  is  True,  then  any environment variables not
                 defined in the environ dict will  be  deleted.   Default:
                 False

          update_minion
                 If   True,  apply  these  environ  changes  to  the  main
                 salt-minion process. If False, the environ  changes  will
                 only affect the current salt subprocess.  Default: False

          permanent
                 On Windows minions this will set the environment variable
                 in  the  registry  so  that  it  is  always  added  as  a
                 environment  variable when applications open. If you want
                 to set the variable to HKLM instead of HKCU just pass  in
                 "HKLM" for this parameter. On all other minion types this
                 will be ignored. Note: This  will  only  take  affect  on
                 applications opened after this has been set.

          Example:

             a_string_env:
                environ.setenv:
                  - name: foo
                  - value: bar
                  - update_minion: True

             a_dict_env:
                environ.setenv:
                  - name: does_not_matter
                  - value:
                      foo: bar
                      baz: quux

   salt.states.eselect
   Management of Gentoo configuration using eselect
   A state module to manage Gentoo configuration via eselect

      profile:
          eselect.set:
              target: hardened/linux/amd64

   salt.states.eselect.set(name,       target,      module_parameter=None,
   action_parameter=None)
          Verify that the given module is set to the given target

          name   The name of the module

          target The target to be set for this module

          module_parameter
                 additional params passed to the defined module

          action_parameter
                 additional params passed to the defined action

   salt.states.etcd_mod
   Manage etcd Keys
   New in version 2015.8.0.

   depends

          * python-etcd

   This state module supports setting and removing keys from etcd.

   Configuration
   To work with an etcd server you must configure  an  etcd  profile.  The
   etcd  config can be set in either the Salt Minion configuration file or
   in pillar:

      my_etd_config:
        etcd.host: 127.0.0.1
        etcd.port: 4001

   It is technically possible to configure etcd without using  a  profile,
   but  this  is  not  considered  to  be a best practice, especially when
   multiple etcd servers or clusters are available.

      etcd.host: 127.0.0.1
      etcd.port: 4001

   NOTE:
      The etcd configuration can also be set in  the  Salt  Master  config
      file,  but  in  order  to use any etcd configurations defined in the
      Salt Master config, the pillar_opts must be set to True.

      Be aware that setting pillar_opts to True has security  implications
      as  this  makes  all  master configuration settings available in all
      minion's pillars.

   Available Functions
   * set

     This will set a value to a key in etcd. Changes will be  returned  if
     the  key  has  been created or the value of the key has been updated.
     This means you can watch these states for changes.

        /foo/bar/baz:
          etcd.set:
            - value: foo
            - profile: my_etcd_config

   * wait_set

     Performs the same functionality as set but only if a watch  requisite
     is True.

        /some/file.txt:
          file.managed:
            - source: salt://file.txt

        /foo/bar/baz:
          etcd.wait_set:
            - value: foo
            - profile: my_etcd_config
            - watch:
              - file: /some/file.txt

   * rm

     This will delete a key from etcd. If the key exists then changes will
     be returned and thus you can watch for changes on the state,  if  the
     key does not exist then no changes will occur.

        /foo/bar/baz:
          etcd.rm:
            - profile: my_etcd_config

   * wait_rm

     Performs  the  same functionality as rm but only if a watch requisite
     is True.

        /some/file.txt:
          file.managed:
            - source: salt://file.txt

        /foo/bar/baz:
          etcd.wait_rm:
            - profile: my_etcd_config
            - watch:
              - file: /some/file.txt

   salt.states.etcd_mod.mod_watch(name, **kwargs)
          Execute a etcd function based on a watch call requisite.

   salt.states.etcd_mod.rm(name, recurse=False, profile=None)
          Deletes a key from etcd. This function is also aliased as rm.

          name   The etcd key name to remove, for example /foo/bar/baz.

          recurse
                 Optional, defaults to False. If True performs a recursive
                 delete.

          profile
                 Optional,  defaults to None. Sets the etcd profile to use
                 which has been defined in the Salt Master config.

   salt.states.etcd_mod.set(name, value, profile=None)
          Set a key in etcd and can be called as set.

          name   The etcd key name, for example: /foo/bar/baz.

          value  The value the key should contain.

          profile
                 Optional, defaults to None. Sets the etcd profile to  use
                 which has been defined in the Salt Master config.

   salt.states.etcd_mod.wait_rm(name, recurse=False, profile=None)
          Deletes  a  key  from etcd only if the watch statement calls it.
          This function is also aliased as wait_rm.

          name   The etcd key name to remove, for example /foo/bar/baz.

          recurse
                 Optional, defaults to False. If True performs a recursive
                 delete,                                              see:
                 https://python-etcd.readthedocs.io/en/latest/#delete-a-key.

          profile
                 Optional,  defaults to None. Sets the etcd profile to use
                 which has been defined in the Salt Master config.

   salt.states.etcd_mod.wait_set(name, value, profile=None)
          Set a key in etcd only if the watch  statement  calls  it.  This
          function is also aliased as wait_set.

          name   The etcd key name, for example: /foo/bar/baz.

          value  The value the key should contain.

          profile
                 The  etcd  profile to use that has been configured on the
                 Salt Master, this is optional and defaults to None.

   salt.states.esxi
   Manage VMware ESXi Hosts.

   New in version 2015.8.4.

   Dependencies
   * pyVmomi Python Module

   * ESXCLI

   pyVmomi
   PyVmomi can be installed via pip:

      pip install pyVmomi

   NOTE:
      Version 6.0 of pyVmomi has some problems with SSL error handling  on
      certain  versions of Python. If using version 6.0 of pyVmomi, Python
      2.6, Python 2.7.9, or newer must be  present.  This  is  due  to  an
      upstream  dependency  in pyVmomi 6.0 that is not supported in Python
      versions 2.7 to 2.7.8. If the  version  of  Python  is  not  in  the
      supported  range,  you  will  need  to install an earlier version of
      pyVmomi. See Issue #29537 for more information.

   Based on the note above, to install an earlier version of pyVmomi  than
   the version currently listed in PyPi, run the following:

      pip install pyVmomi==5.5.0.2014.1.1

   The  5.5.0.2014.1.1  is  a known stable version that this original ESXi
   State Module was developed against.

   ESXCLI
   Currently, about a third of the functions used in the vSphere Execution
   Module  require  the ESXCLI package be installed on the machine running
   the Proxy Minion process.

   The ESXCLI package is also referred to as the VMware  vSphere  CLI,  or
   vCLI.  VMware  provides  vCLI  package  installation  instructions  for
   vSphere 5.5 and vSphere 6.0.

   Once all of the required dependencies are in place and the vCLI package
   is installed, you can check to see if you can connect to your ESXi host
   or vCenter server by running the following command:

      esxcli -s <host-location> -u <username> -p <password> system syslog config get

   If the connection was successful, ESXCLI was successfully installed  on
   your  system.   You should see output related to the ESXi host's syslog
   configuration.

   NOTE:
      Be aware that some functionality in this state module may depend  on
      the type of license attached to the ESXi host.

      For  example,  certain  services  are  only  available to manipulate
      service state or  policies  with  a  VMware  vSphere  Enterprise  or
      Enterprise  Plus license, while others are available with a Standard
      license. The ntpd  service  is  restricted  to  an  Enterprise  Plus
      license, while ssh is available via the Standard license.

      Please see the vSphere Comparison page for more information.

   About
   This  state  module  was  written to be used in conjunction with Salt's
   ESXi Proxy Minion. For a tutorial on  how  to  use  Salt's  ESXi  Proxy
   Minion,   please   refer   to   the  ESXi  Proxy  Minion  Tutorial  for
   configuration examples, dependency installation  instructions,  how  to
   run  remote  execution  functions  against  ESXi hosts via a Salt Proxy
   Minion, and a larger state example.

   salt.states.esxi.coredump_configured(name,      enabled,       dump_ip,
   host_vnic='vmk0', dump_port=6500)
          Ensures a host's core dump configuration.

          name   Name of the state.

          enabled
                 Sets  whether  or not ESXi core dump collection should be
                 enabled.  This is a boolean value set to True or False to
                 enable or disable core dumps.

                 Note  that  ESXi  requires  that  the  core  dump must be
                 enabled before any other parameters may be set. This also
                 affects   the   changes   results  in  the  state  return
                 dictionary. If enabled is  False,  we  can't  obtain  any
                 previous  settings  to  compare  other  state  variables,
                 resulting in many old references returning None.

                 Once enabled is True the changes  dictionary  comparisons
                 will  be more accurate. This is due to the way the system
                 coredemp network configuration command returns data.

          dump_ip
                 The IP address of host that will accept the dump.

          host_vnic
                 Host VNic port through which to communicate. Defaults  to
                 vmk0.

          dump_port
                 TCP port to use for the dump. Defaults to 6500.

          Example:

             configure-host-coredump:
               esxi.coredump_configured:
                 - enabled: True
                 - dump_ip: 'my-coredump-ip.example.com'

   salt.states.esxi.ntp_configured(name,                  service_running,
   ntp_servers=None,      service_policy=None,      service_restart=False,
   update_datetime=False)
          Ensures  a  host's  NTP server configuration such as setting NTP
          servers, ensuring the NTP  daemon  is  running  or  stopped,  or
          restarting the NTP daemon for the ESXi host.

          name   Name of the state.

          service_running
                 Ensures the running state of the ntp daemon for the host.
                 Boolean value where True indicates that  ntpd  should  be
                 running and False indicates that it should be stopped.

          ntp_servers
                 A list of servers that should be added to the ESXi host's
                 NTP configuration.

          service_policy
                 The policy to set for the NTP service.

                 NOTE:
                    When setting the service policy to off or on, you must
                    quote  the setting. If you don't, the yaml parser will
                    set the string to a boolean, which will cause  trouble
                    checking  for  stateful  changes  and  will error when
                    trying to set the policy on the ESXi host.

          service_restart
                 If set  to  True,  the  ntp  daemon  will  be  restarted,
                 regardless  of  its  previous  running  state. Default is
                 False.

          update_datetime
                 If set to True, the date/time on the given host  will  be
                 updated  to  UTC.   Default setting is False. This option
                 should be used with  caution  since  network  delays  and
                 execution delays can result in time skews.

          Example:

             configure-host-ntp:
               esxi.ntp_configured:
                 - service_running: True
                 - ntp_servers:
                   - 192.174.1.100
                   - 192.174.1.200
                 - service_policy: 'on'
                 - service_restart: True

   salt.states.esxi.password_present(name, password)
          Ensures  the  given  password is set on the ESXi host. Passwords
          cannot be obtained from host, so if a password is  set  in  this
          state, the vsphere.update_host_password function will always run
          (except when using  test=True  functionality)  and  the  state's
          changes dictionary will always be populated.

          The  username  for  which  the  password will change is the same
          username that is used to authenticate against the ESXi host  via
          the  Proxy Minion. For example, if the pillar definition for the
          proxy username is defined as root, then the  username  that  the
          password will be updated for via this state is root.

          name   Name of the state.

          password
                 The new password to change on the host.

          Example:

             configure-host-password:
               esxi.password_present:
                 - password: 'new-bad-password'

   salt.states.esxi.ssh_configured(name,   service_running,  ssh_key=None,
   ssh_key_file=None,     service_policy=None,      service_restart=False,
   certificate_verify=False)
          Manage the SSH configuration for a host including whether or not
          SSH is running or the presence of a given SSH  key.  Note:  Only
          one  ssh  key  can be uploaded for root.  Uploading a second key
          will replace any existing key.

          name   Name of the state.

          service_running
                 Ensures whether or not the SSH service should be  running
                 on  a  host.  Represented  as  a boolean value where True
                 indicates that SSH should be running and False  indicates
                 that SSH should stopped.

                 In  order  to  update  SSH  keys, the SSH service must be
                 running.

          ssh_key
                 Public SSH key to added to the  authorized_keys  file  on
                 the  ESXi  host. You can use ssh_key or ssh_key_file, but
                 not both.

          ssh_key_file
                 File containing the public SSH key to  be  added  to  the
                 authorized_keys  file  on  the  ESXi  host.  You  can use
                 ssh_key_file or ssh_key, but not both.

          service_policy
                 The policy to set for the NTP service.

                 NOTE:
                    When setting the service policy to off or on, you must
                    quote  the setting. If you don't, the yaml parser will
                    set the string to a boolean, which will cause  trouble
                    checking  for  stateful  changes  and  will error when
                    trying to set the policy on the ESXi host.

          service_restart
                 If set to  True,  the  SSH  service  will  be  restarted,
                 regardless  of  its  previous  running  state. Default is
                 False.

          certificate_verify
                 If set to True, the SSL connection must present  a  valid
                 certificate.  Default is False.

          Example:

             configure-host-ssh:
               esxi.ssh_configured:
                 - service_running: True
                 - ssh_key_file: /etc/salt/ssh_keys/my_key.pub
                 - service_policy: 'on'
                 - service_restart: True
                 - certificate_verify: True

   salt.states.esxi.syslog_configured(name, syslog_configs, firewall=True,
   reset_service=True, reset_syslog_config=False, reset_configs=None)
          Ensures  the  specified  syslog  configuration  parameters.   By
          default,  this state will reset the syslog service after any new
          or changed parameters are set successfully.

          name   Name of the state.

          syslog_configs
                 Name of parameter to set (corresponds to the command line
                 switch for esxcli without the double dashes (--))

                 Valid   syslog_config   values   are   logdir,   loghost,
                 logdir-unique,    default-rotate,    default-size,    and
                 default-timeout.

                 Each  syslog_config  option  also  needs  a configuration
                 value to set.  For example, loghost requires URLs  or  IP
                 addresses to use for logging. Multiple log servers can be
                 specified by listing them, comma-separated,  but  without
                 spaces before or after commas

                 (reference:
                 https://blogs.vmware.com/vsphere/2012/04/configuring-multiple-syslog-servers-for-esxi-5.html)

          firewall
                 Enable  the  firewall  rule  set  for syslog. Defaults to
                 True.

          reset_service
                 After a successful  parameter  set,  reset  the  service.
                 Defaults to True.

          reset_syslog_config
                 Resets  the  syslog  service  to  it's  default settings.
                 Defaults to False.  If  set  to  True,  default  settings
                 defined  by  the  list of syslog configs in reset_configs
                 will be reset before running any other syslog settings.

          reset_configs
                 A comma-delimited list of parameters to reset. Only  runs
                 if    reset_syslog_config    is    set    to   True.   If
                 reset_syslog_config is set to True, but no syslog configs
                 are  listed  in reset_configs, then reset_configs will be
                 set to all by default.

                 See syslog_configs parameter above for a  list  of  valid
                 options.

          Example:

             configure-host-syslog:
               esxi.syslog_configured:
                 - syslog_configs:
                     loghost: ssl://localhost:5432,tcp://10.1.0.1:1514
                     default-timeout: 120
                 - firewall: True
                 - reset_service: True
                 - reset_syslog_config: True
                 - reset_configs: loghost,default-timeout

   salt.states.esxi.vmotion_configured(name, enabled, device='vmk0')
          Configures  a host's VMotion properties such as enabling VMotion
          and setting the device VirtualNic that VMotion will use.

          name   Name of the state.

          enabled
                 Ensures whether or not VMotion should  be  enabled  on  a
                 host as a boolean value where True indicates that VMotion
                 should be enabled and False indicates that VMotion should
                 be disabled.

          device The  device  that uniquely identifies the VirtualNic that
                 will be used for VMotion for the host. Defaults to vmk0.

          Example:

             configure-vmotion:
               esxi.vmotion_configured:
                 - enabled: True
                 - device: sample-device

   salt.states.esxi.vsan_configured(name,                         enabled,
   add_disks_to_vsan=False)
          Configures   a  host's  VSAN  properties  such  as  enabling  or
          disabling VSAN, or adding VSAN-eligible disks to the VSAN system
          for the host.

          name   Name of the state.

          enabled
                 Ensures  whether  or not VSAN should be enabled on a host
                 as a boolean value where True indicates that VSAN  should
                 be  enabled  and  False  indicates  that  VSAN  should be
                 disabled.

          add_disks_to_vsan
                 If set to True, any VSAN-eligible  disks  for  the  given
                 host  will be added to the host's VSAN system. Default is
                 False.

          Example:

             configure-host-vsan:
               esxi.vsan_configured:
                 - enabled: True
                 - add_disks_to_vsan: True

   salt.states.event
   Send events through Salt's event system during state runs

   salt.states.event.send(name, data=None,  preload=None,  with_env=False,
   with_grains=False, with_pillar=False, **kwargs)
          Send an event to the Salt Master

          New in version 2014.7.0.

          Accepts the same arguments as the event.send execution module of
          the same name.

          Example:

             # ...snip bunch of states above

             mycompany/mystaterun/status/update:
               event.send:
                 - data:
                     status: "Half-way through the state run!"

             # ...snip bunch of states below

   salt.states.event.wait(name, sfun=None)
          Fire an event on the Salt master event  bus  if  called  from  a
          watch statement

          New in version 2014.7.0.

          Example:

             # Stand up a new web server.
             apache:
               pkg:
                 - installed
                 - name: httpd
               service:
                 - running
                 - enable: True
                 - name: httpd

             # Notify the load balancer to update the pool once Apache is running.
             refresh_pool:
               event:
                 - wait
                 - name: mycompany/loadbalancer/pool/update
                 - data:
                     new_web_server_ip: {{ grains['ipv4'] | first() }}
                 - watch:
                   - pkg: apache

   salt.states.file
   Operations on regular files, special files, directories, and symlinks
   Salt  States can aggressively manipulate files on a system. There are a
   number of ways in which files can be managed.

   Regular files can be enforced with the file.managed state.  This  state
   downloads  files  from  the  salt  master and places them on the target
   system. Managed files can be  rendered  as  a  jinja,  mako,  or  wempy
   template, adding a dynamic component to file management.  An example of
   file.managed which makes use of the jinja templating system would  look
   like this:

      /etc/http/conf/http.conf:
        file.managed:
          - source: salt://apache/http.conf
          - user: root
          - group: root
          - mode: 644
          - template: jinja
          - defaults:
              custom_var: "default value"
              other_var: 123
      {% if grains['os'] == 'Ubuntu' %}
          - context:
              custom_var: "override"
      {% endif %}

   It  is also possible to use the py renderer as a templating option. The
   template would be a  Python  script  which  would  need  to  contain  a
   function  called  run(),  which  returns a string. All arguments to the
   state will be made available to  the  Python  script  as  globals.  The
   returned string will be the contents of the managed file. For example:

      def run():
          lines = ['foo', 'bar', 'baz']
          lines.extend([source, name, user, context])  # Arguments as globals
          return '\n\n'.join(lines)

   NOTE:
      The  defaults  and context arguments require extra indentation (four
      spaces instead of the normal  two)  in  order  to  create  a  nested
      dictionary.  More information.

   If  using  a  template, any user-defined template variables in the file
   defined in source must be passed in using the defaults  and/or  context
   arguments.  The  general  best  practice  is to place default values in
   defaults, with conditional overrides going into context, as seen above.

   The template  will  receive  a  variable  custom_var,  which  would  be
   accessed  in  the  template  using  {{  custom_var }}. If the operating
   system is Ubuntu,  the  value  of  the  variable  custom_var  would  be
   override, otherwise it is the default default value

   The  source parameter can be specified as a list. If this is done, then
   the first file to be matched will be the one that is used. This  allows
   you  to  have  a default file on which to fall back if the desired file
   does not exist on the salt fileserver. Here's an example:

      /etc/foo.conf:
        file.managed:
          - source:
            - salt://foo.conf.{{ grains['fqdn'] }}
            - salt://foo.conf.fallback
          - user: foo
          - group: users
          - mode: 644
          - backup: minion

   NOTE:
      Salt supports backing up managed files via the  backup  option.  For
      more  details  on  this  functionality please review the backup_mode
      documentation.

   The  source  parameter  can  also  specify  a  file  in  another   Salt
   environment.   In  this example foo.conf in the dev environment will be
   used instead.

      /etc/foo.conf:
        file.managed:
          - source:
            - salt://foo.conf?saltenv=dev
          - user: foo
          - group: users
          - mode: '0644'

   WARNING:
      When using a mode that includes a leading zero  you  must  wrap  the
      value  in  single  quotes.  If the value is not wrapped in quotes it
      will be read by YAML as an integer and evaluated as an octal.

   The names parameter, which is part of the state compiler, can  be  used
   to  expand  the  contents  of a single state declaration into multiple,
   single state declarations. Each item in the names list receives its own
   individual state name and is converted into its own low-data structure.
   This  is  a  convenient  way  to  manage  several  files  with  similar
   attributes.

   There is more documentation about this feature in the Names declaration
   section of the
      Highstate docs.

   Special files can be managed via the mknod function. This function will
   create  and  enforce  the  permissions  on a special file. The function
   supports the creation of character devices,  block  devices,  and  fifo
   pipes.  The  function  will  create  the  directory structure up to the
   special file if it is needed on  the  minion.  The  function  will  not
   overwrite  or  operate on (change major/minor numbers) existing special
   files with the exception of user, group, and permissions. In most cases
   the  creation  of  some  special  files require root permisisons on the
   minion. This would require that the minion to be run as the root  user.
   Here is an example of a character device:

      /var/named/chroot/dev/random:
        file.mknod:
          - ntype: c
          - major: 1
          - minor: 8
          - user: named
          - group: named
          - mode: 660

   Here is an example of a block device:

      /var/named/chroot/dev/loop0:
        file.mknod:
          - ntype: b
          - major: 7
          - minor: 0
          - user: named
          - group: named
          - mode: 660

   Here is an example of a fifo pipe:

      /var/named/chroot/var/log/logfifo:
        file.mknod:
          - ntype: p
          - user: named
          - group: named
          - mode: 660

   Directories  can  be  managed via the directory function. This function
   can create and enforce the permissions  on  a  directory.  A  directory
   statement will look like this:

      /srv/stuff/substuf:
        file.directory:
          - user: fred
          - group: users
          - mode: 755
          - makedirs: True

   If  you  need  to  enforce  user  and/or group ownership or permissions
   recursively on the directory's contents, you can  do  so  by  adding  a
   recurse directive:

      /srv/stuff/substuf:
        file.directory:
          - user: fred
          - group: users
          - mode: 755
          - makedirs: True
          - recurse:
            - user
            - group
            - mode

   As  a  default, mode will resolve to dir_mode and file_mode, to specify
   both directory and file permissions, use this form:

      /srv/stuff/substuf:
        file.directory:
          - user: fred
          - group: users
          - file_mode: 744
          - dir_mode: 755
          - makedirs: True
          - recurse:
            - user
            - group
            - mode

   Symlinks can be easily created; the symlink function is very simple and
   only takes a few arguments:

      /etc/grub.conf:
        file.symlink:
          - target: /boot/grub/grub.conf

   Recursive  directory  management  can  also  be  set  via  the  recurse
   function. Recursive directory management allows for a directory on  the
   salt  master  to  be  recursively  copied down to the minion. This is a
   great tool for deploying large code and configuration systems. A  state
   using recurse would look something like this:

      /opt/code/flask:
        file.recurse:
          - source: salt://code/flask
          - include_empty: True

   A more complex recurse example:

      {% set site_user = 'testuser' %}
      {% set site_name = 'test_site' %}
      {% set project_name = 'test_proj' %}
      {% set sites_dir = 'test_dir' %}

      django-project:
        file.recurse:
          - name: {{ sites_dir }}/{{ site_name }}/{{ project_name }}
          - user: {{ site_user }}
          - dir_mode: 2775
          - file_mode: '0644'
          - template: jinja
          - source: salt://project/templates_dir
          - include_empty: True

   Retention  scheduling  can  be  applied  to  manage  contents of backup
   directories.  For example:

      /var/backups/example_directory:
        file.retention_schedule:
          - strptime_format: example_name_%Y%m%dT%H%M%S.tar.bz2
          - retain:
              most_recent: 5
              first_of_hour: 4
              first_of_day: 14
              first_of_week: 6
              first_of_month: 6
              first_of_year: all

   salt.states.file.absent(name)
          Make sure that the named file or  directory  is  absent.  If  it
          exists, it will be deleted. This will work to reverse any of the
          functions in the file state module. If a directory is  supplied,
          it will be recursively deleted.

          name   The path which should be deleted

   salt.states.file.accumulated(name, filename, text, **kwargs)
          Prepare   accumulator   which   can   be  used  in  template  in
          file.managed state.  Accumulator dictionary becomes available in
          template. It can also be used in file.blockreplace.

          name   Accumulator name

          filename
                 Filename   which  would  receive  this  accumulator  (see
                 file.managed state documentation about name)

          text   String or list for adding in accumulator

          require_in / watch_in
                 One of them required for  sure  we  fill  up  accumulator
                 before we manage the file. Probably the same as filename

          Example:

          Given the following:

             animals_doing_things:
               file.accumulated:
                 - filename: /tmp/animal_file.txt
                 - text: ' jumps over the lazy dog.'
                 - require_in:
                   - file: animal_file

             animal_file:
               file.managed:
                 - name: /tmp/animal_file.txt
                 - source: salt://animal_file.txt
                 - template: jinja

          One   might  write  a  template  for  animal_file.txt  like  the
          following:

             The quick brown fox{% for animal in accumulator['animals_doing_things'] %}{{ animal }}{% endfor %}

          Collectively, the above states and template file will produce:

             The quick brown fox jumps over the lazy dog.

          Multiple accumulators can be "chained" together.

          NOTE:
             The 'accumulator' data structure is a Python dictionary.   Do
             not expect any loop over the keys in a deterministic order!

   salt.states.file.append(name,  text=None,  makedirs=False, source=None,
   source_hash=None, template='jinja',  sources=None,  source_hashes=None,
   defaults=None, context=None, ignore_whitespace=True)
          Ensure that some text appears at the end of a file.

          The  text will not be appended if it already exists in the file.
          A single string of text or a list of strings may be appended.

          name   The location of the file to append to.

          text   The text to be appended, which can be a single string  or
                 a list of strings.

          makedirs
                 If  the  file  is  located  in  a  path  without a parent
                 directory, then the state will fail. If makedirs  is  set
                 to  True,  then the parent directories will be created to
                 facilitate the creation of the named  file.  Defaults  to
                 False.

          source A  single  source file to append. This source file can be
                 hosted on either the salt master server, or on an HTTP or
                 FTP  server. Both HTTPS and HTTP are supported as well as
                 downloading directly from Amazon S3 compatible URLs  with
                 both  pre-configured  and  automatic IAM credentials (see
                 s3.get  state   documentation).   File   retrieval   from
                 Openstack   Swift   object   storage   is  supported  via
                 swift://container/object_path   URLs    (see    swift.get
                 documentation).

                 For  files hosted on the salt file server, if the file is
                 located on the master in the directory named spam, and is
                 called eggs, the source string is salt://spam/eggs.

                 If  the  file  is  hosted  on  an HTTP or FTP server, the
                 source_hash argument is also required.

          source_hash

                 This can be one of the following:

                        1. a source hash string

                        2. the URI of a file  that  contains  source  hash
                           strings

                 The  function accepts the first encountered long unbroken
                 alphanumeric string of correct length as a valid hash, in
                 order from most secure to least secure:

                    Type    Length
                    ======  ======
                    sha512     128
                    sha384      96
                    sha256      64
                    sha224      56
                    sha1        40
                    md5         32

                 The file can contain several checksums for several files.
                 Each line must contain both the file name and  the  hash.
                 If  no  file  name is matched, the first hash encountered
                 will be used, otherwise the most  secure  hash  with  the
                 correct source file name will be used.

                 Debian file type *.dsc is supported.

                 Examples:

                    /etc/rc.conf ef6e82e4006dee563d98ada2a2a80a27
                    sha254c8525aee419eb649f0233be91c151178b30f0dff8ebbdcc8de71b1d5c8bcc06a  /etc/resolv.conf
                    ead48423703509d37c4a90e6a0d53e143b6fc268

                 Known issues:
                        If  the  remote server URL has the hash file as an
                        apparent sub-directory of  the  source  file,  the
                        module  will discover that it has already cached a
                        directory where  a  file  should  be  cached.  For
                        example:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz/+md5

          template
                 The  named  templating  engine will be used to render the
                 appended-to  file.   Defaults  to  jinja.  The  following
                 templates are supported:

                 * cheetah

                 * genshi

                 * jinja

                 * mako

                 * py

                 * wempy

          sources
                 A list of source files to append. If the files are hosted
                 on an HTTP or FTP server, the source_hashes  argument  is
                 also required.

          source_hashes
                 A list of source_hashes corresponding to the sources list
                 specified in the sources argument.

          defaults
                 Default context passed to the template.

          context
                 Overrides  default  context  variables  passed   to   the
                 template.

          ignore_whitespace
                 New in version 2015.8.4.

                 Spaces  and  Tabs  in  text  are ignored by default, when
                 searching  for  the  appending  content,  one  space   or
                 multiple  tabs are the same for salt.  Set this option to
                 False if you want to change this behavior.

          Multi-line example:

             /etc/motd:
               file.append:
                 - text: |
                     Thou hadst better eat salt with the Philosophers of Greece,
                     than sugar with the Courtiers of Italy.
                     - Benjamin Franklin

          Multiple lines of text:

             /etc/motd:
               file.append:
                 - text:
                   - Trust no one unless you have eaten much salt with him.
                   - "Salt is born of the purest of parents: the sun and the sea."

          Gather text from multiple template files:

             /etc/motd:
               file:
                   - append
                   - template: jinja
                   - sources:
                     - salt://motd/devops-messages.tmpl
                     - salt://motd/hr-messages.tmpl
                     - salt://motd/general-messages.tmpl

          New in version 0.9.5.

   salt.states.file.blockreplace(name,  marker_start='#--  start   managed
   zone   --',   marker_end='#--   end   managed  zone  --',  source=None,
   source_hash=None, template='jinja',  sources=None,  source_hashes=None,
   defaults=None,   context=None,  content='',  append_if_not_found=False,
   prepend_if_not_found=False, backup='.bak', show_changes=True)
          Maintain an edit in a file in  a  zone  delimited  by  two  line
          markers

          New in version 2014.1.0.

          A  block  of  content  delimited by comments can help you manage
          several  lines  entries  without  worrying  about  old   entries
          removal.  This  can  help  you  maintaining  an  un-managed file
          containing manual edits.  Note: this  function  will  store  two
          copies  of  the  file  in-memory  (the  original version and the
          edited version) in order to detect changes  and  only  edit  the
          targeted file if necessary.

          name   Filesystem path to the file to be edited

          marker_start
                 The  line  content identifying a line as the start of the
                 content block.  Note that the whole line containing  this
                 marker will be considered, so whitespace or extra content
                 before or after the marker is included in final output

          marker_end
                 The line content identifying a line as  the  end  of  the
                 content  block.  Note that the whole line containing this
                 marker will be considered, so whitespace or extra content
                 before  or  after the marker is included in final output.
                 Note: you can use file.accumulated and target this state.
                 All  accumulated  data dictionaries content will be added
                 as new lines in the content

          content
                 The content to be used between the two  lines  identified
                 by marker_start and marker_end

          source The  source  file  to download to the minion, this source
                 file can be hosted on either the salt master  server,  or
                 on  an  HTTP  or  FTP  server.   Both  HTTPS and HTTP are
                 supported as well as downloading directly from Amazon  S3
                 compatible  URLs  with  both pre-configured and automatic
                 IAM credentials. (see s3.get  state  documentation)  File
                 retrieval   from   Openstack   Swift  object  storage  is
                 supported  via  swift://container/object_path  URLs,  see
                 swift.get  documentation.   For  files hosted on the salt
                 file server, if the file is located on the master in  the
                 directory  named  spam,  and  is  called eggs, the source
                 string is salt://spam/eggs. If source is  left  blank  or
                 None  (use  ~  in  YAML),  the file will be created as an
                 empty file and the content will not be managed.  This  is
                 also  the  case when a file already exists and the source
                 is undefined; the  contents  of  the  file  will  not  be
                 changed or managed.

                 If  the  file  is hosted on a HTTP or FTP server then the
                 source_hash argument is also required

                 A list of sources can also be  passed  in  to  provide  a
                 default  source  and a set of fallbacks. The first source
                 in the list that is found  to  exist  will  be  used  and
                 subsequent entries in the list will be ignored.

                    file_override_example:
                      file.managed:
                        - source:
                          - salt://file_that_does_not_exist
                          - salt://file_that_exists

          source_hash

                 This can be one of the following:

                        1. a source hash string

                        2. the  URI  of  a  file that contains source hash
                           strings

                 The function accepts the first encountered long  unbroken
                 alphanumeric string of correct length as a valid hash, in
                 order from most secure to least secure:

                    Type    Length
                    ======  ======
                    sha512     128
                    sha384      96
                    sha256      64
                    sha224      56
                    sha1        40
                    md5         32

                 Using a Source Hash File
                        The file can contain several checksums for several
                        files.  Each  line must contain both the file name
                        and the hash.  If no file  name  is  matched,  the
                        first hash encountered will be used, otherwise the
                        most secure hash with the correct source file name
                        will be used.

                        When  using  a  source  hash  file the source_hash
                        argument needs to be a url, the standard  download
                        urls are supported, ftp, http, salt etc:

                        Example:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.hash

                        The  following  is  an  example  of  the supported
                        source_hash format:

                           /etc/rc.conf ef6e82e4006dee563d98ada2a2a80a27
                           sha254c8525aee419eb649f0233be91c151178b30f0dff8ebbdcc8de71b1d5c8bcc06a  /etc/resolv.conf
                           ead48423703509d37c4a90e6a0d53e143b6fc268

                        Debian file type *.dsc files are also supported.

                 Inserting the Source Hash in the sls Data
                        Examples:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: md5=79eef25f9b0b2c642c62b7f737d4f53f

          template
                 The named templating engine will be used  to  render  the
                 downloaded   file.   Defaults  to  jinja.  The  following
                 templates are supported:

                 * cheetah

                 * genshi

                 * jinja

                 * mako

                 * py

                 * wempy

          context
                 Overrides  default  context  variables  passed   to   the
                 template.

          defaults
                 Default context passed to the template.

          append_if_not_found
                 If markers are not found and set to True then the markers
                 and content will be appended  to  the  file.  Default  is
                 False

          prepend_if_not_found
                 If markers are not found and set to True then the markers
                 and content will be prepended to  the  file.  Default  is
                 False

          backup The file extension to use for a backup of the file if any
                 edit is made.  Set this to False to skip making a backup.

          dry_run
                 Don't make any edits to the file

          show_changes
                 Output a unified diff of the old file and the  new  file.
                 If False return a boolean if any changes were made

          Example of usage with an accumulator and with a variable:

             {% set myvar = 42 %}
             hosts-config-block-{{ myvar }}:
               file.blockreplace:
                 - name: /etc/hosts
                 - marker_start: "# START managed zone {{ myvar }} -DO-NOT-EDIT-"
                 - marker_end: "# END managed zone {{ myvar }} --"
                 - content: 'First line of content'
                 - append_if_not_found: True
                 - backup: '.bak'
                 - show_changes: True

             hosts-config-block-{{ myvar }}-accumulated1:
               file.accumulated:
                 - filename: /etc/hosts
                 - name: my-accumulator-{{ myvar }}
                 - text: "text 2"
                 - require_in:
                   - file: hosts-config-block-{{ myvar }}

             hosts-config-block-{{ myvar }}-accumulated2:
               file.accumulated:
                 - filename: /etc/hosts
                 - name: my-accumulator-{{ myvar }}
                 - text: |
                      text 3
                      text 4
                 - require_in:
                   - file: hosts-config-block-{{ myvar }}

          will generate and maintain a block of content in /etc/hosts:

             # START managed zone 42 -DO-NOT-EDIT-
             First line of content
             text 2
             text 3
             text 4
             # END managed zone 42 --

   salt.states.file.comment(name, regex, char='#', backup='.bak')
          Comment out specified lines in a file.

          name   The full path to the file to be edited

          regex  A  regular  expression used to find the lines that are to
                 be commented; this pattern will be wrapped in parenthesis
                 and  will  move  any preceding/trailing ^ or $ characters
                 outside the parenthesis (e.g., the pattern ^foo$ will  be
                 rewritten as ^(foo)$) Note that you _need_ the leading ^,
                 otherwise each time you run  highstate,  another  comment
                 char will be inserted.

          char   # The character to be inserted at the beginning of a line
                 in order to comment it out

          backup .bak The file will be backed up  before  edit  with  this
                 file extension

                 WARNING:
                    This  backup  will  be  overwritten  each  time  sed /
                    comment / uncomment is called. Meaning the backup will
                    only be useful after the first invocation.

                 Set to False/None to not keep a backup.

          Usage:

             /etc/fstab:
               file.comment:
                 - regex: ^bind 127.0.0.1

          New in version 0.9.5.

   salt.states.file.copy(name,    source,   force=False,   makedirs=False,
   preserve=False,   user=None,   group=None,   mode=None,   subdir=False,
   **kwargs)
          If  the  source  file exists on the system, copy it to the named
          file. The named file will  not  be  overwritten  if  it  already
          exists unless the force option is set to True.

          name   The location of the file to copy to

          source The  location  of  the  file  to  copy  to  the  location
                 specified with name

          force  If the target location is present then the file will  not
                 be  moved,  specify "force: True" to overwrite the target
                 file

          makedirs
                 If the target subdirectories don't exist create them

          preserve
                 New in version 2015.5.0.

                 Set preserve: True to preserve user/group  ownership  and
                 mode  after copying. Default is False. If preserve is set
                 to True, then user/group/mode attributes will be ignored.

          user   New in version 2015.5.0.

                 The user to own the copied file,  this  defaults  to  the
                 user salt is running as on the minion. If preserve is set
                 to True, then this will be ignored

          group  New in version 2015.5.0.

                 The group to own the copied file, this  defaults  to  the
                 group  salt  is  running as on the minion. If preserve is
                 set to True or on Windows this will be ignored

          mode   New in version 2015.5.0.

                 The permissions to set  on  the  copied  file,  aka  644,
                 '0775',  '4664'.   If  preserve is set to True, then this
                 will be ignored.  Not supported on Windows

          subdir New in version 2015.5.0.

                 If the name is a directory then place the file inside the
                 named directory

          NOTE:
             The  copy  function  accepts paths that are local to the Salt
             minion.  This function does not support salt://, http://,  or
             the  other  additional  file  paths  that  are  supported  by
             states.file.managed and states.file.recurse.

   salt.states.file.decode(name, encoded_data=None,  contents_pillar=None,
   encoding_type='base64', checksum='md5')
          Decode an encoded file and write it to disk

          New in version 2016.3.0.

          name   Path of the file to be written.

          encoded_data
                 The  encoded  file. Either this option or contents_pillar
                 must be specified.

          contents_pillar
                 A Pillar path to the encoded file.  Uses  the  same  path
                 syntax   as  pillar.get.  The  hashutil.base64_encodefile
                 function can load encoded  content  into  Pillar.  Either
                 this option or encoded_data must be specified.

          encoding_type
                 base64 The type of encoding.

          checksum
                 md5  The  hashing algorithm to use to generate checksums.
                 Wraps the hashutil.digest execution function.

          Usage:

             write_base64_encoded_string_to_a_file:
               file.decode:
                 - name: /tmp/new_file
                 - encoding_type: base64
                 - contents_pillar: mypillar:thefile

             # or

             write_base64_encoded_string_to_a_file:
               file.decode:
                 - name: /tmp/new_file
                 - encoding_type: base64
                 - encoded_data: |
                     Z2V0IHNhbHRlZAo=

          Be careful with multi-line strings that the YAML indentation  is
          correct.  E.g.,

             write_base64_encoded_string_to_a_file:
               file.decode:
                 - name: /tmp/new_file
                 - encoding_type: base64
                 - encoded_data: |
                     {{ salt.pillar.get('path:to:data') | indent(8) }}

   salt.states.file.directory(name,  user=None,  group=None, recurse=None,
   max_depth=None,    dir_mode=None,    file_mode=None,    makedirs=False,
   clean=False,   require=None,  exclude_pat=None,  follow_symlinks=False,
   force=False, backupname=None, allow_symlink=True,  children_only=False,
   **kwargs)
          Ensure that a named directory is present and has the right perms

          name   The location to create or manage a directory

          user   The  user to own the directory; this defaults to the user
                 salt is running as on the minion

          group  The group ownership set for the directory; this  defaults
                 to  the  group  salt  is  running  as  on  the minion. On
                 Windows, this is ignored

          recurse
                 Enforce  user/group  ownership  and  mode  of   directory
                 recursively.  Accepts a list of strings representing what
                 you would like to recurse.   If  mode  is  defined,  will
                 recurse  on  both  file_mode  and  dir_mode  if  they are
                 defined.  If ignore_files  or  ignore_dirs  is  included,
                 files or directories will be left unchanged respectively.
                 Example:

                    /var/log/httpd:
                      file.directory:
                        - user: root
                        - group: root
                        - dir_mode: 755
                        - file_mode: 644
                        - recurse:
                          - user
                          - group
                          - mode

                 Leave files or directories unchanged:

                    /var/log/httpd:
                      file.directory:
                        - user: root
                        - group: root
                        - dir_mode: 755
                        - file_mode: 644
                        - recurse:
                          - user
                          - group
                          - mode
                          - ignore_dirs

                 New in version 2015.5.0.

          max_depth
                 Limit the recursion depth. The default is no  limit=None.
                 'max_depth' and 'clean' are mutually exclusive.

                 New in version 2016.11.0.

          dir_mode / mode
                 The  permissions mode to set any directories created. Not
                 supported on Windows

          file_mode
                 The permissions mode to set any files created  if  'mode'
                 is  run  in  'recurse'.  This  defaults  to dir_mode. Not
                 supported on Windows

          makedirs
                 If the directory is located in a path  without  a  parent
                 directory,  then  the state will fail. If makedirs is set
                 to True, then the parent directories will be  created  to
                 facilitate the creation of the named file.

          clean  Make  sure  that  only  files that are set up by salt and
                 required by this function are kept. If this option is set
                 then  everything in this directory will be deleted unless
                 it is required.  'clean'  and  'max_depth'  are  mutually
                 exclusive.

          require
                 Require other resources such as packages or files

          exclude_pat
                 When  'clean'  is  set to True, exclude this pattern from
                 removal list and preserve in the destination.

          follow_symlinks
                 False If the desired path is a  symlink  (or  recurse  is
                 defined  and  a  symlink is encountered while recursing),
                 follow it and check the permissions of the directory/file
                 to which the symlink points.

                 New in version 2014.1.4.

          force  If  the  name  of  the  directory  exists  and  is  not a
                 directory and force is set to False, the state will fail.
                 If  force  is  set  to  True,  the file in the way of the
                 directory will be deleted to make room for the directory,
                 unless backupname is set, then it will be renamed.

                 New in version 2014.7.0.

          backupname
                 If  the  name  of  the  directory  exists  and  is  not a
                 directory, it will be renamed to the backupname.  If  the
                 backupname  already  exists and force is False, the state
                 will fail. Otherwise,  the  backupname  will  be  removed
                 first.

                 New in version 2014.7.0.

          allow_symlink
                 True If allow_symlink is True and the specified path is a
                 symlink, it will be allowed to remain if it points  to  a
                 directory.  If allow_symlink is False then the state will
                 fail, unless force is also set to True, in which case  it
                 will be removed or renamed, depending on the value of the
                 backupname argument.

                 New in version 2014.7.0.

          children_only
                 False If children_only is True the  base  of  a  path  is
                 excluded  when  performing a recursive operation. In case
                 of /path/to/base, base  will  be  ignored  while  all  of
                 /path/to/base/* are still operated on.

   salt.states.file.exists(name)
          Verify  that  the  named file or directory is present or exists.
          Ensures pre-requisites outside of Salt's purview (e.g., keytabs,
          private  keys,  etc.)  have  been  previously  satisfied  before
          deployment.

          name   Absolute path which must exist

   salt.states.file.line(name,     content,     match=None,     mode=None,
   location=None,      before=None,     after=None,     show_changes=True,
   backup=False,  quiet=False,   indent=True,   create=False,   user=None,
   group=None, file_mode=None)
          Line-based editing of a file.

          New in version 2015.8.0.

          name   Filesystem path to the file to be edited.

          content
                 Content of the line.

          match  Match  the  target  line for an action by a fragment of a
                 string or regular expression.

                 If neither before nor after are provided,  and  match  is
                 also None, match becomes the content value.

          mode   Defines  how to edit a line. One of the following options
                 is required:

                 *

                   ensure If line does not exist, it will be added.

                 *

                   replace
                          If line already exists, it will be replaced.

                 *

                   delete Delete the line, once found.

                 *

                   insert Insert a line.

                 NOTE:
                    If mode=insert is used, at least one of the  following
                    options  must  also  be  defined: location, before, or
                    after. If location is used, it takes  precedence  over
                    the other two options.

          location
                 Defines  where  to  place  content in the line. Note this
                 option is only used when mode=insert is specified.  If  a
                 location  is passed in, it takes precedence over both the
                 before and after kwargs. Valid locations are:

                 *

                   start  Place the content at the beginning of the file.

                 *

                   end    Place the content at the end of the file.

          before Regular expression or an exact case-sensitive fragment of
                 the  string.   This  option  is only used when either the
                 ensure or insert mode is defined.

          after  Regular expression or an exact case-sensitive fragment of
                 the  string.   This  option  is only used when either the
                 ensure or insert mode is defined.

          show_changes
                 Output a unified diff of the old file and the  new  file.
                 If  False  return  a  boolean  if  any changes were made.
                 Default is True

                 NOTE:
                    Using this option will store two copies  of  the  file
                    in-memory   (the   original  version  and  the  edited
                    version) in order to generate the diff.

          backup Create a backup of the original file with the  extension:
                 "Year-Month-Day-Hour-Minutes-Seconds".

          quiet  Do  not  raise  any exceptions. E.g. ignore the fact that
                 the file that is tried to be edited does  not  exist  and
                 nothing really happened.

          indent Keep  indentation  with the previous line. This option is
                 not considered when the delete mode is specified.

          Parameters

                 * create --

                   Create an empty file if doesn't exists.

                   New in version 2016.11.0.

                 * user --

                   The user to own the file, this  defaults  to  the  user
                   salt is running as on the minion.

                   New in version 2016.11.0.

                 * group --

                   The  group ownership set for the file, this defaults to
                   the group salt is running as on the minion On  Windows,
                   this is ignored.

                   New in version 2016.11.0.

                 * file_mode --

                   The  permissions  to  set  on this file, aka 644, 0775,
                   4664. Not supported on Windows.

                   New in version 2016.11.0.

          If an equal sign (=) appears in an argument to a  Salt  command,
          it  is  interpreted  as  a  keyword  argument  in  the format of
          key=val. That processing can be bypassed in  order  to  pass  an
          equal  sign  through  to  the  remote  shell command by manually
          specifying the kwarg:

   salt.states.file.managed(name,       source=None,       source_hash='',
   source_hash_name=None, user=None, group=None, mode=None, template=None,
   makedirs=False,     dir_mode=None,     context=None,      replace=True,
   defaults=None,      backup='',      show_changes=True,     create=True,
   contents=None, tmp_ext='', contents_pillar=None,  contents_grains=None,
   contents_newline=True,     contents_delimiter=':',    allow_empty=True,
   follow_symlinks=True, check_cmd=None, skip_verify=False, **kwargs)
          Manage a given file, this function  allows  for  a  file  to  be
          downloaded  from  the  salt master and potentially run through a
          templating system.

          name   The location of the file to manage

          source The source file to download to the  minion,  this  source
                 file  can  be  hosted  on  either  the salt master server
                 (salt://), the salt minion local file system (/),  or  on
                 an HTTP or FTP server (http(s)://, ftp://).

                 Both  HTTPS and HTTP are supported as well as downloading
                 directly  from  Amazon  S3  compatible  URLs  with   both
                 pre-configured and automatic IAM credentials. (see s3.get
                 state documentation) File retrieval from Openstack  Swift
                 object        storage        is       supported       via
                 swift://container/object_path   URLs,    see    swift.get
                 documentation.  For files hosted on the salt file server,
                 if the file is located on the  master  in  the  directory
                 named  spam,  and  is  called  eggs, the source string is
                 salt://spam/eggs. If source is left blank or None (use  ~
                 in  YAML),  the file will be created as an empty file and
                 the content will not be managed. This is  also  the  case
                 when  a  file already exists and the source is undefined;
                 the contents of the file will not be changed or managed.

                 If the file is hosted on a HTTP or FTP  server  then  the
                 source_hash argument is also required

                 A  list  of  sources  can  also be passed in to provide a
                 default source and a set of fallbacks. The  first  source
                 in  the  list  that  is  found  to exist will be used and
                 subsequent entries in the list will  be  ignored.  Source
                 list  functionality  only supports local files and remote
                 files hosted on the salt master server or retrievable via
                 HTTP, HTTPS, or FTP.

                    file_override_example:
                      file.managed:
                        - source:
                          - salt://file_that_does_not_exist
                          - salt://file_that_exists

          source_hash

                 This can be one of the following:

                        1. a source hash string

                        2. the  URI  of  a  file that contains source hash
                           strings

                 The function accepts the first encountered long  unbroken
                 alphanumeric string of correct length as a valid hash, in
                 order from most secure to least secure:

                    Type    Length
                    ======  ======
                    sha512     128
                    sha384      96
                    sha256      64
                    sha224      56
                    sha1        40
                    md5         32

                 Using a Source Hash File
                        The file can contain several checksums for several
                        files.  Each  line must contain both the file name
                        and the hash.  If no file  name  is  matched,  the
                        first hash encountered will be used, otherwise the
                        most secure hash with the correct source file name
                        will be used.

                        When  using  a  source  hash  file the source_hash
                        argument needs to be a url, the standard  download
                        urls are supported, ftp, http, salt etc:

                        Example:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.hash

                        The following lines are all supported formats:

                           /etc/rc.conf ef6e82e4006dee563d98ada2a2a80a27
                           sha254c8525aee419eb649f0233be91c151178b30f0dff8ebbdcc8de71b1d5c8bcc06a  /etc/resolv.conf
                           ead48423703509d37c4a90e6a0d53e143b6fc268

                        Debian file type *.dsc files are also supported.

                 Inserting the Source Hash in the SLS Data
                        Examples:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: md5=79eef25f9b0b2c642c62b7f737d4f53f

                 Known issues:
                        If  the  remote server URL has the hash file as an
                        apparent sub-directory of  the  source  file,  the
                        module  will discover that it has already cached a
                        directory where  a  file  should  be  cached.  For
                        example:

                           tomdroid-src-0.7.3.tar.gz:
                             file.managed:
                               - name: /tmp/tomdroid-src-0.7.3.tar.gz
                               - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
                               - source_hash: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz/+md5

          source_hash_name
                 When  source_hash refers to a hash file, Salt will try to
                 find  the  correct  hash  by  matching  the  filename/URI
                 associated with that hash. By default, Salt will look for
                 the filename being managed. When managing a file at  path
                 /tmp/foo.txt,  then  the  following  line  in a hash file
                 would match:

                    acbd18db4cc2f85cedef654fccc4a4d8    foo.txt

                 However, sometimes a  hash  file  will  include  multiple
                 similar paths:

                    37b51d194a7513e45b56f6524f2d51f2    ./dir1/foo.txt
                    acbd18db4cc2f85cedef654fccc4a4d8    ./dir2/foo.txt
                    73feffa4b7f6bb68e44cf984c85f6e88    ./dir3/foo.txt

                 In  cases  like  this, Salt may match the incorrect hash.
                 This argument can be used to tell Salt which filename  to
                 match, to ensure that the correct hash is identified. For
                 example:

                    /tmp/foo.txt:
                      file.managed:
                        - source: https://mydomain.tld/dir2/foo.txt
                        - source_hash: https://mydomain.tld/hashes
                        - source_hash_name: ./dir2/foo.txt

                 NOTE:
                    This argument must contain  the  full  filename  entry
                    from  the  checksum file, as this argument is meant to
                    disambiguate matches for multiple files that have  the
                    same  basename. So, in the example above, simply using
                    foo.txt would not match.

                 New in version 2016.3.5.

          user   The user to own the file, this defaults to the user  salt
                 is running as on the minion

          group  The  group  ownership  set for the file, this defaults to
                 the group salt is running as on the  minion  On  Windows,
                 this is ignored

          mode   The mode to set on this file, e.g. 644, 0775, or 4664.

                 NOTE:
                    This option is not supported on Windows.

                 Changed  in  version 2016.11.0: This option can be set to
                 keep,  and  Salt  will  keep  the  mode  from  the   Salt
                 fileserver.  This  is  only supported when the source URL
                 begins with salt://, or for files local  to  the  minion.
                 Because  the source option cannot be used with any of the
                 contents options,  setting  the  mode  to  keep  is  also
                 incompatible with the contents options.

          template
                 If  this  setting is applied, the named templating engine
                 will be used to render the downloaded file. The following
                 templates are supported:

                 * cheetah

                 * genshi

                 * jinja

                 * mako

                 * py

                 * wempy

          makedirs
                 False If set to True, then the parent directories will be
                 created to facilitate the creation of the named file.  If
                 False,  and  the parent directory of the destination file
                 doesn't exist, the state will fail.

          dir_mode
                 If directories are to be  created,  passing  this  option
                 specifies  the permissions for those directories. If this
                 is not set, directories will be assigned  permissions  by
                 adding the execute bit to the mode of the files.

          replace
                 True  If  set  to  False and the file already exists, the
                 file will not be modified even if changes would otherwise
                 be   made.   Permissions  and  ownership  will  still  be
                 enforced, however.

          context
                 Overrides  default  context  variables  passed   to   the
                 template.

          defaults
                 Default context passed to the template.

          backup Overrides the default backup mode for this specific file.

          show_changes
                 Output  a  unified diff of the old file and the new file.
                 If False return a boolean if any changes were made.

          create True If set to False, then the file will only be  managed
                 if the file already exists on the system.

          contents
                 Specify  the  contents  of  the  file.  Cannot be used in
                 combination with source. Ignores hashes and does not  use
                 a templating engine.

                 This  value  can  be  either a single string, a multiline
                 YAML string or a list of strings.  If a list of  strings,
                 then the strings will be joined together with newlines in
                 the resulting file. For example, the  below  two  example
                 states would result in identical file contents:

                    /path/to/file1:
                      file.managed:
                        - contents:
                          - This is line 1
                          - This is line 2

                    /path/to/file2:
                      file.managed:
                        - contents: |
                            This is line 1
                            This is line 2

          contents_pillar
                 New in version 0.17.0.

                 Operates  like contents, but draws from a value stored in
                 pillar, using the pillar path syntax used in  pillar.get.
                 This  is  useful when the pillar value contains newlines,
                 as referencing  a  pillar  variable  using  a  jinja/mako
                 template  can result in YAML formatting issues due to the
                 newlines causing indentation mismatches.

                 For example, the following could be used to deploy an SSH
                 private key:

                    /home/deployer/.ssh/id_rsa:
                      file.managed:
                        - user: deployer
                        - group: deployer
                        - mode: 600
                        - contents_pillar: userdata:deployer:id_rsa

                 This  would  populate /home/deployer/.ssh/id_rsa with the
                 contents of pillar['userdata']['deployer']['id_rsa'].  An
                 example of this pillar setup would be like so:

                    userdata:
                      deployer:
                        id_rsa: |
                            -----BEGIN RSA PRIVATE KEY-----
                            MIIEowIBAAKCAQEAoQiwO3JhBquPAalQF9qP1lLZNXVjYMIswrMe2HcWUVBgh+vY
                            U7sCwx/dH6+VvNwmCoqmNnP+8gTPKGl1vgAObJAnMT623dMXjVKwnEagZPRJIxDy
                            B/HaAre9euNiY3LvIzBTWRSeMfT+rWvIKVBpvwlgGrfgz70m0pqxu+UyFbAGLin+
                            GpxzZAMaFpZw4sSbIlRuissXZj/sHpQb8p9M5IeO4Z3rjkCP1cxI

                            -----END RSA PRIVATE KEY-----
                 NOTE:
                    The private key above is shortened to keep the example
                    brief, but shows how to do multiline string  in  YAML.
                    The  key  is  followed  by  a  pipe character, and the
                    mutliline string is indented two more spaces.

                    To avoid the hassle of creating an indented  multiline
                    YAML string, the file_tree external pillar can be used
                    instead. However, this will not work for binary  files
                    in Salt releases before 2015.8.4.

          contents_grains
                 New in version 2014.7.0.

                 Operates  like contents, but draws from a value stored in
                 grains, using the grains path syntax used in  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:

                    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:

                    salt '*' grains.set motd 'Welcome! This system is managed by Salt.'

          contents_newline
                 True New in version 2014.7.0.

                 Changed  in  version 2015.8.4: This option is now ignored
                 if the contents being deployed contain binary data.

                 If True, files managed using  contents,  contents_pillar,
                 or  contents_grains  will have a newline added to the end
                 of the file if one is not present. Setting this option to
                 False will omit this final newline.

          contents_delimiter
                 New in version 2015.8.4.

                 Can  be  used  to  specify  an  alternate  delimiter  for
                 contents_pillar or contents_grains. This  delimiter  will
                 be  passed  through  to  pillar.get  or  grains.get  when
                 retrieving the contents.

          allow_empty
                 True New in version 2015.8.4.

                 If set to False, then the state will fail if the contents
                 specified   by  contents_pillar  or  contents_grains  are
                 empty.

          follow_symlinks
                 True New in version 2014.7.0.

                 If the desired path is  a  symlink  follow  it  and  make
                 changes to the file to which the symlink points.

          check_cmd
                 New in version 2014.7.0.

                 The  specified  command  will  be  run  with  an appended
                 argument of a temporary file containing the  new  managed
                 contents.   If  the  command exits with a zero status the
                 new managed contents  will  be  written  to  the  managed
                 destination.  If  the  command  exits with a nonzero exit
                 code, the state will fail and no changes will be made  to
                 the file.

                 For  example,  the  following  could  be  used  to verify
                 sudoers before making changes:

                    /etc/sudoers:
                      file.managed:
                        - user: root
                        - group: root
                        - mode: 0440
                        - source: salt://sudoers/files/sudoers.jinja
                        - template: jinja
                        - check_cmd: /usr/sbin/visudo -c -f

                 NOTE:  This  check_cmd  functions  differently  than  the
                 requisite check_cmd.

          tmp_ext
                 Suffix  for  temp  file  created by check_cmd. Useful for
                 checkers dependant on config  file  extension  (e.g.  the
                 init-checkconf upstart config checker).

                    /etc/init/test.conf:
                      file.managed:
                        - user: root
                        - group: root
                        - mode: 0440
                        - tmp_ext: '.conf'
                        - contents:
                          - 'description "Salt Minion"''
                          - 'start on started mountall'
                          - 'stop on shutdown'
                          - 'respawn'
                          - 'exec salt-minion'
                        - check_cmd: init-checkconf -f

          skip_verify
                 False  If  True, hash verification of remote file sources
                 (http://, https://, ftp://)  will  be  skipped,  and  the
                 source_hash argument will be ignored.

                 New in version 2016.3.0.

   salt.states.file.missing(name)
          Verify that the named file or directory is missing, this returns
          True only if the named file is missing but does not  remove  the
          file if it is present.

          name   Absolute path which must NOT exist

   salt.states.file.mknod(name,   ntype,   major=0,   minor=0,  user=None,
   group=None, mode='0600')
          Create a special file similar to the  'nix  mknod  command.  The
          supported  device types are p (fifo pipe), c (character device),
          and b (block device). Provide the major and minor  numbers  when
          specifying  a character device or block device. A fifo pipe does
          not require  this  information.  The  command  will  create  the
          necessary  dirs if needed. If a file of the same name not of the
          same type/major/minor exists, it  will  not  be  overwritten  or
          unlinked  (deleted).  This  is  logically  in  place as a safety
          measure because you can really shoot yourself in the  foot  here
          and  it  is  the behavior of 'nix mknod. It is also important to
          note that not just anyone can create  special  devices.  Usually
          this  is  only  done  as root.  If the state is executed as none
          other than root on a minion, you may receive a permission error.

          name   name of the file

          ntype  node type 'p' (fifo pipe), 'c' (character device), or 'b'
                 (block device)

          major  major number of the device does not apply to a fifo pipe

          minor  minor number of the device does not apply to a fifo pipe

          user   owning user of the device/pipe

          group  owning group of the device/pipe

          mode   permissions on the device/pipe

          Usage:

             /dev/chr:
               file.mknod:
                 - ntype: c
                 - major: 180
                 - minor: 31
                 - user: root
                 - group: root
                 - mode: 660

             /dev/blk:
               file.mknod:
                 - ntype: b
                 - major: 8
                 - minor: 999
                 - user: root
                 - group: root
                 - mode: 660

             /dev/fifo:
               file.mknod:
                 - ntype: p
                 - user: root
                 - group: root
                 - mode: 660

          New in version 0.17.0.

   salt.states.file.mod_run_check_cmd(cmd, filename, **check_cmd_opts)
          Execute the check_cmd logic.

          Return  a  result  dict  if  check_cmd succeeds (check_cmd == 0)
          otherwise return True

   salt.states.file.patch(name,   source=None,   hash=None,    options='',
   dry_run_first=True, **kwargs)
          Apply a patch to a file or directory.

          NOTE:
             A  suitable  patch executable must be available on the minion
             when using this state function.

          name   The file or directory to which the patch will be applied.

          source The source patch to download to the minion,  this  source
                 file  must  be  hosted  on the salt master server. If the
                 file is located in  the  directory  named  spam,  and  is
                 called  eggs,  the  source  string is salt://spam/eggs. A
                 source is required.

          hash   Hash of the patched file. If the hash of the target  file
                 matches this value then the patch is assumed to have been
                 applied. The hash string is the hash  algorithm  followed
                 by        the        hash        of       the       file:
                 md5=e138491e9d5b97023cea823fe17bac22

          options
                 Extra options to pass to patch.

          dry_run_first
                 True Run patch with --dry-run first to check if  it  will
                 apply cleanly.

          saltenv
                 Specify  the environment from which to retrieve the patch
                 file indicated by the source parameter. If not  provided,
                 this  defaults to the environment from which the state is
                 being executed.

          Usage:

             # Equivalent to ``patch --forward /opt/file.txt file.patch``
             /opt/file.txt:
               file.patch:
                 - source: salt://file.patch
                 - hash: md5=e138491e9d5b97023cea823fe17bac22

   salt.states.file.prepend(name, text=None, makedirs=False,  source=None,
   source_hash=None,  template='jinja',  sources=None, source_hashes=None,
   defaults=None, context=None, header=None)
          Ensure that some text appears at the beginning of a file

          The text will not be prepended again if it already exists in the
          file.  You  may specify a single line of text or a list of lines
          to append.

          Multi-line example:

             /etc/motd:
               file.prepend:
                 - text: |
                     Thou hadst better eat salt with the Philosophers of Greece,
                     than sugar with the Courtiers of Italy.
                     - Benjamin Franklin

          Multiple lines of text:

             /etc/motd:
               file.prepend:
                 - text:
                   - Trust no one unless you have eaten much salt with him.
                   - "Salt is born of the purest of parents: the sun and the sea."

          Optionally, require the text  to  appear  exactly  as  specified
          (order  and position). Combine with multi-line or multiple lines
          of input.

             /etc/motd:
               file.prepend:
                 - header: True
                 - text:
                   - This will be the very first line in the file.
                   - The 2nd line, regardless of duplicates elsewhere in the file.
                   - These will be written anew if they do not appear verbatim.

          Gather text from multiple template files:

             /etc/motd:
               file:
                   - prepend
                   - template: jinja
                   - sources:
                     - salt://motd/devops-messages.tmpl
                     - salt://motd/hr-messages.tmpl
                     - salt://motd/general-messages.tmpl

          New in version 2014.7.0.

   salt.states.file.recurse(name,   source,   clean=False,   require=None,
   user=None,  group=None,  dir_mode=None,  file_mode=None, sym_mode=None,
   template=None,   context=None,   defaults=None,    include_empty=False,
   backup='',     include_pat=None,    exclude_pat=None,    maxdepth=None,
   keep_symlinks=False, force_symlinks=False, **kwargs)
          Recurse through a subdirectory  on  the  master  and  copy  said
          subdirectory over to the specified path.

          name   The directory to set the recursion in

          source The  source  directory,  this directory is located on the
                 salt master file server and is specified with the salt://
                 protocol.  If  the  directory is located on the master in
                 the directory named spam, and is called eggs, the  source
                 string is salt://spam/eggs

          clean  Make  sure  that  only  files that are set up by salt and
                 required by this function are kept. If this option is set
                 then  everything in this directory will be deleted unless
                 it is required.

          require
                 Require other resources such as packages or files

          user   The user to own the directory. This defaults to the  user
                 salt is running as on the minion

          group  The  group ownership set for the directory. This defaults
                 to the group  salt  is  running  as  on  the  minion.  On
                 Windows, this is ignored

          dir_mode
                 The mode to set on any directories created.

                 NOTE:
                    This option is not supported on Windows.

          file_mode
                 The mode to set on any files created.  Windows

                 NOTE:
                    This option is not supported on Windows.

                 Changed  in  version 2016.11.0: This option can be set to
                 keep,  and  Salt  will  keep  the  mode  from  the   Salt
                 fileserver.  This  is  only supported when the source URL
                 begins with salt://, or for files local  to  the  minion.
                 Because  the source option cannot be used with any of the
                 contents options,  setting  the  mode  to  keep  is  also
                 incompatible with the contents options.

          sym_mode
                 The mode to set on any symlink created.

                 NOTE:
                    This option is not supported on Windows.

          template
                 If  this  setting is applied, the named templating engine
                 will be used to render the downloaded file. The following
                 templates are supported:

                 * cheetah

                 * genshi

                 * jinja

                 * mako

                 * py

                 * wempy

                 NOTE:
                    The  template  option  is  required  when  recursively
                    applying templates.

          context
                 Overrides  default  context  variables  passed   to   the
                 template.

          defaults
                 Default context passed to the template.

          include_empty
                 Set  this  to  True  if  empty directories should also be
                 created (default is False)

          include_pat
                 When copying, include only this pattern from the  source.
                 Default is glob match; if prefixed with 'E@', then regexp
                 match.  Example:

                    - include_pat: hello*       :: glob matches 'hello01', 'hello02'
                                                   ... but not 'otherhello'
                    - include_pat: E@hello      :: regexp matches 'otherhello',
                                                   'hello01' ...

          exclude_pat
                 Exclude this pattern from the  source  when  copying.  If
                 both  include_pat  and  exclude_pat are supplied, then it
                 will apply conditions  cumulatively.  i.e.  first  select
                 based  on  include_pat, and then within that result apply
                 exclude_pat.

                 Also, when 'clean=True', exclude this  pattern  from  the
                 removal list and preserve in the destination.  Example:

                    - exclude_pat: APPDATA*               :: glob matches APPDATA.01,
                                                             APPDATA.02,.. for exclusion
                    - exclude_pat: E@(APPDATA)|(TEMPDATA) :: regexp matches APPDATA
                                                             or TEMPDATA for exclusion

          maxdepth
                 When copying, only copy paths which are of depth maxdepth
                 from the source path.  Example:

                    - maxdepth: 0      :: Only include files located in the source
                                          directory
                    - maxdepth: 1      :: Only include files located in the source
                                          or immediate subdirectories

          keep_symlinks
                 Keep symlinks when copying from the source.  This  option
                 will  cause  the  copy  operation  to  terminate  at  the
                 symlink. If desire behavior similar to  rsync,  then  set
                 this to True.

          force_symlinks
                 Force  symlink  creation.  This  option  will  force  the
                 symlink creation.  If a file or directory is  obstructing
                 symlink  creation  it will be recursively removed so that
                 symlink creation can proceed. This option is usually  not
                 needed except in special circumstances.

   salt.states.file.rename(name, source, force=False, makedirs=False)
          If  the source file exists on the system, rename it to the named
          file. The named file will  not  be  overwritten  if  it  already
          exists unless the force option is set to True.

          name   The location of the file to rename to

          source The  location  of  the  file  to  move  to  the  location
                 specified with name

          force  If the target location is present then the file will  not
                 be  moved,  specify "force: True" to overwrite the target
                 file

          makedirs
                 If the target subdirectories don't exist create them

   salt.states.file.replace(name,   pattern,   repl,   count=0,   flags=8,
   bufsize=1,    append_if_not_found=False,    prepend_if_not_found=False,
   not_found_content=None,        backup='.bak',        show_changes=True,
   ignore_if_missing=False)
          Maintain an edit in a file.

          New in version 0.17.0.

          name   Filesystem path to the file to be edited. If a symlink is
                 specified, it will be resolved to its target.

          pattern
                 A  regular  expression,  to  be  matched  using  Python's
                 search().

          repl   The replacement text

          count  Maximum  number  of  pattern  occurrences to be replaced.
                 Defaults to 0.  If count is a positive integer n, no more
                 than  n  occurrences  will  be  replaced,  otherwise  all
                 occurrences will be replaced.

          flags  A list of flags defined in the re  module  documentation.
                 Each  list item should be a string that will correlate to
                 the  human-friendly  flag  name.   E.g.,   ['IGNORECASE',
                 'MULTILINE'].  Optionally,  flags  may  be an int, with a
                 value corresponding to the XOR (|)  of  all  the  desired
                 flags. Defaults to 8 (which equates to ['MULTILINE']).

                 NOTE:
                    file.replace  reads  the  entire  file  as a string to
                    support  multiline  regex  patterns.  Therefore,  when
                    using  anchors  such  as  ^ or $ in the pattern, those
                    anchors may be relative to the line OR relative to the
                    file. The default for file.replace is to treat anchors
                    as relative to  the  line,  which  is  implemented  by
                    setting  the  default value of flags to ['MULTILINE'].
                    When  overriding  the  default  value  for  flags,  if
                    'MULTILINE'  is  not  present  then  anchors  will  be
                    relative to the file. If the desired behavior  is  for
                    anchors  to  be  relative to the line, then simply add
                    'MULTILINE' to the list of flags.

          bufsize
                 How much of the file to buffer into memory at  once.  The
                 default value 1 processes one line at a time. The special
                 value file may be specified which will  read  the  entire
                 file into memory before processing.

          append_if_not_found
                 False  If set to True, and pattern is not found, then the
                 content will be appended to the file.

                 New in version 2014.7.0.

          prepend_if_not_found
                 False If set to True and pattern is not found,  then  the
                 content will be prepended to the file.

                 New in version 2014.7.0.

          not_found_content
                 Content  to  use for append/prepend if not found. If None
                 (default), uses repl. Useful when repl uses references to
                 group in pattern.

                 New in version 2014.7.0.

          backup The file extension to use for a backup of the file before
                 editing. Set to False to skip making a backup.

          show_changes
                 True Output a unified diff of the old file  and  the  new
                 file. If False return a boolean if any changes were made.
                 Returns a boolean or a string.

          ignore_if_missing
                 False New in version 2016.3.4.

                 Controls what to do if the file is  missing.  If  set  to
                 False,  the  state  will  display  an error raised by the
                 execution module. If set to True, the state  will  simply
                 report no changes.

          For  complex  regex patterns, it can be useful to avoid the need
          for complex quoting and escape sequences by making use of YAML's
          multiline string syntax.

             complex_search_and_replace:
               file.replace:
                 # <...snip...>
                 - pattern: |
                     CentOS \(2.6.32[^\n]+\n\s+root[^\n]+\n\)+

          NOTE:
             When  using  YAML  multiline  string syntax in pattern:, make
             sure to also use that syntax in the repl: part, or you  might
             loose line feeds.

   salt.states.file.retention_schedule(name, retain, strptime_format=None,
   timezone=None)
          Apply retention scheduling to backup storage directory.

          New in version 2016.11.0.

          Parameters

                 * name -- The filesystem path to the directory containing
                   backups to be managed.

                 * retain --

                   Delete  the  backups,  except  for  the ones we want to
                   keep.  The N below should be an integer but may also be
                   the  special  value  of  all,  which  keeps  all  files
                   matching the  criteria.   All  of  the  retain  options
                   default to None, which means to not keep files based on
                   this criteria.

                   most_recent N
                          Keep the most recent N files.

                   first_of_hour N
                          For the last N hours from now,  keep  the  first
                          file after the hour.

                   first_of_day N
                          For  the  last  N  days from now, keep the first
                          file after midnight.  See also timezone.

                   first_of_week N
                          For the last N weeks from now,  keep  the  first
                          file after Sunday midnight.

                   first_of_month N
                          For  the  last N months from now, keep the first
                          file after the start of the month.

                   first_of_year N
                          For the last N years from now,  keep  the  first
                          file after the start of the year.

                 * strptime_format -- A python strptime format string used
                   to first match the filenames of backups and then  parse
                   the  filename  to  determine  the datetime of the file.
                   https://docs.python.org/2/library/datetime.html#datetime.datetime.strptime
                   Defaults  to  None,  which  considers  all files in the
                   directory to be backups eligible for deletion and  uses
                   os.path.getmtime() to determine the datetime.

                 * timezone  --  The  timezone  to  use  when  determining
                   midnight.  This is only used when  datetime  is  pulled
                   from  os.path.getmtime().   Defaults to None which uses
                   the timezone from the locale.

   salt.states.file.serialize(name,   dataset=None,   dataset_pillar=None,
   user=None,    group=None,    mode=None,    backup='',   makedirs=False,
   show_diff=True, create=True, merge_if_exists=False, **kwargs)
          Serializes dataset and store it into managed  file.  Useful  for
          sharing simple configuration files.

          name   The location of the file to create

          dataset
                 The dataset that will be serialized

          dataset_pillar
                 Operates  like  dataset, but draws from a value stored in
                 pillar, using the pillar path syntax used in  pillar.get.
                 This  is  useful when the pillar value contains newlines,
                 as referencing  a  pillar  variable  using  a  jinja/mako
                 template  can result in YAML formatting issues due to the
                 newlines causing indentation mismatches.

                 New in version 2015.8.0.

          formatter
                 Write the data as this format. Supported output formats:

                 * JSON

                 * YAML

                 * Python (via pprint.pformat)

          user   The user to own the directory, this defaults to the  user
                 salt is running as on the minion

          group  The  group ownership set for the directory, this defaults
                 to the group salt is running as on the minion

          mode   The permissions to set on this file, e.g. 644,  0775,  or
                 4664.

                 NOTE:
                    This option is not supported on Windows.

          backup Overrides the default backup mode for this specific file.

          makedirs
                 Create parent directories for destination file.

                 New in version 2014.1.3.

          show_diff
                 If set to False, the diff will not be shown.

          create Default  is True, if create is set to False then the file
                 will only be managed if the file already  exists  on  the
                 system.

          merge_if_exists
                 Default  is  False,  if  merge_if_exists is True then the
                 existing file will be parsed and the  dataset  passed  in
                 will be merged with the existing content

                 New in version 2014.7.0.

          For example, this state:

             /etc/dummy/package.json:
               file.serialize:
                 - dataset:
                     name: naive
                     description: A package using naive versioning
                     author: A confused individual <[email protected]>
                     dependencies:
                         express: >= 1.2.0
                         optimist: >= 0.1.0
                     engine: node 0.4.1
                 - formatter: json

          will manage the file /etc/dummy/package.json:

             {
               "author": "A confused individual <[email protected]>",
               "dependencies": {
                 "express": ">= 1.2.0",
                 "optimist": ">= 0.1.0"
               },
               "description": "A package using naive versioning",
               "engine": "node 0.4.1",
               "name": "naive"
             }

   salt.states.file.symlink(name,  target,  force=False,  backupname=None,
   makedirs=False, user=None, group=None, mode=None, **kwargs)
          Create a symbolic link (symlink, soft link)

          If the file already exists and is  a  symlink  pointing  to  any
          location  other  than  the specified target, the symlink will be
          replaced. If the symlink is a regular file or directory then the
          state  will  return  False.  If the regular file or directory is
          desired to be replaced with a symlink pass force: True, if it is
          to be renamed, pass a backupname.

          name   The location of the symlink to create

          target The location that the symlink points to

          force  If  the  name  of the symlink exists and is not a symlink
                 and force is set to False, the state will fail. If  force
                 is  set  to True, the file or directory in the way of the
                 symlink file  will  be  deleted  to  make  room  for  the
                 symlink,  unless  backupname  is  set,  when  it  will be
                 renamed

          backupname
                 If the name of the symlink exists and is not  a  symlink,
                 it  will  be renamed to the backupname. If the backupname
                 already exists and force is False, the state  will  fail.
                 Otherwise, the backupname will be removed first.

          makedirs
                 If  the  location  of the symlink does not already have a
                 parent  directory  then  the  state  will  fail,  setting
                 makedirs  to  True  will  allow Salt to create the parent
                 directory

          user   The user to own the file, this defaults to the user  salt
                 is running as on the minion

          group  The  group  ownership  set for the file, this defaults to
                 the group salt is running as on the minion.  On  Windows,
                 this is ignored

          mode   The permissions to set on this file, aka 644, 0775, 4664.
                 Not supported on Windows

   salt.states.file.touch(name, atime=None, mtime=None, makedirs=False)
          Replicate the 'nix "touch" command to create a new empty file or
          update the atime and mtime of an existing file.

          Note that if you just want to create a file and don't care about
          atime or mtime, you should use file.managed instead,  as  it  is
          more      feature-complete.      (Just     leave     out     the
          source/template/contents arguments, and it will just create  the
          file   and/or   check  its  permissions,  without  messing  with
          contents)

          name   name of the file

          atime  atime of the file

          mtime  mtime of the file

          makedirs
                 whether we should create the parent directory/directories
                 in order to touch the file

          Usage:

             /var/log/httpd/logrotate.empty:
               file.touch

          New in version 0.9.5.

   salt.states.file.uncomment(name, regex, char='#', backup='.bak')
          Uncomment specified commented lines in a file

          name   The full path to the file to be edited

          regex  A  regular  expression used to find the lines that are to
                 be  uncommented.   This  regex  should  not  include  the
                 comment character. A leading ^ character will be stripped
                 for convenience (for easily switching  between  comment()
                 and  uncomment()).   The  regex will be searched for from
                 the beginning of the line, ignoring  leading  spaces  (we
                 prepend '^[ t]*')

          char   # The character to remove in order to uncomment a line

          backup .bak  The  file  will  be backed up before edit with this
                 file extension;

                 WARNING:
                    This backup  will  be  overwritten  each  time  sed  /
                    comment / uncomment is called. Meaning the backup will
                    only be useful after the first invocation.

                 Set to False/None to not keep a backup.

          Usage:

             /etc/adduser.conf:
               file.uncomment:
                 - regex: EXTRA_GROUPS

          New in version 0.9.5.

   salt.states.firewall module
   State to check firewall configurations

   salt.states.firewall.check(name, port=None, **kwargs)
          Checks if there is an open connection from  the  minion  to  the
          defined host on a specific port.

          name   host name or ip address to test connection to

          port   The port to test the connection on

          **
                 kwargs

                 Additional parameters, parameters allowed are:
                        proto (tcp or udp) family (ipv4 or ipv6) timeout

             testgoogle:
               firewall.check:
                 - name: 'google.com'
                 - port: 80
                 - proto: 'tcp'

   salt.states.firewalld
   Management of firewalld

   New in version 2015.8.0.

   The  following  example  applies  changes  to  the  public zone, blocks
   echo-reply and echo-request packets, does not set the zone  to  be  the
   default,  enables masquerading, and allows ports 22/tcp and 25/tcp.  It
   will be applied permanently and directly before restart/reload.

      public:
        firewalld.present:
          - name: public
          - block_icmp:
            - echo-reply
            - echo-request
          - default: False
          - masquerade: True
          - ports:
            - 22/tcp
            - 25/tcp

   The following example applies  changes  to  the  public  zone,  enables
   masquerading and configures port forwarding TCP traffic from port 22 to
   2222, and forwards TCP traffic from port 80 to 443 at 192.168.0.1.

      my_zone:
        firewalld.present:
          - name: public
          - masquerade: True
          - port_fwd:
            - 22:2222:tcp
            - 80:443:tcp:192.168.0.1

   The following example binds the public zone to interface  eth0  and  to
   all  packets coming from the 192.168.1.0/24 subnet. It also removes the
   zone from all other interfaces or sources.

      public:
        firewalld.present:
          - name: public
          - interfaces:
            - eth0
          - sources:
            - 192.168.1.0/24

   Here, we define a new service that encompasses TCP ports 4505 4506:

      saltmaster:
        firewalld.service:
          - name: saltmaster
          - ports:
            - 4505/tcp
            - 4506/tcp

   To make this new service available in a  zone,  the  following  can  be
   used,  which  would allow access to the salt master from the 10.0.0.0/8
   subnet:

      saltzone:
        firewalld.present:
          - name: saltzone
          - services:
            - saltmaster
          - sources:
            - 10.0.0.0/8

   class    salt.states.firewalld.ForwardingMapping(srcport,     destport,
   protocol, destaddr)
          Represents a port forwarding statement mapping a local port to a
          remote port for a specific protocol (TCP or UDP)

          todict()
                 Returns  a  pretty  dictionary  meant  for  command  line
                 output.

   salt.states.firewalld.present(name,    block_icmp=None,   default=None,
   masquerade=False,     ports=None,     port_fwd=None,     services=None,
   prune_services=True, interfaces=None, sources=None, rich_rules=None)
          Ensure a zone has specific attributes.

   salt.states.firewalld.service(name, ports=None, protocols=None)
          Ensure  the  service  exists and encompasses the specified ports
          and protocols.

          New in version 2016.11.0.

   salt.states.gem
   Installation of Ruby modules packaged as gems
   A state module to manage rubygems. Gems can be set up to  be  installed
   or removed. This module will use RVM or rbenv if they are installed. In
   that case, you can specify what ruby version and gemset to target.

      addressable:
        gem.installed:
          - user: rvm
          - ruby: jruby@jgemset

   salt.states.gem.installed(name,  ruby=None,  gem_bin=None,   user=None,
   version=None,  rdoc=False,  ri=False,  pre_releases=False,  proxy=None,
   source=None)
          Make sure that a gem is installed.

          name   The name of the gem to install

          ruby: None
                 Only for RVM or rbenv installations: the ruby version and
                 gemset to target.

          gem_bin: None
                 Custom  gem  command  to run instead of the default.  Use
                 this to install gems to a non-default  ruby  install.  If
                 you are using rvm or rbenv use the ruby argument instead.

          user: None
                 The user under which to run the gem command

                 New in version 0.17.0.

          version
                 None Specify the version to install for the gem.  Doesn't
                 play nice with multiple gems at once

          rdoc   False Generate RDoc documentation for the gem(s).

          ri     False Generate RI documentation for the gem(s).

          pre_releases
                 False Install pre-release version of gem(s) if available.

          proxy  None Use the specified HTTP proxy server for all outgoing
                 traffic.  Format: http://hostname[:port]

          source None Use the specified HTTP gem source server to download
                 gem.  Format: http://hostname[:port]

   salt.states.gem.removed(name, ruby=None, user=None, gem_bin=None)
          Make sure that a gem is not installed.

          name   The name of the gem to uninstall

          gem_bin
                 None Full path to gem binary to use.

          ruby   None If RVM or rbenv are installed, the ruby version  and
                 gemset to use.  Ignored if gem_bin is specified.

          user: None
                 The user under which to run the gem command

                 New in version 0.17.0.

   salt.states.gem.sources_add(name, ruby=None, user=None)
          Make sure that a gem source is added.

          name   The URL of the gem source to be added

          ruby: None
                 For  RVM  or  rbenv  installations:  the ruby version and
                 gemset to target.

          user: None
                 The user under which to run the gem command

                 New in version 0.17.0.

   salt.states.gem.sources_remove(name, ruby=None, user=None)
          Make sure that a gem source is removed.

          name   The URL of the gem source to be removed

          ruby: None
                 For RVM or rbenv  installations:  the  ruby  version  and
                 gemset to target.

          user: None
                 The user under which to run the gem command

                 New in version 0.17.0.

   salt.states.git
   States to manage git repositories and git configuration

   IMPORTANT:
      Before  using  git  over ssh, make sure your remote host fingerprint
      exists in your ~/.ssh/known_hosts file.

   Changed in version 2015.8.8: This state module now requires  git  1.6.5
   (released 10 October 2009) or newer.

   salt.states.git.config_set(name,  value=None, multivar=None, repo=None,
   user=None, password=None, **kwargs)
          New in version 2014.7.0.

          Changed  in  version  2015.8.0:  Renamed  from   git.config   to
          git.config_set. For earlier versions, use git.config.

          Ensure that a config value is set to the desired value(s)

          name   Name of the git config value to set

          value  Set a single value for the config item

          multivar
                 Set multiple values for the config item

                 NOTE:
                    The order matters here, if the same parameters are set
                    but in a different order, they  will  be  removed  and
                    replaced in the order specified.

                 New in version 2015.8.0.

          repo   Location of the git repository for which the config value
                 should be set. Required unless global is set to True.

          user   User under which to run git  commands.  By  default,  the
                 commands  are  run  by the user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          global False If True, this will set a global git config option

                 Changed   in   version   2015.8.0:  Option  renamed  from
                 is_global to global. For earlier versions, use is_global.

          Local Config Example:

             # Single value
             mylocalrepo:
               git.config_set:
                 - name: user.email
                 - value: [email protected]
                 - repo: /path/to/repo

             # Multiple values
             mylocalrepo:
               git.config_set:
                 - name: mysection.myattribute
                 - multivar:
                   - foo
                   - bar
                   - baz
                 - repo: /path/to/repo

          Global Config Example (User ``foo``):

             mylocalrepo:
               git.config_set:
                 - name: user.name
                 - value: Foo Bar
                 - user: foo
                 - global: True

   salt.states.git.config_unset(name,     value_regex=None,     repo=None,
   user=None, password=None, **kwargs)
          New in version 2015.8.0.

          Ensure that the named config key is not present

          name   The  name  of  the configuration key to unset. This value
                 can be a regex, but the regex must match the  entire  key
                 name. For example, foo\.  would not match all keys in the
                 foo section, it would be necessary to use foo\..+  to  do
                 so.

          value_regex
                 Regex  indicating  the  values  to unset for the matching
                 key(s)

                 NOTE:
                    This option behaves differently depending  on  whether
                    or  not  all is set to True. If it is, then all values
                    matching the regex will be deleted (this is  the  only
                    way to delete multiple values from a multivar). If all
                    is set to False, then this  state  will  fail  if  the
                    regex matches more than one value in a multivar.

          all    False If True, unset all matches

          repo   Location of the git repository for which the config value
                 should be set. Required unless global is set to True.

          user   User  under  which  to  run  git  commands.  By  default,
                 commands  are  run  by the user under which the minion is
                 running.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          global False If True, this will set a global git config option

          Examples:

             # Value matching 'baz'
             mylocalrepo:
               git.config_unset:
                 - name: foo.bar
                 - value_regex: 'baz'
                 - repo: /path/to/repo

             # Ensure entire multivar is unset
             mylocalrepo:
               git.config_unset:
                 - name: foo.bar
                 - all: True

             # Ensure all variables in 'foo' section are unset, including multivars
             mylocalrepo:
               git.config_unset:
                 - name: 'foo\..+'
                 - all: True

             # Ensure that global config value is unset
             mylocalrepo:
               git.config_unset:
                 - name: foo.bar
                 - global: True

   salt.states.git.detached(name,   ref,   target=None,   remote='origin',
   user=None,  password=None,   force_clone=False,   force_checkout=False,
   fetch_remote=True,  hard_reset=False,  submodules=False, identity=None,
   https_user=None, https_pass=None, onlyif=False, unless=False, **kwargs)
          New in version 2016.3.0.

          Make sure a repository is cloned to the given  target  directory
          and  is  a detached HEAD checkout of the commit ID resolved from
          ref.

          name   Address of the remote repository.

          ref    The branch, tag, or commit ID to  checkout  after  clone.
                 If  a branch or tag is specified it will be resolved to a
                 commit ID and checked out.

          target Name of the target directory where repository is about to
                 be cloned.

          remote origin  Git  remote  to use. If this state needs to clone
                 the repo, it will  clone  it  using  this  value  as  the
                 initial  remote  name.  If the repository already exists,
                 and a remote by this name is not  present,  one  will  be
                 added.

          user   User  under  which  to  run  git  commands.  By  default,
                 commands are run by the user under which  the  minion  is
                 running.

          password
                    Windows  only.  Required  when  specifying  user. This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          force_clone
                 False If the target directory exists and  is  not  a  git
                 repository,  then this state will fail. Set this argument
                 to True to remove the contents of  the  target  directory
                 and clone the repo into it.

          force_checkout
                 False  When  checking out the revision ID, the state will
                 fail if there are unwritten changes. Set this argument to
                 True to discard unwritten changes when checking out.

          fetch_remote
                 True  If  False  a  fetch  will not be performed and only
                 local refs will be reachable.

          hard_reset
                 False If True a hard reset will be performed  before  the
                 checkout and any uncommitted modifications to the working
                 directory will be discarded.  Untracked files will remain
                 in place.

                 NOTE:
                    Changes  resulting  from a hard reset will not trigger
                    requisites.

          submodules
                 False Update submodules

          identity
                 A path on the minion (or a SaltStack fileserver URL, e.g.
                 salt://path/to/identity_file) to a private key to use for
                 SSH authentication.

          https_user
                 HTTP Basic Auth username for HTTPS (only) clones

          https_pass
                 HTTP Basic Auth password for HTTPS (only) clones

          onlyif A command to run as a check, run the named  command  only
                 if the command passed to the onlyif option returns true

          unless A  command  to run as a check, only run the named command
                 if the command passed to the unless option returns false

   salt.states.git.latest(name,  rev='HEAD',   target=None,   branch=None,
   user=None,   password=None,   update_head=True,   force_checkout=False,
   force_clone=False,        force_fetch=False,         force_reset=False,
   submodules=False,     bare=False,     mirror=False,    remote='origin',
   fetch_tags=True,    depth=None,     identity=None,     https_user=None,
   https_pass=None, onlyif=False, unless=False, **kwargs)
          Make sure the repository is cloned to the given directory and is
          up-to-date.

          name   Address of the remote repository, as passed to git clone

                 NOTE:
                    From the Git documentation, there are two URL  formats
                    supported   for  SSH  authentication.  The  below  two
                    examples are equivalent:

                        # ssh:// URL
                        ssh://user@server/project.git

                        # SCP-like syntax
                        user@server:project.git

                    A common mistake is to use an ssh:// URL, but  with  a
                    colon  after  the  domain  instead of a slash. This is
                    invalid syntax in Git, and will therefore not work  in
                    Salt.  When  in  doubt, confirm that a git clone works
                    for the URL before using it in Salt.

                    It has been  reported  by  some  users  that  SCP-like
                    syntax  is  incompatible  with  git  repos  hosted  on
                    Atlassian Stash/BitBucket Server. In these  cases,  it
                    may   be   necessary   to  use  ssh://  URLs  for  SSH
                    authentication.

          rev    HEAD The remote branch, tag, or revision ID  to  checkout
                 after clone / before update. If specified, then Salt will
                 also  ensure  that  the  tracking  branch   is   set   to
                 <remote>/<rev>,  unless  rev  refers to a tag or SHA1, in
                 which case Salt will ensure that the tracking  branch  is
                 unset.

                 If  rev  is not specified, it will be assumed to be HEAD,
                 and Salt will not manage the tracking branch at all.

                 Changed in version 2015.8.0: If not  specified,  rev  now
                 defaults to the remote repository's HEAD.

          target Name of the target directory where repository is about to
                 be cloned

          branch Name of the local  branch  into  which  to  checkout  the
                 specified  rev. If not specified, then Salt will not care
                 what branch is being  used  locally  and  will  just  use
                 whatever branch is currently there.

                 New in version 2015.8.0.

                 NOTE:
                    If  this  argument  is  not specified, this means that
                    Salt  will  not  change  the  local  branch   if   the
                    repository  is  reset  to another branch/tag/SHA1. For
                    example, assume  that  the  following  state  was  run
                    initially:

                        foo_app:
                          git.latest:
                            - name: https://mydomain.tld/apps/foo.git
                            - target: /var/www/foo
                            - user: www

                    This  would have cloned the HEAD of that repo (since a
                    rev wasn't  specified),  and  because  branch  is  not
                    specified,   the   branch   in   the  local  clone  at
                    /var/www/foo would be whatever the default  branch  is
                    on  the  remote  repository  (usually  master, but not
                    always). Now, assume  that  it  becomes  necessary  to
                    switch  this  checkout  to  the dev branch. This would
                    require rev to be set, and probably would also require
                    force_reset to be enabled:

                        foo_app:
                          git.latest:
                            - name: https://mydomain.tld/apps/foo.git
                            - target: /var/www/foo
                            - user: www
                            - rev: dev
                            - force_reset: True

                    The  result  of  this  state  would  be  to  perform a
                    hard-reset  to  origin/dev.  Since  branch   was   not
                    specified though, while /var/www/foo would reflect the
                    contents of the remote repo's dev  branch,  the  local
                    branch  would still remain whatever it was when it was
                    cloned. To make the local branch match the remote one,
                    set branch as well, like so:

                        foo_app:
                          git.latest:
                            - name: https://mydomain.tld/apps/foo.git
                            - target: /var/www/foo
                            - user: www
                            - rev: dev
                            - branch: dev
                            - force_reset: True

                    This  may  seem redundant, but Salt tries to support a
                    wide variety of use  cases,  and  doing  it  this  way
                    allows for the use case where the local branch doesn't
                    need to be strictly managed.

          user   Local system user under which to  run  git  commands.  By
                 default,  commands  are  run  by the user under which the
                 minion is running.

                 NOTE:
                    This is not to  be  confused  with  the  username  for
                    http(s)/SSH authentication.

                 New in version 0.17.0.

          password
                 Windows   only.   Required  when  specifying  user.  This
                 parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

          update_head
                 True If set to False, then the remote repository will  be
                 fetched (if necessary) to ensure that the commit to which
                 rev points exists in the local checkout, but  no  changes
                 will be made to the local HEAD.

                 New in version 2015.8.3.

          force  False  Deprecated since version 2015.8.0: Use force_clone
                 instead. For earlier Salt versions, force must be used.

          force_checkout
                 False When checking out the local branch, the state  will
                 fail if there are unwritten changes. Set this argument to
                 True to discard unwritten changes when checking out.

          force_clone
                 False If the target directory exists and  is  not  a  git
                 repository,  then this state will fail. Set this argument
                 to True to remove the contents of  the  target  directory
                 and clone the repo into it.

          force_fetch
                 False  If a fetch needs to be performed, non-fast-forward
                 fetches will cause this state to fail. Set this  argument
                 to   True   to   force   the   fetch  even  if  it  is  a
                 non-fast-forward update.

                 New in version 2015.8.0.

          force_reset
                 False If the update is not  a  fast-forward,  this  state
                 will   fail.  Set  this  argument  to  True  to  force  a
                 hard-reset to the remote revision in these cases.

          submodules
                 False Update submodules on clone or branch change

          bare   False Set to True if the repository is to be a bare clone
                 of the remote repository.

          mirror Set  to  True  if the repository is to be a mirror of the
                 remote repository. This implies that bare  set  to  True,
                 and thus is incompatible with rev.

          remote origin  Git  remote  to use. If this state needs to clone
                 the repo, it will  clone  it  using  this  value  as  the
                 initial  remote  name.  If the repository already exists,
                 and a remote by this name is not  present,  one  will  be
                 added.

          remote_name
                 Deprecated  since  version  2015.8.0: Use remote instead.
                 For earlier Salt versions, remote_name must be used.

          fetch_tags
                 True If True, then when a fetch  is  performed  all  tags
                 will  be  fetched,  even those which are not reachable by
                 any branch on the remote.

          depth  Defines depth in history when git a clone  is  needed  in
                 order  to  ensure  latest.  E.g.  depth: 1 is useful when
                 deploying from a repository with a long history. Use  rev
                 to  specify  branch.  This is not compatible with tags or
                 revision IDs.

          identity
                 Path to a private key to use for ssh URLs.  This  can  be
                 either  a  single  string,  or  a  list  of  strings. For
                 example:

                    # Single key
                    [email protected]:user/repo.git:
                      git.latest:
                        - user: deployer
                        - identity: /home/deployer/.ssh/id_rsa

                    # Two keys
                    [email protected]:user/repo.git:
                      git.latest:
                        - user: deployer
                        - identity:
                          - /home/deployer/.ssh/id_rsa
                          - /home/deployer/.ssh/id_rsa_alternate

                 If multiple  keys  are  specified,  they  will  be  tried
                 one-by-one  in  order for each git command which needs to
                 authenticate.

                 WARNING:
                    Unless  Salt  is  invoked  from   the   minion   using
                    salt-call,  the  key(s)  must  be  passphraseless. For
                    greater security with passphraseless private keys, see
                    the  sshd(8)  manpage  for information on securing the
                    keypair from the remote side  in  the  authorized_keys
                    file.

                 Changed  in version 2015.8.7: Salt will no longer attempt
                 to use passphrase-protected keys unless invoked from  the
                 minion  using  salt-call, to prevent blocking waiting for
                 user input.

                 Changed in version 2016.3.0: Key can now be specified  as
                 a        SaltStack       fileserver       URL       (e.g.
                 salt://path/to/identity_file).

          https_user
                 HTTP Basic Auth username for HTTPS (only) clones

                 New in version 2015.5.0.

          https_pass
                 HTTP Basic Auth password for HTTPS (only) clones

                 New in version 2015.5.0.

          onlyif A command to run as a check, run the named  command  only
                 if the command passed to the onlyif option returns true

          unless A  command  to run as a check, only run the named command
                 if the command passed to the unless option returns false

          NOTE:
             Clashing  ID  declarations  can  be  avoided  when  including
             different  branches  from the same git repository in the same
             SLS file by using the name argument. The example below checks
             out  the  gh-pages  and  gh-pages-prod branches from the same
             repository into separate directories. The example  also  sets
             up  the  ssh_known_hosts  ssh key required to perform the git
             checkout.

             Also, it has been reported that the SCP-like syntax for

                 gitlab.example.com:
                   ssh_known_hosts:
                     - present
                     - user: root
                     - enc: ecdsa
                     - fingerprint: 4e:94:b0:54:c1:5b:29:a2:70:0e:e1:a3:51:ee:ee:e3

                 git-website-staging:
                   git.latest:
                     - name: [email protected]:user/website.git
                     - rev: gh-pages
                     - target: /usr/share/nginx/staging
                     - identity: /root/.ssh/website_id_rsa
                     - require:
                       - pkg: git
                       - ssh_known_hosts: gitlab.example.com

                 git-website-staging:
                   git.latest:
                     - name: [email protected]:user/website.git
                     - rev: gh-pages
                     - target: /usr/share/nginx/staging
                     - identity: salt://website/id_rsa
                     - require:
                       - pkg: git
                       - ssh_known_hosts: gitlab.example.com

                 git-website-prod:
                   git.latest:
                     - name: [email protected]:user/website.git
                     - rev: gh-pages-prod
                     - target: /usr/share/nginx/prod
                     - identity: /root/.ssh/website_id_rsa
                     - require:
                       - pkg: git
                       - ssh_known_hosts: gitlab.example.com

   salt.states.git.mod_run_check(cmd_kwargs, onlyif, unless)
          Execute the onlyif and unless logic. Return a result dict if:

          * onlyif failed (onlyif != 0)

          * unless succeeded (unless == 0)

          Otherwise, returns True

   salt.states.git.present(name,  force=False,  bare=True,  template=None,
   separate_git_dir=None, shared=None, user=None, password=None)
          Ensure that a repository exists in the given directory

          WARNING:
             If  the minion has Git 2.5 or later installed, name points to
             a worktree, and force is set to True, then the worktree  will
             be deleted. This has been corrected in Salt 2015.8.0.

          name   Path to the directory

                 Changed  in  version  2015.8.0:  This  path  must  now be
                 absolute

          force  False  If  True,  and  if  name  points  to  an  existing
                 directory  which  does not contain a git repository, then
                 the  contents  of  that  directory  will  be  recursively
                 removed  and  a new repository will be initialized in its
                 place.

          bare   True If True, and a repository must be initialized,  then
                 the repository will be a bare repository.

                 NOTE:
                    This  differs  from  the default behavior of git.init,
                    make sure to set this value to False if a bare repo is
                    not desired.

          template
                 If  a  new  repository is initialized, this argument will
                 specify an alternate
                 `template directory`_

                 New in version 2015.8.0.

          separate_git_dir
                 If a new repository is initialized,  this  argument  will
                 specify an alternate $GIT_DIR

                 New in version 2015.8.0.

          shared Set  sharing permissions on git repo. See git-init(1) for
                 more details.

                 New in version 2015.5.0.

          user   User  under  which  to  run  git  commands.  By  default,
                 commands  are  run  by the user under which the minion is
                 running.

                 New in version 0.17.0.

          password
                    Windows only.  Required  when  specifying  user.  This
                    parameter will be ignored on non-Windows platforms.

                 New in version 2016.3.4.

   salt.states.github module
   Github User State Module

   New in version 2016.3.0..

   This state is used to ensure presence of users in the Organization.

      ensure user test is present in github:
          github.present:
              - name: 'Example TestUser1'
              - email: [email protected]
              - username: 'gitexample'

   salt.states.github.absent(name, profile='github', **kwargs)
          Ensure a github user is absent

             ensure user test is absent in github:
                 github.absent:
                     - name: 'Example TestUser1'
                     - email: [email protected]
                     - username: 'gitexample'

          The following parameters are required:

          name   Github handle of the user in organization

   salt.states.github.present(name, profile='github', **kwargs)
          Ensure a user is present

             ensure user test is present in github:
                 github.present:
                     - name: 'gitexample'

          The following parameters are required:

          name   This is the github handle of the user in the organization

   salt.states.github.repo_absent(name, profile='github', **kwargs)
          Ensure a repo is absent.

          Example:

             ensure repo test is absent in github:
                 github.repo_absent:
                     - name: 'test'

          The following parameters are required:

          name   This is the name of the repository in the organization.

          New in version 2016.11.0.

   salt.states.github.repo_present(name,  description=None, homepage=None,
   private=False,  has_issues=True,   has_wiki=True,   has_downloads=True,
   auto_init=False,     gitignore_template=None,    license_template=None,
   profile='github', **kwargs)
          Ensure a repository is present

          name   This is the name of the repository.

          description
                 The description of the repository.

          homepage
                 The URL with more information about the repository.

          private
                 The  visiblity  of  the  repository.  Note  that  private
                 repositories require a paid GitHub account.

          has_issues
                 Whether to enable issues for this repository.

          has_wiki
                 Whether to enable the wiki for this repository.

          has_downloads
                 Whether to enable downloads for this repository.

          auto_init
                 Whether to create an initial commit with an empty README.

          gitignore_template
                 The  desired  language  or platform for a .gitignore, e.g
                 "Haskell".

          license_template
                 The desired LICENSE  template  to  apply,  e.g  "mit"  or
                 "mozilla".

          Example:

             Ensure repo my-repo is present in github:
                 github.repo_present:
                     - name: 'my-repo'
                     - description: 'My very important repository'

          New in version 2016.11.0.

   salt.states.github.team_absent(name, profile='github', **kwargs)
          Ensure a team is absent.

          Example:

             ensure team test is present in github:
                 github.team_absent:
                     - name: 'test'

          The following parameters are required:

          name   This is the name of the team in the organization.

          New in version 2016.11.0.

   salt.states.github.team_present(name,                 description=None,
   repo_names=None,  privacy='secret',  permission='pull',   members=None,
   enforce_mfa=False, no_mfa_grace_seconds=0, profile='github', **kwargs)
          Ensure a team is present

          name   This is the name of the team in the organization.

          description
                 The description of the team.

          repo_names
                 The names of repositories to add the team to.

          privacy
                 The  level  of  privacy  for the team, can be 'secret' or
                 'closed'. Defaults to secret.

          permission
                 The default permission for new repositories added to  the
                 team, can be 'pull', 'push' or 'admin'. Defaults to pull.

          members
                 The members belonging to the team, specified as a dict of
                 member name to optional  configuration.  Options  include
                 'enforce_mfa_from' and 'mfa_exempt'.

          enforce_mfa
                 Whether  to  enforce  MFA  requirements on members of the
                 team. If True then all members without  mfa_exempt:  True
                 configured  will  be  removed  from  the  team. Note that
                 no_mfa_grace_seconds may be set to allow members a  grace
                 period.

          no_mfa_grace_seconds
                 The  number  of  seconds of grace time that a member will
                 have to enable MFA before being removed  from  the  team.
                 The  grace period will begin from enforce_mfa_from on the
                 member configuration, which defaults to 1970/01/01.

          Example:

             Ensure team test is present in github:
                 github.team_present:
                     - name: 'test'
                     - members:
                         user1: {}
                         user2: {}

             Ensure team test_mfa is present in github:
                 github.team_present:
                     - name: 'test_mfa'
                     - members:
                         user1:
                             enforce_mfa_from: 2016/06/15
                     - enforce_mfa: True

          New in version 2016.11.0.

   salt.states.glance
   Managing Images in OpenStack Glance
   salt.states.glance.image_present(name,             visibility='public',
   protected=None,     checksum=None,     location=None,    wait_for=None,
   timeout=30)
          Checks  if  given  image  is  present  with  properties  set  as
          specified.

          An image should got through the stages 'queued', 'saving' before
          becoming 'active'. The attribute 'checksum' can only be  checked
          once  the  image is active.  If you don't specify 'wait_for' but
          'checksum' the function will wait for the image to become active
          before comparing checksums. If you don't specify checksum either
          the function will return when the image reached  'saving'.   The
          default timeout for both is 30 seconds.

          Supported properties:

                 * visibility ('public' or 'private')

                 * protected (bool)

                 * checksum (string, md5sum)

                 * location (URL, to copy from)

   salt.states.glusterfs
   Manage GlusterFS pool.

   salt.states.glusterfs.add_volume_bricks(name, bricks)
          Add brick(s) to an existing volume

          name   Volume name

          bricks List of bricks to add to the volume

             myvolume:
               glusterfs.add_volume_bricks:
                 - bricks:
                     - host1:/srv/gluster/drive1
                     - host2:/srv/gluster/drive2

             Replicated Volume:
               glusterfs.add_volume_bricks:
                 - name: volume2
                 - bricks:
                   - host1:/srv/gluster/drive2
                   - host2:/srv/gluster/drive3

   salt.states.glusterfs.created(*args, **kwargs)
          Deprecated version of more descriptively named volume_present

   salt.states.glusterfs.peered(name)
          Check if node is peered.

          name   The remote host with which to peer.

             peer-cluster:
               glusterfs.peered:
                 - name: two

             peer-clusters:
               glusterfs.peered:
                 - names:
                   - one
                   - two
                   - three
                   - four

   salt.states.glusterfs.started(name)
          Check if volume has been started

          name   name of the volume

             mycluster:
               glusterfs.started: []

   salt.states.glusterfs.volume_present(name,     bricks,    stripe=False,
   replica=False,    device_vg=False,    transport='tcp',     start=False,
   force=False)
          Ensure that the volume exists

          name   name of the volume

          bricks list of brick paths

          start  ensure that the volume is also started

             myvolume:
               glusterfs.created:
                 - bricks:
                     - host1:/srv/gluster/drive1
                     - host2:/srv/gluster/drive2

             Replicated Volume:
               glusterfs.created:
                 - name: volume2
                 - bricks:
                   - host1:/srv/gluster/drive2
                   - host2:/srv/gluster/drive3
                 - replica: 2
                 - start: True

   salt.states.gnomedesktop
   Configuration of the GNOME desktop
   Control the GNOME settings

      localdesktop_wm_prefs:
          gnomedesktop.wm_preferences:
              - user: username
              - audible_bell: false
              - action_double_click_titlebar: 'toggle-maximize'
              - visual_bell: true
              - num_workspaces: 6
      localdesktop_lockdown:
          gnomedesktop.desktop_lockdown:
              - user: username
              - disable_user_switching: true
      localdesktop_interface:
          gnomedesktop.desktop_interface:
              - user: username
              - clock_show_date: true
              - clock_format: 12h

   salt.states.gnomedesktop.desktop_interface(name,             user=None,
   automatic_mnemonics=None,                      buttons_have_icons=None,
   can_change_accels=None,     clock_format=None,    clock_show_date=None,
   clock_show_seconds=None,   cursor_blink=None,   cursor_blink_time=None,
   cursor_blink_timeout=None,     cursor_size=None,     cursor_theme=None,
   document_font_name=None,    enable_animations=None,     font_name=None,
   gtk_color_palette=None,    gtk_color_scheme=None,   gtk_im_module=None,
   gtk_im_preedit_style=None,                    gtk_im_status_style=None,
   gtk_key_theme=None,      gtk_theme=None,      gtk_timeout_initial=None,
   gtk_timeout_repeat=None,      icon_theme=None,      menubar_accel=None,
   menubar_detachable=None,                         menus_have_icons=None,
   menus_have_tearoff=None,                      monospace_font_name=None,
   show_input_method_menu=None,                    show_unicode_menu=None,
   text_scaling_factor=None,                      toolbar_detachable=None,
   toolbar_icons_size=None,                            toolbar_style=None,
   toolkit_accessibility=None, **kwargs)
          desktop_interface:       sets        values        in        the
          org.gnome.desktop.interface schema

   salt.states.gnomedesktop.desktop_lockdown(name,              user=None,
   disable_application_handlers=None,           disable_command_line=None,
   disable_lock_screen=None,                         disable_log_out=None,
   disable_print_setup=None,                        disable_printing=None,
   disable_save_to_disk=None,                 disable_user_switching=None,
   user_administration_disabled=None, **kwargs)
          desktop_lockdown: sets values in the  org.gnome.desktop.lockdown
          schema

   salt.states.gnomedesktop.wm_preferences(name,                user=None,
   action_double_click_titlebar=None,   action_middle_click_titlebar=None,
   action_right_click_titlebar=None,               application_based=None,
   audible_bell=None,       auto_raise=None,        auto_raise_delay=None,
   button_layout=None,      disable_workarounds=None,     focus_mode=None,
   focus_new_windows=None,                     mouse_button_modifier=None,
   num_workspaces=None,                               raise_on_click=None,
   resize_with_right_button=None,     theme=None,      titlebar_font=None,
   titlebar_uses_system_font=None,                       visual_bell=None,
   visual_bell_type=None, workspace_names=None, **kwargs)
          wm_preferences:        sets        values         in         the
          org.gnome.desktop.wm.preferences schema

   salt.states.gpg module
   Management of the GPG keychains
   New in version 2016.3.0.

   salt.states.gpg.absent(name,   keys=None,   user=None,  gnupghome=None,
   **kwargs)
          Ensure GPG public key is absent in keychain

          name   The unique name or keyid for the GPG public key.

          keys   The keyId or keyIds to add to the GPG keychain.

          user   Add GPG keys to the user's keychain

          gnupghome
                 Override GNUPG Home directory

   salt.states.gpg.present(name,  keys=None,  user=None,   keyserver=None,
   gnupghome=None, trust=None, **kwargs)
          Ensure GPG public key is present in keychain

          name   The unique name or keyid for the GPG public key.

          keys   The keyId or keyIds to add to the GPG keychain.

          user   Add GPG keys to the user's keychain

          keyserver
                 The keyserver to retrieve the keys from.

          gnupghome
                 Override GNUPG Home directory

          trust  Trust  level  for  the  key  in  the keychain, ignored by
                 default.    Valid   trust   levels:   expired,   unknown,
                 not_trusted, marginally, fully, ultimately

   salt.states.grafana
   Manage Grafana Dashboards

   This  module uses elasticsearch, which can be installed via package, or
   pip.

   You can specify elasticsearch hosts directly to the module, or you  can
   use an elasticsearch profile via pillars:

      mygrafanaprofile:
        hosts:
          - es1.example.com:9200
          - es2.example.com:9200
        index: grafana-dash

      # Basic usage (uses default pillar profile key 'grafana')
      Ensure myservice dashboard is managed:
        grafana.dashboard_present:
          - name: myservice
          - dashboard_from_pillar: default
          - rows_from_pillar:
              - systemhealth
              - requests

      # Passing hosts in
      Ensure myservice dashboard is managed:
        grafana.dashboard_present:
          - name: myservice
          - dashboard_from_pillar: default
          - rows:
              - collapse: false
                editable: true
                height: 150px
                title: System Health
                panels:
                  - aliasColors: {}
                    id: 200000
                    annotate:
                      enable: false
                    bars: false
                    datasource: null
                    editable: true
                    error: false
                    fill: 7
                    grid:
                      leftMax: 100
                      leftMin: null
                      rightMax: null
                      rightMin: null
                      threshold1: 60
                      threshold1Color: rgb(216, 27, 27)
                      threshold2: null
                      threshold2Color: rgba(234, 112, 112, 0.22)
                    leftYAxisLabel: ''
                    legend:
                      avg: false
                      current: false
                      max: false
                      min: false
                      show: false
                      total: false
                      values: false
                    lines: true
                    linewidth: 1
                    nullPointMode: connected
                    percentage: false
                    pointradius: 5
                    points: false
                    renderer: flot
                    resolution: 100
                    scale: 1
                    seriesOverrides: []
                    span: 4
                    stack: false
                    steppedLine: false
                    targets:
                      - target: cloudwatch.aws.ec2.mysrv.cpuutilization.average
                    title: CPU (asg average)
                    tooltip:
                      query_as_alias: true
                      shared: false
                      value_type: cumulative
                    type: graph
                    x-axis: true
                    y-axis: true
                    y_formats:
                      - short
                      - short
                    zerofill: true
          - rows_from_pillar:
            - systemhealth
            - requests
          - profile:
              hosts:
                - es1.example.com:9200
                - es2.example.com:9200
              index: grafana-dash

      # Using a profile from pillars
      Ensure myservice dashboard is managed:
        grafana.dashboard_present:
          - name: myservice
          - dashboard:
              annotations:
                enable: true
                list: []
              editable: true
              hideAllLegends: false
              hideControls: false
              nav:
                - collapse: false
                  enable: true
                  notice: false
                  now: true
                  refresh_intervals:
                    - 10s
                    - 30s
                    - 1m
                    - 5m
                    - 15m
                    - 30m
                    - 1h
                    - 2h
                    - 1d
                  status: Stable
                  time_options:
                    - 5m
                    - 15m
                    - 1h
                    - 2h
                    - 3h
                    - 4h
                    - 6h
                    - 12h
                    - 1d
                    - 2d
                    - 4d
                    - 7d
                    - 16d
                    - 30d
                  type: timepicker
              originalTitle: dockerregistry
              refresh: 1m
              rows: []
              sharedCrosshair: false
              style: dark
              tags: []
              templating:
                enable: true
                list: []
              time:
                from: now-2h
                to: now
              timezone: browser
          - rows_from_pillars:
            - systemhealth
            - requests
          - profile: mygrafanaprofile

   The  behavior  of  this  module  is to create dashboards if they do not
   exist, to add rows if they do not exist in existing dashboards, and  to
   update  rows  if  they  exist in dashboards. The module will not manage
   rows that are not defined, allowing users to manage  their  own  custom
   rows.

   salt.states.grafana.dashboard_absent(name,                  hosts=None,
   profile='grafana')
          Ensure the named grafana dashboard is deleted.

          name   Name of the grafana dashboard.

          profile
                 A pillar key or dict that contains a list of hosts and an
                 elasticsearch index to use.

   salt.states.grafana.dashboard_present(name,             dashboard=None,
   dashboard_from_pillar=None,      rows=None,      rows_from_pillar=None,
   profile='grafana')
          Ensure the grafana dashboard exists and is managed.

          name   Name of the grafana dashboard.

          dashboard
                 A dict that defines a dashboard that should be managed.

          dashboard_from_pillar
                 A  pillar  key  that  contains  a grafana dashboard dict.
                 Mutually exclusive with dashboard.

          rows   A list of grafana rows.

          rows_from_pillar
                 A list of pillar  keys  that  contain  lists  of  grafana
                 dashboard  rows.   Rows  defined  in  the pillars will be
                 appended to the rows defined in the state.

          profile
                 A pillar key or dict that contains a list of hosts and an
                 elasticsearch index to use.

   salt.states.grafana_dashboard module
   Manage Grafana v2.0 Dashboards

   New in version 2016.3.0.

      grafana:
        grafana_timeout: 3
        grafana_token: qwertyuiop
        grafana_url: 'https://url.com'

      Ensure minimum dashboard is managed:
        grafana_dashboard.present:
          - name: insightful-dashboard
          - base_dashboards_from_pillar:
            - default_dashboard
          - base_rows_from_pillar:
            - default_row
          - base_panels_from_pillar:
            - default_panel
          - dashboard:
              rows:
                - title: Usage
                  panels:
                    - targets:
                        - target: alias(constantLine(50), 'max')
                      title: Imaginary
                      type: graph

   The  behavior  of  this  module  is to create dashboards if they do not
   exist, to add rows if they do not exist in existing dashboards, and  to
   update  rows  if  they  exist in dashboards. The module will not manage
   rows that are not defined, allowing users to manage  their  own  custom
   rows.

   salt.states.grafana_dashboard.absent(name, profile='grafana')
          Ensure the named grafana dashboard is absent.

          name   Name of the grafana dashboard.

          profile
                 A pillar key or dict that contains grafana information

   salt.states.grafana_dashboard.present(name,
   base_dashboards_from_pillar=None,         base_panels_from_pillar=None,
   base_rows_from_pillar=None, dashboard=None, profile='grafana')
          Ensure the grafana dashboard exists and is managed.

          name   Name of the grafana dashboard.

          base_dashboards_from_pillar
                 A  pillar  key  that  contains  a  list  of dashboards to
                 inherit from

          base_panels_from_pillar
                 A pillar key that contains a list of  panels  to  inherit
                 from

          base_rows_from_pillar
                 A pillar key that contains a list of rows to inherit from

          dashboard
                 A dict that defines a dashboard that should be managed.

          profile
                 A pillar key or dict that contains grafana information

   salt.states.grafana_datasource module
   Manage Grafana v2.0 data sources

   New in version 2016.3.0.

      grafana:
        grafana_timeout: 3
        grafana_token: qwertyuiop
        grafana_url: 'https://url.com'

      Ensure influxdb data source is present:
        grafana_datasource.present:
          - name: influxdb
          - type: influxdb
          - url: http://localhost:8086
          - access: proxy
          - basic_auth: true
          - basic_auth_user: myuser
          - basic_auth_password: mypass
          - is_default: true

   salt.states.grafana_datasource.absent(name, profile='grafana')
          Ensure that a data source is present.

          name   Name of the data source to remove.

   salt.states.grafana_datasource.present(name, type, url, access='proxy',
   user='',       password='',       database='',        basic_auth=False,
   basic_auth_user='',      basic_auth_password='',      is_default=False,
   json_data=None, profile='grafana')
          Ensure that a data source is present.

          name   Name of the data source.

          type   Which type of data source it is  ('graphite',  'influxdb'
                 etc.).

          url    The URL to the data source API.

          user   Optional - user to authenticate with the data source

          password
                 Optional - password to authenticate with the data source

          basic_auth
                 Optional  -  set  to  True  to  use  HTTP  basic  auth to
                 authenticate with the data source.

          basic_auth_user
                 Optional - HTTP basic auth username.

          basic_auth_password
                 Optional - HTTP basic auth password.

          is_default
                 Default: False

   salt.states.grains
   Manage grains on the minion
   This state allows for grains to be set.  Grains set or altered this way
   are  stored  in  the  'grains'  file  on  the  minions,  by default at:
   /etc/salt/grains

   Note: This does NOT override any grains set in the minion file.

   salt.states.grains.absent(name,    destructive=False,    delimiter=':',
   force=False)
          New in version 2014.7.0.

          Delete a grain from the grains config file

          name   The grain name

          destructive
                 If  destructive  is  True,  delete  the  entire grain. If
                 destructive is False, set  the  grain's  value  to  None.
                 Defaults to False.

          force  If  force is True, the existing grain will be overwritten
                 regardless  of  its  existing  or  provided  value  type.
                 Defaults to False

                 New in version v2015.8.2.

          delimiter
                 A delimiter different from the default can be provided.

                 New in version v2015.8.2.

          Changed in version v2015.8.2.

          This  state  now support nested grains and complex values. It is
          also more conservative: if a grain has a value that is a list or
          a  dict,  it  will  not be removed unless the force parameter is
          True.

             grain_name:
               grains.absent: []

   salt.states.grains.append(name, value, convert=False, delimiter=':')
          New in version 2014.7.0.

          Append a value to a list in the grains config  file.  The  grain
          that is being appended to (name) must exist before the new value
          can be added.

          name   The grain name

          value  The value to append

          convert
                 If convert is True,  convert  non-list  contents  into  a
                 list.   If  convert  is  False  and  the  grain  contains
                 non-list contents, an error is given. Defaults to False.

          delimiter
                 A delimiter different from the default can be provided.

                 New in version v2015.8.2.

             grain_name:
               grains.append:
                 - value: to_be_appended

   salt.states.grains.list_absent(name, value, delimiter=':')
          Delete a value from a grain formed as a list.

          New in version 2014.1.0.

          name   The grain name.

          value  The value to delete from the grain list.

          delimiter
                 A delimiter different from the default : can be provided.

                 New in version v2015.8.2.

          The grain should be list type

             roles:
               grains.list_absent:
                 - value: db

          For multiple grains, the syntax looks like:

             roles:
               grains.list_absent:
                 - value:
                   - web
                   - dev

   salt.states.grains.list_present(name, value, delimiter=':')
          New in version 2014.1.0.

          Ensure the value is present in the list-type grain. Note: If the
          grain  that  is  provided  in name is not present on the system,
          this new grain will be created with the  corresponding  provided
          value.

          name   The grain name.

          value  The value is present in the list type grain.

          delimiter
                 A delimiter different from the default : can be provided.

                 New in version v2015.8.2.

          The grain should be list type

             roles:
               grains.list_present:
                 - value: web

          For multiple grains, the syntax looks like:

             roles:
               grains.list_present:
                 - value:
                   - web
                   - dev

   salt.states.grains.present(name, value, delimiter=':', force=False)
          Ensure that a grain is set

          Changed in version v2015.8.2.

          name   The grain name

          value  The value to set on the grain

          force  If  force is True, the existing grain will be overwritten
                 regardless  of  its  existing  or  provided  value  type.
                 Defaults to False

                 New in version v2015.8.2.

          delimiter
                 A delimiter different from the default can be provided.

                 New in version v2015.8.2.

          It  is  now capable to set a grain to a complex value (ie. lists
          and dicts) and supports nested grains as well.

          If the grain does not yet exist, a new grain is set to the given
          value.  For  a  nested  grain, the necessary keys are created if
          they don't exist. If a given key is an existing value,  it  will
          be converted, but an existing value different from the given key
          will fail the state.

          If the grain with the given name exists, its value is updated to
          the  new  value unless its existing or provided value is complex
          (list or dict). Use force: True to overwrite.

             cheese:
               grains.present:
                 - value: edam

             nested_grain_with_complex_value:
               grains.present:
                 - name: icinga:Apache SSL
                 - value:
                   - command: check_https
                   - params: -H localhost -p 443 -S

             with,a,custom,delimiter:
               grains.present:
                 - value: yay
                 - delimiter: ,

   salt.states.group
   Management of user groups
   The group module is used to create  and  manage  unix  group  settings,
   groups can be either present or absent:

      cheese:
        group.present:
          - gid: 7648
          - system: True
          - addusers:
            - user1
            - users2
          - delusers:
            - foo

      cheese:
        group.present:
          - gid: 7648
          - system: True
          - members:
            - foo
            - bar
            - user1
            - user2

   salt.states.group.absent(name)
          Ensure that the named group is absent

          name   The name of the group to remove

   salt.states.group.present(name,  gid=None, system=False, addusers=None,
   delusers=None, members=None)
          Ensure that a group is present

          name   The name of the group to manage

          gid    The group id to assign to the named group; if left empty,
                 then the next available group id will be assigned

          system Whether  or  not the named group is a system group.  This
                 is essentially the '-r' option of 'groupadd'.

          addusers
                 List of additional users to be added as a group members.

          delusers
                 Ensure these user are removed from the group membership.

          members
                 Replace  existing  group  members  with  a  list  of  new
                 members.

          Note:  Options  'members'  and  'addusers/delusers' are mutually
          exclusive and
                 can not be used together.

   salt.states.hg
   Interaction with Mercurial repositories
   Before using hg over ssh, make sure the remote host fingerprint already
   exists  in  ~/.ssh/known_hosts,  and  the  remote  host has this host's
   public key.

      https://bitbucket.org/example_user/example_repo:
          hg.latest:
            - rev: tip
            - target: /tmp/example_repo

   salt.states.hg.latest(name,   rev=None,    target=None,    clean=False,
   user=None, identity=None, force=False, opts=False)
          Make sure the repository is cloned to the given directory and is
          up to date

          name   Address of the remote repository as passed to "hg clone"

          rev    The remote branch, tag, or revision hash to clone/pull

          target Target destination directory path on minion to clone into

          clean  Force a clean update with -C (Default: False)

          user   Name  of  the  user  performing   repository   management
                 operations

                 New in version 0.17.0.

          identity
                 Private  SSH  key on the minion server for authentication
                 (ssh://)

                 New in version 2015.5.0.

          force  Force hg to clone into pre-existing directories  (deletes
                 contents)

          opts   Include  additional  arguments  and  options  to  the  hg
                 command line

   salt.states.hipchat
   Send a message to Hipchat
   This state is useful for sending messages to Hipchat during state runs.

   The property api_url is optional. By defaul will use the public HipChat
   API at https://api.hipchat.com

   New in version 2015.5.0.

      hipchat-message:
        hipchat.send_message:
          - room_id: 123456
          - from_name: SuperAdmin
          - message: 'This state was executed successfully.'
          - api_url: https://hipchat.myteam.com
          - api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15
          - api_version: v1

   The api key can be specified in the master or minion configuration like
   below:

      hipchat:
        api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15
        api_version: v1

   salt.states.hipchat.send_message(name,  room_id,  from_name,   message,
   api_url=None,  api_key=None,  api_version=None, message_color='yellow',
   notify=False)
          Send a message to a Hipchat room.

             hipchat-message:
               hipchat.send_message:
                 - room_id: 123456
                 - from_name: SuperAdmin
                 - message: 'This state was executed successfully.'
                 - api_url: https://hipchat.myteam.com
                 - api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15
                 - api_version: v1
                 - color: green
                 - notify: True

          The following parameters are required:

          name   The unique name for this event.

          room_id
                 The room to send the message to. Can either be the ID  or
                 the name.

          from_name
                 The  name of that is to be shown in the "from" field.  If
                 not specified, defaults to.

          message
                 The message that is to be sent to the Hipchat room.

          The following parameters are optional:

          api_url
                 The API URl to be used.  If not specified here or in  the
                 configuration  options  of master or minion, will use the
                 public HipChat API: https://api.hipchat.com

          api_key
                 The api key for Hipchat to use for authentication, if not
                 specified  in  the  configuration  options  of  master or
                 minion.

          api_version
                 The api version for Hipchat to use, if not  specified  in
                 the configuration options of master or minion.

          color  The color the Hipchat message should be displayed in. One
                 of  the  following,  default:  yellow  "yellow",   "red",
                 "green", "purple", "gray", or "random".

          notify Should a notification in the room be raised.

   salt.states.host
   Management of addresses and names in hosts file
   The  /etc/hosts file can be managed to contain definitions for specific
   hosts:

      salt-master:
        host.present:
          - ip: 192.168.0.42

   Or using the names directive, you can put several names  for  the  same
   IP.  (Do not try one name with space-separated values).

      server1:
        host.present:
          - ip: 192.168.0.42
          - names:
            - server1
            - florida

   NOTE:
      Changing  the  names  in  host.present  does  not cause an update to
      remove the old entry.

      server1:
        host.present:
          - ip:
            - 192.168.0.42
            - 192.168.0.43
            - 192.168.0.44
          - names:
            - server1

   You can replace all existing names for a particular IP address:

      127.0.1.1:
        host.only:
          - hostnames:
            - foo.example.com
            - foo

   Or delete all existing names for an address:

      203.0.113.25:
          host.only:
            - hostnames: []

   salt.states.host.absent(name, ip)
          Ensure that the named host is absent

          name   The host to remove

          ip     The ip addr(s) of the host to remove

   salt.states.host.only(name, hostnames)
          Ensure that only the given hostnames  are  associated  with  the
          given IP address.

          New in version 2016.3.0.

          name   The IP address to associate with the given hostnames.

          hostnames
                 Either  a  single  hostname  or  a  list  of hostnames to
                 associate with the given IP address in the  given  order.
                 Any  other  hostname  associated  with  the IP address is
                 removed.  If no hostnames are  specified,  all  hostnames
                 associated with the given IP address are removed.

   salt.states.host.present(name, ip)
          Ensures that the named host is present with the given ip

          name   The host to assign an ip to

          ip     The ip addr(s) to apply to the host

   salt.states.htpasswd
   Support  for  htpasswd  module.  Requires the apache2-utils package for
   Debian-based distros.

   New in version 2014.7.0.

      username:
        webutil.user_exists:
          - password: secr3t
          - htpasswd_file: /etc/nginx/htpasswd
          - options: d
          - force: true

   salt.states.htpasswd.user_exists(name,                   password=None,
   htpasswd_file=None, options='', force=False, runas=None)
          Make sure the user is inside the specified htpasswd file

          name   User name

          password
                 User password

          htpasswd_file
                 Path to the htpasswd file

          options
                 See salt.modules.htpasswd.useradd

          force  Touch the file even if user already created

          runas  The system user to run htpasswd command with

   salt.states.http
   HTTP monitoring states

   Perform an HTTP query and statefully return the result

   New in version 2015.5.0.

   salt.states.http.query(name,      match=None,      match_type='string',
   status=None, wait_for=None, **kwargs)
          Perform an HTTP query and statefully return the result

          New in version 2015.5.0.

          name   The name of the query.

          match  Specifies a pattern to look for in the  return  text.  By
                 default, this will perform a string comparison of looking
                 for the value of match in the return text.

          match_type
                 Specifies the type of pattern matching to use. Default is
                 string,  but  can  also  be  set  to  pcre to use regular
                 expression matching if a more complex pattern matching is
                 required.

                 NOTE:
                    Despite the name of match_type for this argument, this
                    setting actually uses  Python's  re.search()  function
                    rather than Python's re.match() function.

          status The status code for a URL for which to be checked. Can be
                 used instead of or in addition to the match setting.

          If both match and status options are set, both settings will  be
          checked.   However, note that if only one option is True and the
          other is False, then False will be returned.  If  this  case  is
          reached,   the   comments   in  the  return  data  will  contain
          troubleshooting information.

          For more information about the http.query state,  refer  to  the
          HTTP Tutorial.

             query_example:
               http.query:
                 - name: 'http://example.com/'
                 - status: '200'

   salt.states.http.wait_for_successful_query(name,          wait_for=300,
   **kwargs)
          Like query but, repeat and wait until match/match_type or status
          is fulfilled. State returns result from last query state in case
          of success or if no successful query was  made  within  wait_for
          timeout.

   salt.states.ifttt
   Trigger an event in IFTTT
   This state is useful for trigging events in IFTTT.

   New in version 2015.8.0.

      ifttt-event:
        ifttt.trigger_event:
          - event: TestEvent
          - value1: 'This state was executed successfully.'
          - value2: 'Another value we can send.'
          - value3: 'A third value we can send.'

   The api key can be specified in the master or minion configuration like
   below:

      ifttt: secret_key: bzMRb-KKIAaNOwKEEw792J7Eb-B3z7muhdhYblJn4V6

   salt.states.ifttt.trigger_event(name, event, value1=None,  value2=None,
   value3=None)
          Trigger an event in IFTTT

             ifttt-event:
               ifttt.trigger_event:
                 - event: TestEvent
                 - value1: 'A value that we want to send.'
                 - value2: 'A second value that we want to send.'
                 - value3: 'A third value that wen want to send.'

          The following parameters are required:

          name   The unique name for this event.

          event  The name of the event to trigger in IFTTT.

          The following parameters are optional:

          value1 One of the values that we can send to IFTT.

          value2 One of the values that we can send to IFTT.

          value3 One of the values that we can send to IFTT.

   salt.states.incron
   Management of incron, the inotify cron
   The  incron  state  module  allows  for  user  incrontabs to be cleanly
   managed.

   Incron declarations require a  number  of  parameters.  The  parameters
   needed to be declared: path, mask, and cmd. The user whose incrontab is
   to be edited also needs to be defined.

   When making changes to an existing incron job, the path declaration  is
   the unique factor, so if an existing cron that looks like this:

      Watch for modifications in /home/user:
          incron.present:
              - user: root
              - path: /home/user
              - mask:
                  - IN_MODIFY
              - cmd: 'echo "$$ $@"'

   Is changed to this:

      Watch for modifications and access in /home/user:
          incron.present:
              - user: root
              - path: /home/user
              - mask:
                  - IN_MODIFY
                  - IN_ACCESS
              - cmd: 'echo "$$ $@"'

   Then  the  existing  cron  will  be updated, but if the cron command is
   changed, then a new cron job will be added to the user's crontab.

   New in version 0.17.0.

   salt.states.incron.absent(name, path, mask, cmd, user='root')
          Verifies that  the  specified  incron  job  is  absent  for  the
          specified  user; only the name is matched when removing a incron
          job.

          name   Unique comment describing the entry

          path   The path that should be watched

          user   The name of the user who's crontab needs to be  modified,
                 defaults to the root user

          mask   The mask of events that should be monitored for

          cmd    The cmd that should be executed

   salt.states.incron.present(name, path, mask, cmd, user='root')
          Verifies  that  the  specified  incron  job  is  present for the
          specified  user.   For  more  advanced  information  about  what
          exactly  can  be  set  in the cron timing parameters, check your
          incron system's documentation. Most  Unix-like  systems'  incron
          documentation  can  be  found  via the incrontab man page: man 5
          incrontab.

          name   Unique comment describing the entry

          path   The path that should be watched

          user   The name of the user who's crontab needs to be  modified,
                 defaults to the root user

          mask   The mask of events that should be monitored for

          cmd    The cmd that should be executed

   salt.states.influxdb_database
   Management of Influxdb databases
   (compatible with InfluxDB version 0.9+)

   salt.states.influxdb_database.absent(name, **client_args)
          Ensure that given database is absent.

          name   Name of the database to remove.

   salt.states.influxdb_database.present(name, **client_args)
          Ensure that given database is present.

          name   Name of the database to create.

   salt.states.influxdb_user
   Management of InfluxDB users
   (compatible with InfluxDB version 0.9+)

   salt.states.influxdb_user.absent(name, **client_args)
          Ensure that given user is absent.

          name   The name of the user to manage

   salt.states.influxdb_user.present(name,      password,     admin=False,
   **client_args)
          Ensure that given user is present.

          name   Name of the user to manage

          password
                 Password of the user

          admin  False Whether the user should have cluster administration
                 privileges or not.

   salt.states.infoblox module
   states for infoblox stuff

   ensures a record is either present or absent in an Infoblox DNS system

   New in version 2016.3.0.

   salt.states.infoblox.absent(name,         record_type,        dns_view,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          Ensure a record does not exists

          name   Name of the record

          record_type
                 record type (host, a, cname, etc)

          dns_view
                 DNS View

          infoblox_server
                 infoblox  server  to  connect  to (will try pillar if not
                 specified)

          infoblox_user
                 username to use to connect to infoblox (will  try  pillar
                 if not specified)

          infoblox_password
                 password  to  use to connect to infoblox (will try pillar
                 if not specified)

          verify_ssl
                 verify SSL certificates

          Example:

             some-state:
                 infoblox.absent:
                   - name: some.dns.record
                   - record_type: host
                   - dns_view: MyView
                   - sslVerify: False

   salt.states.infoblox.present(name,   value,   record_type,    dns_view,
   infoblox_server=None,    infoblox_user=None,    infoblox_password=None,
   infoblox_api_version='v1.4.2', sslVerify=True)
          Ensure a record exists

          name   Name of the record

          value  Value of the record

          record_type
                 record type (host, a, cname, etc)

          dns_view
                 DNS View

          infoblox_server
                 infoblox server to connect to (will  try  pillar  if  not
                 specified)

          infoblox_user
                 username  to  use to connect to infoblox (will try pillar
                 if not specified)

          infoblox_password
                 password to use to connect to infoblox (will  try  pillar
                 if not specified)

          verify_ssl
                 verify SSL certificates

          Example:

             some-state:
                 infoblox.present:
                   - name: some.dns.record
                   - value: 10.1.1.3
                   - record_type: host
                   - sslVerify: False

   salt.states.ini_manage
   Manage ini files
   maintainer
          <[email protected]>

   maturity
          new

   depends
          re

   platform
          all

   salt.states.ini_manage.options_absent(name,              sections=None,
   separator='=')

             /home/saltminion/api-paste.ini:
               ini.options_absent:
                 - separator: '='
                 - sections:
                     test:
                       - testkey
                       - secondoption
                     test1:
                       - testkey1

          options present in file and not specified in sections dict  will
          be untouched

          changes dict will contain the list of changes made

   salt.states.ini_manage.options_present(name,             sections=None,
   separator='=')

             /home/saltminion/api-paste.ini:
               ini.options_present:
                 - separator: '='
                 - sections:
                     test:
                       testkey: 'testval'
                       secondoption: 'secondvalue'
                     test1:
                       testkey1: 'testval121'

          options present in file and not specified in sections dict  will
          be untouched

          changes dict will contain the list of changes made

   salt.states.ini_manage.sections_absent(name,             sections=None,
   separator='=')

             /home/saltminion/api-paste.ini:
               ini.sections_absent:
                 - separator: '='
                 - sections:
                     - test
                     - test1

          options present in file and not specified in  sections  will  be
          deleted changes dict will contain the sections that changed

   salt.states.ini_manage.sections_present(name,            sections=None,
   separator='=')

             /home/saltminion/api-paste.ini:
               ini.sections_present:
                 - separator: '='
                 - sections:
                     - section_one
                     - section_two

          This will only create empty sections. To  also  create  options,
          use options_present state

          options  present  in  file and not specified in sections will be
          deleted changes dict will contain the sections that changed

   salt.states.ipmi
   Manage IPMI devices over LAN
   The following configuration defaults can  be  defined  in  the  minion,
   master config or pillar:

      ipmi.config:
          api_host: 127.0.0.1
          api_user: admin
          api_pass: apassword
          api_port: 623
          api_kg: None

   Every call can override the config defaults:

      ensure myipmi system is set to network boot:
          ipmi.boot_device:
              - name: network
              - api_host: myipmi.hostname.com
              - api_user: root
              - api_pass: apassword
              - api_kg: None

      ensure myipmi system is powered on:
          ipmi.power:
              - name: boot
              - api_host: myipmi.hostname.com
              - api_user: root
              - api_pass: apassword

   salt.states.ipmi.boot_device(name='default', **kwargs)
          Request power state change

          name = default

                 * network -- Request network boot

                 * hd -- Boot from hard drive

                 * safe -- Boot from hard drive, requesting 'safe mode'

                 * optical -- boot from CD/DVD/BD drive

                 * setup -- Boot into setup utility

                 * default -- remove any IPMI directed boot device request

          kwargs

                 * api_host=localhost

                 * api_user=admin

                 * api_pass=

                 * api_port=623

                 * api_kg=None

   salt.states.ipmi.power(name='power_on', wait=300, **kwargs)
          Request power state change

          name

                 Ensure power state one of:

                        * power_on -- system turn on

                        * power_off  --  system  turn off (without waiting
                          for OS)

                        * shutdown -- request OS proper shutdown

                        * reset -- reset (without waiting for OS)

                        * boot --  If  system  is  off,  then  'on',  else
                          'reset'

          wait   wait  X  seconds  for the job to complete before forcing.
                 (defaults to 300 seconds)

          kwargs

                 * api_host=localhost

                 * api_user=admin

                 * api_pass=

                 * api_port=623

                 * api_kg=None

   salt.states.ipmi.user_absent(name, channel=14, **kwargs)
          Remove user Delete all user (uid) records  having  the  matching
          name.

          name   string name of user to delete

          channel
                 channel  to  remove  user  access from defaults to 14 for
                 auto.

          kwargs

                 * api_host=localhost

                 * api_user=admin

                 * api_pass=

                 * api_port=623

                 * api_kg=None

   salt.states.ipmi.user_present(name,    uid,    password,    channel=14,
   callback=False,              link_auth=True,             ipmi_msg=True,
   privilege_level='administrator', **kwargs)
          Ensure IPMI user and user privileges.

          name   name of user (limit 16 bytes)

          uid    user id number (1 to 7)

          password
                 user password (limit 16 bytes)

          channel
                 ipmi channel defaults to 14 for auto

          callback
                 User Restricted to Callback

                 False = User Privilege Limit is determined  by  the  User
                 Privilege Limit
                        parameter  privilege_level,  for both callback and
                        non-callback connections.

                 True  =  User  Privilege  Limit  is  determined  by   the
                 privilege_level
                        parameter   for   callback   connections,  but  is
                        restricted  to  Callback  level  for  non-callback
                        connections.  Thus,  a  user  can  only initiate a
                        Callback when they 'call in' to the BMC, but  once
                        the  callback  connection  has been made, the user
                        could  potentially  establish  a  session  as   an
                        Operator.

          link_auth
                 User   Link   authentication  True/False  user  name  and
                 password   information   will   be    used    for    link
                 authentication,  e.g.  PPP  CHAP)  for the given channel.
                 Link authentication itself is a global  setting  for  the
                 channel  and  is  enabled/disabled  via  the serial/modem
                 configuration parameters.

          ipmi_msg
                 User IPMI Messaging True/False  user  name  and  password
                 information  will  be  used  for  IPMI Messaging. In this
                 case, 'IPMI Messaging' refers to the ability  to  execute
                 generic  IPMI  commands  that  are  not associated with a
                 particular payload type. For example, if  IPMI  Messaging
                 is  disabled  for  a  user,  but that user is enabled for
                 activating the  SOL  payload  type,  then  IPMI  commands
                 associated  with  SOL and session management, such as Get
                 SOL  Configuration  Parameters  and  Close  Session   are
                 available, but generic IPMI commands such as Get SEL Time
                 are unavailable.)  ipmi_msg

          privilege_level

                 * callback

                 * user

                 * operator

                 * administrator

                 * proprietary

                 * no_access

          kwargs

                 * api_host=localhost

                 * api_user=admin

                 * api_pass=

                 * api_port=623

                 * api_kg=None

   salt.states.ipset
   Management of ipsets
   This is an ipset-specific module designed to manage IPSets for  use  in
   IPTables Firewalls.

      setname:
        ipset.set_present:
          - set_type: bitmap:ip
          - range: 192.168.0.0/16
          - comment: True

      setname:
        ipset.set_absent:
          - set_type: bitmap:ip
          - range: 192.168.0.0/16
          - comment: True

      setname_entries:
        ipset.present:
          - set_name: setname
          - entry: 192.168.0.3
          - comment: Hello
          - require:
              - ipset: baz

      setname_entries:
        ipset.present:
          - set_name: setname
          - entry:
              - 192.168.0.3
              - 192.168.1.3
          - comment: Hello
          - require:
              - ipset: baz

      setname_entries:
        ipset.absent:
          - set_name: setname
          - entry:
              - 192.168.0.3
              - 192.168.1.3
          - comment: Hello
          - require:
              - ipset: baz

      setname:
        ipset.flush:

   salt.states.ipset.absent(name, entry=None, entries=None, family='ipv4',
   **kwargs)
          New in version 2014.7.0.

          Remove a entry or entries from a chain

          name   A user-defined name to call this entry by in another part
                 of  a  state  or  formula.  This  should not be an actual
                 entry.

          family Network family, ipv4 or ipv6.

   salt.states.ipset.flush(name, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Flush current ipset set

          family Networking family, either ipv4 or ipv6

   salt.states.ipset.present(name, entry=None, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Append a entry to a set

          name   A user-defined name to call this entry by in another part
                 of  a  state  or  formula.  This  should not be an actual
                 entry.

          entry  A single entry to add to a set or a list  of  entries  to
                 add to a set

          family Network family, ipv4 or ipv6.

   salt.states.ipset.set_absent(name, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Verify the set is absent.

          family Networking family, either ipv4 or ipv6

   salt.states.ipset.set_present(name, set_type, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Verify the set exists.

          name   A user-defined set name.

          set_type
                 The type for the set.

          family Networking family, either ipv4 or ipv6

   salt.states.iptables
   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.

      httpd:
        iptables.append:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.append:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match:
              - state
              - comment
          - comment: "Allow HTTP"
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.append:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match:
              - state
              - comment
          - comment: "Allow HTTP"
          - connstate: NEW
          - source: '127.0.0.1'
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      .. Invert Rule
      httpd:
        iptables.append:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match:
              - state
              - comment
          - comment: "Allow HTTP"
          - connstate: NEW
          - source: '! 127.0.0.1'
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.append:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match:
              - state
              - comment
          - comment: "Allow HTTP"
          - connstate: NEW
          - source: 'not 127.0.0.1'
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.append:
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.append:
          - table: filter
          - family: ipv4
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dports:
              - 80
              - 443
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.insert:
          - position: 1
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.insert:
          - position: 1
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.delete:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.delete:
          - position: 1
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        iptables.delete:
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      default to accept:
        iptables.set_policy:
          - chain: INPUT
          - policy: ACCEPT

   NOTE:
      Various functions of the iptables module use the --check option.  If
      the  version  of iptables on the target system does not include this
      option, an alternate version of this check will be  performed  using
      the  output  of iptables-save. This may have unintended consequences
      on legacy releases of iptables.

   salt.states.iptables.append(name,    table='filter',     family='ipv4',
   **kwargs)
          New in version 0.17.0.

          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 formula. This should not be an actual rule.

          table  The table that owns the chain which should be modified

          family Network family, ipv4 or ipv6.

          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 ctstate).

          Jump  options  that  doesn't  take arguments should be passed in
          with an empty string.

   salt.states.iptables.chain_absent(name, table='filter', family='ipv4')
          New in version 2014.1.0.

          Verify the chain is absent.

          table  The table to remove the chain from

          family Networking family, either ipv4 or ipv6

   salt.states.iptables.chain_present(name, table='filter', family='ipv4')
          New in version 2014.1.0.

          Verify the chain is exist.

          name   A user-defined chain name.

          table  The table to own the chain.

          family Networking family, either ipv4 or ipv6

   salt.states.iptables.delete(name,    table='filter',     family='ipv4',
   **kwargs)
          New in version 2014.1.0.

          Delete a rule to a chain

          name   A  user-defined name to call this rule by in another part
                 of a state or formula. This should not be an actual rule.

          table  The table that owns the chain that should be modified

          family Networking family, either ipv4 or ipv6

          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 ctstate).

          Jump  options  that  doesn't  take arguments should be passed in
          with an empty string.

   salt.states.iptables.flush(name,     table='filter',     family='ipv4',
   **kwargs)
          New in version 2014.1.0.

          Flush current iptables state

          table  The table that owns the chain that should be modified

          family Networking family, either ipv4 or ipv6

   salt.states.iptables.insert(name,     table='filter',    family='ipv4',
   **kwargs)
          New in version 2014.1.0.

          Insert a rule into a chain

          name   A user-defined name to call this rule by in another  part
                 of a state or formula. This should not be an actual rule.

          table  The table that owns the chain that should be modified

          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 ctstate).

          Jump options that doesn't take arguments  should  be  passed  in
          with an empty string.

   salt.states.iptables.mod_aggregate(low, chunks, running)
          The  mod_aggregate  function  which  looks  up  all rules in the
          available low chunks and merges them into a single rules ref  in
          the present low data

   salt.states.iptables.set_policy(name,   table='filter',  family='ipv4',
   **kwargs)
          New in version 2014.1.0.

          Sets the default policy for iptables firewall tables

          table  The table that owns the chain that should be modified

          family Networking family, either ipv4 or ipv6

          policy The requested table policy

   salt.states.jboss7
   Manage JBoss 7 Application Server via CLI interface

   New in version 2015.5.0.

   This state uses  the  jboss-cli.sh  script  from  a  JBoss  or  Wildfly
   installation and parses its output to determine the execution result.

   In  order  to  run  each  state,  a  jboss_config  dictionary  with the
   following properties must be passed:

      jboss:
         cli_path: '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'
         controller: 10.11.12.13:9999
         cli_user: 'jbossadm'
         cli_password: 'jbossadm'

   If the controller doesn't require a password,  then  the  cli_user  and
   cli_password parameters are optional.

   Since  same  dictionary  with  configuration  will  be  used in all the
   states, it may be more convenient to move JBoss configuration and other
   properties to the pillar.

   Example of application deployment from local filesystem:

      application_deployed:
        jboss7.deployed:
          - salt_source:
              target_file: '/tmp/webapp.war'
          - jboss_config: {{ pillar['jboss'] }}

   For   the  sake  of  brevity,  examples  for  each  state  assume  that
   jboss_config is contained in the pillar.

   salt.states.jboss7.bindings_exist(name,     jboss_config,     bindings,
   profile=None)
          Ensures that given JNDI binding are present on the server.  If a
          binding doesn't exist on the server it will be created.   If  it
          already exists its value will be changed.

          jboss_config:
                 Dict with connection properties (see state description)

          bindings:
                 Dict with bindings to set.

          profile:
                 The profile name (domain mode only)

          Example:

             jndi_entries_created:
               jboss7.bindings_exist:
                - bindings:
                   'java:global/sampleapp/environment': 'DEV'
                   'java:global/sampleapp/configurationFile': '/var/opt/sampleapp/config.properties'
                - jboss_config: {{ pillar['jboss'] }}

   salt.states.jboss7.datasource_exists(name,                jboss_config,
   datasource_properties, recreate=False, profile=None)
          Ensures that a datasource with given  properties  exist  on  the
          jboss  instance.   If  datasource  doesn't exist, it is created,
          otherwise  only  the  properties  that  are  different  will  be
          updated.

          name   Datasource property name

          jboss_config
                 Dict with connection properties (see state description)

          datasource_properties
                 Dict with datasource properties

          recreate
                 False  If  set  to  True and datasource exists it will be
                 removed  and  created  again.  However,  if   there   are
                 deployments that depend on the datasource, it will not me
                 possible to remove it.

          profile
                 None The profile name for this  datasource  (domain  mode
                 only)

          Example:

             sampleDS:
               jboss7.datasource_exists:
                - recreate: False
                - datasource_properties:
                    driver-name: mysql
                    connection-url: 'jdbc:mysql://localhost:3306/sampleDatabase'
                    jndi-name: 'java:jboss/datasources/sampleDS'
                    user-name: sampleuser
                    password: secret
                    min-pool-size: 3
                    use-java-context: True
                - jboss_config: {{ pillar['jboss'] }}
                - profile: full-ha

   salt.states.jboss7.deployed(name, jboss_config, salt_source=None)
          Ensures that the given application is deployed on server.

          jboss_config:
                 Dict with connection properties (see state description)

          salt_source:

                 How to find the artifact to be deployed.

                        target_file:
                               Where  to  look in the minion's file system
                               for  the  artifact  to  be  deployed  (e.g.
                               '/tmp/application-web-0.39.war').      When
                               source is specified,  also specifies  where
                               to save the retrieved file.

                        source:
                               (optional)   File   on  salt  master  (e.g.
                               salt://application-web-0.39.war).        If
                               absent,  no files will be retrieved and the
                               artifact in target_file will  be  used  for
                               the deployment.

                        undeploy:
                               (optional)   Regular  expression  to  match
                               against   existing    deployments.     When
                               present,  if  there  is  a  deployment that
                               matches the regular expression, it will  be
                               undeployed   before  the  new  artifact  is
                               deployed.

          Examples:

          Deployment of a file from minion's local file system:

             application_deployed:
               jboss7.deployed:
                 - salt_source:
                     target_file: '/tmp/webapp.war'
                 - jboss_config: {{ pillar['jboss'] }}

          It is assumed that /tmp/webapp.war was made  available  by  some
          other means.  No applications will be undeployed; if an existing
          deployment that  shares  that  name  exists,  then  it  will  be
          replaced with the updated version.

          Deployment of a file from the Salt master's file system:

             application_deployed:
               jboss7.deployed:
                - salt_source:
                     source: salt://application-web-0.39.war
                     target_file: '/tmp/application-web-0.39.war'
                     undeploy: 'application-web-.*'
                - jboss_config: {{ pillar['jboss'] }}

          Here, application-web-0.39.war file is downloaded from Salt file
          system  to   /tmp/application-web-0.39.war   file   on   minion.
          Existing   deployments  are  checked  if  any  of  them  matches
          'application-web-.*' regular expression, and if so  then  it  is
          undeployed  before  deploying the application. This is useful to
          automate deployment of new application versions.

          If the source parameter of salt_source is specified, it can  use
          any  protocol  that the file states use.  This includes not only
          downloading from the master but also HTTP,  HTTPS,  FTP,  Amazon
          S3, and OpenStack Swift.

   salt.states.jboss7.reloaded(name, jboss_config, timeout=60, interval=5)
          Reloads configuration of jboss server.

          jboss_config:
                 Dict with connection properties (see state description)

          timeout:
                 Time  to  wait  until  jboss  is  back  in running state.
                 Default timeout is 60s.

          interval:
                 Interval between state checks. Default  interval  is  5s.
                 Decreasing  the  interval  may  slightly decrease waiting
                 time but be aware that every status check is  a  call  to
                 jboss-cli which is a java process. If interval is smaller
                 than process cleanup time it may easily lead to excessive
                 resource consumption.

          This step performs the following operations:

          * Ensures that server is in running or reload-required state (by
            reading server-state attribute)

          * Reloads configuration

          * Waits for server to reload and be in running state

          Example:

             configuration_reloaded:
                jboss7.reloaded:
                 - jboss_config: {{ pillar['jboss'] }}

   salt.states.jenkins module
   Management of Jenkins
   New in version 2016.3.0.

   salt.states.jenkins.absent(name, **kwargs)
          Ensure the job is present in the Jenkins configured jobs

          name   The name of the Jenkins job to remove.

   salt.states.jenkins.present(name, config=None, **kwargs)
          Ensure the job is present in the Jenkins configured jobs

          name   The unique name for the Jenkins job

          config The Salt URL for the file to use for configuring the job.

   salt.states.junos module
   State modules to interact with Junos devices.
   These modules call the corresponding execution modules.  Refer to junos
   for further information.

   salt.states.junos.cli(name)
          Executes the CLI commands and reuturns the text output.

             show version:
               junos.cli

          name: the command to be executed on junos CLI.

   salt.states.junos.commit(name)
          Commits the changes loaded into the candidate configuration.

             commit the changes:
               junos.commit

          name: can be anything

   salt.states.junos.diff(name)
          Gets  the  difference  between  the  candidate  and  the current
          configuration.

             get the diff:
               junos.diff

          name: can be anything

   salt.states.junos.file_copy(name, dest=None)
          Copies the file from the local device to the junos device.

             /home/m2/info.txt:
               junos:
                 - file_copy
                 - dest: info_copy.txt

          name: source path of the file.

          dest: destination path where the file will be placed.

   salt.states.junos.install_config(name, **kwargs)
          Loads and commits the configuration provided.

             /home/user/config.set:
               junos:
                 - install_config
                 - timeout: 100

          name: path to the configuration file.

          keyworded arguments taken by load fucntion of PyEZ

   salt.states.junos.install_os(name, **kwargs)
          Installs the given image on the device. After  the  installation
          is complete the device is rebooted, if reboot=True is given as a
          keyworded argument.

             /home/user/junos_image.tgz:
               junos:
                 - install_os
                 - timeout: 100
                 - reboot: True

          name: path to the image file.

          kwargs: keyworded arguments to be given such as timeout,  reboot
          etc

   salt.states.junos.rollback(name)
          Rollbacks the committed changes.

             rollback the changes:
               junos.rollback

          name: can be anything

   salt.states.junos.rpc(name,    dest=None,    format='xml',   args=None,
   **kwargs)
             Executes the given rpc. The returned data can be stored in  a
             file  by  specifying  the  destination  path  with dest as an
             argument

                 get-interface-information:
                     junos:
                       - rpc
                       - dest: /home/user/rpc.log
                       - interface_name: lo0

          name: the rpc to be executed.

          args: other arguments as taken by rpc call of PyEZ

          kwargs: keyworded arguments taken by rpc call of PyEZ

   salt.states.junos.set_hostname(name, commit_changes=True)
             Changes the hostname of the device.

                 device name:
                   junos:
                     - set_hostname
                     - commit_changes: False

          name: the name to be given to the device

          commit_changes: whether to commit the changes

   salt.states.junos.shutdown(name, time=0)
          Shuts down the device.

             shut the device:
               junos:
                 - shutdown
                 - time: 10

          name: can be anything

          time: time after which the system  should  shutdown(in  seconds,
          default=0)

   salt.states.junos.zeroize(name)
          Resets the device to default factory settings.

             reset my device:
               junos.zeroize

          name: can be anything

   salt.states.k8s
   Manage Kubernetes

   New in version 2016.3.0.

      kube_label_1:
        k8s.label_present:
          - name: mylabel
          - value: myvalue
          - node: myothernodename
          - apiserver: http://mykubeapiserer:8080

      kube_label_2:
        k8s.label_absent:
          - name: mylabel
          - node: myothernodename
          - apiserver: http://mykubeapiserer:8080

      kube_label_3:
        k8s.label_folder_present:
          - name: mylabel
          - node: myothernodename
          - apiserver: http://mykubeapiserer:8080

   salt.states.k8s.label_absent(name, node=None, apiserver=None)
          Ensure the label doesn't exist on the kube node.

          name   Name of the label.

          node   Override node ID.

          apiserver
                 K8S apiserver URL.

   salt.states.k8s.label_folder_absent(name, node=None, apiserver=None)
          Ensure the label folder doesn't exist on the kube node.

          name   Name of the label folder.

          node   Override node ID.

          apiserver
                 K8S apiserver URL.

   salt.states.k8s.label_present(name, value, node=None, apiserver=None)
          Ensure the label exists on the kube node.

          name   Name of the label.

          value  Value of the label.

          node   Override node ID.

          apiserver
                 K8S apiserver URL.

   salt.states.kapacitor module
   Kapacitor state module.

   configuration
          This  module  accepts connection configuration details either as
          parameters or as configuration settings in  /etc/salt/minion  on
          the relevant minions:

             kapacitor.host: 'localhost'
             kapacitor.port: 9092

          This  data  can  also be passed into pillar. Options passed into
          opts will overwrite options passed into pillar.

   New in version 2016.11.0.

   salt.states.kapacitor.task_absent(name)
          Ensure that a task is absent from Kapacitor.

          name   Name of the task.

   salt.states.kapacitor.task_present(name,                   tick_script,
   task_type='stream',      database=None,     retention_policy='default',
   enable=True)
          Ensure that a task is present and up-to-date in Kapacitor.

          name   Name of the task.

          tick_script
                 Path to the TICK script for the task. Can  be  a  salt://
                 source.

          task_type
                 Task type. Defaults to 'stream'

          database
                 Which  database  to  fetch  data  from. Defaults to None,
                 which will use the default database in InfluxDB.

          retention_policy
                 Which retention policy to fetch data  from.  Defaults  to
                 'default'.

          enable Whether to enable the task or not. Defaults to True.

   salt.states.keyboard
   Management of keyboard layouts
   The keyboard layout can be managed for the system:

      us:
        keyboard.system

   Or it can be managed for XOrg:

      us:
        keyboard.xorg

   salt.states.keyboard.system(name)
          Set the keyboard layout for the system

          name   The keyboard layout to use

   salt.states.keyboard.xorg(name)
          Set the keyboard layout for XOrg

          layout The keyboard layout to use

   salt.states.keystone
   Management of Keystone users
   depends

          * keystoneclient Python module

   configuration
          See salt.modules.keystone for setup instructions.

      Keystone tenants:
        keystone.tenant_present:
          - names:
            - admin
            - demo
            - service

      Keystone roles:
        keystone.role_present:
          - names:
            - admin
            - Member

      admin:
        keystone.user_present:
          - password: R00T_4CC3SS
          - email: [email protected]
          - roles:
              admin:   # tenants
                - admin  # roles
              service:
                - admin
                - Member
          - require:
            - keystone: Keystone tenants
            - keystone: Keystone roles

      nova:
        keystone.user_present:
          - password: '$up3rn0v4'
          - email: [email protected]
          - tenant: service
          - roles:
              service:
                - admin
          - require:
            - keystone: Keystone tenants
            - keystone: Keystone roles

      demo:
        keystone.user_present:
          - password: 'd3m0n$trati0n'
          - email: [email protected]
          - tenant: demo
          - roles:
              demo:
                - Member
          - require:
            - keystone: Keystone tenants
            - keystone: Keystone roles

      nova service:
        keystone.service_present:
          - name: nova
          - service_type: compute
          - description: OpenStack Compute Service

   salt.states.keystone.endpoint_absent(name,                profile=None,
   **connection_args)
          Ensure that the endpoint for a service doesn't exist in Keystone
          catalog

          name   The name of the service whose endpoints should not exist

   salt.states.keystone.endpoint_present(name,             publicurl=None,
   internalurl=None,  adminurl=None,   region='RegionOne',   profile=None,
   url=None, interface=None, **connection_args)
          Ensure the specified endpoints exists for service

          name   The Service name

          publicurl
                 The public url of service endpoint (for V2 API)

          internalurl
                 The internal url of service endpoint (for V2 API)

          adminurl
                 The admin url of the service endpoint (for V2 API)

          region The region of the endpoint

          url    The endpoint URL (for V3 API)

          interface
                 The interface type, which describes the visibility of the
                 endpoint. (for V3 API)

   salt.states.keystone.project_absent(name,                 profile=None,
   **connection_args)
          Ensure   that   the  keystone  project  is  absent.   Alias  for
          tenant_absent from V2 API to fulfill V3 API naming convention.

          New in version 2016.11.0.

          name   The name of the project that should not exist

             delete_nova:
                 keystone.project_absent:
                     - name: nova

   salt.states.keystone.project_present(name,            description=None,
   enabled=True, profile=None, **connection_args)
          Ensures   that   the   keystone   project   exists   Alias   for
          tenant_present from V2 API to fulfill V3 API naming convention.

          New in version 2016.11.0.

          name   The name of the project to manage

          description
                 The description to use for this project

          enabled
                 Availability state for this project

             nova:
                 keystone.project_present:
                     - enabled: True
                     - description: 'Nova Compute Service'

   salt.states.keystone.role_absent(name, profile=None, **connection_args)
          Ensure that the keystone role is absent.

          name   The name of the role that should not exist

   salt.states.keystone.role_present(name,                   profile=None,
   **connection_args)
          ' Ensures that the keystone role exists

          name   The name of the role that should be present

   salt.states.keystone.service_absent(name,                 profile=None,
   **connection_args)
          Ensure that the service doesn't exist in Keystone catalog

          name   The name of the service that should not exist

   salt.states.keystone.service_present(name,                service_type,
   description=None, profile=None, **connection_args)
          Ensure service present in Keystone catalog

          name   The name of the service

          service_type
                 The type of Openstack Service

          description (optional)
                 Description of the service

   salt.states.keystone.tenant_absent(name,                  profile=None,
   **connection_args)
          Ensure that the keystone tenant is absent.

          name   The name of the tenant that should not exist

   salt.states.keystone.tenant_present(name,             description=None,
   enabled=True, profile=None, **connection_args)
          Ensures that the keystone tenant exists

          name   The name of the tenant to manage

          description
                 The description to use for this tenant

          enabled
                 Availability state for this tenant

   salt.states.keystone.user_absent(name, profile=None, **connection_args)
          Ensure that the keystone user is absent.

          name   The name of the user that should not exist

   salt.states.keystone.user_present(name,  password,  email, tenant=None,
   enabled=True,    roles=None,     profile=None,     password_reset=True,
   project=None, **connection_args)
          Ensure  that  the  keystone  user  is present with the specified
          properties.

          name   The name of the user to manage

          password
                 The password to use for this user.

                 NOTE:
                    If the user already exists and  a  different  password
                    was  set for the user than the one specified here, the
                    password for the user will be updated. Please set  the
                    password_reset  option  to  False  if  this is not the
                    desired behavior.

          password_reset
                 Whether or not  to  reset  password  after  initial  set.
                 Defaults to True.

          email  The email address for this user

          tenant The tenant (name) for this user

          project
                 The project (name) for this user (overrides tenant in api
                 v3)

          enabled
                 Availability state for this user

          roles  The roles the  user  should  have  under  given  tenants.
                 Passed  as a dictionary mapping tenant names to a list of
                 roles in this tenant, i.e.:

                    roles:
                        admin:   # tenant
                          - admin  # role
                        service:
                          - admin
                          - Member

   salt.states.kmod
   Loading and unloading of kernel modules
   The Kernel modules on a system can be managed  cleanly  with  the  kmod
   state module:

      add_kvm:
        kmod.present:
          - name: kvm_amd
      remove_beep:
        kmod.absent:
          - name: pcspkr

   Multiple   modules   can   be   specified  for  both  kmod.present  and
   kmod.absent.

      add_sound:
        kmod.present:
          - mods:
            - snd_hda_codec_hdmi
            - snd_hda_codec
            - snd_hwdep
            - snd_hda_core
            - snd_pcm
            - snd_timer
            - snd

   salt.states.kmod.absent(name, persist=False, comment=True, mods=None)
          Verify that the named kernel module is not loaded

          name   The name of the kernel module to verify is not loaded

          persist
                 Remove module from /etc/modules

          comment
                 Comment out module in /etc/modules rather than remove it

          mods   A list of  modules  to  verify  are  unloaded.   If  this
                 argument  is  used,  the  name  argument,  although still
                 required, is not used, and becomes a placeholder

                 New in version 2016.3.0.

   salt.states.kmod.present(name, persist=False, mods=None)
          Ensure that the specified kernel module is loaded

          name   The name of the kernel module to verify is loaded

          persist
                 Also add module to /etc/modules

          mods   A list of modules to verify are loaded.  If this argument
                 is  used,  the name argument, although still required, is
                 not used, and becomes a placeholder

                 New in version 2016.3.0.

   salt.states.layman
   Management of Gentoo Overlays using layman
   A state module to manage Gentoo package overlays via layman

      sunrise:
          layman.present

   salt.states.layman.absent(name)
          Verify that the overlay is absent

          name   The name of the overlay to delete

   salt.states.layman.present(name)
          Verify that the overlay is present

          name   The name of the overlay to add

   salt.states.ldap
   Manage entries in an LDAP database
   New in version 2016.3.0.

   The states.ldap state module allows you  to  manage  LDAP  entries  and
   their attributes.

   salt.states.ldap.managed(name, entries, connect_spec=None)
          Ensure  the  existence  (or  not)  of  LDAP  entries  and  their
          attributes

          Example:

             ldapi:///:
               ldap.managed:
                 - connect_spec:
                     bind:
                       method: sasl

                 - entries:

                   # make sure the entry doesn't exist
                   - cn=foo,ou=users,dc=example,dc=com:
                     - delete_others: True

                   # make sure the entry exists with only the specified
                   # attribute values
                   - cn=admin,dc=example,dc=com:
                     - delete_others: True
                     - replace:
                         cn:
                           - admin
                         description:
                           - LDAP administrator
                         objectClass:
                           - simpleSecurityObject
                           - organizationalRole
                         userPassword:
                           - {{pillar.ldap_admin_password}}

                   # make sure the entry exists, its olcRootDN attribute
                   # has only the specified value, the olcRootDN attribute
                   # doesn't exist, and all other attributes are ignored
                   - 'olcDatabase={1}hdb,cn=config':
                     - replace:
                         olcRootDN:
                           - cn=admin,dc=example,dc=com
                         # the admin entry has its own password attribute
                         olcRootPW: []

                   # note the use of 'default'.  also note how you don't
                   # have to use list syntax if there is only one attribute
                   # value
                   - cn=foo,ou=users,dc=example,dc=com:
                     - delete_others: True
                     - default:
                         userPassword: changeme
                         shadowLastChange: 0
                         # keep sshPublicKey if present, but don't create
                         # the attribute if it is missing
                         sshPublicKey: []
                     - replace:
                         cn: foo
                         uid: foo
                         uidNumber: 1000
                         gidNumber: 1000
                         gecos: Foo Bar
                         givenName: Foo
                         sn: Bar
                         homeDirectory: /home/foo
                         loginShell: /bin/bash
                         objectClass:
                           - inetOrgPerson
                           - posixAccount
                           - top
                           - ldapPublicKey
                           - shadowAccount

          Parameters

                 * name -- The URL of the LDAP server.  This is ignored if
                   connect_spec  is  either  a connection object or a dict
                   with a 'url' entry.

                 * entries --

                   A description of the desired state of zero or more LDAP
                   entries.

                   entries  is an iterable of dicts.  Each of these dict's
                   keys are the distinguished names (DNs) of LDAP  entries
                   to  manage.  Each of these dicts is processed in order.
                   A later dict can  reference  an  LDAP  entry  that  was
                   already  mentioned  in  an earlier dict, which makes it
                   possible for  later  dicts  to  enhance  or  alter  the
                   desired state of an LDAP entry.

                   The DNs are mapped to a description of the LDAP entry's
                   desired  state.   These  LDAP  entry  descriptions  are
                   themselves  iterables  of  dicts.   Each  dict  in  the
                   iterable  is  processed   in   order.    They   contain
                   directives  controlling  the  entry's  state.   The key
                   names  the  directive  type  and  the  value  is  state
                   information  for the directive.  The specific structure
                   of the state information depends on the directive type.

                   The structure of entries looks like this:

                      [{dn1: [{directive1: directive1_state,
                               directive2: directive2_state},
                              {directive3: directive3_state}],
                        dn2: [{directive4: directive4_state,
                               directive5: directive5_state}]},
                       {dn3: [{directive6: directive6_state}]}]

                   These are the directives:

                   *

                     'delete_others'
                            Boolean   indicating   whether    to    delete
                            attributes  not  mentioned in this dict or any
                            of the other  directive  dicts  for  this  DN.
                            Defaults to False.

                            If  you  don't  want to delete an attribute if
                            present, but you also don't want to add it  if
                            it  is  missing or modify it if it is present,
                            you can use either the 'default' directive  or
                            the 'add' directive with an empty value list.

                   *

                     'default'
                            A   dict  mapping  an  attribute  name  to  an
                            iterable of default values for that attribute.
                            If  the  attribute  already exists, it is left
                            alone.  If not, it is created using the  given
                            list of values.

                            An  empty  value list is useful when you don't
                            want to create an attribute if it  is  missing
                            but   you  do  want  to  preserve  it  if  the
                            'delete_others' key is True.

                   *

                     'add'  Attribute values to add to the entry.  This is
                            a   dict  mapping  an  attribute  name  to  an
                            iterable of values to add.

                            An empty value list is useful when  you  don't
                            want  to  create an attribute if it is missing
                            but  you  do  want  to  preserve  it  if   the
                            'delete_others' key is True.

                   *

                     'delete'
                            Attribute  values  to  remove  from the entry.
                            This is a dict mapping an attribute name to an
                            iterable   of   values   to  delete  from  the
                            attribute.  If the iterable is empty,  all  of
                            the attribute's values are deleted.

                   *

                     'replace'
                            Attributes to replace.  This is a dict mapping
                            an attribute name to an  iterable  of  values.
                            Any  existing  values  for  the  attribute are
                            deleted, then the given values are added.  The
                            iterable may be empty.

                   In  the  above  directives,  the iterables of attribute
                   values may instead be None, in which case an empty list
                   is  used,  or  a  scalar such as a string or number, in
                   which case a new list containing the scalar is used.

                   Note that if all attribute values are removed  from  an
                   entry, the entire entry is deleted.

                 * connect_spec -- See the description of the connect_spec
                   parameter of the ldap3.connect function  in  the  ldap3
                   execution  module.   If  this  is  a dict and the 'url'
                   entry is not specified, the 'url' entry is set  to  the
                   value of the name parameter.

          Returns
                 A dict with the following keys:

                 *

                   'name' This  is  the  same  object  passed  to the name
                          parameter.

                 *

                   'changes'
                          This is a dict describing the changes made  (or,
                          in  test  mode, the changes that would have been
                          attempted).  If no  changes  were  made  (or  no
                          changes  would  have  been attempted), then this
                          dict is  empty.   Only  successful  changes  are
                          included.

                          Each  key  is  a DN of an entry that was changed
                          (or would have been changed).  Entries that were
                          not changed (or would not have been changed) are
                          not included.  The value  is  a  dict  with  two
                          keys:

                          *

                            'old'  The   state   of   the   entry   before
                                   modification.  If  the  entry  did  not
                                   previously  exist,  this  key  maps  to
                                   None.  Otherwise, the value is  a  dict
                                   mapping   each   of   the  old  entry's
                                   attributes to  a  list  of  its  values
                                   before  any  modifications  were  made.
                                   Unchanged attributes are excluded  from
                                   this dict.

                          *

                            'new'  The    state   of   the   entry   after
                                   modification.    If   the   entry   was
                                   deleted,   this   key   maps  to  None.
                                   Otherwise, the value is a dict  mapping
                                   each  of  the  entry's  attributes to a
                                   list   of   its   values   after    the
                                   modifications   were  made.   Unchanged
                                   attributes are excluded from this dict.

                          Example 'changes' dict where  a  new  entry  was
                          created  with  a single attribute containing two
                          values:

                             {'dn1': {'old': None,
                                      'new': {'attr1': ['val1', 'val2']}}}

                          Example 'changes' dict where a new attribute was
                          added to an existing entry:

                             {'dn1': {'old': {},
                                      'new': {'attr2': ['val3']}}}

                 *

                   'result'
                          One of the following values:

                          * True  if  no  changes were necessary or if all
                            changes were applied successfully.

                          * False if at least one change was unable to  be
                            applied.

                          * None  if changes would be applied but it is in
                            test mode.

   salt.states.linux_acl
   Linux File Access Control Lists

   Ensure a Linux ACL is present

      root:
        acl.present:
          - name: /root
          - acl_type: user
          - acl_name: damian
          - perms: rwx

   Ensure a Linux ACL does not exist

      root:
        acl.absent:
          - name: /root
          - acl_type: user
          - acl_name: damian
          - perms: rwx

   salt.states.linux_acl.absent(name,  acl_type,  acl_name='',   perms='',
   recurse=False)
          Ensure a Linux ACL does not exist

   salt.states.linux_acl.present(name,  acl_type,  acl_name='',  perms='',
   recurse=False)
          Ensure a Linux ACL is present

   salt.states.locale
   Management of languages/locales
   Manage the available locales and the system default:

      us_locale:
        locale.present:
          - name: en_US.UTF-8

      default_locale:
        locale.system:
          - name: en_US.UTF-8
          - require:
            - locale: us_locale

   salt.states.locale.present(name)
          Generate a locale if it is not present

          New in version 2014.7.0.

          name   The name of the locale to be present. Some  distributions
                 require the charmap to be specified as part of the locale
                 at this point.

   salt.states.locale.system(name)
          Set the locale for the system

          name   The name of the locale to use

   salt.states.lvm
   Management of Linux logical volumes
   A state module to manage LVMs

      /dev/sda:
        lvm.pv_present

      my_vg:
        lvm.vg_present:
          - devices: /dev/sda

      lvroot:
        lvm.lv_present:
          - vgname: my_vg
          - size: 10G
          - stripes: 5
          - stripesize: 8K

   salt.states.lvm.lv_absent(name, vgname=None)
          Remove a given existing logical volume  from  a  named  existing
          volume group

          name   The logical volume to remove

          vgname The volume group name

   salt.states.lvm.lv_present(name,  vgname=None, size=None, extents=None,
   snapshot=None, pv='', thinvolume=False, thinpool=False, **kwargs)
          Create a new logical volume

          name   The name of the logical volume

          vgname The volume group name for this logical volume

          size   The initial size of the logical volume

          extents
                 The number of logical extents to allocate

          snapshot
                 The name of the snapshot

          pv     The physical volume to use

          kwargs Any supported options to lvcreate. See linux_lvm for more
                 details.

          New in version to_complete.

          thinvolume
                 Logical volume is thinly provisioned

          thinpool
                 Logical volume is a thin pool

   salt.states.lvm.pv_absent(name)
          Ensure that a Physical Device is not being used by lvm

          name   The device name to initialize.

   salt.states.lvm.pv_present(name, **kwargs)
          Set a physical device to be used as an LVM physical volume

          name   The device name to initialize.

          kwargs Any supported options to pvcreate. See linux_lvm for more
                 details.

   salt.states.lvm.vg_absent(name)
          Remove an LVM volume group

          name   The volume group to remove

   salt.states.lvm.vg_present(name, devices=None, **kwargs)
          Create an LVM volume group

          name   The volume group name to create

          devices
                 A list of devices that will be added to the volume group

          kwargs Any supported options to vgcreate. See linux_lvm for more
                 details.

   salt.states.lvs_server
   Management of LVS (Linux Virtual Server) Real Server
   salt.states.lvs_server.absent(name,                      protocol=None,
   service_address=None, server_address=None)
          Ensure the LVS Real Server in specified service is absent.

          name   The name of the LVS server.

          protocol
                 The service protocol(only support  tcp,  udp  and  fwmark
                 service).

          service_address
                 The LVS service address.

          server_address
                 The LVS real server address.

   salt.states.lvs_server.present(name,                     protocol=None,
   service_address=None, server_address=None,  packet_forward_method='dr',
   weight=1)
          Ensure that the named service is present.

          name   The LVS server name

          protocol
                 The service protocol

          service_address
                 The LVS service address

          server_address
                 The real server address.

          packet_forward_method
                 The  LVS  packet forwarding method(dr for direct routing,
                 tunnel   for   tunneling,   nat   for   network    access
                 translation).

          weight The  capacity   of a server relative to the others in the
                 pool.

             lvsrs:
               lvs_server.present:
                 - protocol: tcp
                 - service_address: 1.1.1.1:80
                 - server_address: 192.168.0.11:8080
                 - packet_forward_method: dr
                 - weight: 10

   salt.states.lvs_service
   Management of LVS (Linux Virtual Server) Service
   salt.states.lvs_service.absent(name,                     protocol=None,
   service_address=None)
          Ensure the LVS service is absent.

          name   The name of the LVS service

          protocol
                 The service protocol

          service_address
                 The LVS service address

   salt.states.lvs_service.present(name,                    protocol=None,
   service_address=None, scheduler='wlc')
          Ensure that the named service is present.

          name   The LVS service name

          protocol
                 The service protocol

          service_address
                 The LVS service address

          scheduler
                 Algorithm  for  allocating  TCP   connections   and   UDP
                 datagrams to real servers.

             lvstest:
               lvs_service.present:
                 - service_address: 1.1.1.1:80
                 - protocol: tcp
                 - scheduler: rr

   salt.states.lxc
   Manage Linux Containers
   salt.states.lxc.absent(name, stop=False, path=None)
          Ensure a container is not present, destroying it if present

          name   Name of the container to destroy

          stop   stop before destroying default: false

                 New in version 2015.5.2.

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             web01:
               lxc.absent

   salt.states.lxc.edited_conf(name, lxc_conf=None, lxc_conf_unset=None)

          WARNING:
             This state is unsuitable for setting parameters  that  appear
             more  than  once  in  an LXC config file, or parameters which
             must appear in a certain order (such as when configuring more
             than one network interface). It is slated to be replaced, and
             as of version 2015.5.0 it is deprecated.

          Edit LXC configuration options

          Deprecated since version 2015.5.0.

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

             setconf:
               lxc.edited_conf:
                 - name: ubuntu
                 - lxc_conf:
                     - network.ipv4.ip: 10.0.3.6
                 - lxc_conf_unset:
                     - lxc.utsname

   salt.states.lxc.frozen(name, start=True, path=None)
          New in version 2015.5.0.

          Ensure that a container is frozen

          NOTE:
             This  state  does  not  enforce  the  existence  of the named
             container, it just freezes the container if it is running. To
             ensure that the named container exists, use lxc.present.

          name   The name of the container

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          start  True Start container first, if necessary. If False,  then
                 this state will fail if the container is not running.

             web01:
               lxc.frozen

             web02:
               lxc.frozen:
                 - start: False

   salt.states.lxc.present(name,       running=None,      clone_from=None,
   snapshot=False,  profile=None,   network_profile=None,   template=None,
   options=None,    image=None,   config=None,   fstype=None,   size=None,
   backing=None, vgname=None, lvname=None, path=None)
          Changed in version 2015.8.0:  The  lxc.created  state  has  been
          renamed to lxc.present, and the lxc.cloned state has been merged
          into this state.

          Create the named container if it does not exist

          name   The name of the container to be created

          path   path  to  the  container  parent  default:   /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          running
                 False.INDENT 7.0

          * If True, ensure that the container is running

          * If False, ensure that the container is stopped

          * If  None,  do nothing with regards to the running state of the
            container

          New in version 2015.8.0.

   clone_from
          Create named container as a clone of the specified container

   snapshot
          False Use Copy On Write snapshots  (LVM).  Only  supported  with
          clone_from.

   profile
          Profile  to  use in container creation (see the LXC Tutorial for
          more information). Values in a profile will be overridden by the
          parameters listed below.

   network_profile
          Network  Profile  to  use  in  container  creation  (see the LXC
          Tutorial for more information). Values  in  a  profile  will  be
          overridden by the parameters listed below.

          New in version 2015.5.2.

   Container Creation Arguments

          template
                 The   template   to  use.  E.g.,  'ubuntu'  or  'fedora'.
                 Conflicts with the image argument.

                 NOTE:
                    The download template  requires  the  following  three
                    parameters to be defined in options:

                    * dist - The name of the distribution

                    * release - Release name/version

                    * arch - Architecture of the container

                    The   available   images   can  be  listed  using  the
                    lxc.images function.

          options
             New in version 2015.5.0.

             Template-specific options to pass to the lxc-create  command.
             These correspond to the long options (ones beginning with two
             dashes) that the template script accepts. For example:

                 web01:
                   lxc.present:
                     - template: download
                     - options:
                         dist: centos
                         release: 6
                         arch: amd64

             Remember to double-indent the  options,  due  to  how  PyYAML
             works.

          image  A  tar  archive  to  use as the rootfs for the container.
                 Conflicts with the template argument.

          backing
                 The type of storage to use. Set to  lvm  to  use  an  LVM
                 group.  Defaults to filesystem within /var/lib/lxc.

          fstype Filesystem type to use on LVM logical volume

          size   Size  of the volume to create. Only applicable if backing
                 is set to lvm.

          vgname lxc Name of the LVM volume group in which to  create  the
                 volume  for this container. Only applicable if backing is
                 set to lvm.

          lvname Name of the LVM logical volume in  which  to  create  the
                 volume  for this container. Only applicable if backing is
                 set to lvm.

   salt.states.lxc.running(name, restart=False, path=None)
          Changed in version 2015.5.0:  The  lxc.started  state  has  been
          renamed to lxc.running

          Ensure that a container is running

          NOTE:
             This  state  does  not  enforce  the  existence  of the named
             container, it just starts the container if it is not running.
             To ensure that the named container exists, use lxc.present.

          name   The name of the container

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          restart
                 False Restart container if it is already running

             web01:
               lxc.running

             web02:
               lxc.running:
                 - restart: True

   salt.states.lxc.set_pass(name, **kwargs)
          Deprecated since version 2015.5.0.

          This state function has been disabled, as it did not conform  to
          design   guidelines.   Specifically,   due   to  the  fact  that
          lxc.set_password uses chpasswd(8) to set the password, there was
          no  method  to  make this action idempotent (in other words, the
          password would be changed every time).  This  makes  this  state
          redundant, since the following state will do the same thing:

             setpass:
               module.run:
                 - name: set_pass
                 - m_name: root
                 - password: secret

   salt.states.lxc.stopped(name, kill=False, path=None)
          Ensure that a container is stopped

          NOTE:
             This  state  does  not  enforce  the  existence  of the named
             container, it just stops  the  container  if  it  running  or
             frozen.  To  ensure  that  the  named  container  exists, use
             lxc.present, or use the lxc.absent state to ensure  that  the
             container does not exist.

          name   The name of the container

          path   path   to  the  container  parent  default:  /var/lib/lxc
                 (system default)

                 New in version 2015.8.0.

          kill   False Do not wait for the container  to  stop,  kill  all
                 tasks  in  the  container.   Older LXC versions will stop
                 containers like this irrespective of this argument.

                 New in version 2015.5.0.

             web01:
               lxc.stopped

   salt.states.mac_assistive module
   Allows you to manage assistive access on OS X minions with 10.9+
   Install, enable and disable assitive access on OS X minions

      /usr/bin/osacript:
        assistive.installed:
          - enabled: True

   salt.states.mac_assistive.installed(name, enabled=True)
          Make sure that we have the given bundle ID or  path  to  command
          installed in the assistive access panel.

          name   The bundle ID or path to command

          enable Should assistive access be enabled on this application?

   salt.states.mac_defaults module
   Writing/reading defaults from an OS X minion
   salt.states.mac_defaults.absent(name, domain, user=None)
          Make sure the defaults value is absent

          name   The key of the given domain to remove

          domain The name of the domain to remove from

          user   The user to write the defaults to

   salt.states.mac_defaults.write(name,   domain,  value,  vtype='string',
   user=None)
          Write a default to the system

          name   The key of the given domain to write to

          domain The name of the domain to write to

          value  The value to write to the given key

          vtype  The type of value to be written, valid types are  string,
                 data,   int[eger],   float,   bool[ean],   date,   array,
                 array-add, dict, dict-add

          user   The user to write the defaults to

   salt.states.mac_keychain module
   Installing of certificates to the keychain
   Install certificats to the OS X keychain

      /mnt/test.p12:
        keychain.installed:
          - password: test123

   salt.states.mac_keychain.default_keychain(name,          domain='user',
   user=None)
          Set the default keychain to use

          name   The chain in which to use as the default

          domain The     domain     to     use     valid     values    are
                 user|system|common|dynamic, the default is user

          user   The user to run as

   salt.states.mac_keychain.installed(name,                      password,
   keychain='/Library/Keychains/System.keychain', **kwargs)
          Install a p12 certificate file into the OS X keychain

          name   The certificate to install

          password
                 The   password   for   the  certificate  being  installed
                 formatted in the way described for openssl command in the
                 PASS PHRASE ARGUMENTS section

          keychain
                 The keychain to install the certificate to, this defaults
                 to /Library/Keychains/System.keychain

          allow_any
                 Allow any application to access the imported  certificate
                 without warning

          keychain_password
                 If your keychain is likely to be locked pass the password
                 and it will be unlocked before running the import

   salt.states.mac_keychain.uninstalled(name,                    password,
   keychain='/Library/Keychains/System.keychain', keychain_password=None)
          Uninstall a p12 certificate file from the OS X keychain

          name   The  certificate  to  uninstall, this can be a path for a
                 .p12 or the friendly name

          password
                 The  password  for  the   certificate   being   installed
                 formatted in the way described for openssl command in the
                 PASS PHRASE ARGUMENTS section

          cert_name
                 The friendly name of the certificate, this  can  be  used
                 instead of giving a certificate

          keychain
                 The   keychain  to  remove  the  certificate  from,  this
                 defaults to /Library/Keychains/System.keychain

          keychain_password
                 If your keychain is likely to be locked pass the password
                 and it will be unlocked before running the import

   salt.states.mac_package module
   Installing of mac pkg files
   Install any kind of pkg, dmg or app file on Mac OS X:

      /mnt/test.pkg:
        macpackage.installed:
          - store: True

      /mnt/test.dmg:
        macpackage.installed:
          - dmg: True

      /mnt/xcode.dmg:
          macpackage.installed:
              - dmg: True
              - app: True
              - target: /Applications/Xcode.app
              - version_check: xcodebuild -version=Xcode 7.1

   .*7B91b

   salt.states.mac_package.installed(name,           target='LocalSystem',
   dmg=False, store=False, app=False, mpkg=False, user=None,  onlyif=None,
   unless=None, force=False, allow_untrusted=False, version_check=None)
          Install  a Mac OS Package from a pkg or dmg file, if given a dmg
          file it will first be mounted in a temporary location

          name   The pkg or dmg file to install

          target The location in which to install the package. This can be
                 a path or LocalSystem

          dmg    Is the given file a dmg file?

          store  Should  the pkg be installed as if it was from the Mac OS
                 Store?

          app    Is the file a .app? If so then we'll just  copy  that  to
                 /Applications/ or the given target

          mpkg   Is  the  file  a .mpkg? If so then we'll check all of the
                 .pkg files found are installed

          user   Name of the user performing the unless or onlyif checks

          onlyif A command to run as a check, run the named  command  only
                 if the command passed to the onlyif option returns true

          unless A  command  to run as a check, only run the named command
                 if the command passed to the unless option returns false

          force  Force the package to be installed  even  if  its  already
                 been found installed

          allow_untrusted
                 Allow the installation of untrusted packages

          version_check
                 The  command  and  version that we want to check against,
                 the version number can use regex.

   salt.states.mac_xattr module
   Allows you to manage extended attributes on files or directories
   Install, enable and disable assitive access on OS X minions

      /path/to/file:
        xattr.exists:
          - attributes:
              - com.file.attr=test
              - com.apple.quarantine=0x00001111

   salt.states.mac_xattr.delete(name, attributes)
          Make  sure  the  given   attributes   are   deleted   from   the
          file/directory

          name   The path to the file/directory

          attributes
                 The   attributes   that   should   be  removed  from  the
                 file/directory, this is accepted as an array.

   salt.states.mac_xattr.exists(name, attributes)
          Make sure the given attributes exist on the file/directory

          name   The path to the file/directory

          attributes
                 The attributes that should exist on  the  file/directory,
                 this  is  accepted  as an array, with key and value split
                 with an equals sign, if you want to specify a  hex  value
                 then add 0x to the beginning of the value.

   salt.states.makeconf
   Management of Gentoo make.conf
   A state module to manage Gentoo's make.conf file

      makeopts:
        makeconf.present:
          - value: '-j3'

   salt.states.makeconf.absent(name)
          Verify that the variable is not in the make.conf.

          name   The  variable  name. This will automatically be converted
                 to upper case since variables in make.conf are  in  upper
                 case

   salt.states.makeconf.present(name,      value=None,      contains=None,
   excludes=None)
          Verify that the  variable  is  in  the  make.conf  and  has  the
          provided  settings.  If value is set, contains and excludes will
          be ignored.

          name   The variable name. This will automatically  be  converted
                 to  upper  case since variables in make.conf are in upper
                 case

          value  Enforce that the value of the  variable  is  set  to  the
                 provided value

          contains
                 Enforce  that  the  value  of  the  variable contains the
                 provided value

          excludes
                 Enforce that the value of the variable does  not  contain
                 the provided value.

   salt.states.marathon_app module
   Configure Marathon apps via a salt proxy.

      my_app:
        marathon_app.config:
          - config:
              cmd: "while [ true ] ; do echo 'Hello Marathon' ; sleep 5 ; done"
              cpus: 0.1
              mem: 10
              instances: 3

   New in version 2015.8.2.

   salt.states.marathon_app.absent(name)
          Ensure that the marathon app with the given id is not present.

          Parameters
                 name -- The app name/id

          Returns
                 A standard Salt changes dictionary

   salt.states.marathon_app.config(name, config)
          Ensure that the marathon app with the given id is present and is
          configured to match the given config values.

          Parameters

                 * name -- The app name/id

                 * config -- The configuration to apply (dict)

          Returns
                 A standard Salt changes dictionary

   salt.states.marathon_app.running(name, restart=False, force=True)
          Ensure that the marathon app with the given id  is  present  and
          restart if set.

          Parameters

                 * name -- The app name/id

                 * restart -- Restart the app

                 * force -- Override the current deployment

          Returns
                 A standard Salt changes dictionary

   salt.states.mdadm
   Managing software RAID with mdadm
   A state module for creating or destroying software RAID devices.

      /dev/md0:
        raid.present:
          - level: 5
          - devices:
            - /dev/xvdd
            - /dev/xvde
            - /dev/xvdf
          - chunk: 256
          - run: True

   salt.states.mdadm.absent(name)
          Verify that the raid is absent

          name   The name of raid device to be destroyed

             /dev/md0:
               raid:
                 - absent

   salt.states.mdadm.present(name, level, devices, **kwargs)
          Verify that the raid is present

          Changed in version 2014.7.0.

          name   The name of raid device to be created

          level  The RAID level to use when creating the raid.

          devices
                 A list of devices used to build the array.

          kwargs Optional arguments to be passed to mdadm.

          Example:

             /dev/md0:
               raid.present:
                 - level: 5
                 - devices:
                   - /dev/xvdd
                   - /dev/xvde
                   - /dev/xvdf
                 - chunk: 256
                 - run: True

   salt.states.memcached
   States for Management of Memcached Keys
   New in version 2014.1.0.

   salt.states.memcached.absent(name,     value=None,    host='127.0.0.1',
   port=11211, time=0)
          Ensure that a memcached key is not present.

          name   The key

          value  None If specified, only ensure that the key is absent  if
                 it matches the specified value.

          host   The memcached server IP address

          port   The memcached server port

             foo:
               memcached.absent

             bar:
               memcached.absent:
                 - host: 10.0.0.1

   salt.states.memcached.managed(name,    value=None,    host='127.0.0.1',
   port=11211, time=0, min_compress_len=0)
          Manage a memcached key.

          name   The key to manage

          value  The value to set for that key

          host   The memcached server IP address

          port   The memcached server port

             foo:
               memcached.managed:
                 - value: bar

   salt.states.modjk
   State to control Apache modjk

   salt.states.modjk.worker_activated(name,                  workers=None,
   profile='default')
          Activate all the workers in the modjk load balancer

          Example:

             loadbalancer:
               modjk.worker_activated:
                 - workers:
                   - app1
                   - app2

   salt.states.modjk.worker_disabled(name,                   workers=None,
   profile='default')
          Disable all the workers in the modjk load balancer

          Example:

             loadbalancer:
               modjk.worker_disabled:
                 - workers:
                   - app1
                   - app2

   salt.states.modjk.worker_recover(name, workers=None, profile='default')
          Recover all the workers in the modjk load balancer

          Example:

             loadbalancer:
               modjk.worker_recover:
                 - workers:
                   - app1
                   - app2

   salt.states.modjk.worker_stopped(name, workers=None, profile='default')
          Stop all the workers in the modjk load balancer

          Example:

             loadbalancer:
               modjk.worker_stopped:
                 - workers:
                   - app1
                   - app2

   salt.states.modjk_worker
   Manage modjk workers
   Send commands to a modjk load balancer via the peer system.

   This module can be used with the prereq  requisite  to  remove/add  the
   worker from the load balancer before deploying/restarting service.

   Mandatory Settings:

   * The minion needs to have permission to publish the modjk.*  functions
     (see here for information on configuring peer publishing permissions)

   * The modjk load balancer must be configured as  stated  in  the  modjk
     execution module documentation

   salt.states.modjk_worker.activate(name, lbn, target, profile='default',
   expr_form='glob')
          Activate the named worker from the lbn  load  balancers  at  the
          targeted minions

          Example:

             disable-before-deploy:
               modjk_worker.activate:
                 - name: {{ grains['id'] }}
                 - lbn: application
                 - target: 'roles:balancer'
                 - expr_form: grain

   salt.states.modjk_worker.disable(name,  lbn, target, profile='default',
   expr_form='glob')
          Disable the named worker from the  lbn  load  balancers  at  the
          targeted  minions.  The worker will get traffic only for current
          sessions and won't get new ones.

          Example:

             disable-before-deploy:
               modjk_worker.disable:
                 - name: {{ grains['id'] }}
                 - lbn: application
                 - target: 'roles:balancer'
                 - expr_form: grain

   salt.states.modjk_worker.stop(name,  lbn,  target,   profile='default',
   expr_form='glob')
          Stop  the  named  worker  from  the  lbn  load  balancers at the
          targeted minions The worker won't get any traffic from the lbn

          Example:

             disable-before-deploy:
               modjk_worker.stop:
                 - name: {{ grains['id'] }}
                 - lbn: application
                 - target: 'roles:balancer'
                 - expr_form: grain

   salt.states.module
   Execution of Salt modules from within states
   These states allow individual execution module calls  to  be  made  via
   states. To call a single module function use a module.run state:

      mine.send:
        module.run:
          - name: network.interfaces

   Note  that  this  example  is  probably unnecessary to use in practice,
   since the mine_functions and mine_interval  config  parameters  can  be
   used to schedule updates for the mine (see here for more info).

   It  is  sometimes desirable to trigger a function call after a state is
   executed, for this the module.wait state can be used:

      mine.send:
        module.wait:
          - name: network.interfaces
          - watch:
            - file: /etc/network/interfaces

   All arguments that the module state does not consume are passed through
   to the execution module function being executed:

      fetch_out_of_band:
        module.run:
          - name: git.fetch
          - cwd: /path/to/my/repo
          - user: myuser
          - opts: '--all'

   Due  to  how  the  state  system works, if a module function accepts an
   argument called, name,  then  m_name  must  be  used  to  specify  that
   argument, to avoid a collision with the name argument.

   Here  is  a  list of keywords hidden by the state system, which must be
   prefixed with m_:

   * fun

   * name

   * names

   * state

   * saltenv

   For example:

      disable_nfs:
        module.run:
          - name: service.disable
          - m_name: nfs

   Note that some modules read all or some of the arguments from a list of
   keyword arguments. For example:

      mine.send:
        module.run:
          - func: network.ip_addrs
          - kwargs:
              interface: eth0

      cloud.create:
        module.run:
          - func: cloud.create
          - provider: test-provider
          - m_names:
            - test-vlad
          - kwargs: {
                ssh_username: 'ubuntu',
                image: 'ami-8d6d9daa',
                securitygroup: 'default',
                size: 'c3.large',
                location: 'ap-northeast-1',
                delvol_on_destroy: 'True'
            }

   salt.states.module.mod_watch(name, **kwargs)
          This function is an alias of run.
             Run a single module function

             name   The module function to execute

             returner
                    Specify  the returner to send the return of the module
                    execution to

             kwargs Pass any arguments needed to execute the function

   salt.states.module.run(name, **kwargs)
          Run a single module function

          name   The module function to execute

          returner
                 Specify the returner to send the  return  of  the  module
                 execution to

          kwargs Pass any arguments needed to execute the function

   salt.states.module.wait(name, **kwargs)
          Run  a  single module function only if the watch statement calls
          it

          name   The module function to execute

          **kwargs
                 Pass any arguments needed to execute the function

          NOTE:
             Like the cmd.run state, this state will return True  but  not
             actually  execute,  unless  one  of  the following two things
             happens:

             1. The state has a watch requisite, and the state which it is
                watching changes.

             2. Another  state  has  a watch_in requisite which references
                this state, and the state wth the watch_in changes.

   salt.states.mongodb_database
   Management of Mongodb databases

   Only deletion is supported, creation doesn't make sense and can be done
   using mongodb_user.present

   salt.states.mongodb_database.absent(name,   user=None,   password=None,
   host=None, port=None, authdb=None)
          Ensure that the named database is absent

          name   The name of the database to remove

          user   The user to connect as (must be able to create the user)

          password
                 The password of the user

          host   The host to connect to

          port   The port to connect to

          authdb The database in which to authenticate

   salt.states.mongodb_user
   Management of Mongodb users
   NOTE:
      This module requires PyMongo to be installed.

   salt.states.mongodb_user.absent(name,     user=None,     password=None,
   host=None, port=None, database='admin', authdb=None)
          Ensure that the named user is absent

          name   The name of the user to remove

          user   MongoDB user with sufficient privilege to create the user

          password
                 Password  for  the  admin  user  specified  by  the  user
                 parameter

          host   The hostname/IP address of the MongoDB server

          port   The port on which MongoDB is listening

          database
                 The database from which to remove the user  specified  by
                 the name parameter

          authdb The database in which to authenticate

   salt.states.mongodb_user.present(name,     passwd,    database='admin',
   user=None, password=None, host='localhost', port=27017, authdb=None)
          Ensure that the user is present with the specified properties

          name   The name of the user to manage

          passwd The password of the user to manage

          user   MongoDB user with sufficient privilege to create the user

          password
                 Password for the  admin  user  specified  with  the  user
                 parameter

          host   The hostname/IP address of the MongoDB server

          port   The port on which MongoDB is listening

          database
                 The database in which to create the user

                 NOTE:
                    If the database doesn't exist, it will be created.

          authdb The database in which to authenticate

          Example:

             mongouser-myapp:
               mongodb_user.present:
               - name: myapp
               - passwd: password-of-myapp
               # Connect as admin:sekrit
               - user: admin
               - password: sekrit

   salt.states.monit
   Monit state
   Manage monit states

   monit_enable_service_monitoring:

          monit.monitor:

                 * name: service

   monit_disable_service_monitoring:

          monit.unmonitor:

                 * name: service

   NOTE:
      Use  of  these  states  require  that  the monit execution module is
      available.

   salt.states.monit.monitor(name)
          Get the summary from module monit and try to see if  service  is
          being monitored. If not then monitor the service.

   salt.states.monit.unmonitor(name)
          Get  the  summary from module monit and try to see if service is
          being monitored. If it is then stop monitoring the service.

   salt.states.mount
   Mounting of filesystems
   Mount any type of mountable filesystem with the mounted function:

      /mnt/sdb:
        mount.mounted:
          - device: /dev/sdb1
          - fstype: ext4
          - mkmnt: True
          - opts:
            - defaults

      /srv/bigdata:
        mount.mounted:
          - device: UUID=066e0200-2867-4ebe-b9e6-f30026ca2314
          - fstype: xfs
          - opts: nobootwait,noatime,nodiratime,nobarrier,logbufs=8
          - dump: 0
          - pass_num: 2
          - persist: True
          - mkmnt: True

   salt.states.mount.mod_watch(name, user=None, **kwargs)
          The mounted watcher, called to invoke the watch command.

          name   The name of the mount point

   salt.states.mount.mounted(name,    device,     fstype,     mkmnt=False,
   opts='defaults', dump=0, pass_num=0, config='/etc/fstab', persist=True,
   mount=True,   user=None,    match_on='auto',    device_name_regex=None,
   extra_mount_invisible_options=None,    extra_mount_invisible_keys=None,
   extra_mount_ignore_fs_keys=None,    extra_mount_translate_options=None,
   hidden_opts=None)
          Verify that a device is mounted

          name   The  path  to  the  location  where  the  device is to be
                 mounted

          device The device name,  typically  the  device  node,  such  as
                 /dev/sdb1 or UUID=066e0200-2867-4ebe-b9e6-f30026ca2314 or
                 LABEL=DATA

          fstype The filesystem type, this will be xfs,  ext2/3/4  in  the
                 case of classic filesystems, and fuse in the case of fuse
                 mounts

          mkmnt  If the mount point is not present  then  the  state  will
                 fail,  set mkmnt: True to create the mount point if it is
                 otherwise not present

          opts   A list object of options or a comma delimited list

          dump   The dump value to be passed into the fstab, Default is 0

          pass_num
                 The pass value to be passed into the fstab, Default is 0

          config Set an alternative location for  the  fstab,  Default  is
                 /etc/fstab

          persist
                 Set if the mount should be saved in the fstab, Default is
                 True

          mount  Set if the mount should be mounted  immediately,  Default
                 is True

          user   The user to own the mount; this defaults to the user salt
                 is running as on the minion

          match_on
                 A name or list of fstab properties on  which  this  state
                 should  be  applied.   Default  is  auto, a special value
                 indicating to guess based on fstype.   In  general,  auto
                 matches on name for recognized special devices and device
                 otherwise.

          device_name_regex
                 A list of device exact names or regular expressions which
                 should not force a remount. For example, glusterfs may be
                 mounted with a comma-separated list of servers in  fstab,
                 but  the  /proc/self/mountinfo  will  show only the first
                 available server.

                    {% set glusterfs_ip_list = ['10.0.0.1', '10.0.0.2', '10.0.0.3'] %}

                    mount glusterfs volume:
                      mount.mounted:
                        - name: /mnt/glusterfs_mount_point
                        - device: {{ glusterfs_ip_list|join(',') }}:/volume_name
                        - fstype: glusterfs
                        - opts: _netdev,rw,defaults,direct-io-mode=disable
                        - mkmnt: True
                        - persist: True
                        - dump: 0
                        - pass_num: 0
                        - device_name_regex:
                          - ({{ glusterfs_ip_list|join('|') }}):/volume_name

                 New in version 2016.11.0.

          extra_mount_invisible_options
                 A list of extra options that are not visible through  the
                 /proc/self/mountinfo interface.

                 If a option is not visible through this interface it will
                 always  remount  the  device.  This  option  extends  the
                 builtin mount_invisible_options list.

          extra_mount_invisible_keys
                 A  list of extra key options that are not visible through
                 the /proc/self/mountinfo interface.

                 If a key option is not visible through this interface  it
                 will  always  remount the device. This option extends the
                 builtin mount_invisible_keys list.

                 A good example for a key option is the password option:

                    password=badsecret

          extra_ignore_fs_keys
                 A dict of filesystem options which  should  not  force  a
                 remount.  This  will  update the internal dictionary. The
                 dict should look like this:

                    {
                        'ramfs': ['size']
                    }

          extra_mount_translate_options
                 A  dict  of  mount  options  that  gets  translated  when
                 mounted.  To  prevent a remount add additional options to
                 the default dictionary. This  will  update  the  internal
                 dictionary. The dictionary should look like this:

                    {
                        'tcp': 'proto=tcp',
                        'udp': 'proto=udp'
                    }

          hidden_opts
                 A  list  of  mount  options  that  will  be  ignored when
                 considering a remount as part of the state application

                 New in version 2015.8.2.

   salt.states.mount.swap(name, persist=True, config='/etc/fstab')
          Activates a swap device

             /root/swapfile:
               mount.swap

          NOTE:
             swap does not currently support LABEL

   salt.states.mount.unmounted(name,   device=None,   config='/etc/fstab',
   persist=False, user=None)
          New in version 0.17.0.

          Verify that a device is not mounted

          name   The  path  to  the  location  where  the  device is to be
                 unmounted from

          device The device to be unmounted.  This is optional because the
                 device could be mounted in multiple places.

                 New in version 2015.5.0.

          config Set  an  alternative  location  for the fstab, Default is
                 /etc/fstab

          persist
                 Set if the mount should be purged from the fstab, Default
                 is False

          user   The user to own the mount; this defaults to the user salt
                 is running as on the minion

   salt.states.mysql_database
   Management of MySQL databases (schemas)
   depends

          * MySQLdb Python module

   configuration
          See salt.modules.mysql for setup instructions.

   The mysql_database module is used to create and manage MySQL databases.
   Databases can be set as either absent or present.

      frank:
        mysql_database.present

   salt.states.mysql_database.absent(name, **connection_args)
          Ensure that the named database is absent

          name   The name of the database to remove

   salt.states.mysql_database.present(name,            character_set=None,
   collate=None, **connection_args)
          Ensure that the named database is  present  with  the  specified
          properties

          name   The name of the database to manage

   salt.states.mysql_grants
   Management of MySQL grants (user permissions)
   depends

          * MySQLdb Python module

   configuration
          See salt.modules.mysql for setup instructions.

   The mysql_grants module is used to grant and revoke MySQL permissions.

   The  name  you pass in purely symbolic and does not have anything to do
   with the grant itself.

   The database parameter needs to specify  a  'priv_level'  in  the  same
   specification as defined in the MySQL documentation:

   * *

   * *.*

   * db_name.*

   * db_name.tbl_name

   * etc...

   This  state  is  not  able  to set password for the permission from the
   specified host. See salt.states.mysql_user for further instructions.

      frank_exampledb:
         mysql_grants.present:
          - grant: select,insert,update
          - database: exampledb.*
          - user: frank
          - host: localhost

      frank_otherdb:
        mysql_grants.present:
          - grant: all privileges
          - database: otherdb.*
          - user: frank

      restricted_singletable:
        mysql_grants.present:
          - grant: select
          - database: somedb.sometable
          - user: joe

   salt.states.mysql_grants.absent(name,    grant=None,     database=None,
   user=None,     host='localhost',    grant_option=False,    escape=True,
   **connection_args)
          Ensure that the grant is absent

          name   The name (key) of the grant to add

          grant  The grant priv_type  (i.e.  select,insert,update  OR  all
                 privileges)

          database
                 The database priv_level (i.e. db.tbl OR db.*)

          user   The user to apply the grant to

          host   The network/host that the grant should apply to

   salt.states.mysql_grants.present(name,    grant=None,    database=None,
   user=None,    host='localhost',    grant_option=False,     escape=True,
   revoke_first=False, ssl_option=False, **connection_args)
          Ensure that the grant is present with the specified properties

          name   The name (key) of the grant to add

          grant  The  grant  priv_type  (i.e.  select,insert,update OR all
                 privileges)

          database
                 The database priv_level (i.e. db.tbl OR db.*)

          user   The user to apply the grant to

          host   The network/host that the grant should apply to

          grant_option
                 Adds the WITH GRANT OPTION to the defined grant.  Default
                 is False

          escape Defines  if  the  database  value  gets  escaped  or not.
                 Default is True

          revoke_first
                 By default, MySQL will not do anything  if  you  issue  a
                 command  to  grant  privileges  that are more restrictive
                 than what's already in place. This effectively means that
                 you  cannot  downgrade permissions without first revoking
                 permissions applied to a db.table/user pair first.

                 To have Salt forcibly revoke perms before applying a  new
                 grant, enable the 'revoke_first options.

                 WARNING:  This  will  remove  permissions  for a database
                 before attempting to apply new permissions. There  is  no
                 guarantee  that new permissions will be applied correctly
                 which can leave your database security in an unknown  and
                 potentially dangerous state.  Use with caution!

                 Default is False

          ssl_option
                 Adds the specified ssl options for the connecting user as
                 requirements  for  this  grant.  Value  is  a   list   of
                 single-element  dicts  corresponding  to  the list of ssl
                 options to use.

                 Possible key/value pairings for the dicts in the value:

                    - SSL: True
                    - X509: True
                    - SUBJECT: <subject>
                    - ISSUER: <issuer>
                    - CIPHER: <cipher>

                 The non-boolean  ssl  options  take  a  string  as  their
                 values, which should be an appropriate value as specified
                 by the MySQL documentation for these options.

                 Default is False (no ssl options will be used)

   salt.states.mysql_query
   Execution of MySQL queries
   New in version 2014.7.0.

   depends

          * MySQLdb Python module

   configuration
          See salt.modules.mysql for setup instructions.

   The mysql_query module is used to execute queries on  MySQL  databases.
   Its output may be stored in a file or in a grain.

      query_id:
        mysql_query.run
          - database: my_database
          - query:    "SELECT * FROM table;"
          - output:   "/tmp/query_id.txt"

   salt.states.mysql_query.run(name,    database,    query,   output=None,
   grain=None, key=None, overwrite=True, **connection_args)
          Execute an arbitrary query on the specified database

          name   Used only as an ID

          database
                 The name of the database to execute the query on

          query  The query to execute

          output grain: output in a grain other: the file to store results
                 None:  output to the result comment (default)

          grain: grain to store the output (need output=grain)

          key:   the  specified grain will be treated as a dictionary, the
                 result of this state will be stored under  the  specified
                 key.

          overwrite:
                 The  file  or  grain  will  be  overwritten if it already
                 exists (default)

   salt.states.mysql_user
   Management of MySQL users
   depends

          * MySQLdb Python module

   configuration
          See salt.modules.mysql for setup instructions.

      frank:
        mysql_user.present:
          - host: localhost
          - password: bobcat

   New in version 0.16.2: Authentication overrides have been added.

   The MySQL authentication information specified  in  the  minion  config
   file  can  be  overridden  in  states  using  the  following arguments:
   connection_host,  connection_port,  connection_user,   connection_pass,
   connection_db,   connection_unix_socket,   connection_default_file  and
   connection_charset.

      frank:
        mysql_user.present:
          - host: localhost
          - password: "bob@cat"
          - connection_user: someuser
          - connection_pass: somepass
          - connection_charset: utf8
          - saltenv:
            - LC_ALL: "en_US.utf8"

   This state  is  not  able  to  grant  permissions  for  the  user.  See
   salt.states.mysql_grants for further instructions.

   salt.states.mysql_user.absent(name,                   host='localhost',
   **connection_args)
          Ensure that the named user is absent

          name   The name of the user to remove

   salt.states.mysql_user.present(name,  host='localhost',  password=None,
   password_hash=None,     allow_passwordless=False,    unix_socket=False,
   password_column=None, **connection_args)
          Ensure that  the  named  user  is  present  with  the  specified
          properties.  A  passwordless  user can be configured by omitting
          password and password_hash, and  setting  allow_passwordless  to
          True.

          name   The name of the user to manage

          host   Host for which this user/password combo applies

          password
                 The  password  to use for this user. Will take precedence
                 over the password_hash option if both are specified.

          password_hash
                 The password  in  hashed  form.  Be  sure  to  quote  the
                 password because YAML doesn't like the *. A password hash
                 can be obtained from the mysql command-line  client  like
                 so:

                    mysql> SELECT PASSWORD('mypass');
                    +-------------------------------------------+
                    | PASSWORD('mypass')                        |
                    +-------------------------------------------+
                    | *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
                    +-------------------------------------------+
                    1 row in set (0.00 sec)

          allow_passwordless
                 If  True,  then password and password_hash can be omitted
                 to permit a passwordless login.

                 New in version 0.16.2.

          unix_socket
                 If True and allow_passwordless is True,  the  unix_socket
                 auth plugin will be used.

   salt.states.netntp
   Network NTP
   Manage  the  configuration  of  NTP  peers  and  servers on the network
   devices through the NAPALM proxy.

   codeauthor
          Mircea  Ulinic  <[email protected]>  &  Jerome   Fleury   <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * Requires  netaddr to be installed: pip install netaddr to check if IP
     Addresses are correctly specified

   * Requires dnspython to be installed: pip install dnspython to  resolve
     the nameserver entities

   (in  case  the user does not configure the peers/servers using their IP
   addresses) - NAPALM proxy minion - NTP  operational  and  configuration
   management module

   salt.states.netntp.managed(name, peers=None, servers=None)
          Manages  the  configuration  of  NTP  peers  and  servers on the
          device, as specified in the state SLS file.   NTP  entities  not
          specified  in  these  lists  will be removed whilst entities not
          configured on the device will be set.

          SLS Example:

             netntp_example:
                 netntp.managed:
                      - peers:
                         - 192.168.0.1
                         - 172.17.17.1
                      - servers:
                         - 24.124.0.251
                         - 138.236.128.36

          Output example:

             {
                 'edge01.nrt04': {
                     'netntp_|-netntp_example_|-netntp_example_|-managed': {
                         'comment': 'NTP servers already configured as needed.',
                         'name': 'netntp_example',
                         'start_time': '12:45:24.056659',
                         'duration': 2938.857,
                         'changes': {
                             'peers': {
                                 'removed': [
                                     '192.168.0.2',
                                     '192.168.0.3'
                                 ],
                                 'added': [
                                     '192.168.0.1',
                                     '172.17.17.1'
                                 ]
                             }
                         },
                         'result': None
                     }
                 }
             }

   salt.states.network
   Configuration of network interfaces
   The network module is used  to  create  and  manage  network  settings,
   interfaces  can  be  set  as  either managed or ignored. By default all
   interfaces are ignored unless specified.

   NOTE:
      Prior to version 2014.1.0, only RedHat-based systems (RHEL,  CentOS,
      Scientific  Linux, etc.) are supported. Support for Debian/Ubuntu is
      new in 2014.1.0 and should be considered experimental.

      Other platforms are not yet supported.

      system:
        network.system:
          - enabled: True
          - hostname: server1.example.com
          - gateway: 192.168.0.1
          - gatewaydev: eth0
          - nozeroconf: True
          - nisdomain: example.com
          - require_reboot: True

      eth0:
        network.managed:
          - enabled: True
          - type: eth
          - proto: none
          - ipaddr: 10.1.0.1
          - netmask: 255.255.255.0
          - dns:
            - 8.8.8.8
            - 8.8.4.4

      eth0-range0:
        network.managed:
          - type: eth
          - ipaddr_start: 192.168.1.1
          - ipaddr_end: 192.168.1.10
          - clonenum_start: 10
          - mtu: 9000

      bond0-range0:
        network.managed:
          - type: eth
          - ipaddr_start: 192.168.1.1
          - ipaddr_end: 192.168.1.10
          - clonenum_start: 10
          - mtu: 9000

      eth1.0-range0:
        network.managed:
          - type: eth
          - ipaddr_start: 192.168.1.1
          - ipaddr_end: 192.168.1.10
          - clonenum_start: 10
          - vlan: True
          - mtu: 9000

      bond0.1-range0:
        network.managed:
          - type: eth
          - ipaddr_start: 192.168.1.1
          - ipaddr_end: 192.168.1.10
          - clonenum_start: 10
          - vlan: True
          - mtu: 9000

      .. note::
          add support of ranged interfaces (vlan, bond and eth) for redhat system,
          Important:type must be eth.

      routes:
        network.routes:
          - name: eth0
          - routes:
            - name: secure_network
              ipaddr: 10.2.0.0
              netmask: 255.255.255.0
              gateway: 10.1.0.3
            - name: HQ_network
              ipaddr: 10.100.0.0
              netmask: 255.255.0.0
              gateway: 10.1.0.10

      eth2:
        network.managed:
          - enabled: True
          - type: slave
          - master: bond0

      eth3:
        network.managed:
          - enabled: True
          - type: slave
          - master: bond0

      eth4:
        network.managed:
          - enabled: True
          - type: eth
          - proto: dhcp
          - bridge: br0

      eth5:
        network.managed:
          - enabled: True
          - type: eth
          - proto: dhcp
          - noifupdown: True  # Do not restart the interface
                              # you need to reboot/reconfigure manualy

      bond0:
        network.managed:
          - type: bond
          - ipaddr: 10.1.0.1
          - netmask: 255.255.255.0
          - mode: active-backup
          - proto: static
          - dns:
            - 8.8.8.8
            - 8.8.4.4
          - ipv6:
          - enabled: False
          - slaves: eth2 eth3
          - require:
            - network: eth2
            - network: eth3
          - miimon: 100
          - arp_interval: 250
          - downdelay: 200
          - lacp_rate: fast
          - max_bonds: 1
          - updelay: 0
          - use_carrier: on
          - xmit_hash_policy: layer2
          - mtu: 9000
          - autoneg: on
          - speed: 1000
          - duplex: full
          - rx: on
          - tx: off
          - sg: on
          - tso: off
          - ufo: off
          - gso: off
          - gro: off
          - lro: off

      bond0.2:
        network.managed:
          - type: vlan
          - ipaddr: 10.1.0.2
          - use:
            - network: bond0
          - require:
            - network: bond0

      bond0.3:
        network.managed:
          - type: vlan
          - ipaddr: 10.1.0.3
          - use:
            - network: bond0
          - require:
            - network: bond0

      bond0.10:
        network.managed:
          - type: vlan
          - ipaddr: 10.1.0.4
          - use:
            - network: bond0
          - require:
            - network: bond0

      bond0.12:
        network.managed:
          - type: vlan
          - ipaddr: 10.1.0.5
          - use:
            - network: bond0
          - require:
            - network: bond0
      br0:
        network.managed:
          - enabled: True
          - type: bridge
          - proto: dhcp
          - bridge: br0
          - delay: 0
          - ports: eth4
          - bypassfirewall: True
          - use:
            - network: eth4
          - require:
            - network: eth4

      system:
        network.system:
          - enabled: True
          - hostname: server1.example.com
          - gateway: 192.168.0.1
          - gatewaydev: eth0
          - nozeroconf: True
          - nisdomain: example.com
          - require_reboot: True
          - apply_hostname: True

      lo:
        network.managed:
          - name: lo
          - type: eth
          - onboot: yes
          - userctl: no
          - ipv6_autoconf: no
          - enable_ipv6: true
          - ipaddrs:
            - 127.0.0.1/8
            - 10.1.0.4/32
            - 10.1.0.12/32
          - ipv6addrs:
            - fc00::1/128
            - fc00::100/128

      .. note::
          Apply changes to hostname immediately.

      .. versionadded:: 2015.5.0

      system:
        network.system:
          - hostname: server2.example.com
          - apply_hostname: True
          - retain_settings: True

      .. note::
          Use `retain_settings` to retain current network settings that are not
          otherwise specified in the state. Particularly useful if only setting
          the hostname. Default behavior is to delete unspecified network
          settings.

      .. versionadded:: 2016.11.0

   NOTE:
      When managing bridged interfaces on a Debian or Ubuntu based system,
      the  ports  argument  is  required.  Red Hat systems will ignore the
      argument.

   salt.states.network.managed(name, type, enabled=True, **kwargs)
          Ensure that the named interface is configured properly.

          name   The name of the interface to manage

          type   Type of interface and configuration.

          enabled
                 Designates the state of this interface.

          kwargs The IP parameters for this interface.

   salt.states.network.routes(name, **kwargs)
          Manage network interface static routes.

          name   Interface name to apply the route to.

          kwargs Named routes

   salt.states.network.system(name, **kwargs)
          Ensure that global network settings are configured properly.

          name   Custom name to represent this configuration change.

          kwargs The global parameters for the system.

   salt.states.nftables
   Management of nftables
   This is an nftables-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.

      httpd:
        nftables.append:
          - table: filter
          - chain: input
          - jump: accept
          - match: state
          - connstate: new
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.append:
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.insert:
          - position: 1
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.insert:
          - position: 1
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.delete:
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.delete:
          - position: 1
          - table: filter
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

      httpd:
        nftables.delete:
          - table: filter
          - family: ipv6
          - chain: INPUT
          - jump: ACCEPT
          - match: state
          - connstate: NEW
          - dport: 80
          - proto: tcp
          - sport: 1025:65535
          - save: True

   salt.states.nftables.append(name, family='ipv4', **kwargs)
          New in version 0.17.0.

          Append a rule to a chain

          name   A  user-defined name to call this rule by in another part
                 of a state or formula. This should not be an actual rule.

          family Network family, ipv4 or ipv6.

          All other arguments are passed in with the same name as the long
          option  that  would  normally  be  used  for  nftables, with one
          exception: --state is specified as connstate  instead  of  state
          (not to be confused with ctstate).

   salt.states.nftables.chain_absent(name, table='filter', family='ipv4')
          New in version 2014.7.0.

          Verify the chain is absent.

          family Networking family, either ipv4 or ipv6

   salt.states.nftables.chain_present(name,                table='filter',
   table_type=None, hook=None, priority=None, family='ipv4')
          New in version 2014.7.0.

          Verify the chain is exist.

          name   A user-defined chain name.

          table  The table to own the chain.

          family Networking family, either ipv4 or ipv6

   salt.states.nftables.delete(name, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Delete a rule to a chain

          name   A user-defined name to call this rule by in another  part
                 of a state or formula. This should not be an actual rule.

          family Networking family, either ipv4 or ipv6

          All other arguments are passed in with the same name as the long
          option that would  normally  be  used  for  nftables,  with  one
          exception:  --state  is  specified as connstate instead of state
          (not to be confused with ctstate).

   salt.states.nftables.flush(name, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Flush current nftables state

          family Networking family, either ipv4 or ipv6

   salt.states.nftables.insert(name, family='ipv4', **kwargs)
          New in version 2014.7.0.

          Insert a rule into a chain

          name   A user-defined name to call this rule by in another  part
                 of a state or formula. This should not be an actual rule.

          family Networking family, either ipv4 or ipv6

          All other arguments are passed in with the same name as the long
          option that would  normally  be  used  for  nftables,  with  one
          exception:  --state  is  specified as connstate instead of state
          (not to be confused with ctstate).

   salt.states.npm
   Installation of NPM Packages
   These states manage the installed packages for node.js using  the  Node
   Package Manager (npm). Note that npm must be installed for these states
   to be available,  so  npm  states  should  include  a  requisite  to  a
   pkg.installed  state  for the package which provides npm (simply npm in
   most cases). Example:

      npm:
        pkg.installed

      yaml:
        npm.installed:
          - require:
            - pkg: npm

   salt.states.npm.bootstrap(name, user=None, silent=True)
          Bootstraps a node.js application.

          Will execute 'npm install --json' on the specified directory.

          user   The user to run NPM with

                 New in version 0.17.0.

   salt.states.npm.cache_cleaned(name=None, user=None)
          Ensure that the given package is not cached.

          If no package is specified, this ensures  the  entire  cache  is
          cleared.

          name   The name of the package to remove from the cache, or None
                 for all packages

          user   The user to run NPM with

   salt.states.npm.installed(name,   pkgs=None,    dir=None,    user=None,
   force_reinstall=False, registry=None, env=None)
          Verify that the given package is installed and is at the correct
          version (if specified).

             coffee-script:
               npm.installed:
                 - user: someuser

             [email protected]:
               npm.installed: []

          name   The package to install

                 Changed in version 2014.7.2: This parameter is no  longer
                 lowercased  by  salt  so  that case-sensitive NPM package
                 names will work.

          pkgs   A  list  of  packages  to  install  with  a  single   npm
                 invocation; specifying this argument will ignore the name
                 argument

                 New in version 2014.7.0.

          dir    The target directory in which to install the package,  or
                 None for global installation

          user   The user to run NPM with

                 New in version 0.17.0.

          registry
                 The NPM registry from which to install the package

                 New in version 2014.7.0.

          env    A  list  of  environment  variables  to  be  set prior to
                 execution. The format is the same as the cmd.run.   state
                 function.

                 New in version 2014.7.0.

          force_reinstall
                 Install the package even if it is already installed

   salt.states.npm.removed(name, dir=None, user=None)
          Verify that the given package is not installed.

          dir    The  target directory in which to install the package, or
                 None for global installation

          user   The user to run NPM with

                 New in version 0.17.0.

   salt.states.ntp
   Management of NTP servers
   New in version 2014.1.0.

   This state is used to manage NTP servers.  Currently  only  Windows  is
   supported.

      win_ntp:
        ntp.managed:
          - servers:
            - pool.ntp.org
            - us.pool.ntp.org

   salt.states.ntp.managed(name, servers=None)
          Manage NTP servers

          servers
                 A list of NTP servers

   salt.states.nxos module
   State module for Cisco NX OS Switches Proxy minions

   For  documentation  on  setting  up  the  nxos proxy minion look in the
   documentation for salt.proxy.nxos.

   salt.states.nxos.config_absent(name)
          Ensure a specific configuration  line  does  not  exist  in  the
          running config

          name   config line to remove

          Examples:

             add snmp group:
               nxos.config_absent:
                 - names:
                   - snmp-server community randoSNMPstringHERE group network-operator
                   - snmp-server community AnotherRandomSNMPSTring group network-admin

          NOTE:
             For  certain  cases  extra  lines  could  be removed based on
             dependencies.  In this example, included  after  the  example
             for  config_present,  the  ACLs would be removed because they
             depend on the existance of the group.

   salt.states.nxos.config_present(name)
          Ensure a specific  configuration  line  exists  in  the  running
          config

          name   config line to set

          Examples:

             add snmp group:
               nxos.config_present:
                 - names:
                   - snmp-server community randoSNMPstringHERE group network-operator
                   - snmp-server community AnotherRandomSNMPSTring group network-admin

             add snmp acl:
               nxos.config_present:
                 - names:
                   - snmp-server community randoSNMPstringHERE use-acl snmp-acl-ro
                   - snmp-server community AnotherRandomSNMPSTring use-acl snmp-acl-rw

   salt.states.nxos.replace(name, repl, full_match=False)
          Replace  all  instances  of a string or full line in the running
          config

          name   String to replace

          repl   The replacement text

          full_match
                 Whether name will match the full line or only a subset of
                 the  line.   Defaults  to  False. When False, .* is added
                 around name for matching in the show run config.

          Examples:

             replace snmp string:
               nxos.replace:
                 - name: randoSNMPstringHERE
                 - repl: NEWrandoSNMPstringHERE

             replace full snmp string:
               nxos.replace:
                 - name: ^snmp-server community randoSNMPstringHERE group network-operator$
                 - repl: snmp-server community NEWrandoSNMPstringHERE group network-operator
                 - full_match: True

          NOTE:
             The first example will replace the SNMP string  on  both  the
             group  and  the  ACL,  so  you will not lose the ACL setting.
             Because the second is an exact match of the  line,  when  the
             group  is  removed,  the  ACL  is  removed,  but not readded,
             because it was not matched.

   salt.states.nxos.user_absent(name)
          Ensure a user is not present

          name   username to remove if it exists

          Examples:

             delete:
               nxos.user_absent:
                 - name: daniel

   salt.states.nxos.user_present(name,     password=None,      roles=None,
   encrypted=False, crypt_salt=None, algorithm='sha256')
          Ensure a user is present with the specified groups

          name   Name of user

          password
                 Encrypted or Plain Text password for user

          roles  List of roles the user should be assigned.  Any roles not
                 in this list will be removed

          encrypted
                 Whether  the  password  is  encrypted  already  or   not.
                 Defaults to False

          crypt_salt
                 Salt  to  use  when  encrypting the password.  Default is
                 None (salt is randomly generated for unhashed passwords)

          algorithm
                 Algorithm to  use  for  hashing  password.   Defaults  to
                 sha256.  Accepts md5, blowfish, sha256, sha512

          Examples:

             create:
               nxos.user_present:
                 - name: daniel
                 - roles:
                   - vdc-admin

             set_password:
               nxos.user_present:
                 - name: daniel
                 - password: admin
                 - roles:
                   - network-admin

             update:
               nxos.user_present:
                 - name: daniel
                 - password: AiN9jaoP
                 - roles:
                   - network-admin
                   - vdc-admin

   salt.states.openstack_config
   Manage OpenStack configuration file settings.

   maintainer
          Jeffrey C. Ollie <[email protected]>

   maturity
          new

   depends

   platform
          linux

   salt.states.openstack_config.absent(name,       filename,      section,
   parameter=None)
          Ensure a value is not set in an OpenStack configuration file.

          filename
                 The full path to the configuration file

          section
                 The section in which the parameter will be set

          parameter (optional)
                 The  parameter  to  change.   If  the  parameter  is  not
                 supplied, the name will be used as the parameter.

   salt.states.openstack_config.present(name,  filename,  section,  value,
   parameter=None)
          Ensure a value is set in an OpenStack configuration file.

          filename
                 The full path to the configuration file

          section
                 The section in which the parameter will be set

          parameter (optional)
                 The  parameter  to  change.   If  the  parameter  is  not
                 supplied, the name will be used as the parameter.

          value  The value to set

   salt.states.openvswitch_bridge module
   Management of Open vSwitch bridges.

   salt.states.openvswitch_bridge.absent(name)
          Ensures that the named bridge does not exist, eventually deletes
          it.

          Parameters
                 name -- The name of the bridge.

   salt.states.openvswitch_bridge.present(name)
          Ensures that the named bridge exists, eventually creates it.

          Parameters
                 name -- The name of the bridge.

   salt.states.openvswitch_port module
   Management of Open vSwitch ports.

   salt.states.openvswitch_port.absent(name, bridge=None)
          Ensures that the named port exists on bridge, eventually deletes
          it.  If bridge is not set, port is removed from  whatever bridge
          contains it.

          Parameters

                 * name -- The name of the port.

                 * bridge -- The name of the bridge.

   salt.states.openvswitch_port.present(name, bridge, type=None,  id=None,
   remote=None, dst_port=None)
          Ensures that the named port exists on bridge, eventually creates
          it.

          Parameters

                 * name -- The name of the port.

                 * bridge -- The name of the bridge.

                 * type -- Optional type of interface to create, currently
                   supports: vlan, vxlan and gre.

                 * id -- Optional tunnel's key.

                 * remote -- Remote endpoint's IP address.

                 * dst_port -- Port to use when creating tunnelport in the
                   switch.

   salt.states.pagerduty
   Create an Event in PagerDuty
   New in version 2014.1.0.

   This state is useful for  creating  events  on  the  PagerDuty  service
   during state runs.

      server-warning-message:
        pagerduty.create_event:
          - name: 'This is a server warning message'
          - details: 'This is a much more detailed message'
          - service_key: 9abcd123456789efabcde362783cdbaf
          - profile: my-pagerduty-account

   salt.states.pagerduty.create_event(name, details, service_key, profile)
          Create an event on the PagerDuty service

             server-warning-message:
               pagerduty.create_event:
                 - name: 'This is a server warning message'
                 - details: 'This is a much more detailed message'
                 - service_key: 9abcd123456789efabcde362783cdbaf
                 - profile: my-pagerduty-account

          The following parameters are required:

          name   This is a short description of the event.

          details
                 This can be a more detailed description of the event.

          service_key
                 This key can be found by using pagerduty.list_services.

          profile
                 This  refers  to  the  configuration  profile  to  use to
                 connect to the PagerDuty service.

   salt.states.pagerduty_escalation_policy
   Manage PagerDuty escalation policies.

   Schedules and users can be referenced by pagerduty ID, or by  name,  or
   by email address.

   For example:

      ensure test escalation policy:
          pagerduty_escalation_policy.present:
              - name: bruce test escalation policy
              - escalation_rules:
                  - targets:
                      - type: schedule
                        id: 'bruce test schedule level1'
                      - type: user
                        id: 'Bruce Sherrod'
                    escalation_delay_in_minutes: 15
                  - targets:
                      - type: schedule
                        id: 'bruce test schedule level2'
                    escalation_delay_in_minutes: 15
                  - targets:
                      - type: user
                        id: 'Bruce TestUser1'
                      - type: user
                        id: 'Bruce TestUser2'
                      - type: user
                        id: 'Bruce TestUser3'
                      - type: user
                        id:  'bruce+[email protected]'
                    escalation_delay_in_minutes: 15

   salt.states.pagerduty_escalation_policy.absent(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure that  a  PagerDuty  escalation  policy  does  not  exist.
          Accepts          all          the         arguments         that
          pagerduty_escalation_policy.present  accepts;  but  ignores  all
          arguments except the name.

          Name  can  be  the escalation policy id or the escalation policy
          name.

   salt.states.pagerduty_escalation_policy.present(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure  that  a pagerduty escalation policy exists.  Will create
          or update as needed.

          This   method   accepts   as   args   everything   defined    in
          https://developer.pagerduty.com/documentation/rest/escalation_policies/create.
          In addition, user and schedule id's will be translated from name
          (or email address) into PagerDuty unique ids.  For example:

          pagerduty_escalation_policy.present:

                 * name: bruce test escalation policy

                 *

                   escalation_rules:

                          *

                            targets:

                                   * type:   schedule   id:   'bruce  test
                                     schedule level1'

                                   * type: user id: 'Bruce Sherrod'

          In this example, 'Bruce Sherrod' will be looked up and  replaced
          with  the  PagerDuty id (usually a 7 digit all-caps string, e.g.
          PX6GQL7)

   salt.states.pagerduty_schedule
   Manage PagerDuty schedules.  Example.INDENT 0.0

   ensure test schedule:

          pagerduty_schedule.present:

                 * name: 'bruce test schedule level1'

                 *

                   schedule:
                          name: 'bruce test  schedule  level1'  time_zone:
                          'Pacific Time (US & Canada)' schedule_layers:

                             * name:    'Schedule    Layer    1'    start:
                               '2015-01-01T00:00:00' users:

                                   *

                                     user:  'id': 'Bruce TestUser1'

                                     member_order: 1

                                   *

                                     user:  'id': 'Bruce TestUser2'

                                     member_order: 2

                                   *

                                     user:  'id': 'bruce+[email protected]'

                                     member_order: 3

                                   *

                                     user:  'id': 'bruce+[email protected]'

                                     member_order: 4

                               rotation_virtual_start:
                               '2015-01-01T00:00:00'      priority:      1
                               rotation_turn_length_seconds: 604800

   salt.states.pagerduty_schedule.absent(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure  that  a  pagerduty schedule does not exist.  Name can be
          pagerduty schedule id or pagerduty schedule name.

   salt.states.pagerduty_schedule.present(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure that a pagerduty schedule exists.  This method accepts as
          args             everything              defined              in
          https://developer.pagerduty.com/documentation/rest/schedules/create.
          This means that most arguments are in a dict called "schedule."

          User id's can be pagerduty id, or name, or email address.

   salt.states.pagerduty_service
   Manage PagerDuty services

   Escalation policies can be referenced by pagerduty ID or by namea.

   For example:

      ensure test service

             pagerduty_service.present:

                    * name: 'my service'

                    * escalation_policy_id: 'my escalation policy'

                    * type: nagios

                    [etc]

   salt.states.pagerduty_service.absent(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure  a  pagerduty  service  does  not exist.  Name can be the
          service name or pagerduty service id.

   salt.states.pagerduty_service.present(profile='pagerduty',
   subdomain=None, api_key=None, **kwargs)
          Ensure   pagerduty  service  exists.   This  method  accepts  as
          arguments            everything            defined            in
          https://developer.pagerduty.com/documentation/rest/services/create

          Note that many arguments are mutually  exclusive,  depending  on
          the "type" argument.

          Examples:

          #      create      a      PagerDuty     email     service     at
          [email protected]  ensure  generic  email  service
          exists:

             pagerduty_service.present:

                    * name: my email service

                    *

                      service:
                             description:  "email  service  controlled  by
                             salt"  escalation_policy_id:  "my  escalation
                             policy"  type:  "generic_email"  service_key:
                             "test-email"

          # create a pagerduty service using cloudwatch integration ensure
          my cloudwatch service exists:

             pagerduty_service.present:

                    * name: my cloudwatch service

                    *

                      service:
                             escalation_policy_id:  "my escalation policy"
                             type:   aws_cloudwatch    description:    "my
                             cloudwatch service controlled by salt"

          TODO: aws_cloudwatch type should be integrated with boto_sns

   salt.states.pagerduty_user
   Manage PagerDuty users.  Example.INDENT 0.0

   ensure bruce test user 1:

          pagerduty.user_present:

                 * name: 'Bruce TestUser1'

                 * email: bruce+[email protected]

                 * requester_id: P1GV5NT

   salt.states.pagerduty_user.absent(profile='pagerduty',  subdomain=None,
   api_key=None, **kwargs)
          Ensure pagerduty user does not exist.  Name can be pagerduty id,
          email address, or user name.

   salt.states.pagerduty_user.present(profile='pagerduty', subdomain=None,
   api_key=None, **kwargs)
          Ensure pagerduty user exists.  Arguments match  those  supported
          by
          https://developer.pagerduty.com/documentation/rest/users/create.

   salt.states.pcs module
   Management of Pacemaker/Corosync clusters with PCS
   A  state  module  to  manage  Pacemaker/Corosync  clusters   with   the
   Pacemaker/Corosync configuration system(PCS)

   New in version 2016.110.

   depends
          pcs

   Walkthrough of a complete pcs cluster setup:

   Requirements:
          PCS  is  installed,  pcs service is started and the password for
          the hacluster user is set and known.

   Remark on the cibname variable used in the examples:
          The use of the cibname varible is optional.  Use it only if  you
          want  to  deploy your changes into a cibfile first and then push
          it.  This makes only  sense  if  you  want  to  deploy  multiple
          changes (which require each other) at ones to the cluster.

   At first the cibfile must be created:

      mysql_pcs__cib_present_cib_for_galera:
          pcs.cib_present:
              - cibname: cib_for_galera
              - scope: None
              - extra_args: None

   Then the cibfile can be modified by creating resources (creating only 1
   resource for demonstration, see also 7.):

      mysql_pcs__resource_present_galera:
          pcs.resource_present:
              - resource_id: galera
              - resource_type: "ocf:heartbeat:galera"
              - resource_options:
                  - 'wsrep_cluster_address=gcomm://node1.example.org,node2.example.org,node3.example.org'
                  - '--master'
              - cibname: cib_for_galera

   After modifying the cibfile it can be pushed to the  live  CIB  in  the
   cluster:

      mysql_pcs__cib_pushed_cib_for_galera:
          pcs.cib_pushed:
              - cibname: cib_for_galera
              - scope: None
              - extra_args: None

   Create a cluster from scratch:

   1. Authorize nodes to each other:

         pcs_auth__auth:
             pcs.auth:
                 - nodes:
                     - node1.example.com
                     - node2.example.com
                 - pcsuser: hacluster
                 - pcspasswd: hoonetorg
                 - extra_args: []

   2. Do the initial cluster setup:

         pcs_setup__setup:
             pcs.cluster_setup:
                 - nodes:
                     - node1.example.com
                     - node2.example.com
                 - pcsclustername: pcscluster
                 - extra_args:
                     - '--start'
                     - '--enable'

   3. Optional: Set cluster properties:

         pcs_properties__prop_has_value_no-quorum-policy:
             pcs.prop_has_value:
                 - prop: no-quorum-policy
                 - value: ignore
                 - cibname: cib_for_cluster_settings

   4. Optional: Set resource defaults:

         pcs_properties__resource_defaults_to_resource-stickiness:
             pcs.resource_defaults_to:
                 - default: resource-stickiness
                 - value: 100
                 - cibname: cib_for_cluster_settings

   5. Optional: Set resource op defaults:

         pcs_properties__resource_op_defaults_to_monitor-interval:
             pcs.resource_op_defaults_to:
                 - op_default: monitor-interval
                 - value: 60s
                 - cibname: cib_for_cluster_settings

   6. Configure Fencing (!is not optional on production ready cluster!):

         pcs_stonith__created_eps_fence:
             pcs.stonith_present:
                 - stonith_id: eps_fence
                 - stonith_device_type: fence_eps
                 - stonith_device_options:
                     - 'pcmk_host_map=node1.example.org:01;node2.example.org:02'
                     - 'ipaddr=myepsdevice.example.org'
                     - 'power_wait=5'
                     - 'verbose=1'
                     - 'debug=/var/log/pcsd/eps_fence.log'
                     - 'login=hidden'
                     - 'passwd=hoonetorg'
                 - cibname: cib_for_stonith

   7. Add resources to your cluster:

         mysql_pcs__resource_present_galera:
             pcs.resource_present:
                 - resource_id: galera
                 - resource_type: "ocf:heartbeat:galera"
                 - resource_options:
                     - 'wsrep_cluster_address=gcomm://node1.example.org,node2.example.org,node3.example.org'
                      - '--master'
                  - cibname: cib_for_galera

   8. Optional: Add constraints (locations, colocations, orders):

         haproxy_pcs__constraint_present_colocation-vip_galera-haproxy-clone-INFINITY:
             pcs.constraint_present:
                 - constraint_id: colocation-vip_galera-haproxy-clone-INFINITY
                 - constraint_type: colocation
                 - constraint_options:
                     - 'add'
                     - 'vip_galera'
                     - 'with'
                     - 'haproxy-clone'
                 - cibname: cib_for_haproxy

   New in version 2016.3.0.

   salt.states.pcs.auth(name,          nodes,         pcsuser='hacluster',
   pcspasswd='hacluster', extra_args=None)
          Ensure all nodes are authorized to the cluster

          name   Irrelevant, not used (recommended: pcs_auth__auth)

          nodes  a list of nodes which should be authorized to the cluster

          pcsuser
                 user for communitcation with pcs (default: hacluster)

          pcspasswd
                 password for pcsuser (default: hacluster)

          extra_args
                 list of extra option for the 'pcs cluster auth' command

          Example:

             pcs_auth__auth:
                 pcs.auth:
                     - nodes:
                         - node1.example.com
                         - node2.example.com
                     - pcsuser: hacluster
                     - pcspasswd: hoonetorg
                     - extra_args: []

   salt.states.pcs.cib_present(name, cibname, scope=None, extra_args=None)
          Ensure that a CIB-file with the content of the current live  CIB
          is created

          Should be run on one cluster node only (there may be races)

          name   Irrelevant,         not         used        (recommended:
                 {{formulaname}}__cib_present_{{cibname}})

          cibname
                 name/path of the file containing the CIB

          scope  specific section of the CIB (default:

          extra_args
                 additional options for creating the CIB-file

          Example:

             mysql_pcs__cib_present_cib_for_galera:
                 pcs.cib_present:
                     - cibname: cib_for_galera
                     - scope: None
                     - extra_args: None

   salt.states.pcs.cib_pushed(name, cibname, scope=None, extra_args=None)
          Ensure that a CIB-file is pushed if  it  is  changed  since  the
          creation of it with pcs.cib_present

          Should be run on one cluster node only (there may be races)

          name   Irrelevant,         not         used        (recommended:
                 {{formulaname}}__cib_pushed_{{cibname}})

          cibname
                 name/path of the file containing the CIB

          scope  specific section of the CIB

          extra_args
                 additional options for creating the CIB-file

          Example:

             mysql_pcs__cib_pushed_cib_for_galera:
                 pcs.cib_pushed:
                     - cibname: cib_for_galera
                     - scope: None
                     - extra_args: None

   salt.states.pcs.cluster_node_present(name, node, extra_args=None)
          Add a node to the Pacemaker cluster via PCS Should be run on one
          cluster  node  only  (there  may  be races) Can only be run on a
          already setup/added node

          name   Irrelevant,        not         used         (recommended:
                 pcs_setup__node_add_{{node}})

          node   node that should be added

          extra_args
                 list  of  extra  option  for  the  'pcs cluster node add'
                 command

          Example:

             pcs_setup__node_add_node1.example.com:
                 pcs.cluster_node_present:
                     - node: node1.example.com
                     - extra_args:
                         - '--start'
                         - '--enable'

   salt.states.pcs.cluster_setup(name, nodes, pcsclustername='pcscluster',
   extra_args=None)
          Setup  Pacemaker cluster on nodes.  Should be run on one cluster
          node only (there may be races)

          name   Irrelevant, not used (recommended: pcs_setup__setup)

          nodes  a list of nodes which should be set up

          pcsclustername
                 Name of the Pacemaker cluster

          extra_args
                 list of extra option for the 'pcs cluster setup' command

          Example:

             pcs_setup__setup:
                 pcs.cluster_setup:
                     - nodes:
                         - node1.example.com
                         - node2.example.com
                     - pcsclustername: pcscluster
                     - extra_args:
                         - '--start'
                         - '--enable'

   salt.states.pcs.constraint_present(name,                 constraint_id,
   constraint_type, constraint_options=None, cibname=None)
          Ensure that a constraint is created

          Should  be run on one cluster node only (there may be races) Can
          only be run on a node with a functional pacemaker/corosync

          name   Irrelevant,        not         used         (recommended:
                 {{formulaname}}__constraint_present_{{constraint_id}})

          constraint_id
                 name  for the constraint (try first to create manually to
                 find out the autocreated name)

          constraint_type
                 constraint type (location, colocation, order)

          constraint_options
                 options for creating the constraint

          cibname
                 use a cached CIB-file named like cibname instead  of  the
                 live CIB

          Example:

             haproxy_pcs__constraint_present_colocation-vip_galera-haproxy-clone-INFINITY:
                 pcs.constraint_present:
                     - constraint_id: colocation-vip_galera-haproxy-clone-INFINITY
                     - constraint_type: colocation
                     - constraint_options:
                         - 'add'
                         - 'vip_galera'
                         - 'with'
                         - 'haproxy-clone'
                     - cibname: cib_for_haproxy

   salt.states.pcs.prop_has_value(name,   prop,   value,  extra_args=None,
   cibname=None)
          Ensure that a property in the cluster is set to a given value

          Should be run on one cluster node only (there may be races)

          name   Irrelevant,        not         used         (recommended:
                 pcs_properties__prop_has_value_{{prop}})

          prop   name of the property

          value  value of the property prop

          extra_args
                 additional options for the pcs property command

          cibname
                 use  a  cached CIB-file named like cibname instead of the
                 live CIB

          Example:

             pcs_properties__prop_has_value_no-quorum-policy:
                 pcs.prop_has_value:
                     - prop: no-quorum-policy
                     - value: ignore
                     - cibname: cib_for_cluster_settings

   salt.states.pcs.resource_defaults_to(name,       default,        value,
   extra_args=None, cibname=None)
          Ensure a resource default in the cluster is set to a given value

          Should  be run on one cluster node only (there may be races) Can
          only be run on a node with a functional pacemaker/corosync

          name   Irrelevant,        not         used         (recommended:
                 pcs_properties__resource_defaults_to_{{default}})

          default
                 name of the default resource property

          value  value of the default resource property

          extra_args
                 additional options for the pcs command

          cibname
                 use  a  cached CIB-file named like cibname instead of the
                 live CIB

          Example:

             pcs_properties__resource_defaults_to_resource-stickiness:
                 pcs.resource_defaults_to:
                     - default: resource-stickiness
                     - value: 100
                     - cibname: cib_for_cluster_settings

   salt.states.pcs.resource_op_defaults_to(name,    op_default,     value,
   extra_args=None, cibname=None)
          Ensure  a  resource operation default in the cluster is set to a
          given value

          Should be run on one cluster node only (there may be races)  Can
          only be run on a node with a functional pacemaker/corosync

          name   Irrelevant,         not         used        (recommended:
                 pcs_properties__resource_op_defaults_to_{{op_default}})

          op_default
                 name of the operation default resource property

          value  value of the operation default resource property

          extra_args
                 additional options for the pcs command

          cibname
                 use a cached CIB-file named like cibname instead  of  the
                 live CIB

          Example:

             pcs_properties__resource_op_defaults_to_monitor-interval:
                 pcs.resource_op_defaults_to:
                     - op_default: monitor-interval
                     - value: 60s
                     - cibname: cib_for_cluster_settings

   salt.states.pcs.resource_present(name,    resource_id,   resource_type,
   resource_options=None, cibname=None)
          Ensure that a resource is created

          Should be run on one cluster node only (there may be races)  Can
          only be run on a node with a functional pacemaker/corosync

          name   Irrelevant,         not         used        (recommended:
                 {{formulaname}}__resource_present_{{resource_id}})

          resource_id
                 name for the resource

          resource_type
                 resource type (f.e. ocf:heartbeat:IPaddr2 or VirtualIP)

          resource_options
                 additional options for creating the resource

          cibname
                 use a cached CIB-file named like cibname instead  of  the
                 live CIB

          Example:

             mysql_pcs__resource_present_galera:
                 pcs.resource_present:
                     - resource_id: galera
                     - resource_type: "ocf:heartbeat:galera"
                     - resource_options:
                         - 'wsrep_cluster_address=gcomm://node1.example.org,node2.example.org,node3.example.org'
                         - '--master'
                     - cibname: cib_for_galera

   salt.states.pcs.stonith_present(name,  stonith_id, stonith_device_type,
   stonith_device_options=None, cibname=None)
          Ensure that a fencing resource is created

          Should be run on one cluster node only (there may be races)  Can
          only be run on a node with a functional pacemaker/corosync

          name   Irrelevant,         not         used        (recommended:
                 pcs_stonith__created_{{stonith_id}})

          stonith_id
                 name for the stonith resource

          stonith_device_type
                 name of the stonith agent fence_eps, fence_xvm f.e.

          stonith_device_options
                 additional options for creating the stonith resource

          cibname
                 use a cached CIB-file named like cibname instead  of  the
                 live CIB

          Example:

             pcs_stonith__created_eps_fence:
                 pcs.stonith_present:
                     - stonith_id: eps_fence
                     - stonith_device_type: fence_eps
                     - stonith_device_options:
                         - 'pcmk_host_map=node1.example.org:01;node2.example.org:02'
                         - 'ipaddr=myepsdevice.example.org'
                         - 'power_wait=5'
                         - 'verbose=1'
                         - 'debug=/var/log/pcsd/eps_fence.log'
                         - 'login=hidden'
                         - 'passwd=hoonetorg'
                     - cibname: cib_for_stonith

   salt.states.pecl
   Installation of PHP Extensions Using pecl
   These  states  manage the installed pecl extensions. Note that php-pear
   must be installed for these states to  be  available,  so  pecl  states
   should  include  a  requisite  to a pkg.installed state for the package
   which provides pecl (php-pear in most cases). Example:

      php-pear:
        pkg.installed

      mongo:
        pecl.installed:
          - require:
            - pkg: php-pear

   salt.states.pecl.installed(name,     version=None,      defaults=False,
   force=False, preferred_state='stable')
          New in version 0.17.0.

          Make sure that a pecl extension is installed.

          name   The pecl extension name to install

          version
                 The pecl extension version to install. This option may be
                 ignored to install the latest stable version.

          defaults
                 Use default answers  for  extensions  such  as  pecl_http
                 which  ask  questions  before  installation. Without this
                 option, the pecl.installed state will  hang  indefinitely
                 when trying to install these extensions.

          force  Whether to force the installed version or not

          preferred_state
                 The pecl extension state to install

   salt.states.pecl.removed(name)
          Make sure that a pecl extension is not installed.

          name   The pecl extension name to uninstall

   salt.states.pip_state
   Installation of Python Packages Using pip
   These  states  manage  system  installed python packages. Note that pip
   must be installed for these states  to  be  available,  so  pip  states
   should  include  a  requisite  to a pkg.installed state for the package
   which provides pip (python-pip in most cases). Example:

      python-pip:
        pkg.installed

      virtualenvwrapper:
        pip.installed:
          - require:
            - pkg: python-pip

   salt.states.pip_state.installed(name,     pkgs=None,      pip_bin=None,
   requirements=None,  bin_env=None,  use_wheel=False, no_use_wheel=False,
   log=None,   proxy=None,   timeout=None,    repo=None,    editable=None,
   find_links=None,  index_url=None, extra_index_url=None, no_index=False,
   mirrors=None,       build=None,       target=None,       download=None,
   download_cache=None, source=None, upgrade=False, force_reinstall=False,
   ignore_installed=False,       exists_action=None,        no_deps=False,
   no_install=False,        no_download=False,       install_options=None,
   global_options=None,     user=None,      no_chown=False,      cwd=None,
   pre_releases=False,         cert=None,        allow_all_external=False,
   allow_external=None,                             allow_unverified=None,
   process_dependency_links=False,       env_vars=None,      use_vt=False,
   trusted_host=None, no_cache_dir=False)
          Make sure the package is installed

          name   The name of the python package to install. You  can  also
                 specify version numbers here using the standard operators
                 ==, >=, <=. If requirements is given, this parameter will
                 be ignored.

          Example:

             django:
               pip.installed:
                 - name: django >= 1.6, <= 1.7
                 - require:
                   - pkg: python-pip

          This will install the latest Django version greater than 1.6 but
          less than 1.7.

          requirements
                 Path to a pip requirements file. If the path begins  with
                 salt:// the file will be transferred from the master file
                 server.

          user   The user under which to run pip

          use_wheel
                 False Prefer wheel archives (requires pip>=1.4)

          no_use_wheel
                 False Force to not use wheel archives (requires pip>=1.4)

          log    Log file where a complete (maximum verbosity) record will
                 be kept

          proxy  Specify       a       proxy       in       the       form
                 user:[email protected]:port.     Note     that      the
                 user:password@  is  optional and required only if you are
                 behind  an   authenticated   proxy.    If   you   provide
                 [email protected]:port  then  you  will be prompted for a
                 password.

          timeout
                 Set the socket timeout (default 15 seconds)

          editable
                 install         something         editable          (i.e.
                 git+https://github.com/worldcompany/djangoembed.git#egg=djangoembed)

          find_links
                 URL to look for packages at

          index_url
                 Base URL of Python Package Index

          extra_index_url
                 Extra URLs of package  indexes  to  use  in  addition  to
                 index_url

          no_index
                 Ignore package index

          mirrors
                 Specific  mirror  URL(s)  to  query  (automatically  adds
                 --use-mirrors)

          build  Unpack packages into build dir

          target Install packages into target dir

          download
                 Download packages into  download  instead  of  installing
                 them

          download_cache
                 Cache downloaded packages in download_cache dir

          source Check out editable packages into source dir

          upgrade
                 Upgrade all packages to the newest available version

          force_reinstall
                 When  upgrading,  reinstall all packages even if they are
                 already up-to-date.

          ignore_installed
                 Ignore the installed packages (reinstalling instead)

          exists_action
                 Default action when  a  path  already  exists:  (s)witch,
                 (i)gnore, (w)ipe, (b)ackup

          no_deps
                 Ignore package dependencies

          no_install
                 Download  and  unpack  all  packages,  but don't actually
                 install them

          no_chown
                 When user is given, do not attempt to copy  and  chown  a
                 requirements file

          no_cache_dir:
                 Disable the cache.

          cwd    Current working directory to run pip from

          pre_releases
                 Include pre-releases in the available versions

          cert   Provide a path to an alternate CA bundle

          allow_all_external
                 Allow the installation of all externally hosted files

          allow_external
                 Allow  the installation of externally hosted files (comma
                 separated list)

          allow_unverified
                 Allow the installation of insecure and unverifiable files
                 (comma separated list)

          process_dependency_links
                 Enable the processing of dependency links

          bin_env
                 None  Absolute path to a virtual environment directory or
                 absolute path to a  pip  executable.  The  example  below
                 assumes   a  virtual  environment  has  been  created  at
                 /foo/.virtualenvs/bar.

          env_vars
                 Add or modify environment variables. Useful for  tweaking
                 build  steps, such as specifying INCLUDE or LIBRARY paths
                 in Makefiles, build scripts or compiler calls.  This must
                 be in the form of a dictionary or a mapping.

                 Example:

                    django:
                      pip.installed:
                        - name: django_app
                        - env_vars:
                            CUSTOM_PATH: /opt/django_app
                            VERBOSE: True

          use_vt Use VT terminal emulation (see output while installing)

          trusted_host
                 Mark  this  host as trusted, even though it does not have
                 valid or any HTTPS.

          Example:

             django:
               pip.installed:
                 - name: django >= 1.6, <= 1.7
                 - bin_env: /foo/.virtualenvs/bar
                 - require:
                   - pkg: python-pip

          Or

          Example:

             django:
               pip.installed:
                 - name: django >= 1.6, <= 1.7
                 - bin_env: /foo/.virtualenvs/bar/bin/pip
                 - require:
                   - pkg: python-pip

             Attention

                    The following arguments are deprecated, do not use.

          pip_bin
                 None Deprecated, use bin_env

          Changed in version 0.17.0: use_wheel option added.

          install_options
             Extra arguments  to  be  supplied  to  the  setup.py  install
             command.   If  you are using an option with a directory path,
             be sure to use absolute path.

             Example:

                 django:
                   pip.installed:
                     - name: django
                     - install_options:
                       - --prefix=/blah
                     - require:
                       - pkg: python-pip

          global_options
                 Extra global options to be supplied to the setup.py  call
                 before the install command.

                 New in version 2014.1.3.

             Attention

                    As  of  Salt  0.17.0 the pip state needs an importable
                    pip module.  This usually means  having  the  system's
                    pip  package  installed or running Salt from an active
                    virtualenv.

                    The reason for this requirement is because pip already
                    does  a  pretty good job parsing its own requirements.
                    It makes no sense for  Salt  to  do  pip  requirements
                    parsing  and validation before passing them to the pip
                    library. It's functionality duplication and it's  more
                    error prone.

             Attention

                    Please  set  reload_modules:  True  to  have  the salt
                    minion import this module after installation.

          Example:

             pyopenssl:
                 pip.installed:
                     - name: pyOpenSSL
                     - reload_modules: True
                     - exists_action: i

   salt.states.pip_state.removed(name,  requirements=None,   bin_env=None,
   log=None, proxy=None, timeout=None, user=None, cwd=None, use_vt=False)
          Make sure that a package is not installed.

          name   The name of the package to uninstall

          user   The user under which to run pip

          bin_env
                 None the pip executable or virtualenenv to use

          use_vt Use VT terminal emulation (see output while installing)

   salt.states.pip_state.uptodate(name, bin_env=None, user=None, cwd=None,
   use_vt=False)
          New in version 2015.5.0.

          Verify that the system is completely up to date.

          name   The name has no functional value and is only  used  as  a
                 tracking reference

          user   The user under which to run pip

          bin_env
                 the pip executable or virtualenenv to use

          use_vt Use VT terminal emulation (see output while installing)

   salt.states.pkg
   Installation of packages using OS package managers such as yum or apt-get
   NOTE:
      On  minions running systemd>=205, as of version 2015.8.12, 2016.3.3,
      and 2016.11.0, systemd-run(1) is now used to isolate commands  which
      modify  installed  packages  from  the  salt-minion daemon's control
      group. This is done to keep systemd from killing the package manager
      commands  spawned by Salt, when Salt updates itself (see KillMode in
      the systemd.kill(5) manpage for more information). If desired, usage
      of  systemd-run(1)  can  be  suppressed  by  setting a config option
      called systemd.use_scope, with a value of False (no quotes).

   Salt can manage software packages via the pkg  state  module,  packages
   can  be  set  up  to  be installed, latest, removed and purged. Package
   management declarations are typically rather simple:

      vim:
        pkg.installed

   A more involved example involves pulling from a custom repository.

      base:
        pkgrepo.managed:
          - humanname: Logstash PPA
          - name: ppa:wolfnet/logstash
          - dist: precise
          - file: /etc/apt/sources.list.d/logstash.list
          - keyid: 28B04E4A
          - keyserver: keyserver.ubuntu.com

      logstash:
        pkg.installed
          - fromrepo: ppa:wolfnet/logstash

   Multiple packages can also be installed with the use of the pkgs  state
   module

      dotdeb.repo:
        pkgrepo.managed:
          - humanname: Dotdeb
          - name: deb http://packages.dotdeb.org wheezy-php55 all
          - dist: wheezy-php55
          - file: /etc/apt/sources.list.d/dotbeb.list
          - keyid: 89DF5277
          - keyserver: keys.gnupg.net
          - refresh_db: true

      php.packages:
        pkg.installed:
          - fromrepo: wheezy-php55
          - pkgs:
            - php5-fpm
            - php5-cli
            - php5-curl

   WARNING:
      Package names are currently case-sensitive. If the minion is using a
      package manager which is not case-sensitive (such  as  pkgng),  then
      this  state  will  fail if the proper case is not used. This will be
      addressed in a future release of Salt.

   salt.states.pkg.group_installed(name,     skip=None,      include=None,
   **kwargs)
          New in version 2015.8.0.

          Changed in version 2016.11.0: Added support in pacman

          Ensure  that an entire package group is installed. This state is
          currently  only  supported  for  the  yum  and  pacman   package
          managers.

          skip   Packages  that would normally be installed by the package
                 group  ("default"  packages),   which   should   not   be
                 installed.

                    Load Balancer:
                      pkg.group_installed:
                        - skip:
                          - piranha

          include
                 Packages  which  are included in a group, which would not
                 normally be installed by a yum  groupinstall  ("optional"
                 packages).   Note   that  this  will  not  enforce  group
                 membership; if you include packages which are not members
                 of the specified groups, they will still be installed.

                    Load Balancer:
                      pkg.group_installed:
                        - include:
                          - haproxy

                 Changed in version 2016.3.0: This option can no longer be
                 passed as a comma-separated list, it must now  be  passed
                 as a list (as shown in the above example).

          NOTE:
             Because this is essentially a wrapper around pkg.install, any
             argument which can be  passed  to  pkg.install  may  also  be
             included  here,  and  it  will  be  passed  on to the call to
             pkg.install.

   salt.states.pkg.installed(name,       version=None,       refresh=None,
   fromrepo=None,  skip_verify=False,  skip_suggestions=False,  pkgs=None,
   sources=None,  allow_updates=False,  pkg_verify=False,  normalize=True,
   ignore_epoch=False, reinstall=False, update_holds=False, **kwargs)
             Ensure  that  the  package  is  installed, and that it is the
             correct version (if specified).

             param str name
                    The  name  of  the  package  to  be  installed.   This
                    parameter  is ignored if either "pkgs" or "sources" is
                    used. Additionally, please note that this  option  can
                    only  be  used  to  install  packages  from a software
                    repository.  To install a package file  manually,  use
                    the "sources" option detailed below.

             param str version
                    Install  a  specific version of a package. This option
                    is ignored  if  "sources"  is  used.  Currently,  this
                    option  is  supported for the following pkg providers:
                    apt, ebuild, pacman, win_pkg, yumpkg, and zypper.  The
                    version  number includes the release designation where
                    applicable, to allow Salt to target a specific release
                    of   a   given  version.  When  in  doubt,  using  the
                    pkg.latest_version function for an uninstalled package
                    will tell you the version available.

                        # salt myminion pkg.latest_version vim-enhanced
                        myminion:
                            2:7.4.160-1.el7

                    IMPORTANT:
                        As  of  version  2015.8.7,  for  distros which use
                        yum/dnf, packages which  have  a  version  with  a
                        nonzero  epoch (that is, versions which start with
                        a  number  followed  by  a  colon  like   in   the
                        pkg.latest_version  output  above)  must  have the
                        epoch included when specifying the version number.
                        For example:

                           vim-enhanced:
                             pkg.installed:
                               - version: 2:7.4.160-1.el7

                        In  version 2015.8.9, an ignore_epoch argument has
                        been  added  to  pkg.installed,  pkg.removed,  and
                        pkg.purged  states,  which  causes the epoch to be
                        disregarded when the state checks to  see  if  the
                        desired version was installed.

                    Also,  while  this function is not yet implemented for
                    all pkg frontends, pkg.list_repo_pkgs  will  show  all
                    versions  available  in the various repositories for a
                    given package, irrespective of whether or  not  it  is
                    installed.

                        # salt myminion pkg.list_repo_pkgs httpd
                        myminion:
                            ----------
                            base:
                                |_
                                  ----------
                                  httpd:
                                      2.2.15-29.el6.centos
                            updates:
                                |_
                                  ----------
                                  httpd:
                                      2.2.15-30.el6.centos

                    The  version  strings  returned  by  either  of  these
                    functions can be used as  version  specifiers  in  pkg
                    states.

                    You can install a specific version when using the pkgs
                    argument by including the version after the package:

                        common_packages:
                          pkg.installed:
                            - pkgs:
                              - unzip
                              - dos2unix
                              - salt-minion: 2015.8.5-1.el6

                    If the version given is the string latest, the  latest
                    available  package  version  will  be  installed   la
                    pkg.latest.

             param bool refresh
                    This parameter controls whether  or  not  the  package
                    repo  database  is  updated  prior  to  installing the
                    requested package(s).

                    If  True,  the  package  database  will  be  refreshed
                    (apt-get  update or equivalent, depending on platform)
                    before installing.

                    If False, the package database will not  be  refreshed
                    before installing.

                    If  unset, then Salt treats package database refreshes
                    differently depending on whether or not  a  pkg  state
                    has been executed already during the current Salt run.
                    Once a refresh has been performed in a pkg state,  for
                    the remainder of that Salt run no other refreshes will
                    be performed for pkg states which  do  not  explicitly
                    set refresh to True. This prevents needless additional
                    refreshes from slowing down the Salt run.

             param str cache_valid_time
                    New in version 2016.11.0.

                    This parameter sets the value in seconds  after  which
                    the  cache is marked as invalid, and a cache update is
                    necessary. This  overwrites  the  refresh  parameter's
                    default behavior.

                    Example:

                        httpd:
                          pkg.installed:
                            - fromrepo: mycustomrepo
                            - skip_verify: True
                            - skip_suggestions: True
                            - version: 2.0.6~ubuntu3
                            - refresh: True
                            - cache_valid_time: 300
                            - allow_updates: True
                            - hold: False

                    In  this  case,  a  refresh  will not take place for 5
                    minutes since the last apt-get update was executed  on
                    the system.

                    NOTE:
                        This  parameter  is available only on Debian based
                        distributions and has no effect on the rest.

             param str fromrepo
                    Specify a repository from which to install

                    NOTE:
                        Distros which use APT (Debian,  Ubuntu,  etc.)  do
                        not  have  a  concept of repositories, in the same
                        way as YUM-based distros  do.  When  a  source  is
                        added, it is assigned to a given release. Consider
                        the following source configuration:

                           deb http://ppa.launchpad.net/saltstack/salt/ubuntu precise main

                        The packages provided by this source would be made
                        available   via  the  precise  release,  therefore
                        fromrepo would need to be set to precise for  Salt
                        to install the package from this source.

                        Having  multiple  sources  in the same release may
                        result in  the  default  install  candidate  being
                        newer  than  what is desired. If this is the case,
                        the desired version must be  specified  using  the
                        version parameter.

                        If  the  pkgs  parameter  is being used to install
                        multiple packages in the same state, then  instead
                        of  using  version,  use  the  method  of  version
                        specification described in  the  Multiple  Package
                        Installation Options section below.

                        Running the shell command apt-cache policy pkgname
                        on  a  minion   can   help   elucidate   the   APT
                        configuration  and  aid  in  properly  configuring
                        states:

                           root@saltmaster:~# salt ubuntu01 cmd.run 'apt-cache policy ffmpeg'
                           ubuntu01:
                               ffmpeg:
                               Installed: (none)
                               Candidate: 7:0.10.11-1~precise1
                               Version table:
                                   7:0.10.11-1~precise1 0
                                       500 http://ppa.launchpad.net/jon-severinsson/ffmpeg/ubuntu/ precise/main amd64 Packages
                                   4:0.8.10-0ubuntu0.12.04.1 0
                                       500 http://us.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
                                       500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
                                   4:0.8.1-0ubuntu1 0
                                       500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

                        The release is located directly after the source's
                        URL.  The  actual  release name is the part before
                        the    slash,    so     to     install     version
                        4:0.8.10-0ubuntu0.12.04.1  either  precise-updates
                        or precise-security could be used for the fromrepo
                        value.

             param bool skip_verify
                    Skip  the GPG verification check for the package to be
                    installed

             param bool skip_suggestions
                    Force  strict  package  naming.  Disables  lookup   of
                    package alternatives.

                    New in version 2014.1.1.

             param bool allow_updates
                    Allow the package to be updated outside Salt's control
                    (e.g. auto updates on Windows). This means  a  package
                    on the Minion can have a newer version than the latest
                    available  in  the  repository  without  enforcing   a
                    re-installation of the package.

                    New in version 2014.7.0.

                    Example:

                        httpd:
                          pkg.installed:
                            - fromrepo: mycustomrepo
                            - skip_verify: True
                            - skip_suggestions: True
                            - version: 2.0.6~ubuntu3
                            - refresh: True
                            - allow_updates: True
                            - hold: False

             param bool pkg_verify
                    New in version 2014.7.0.

                    For  requested packages that are already installed and
                    would not be targeted for upgrade  or  downgrade,  use
                    pkg.verify  to determine if any of the files installed
                    by the package have been altered. If files  have  been
                    altered,  the  reinstall option of pkg.install is used
                    to force a reinstall. Types to ignore can be passed to
                    pkg.verify.  Additionally,  verify_options can be used
                    to modify further  the  behavior  of  pkg.verify.  See
                    examples  below.   Currently, this option is supported
                    for the following pkg providers: yumpkg.

                    Examples:

                        httpd:
                          pkg.installed:
                            - version: 2.2.15-30.el6.centos
                            - pkg_verify: True

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo
                              - bar: 1.2.3-4
                              - baz
                            - pkg_verify:
                              - ignore_types:
                                - config
                                - doc

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo
                              - bar: 1.2.3-4
                              - baz
                            - pkg_verify:
                              - ignore_types:
                                - config
                                - doc
                              - verify_options:
                                - nodeps
                                - nofiledigest

             param list ignore_types
                    List of types to ignore when verifying the package

                    New in version 2014.7.0.

             param list verify_options
                    List of additional options to pass when verifying  the
                    package.  These  options  will  be added to the rpm -V
                    command, prepended with -- (for example,  when  nodeps
                    is  passed  in  this  option,  rpm -V will be run with
                    --nodeps).

                    New in version 2016.11.0.

             param bool normalize
                    Normalize   the   package   name   by   removing   the
                    architecture,  if  the  architecture of the package is
                    different  from  the  architecture  of  the  operating
                    system. The ability to disable this behavior is useful
                    for  poorly-created   packages   which   include   the
                    architecture  as  an  actual part of the name, such as
                    kernel modules which match a specific kernel version.

                    New in version 2014.7.0.

                    Example:

                        gpfs.gplbin-2.6.32-279.31.1.el6.x86_64:
                          pkg.installed:
                            - normalize: False

             param bool ignore_epoch
                    When a package  version  contains  an  non-zero  epoch
                    (e.g.   1:3.14.159-2.el7,  and a specific version of a
                    package is desired, set this option to True to  ignore
                    the epoch when comparing versions. This allows for the
                    following SLS to be used:

                        # Actual vim-enhanced version: 2:7.4.160-1.el7
                        vim-enhanced:
                          pkg.installed:
                            - version: 7.4.160-1.el7
                            - ignore_epoch: True

                    Without this option set to True in the above  example,
                    the  package  would  be installed, but the state would
                    report as failed because the actual installed  version
                    would  be  2:7.4.160-1.el7. Alternatively, this option
                    can be left as False and the full version string (with
                    epoch) can be specified in the SLS file:

                        vim-enhanced:
                          pkg.installed:
                            - version: 2:7.4.160-1.el7

                    New in version 2015.8.9.

             MULTIPLE  PACKAGE  INSTALLATION  OPTIONS:  (not  supported in
             pkgng)

             param list pkgs
                    A  list  of  packages  to  install  from  a   software
                    repository.  All  packages  listed  under pkgs will be
                    installed via a single command.

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo
                              - bar
                              - baz
                            - hold: True

                    NOTE: For apt, ebuild,  pacman,  yumpkg,  and  zypper,
                    version numbers can be specified in the pkgs argument.
                    For example:

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo
                              - bar: 1.2.3-4
                              - baz

                    Additionally, ebuild, pacman and zypper support the <,
                    <=,  >=,  and  >  operators for more control over what
                    versions will be installed. For example:

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo
                              - bar: '>=1.2.3-4'
                              - baz

                    NOTE: When using comparison operators, the  expression
                    must  be  enclosed  in  quotes  to avoid a YAML render
                    error.

                    With ebuild is also possible to  specify  a  use  flag
                    list  and/or  if  the  given  packages  should  be  in
                    package.accept_keywords file and/or the  overlay  from
                    which  you  want  the  package  to  be  installed. For
                    example:

                        mypkgs:
                          pkg.installed:
                            - pkgs:
                              - foo: '~'
                              - bar: '~>=1.2:slot::overlay[use,-otheruse]'
                              - baz

             param list sources
                    A list of packages to install, along with  the  source
                    URI  or local path from which to install each package.
                    In the example below, foo, bar, baz, etc. refer to the
                    name  of the package, as it would appear in the output
                    of the pkg.version or pkg.list_pkgs salt CLI commands.

                        mypkgs:
                          pkg.installed:
                            - sources:
                              - foo: salt://rpms/foo.rpm
                              - bar: http://somesite.org/bar.rpm
                              - baz: ftp://someothersite.org/baz.rpm
                              - qux: /minion/path/to/qux.rpm

             PLATFORM-SPECIFIC ARGUMENTS

             These are specific to each OS. If it does not  apply  to  the
             execution module for your OS, it is ignored.

             param bool hold
                    Force  the package to be held at the current installed
                    version.  Currently works with  YUM/DNF  &  APT  based
                    systems.

                    New in version 2014.7.0.

             param bool update_holds
                    If  True,  and  this function would update the package
                    version, any packages which are  being  held  will  be
                    temporarily  unheld  so  that  they  can  be  updated.
                    Otherwise, if this function attempts to update a  held
                    package,  the  held package(s) will be skipped and the
                    state will fail.  By default, this parameter is set to
                    False.

                    This option is currently supported only for YUM/DNF.

                    New in version 2016.11.0.

             param list names
                    A   list  of  packages  to  install  from  a  software
                    repository.   Each   package   will    be    installed
                    individually by the package manager.

                    WARNING:
                        Unlike  pkgs, the names parameter cannot specify a
                        version.  In addition, it makes a separate call to
                        the  package  management  frontend to install each
                        package, whereas pkgs makes just a single call. It
                        is  therefore  recommended  to use pkgs instead of
                        names to install multiple packages, both  for  the
                        additional    features    and    the   performance
                        improvement that it brings.

             param bool install_recommends
                    Whether to install the packages marked as recommended.
                    Default  is  True. Currently only works with APT-based
                    systems.

                    New in version 2015.5.0.

                        httpd:
                          pkg.installed:
                            - install_recommends: False

             param bool only_upgrade
                    Only  upgrade  the  packages,  if  they  are   already
                    installed. Default is False. Currently only works with
                    APT-based systems.

                    New in version 2015.5.0.

                        httpd:
                          pkg.installed:
                            - only_upgrade: True

                    NOTE:
                        If this parameter is set to True and  the  package
                        is not already installed, the state will fail.

          Parameters
                 report_reboot_exit_codes (bool) -- .INDENT 7.0
             If the installer exits with a recognized exit code indicating
             that a reboot is required, the module function
                 win_system.set_reboot_required_witnessed

             will be called, preserving the knowledge of  this  event  for
             the  remainder  of  the  current  boot  session. For the time
             being, 3010 is the only recognized exit  code,  but  this  is
             subject  to  future  refinement.   The  value  of  this param
             defaults to True. This paramater has no effect on non-Windows
             systems.

             New in version 2016.11.0.

                 ms vcpp installed:
                   pkg.installed:
                     - name: ms-vcpp
                     - version: 10.0.40219
                     - report_reboot_exit_codes: False

          return A   dictionary  containing  the  state  of  the  software
                 installation

          rtype dict

          NOTE:
             The pkg.installed state supports the usage of reload_modules.
             This  functionality  allows  you  to force Salt to reload all
             modules.  In  many  cases,   Salt   is   clever   enough   to
             transparently  reload  the  modules.   For  example,  if  you
             install a package, Salt reloads modules  because  some  other
             module   or   state  might  require  the  package  which  was
             installed.  However, there are some edge cases where this may
             not  be  the  case,  which is what reload_modules is meant to
             resolve.

             You should only use reload_modules if your pkg.installed does
             some  sort  of  installation  where  if you do not reload the
             modules future items in your state which rely on the software
             being  installed  will fail. Please see the Reloading Modules
             documentation for more information.

   salt.states.pkg.latest(name,        refresh=None,        fromrepo=None,
   skip_verify=False, pkgs=None, watch_flags=True, **kwargs)
             Ensure  that  the  named  package is installed and the latest
             available package. If the package can be updated, this  state
             function  will update the package. Generally it is better for
             the installed function to be used, as latest will update  the
             package whenever a new package is available.

             name   The  name  of  the  package  to maintain at the latest
                    available  version.   This  parameter  is  ignored  if
                    "pkgs" is used.

             fromrepo
                    Specify a repository from which to install

             skip_verify
                    Skip  the GPG verification check for the package to be
                    installed

             refresh
                    This parameter controls whether  or  not  the  package
                    repo  database  is  updated  prior to checking for the
                    latest available version of the requested packages.

                    If  True,  the  package  database  will  be  refreshed
                    (apt-get  update or equivalent, depending on platform)
                    before checking for the latest  available  version  of
                    the requested packages.

                    If  False,  the package database will not be refreshed
                    before checking.

                    If unset, then Salt treats package database  refreshes
                    differently  depending  on  whether or not a pkg state
                    has been executed already during the current Salt run.
                    Once  a refresh has been performed in a pkg state, for
                    the remainder of that Salt run no other refreshes will
                    be  performed  for  pkg states which do not explicitly
                    set refresh to True. This prevents needless additional
                    refreshes from slowing down the Salt run.

             param str cache_valid_time
                    New in version 2016.11.0.

                    This  parameter  sets the value in seconds after which
                    the cache is marked as invalid, and a cache update  is
                    necessary.  This  overwrites  the  refresh parameter's
                    default behavior.

                    Example:

                        httpd:
                          pkg.latest:
                            - refresh: True
                            - cache_valid_time: 300

                    In this case, a refresh will  not  take  place  for  5
                    minutes  since the last apt-get update was executed on
                    the system.

                    NOTE:
                        This parameter is available only on  Debian  based
                        distributions and has no effect on the rest.

             Multiple Package Installation Options:

             (Not  yet supported for: FreeBSD, OpenBSD, MacOS, and Solaris
             pkgutil)

             pkgs   A list of packages to maintain at the latest available
                    version.

                 mypkgs:
                   pkg.latest:
                     - pkgs:
                       - foo
                       - bar
                       - baz

             install_recommends
                    Whether to install the packages marked as recommended.
                    Default is True. Currently only works  with  APT-based
                    systems.

                    New in version 2015.5.0.

                 httpd:
                   pkg.latest:
                     - install_recommends: False

             only_upgrade
                    Only   upgrade  the  packages,  if  they  are  already
                    installed. Default is False. Currently only works with
                    APT-based systems.

                    New in version 2015.5.0.

                 httpd:
                   pkg.latest:
                     - only_upgrade: True

             NOTE:
                 If  this  parameter is set to True and the package is not
                 already installed, the state will fail.

          report_reboot_exit_codes
                 If the  installer  exits  with  a  recognized  exit  code
                 indicating that a reboot is required, the module function
                    win_system.set_reboot_required_witnessed

                 will  be  called,  preserving the knowledge of this event
                 for the remainder of the current boot  session.  For  the
                 time  being,  3010  is the only recognized exit code, but
                 this is subject to future refinement. The value  of  this
                 param  defaults  to True. This paramater has no effect on
                 non-Windows systems.

                 New in version 2016.11.0.

                    ms vcpp installed:
                      pkg.latest:
                        - name: ms-vcpp
                        - report_reboot_exit_codes: False

   salt.states.pkg.mod_aggregate(low, chunks, running)
          The mod_aggregate function which looks up all  packages  in  the
          available  low  chunks and merges them into a single pkgs ref in
          the present low data

   salt.states.pkg.mod_init(low)
          Set a flag to tell the install functions to refresh the  package
          database.   This  ensures that the package database is refreshed
          only once during a state run significantly improving  the  speed
          of package management during a state run.

          It  sets  a  flag  for  a  number  of  reasons, primarily due to
          timeline logic.  When originally setting up the mod_init for pkg
          a  number  of corner cases arose with different package managers
          and how they refresh package data.

          It also runs the "ex_mod_init" from the package  manager  module
          that  is currently loaded. The "ex_mod_init" is expected to work
          as a normal "mod_init" function.

          SEE ALSO:
             salt.modules.ebuild.ex_mod_init()

   salt.states.pkg.mod_watch(name, **kwargs)
          Install/reinstall a package based on a watch requisite

   salt.states.pkg.purged(name, version=None,  pkgs=None,  normalize=True,
   ignore_epoch=False, **kwargs)
          Verify  that  a  package  is not installed, calling pkg.purge if
          necessary to purge the package. All configuration files are also
          removed.

          name   The name of the package to be purged.

          version
                 The  version of the package that should be removed. Don't
                 do  anything  if  the  package  is  installed   with   an
                 unmatching version.

                 IMPORTANT:
                    As of version 2015.8.7, for distros which use yum/dnf,
                    packages which have a version  with  a  nonzero  epoch
                    (that  is, versions which start with a number followed
                    by a colon like in the example above)  must  have  the
                    epoch  included  when  specifying  the version number.
                    For example:

                        vim-enhanced:
                          pkg.installed:
                            - version: 2:7.4.160-1.el7

                    In version 2015.8.9, an ignore_epoch argument has been
                    added  to  pkg.installed,  pkg.removed, and pkg.purged
                    states, which causes the epoch to be disregarded  when
                    the  state  checks  to  see if the desired version was
                    installed. If ignore_epoch was not set  to  True,  and
                    instead  of 2:7.4.160-1.el7 a version of 7.4.160-1.el7
                    were used, this state would report success  since  the
                    actual  installed  version includes the epoch, and the
                    specified version would not match.

          normalize
                 True  Normalize  the  package  name   by   removing   the
                 architecture,  if  the  architecture  of  the  package is
                 different from the architecture of the operating  system.
                 The  ability  to  disable  this  behavior  is  useful for
                 poorly-created packages which include the architecture as
                 an  actual part of the name, such as kernel modules which
                 match a specific kernel version.

                 New in version 2015.8.0.

          ignore_epoch
                 False When a package version contains an  non-zero  epoch
                 (e.g.   1:3.14.159-2.el7,  and  a  specific  version of a
                 package is desired, set this option to True to ignore the
                 epoch  when  comparing  versions.  This  allows  for  the
                 following SLS to be used:

                    # Actual vim-enhanced version: 2:7.4.160-1.el7
                    vim-enhanced:
                      pkg.purged:
                        - version: 7.4.160-1.el7
                        - ignore_epoch: True

                 Without this option set to True in the above example, the
                 state  would  falsely  report  success  since  the actual
                 installed version is 2:7.4.160-1.el7. Alternatively, this
                 option  can  be left as False and the full version string
                 (with epoch) can be specified in the SLS file:

                    vim-enhanced:
                      pkg.purged:
                        - version: 2:7.4.160-1.el7

                 New in version 2015.8.9.

          Multiple Package Options:

          pkgs   A list of packages to purge. Must be passed as  a  python
                 list.  The  name parameter will be ignored if this option
                 is passed. It accepts version numbers as well.

          New in version 0.16.0.

   salt.states.pkg.removed(name, version=None, pkgs=None,  normalize=True,
   ignore_epoch=False, **kwargs)
          Verify  that  a  package is not installed, calling pkg.remove if
          necessary to remove the package.

          name   The name of the package to be removed.

          version
                 The version of the package that should be removed.  Don't
                 do   anything   if  the  package  is  installed  with  an
                 unmatching version.

                 IMPORTANT:
                    As of version 2015.8.7, for distros which use yum/dnf,
                    packages  which  have  a  version with a nonzero epoch
                    (that is, versions which start with a number  followed
                    by  a  colon  like in the example above) must have the
                    epoch included when  specifying  the  version  number.
                    For example:

                        vim-enhanced:
                          pkg.installed:
                            - version: 2:7.4.160-1.el7

                    In version 2015.8.9, an ignore_epoch argument has been
                    added to pkg.installed,  pkg.removed,  and  pkg.purged
                    states,  which causes the epoch to be disregarded when
                    the state checks to see if  the  desired  version  was
                    installed.  If  ignore_epoch  was not set to True, and
                    instead of 2:7.4.160-1.el7 a version of  7.4.160-1.el7
                    were  used,  this state would report success since the
                    actual installed version includes the epoch,  and  the
                    specified version would not match.

          normalize
                 True   Normalize   the   package  name  by  removing  the
                 architecture, if  the  architecture  of  the  package  is
                 different  from the architecture of the operating system.
                 The ability  to  disable  this  behavior  is  useful  for
                 poorly-created packages which include the architecture as
                 an actual part of the name, such as kernel modules  which
                 match a specific kernel version.

                 New in version 2015.8.0.

          ignore_epoch
                 False  When  a package version contains an non-zero epoch
                 (e.g.  1:3.14.159-2.el7, and  a  specific  version  of  a
                 package is desired, set this option to True to ignore the
                 epoch  when  comparing  versions.  This  allows  for  the
                 following SLS to be used:

                    # Actual vim-enhanced version: 2:7.4.160-1.el7
                    vim-enhanced:
                      pkg.removed:
                        - version: 7.4.160-1.el7
                        - ignore_epoch: True

                 Without this option set to True in the above example, the
                 state would  falsely  report  success  since  the  actual
                 installed version is 2:7.4.160-1.el7. Alternatively, this
                 option can be left as False and the full  version  string
                 (with epoch) can be specified in the SLS file:

                    vim-enhanced:
                      pkg.removed:
                        - version: 2:7.4.160-1.el7

                 New in version 2015.8.9.

          Multiple Package Options:

          pkgs   A  list of packages to remove. Must be passed as a python
                 list. The name parameter will be ignored if  this  option
                 is passed. It accepts version numbers as well.

                 New in version 0.16.0.

   salt.states.pkg.uptodate(name, refresh=False, **kwargs)
          New in version 2014.7.0.

          Verify that the system is completely up to date.

          name   The  name  has  no functional value and is only used as a
                 tracking reference

          refresh
                 refresh the package  database  before  checking  for  new
                 upgrades

          Parameters
                 cache_valid_time (str) --

                 This  parameter  sets  the  value  in seconds after which
                 cache marked as invalid, and cache update  is  necessary.
                 This overwrite refresh parameter default behavior.

                 In  this  case  cache_valid_time is set, refresh will not
                 take place for  amount  in  seconds  since  last  apt-get
                 update executed on the system.

                 NOTE:
                    This   parameter   available   only  on  Debian  based
                    distributions, and have no effect on the rest.

          kwargs Any keyword arguments to pass through to pkg.upgrade.

                 New in version 2015.5.0.

   salt.states.pkgbuild
   The pkgbuild state is the front of Salt package  building  backend.  It
   automatically builds DEB and RPM packages from specified sources

   New in version 2015.8.0.

      salt_2015.5.2:
        pkgbuild.built:
          - runas: thatch
          - results:
            - salt-2015.5.2-2.el7.centos.noarch.rpm
            - salt-api-2015.5.2-2.el7.centos.noarch.rpm
            - salt-cloud-2015.5.2-2.el7.centos.noarch.rpm
            - salt-master-2015.5.2-2.el7.centos.noarch.rpm
            - salt-minion-2015.5.2-2.el7.centos.noarch.rpm
            - salt-ssh-2015.5.2-2.el7.centos.noarch.rpm
            - salt-syndic-2015.5.2-2.el7.centos.noarch.rpm
          - dest_dir: /tmp/pkg
          - spec: salt://pkg/salt/spec/salt.spec
          - template: jinja
          - deps:
            - salt://pkg/salt/sources/required_dependency.rpm
          - tgt: epel-7-x86_64
          - sources:
            - salt://pkg/salt/sources/logrotate.salt
            - salt://pkg/salt/sources/README.fedora
            - salt://pkg/salt/sources/salt-2015.5.2.tar.gz
            - salt://pkg/salt/sources/salt-2015.5.2-tests.patch
            - salt://pkg/salt/sources/salt-api
            - salt://pkg/salt/sources/salt-api.service
            - salt://pkg/salt/sources/salt-master
            - salt://pkg/salt/sources/salt-master.service
            - salt://pkg/salt/sources/salt-minion
            - salt://pkg/salt/sources/salt-minion.service
            - salt://pkg/salt/sources/saltpkg.sls
            - salt://pkg/salt/sources/salt-syndic
            - salt://pkg/salt/sources/salt-syndic.service
            - salt://pkg/salt/sources/SaltTesting-2015.5.8.tar.gz
      /tmp/pkg:
        pkgbuild.repo

   salt.states.pkgbuild.built(name,  runas,  dest_dir, spec, sources, tgt,
   template=None,   deps=None,   env=None,   results=None,    force=False,
   saltenv='base', log_dir='/var/log/salt/pkgbuild')
          Ensure  that  the named package is built and exists in the named
          directory

          name   The name to track the build, the name value is  otherwise
                 unused

          runas  The user to run the build process as

          dest_dir
                 The directory on the minion to place the built package(s)

          spec   The location of the spec file (used for rpms)

          sources
                 The list of package sources

          tgt    The target platform to run the build on

          template
                 Run the spec file through a templating engine

                 Changed   in  version  2015.8.2:  This  argument  is  now
                 optional, allowing for no templating engine to be used if
                 none is desired.

          deps   Packages  required  to  ensure  that the named package is
                 built can be hosted on either the salt master  server  or
                 on  an  HTTP  or  FTP  server.   Both  HTTPS and HTTP are
                 supported as well as downloading directly from Amazon  S3
                 compatible  URLs  with  both pre-configured and automatic
                 IAM credentials

          env    A dictionary of environment variables to be set prior  to
                 execution.  Example:

                    - env:
                        DEB_BUILD_OPTIONS: 'nocheck'

                 WARNING:
                    The  above  illustrates  a common PyYAML pitfall, that
                    yes, no, on, off, true, and false are  all  loaded  as
                    boolean True and False values, and must be enclosed in
                    quotes to be used as strings. More info on  this  (and
                    other) PyYAML idiosyncrasies can be found here.

          results
                 The names of the expected rpms that will be built

          force  False  If  True,  packages  will  be  built  even if they
                 already exist  in  the  dest_dir.  This  is  useful  when
                 building  a  package  for  continuous  or nightly package
                 builds.

                 New in version 2015.8.2.

          saltenv
                 The saltenv to use for files  downloaded  from  the  salt
                 filesever

          log_dir
                 /var/log/salt/rpmbuild   Root  directory  for  log  files
                 created from the build. Logs will be organized by package
                 name,  version,  OS  release,  and CPU architecture under
                 this directory.

                 New in version 2015.8.2.

   salt.states.pkgbuild.repo(name,          keyid=None,          env=None,
   use_passphrase=False,  gnupghome='/etc/salt/gpgkeys',  runas='builder',
   timeout=15.0)
          Make a package repository and optionally sign  it  and  packages
          present

          The  name  is  directory to turn into a repo. This state is best
          used with onchanges linked to your package building states.

          name   The directory to  find  packages  that  will  be  in  the
                 repository

          keyid  Changed in version 2016.3.0.

                 Optional   Key   ID   to  use  in  signing  packages  and
                 repository.  Utilizes Public and Private keys  associated
                 with  keyid  which  have  been  loaded  into the minion's
                 Pillar data.

                 For example, contents from a Pillar data file with  named
                 Public and Private keys as follows:

                    gpg_pkg_priv_key: |
                      -----BEGIN PGP PRIVATE KEY BLOCK-----
                      Version: GnuPG v1

                      lQO+BFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      Ebe+8JCQTwqSXPRTzXmy/b5WXDeM79CkLWvuGpXFor76D+ECMRPv/rawukEcNptn
                      R5OmgHqvydEnO4pWbn8JzQO9YX/Us0SMHBVzLC8eIi5ZIopzalvX
                      =JvW8

                      -----END PGP PRIVATE KEY BLOCK-----
                    gpg_pkg_priv_keyname: gpg_pkg_key.pem

                    gpg_pkg_pub_key: |
                      -----BEGIN PGP PUBLIC KEY BLOCK-----
                      Version: GnuPG v1

                      mQENBFciIfQBCADAPCtzx7I5Rl32escCMZsPzaEKWe7bIX1em4KCKkBoX47IG54b
                      w82PCE8Y1jF/9Uk2m3RKVWp3YcLlc7Ap3gj6VO4ysvVz28UbnhPxsIkOlf2cq8qc
                      .
                      .
                      bYP7t5iwJmQzRMyFInYRt77wkJBPCpJc9FPNebL9vlZcN4zv0KQta+4alcWivvoP
                      4QIxE+/+trC6QRw2m2dHk6aAeq/J0Sc7ilZufwnNA71hf9SzRIwcFXMsLx4iLlki
                      inNqW9c=
                      =s1CX

                      -----END PGP PUBLIC KEY BLOCK-----
                    gpg_pkg_pub_keyname: gpg_pkg_key.pub

          env    Changed in version 2016.3.0.

                 A  dictionary  of environment variables to be utilized in
                 creating the repository. Example:

                    - env:
                        OPTIONS: 'ask-passphrase'

                 WARNING:
                    The above illustrates a common  PyYAML  pitfall,  that
                    yes,  no,  on,  off, true, and false are all loaded as
                    boolean True and False values, and must be enclosed in
                    quotes  to  be used as strings. More info on this (and
                    other) PyYAML idiosyncrasies can be found here.

                    Use  of  OPTIONS  on  some  platforms,  for   example:
                    ask-passphrase,  will  require gpg-agent or similar to
                    cache passphrases.

                 NOTE:
                    This  parameter   is   not   used   for   making   yum
                    repositories.

          use_passphrase
                 False New in version 2016.3.0.

                 Use a passphrase with the signing key presented in keyid.
                 Passphrase is received from Pillar data  which  could  be
                 passed  on  the  command  line with pillar parameter. For
                 example:

                    pillar='{ "gpg_passphrase" : "my_passphrase" }'

          gnupghome
                 /etc/salt/gpgkeys New in version 2016.3.0.

                 Location where GPG related files are  stored,  used  with
                 'keyid'

          runas  builder New in version 2016.3.0.

                 User  to  create  the  repository as, and optionally sign
                 packages.

                 NOTE:
                    Ensure the user has correct permissions to  any  files
                    and directories which are to be utilized.

          timeout
                 15.0 New in version 2016.3.4.

                 Timeout  in  seconds to wait for the prompt for inputting
                 the passphrase.

   salt.states.pkgng
   Manage package remote repo using FreeBSD pkgng
   Salt can manage the URL pkgng pulls packages from.  ATM the  state  and
   module are small so use cases are typically rather simple:

      pkgng_clients:
        pkgng.update_packaging_site:
          - name: "http://192.168.0.2"

   salt.states.pkgrepo
   Management of APT/YUM package repos
   Package repositories for APT-based and YUM-based distros can be managed
   with these states. Here is some example SLS:

      base:
        pkgrepo.managed:
          - humanname: CentOS-$releasever - Base
          - mirrorlist: http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
          - comments:
              - 'http://mirror.centos.org/centos/$releasever/os/$basearch/'
          - gpgcheck: 1
          - gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

      base:
        pkgrepo.managed:
          - humanname: Logstash PPA
          - name: deb http://ppa.launchpad.net/wolfnet/logstash/ubuntu precise main
          - dist: precise
          - file: /etc/apt/sources.list.d/logstash.list
          - keyid: 28B04E4A
          - keyserver: keyserver.ubuntu.com
          - require_in:
            - pkg: logstash

        pkg.latest:
          - name: logstash
          - refresh: True

      base:
        pkgrepo.managed:
          - humanname: deb-multimedia
          - name: deb http://www.deb-multimedia.org stable main
          - file: /etc/apt/sources.list.d/deb-multimedia.list
          - key_url: salt://deb-multimedia/files/marillat.pub

      base:
        pkgrepo.managed:
          - humanname: Google Chrome
          - name: deb http://dl.google.com/linux/chrome/deb/ stable main
          - dist: stable
          - file: /etc/apt/sources.list.d/chrome-browser.list
          - require_in:
            - pkg: google-chrome-stable
          - gpgcheck: 1
          - key_url: https://dl-ssl.google.com/linux/linux_signing_key.pub

      base:
        pkgrepo.managed:
          - ppa: wolfnet/logstash
        pkg.latest:
          - name: logstash
          - refresh: True

   NOTE:
      On Ubuntu systems, the python-software-properties package should  be
      installed  for  better support of PPA repositories. To check if this
      package is installed, run dpkg -l python-software-properties.

      Also,   some   Ubuntu    releases    have    a    bug    in    their
      python-software-properties  package, a missing dependency on pycurl,
      so python-pycurl will need to be manually installed  if  it  is  not
      present once python-software-properties is installed.

      On  Ubuntu  & Debian systems, the `python-apt package is required to
      be installed.  To check if this package is installed,  run  dpkg  -l
      python-software-properties.   python-apt  will  need  to be manually
      installed if it is not present.

   salt.states.pkgrepo.absent(name, **kwargs)
          This function deletes the specified repo on the  system,  if  it
          exists. It is essentially a wrapper around pkg.del_repo.

          name   The  name of the package repo, as it would be referred to
                 when running the regular package manager commands.

          UBUNTU-SPECIFIC OPTIONS

          ppa    On Ubuntu, you can take  advantage  of  Personal  Package
                 Archives  on  Launchpad simply by specifying the user and
                 archive name.

                    logstash-ppa:
                      pkgrepo.absent:
                        - ppa: wolfnet/logstash

          ppa_auth
                 For Ubuntu PPAs there can be private  PPAs  that  require
                 authentication    to   access.   For   these   PPAs   the
                 username/password can be specified.  This is required for
                 matching  if  the name format uses the ppa: specifier and
                 is private (requires username/password to  access,  which
                 is encoded in the URI).

                    logstash-ppa:
                      pkgrepo.absent:
                        - ppa: wolfnet/logstash
                        - ppa_auth: username:password

          keyid  If  passed,  then the GPG key corresponding to the passed
                 KeyID will also be removed.

          keyid_ppa
                 False If set to True, the GPG key's ID will be looked  up
                 from   ppa.launchpad.net   and  removed,  and  the  keyid
                 argument will be ignored.

                 NOTE:
                    This  option  will  be  disregarded  unless  the   ppa
                    argument is present.

   salt.states.pkgrepo.managed(name, ppa=None, **kwargs)
          This  state  manages  software  package repositories. Currently,
          yum, apt, and zypper repositories are supported.

          YUM OR ZYPPER-BASED SYSTEMS

          NOTE:
             One of baseurl or mirrorlist below is required. Additionally,
             note  that  this  state  is not presently capable of managing
             more than one repo in a single repo file, so each instance of
             this  state  will  manage  a  single repo file containing the
             configuration for a single repo.

          name   This value will be used in two ways: Firstly, it will  be
                 the  repo  ID,  as  seen  in the entry in square brackets
                 (e.g. [foo]) for a given repo. Secondly, it will  be  the
                 name  of  the  file  as  stored in /etc/yum.repos.d (e.g.
                 /etc/yum.repos.d/foo.conf).

          humanname
                 This is used as the "name" value  in  the  repo  file  in
                 /etc/yum.repos.d/    (or   /etc/zypp/repos.d   for   SUSE
                 distros).

          baseurl
                 The URL to a yum repository

          mirrorlist
                 A URL which points to a file containing a  collection  of
                 baseurls

          comments
                 Sometimes  you want to supply additional information, but
                 not as enabled configuration. Anything supplied for  this
                 list  will  be  saved  in  the  repo configuration with a
                 comment marker (#) in front.

          Additional configuration values seen in yum repo files, such  as
          gpgkey  or  gpgcheck,  will be used directly as key-value pairs.
          For example:

             foo:
               pkgrepo.managed:
                 - humanname: Personal repo for foo
                 - baseurl: https://mydomain.tld/repo/foo/$releasever/$basearch
                 - gpgkey: file:///etc/pki/rpm-gpg/foo-signing-key
                 - gpgcheck: 1

          APT-BASED SYSTEMS

          ppa    On Ubuntu, you can take  advantage  of  Personal  Package
                 Archives  on  Launchpad simply by specifying the user and
                 archive name. The keyid will be  queried  from  launchpad
                 and   everything  else  is  set  automatically.  You  can
                 override any of the below settings by simply setting them
                 as you would normally. For example:

                    logstash-ppa:
                      pkgrepo.managed:
                        - ppa: wolfnet/logstash

          ppa_auth
                 For  Ubuntu  PPAs  there can be private PPAs that require
                 authentication   to   access.   For   these   PPAs    the
                 username/password  can  be  passed as an HTTP Basic style
                 username/password combination.

                    logstash-ppa:
                      pkgrepo.managed:
                        - ppa: wolfnet/logstash
                        - ppa_auth: username:password

          name   On apt-based systems this must be the complete  entry  as
                 it would be seen in the sources.list file.  This can have
                 a limited subset of components (i.e. 'main') which can be
                 added/modified with the comps option.

                    precise-repo:
                      pkgrepo.managed:
                        - name: deb http://us.archive.ubuntu.com/ubuntu precise main

                 NOTE:
                    The  above  example is intended as a more readable way
                    of configuring  the  SLS,  it  is  equivalent  to  the
                    following:

                        'deb http://us.archive.ubuntu.com/ubuntu precise main':
                          pkgrepo.managed

          disabled
                 Toggles  whether  or  not  the repo is used for resolving
                 dependencies and/or installing packages.

          comps  On apt-based systems, comps dictate the types of packages
                 to  be installed from the repository (e.g. main, nonfree,
                 ...).   For  purposes  of  this,  comps   should   be   a
                 comma-separated list.

          file   The  filename  for  the  .list  that  the  repository  is
                 configured in.  It is important to include the  full-path
                 AND  make sure it is in a directory that APT will look in
                 when handling packages

          dist   This dictates the release  of  the  distro  the  packages
                 should  be  built  for.   (e.g. unstable). This option is
                 rarely needed.

          keyid  The KeyID of the GPG key to  install.  This  option  also
                 requires the keyserver option to be set.

          keyserver
                 This  is  the  name of the keyserver to retrieve gpg keys
                 from.  The keyid option must also be set for this  option
                 to work.

          key_url
                 URL  to  retrieve  a  GPG  key  from. Allows the usage of
                 http://, https:// as well as salt://.

                 NOTE:
                    Use either keyid/keyserver or key_url, but not both.

          consolidate
                 If  set  to  true,  this  will  consolidate  all  sources
                 definitions  to  the  sources.list  file, cleanup the now
                 unused files, consolidate components (e.g. main) for  the
                 same  URI,  type,  and architecture to a single line, and
                 finally remove comments from the sources.list file.   The
                 consolidate  will  run every time the state is processed.
                 The option only needs to be set on one  repo  managed  by
                 salt to take effect.

          clean_file
                 If  set to true, empty file before config repo, dangerous
                 if use multiple sources in one file.

                 New in version 2015.8.0.

          refresh_db
                 If set to false this will skip refreshing the apt package
                 database on debian based systems.

          require_in
                 Set  this  to  a  list  of pkg.installed or pkg.latest to
                 trigger the running of apt-get update prior to attempting
                 to  install  these packages. Setting a require in the pkg
                 will not work for this.

   salt.states.portage_config
   Management of Portage package configuration on Gentoo
   A state module to manage Portage configuration on Gentoo

      salt:
          portage_config.flags:
              - use:
                  - openssl

   salt.states.portage_config.flags(name, use=None,  accept_keywords=None,
   env=None, license=None, properties=None, unmask=False, mask=False)
          Enforce the given flags on the given package or DEPEND atom.

          WARNING:
             In  most cases, the affected package(s) need to be rebuilt in
             order to apply the changes.

          name   The name of the package or its DEPEND atom

          use    A list of USE flags

          accept_keywords
                 A list of keywords to accept. ~ARCH  means  current  host
                 arch, and will be translated into a line without keywords

          env    A list of environment files

          license
                 A list of accepted licenses

          properties
                 A list of additional properties

          unmask A boolean to unmask the package

          mask   A boolean to mask the package

   salt.states.portage_config.mod_init(low)
          Enforce a nice structure on the configuration files.

   salt.states.ports
   Manage software from FreeBSD ports

   New in version 2014.1.0.

   NOTE:
      It   may  be  helpful  to  use  a  higher  timeout  when  running  a
      ports.installed state, since compiling the port  may  exceed  Salt's
      timeout.

          salt -t 1200 '*' state.highstate

   salt.states.ports.installed(name, options=None)
          Verify  that  the  desired  port  is  installed, and that it was
          compiled with the desired options.

          options
                 Make sure that the desired non-default options are set

                 WARNING:
                    Any build options not passed here assume  the  default
                    values for the port, and are not just differences from
                    the existing  cached  options  from  a  previous  make
                    config.

          Example usage:

             security/nmap:
               ports.installed:
                 - options:
                   - IPV6: off

   salt.states.postgres_cluster module
   Management of PostgreSQL clusters
   The   postgres_cluster  state  module  is  used  to  manage  PostgreSQL
   clusters.  Clusters can be set as either absent or present

      create cluster 9.3 main:
        postgres_cluster.present:
            - name: 'main'
            - version: '9.3'

   salt.states.postgres_cluster.absent(version, name)
          Ensure that the named cluster is absent

          version
                 Version of the postgresql server of the cluster to remove

          name   The name of the cluster to remove

                 New in version 2015.XX.

   salt.states.postgres_cluster.present(version,     name,      port=None,
   encoding=None, locale=None, datadir=None)
          Ensure  that  the  named  cluster  is present with the specified
          properties.  For more information about all of these options see
          man pg_createcluster(1)

          version
                 Version of the postgresql cluster

          name   The name of the cluster

          port   Cluster port

          encoding
                 The character encoding scheme to be used in this database

          locale Locale with which to create cluster

          datadir
                 Where the cluster is stored

                 New in version 2015.XX.

   salt.states.postgres_database
   Management of PostgreSQL databases
   The  postgres_database  module  is  used  to create and manage Postgres
   databases.  Databases can be set as either absent or present

      frank:
        postgres_database.present

   salt.states.postgres_database.absent(name,                   user=None,
   maintenance_db=None,   db_password=None,   db_host=None,  db_port=None,
   db_user=None)
          Ensure that the named database is absent

          name   The name of the database to remove

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

          user   System user all operations should be performed on  behalf
                 of

                 New in version 0.17.0.

   salt.states.postgres_database.present(name,            tablespace=None,
   encoding=None,     lc_collate=None,     lc_ctype=None,      owner=None,
   owner_recurse=False,   template=None,  user=None,  maintenance_db=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure that the named database is  present  with  the  specified
          properties.  For more information about all of these options see
          man createdb(1)

          name   The name of the database to manage

          tablespace
                 Default tablespace for the database

          encoding
                 The character encoding scheme to be used in this database

          lc_collate
                 The LC_COLLATE setting to be used in this database

          lc_ctype
                 The LC_CTYPE setting to be used in this database

          owner  The username of the database owner

          owner_recurse
                 Recurse owner change to all relations in the database

          template
                 The template database from which to build this database

          user   System user all operations should be performed on  behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

                 New in version 0.17.0.

   salt.states.postgres_extension
   Management of PostgreSQL extensions
   A module used to install and manage PostgreSQL extensions.

      adminpack:
        postgres_extension.present

   New in version 2014.7.0.

   salt.states.postgres_extension.absent(name,             if_exists=None,
   restrict=None,    cascade=None,     user=None,     maintenance_db=None,
   db_user=None, db_password=None, db_host=None, db_port=None)
          Ensure that the named extension is absent.

          name   Extension name of the extension to remove

          if_exists
                 Add if exist slug

          restrict
                 Add restrict slug

          cascade
                 Drop on cascade

          user   System  user all operations should be performed on behalf
                 of

          maintenance_db
                 Database to act on

          db_user
                 Database username if different from config or default

          db_password
                 User password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_extension.present(name,        if_not_exists=None,
   schema=None,     ext_version=None,     from_version=None,    user=None,
   maintenance_db=None,  db_user=None,   db_password=None,   db_host=None,
   db_port=None)
          Ensure that the named extension is present.

          NOTE:
             Before  you  can  use  the  state to load an extension into a
             database, the extension's supporting files  must  be  already
             installed.

          For  more  information  about  all  of  these options see CREATE
          EXTENSION SQL command reference in the PostgreSQL documentation.

          name   The name of the extension to be installed

          if_not_exists
                 Add an IF NOT EXISTS parameter to the DDL statement

          schema Schema to install the extension into

          ext_version
                 Version to install

          from_version
                 Old extension version if already installed

          user   System user all operations should be performed on  behalf
                 of

          maintenance_db
                 Database to act on

          db_user
                 Database username if different from config or default

          db_password
                 User password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_group
   Management of PostgreSQL groups (roles)
   The postgres_group module is used to create and manage Postgres groups.

      frank:
        postgres_group.present

   salt.states.postgres_group.absent(name, user=None, maintenance_db=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure that the named group is absent

          name   The groupname of the group to remove

          user   System user all operations should be performed on  behalf
                 of

                 New in version 0.17.0.

          db_user
                 database username if different from config or defaul

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_group.present(name,                 createdb=None,
   createroles=None,  createuser=None,   encrypted=None,   superuser=None,
   inherit=None,      login=None,     replication=None,     password=None,
   refresh_password=None,  groups=None,  user=None,   maintenance_db=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure  that  the  named  group  is  present  with the specified
          privileges Please note that the user/group notion in  postgresql
          is  just  abstract,  we  have  roles, where users can be seen as
          roles with the LOGIN privilege and groups the others.

          name   The name of the group to manage

          createdb
                 Is the group allowed to create databases?

          createroles
                 Is the group allowed to create other roles/users

          createuser
                 Alias to create roles,  and  history  problem,  in  pgsql
                 normally createuser == superuser

          encrypted
                 Should the password be encrypted in the system catalog?

          login  Should the group have login perm

          inherit
                 Should the group inherit permissions

          superuser
                 Should the new group be a "superuser"

          replication
                 Should  the  new  group  be allowed to initiate streaming
                 replication

          password
                 The group's password It can be either a plain string or a
                 md5 postgresql hashed password:

                    'md5{MD5OF({password}{role}}'

                 If  encrypted  is  None  or  True,  the  password will be
                 automatically encrypted to the previous format if  it  is
                 not already done.

          refresh_password
                 Password refresh flag

                 Boolean   attribute   to   specify  whether  to  password
                 comparison check should be performed.

                 If  refresh_password  is  True,  the  password  will   be
                 automatically   updated  without  extra  password  change
                 check.

                 This  behaviour  makes  it   possible   to   execute   in
                 environments  without  superuser  access  available, e.g.
                 Amazon RDS for PostgreSQL

          groups A string of comma separated groups the group should be in

          user   System user all operations should be performed on  behalf
                 of

                 New in version 0.17.0.

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_initdb
   Initialization of PostgreSQL data directory
   The  postgres_initdb  module  is used to initialize the postgresql data
   directory.

   New in version 2016.3.0.

      pgsql-data-dir:
        postgres_initdb.present:
          - name: /var/lib/pgsql/data
          - auth: password
          - user: postgres
          - password: strong_password
          - encoding: UTF8
          - locale: C
          - runas: postgres

   salt.states.postgres_initdb.present(name,   user=None,   password=None,
   auth='password', encoding='UTF8', locale=None, runas=None)
          Initialize the PostgreSQL data directory

          name   The name of the directory to initialize

          user   The database superuser name

          password
                 The password to set for the postgres user

          auth   The default authentication method for local connections

          encoding
                 The default encoding for new databases

          locale The default locale for new databases

          runas  The  system  user  the  operation  should be performed on
                 behalf of

   salt.states.postgres_language
   Management of PostgreSQL languages
   The postgres_language module is used  to  create  and  manage  Postgres
   languages.  Languages can be set as either absent or present

   New in version 2016.3.0.

      plpgsql:
        postgres_language.present:
          - maintenance_db: testdb

      plpgsql:
        postgres_language.absent:
          - maintenance_db: testdb

   salt.states.postgres_language.absent(name,  maintenance_db,  user=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure  that  a  named  language  is  absent  in  the  specified
          database.

          name   The name of the language to remove

          maintenance_db
                 The  name  of the database in which the language is to be
                 installed

          user   System user all operations should be performed on  behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_language.present(name,  maintenance_db, user=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure that  a  named  language  is  present  in  the  specified
          database.

          name   The name of the language to install

          maintenance_db
                 The  name  of the database in which the language is to be
                 installed

          user   System user all operations should be performed on  behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_privileges
   Management of PostgreSQL Privileges
   The  postgres_privileges  module is used to manage Postgres privileges.
   Privileges can be set as either absent or present.

   Privileges can be set on the following database object types:

   * database

   * schema

   * tablespace

   * table

   * sequence

   * language

   * group

   Setting the grant option is supported as well.

   New in version 2016.3.0.

      baruwa:
        postgres_privileges.present:
          - object_name: awl
          - object_type: table
          - privileges:
            - SELECT
            - INSERT
            - DELETE
          - grant_option: False
          - prepend: public
          - maintenance_db: testdb

      andrew:
        postgres_privileges.present:
          - object_name: admins
          - object_type: group
          - grant_option: False
          - maintenance_db: testdb

      baruwa:
        postgres_privileges.absent:
          - object_name: awl
          - object_type: table
          - privileges:
            - SELECT
            - INSERT
            - DELETE
          - prepend: public
          - maintenance_db: testdb

      andrew:
        postgres_privileges.absent:
          - object_name: admins
          - object_type: group
          - maintenance_db: testdb

   salt.states.postgres_privileges.absent(name, object_name,  object_type,
   privileges=None,   prepend='public',   maintenance_db=None,  user=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Revoke the requested privilege(s) on the specificed object(s)

          name   Name of the role whose privileges should be revoked

          object_name
                 Name of the object on which the revoke is to be performed

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          privileges
                 Comma separated list of privileges to  revoke,  from  the
                 list below:

                 * INSERT

                 * CREATE

                 * TRUNCATE

                 * CONNECT

                 * TRIGGER

                 * SELECT

                 * USAGE

                 * TEMPORARY

                 * UPDATE

                 * EXECUTE

                 * REFERENCES

                 * DELETE

                 * ALL

                 note   privileges  should  not be set when revoking group
                        membership

          prepend
                 Table and Sequence object types live under  a  schema  so
                 this  should  be  provided if the object is not under the
                 default public schema

          maintenance_db
                 The name of the database in which the language is  to  be
                 installed

          user   System  user all operations should be performed on behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_privileges.present(name, object_name, object_type,
   privileges=None,          grant_option=None,          prepend='public',
   maintenance_db=None,   user=None,    db_password=None,    db_host=None,
   db_port=None, db_user=None)
          Grant  the  requested  privilege(s) on the specified object to a
          role

          name   Name of the role to which privileges should be granted

          object_name
                 Name of the object on which the grant is to be performed.
                 'ALL'  may  be  used  for  objects  of  type  'table'  or
                 'sequence'.

          object_type
                 The object type, which can be one of the following:

                 * table

                 * sequence

                 * schema

                 * tablespace

                 * language

                 * database

                 * group

          privileges
                 List of privileges to grant, from the list below:

                 * INSERT

                 * CREATE

                 * TRUNCATE

                 * CONNECT

                 * TRIGGER

                 * SELECT

                 * USAGE

                 * TEMPORARY

                 * UPDATE

                 * EXECUTE

                 * REFERENCES

                 * DELETE

                 * ALL

                 note   privileges should not be set when  granting  group
                        membership

          grant_option
                 If  grant_option  is  set  to  True, the recipient of the
                 privilege can in turn grant it to others

          prepend
                 Table and Sequence object types live under  a  schema  so
                 this  should  be  provided if the object is not under the
                 default public schema

          maintenance_db
                 The name of the database in which the language is  to  be
                 installed

          user   System  user all operations should be performed on behalf
                 of

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_schema
   Management of PostgreSQL schemas
   The postgres_schemas module is  used  to  create  and  manage  Postgres
   schemas.

      public:
        postgres_schema.present 'dbname' 'name'

   salt.states.postgres_schema.absent(dbname,      name,     db_user=None,
   db_password=None, db_host=None, db_port=None)
          Ensure that the named schema is absent.

          dbname The database's name will work on

          name   The name of the schema to remove

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_schema.present(dbname,      name,      owner=None,
   db_user=None, db_password=None, db_host=None, db_port=None)
          Ensure that the named schema is present in the database.

          dbname The database's name will work on

          name   The name of the schema to manage

          owner  The database user that will be the owner of the schema

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_tablespace
   Management of PostgreSQL tablespace
   A module used to create and manage PostgreSQL tablespaces.

      ssd-tablespace:
        postgres_tablespace.present:
          - name: indexes
          - directory: /mnt/ssd-data

   New in version 2015.8.0.

   salt.states.postgres_tablespace.absent(name,                 user=None,
   maintenance_db=None,  db_user=None,   db_password=None,   db_host=None,
   db_port=None)
          Ensure that the named tablespace is absent.

          name   The name of the tablespace to remove

          user   System  user all operations should be performed on behalf
                 of

          maintenance_db
                 Database to act on

          db_user
                 Database username if different from config or defaul

          db_password
                 User password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_tablespace.present(name, directory,  options=None,
   owner=None,     user=None,    maintenance_db=None,    db_password=None,
   db_host=None, db_port=None, db_user=None)
          Ensure that the named tablespace is present with  the  specified
          properties.  For more information about all of these options see
          man

          ``
          create_tablespace``(7).

          name   The name of the tablespace to create/manage.

          directory
                 The directory where the tablespace will be located,  must
                 already exist

          options
                 A  dictionary  of  options to specify for the tablespace.
                 Currently, the  only  tablespace  options  supported  are
                 seq_page_cost  and  random_page_cost.  Default values are
                 shown in the example below:

                    my_space:
                      postgres_tablespace.present:
                        - directory: /srv/my_tablespace
                        - options:
                            seq_page_cost: 1.0
                            random_page_cost: 4.0

          owner  The  database  user  that  will  be  the  owner  of   the
                 tablespace.   Defaults  to the user executing the command
                 (i.e. the user option)

          user   System user all operations should be performed on  behalf
                 of

          maintenance_db
                 Database to act on

          db_user
                 Database username if different from config or default

          db_password
                 User password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_user
   Management of PostgreSQL users (roles)
   The postgres_users module is used to create and manage Postgres users.

      frank:
        postgres_user.present

   salt.states.postgres_user.absent(name,  user=None, maintenance_db=None,
   db_password=None, db_host=None, db_port=None, db_user=None)
          Ensure that the named user is absent

          name   The username of the user to remove

          user   System user all operations should be performed on  behalf
                 of

                 New in version 0.17.0.

          db_user
                 database username if different from config or default

          db_password
                 user password if any password for a specified user

          db_host
                 Database host if different from config or default

          db_port
                 Database port if different from config or default

   salt.states.postgres_user.present(name,                  createdb=None,
   createroles=None,  createuser=None,   encrypted=None,   superuser=None,
   replication=None,      inherit=None,     login=None,     password=None,
   default_password=None, refresh_password=None,  groups=None,  user=None,
   maintenance_db=None,   db_password=None,   db_host=None,  db_port=None,
   db_user=None)
          Ensure that  the  named  user  is  present  with  the  specified
          privileges  Please note that the user/group notion in postgresql
          is just abstract, we have roles, where users  can  be  seens  as
          roles with the LOGIN privilege and groups the others.

          name   The name of the system user to manage.

          createdb
                 Is the user allowed to create databases?

          createroles
                 Is the user allowed to create other users?

          createuser
                 Alias to create roles

          encrypted
                 Should the password be encrypted in the system catalog?

          login  Should the group have login perm

          inherit
                 Should the group inherit permissions

          superuser
                 Should the new user be a "superuser"

          replication
                 Should  the  new  user  be  allowed to initiate streaming
                 replication

          password
                 The system user's password. It  can  be  either  a  plain
                 string or a md5 postgresql hashed password:

                    'md5{MD5OF({password}{role}}'

                 If  encrypted  is  None  or  True,  the  password will be
                 automatically encrypted to the previous format if  it  is
                 not already done.

          default_passwoord
                 The  password  used  only  when creating the user, unless
                 password is set.

                 New in version 2016.3.0.

          refresh_password
                 Password refresh flag

                 Boolean  attribute  to  specify   whether   to   password
                 comparison check should be performed.

                 If   refresh_password  is  True,  the  password  will  be
                 automatically  updated  without  extra  password   change
                 check.

                 This   behaviour   makes   it   possible  to  execute  in
                 environments without  superuser  access  available,  e.g.
                 Amazon RDS for PostgreSQL

          groups A string of comma separated groups the user should be in

          user   System  user all operations should be performed on behalf
                 of

                 New in version 0.17.0.

          db_user
                 Postres database username, if different  from  config  or
                 default.

          db_password
                 Postgres   user's   password,  if  any  password,  for  a
                 specified db_user.

          db_host
                 Postgres database  host,  if  different  from  config  or
                 default.

          db_port
                 Postgres  database  port,  if  different  from  config or
                 default.

   salt.states.powerpath
   Powerpath configuration support
   Allows   configuration    of    EMC    Powerpath.     Currently    only
   addition/deletion of licenses is supported.

      key:
        powerpath.license_present: []

   salt.states.powerpath.license_absent(name)
          Ensures  that  the  specified PowerPath license key is absent on
          the host.

          name   The license key to ensure is absent

   salt.states.powerpath.license_present(name)
          Ensures that the specified PowerPath license key is  present  on
          the host.

          name   The license key to ensure is present

   salt.states.probes
   Network Probes
   Configure  RPM  (JunOS)/SLA  (Cisco)  probes  on  the device via NAPALM
   proxy.

   codeauthor
          Mircea  Ulinic  <[email protected]>  &  Jerome   Fleury   <
          [email protected]>

   maturity
          new

   depends
          napalm

   platform
          unix

   Dependencies
   * napalm probes management module

   salt.states.probes.managed(name, probes, defaults=None)
          Ensure  the  networks  device  is configured as specified in the
          state SLS file.  Probes not specified  will  be  removed,  while
          probes not confiured as expected will trigger config updates.

          Parameters
                 probes -- Defines the probes as expected to be configured
                 on the device.

          In order to ease the configuration and avoid repeating the  same
          parameters  for each probe, the next parameter (defaults) can be
          used,  providing  common  characteristics.    :param   defaults:
          Specifies common parameters for the probes.

          SLS Example:

             rpmprobes:
                 probes.managed:
                     - probes:
                         probe_name1:
                             probe1_test1:
                                 source: 192.168.0.2
                                 target: 192.168.0.1
                             probe1_test2:
                                 target: 172.17.17.1
                             probe1_test3:
                                 target: 8.8.8.8
                                 probe_type: http-ping
                         probe_name2:
                             probe2_test1:
                                 test_interval: 100
                     - defaults:
                         target: 10.10.10.10
                         probe_count: 15
                         test_interval: 3
                         probe_type: icmp-ping

          In  the  probes  configuration,  the only mandatory attribute is
          target (specified either in probes configuration, either in  the
          defaults  dictionary).   All  the  other parameters will use the
          operating system defaults, if not provided:

          *

            source: Specifies the source IP Address to be used during  the
            tests.
                   If not specified will use the IP Address of the logical
                   interface loopback0.

          * target:           Destination IP Address.

          * probe_count:      Total number of  probes  per  test  (1..15).
            System defaults: 1 on both JunOS & Cisco.

          * probe_interval:    Delay  between  tests  (0..86400  seconds).
            System defaults: 3 on JunOS, 5 on Cisco.

          * probe_type:       Probe request type. Available options:

               * icmp-ping

               * tcp-ping

               * udp-ping

          Using the example configuration above, after running the  state,
          on  the  device  will be configured 4 probes, with the following
          properties:

             probe_name1:
                 probe1_test1:
                     source: 192.168.0.2
                     target: 192.168.0.1
                     probe_count: 15
                     test_interval: 3
                     probe_type: icmp-ping
                 probe1_test2:
                     target: 172.17.17.1
                     probe_count: 15
                     test_interval: 3
                     probe_type: icmp-ping
                 probe1_test3:
                     target: 8.8.8.8
                     probe_count: 15
                     test_interval: 3
                     probe_type: http-ping
             probe_name2:
                 probe2_test1:
                     target: 10.10.10.10
                     probe_count: 15
                     test_interval: 3
                     probe_type: icmp-ping

   salt.states.process
   Process Management
   Ensure a process matching a given pattern is absent.

      httpd-absent:
        process.absent:
          - name: apache2

   salt.states.process.absent(name, user=None, signal=None)
          Ensures that the named command is not running.

          name   The pattern to match.

          user   The user process belongs

          signal Signal to send to the process(es).

   salt.states.pushover
   Send a message to PushOver
   This state is useful for sending  messages  to  PushOver  during  state
   runs.

   New in version 2015.5.0.

      pushover-message:
        pushover.post_message:
          - user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          - token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          - title: Salt Returner
          - device: phone
          - priority: -1
          - expire: 3600
          - retry: 5
          - message: 'This state was executed successfully.'

   The api key can be specified in the master or minion configuration like
   below:

      pushover:
             token: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.states.pushover.post_message(name,     user=None,     device=None,
   message=None,   title=None,   priority=None,  expire=None,  retry=None,
   sound=None, api_version=1, token=None)
          Send a message to a PushOver channel.

             pushover-message:
               pushover.post_message:
                 - user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
                 - token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
                 - title: Salt Returner
                 - device: phone
                 - priority: -1
                 - expire: 3600
                 - retry: 5

          The following parameters are required:

          name   The unique name for this event.

          user   The user or group of users to send the message  to.  Must
                 be ID of user, not name or email address.

          message
                 The message that is to be sent to the PushOver channel.

          The following parameters are optional:

          title  The title to use for the message.

          device The device for the user to send the message to.

          priority
                 The priority for the message.

          expire The  message  should  expire  after  specified  amount of
                 seconds.

          retry  The message should be resent this many times.

          token  The token for PushOver to use for authentication, if  not
                 specified  in  the  configuration  options  of  master or
                 minion.

   salt.states.pyenv
   Managing python installations with pyenv
   This module is used to install and  manage  python  installations  with
   pyenv.  Different versions of python can be installed, and uninstalled.
   pyenv will be installed automatically the first time it is  needed  and
   can  be  updated  later.  This  module  will  not automatically install
   packages which pyenv will need to compile the versions of python.

   If pyenv is run  as  the  root  user  then  it  will  be  installed  to
   /usr/local/pyenv,  otherwise it will be installed to the users ~/.pyenv
   directory. To make pyenv available in the shell you may need to add the
   pyenv/shims  and  pyenv/bin  directories  to the users PATH. If you are
   installing as root and want other users to be able to access pyenv then
   you will need to add pyenv_ROOT to their environment.

   This is how a state configuration could look like:

      pyenv-deps:
        pkg.installed:
          - pkgs:
            - make
            - build-essential
            - libssl-dev
            - zlib1g-dev
            - libbz2-dev
            - libreadline-dev
            - libsqlite3-dev
            - wget
            - curl
            - llvm
      python-2.6:
        pyenv.absent:
          - require:
            - pkg: pyenv-deps

      python-2.7.6:
        pyenv.installed:
          - default: True
          - require:
            - pkg: pyenv-deps

   NOTE:
      Git  needs  to be installed and available via PATH if pyenv is to be
      installed automatically by the module.

   salt.states.pyenv.absent(name, user=None)
          Verify that the specified python is not  installed  with  pyenv.
          pyenv is installed if necessary.

          name   The version of python to uninstall

          user: None
                 The user to run pyenv as.

                 New in version 0.17.0.

          New in version 0.16.0.

   salt.states.pyenv.install_pyenv(name, user=None)
          Install  pyenv  if not installed. Allows you to require pyenv be
          installed prior to installing the plugins. Useful if you want to
          install  pyenv plugins via the git or file modules and need them
          installed before installing any rubies.

          Use the pyenv.root configuration option  to  set  the  path  for
          pyenv  if  you  want a system wide install that is not in a user
          home dir.

          user: None
                 The user to run pyenv as.

   salt.states.pyenv.installed(name, default=False, user=None)
          Verify that the specified python is installed with pyenv.  pyenv
          is installed if necessary.

          name   The version of python to install

          default
                 False Whether to make this python the default.

          user: None
                 The user to run pyenv as.

                 New in version 0.17.0.

          New in version 0.16.0.

   salt.states.pyrax_queues
   Manage Rackspace Queues
   New in version 2015.5.0.

   Create  and destroy Rackspace queues. Be aware that this interacts with
   Rackspace's services, and so may incur charges.

   This module uses pyrax, which can be installed  via  package,  or  pip.
   This  module  is greatly inspired by boto_* modules from SaltStack code
   source.

      myqueue:
          pyrax_queues.present:
              - provider: my-pyrax

      myqueue:
          pyrax_queues.absent:
              - provider: my-pyrax

   salt.states.pyrax_queues.absent(name, provider)
          Ensure the named Rackspace queue is deleted.

          name   Name of the Rackspace queue.

          provider
                 Salt Cloud provider

   salt.states.pyrax_queues.present(name, provider)
          Ensure the RackSpace queue exists.

          name   Name of the Rackspace queue.

          provider
                 Salt Cloud Provider

   salt.states.quota
   Management of POSIX Quotas
   The quota can be managed for the system:

      /:
        quota.mode:
          mode: off
          quotatype: user

   salt.states.quota.mode(name, mode, quotatype)
          Set the quota for the system

          name   The filesystem to set the quota mode on

          mode   Whether the quota system is on or off

          quotatype
                 Must be user or group

   salt.states.rabbitmq_cluster
   Manage RabbitMQ Clusters
   Example:

      [email protected]:
        rabbitmq_cluster.join:
          - user: rabbit
          - host: rabbit.example.com

   salt.states.rabbitmq_cluster.join(name,      host,       user='rabbit',
   ram_node=None, runas='root')
          This function is an alias of joined.
             Ensure  the  current  node  joined  to  a  cluster  with node
             user@host

             name   Irrelevant, not used (recommended: user@host)

             user   The user of node to join to (default: rabbit)

             host   The host of node to join to

             ram_node
                    Join node as a RAM node

             runas  The user to run the rabbitmq command as

   salt.states.rabbitmq_cluster.joined(name,     host,      user='rabbit',
   ram_node=None, runas='root')
          Ensure the current node joined to a cluster with node user@host

          name   Irrelevant, not used (recommended: user@host)

          user   The user of node to join to (default: rabbit)

          host   The host of node to join to

          ram_node
                 Join node as a RAM node

          runas  The user to run the rabbitmq command as

   salt.states.rabbitmq_plugin
   Manage RabbitMQ Plugins
   New in version 2014.1.0.

   Example:

      some_plugin:
        rabbitmq_plugin.enabled: []

   salt.states.rabbitmq_plugin.disabled(name, runas=None)
          Ensure the RabbitMQ plugin is disabled.

          name   The name of the plugin

          runas  The user to run the rabbitmq-plugin command as

   salt.states.rabbitmq_plugin.enabled(name, runas=None)
          Ensure the RabbitMQ plugin is enabled.

          name   The name of the plugin

          runas  The user to run the rabbitmq-plugin command as

   salt.states.rabbitmq_policy
   Manage RabbitMQ Policies
   maintainer
          Benn Eichhorn <[email protected]>

   maturity
          new

   platform
          all

   Example:

      rabbit_policy:
        rabbitmq_policy.present:
          - name: HA
          - pattern: '.*'
          - definition: '{"ha-mode": "all"}'

   salt.states.rabbitmq_policy.absent(name, vhost='/', runas=None)
          Ensure the named policy is absent

          Reference: http://www.rabbitmq.com/ha.html

          name   The name of the policy to remove

          runas  Name of the user to run the command as

   salt.states.rabbitmq_policy.present(name,      pattern,     definition,
   priority=0, vhost='/', runas=None)
          Ensure the RabbitMQ policy exists.

          Reference: http://www.rabbitmq.com/ha.html

          name   Policy name

          pattern
                 A regex of queues to apply the policy to

          definition
                 A json dict describing the policy

          priority
                 Priority (defaults to 0)

          vhost  Virtual host to apply to (defaults to '/')

          runas  Name of the user to run the command as

   salt.states.rabbitmq_user
   Manage RabbitMQ Users
   Example:

      rabbit_user:
        rabbitmq_user.present:
          - password: password
          - force: True
          - tags:
            - monitoring
            - user
          - perms:
            - '/':
              - '.*'
              - '.*'
              - '.*'
          - runas: rabbitmq

   salt.states.rabbitmq_user.absent(name, runas=None)
          Ensure the named user is absent

          name   The name of the user to remove

          runas  User to run the command

   salt.states.rabbitmq_user.present(name,   password=None,   force=False,
   tags=None, perms=(), runas=None)
          Ensure the RabbitMQ user exists.

          name   User name

          password
                 User's password, if one needs to be set

          force  If user exists, forcibly change the password

          tags   Optional list of tags for the user

          perms  A list of dicts with vhost keys and 3-tuple values

          runas  Name of the user to run the command

   salt.states.rabbitmq_vhost
   Manage RabbitMQ Virtual Hosts
   Example:

      virtual_host:
        rabbitmq_vhost.present:
          - user: rabbit_user
          - conf: .*
          - write: .*
          - read: .*

   salt.states.rabbitmq_vhost.absent(name)
          Ensure the RabbitMQ Virtual Host is absent

          name   Name of the Virtual Host to remove

          runas  User to run the command

                 Deprecated since version 2015.8.0.

   salt.states.rabbitmq_vhost.present(name)
          Ensure the RabbitMQ VHost exists.

          name   VHost name

          user   Initial user permission to set on the VHost, if present

                 Deprecated since version 2015.8.0.

          owner  Initial owner permission to set on the VHost, if present

                 Deprecated since version 2015.8.0.

          conf   Initial  conf  string  to  apply  to  the VHost and user.
                 Defaults to .*

                 Deprecated since version 2015.8.0.

          write  Initial write permissions to apply to the VHost and user.
                 Defaults to .*

                 Deprecated since version 2015.8.0.

          read   Initial  read permissions to apply to the VHost and user.
                 Defaults to .*

                 Deprecated since version 2015.8.0.

          runas  Name of the user to run the command

                 Deprecated since version 2015.8.0.

   salt.states.rbenv
   Managing Ruby installations with rbenv
   This module is used to install and manage ruby installations with rbenv
   and the ruby-build plugin. Different versions of ruby can be installed,
   and uninstalled.  Rbenv will be installed automatically the first  time
   it   is  needed  and  can  be  updated  later.  This  module  will  not
   automatically install packages which rbenv will  need  to  compile  the
   versions  of  ruby.  If your version of ruby fails to install, refer to
   the  ruby-build  documentation  to  verify  you  are  not  missing  any
   dependencies: https://github.com/sstephenson/ruby-build/wiki

   If  rbenv  is  run  as  the  root  user  then  it  will be installed to
   /usr/local/rbenv, otherwise it will be installed to the users  ~/.rbenv
   directory. To make rbenv available in the shell you may need to add the
   rbenv/shims and rbenv/bin directories to the users  PATH.  If  you  are
   installing as root and want other users to be able to access rbenv then
   you will need to add RBENV_ROOT to their environment.

   The following state configuration  demonstrates  how  to  install  Ruby
   1.9.x and 2.x using rbenv on Ubuntu/Debian:

      rbenv-deps:
        pkg.installed:
          - names:
            - bash
            - git
            - openssl
            - libssl-dev
            - make
            - curl
            - autoconf
            - bison
            - build-essential
            - libffi-dev
            - libyaml-dev
            - libreadline6-dev
            - zlib1g-dev
            - libncurses5-dev

      ruby-1.9.3-p429:
        rbenv.absent:
          - require:
            - pkg: rbenv-deps

      ruby-2.0.0-p598:
        rbenv.installed:
          - default: True
          - require:
            - pkg: rbenv-deps

   salt.states.rbenv.absent(name, user=None)
          Verify  that  the  specified  ruby  is not installed with rbenv.
          Rbenv is installed if necessary.

          name   The version of ruby to uninstall

          user: None
                 The user to run rbenv as.

                 New in version 0.17.0.

          New in version 0.16.0.

   salt.states.rbenv.install_rbenv(name, user=None)
          Install rbenv if not installed. Allows you to require  rbenv  be
          installed prior to installing the plugins. Useful if you want to
          install rbenv plugins via the git or file modules and need  them
          installed before installing any rubies.

          Use  the  rbenv.root  configuration  option  to set the path for
          rbenv if you want a system wide install that is not  in  a  user
          home dir.

          user: None
                 The user to run rbenv as.

   salt.states.rbenv.installed(name, default=False, user=None)
          Verify that the specified ruby is installed with rbenv. Rbenv is
          installed if necessary.

          name   The version of ruby to install

          default
                 False Whether to make this ruby the default.

          user: None
                 The user to run rbenv as.

                 New in version 0.17.0.

          New in version 0.16.0.

   salt.states.rdp
   Manage RDP Service on Windows servers

   salt.states.rdp.disabled(name)
          Disable the RDP service

   salt.states.rdp.enabled(name)
          Enable the RDP service and make sure access to the RDP  port  is
          allowed in the firewall configuration

   salt.states.redismod
   Management of Redis server
   New in version 2014.7.0.

   depends

          * redis Python module

   configuration
          See salt.modules.redis for setup instructions.

      key_in_redis:
        redis.string:
          - value: string data

   The redis server information specified in the minion config file can be
   overridden in states using the following  arguments:  host,  post,  db,
   password.

      key_in_redis:
        redis.string:
          - value: string data
          - host: localhost
          - port: 6379
          - db: 0
          - password: somuchkittycat

   salt.states.redismod.absent(name, keys=None, **connection_args)
          Ensure key absent from redis

          name   Key to ensure absent from redis

          keys   list  of  keys  to ensure absent, name will be ignored if
                 this is used

   salt.states.redismod.slaveof(name,                  sentinel_host=None,
   sentinel_port=None, sentinel_password=None, **connection_args)
          Set this redis instance as a slave.

          name   Master to make this a slave of

          sentinel_host
                 Ip of the sentinel to check for the master

          sentinel_port
                 Port of the sentinel to check for the master

   salt.states.redismod.string(name,  value,  expire=None,  expireat=None,
   **connection_args)
          Ensure that the key exists in redis with the value specified

          name   Redis key to manage

          value  Data to persist in key

          expire Sets time to live for key in seconds

          expireat
                 Sets  expiration  time  for  key  via   UNIX   timestamp,
                 overrides expire

   salt.states.reg
   Manage the Windows registry
   Many  python  developers  think of registry keys as if they were python
   keys in a dictionary which is not the case.  The  windows  registry  is
   broken down into the following components:

   Hives
   This  is  the  top  level of the registry. They all begin with HKEY.  -
   HKEY_CLASSES_ROOT (HKCR) - HKEY_CURRENT_USER(HKCU) - HKEY_LOCAL MACHINE
   (HKLM) - HKEY_USER (HKU) - HKEY_CURRENT_CONFIG

   Keys
   Hives  contain keys. These are basically the folders beneath the hives.
   They can contain any number of subkeys.

   Values or Entries
   Values or Entries are the name/data pairs beneath the keys and subkeys.
   All   keys   have   a   default   name/data   pair.   It   is   usually
   "(Default)"="(value not set)". The actual value for the  name  and  the
   date  is Null. The registry editor will display "(Default)" and "(value
   not set)".

   The following example is taken from the windows startup portion of  the
   registry:                                                             `
   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
   "RTHDVCPL"="\"C:\\Program   Files\\Realtek\\Audio\\HDA\\RtkNGUI64.exe\"
   -s" "NvBackend"="\"C:\\Program Files (x86)\\NVIDIA  Corporation\\Update
   Core\\NvBackend.exe\"" "BTMTrayAgent"="rundll32.exe \"C:\\Program Files
   (x86)\\Intel\\Bluetooth\	tmshellex.dll\",TrayApp" `  In  this  example
   these are the values for each:

   Hive: HKEY_LOCAL_MACHINE

   Key and subkeys: SOFTWAREMicrosoftWindowsCurrentVersionRun

   Value:

          * There are 3 value names: RTHDVCPL, NvBackend, and BTMTrayAgent

          * Each value name has a corresponding value

   salt.states.reg.absent(name, vname=None, use_32bit_registry=False)
          Ensure  a  registry  value  is  removed.  To  remove  a  key use
          key_absent.

          Parameters
                 name (str) -- A string value representing the  full  path
                 of the key to

          include the HIVE, Key, and all Subkeys. For example:

          HKEY_LOCAL_MACHINE\SOFTWARE\Salt

          Valid hive values include:

          * HKEY_CURRENT_USER or HKCU

          * HKEY_LOCAL_MACHINE or HKLM

          * HKEY_USERS or HKU

          Parameters
                 vname (str) -- The name of the value you'd like to create
                 beneath the

          Key. If this parameter is not passed it will assume you want  to
          set the (Default) value

          Parameters
                 use_32bit_registry (bool) -- Use the 32bit portion of the
                 registry.

          Applies only to 64bit windows. 32bit Windows  will  ignore  this
          parameter.  Default is False.

          Returns
                 Returns  a dictionary showing the results of the registry
                 operation.

          Return type
                 dict

          CLI Example:

             'HKEY_CURRENT_USER\SOFTWARE\Salt':
               reg.absent
                 - vname: version

          In the above example the value named  version  will  be  removed
          from  the  SOFTWARESalt  key  in  the HKEY_CURRENT_USER hive. If
          vname was not passed, the (Default) value would be deleted.

   salt.states.reg.key_absent(name, use_32bit_registry=False)
          New in version 2015.5.4.

          Ensure a registry key is removed. This will remove a key and all
          value  entries  it  contains.  It  will fail if the key contains
          subkeys.

          Parameters
                 name (str) -- A string representing the full path to  the
                 key to be

          removed to include the hive and the keypath. The hive can be any
          of the following:

          * HKEY_LOCAL_MACHINE or HKLM

          * HKEY_CURRENT_USER or HKCU

          * HKEY_USER or HKU

          Parameters
                 use_32bit_registry (bool) -- Use the 32bit portion of the
                 registry.

          Applies  only  to  64bit windows. 32bit Windows will ignore this
          parameter.  Default is False.

          Returns
                 Returns a dictionary showing the results of the  registry
                 operation.

          Return type
                 dict

          The  following example will delete the SOFTWARE\Salt key and all
          subkeys under the HKEY_CURRENT_USER hive.

          Example:

             'HKEY_CURRENT_USER\SOFTWARE\Salt':
               reg.key_absent:
                 - force: True

          In the above example the path is interpreted as follows:

          * HKEY_CURRENT_USER is the hive

          * SOFTWARE\Salt is the key

   salt.states.reg.present(name, vname=None,  vdata=None,  vtype='REG_SZ',
   use_32bit_registry=False)
          Ensure a registry key or value is present.

          Parameters
                 name  (str)  -- A string value representing the full path
                 of the key to

          include the HIVE, Key, and all Subkeys. For example:

          HKEY_LOCAL_MACHINE\SOFTWARE\Salt

          Valid  hive  values  include:  -  HKEY_CURRENT_USER  or  HKCU  -
          HKEY_LOCAL_MACHINE or HKLM - HKEY_USERS or HKU

          Parameters
                 vname (str) -- The name of the value you'd like to create
                 beneath the

          Key. If this parameter is not passed it will assume you want  to
          set the (Default) value

          Parameters
                 vdata  (str)  --  The value you'd like to set. If a value
                 name (vname) is

          passed, this will be the data for that value name. If not,  this
          will be the (Default) value for the key.

          The  type for the (Default) value is always REG_SZ and cannot be
          changed.  This parameter is optional. If  not  passed,  the  Key
          will be created with no associated item/value pairs.

          Parameters
                 vtype  (str)  --  The value type for the data you wish to
                 store in the

          registry. Valid values are:

          * REG_BINARY

          * REG_DWORD

          * REG_EXPAND_SZ

          * REG_MULTI_SZ

          * REG_SZ (Default)

          Parameters
                 use_32bit_registry (bool) -- Use the 32bit portion of the
                 registry.

          Applies  only  to  64bit windows. 32bit Windows will ignore this
          parameter.  Default is False.

          Returns
                 Returns a dictionary showing the results of the  registry
                 operation.

          Return type
                 dict

          The  following  example  will  set  the  (Default) value for the
          SOFTWARE\Salt key in the HKEY_CURRENT_USER hive to 2016.3.1:

          Example:

             HKEY_CURRENT_USER\SOFTWARE\Salt:
               reg.present:
                 - vdata: 2016.3.1

          The following example will set the value for the  version  entry
          under  the  SOFTWARE\Salt  key  in the HKEY_CURRENT_USER hive to
          2016.3.1. The value will be reflected in Wow6432Node:

          Example:

             HKEY_CURRENT_USER\SOFTWARE\Salt:
               reg.present:
                 - vname: version
                 - vdata: 2016.3.1

          In the above example the  path  is  interpreted  as  follows:  -
          HKEY_CURRENT_USER is the hive - SOFTWARE\Salt is the key - vname
          is the value name ('version') that will be created under the key
          - vdata is the data that will be assigned to 'version'

   salt.states.rsync
   State to synchronize files and directories with rsync.

   New in version 2016.3.0.

      /opt/user-backups:
        rsync.synchronized:
          - source: /home
          - force: True

   salt.states.rsync.synchronized(name, source, delete=False, force=False,
   update=False,   passwordfile=None,   exclude=None,    excludefrom=None,
   prepare=False, dryrun=False)
          Guarantees  that  the  source  directory is always copied to the
          target.

          name   Name of the target directory.

          source Source directory.

          prepare
                 Create destination directory if it does not exists.

          delete Delete extraneous files from the destination  dirs  (True
                 or False)

          force  Force deletion of dirs even if not empty

          update Skip files that are newer on the receiver (True or False)

          passwordfile
                 Read daemon-access password from the file (path)

          exclude
                 Exclude files, that matches pattern.

          excludefrom
                 Read exclude patterns from the file (path)

          dryrun Perform  a trial run with no changes made. Is the same as
                 doing test=True

                 New in version 2016.3.1.

   salt.states.rvm
   Managing Ruby installations and gemsets with Ruby Version Manager (RVM)
   This module is used  to  install  and  manage  ruby  installations  and
   gemsets  with RVM, the Ruby Version Manager. Different versions of ruby
   can be installed and gemsets created.  RVM  itself  will  be  installed
   automatically  if  it's not present. This module will not automatically
   install packages that RVM depends on or ones that are needed  to  build
   ruby.  If you want to run RVM as an unprivileged user (recommended) you
   will  have  to  create  this  user  yourself.  This  is  how  a   state
   configuration could look like:

      rvm:
        group.present: []
        user.present:
          - gid: rvm
          - home: /home/rvm
          - require:
            - group: rvm

      rvm-deps:
        pkg.installed:
          - pkgs:
            - bash
            - coreutils
            - gzip
            - bzip2
            - gawk
            - sed
            - curl
            - git-core
            - subversion

      mri-deps:
        pkg.installed:
          - pkgs:
            - build-essential
            - openssl
            - libreadline6
            - libreadline6-dev
            - curl
            - git-core
            - zlib1g
            - zlib1g-dev
            - libssl-dev
            - libyaml-dev
            - libsqlite3-0
            - libsqlite3-dev
            - sqlite3
            - libxml2-dev
            - libxslt1-dev
            - autoconf
            - libc6-dev
            - libncurses5-dev
            - automake
            - libtool
            - bison
            - subversion
            - ruby

      jruby-deps:
        pkg.installed:
          - pkgs:
            - curl
            - g++
            - openjdk-6-jre-headless

      ruby-1.9.2:
        rvm.installed:
          - default: True
          - user: rvm
          - require:
            - pkg: rvm-deps
            - pkg: mri-deps
            - user: rvm

      jruby:
        rvm.installed:
          - user: rvm
          - require:
            - pkg: rvm-deps
            - pkg: jruby-deps
            - user: rvm

      jgemset:
        rvm.gemset_present:
          - ruby: jruby
          - user: rvm
          - require:
            - rvm: jruby

      mygemset:
        rvm.gemset_present:
          - ruby: ruby-1.9.2
          - user: rvm
          - require:
            - rvm: ruby-1.9.2

   salt.states.rvm.gemset_present(name, ruby='default', user=None)
          Verify that the gemset is present.

          name   The name of the gemset.

          ruby: default
                 The ruby version this gemset belongs to.

          user: None
                 The user to run rvm as.

                 New in version 0.17.0.

   salt.states.rvm.installed(name, default=False, user=None)
          Verify  that  the  specified  ruby is installed with RVM. RVM is
          installed when necessary.

          name   The version of ruby to install

          default
                 False Whether to make this ruby the default.

          user: None
                 The user to run rvm as.

                 New in version 0.17.0.

   salt.states.salt_proxy module
   Salt proxy state

   New in version 2015.8.2.

   State to deploy and run salt-proxy processes on a minion.

   Set up pillar data for your proxies per the documentation.

   Run the state as below

   ..code-block:: yaml

      salt-proxy-configure:

             salt_proxy.configure_proxy:

                    * proxyname: p8000

                    * start: True

   This  state   will   configure   the   salt   proxy   settings   within
   /etc/salt/proxy  (if  /etc/salt/proxy  doesn't  exists)  and  start the
   salt-proxy process (default true), if it isn't already running.

   salt.states.salt_proxy.configure_proxy(name,         proxyname='p8000',
   start=True)
          Create  the  salt  proxy  file  and  start  the proxy process if
          required

          Parameters

                 * name -- The name of this state

                 * proxyname -- Name to be used  for  this  proxy  (should
                   match entries in pillar)

                 * start  --  Boolean  indicating if the process should be
                   started

          Example:

          ..code-block:: yaml

             salt-proxy-configure:

                    salt_proxy.configure_proxy:

                           * proxyname: p8000

                           * start: True

   salt.states.saltmod
   Control the Salt command interface
   This state is intended for use from the Salt Master. It provides access
   to  sending  commands  down  to  minions as well as access to executing
   master-side modules. These state functions wrap Salt's Python API.
      Support for masterless minions was added to the salt.state function,
      so they can run orchestration sls files. This is particularly useful
      when the rendering of a state  is  dependent  on  the  execution  of
      another   state.    Orchestration   will  render  and  execute  each
      orchestration block  independently,  while  honoring  requisites  to
      ensure the states are applied in the correct order.

   SEE ALSO:
      More Orchestrate documentation

      * Full Orchestrate Tutorial

      * The Orchestrate runner

   salt.states.saltmod.function(name,   tgt,   ssh=False,   tgt_type=None,
   expr_form=None,   ret='',   expect_minions=False,    fail_minions=None,
   fail_function=None, arg=None, kwarg=None, timeout=None, batch=None)
          Execute  a single module function on a remote minion via salt or
          salt-ssh

          name   The  name  of  the  function  to  run,  aka  cmd.run   or
                 pkg.install

          tgt    The target specification, aka '*' for all minions

          tgt_type | expr_form
                 The target type, defaults to glob

          arg    The list of arguments to pass into the function

          kwarg  The  dict  (not a list) of keyword arguments to pass into
                 the function

          ret    Optionally set a single or a list of returners to use

          expect_minions
                 An optional boolean for failing if some  minions  do  not
                 respond

          fail_minions
                 An  optional list of targeted minions where failure is an
                 option

          fail_function
                 An optional string that points  to  a  salt  module  that
                 returns True or False based on the returned data dict for
                 individual minions

          ssh    Set to True to use the ssh client instead of the standard
                 salt client

   salt.states.saltmod.runner(name, **kwargs)
          Execute a runner module on the master

          New in version 2014.7.0.

          name   The name of the function to run

          kwargs Any keyword arguments to pass to the runner function

             run-manage-up:
              salt.runner:
                - name: manage.up

   salt.states.saltmod.state(name,    tgt,    ssh=False,    tgt_type=None,
   expr_form=None,    ret='',    highstate=None,    sls=None,    top=None,
   saltenv=None,     test=False,     pillar=None,    expect_minions=False,
   fail_minions=None,   allow_fail=0,   concurrent=False,    timeout=None,
   batch=None, queue=False, orchestration_jid=None)
          Invoke a state run on a given target

          name   An arbitrary name used to track the state execution

          tgt    The target specification for the state run.

                 Masterless  support: When running on a masterless minion,
                 the tgt is ignored and will always be the local minion.

          tgt_type | expr_form
                 The target type to resolve, defaults to glob

          ret    Optionally set a single or a list of returners to use

          highstate
                 Defaults to None, if set to True the target systems  will
                 ignore any sls references specified in the sls option and
                 call state.highstate on the targeted minions

          top    Should be the name of a top file.  If  set  state.top  is
                 called with this top file instead of state.sls.

          sls    A group of sls files to execute. This can be defined as a
                 single string containing a single sls file, or a list  of
                 sls files

          test   Pass test=true through to the state function

          pillar Pass the pillar kwarg through to the state function

          saltenv
                 The default salt environment to pull sls files from

          ssh    Set to True to use the ssh client instead of the standard
                 salt client

          roster In the event of using salt-ssh, a roster  system  can  be
                 set

          expect_minions
                 An  optional  boolean  for failing if some minions do not
                 respond

          fail_minions
                 An optional list of targeted minions where failure is  an
                 option

          allow_fail
                 Pass in the number of minions to allow for failure before
                 setting the result of the execution to False

          concurrent
                 Allow multiple state runs to occur at once.

                 WARNING:  This  flag  is  potentially  dangerous.  It  is
                 designed  for  use when multiple state runs can safely be
                 run at the same Do not  use  this  flag  for  performance
                 optimization.

          queue  Pass queue=true through to the state function

          batch  Execute the command in batches. E.g.: 10%.

                 New in version 2016.3.0.

          Examples:

          Run a list of sls files via state.sls on target minions:

             webservers:
               salt.state:
                 - tgt: 'web*'
                 - sls:
                   - apache
                   - django
                   - core
                 - saltenv: prod

          Run a full state.highstate on target mininons.

             databases:
               salt.state:
                 - tgt: role:database
                 - tgt_type: grain
                 - highstate: True

   salt.states.saltmod.wait_for_event(name,     id_list,    event_id='id',
   timeout=300, node='master')
          Watch Salt's event bus and block until a condition is met

          New in version 2014.7.0.

          name   An  event  tag  to  watch  for;  supports   Reactor-style
                 globbing.

          id_list
                 A  list  of event identifiers to watch for -- usually the
                 minion ID. Each time an event tag is  matched  the  event
                 data  is  inspected  for event_id, if found it is removed
                 from id_list. When id_list is empty this function returns
                 success.

          event_id
                 id The name of a key in the event data. Default is id for
                 the minion ID, another common value is name for use  with
                 orchestrating salt-cloud events.

          timeout
                 300 The maximum time in seconds to wait before failing.

          The  following  example  blocks  until  all  the  listed minions
          complete a restart and reconnect to the Salt master:

             reboot_all_minions:
               salt.function:
                 - name: system.reboot
                 - tgt: '*'

             wait_for_reboots:
               salt.wait_for_event:
                 - name: salt/minion/*/start
                 - id_list:
                   - jerry
                   - stuart
                   - dave
                   - phil
                   - kevin
                   - mike
                 - require:
                   - salt: reboot_all_minions

   salt.states.saltmod.wheel(name, **kwargs)
          Execute a wheel module on the master

          New in version 2014.7.0.

          name   The name of the function to run

          kwargs Any keyword arguments to pass to the wheel function

             accept_minion_key:
               salt.wheel:
                 - name: key.accept
                 - match: frank

   salt.states.schedule
   Management of the Salt scheduler
      job3:
        schedule.present:
          - function: test.ping
          - seconds: 3600
          - splay: 10

      This will schedule the command: test.ping every 3600 seconds
      (every hour) splaying the time between 0 and 10 seconds

      job2:
        schedule.present:
          - function: test.ping
          - seconds: 15
          - splay:
              start: 10
              end: 20

      This will schedule the command: test.ping every 15 seconds
      splaying the time between 10 and 20 seconds

      job1:
        schedule.present:
          - function: state.sls
          - job_args:
            - httpd
          - job_kwargs:
              test: True
          - when:
              - Monday 5:00pm
              - Tuesday 3:00pm
              - Wednesday 5:00pm
              - Thursday 3:00pm
              - Friday 5:00pm

      This will schedule the command: state.sls httpd test=True at 5pm on Monday,
      Wednesday and Friday, and 3pm on Tuesday and Thursday.  Requires that
      python-dateutil is installed on the minion.

      job1:
        schedule.present:
          - function: state.sls
          - job_args:
            - httpd
          - job_kwargs:
              test: True
          - cron: '*/5 * * * *'

      Scheduled jobs can also be specified using the format used by cron.  This will
      schedule the command: state.sls httpd test=True to run every 5 minutes.  Requires
      that python-croniter is installed on the minion.

      job1:
        schedule.present:
          - function: state.sls
          - job_args:
            - httpd
          - job_kwargs:
              test: True
          - when:
              - Monday 5:00pm
              - Tuesday 3:00pm
              - Wednesday 5:00pm
              - Thursday 3:00pm
              - Friday 5:00pm
          - returner: xmpp
          - return_config: xmpp_state_run
          - return_kwargs:
              recipient: [email protected]

      This will schedule the command: state.sls httpd test=True at 5pm on Monday,
      Wednesday and Friday, and 3pm on Tuesday and Thursday.  Using the xmpp returner
      to return the results of the scheduled job, with the alternative configuration
      options found in the xmpp_state_run section.

   salt.states.schedule.absent(name, **kwargs)
          Ensure a job is absent from the schedule

          name   The unique name that is given to the scheduled job.

          persist
                 Whether the job should persist between  minion  restarts,
                 defaults to True.

   salt.states.schedule.disabled(name, **kwargs)
          Ensure a job is disabled in the schedule

          name   The unique name that is given to the scheduled job.

          persist
                 Whether  the  job should persist between minion restarts,
                 defaults to True.

   salt.states.schedule.enabled(name, **kwargs)
          Ensure a job is enabled in the schedule

          name   The unique name that is given to the scheduled job.

          persist
                 Whether the job should persist between  minion  restarts,
                 defaults to True.

   salt.states.schedule.present(name, **kwargs)
          Ensure a job is present in the schedule

          name   The unique name that is given to the scheduled job.

          seconds
                 The  scheduled  job  will be executed after the specified
                 number of seconds have passed.

          minutes
                 The scheduled job will be executed  after  the  specified
                 number of minutes have passed.

          hours  The  scheduled  job  will be executed after the specified
                 number of hours have passed.

          days   The scheduled job will be executed  after  the  specified
                 number of days have passed.

          when   This will schedule the job at the specified time(s).  The
                 when parameter must be a single  value  or  a  dictionary
                 with  the  date  string(s)  using  the  dateutil  format.
                 Requires python-dateutil.

          cron   This will schedule the job at the specified time(s) using
                 the crontab format.  Requires python-croniter.

          run_on_start
                 Whether  the  job will run when Salt minion start.  Value
                 should be a boolean.

          function
                 The function that should be  executed  by  the  scheduled
                 job.

          job_args
                 The arguments that will be used by the scheduled job.

          job_kwargs
                 The  keyword arguments that will be used by the scheduled
                 job.

          maxrunning
                 Ensure that  there  are  no  more  than  N  copies  of  a
                 particular job running.

          jid_include
                 Include the job into the job cache.

          splay  The  amount  of time in seconds to splay a scheduled job.
                 Can be specified as a single value in  seconds  or  as  a
                 dictionary range with 'start' and 'end' values.

          range  This   will   schedule   the  command  within  the  range
                 specified.  The range parameter must be a dictionary with
                 the  date  strings  using  the  dateutil format. Requires
                 python-dateutil.

          once   This will schedule a job to run  once  on  the  specified
                 date.

          once_fmt
                 The default date format is ISO 8601 but can be overridden
                 by also specifying the once_fmt option.

          enabled
                 Whether the job should be  enabled  or  disabled.   Value
                 should be a boolean.

          return_job
                 Whether to return information to the Salt master upon job
                 completion.

          metadata
                 Using  the  metadata  parameter  special  values  can  be
                 associated  with  a  scheduled job.  These values are not
                 used in the execution of the job,  but  can  be  used  to
                 search  for  specific  jobs  later  if  combined with the
                 return_job parameter.  The  metadata  parameter  must  be
                 specified as a dictionary, othewise it will be ignored.

          returner
                 The  returner  to  use  to  return  the  results  of  the
                 scheduled job.

          return_config
                 The  alternative  configuration  to  use   for   returner
                 configuration options.

          return_kwargs
                 Any  individual returner configuration items to override.
                 Should be passed as a dictionary.

          persist
                 Whether the job should persist between  minion  restarts,
                 defaults to True.

   salt.states.selinux
   Management of SELinux rules
   If SELinux is available for the running system, the mode can be managed
   and booleans can be set.

      enforcing:
          selinux.mode

      samba_create_home_dirs:
          selinux.boolean:
            - value: True
            - persist: True

      nginx:
          selinux.module:
            - enabled: False

   NOTE:
      Use of these states require that the  selinux  execution  module  is
      available.

   salt.states.selinux.boolean(name, value, persist=False)
          Set up an SELinux boolean

          name   The name of the boolean to set

          value  The value to set on the boolean

          persist
                 Defaults  to  False,  set  persist  to  true  to make the
                 boolean apply on a reboot

   salt.states.selinux.mode(name)
          Verifies  the  mode  SELinux  is  running  in,  can  be  set  to
          enforcing, permissive, or disabled

             Note:  A  change  to  or from disabled mode requires a system
             reboot.
                    You will need to perform this yourself.

          name   The mode to run SELinux  in,  permissive,  enforcing,  or
                 disabled.

   salt.states.selinux.module(name, module_state='Enabled', version='any')
          Enable/Disable  and  optionally  force a specific version for an
          SELinux module

          name   The name of the module to control

          module_state
                 Should the module be enabled or disabled?

          version
                 Defaults to no preference, set to a  specified  value  if
                 required.   Currently  can  only  alert if the version is
                 incorrect.

          New in version 2016.3.0.

   salt.states.serverdensity_device
   Monitor Server with Server Density
   New in version 2014.7.0.

   Server Density Is a hosted monitoring service.

   WARNING:
      This state module is beta. It might be changed later to include more
      or less automation.

   NOTE:
      This  state  module requires a pillar for authentication with Server
      Density To install a v1 agent:

          serverdensity:
            api_token: "b97da80a41c4f61bff05975ee51eb1aa"
            account_url: "https://your-account.serverdensity.io"

      To install a v2 agent:

          serverdensity:
            api_token: "b97da80a41c4f61bff05975ee51eb1aa"
            account_name: "your-account"

   NOTE:
      Although  Server  Density  allows  duplicate  device  names  in  its
      database,  this module will raise an exception if you try monitoring
      devices with the same name.

   Example:

      'server_name':
        serverdensity_device.monitored

   salt.states.serverdensity_device.monitored(name,            group=None,
   salt_name=True, salt_params=True, agent_version=1, **params)
          Device is monitored with Server Density.

          name   Device name in Server Density.

          salt_name
                 If  True  (default), takes the name from the id grain. If
                 False, the provided name is used.

          group  Group name  under  with  device  will  appear  in  Server
                 Density dashboard.  Default - None.

          agent_version
                 The  agent version you want to use. Valid values are 1 or
                 2.  Default - 1.

          salt_params
                 If True  (default),  needed  config  parameters  will  be
                 sourced from grains and from status.all_status.

          params Add  parameters  that  you  want  to appear in the Server
                 Density  dashboard.   Will  overwrite   the   salt_params
                 parameters. For more info, see the API docs.

          Usage example:

             'server_name':
               serverdensity_device.monitored

             'server_name':
               serverdensity_device.monitored:
                 - group: web-servers

             'my_special_server':
               serverdensity_device.monitored:
                 - salt_name: False
                 - group: web-servers
                 - cpuCores: 2
                 - os: '{"code": "linux", "name": "Linux"}'

   salt.states.service
   Starting or restarting of services and daemons
   Services  are  defined  as system daemons typically started with system
   init or 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  service  modules  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 Overriding Virtual
   Module Providers 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 script status command. A status return code of 0  it  is
      considered running.  Any other return code is considered dead.

      httpd:
        service.running: []

   The  service  can  also  be set to be started at runtime via the enable
   option:

      openvpn:
        service.running:
          - enable: True

   By default if a  service  is  triggered  to  refresh  due  to  a  watch
   statement  the service is by default restarted. If the desired behavior
   is to reload the service, then set the reload value to True:

      redis:
        service.running:
          - enable: True
          - reload: True
          - watch:
            - pkg: redis

   NOTE:
      More  details  regarding  watch  can  be  found  in  the  Requisites
      documentation.

   salt.states.service.dead(name, enable=None, sig=None, **kwargs)
          Ensure that the named service is dead by stopping the service if
          it is running

          name   The name of the init or rc  script  used  to  manage  the
                 service

          enable Set the service to be enabled at boot time, True sets the
                 service to be enabled, False sets the named service to be
                 disabled.  The  default is None, which does not enable or
                 disable anything.

          sig    The string to search for when  looking  for  the  service
                 process with ps

   salt.states.service.disabled(name, **kwargs)
          Ensure that the service is disabled on boot, only use this state
          if you don't want to manage the running process,  remember  that
          if you want to disable a service to use the enable: False option
          for the running or dead function.

          name   The name of the init or rc  script  used  to  manage  the
                 service

   salt.states.service.enabled(name, **kwargs)
          Ensure  that the service is enabled on boot, only use this state
          if you don't want to manage the running process,  remember  that
          if  you want to enable a running service to use the enable: True
          option for the running or dead function.

          name   The name of the init or rc  script  used  to  manage  the
                 service

   salt.states.service.mod_watch(name,  sfun=None, sig=None, reload=False,
   full_restart=False, init_delay=None, force=False, **kwargs)
          The service watcher, called to invoke the watch command.

          name   The name of the init or rc  script  used  to  manage  the
                 service

          sfun   The  original function which triggered the mod_watch call
                 (service.running, for example).

          sig    The string to search for when  looking  for  the  service
                 process with ps

          reload Use  reload  instead  of  the  default restart (exclusive
                 option with full_restart, defaults to reload if both  are
                 used)

          full_restart
                 Use  service.full_restart  instead  of restart (exclusive
                 option with reload)

          force  Use service.force_reload instead of reload (needs  reload
                 to be set to True)

          init_delay
                 Add  a  sleep  command (in seconds) before the service is
                 restarted/reloaded

   salt.states.service.running(name,        enable=None,         sig=None,
   init_delay=None, **kwargs)
          Ensure that the service is running

          name   The  name  of  the  init  or rc script used to manage the
                 service

          enable Set the service to be enabled at boot time, True sets the
                 service to be enabled, False sets the named service to be
                 disabled. The default is None, which does not  enable  or
                 disable anything.

          sig    The  string  to  search  for when looking for the service
                 process with ps

          init_delay
                 Some services may not be  truly  available  for  a  short
                 period after their startup script indicates to the system
                 that they are. Provide an 'init_delay'  to  specify  that
                 this  state  should  wait  an  additional given number of
                 seconds after a service  has  started  before  returning.
                 Useful  for  requisite  states  wherein a dependent state
                 might assume a service has started but is not  yet  fully
                 initialized.

          NOTE:

             watch  can  be used with service.running to restart a service
             when
                    another state changes ( example: a file.managed  state
                    that creates the service's config file ). More details
                    regarding  watch  can  be  found  in  the   Requisites
                    documentation.

   salt.states.slack
   Send a message to Slack
   This state is useful for sending messages to Slack during state runs.

   New in version 2015.5.0.

      slack-message:
        slack.post_message:
          - channel: '#general'
          - from_name: SuperAdmin
          - message: 'This state was executed successfully.'
          - api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   The api key can be specified in the master or minion configuration like
   below:

      slack:
        api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

   salt.states.slack.post_message(name,   channel,   from_name,   message,
   api_key=None, icon=None)
          Send a message to a Slack channel.

             slack-message:
               slack.post_message:
                 - channel: '#general'
                 - from_name: SuperAdmin
                 - message: 'This state was executed successfully.'
                 - api_key: peWcBiMOS9HrZG15peWcBiMOS9HrZG15

          The following parameters are required:

          name   The unique name for this event.

          channel
                 The  channel to send the message to. Can either be the ID
                 or the name.

          from_name
                 The name of that is to be shown in the "from" field.

          message
                 The message that is to be sent to the Slack channel.

          The following parameters are optional:

          api_key
                 The api key for Slack to use for authentication,  if  not
                 specified  in  the  configuration  options  of  master or
                 minion.

          icon   URL to an image to use as the icon for this message

   salt.states.smartos
   Management of SmartOS Standalone Compute Nodes

   maintainer
          Jorge Schrauwen <[email protected]>

   maturity
          new

   depends
          vmadm, imgadm

   platform
          smartos

   New in version 2016.3.0.

      vmtest.example.org:
        smartos.vm_present:
          - config:
              reprovision: true
          - vmconfig:
              image_uuid: c02a2044-c1bd-11e4-bd8c-dfc1db8b0182
              brand: joyent
              alias: vmtest
              quota: 5
              max_physical_memory: 512
              tags:
                label: 'test vm'
                owner: 'sjorge'
              nics:
                "82:1b:8e:49:e9:12"
                  nic_tag: trunk
                  mtu: 1500
                  ips:
                    - 172.16.1.123/16
                    - 192.168.2.123/24
                  vlan_id: 10
                "82:1b:8e:49:e9:13"
                  nic_tag: trunk
                  mtu: 1500
                  ips:
                    - dhcp
                  vlan_id: 30
              filesystems:
                "/bigdata":
                  source: "/bulk/data"
                  type: lofs
                  options:
                    - ro
                    - nodevices

      kvmtest.example.org:
        smartos.vm_present:
          - vmconfig:
              brand: kvm
              alias: kvmtest
              cpu_type: host
              ram: 512
              vnc_port: 9
              tags:
                label: 'test kvm'
                owner: 'sjorge'
              disks:
                disk0
                  size: 2048
                  model: virtio
                  compression: lz4
                  boot: true
              nics:
                "82:1b:8e:49:e9:15"
                  nic_tag: trunk
                  mtu: 1500
                  ips:
                    - dhcp
                  vlan_id: 30

      cleanup_images:
        smartos.image_vacuum

   NOTE:
      Keep in mind that when removing properties from vmconfig  they  will
      not  get  removed  from  the  vm's current configuration, except for
      nics, disk, tags, ...  they get removed via add_*, set_*,  update_*,
      and  remove_*.  Properties  must  be manually reset to their default
      value.  The same behavior as when using 'vmadm update'.

   salt.states.smartos.config_absent(name)
          Ensure configuration property is absent in /usbkey/config

          name   string name of property

   salt.states.smartos.config_present(name, value)
          Ensure configuration property is set to value in /usbkey/config

          name   string name of property

          value  string value of property

   salt.states.smartos.image_absent(name)
          Ensure image is absent on the computenode

          name   string uuid of image

          NOTE:
             computenode.image_absent will only remove the image if it  is
             not used by a vm.

   salt.states.smartos.image_present(name)
          Ensure image is present on the computenode

          name   string uuid of image

   salt.states.smartos.image_vacuum(name)
          Delete images not in use or installed via image_present

   salt.states.smartos.vm_absent(name, archive=False)
          Ensure vm is absent on the computenode

          name   string hostname of vm

          archive
                 boolean toggle archiving of vm on removal

          NOTE:
             State ID is used as hostname. Hostnames must be unique.

   salt.states.smartos.vm_present(name, vmconfig, config=None)
          Ensure vm is present on the computenode

          name   string hostname of vm

          vmconfig
                 dict options to set for the vm

          config dict fine grain control over vm_present

          NOTE:

             The  following configuration properties can be toggled in the
             config parameter.

                    * kvm_reboot (true) - reboots of kvm zones  if  needed
                      for a config update

                    * auto_import (false) - automatic importing of missing
                      images

                    * reprovision  (false)  -  reprovision  on  image_uuid
                      changes

          NOTE:
             State ID is used as hostname. Hostnames must be unique.

          NOTE:
             If  hostname is provided in vmconfig this will take president
             over the State ID.  This allows multiple states to be applied
             to the same vm.

          NOTE:

             The following instances should have a unique ID.

                    * nic : mac

                    * filesystem: target

                    * disk : path or diskN for zvols

             e.g. disk0 will be the first disk added, disk1 the 2nd,...

   salt.states.smartos.vm_running(name)
          Ensure vm is in the running state on the computenode

          name   string hostname of vm

          NOTE:
             State ID is used as hostname. Hostnames must be unique.

   salt.states.smartos.vm_stopped(name)
          Ensure vm is in the stopped state on the computenode

          name   string hostname of vm

          NOTE:
             State ID is used as hostname. Hostnames must be unique.

   salt.states.smtp
   Sending Messages via SMTP
   New in version 2014.7.0.

   This  state  is useful for firing messages during state runs, using the
   SMTP protocol

      server-warning-message:
        smtp.send_msg:
          - name: 'This is a server warning message'
          - profile: my-smtp-account
          - recipient: [email protected]

   salt.states.smtp.send_msg(name, recipient,  subject,  sender,  profile,
   use_ssl='True')
          Send a message via SMTP

             server-warning-message:
               smtp.send_msg:
                 - name: 'This is a server warning message'
                 - profile: my-smtp-account
                 - subject: 'Message from Salt'
                 - recipient: [email protected]
                 - sender: [email protected]
                 - use_ssl: True

          name   The message to send via SMTP

   salt.states.splunk
   Splunk User State Module

   New in version 2016.3.0..

   This state is used to ensure presence of users in splunk.

      ensure example test user 1:
          splunk.present:
              - name: 'Example TestUser1'
              - email: [email protected]

   salt.states.splunk.absent(email, profile='splunk', **kwargs)
          Ensure a splunk user is absent

             ensure example test user 1:
                 splunk.absent:
                     - email: '[email protected]'
                     - name: 'exampleuser'

          The following parameters are required:

          email  This is the email of the user in splunk

          name   This is the splunk username used to identify the user.

   salt.states.splunk.present(email, profile='splunk', **kwargs)
          Ensure a user is present

             ensure example test user 1:
                 splunk.user_present:
                     - realname: 'Example TestUser1'
                     - name: 'exampleuser'
                     - email: '[email protected]'
                     - roles: ['user']

          The following parameters are required:

          email  This is the email of the user in splunk

   salt.states.splunk_search
   Splunk Search State Module

   New in version 2015.5.0.

   This state is used to ensure presence of splunk searches.

      server-warning-message:
        splunk_search.present:
          - name: This is the splunk search name
          - search: index=main sourcetype=

   salt.states.splunk_search.absent(name, profile='splunk')
          Ensure a search is absent

             API Error Search:
               splunk_search.absent

          The following parameters are required:

          name   This is the name of the search in splunk

   salt.states.splunk_search.present(name, profile='splunk', **kwargs)
          Ensure a search is present

             API Error Search:
               splunk_search.present:
                 search: index=main sourcetype=blah
                 template: alert_5min

          The following parameters are required:

          name   This is the name of the search in splunk

   salt.states.sqlite3
   Management of SQLite3 databases
   depends

          * SQLite3 Python Module

   configuration
          See salt.modules.sqlite3 for setup instructions

   New in version 2016.3.0.

   The  sqlite3  module is used to create and manage sqlite3 databases and
   execute queries

   Here is an example of creating a table using sql statements:

          users:
            sqlite3.table_present:
              - db: /var/www/data/app.sqlite
              - schema: CREATE TABLE `users` (`username` TEXT COLLATE NOCASE UNIQUE NOT NULL, `password` BLOB NOT NULL, `salt` BLOB NOT NULL, `last_login` INT)

   Here is an example of creating a table using yaml/jinja instead of sql:

          users:
            sqlite3.table_present:
              - db: /var/www/app.sqlite
              - schema:
                - email TEXT COLLATE NOCASE UNIQUE NOT NULL
                - firstname TEXT NOT NULL
                - lastname TEXT NOT NULL
                - company TEXT NOT NULL
                - password BLOB NOT NULL
                - salt BLOB NOT NULL

   Here is an example of making sure a table is absent:

          badservers:
            sqlite3.table_absent:
              - db: /var/www/data/users.sqlite

   Sometimes you would to have specific data in tables to be used by other
   services  Here  is  an  example  of making sure rows with specific data
   exist:

          user_john_doe_xyz:
            sqlite3.row_present:
              - db: /var/www/app.sqlite
              - table: users
              - where_sql: email='[email protected]'
              - data:
                  email: [email protected]
                  lastname: doe
                  firstname: john
                  company: companyxyz.com
                  password: abcdef012934125
                  salt: abcdef012934125
              - require:
                - sqlite3: users

   Here is an example of removing a row from a table:

          user_john_doe_abc:
            sqlite3.row_absent:
              - db: /var/www/app.sqlite
              - table: users
              - where_sql: email="[email protected]"
              - require:
                - sqlite3: users

   salt.states.sqlite3.row_absent(name,     db,     table,      where_sql,
   where_args=None)
          Makes  sure the specified row is absent in db.  If multiple rows
          match where_sql, then the state will fail.

          name   Only used as the unique ID

          db     The database file name

          table  The table name to check

          where_sql
                 The sql to select the row to check

          where_args
                 The list parameters to substitute in where_sql

   salt.states.sqlite3.row_present(name,  db,  table,   data,   where_sql,
   where_args=None, update=False)
          Checks  to  make  sure  the  given row exists. If row exists and
          update is True then row will be updated with data. Otherwise  it
          will leave existing row unmodified and check it against data. If
          the existing data doesn't match data_check the state will  fail.
          If  the  row  doesn't  exist  then  it will insert data into the
          table. If more than one row matches, then the state will fail.

          name   Only used as the unique ID

          db     The database file name

          table  The table name to check the data

          data   The dictionary of key/value pairs to check against if row
                 exists, insert into the table if it doesn't

          where_sql
                 The sql to select the row to check

          where_args
                 The list parameters to substitute in where_sql

          update True  will  replace the existing row with data When False
                 and the row exists and data does not equal the  row  data
                 then the state will fail

   salt.states.sqlite3.table_absent(name, db)
          Make sure the specified table does not exist

          name   The name of the table

          db     The name of the database file

   salt.states.sqlite3.table_present(name, db, schema, force=False)
          Make sure the specified table exists with the specified schema

          name   The name of the table

          db     The name of the database file

          schema The dictionary containing the schema information

          force  If  the  name  of  the  table  exists and force is set to
                 False, the state will fail.  If force is set to True, the
                 existing table will be replaced with the new table

   salt.states.ssh_auth
   Control of entries in SSH authorized_key files
   The  information  stored  in  a  user's  SSH authorized key file can be
   easily controlled via the ssh_auth state. Defaults can be  set  by  the
   enc,  options,  and  comment  keys. These defaults can be overridden by
   including them in the name.

   Since the YAML specification limits the length of simple keys  to  1024
   characters, and since SSH keys are often longer than that, you may have
   to use a YAML 'explicit key', as demonstrated  in  the  second  example
   below.

      AAAAB3NzaC1kc3MAAACBAL0sQ9fJ5bYTEyY==:
        ssh_auth.present:
          - user: root
          - enc: ssh-dss

      ? AAAAB3NzaC1kc3MAAACBAL0sQ9fJ5bYTEyY==...
      :
        ssh_auth.present:
          - user: root
          - enc: ssh-dss

      thatch:
        ssh_auth.present:
          - user: root
          - source: salt://ssh_keys/thatch.id_rsa.pub
          - config: '%h/.ssh/authorized_keys'

      sshkeys:
        ssh_auth.present:
          - user: root
          - enc: ssh-rsa
          - options:
            - option1="value1"
            - option2="value2 flag2"
          - comment: myuser
          - names:
            - AAAAB3NzaC1kc3MAAACBAL0sQ9fJ5bYTEyY==
            - ssh-dss AAAAB3NzaCL0sQ9fJ5bYTEyY== user@domain
            - option3="value3" ssh-dss AAAAB3NzaC1kcQ9J5bYTEyY== other@testdomain
            - AAAAB3NzaC1kcQ9fJFF435bYTEyY== newcomment

   salt.states.ssh_auth.absent(name,   user,   enc='ssh-rsa',  comment='',
   source='', options=None, config='.ssh/authorized_keys')
          Verifies that the specified SSH key is absent

          name   The SSH key to manage

          user   The user who owns the SSH authorized keys file to modify

          enc    Defines what type of key is being used; can  be  ed25519,
                 ecdsa, ssh-rsa or ssh-dss

          comment
                 The comment to be placed with the SSH public key

          options
                 The options passed to the key, pass a list object

          source The source file for the key(s). Can contain any number of
                 public keys, in  standard  "authorized_keys"  format.  If
                 this is set, comment, enc and options will be ignored.

                 New in version 2015.8.0.

          config The  location of the authorized keys file relative to the
                 user's      home       directory,       defaults       to
                 ".ssh/authorized_keys".  Token  expansion  %u  and %h for
                 username and home path supported.

   salt.states.ssh_auth.present(name,  user,  enc='ssh-rsa',   comment='',
   source='', options=None, config='.ssh/authorized_keys', **kwargs)
          Verifies that the specified SSH key is present for the specified
          user

          name   The SSH key to manage

          user   The user who owns the SSH authorized keys file to modify

          enc    Defines what type of key is being used; can  be  ed25519,
                 ecdsa, ssh-rsa or ssh-dss

          comment
                 The comment to be placed with the SSH public key

          source The source file for the key(s). Can contain any number of
                 public keys, in  standard  "authorized_keys"  format.  If
                 this is set, comment and enc will be ignored.

          NOTE:
             The  source  file must contain keys in the format <enc> <key>
             <comment>. If you have generated a  keypair  using  PuTTYgen,
             then  you  will  need  to  do  the  following  to retrieve an
             OpenSSH-compatible public key.

             1. In PuTTYgen, click Load, and select the private  key  file
                (not the public key), and click Open.

             2. Copy  the  public  key from the box labeled Public key for
                pasting into OpenSSH authorized_keys file.

             3. Paste it into a new file.

          options
                 The options passed to the key, pass a list object

          config The location of the authorized keys file relative to  the
                 user's       home       directory,       defaults      to
                 ".ssh/authorized_keys". Token expansion  %u  and  %h  for
                 username and home path supported.

   salt.states.ssh_known_hosts
   Control of SSH known_hosts entries
   Manage the information stored in the known_hosts files.

      github.com:
        ssh_known_hosts:
          - present
          - user: root
          - fingerprint: 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48

      example.com:
        ssh_known_hosts:
          - absent
          - user: root

   salt.states.ssh_known_hosts.absent(name, user=None, config=None)
          Verifies that the specified host is not known by the given user

          name   The host name

          user   The user who owns the ssh authorized keys file to modify

          config The  location of the authorized keys file relative to the
                 user's home directory, defaults to ".ssh/known_hosts". If
                 no      user      is      specified,      defaults     to
                 "/etc/ssh/ssh_known_hosts".  If  present,  must   be   an
                 absolute path when a user is not specified.

   salt.states.ssh_known_hosts.present(name,  user=None, fingerprint=None,
   key=None,  port=None,  enc=None,  config=None,   hash_known_hosts=True,
   timeout=5)
          Verifies that the specified host is known by the specified user

          On  many  systems,  specifically those running with openssh 4 or
          older, the enc option must be set, only openssh 5 and above  can
          detect the key type.

          name   The name of the remote host (e.g. "github.com")

          user   The user who owns the ssh authorized keys file to modify

          fingerprint
                 The  fingerprint  of the key which must be present in the
                 known_hosts file (optional if key specified)

          key    The public key which must be present in  the  known_hosts
                 file (optional if fingerprint specified)

          port   optional  parameter,  port  which  will  be  used to when
                 requesting the public key from the remote host,  defaults
                 to port 22.

          enc    Defines  what  type of key is being used, can be ed25519,
                 ecdsa ssh-rsa or ssh-dss

          config The location of the authorized keys file relative to  the
                 user's home directory, defaults to ".ssh/known_hosts". If
                 no     user      is      specified,      defaults      to
                 "/etc/ssh/ssh_known_hosts".   If   present,  must  be  an
                 absolute path when a user is not specified.

          hash_known_hosts
                 True Hash all hostnames and addresses in the known  hosts
                 file.

          timeout
                 int  Set the timeout for connection attempts.  If timeout
                 seconds have elapsed since a connection was initiated  to
                 a host or since the last time anything was read from that
                 host, then the connection  is  closed  and  the  host  in
                 question considered unavailable.  Default is 5 seconds.

                 New in version 2016.3.0.

   salt.states.stateconf
   Stateconf System
   The  stateconf  system  is  intended  for  use  only with the stateconf
   renderer. This State module presents the set  function.  This  function
   does  not  execute  any functionality, but is used to interact with the
   stateconf renderer.

   salt.states.stateconf.context(name, **kwargs)
          No-op state to support state config via the stateconf renderer.

   salt.states.stateconf.set(name, **kwargs)
          No-op state to support state config via the stateconf renderer.

   salt.states.status
   Minion status monitoring

   Maps to the status execution module.

   salt.states.status.loadavg(name, maximum=None, minimum=None)
          Return the  current  load  average  for  the  specified  minion.
          Available  values  for name are 1-min, 5-min and 15-min. minimum
          and maximum values should be passed in as strings.

   salt.states.status.process(name)
          Return whether the specified signature is found in  the  process
          tree. This differs slightly from the services states, in that it
          may refer to a process that is not managed via the init system.

   salt.states.stormpath_account
   Support for Stormpath.

   New in version 2015.8.0.

   salt.states.stormpath_account.absent(name, directory_id=None)
          Ensure that an account associated with the given  email  address
          is  absent.  Will search all directories for the account, unless
          a directory_id is specified.

          name   The email address of the account to delete.

          directory_id
                 Optional. The ID of the directory  that  the  account  is
                 expected  to  belong to. If not specified, then a list of
                 directories will be retrieved, and each will  be  scanned
                 for the account. Specifying a directory_id will therefore
                 cut down on the number  of  requests  to  Stormpath,  and
                 increase performance of this state.

   salt.states.stormpath_account.present(name, **kwargs)
          Ensure that an account is present and properly configured

          name   The email address associated with the Stormpath account

          directory_id
                 The  ID  of  a  directory  which  the account belongs to.
                 Required.

          password
                 Required when creating a new account. If specified, it is
                 advisable  to  reference the password in another database
                 using an sdb:// URL.  Will NOT update the password if  an
                 account already exists.

          givenName
                 Required when creating a new account.

          surname
                 Required when creating a new account.

          username
                 Optional.  Must be unique across the owning directory. If
                 not specified, the username will  default  to  the  email
                 field.

          middleName
                 Optional.

          status enabled  accounts  are  able  to  login to their assigned
                 applications,  disabled  accounts  may   not   login   to
                 applications,  unverified  accounts are disabled and have
                 not verified their email address.

          customData.
                 Optional. Must be specified as a dict.

   salt.states.supervisord
   Interaction with the Supervisor daemon
      wsgi_server:
        supervisord.running:
          - require:
            - pkg: supervisor
          - watch:
            - file: /etc/nginx/sites-enabled/wsgi_server.conf

   salt.states.supervisord.dead(name,      user=None,      conf_file=None,
   bin_env=None, **kwargs)
          Ensure the named service is dead (not running).

          name   Service  name  as defined in the supervisor configuration
                 file

          user   Name of the user to run the supervisorctl command

                 New in version 0.17.0.

          conf_file
                 path to supervisorctl config file

          bin_env
                 path to supervisorctl bin  or  path  to  virtualenv  with
                 supervisor installed

   salt.states.supervisord.running(name,    restart=False,   update=False,
   user=None, conf_file=None, bin_env=None, **kwargs)
          Ensure the named service is running.

          name   Service name as defined in the  supervisor  configuration
                 file

          restart
                 Whether to force a restart

          update Whether to update the supervisor configuration.

          user   Name of the user to run the supervisorctl command

                 New in version 0.17.0.

          conf_file
                 path to supervisorctl config file

          bin_env
                 path  to  supervisorctl  bin  or  path to virtualenv with
                 supervisor installed

   salt.states.svn
   Manage SVN repositories
   Manage  repository  checkouts  via  the  svn  vcs  system.  Note   that
   subversion  must  be installed for these states to be available, so svn
   states should include a requisite to  a  pkg.installed  state  for  the
   package which provides subversion (subversion in most cases). Example:

      subversion:
        pkg.installed

      http://unladen-swallow.googlecode.com/svn/trunk/:
        svn.latest:
          - target: /tmp/swallow

   salt.states.svn.dirty(name,     target,    user=None,    username=None,
   password=None, ignore_unversioned=False)
          Determine if the working directory has been changed.

   salt.states.svn.export(name,    target=None,    rev=None,    user=None,
   username=None,     password=None,     force=False,     overwrite=False,
   externals=True, trust=False)
          Export a file or directory from an SVN repository

          name   Address and path to the file or directory to be exported.

          target Name of the target directory where the checkout will  put
                 the working directory

          rev    None The name revision number to checkout. Enable "force"
                 if the directory already exists.

          user   None Name of the user  performing  repository  management
                 operations

          username
                 None The user to access the name repository with. The svn
                 default is the current user

          password
                 Connect to the Subversion server with this password

                 New in version 0.17.0.

          force  False Continue if conflicts are encountered

          overwrite
                 False Overwrite existing target

          externals
                 True Change to False to not checkout or update externals

          trust  False  Automatically  trust  the  remote  server.   SVN's
                 --trust-server-cert

   salt.states.svn.latest(name,    target=None,    rev=None,    user=None,
   username=None, password=None, force=False, externals=True, trust=False)
          Checkout or update the working directory to the latest  revision
          from the remote repository.

          name   Address   of  the  name  repository  as  passed  to  "svn
                 checkout"

          target Name of the target directory where the checkout will  put
                 the working directory

          rev    None The name revision number to checkout. Enable "force"
                 if the directory already exists.

          user   None Name of the user  performing  repository  management
                 operations

          username
                 None The user to access the name repository with. The svn
                 default is the current user

          password
                 Connect to the Subversion server with this password

                 New in version 0.17.0.

          force  False Continue if conflicts are encountered

          externals
                 True Change to False to not checkout or update externals

          trust  False  Automatically  trust  the  remote  server.   SVN's
                 --trust-server-cert

   salt.states.sysctl
   Configuration of the Linux kernel using sysctl
   Control the kernel sysctl system.

      vm.swappiness:
        sysctl.present:
          - value: 20

   salt.states.sysctl.present(name, value, config=None)
          Ensure  that  the  named  sysctl  value  is  set  in  memory and
          persisted to the named configuration file.  The  default  sysctl
          configuration file is /etc/sysctl.conf

          name   The name of the sysctl value to edit

          value  The sysctl value to apply

          config The  location  of  the  sysctl configuration file. If not
                 specified, the proper location will be detected based  on
                 platform.

   salt.states.syslog_ng
   State module for syslog_ng
   maintainer
          Tibor Benke <[email protected]>

   maturity
          new

   depends
          cmd, ps, syslog_ng

   platform
          all

   Users  can  generate  syslog-ng configuration files from YAML format or
   use
          plain ones and reload, start, or stop their syslog-ng  by  using
          this module.

   Details
   The  service  module  is  not  available  on all system, so this module
   includes syslog_ng.reloaded, syslog_ng.stopped,  and  syslog_ng.started
   functions.   If the service module is available on the computers, users
   should use that.

   Users  can  generate  syslog-ng  configuration  with   syslog_ng.config
   function.  For more information see syslog-ng state usage.

   Syslog-ng configuration file format
   The syntax of a configuration snippet in syslog-ng.conf:
          object_type object_id {<options>};

   These  constructions  are  also  called  statements.  There are options
   inside of them:
          option(parameter1, parameter2); option2(parameter1, parameter2);

   You can find more information about syslog-ng's configuration syntax in
   the                Syslog-ng                Admin                guide:
   http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.5-guides/en/syslog-ng-ose-v3.5-guide-admin/html-single/index.html#syslog-ng.conf.5

   salt.states.syslog_ng.config(name, config, write=True)
          Builds syslog-ng configuration.

          name : the id of the Salt document config : the parsed YAML code
          write : if True, it writes  the config  into  the  configuration
          file, otherwise just returns it

   salt.states.syslog_ng.reloaded(name)
          Reloads syslog-ng.

   salt.states.syslog_ng.started(name=None,     user=None,     group=None,
   chroot=None, caps=None, no_caps=False, pidfile=None, enable_core=False,
   fd_limit=None,  verbose=False, debug=False, trace=False, yydebug=False,
   persist_file=None, control=None, worker_threads=None, *args, **kwargs)
          Ensures, that syslog-ng is started via the given parameters.

          Users shouldn't use this function,  if  the  service  module  is
          available on their system.

   salt.states.syslog_ng.stopped(name=None)
          Kills syslog-ng.

   salt.states.sysrc
   salt.states.sysrc.absent(name, **kwargs)
          Ensure a sysrc variable is absent.

          name   The variable name to set

          file   (optional) The rc file to add the variable to.

          jail   (option) the name or JID of the jail to set the value in.

   salt.states.sysrc.managed(name, value, **kwargs)
          Ensure a sysrc variable is set to a specific value.

          name   The variable name to set

          value  Value to set the variable to

          file   (optional) The rc file to add the variable to.

          jail   (option) the name or JID of the jail to set the value in.

          Example:

             syslogd:
               sysrc.managed:
                 - name: syslogd_flags
                 - value: -ss

   salt.states.telemetry_alert
   New in version 2016.3.0..

   Manage Telemetry alert configurations
   Create, Update and destroy Mongo Telemetry alert configurations.

   This module uses requests, which can be installed via package, or pip.

   This module accepts explicit credential (telemetry api key) or can also
   read api key credentials from a pillar.  Example:

      ensure telemetry alert X is defined on deployment Y:
          telemetry_alert.present:
              - deployment_id: "rs-XXXXXX"
              - metric_name: "testMetric"
              - alert_config:
                 max: 1
                 filter:  SERVER_ROLE_MONGOD_PRIMARY
                 escalate_to: "[email protected]"
              - name: "**MANAGED BY ORCA DO NOT EDIT BY HAND** manages alarm on testMetric"

   salt.states.telemetry_alert.absent(name,  deployment_id,   metric_name,
   api_key=None, profile='telemetry')
          Ensure the telemetry alert config is deleted

          name   An  optional  description  of  the  alarms (not currently
                 supported by telemetry API)

          deployment_id
                 Specifies the ID of the root deployment resource (replica
                 set  cluster  or  sharded  cluster)  to  which this alert
                 definition is attached

          metric_name
                 Specifies the unique ID of the  metric  to  whose  values
                 these thresholds will be applied

          api_key
                 Telemetry api key for the user

          profile
                 A  dict  with  telemetry config data. If present, will be
                 used instead of api_key.

   salt.states.telemetry_alert.present(name,  deployment_id,  metric_name,
   alert_config, api_key=None, profile='telemetry')
          Ensure the telemetry alert exists.

          name   An  optional  description  of  the  alarm  (not currently
                 supported by telemetry API)

          deployment_id
                 Specifies the ID of the root deployment resource (replica
                 set  cluster  or  sharded  cluster)  to  which this alert
                 definition is attached

          metric_name
                 Specifies the unique ID of the  metric  to  whose  values
                 these thresholds will be applied

          alert_config: Is a list of dictionaries where each dict contains
          the following fields:

                 filter By default the alert will apply to the  deployment
                        and  all  its constituent resources.  If the alert
                        only applies to a subset  of  those  resources,  a
                        filter may be specified to narrow this scope.

                 min    the smallest "ok" value the metric may take on; if
                        missing or null, no minimum is enforced.

                 max    the largest "ok" value the metric may take on;  if
                        missing or null, no maximum is enforced.

                 notify_all
                        Used  to  indicate  if  you  want  to  alert  both
                        onCallEngineer and apiNotifications

          api_key
                 Telemetry api key for the user

          profile
                 A dict of telemetry config information.  If present, will
                 be used instead of api_key.

   salt.states.test
   Test States
   Provide test case states that enable easy testing of things to do with
          state  calls,  e.g.  running, calling, logging, output filtering
          etc.

      always-passes-with-any-kwarg:
        test.nop:
          - name: foo
          - something: else
          - foo: bar

      always-passes:
        test.succeed_without_changes:
          - name: foo

      always-fails:
        test.fail_without_changes:
          - name: foo

      always-changes-and-succeeds:
        test.succeed_with_changes:
          - name: foo

      always-changes-and-fails:
        test.fail_with_changes:
          - name: foo

      my-custom-combo:
        test.configurable_test_state:
          - name: foo
          - changes: True
          - result: False
          - comment: bar.baz

      is-pillar-foo-present-and-bar-is-int:
        test.check_pillar:
          - present:
              - foo
          - integer:
              - bar

   salt.states.test.check_pillar(name,     present=None,     boolean=None,
   integer=None,      string=None,      listing=None,     dictionary=None,
   verbose=False)
          Checks the presence and, optionally, the type of given  keys  in
          Pillar.   Supported  kwargs  for  types  are: - boolean (bool) -
          integer (int) - string  (str)  -  listing  (list)  -  dictionary
          (dict)

          Checking for None type pillars is not implemented yet.

             is-pillar-foo-present-and-bar-is-int:
               test.check_pillar:
                 - present:
                     - foo
                 - integer:
                     - bar

   salt.states.test.configurable_test_state(name,            changes=True,
   result=True, comment='')
          A configurable test state which determines its output  based  on
          the inputs.

          New in version 2014.7.0.

          name:  A unique string.

          changes:
                 Do  we  return  anything  in  the changes field?  Accepts
                 True, False, and 'Random' Default is True

          result:
                 Do we return successfully or not?  Accepts  True,  False,
                 and  'Random' Default is True If test is True and changes
                 is True, this will be None.  If  test  is  True  and  and
                 changes is False, this will be True.

          comment:
                 String to fill the comment field with.  Default is ''

   salt.states.test.fail_with_changes(name)
          Returns failure and changes is not empty.

          New in version 2014.7.0.

          name:  A unique string.

   salt.states.test.fail_without_changes(name)
          Returns failure.

          New in version 2014.7.0.

          name:  A unique string.

   salt.states.test.mod_watch(name, sfun=None, **kwargs)
          Call this function via a watch statement

          New in version 2014.7.0.

          Any  parameters in the state return dictionary can be customized
          by adding the keywords result, comment, and changes.

             this_state_will_return_changes:
               test.succeed_with_changes

             this_state_will_NOT_return_changes:
               test.succeed_without_changes

             this_state_is_watching_another_state:
               test.succeed_without_changes:
                 - comment: 'This is a custom comment'
                 - watch:
                   - test: this_state_will_return_changes
                   - test: this_state_will_NOT_return_changes

             this_state_is_also_watching_another_state:
               test.succeed_without_changes:
                 - watch:
                   - test: this_state_will_NOT_return_changes

   salt.states.test.nop(name, **kwargs)
          A no-op state that does nothing. Useful in conjunction with  the
          use  requisite,  or  in templates which could otherwise be empty
          due to jinja rendering

          New in version 2015.8.1.

   salt.states.test.show_notification(name, text=None, **kwargs)
          Simple notification using text argument.

          New in version 2015.8.0.

          name   A unique string.

          text   Text to return in the comment.

   salt.states.test.succeed_with_changes(name)
          Returns successful and changes is not empty

          New in version 2014.7.0.

          name:  A unique string.

   salt.states.test.succeed_without_changes(name)
          Returns successful.

          New in version 2014.7.0.

          name   A unique string.

   salt.states.timezone
   Management of timezones
   The timezone can be managed for the system:

      America/Denver:
        timezone.system

   The system and the hardware clock are not necessarily set to  the  same
   time.   By  default, the hardware clock is set to localtime, meaning it
   is set to the same time as the system clock. If utc  is  set  to  True,
   then  the  hardware clock will be set to UTC, and the system clock will
   be an offset of that.

      America/Denver:
        timezone.system:
          - utc: True

   The Ubuntu community documentation  contains  an  explanation  of  this
   setting,  as it applies to systems that dual-boot with Windows. This is
   explained in greater detail here.

   salt.states.timezone.system(name, utc=True)
          Set the timezone for the system.

          name   The name of the timezone to use (e.g.: America/Denver)

          utc    Whether or not to set the hardware clock to UTC  (default
                 is True)

   salt.states.tls
   Enforce state for SSL/TLS
   salt.states.tls.valid_certificate(name,   weeks=0,   days=0,   hours=0,
   minutes=0, seconds=0)
          Verify that a TLS certificate is valid now and (optionally) will
          be  valid  for  the  time  specified through weeks, days, hours,
          minutes, and seconds.

   salt.states.tomcat
   Manage Apache Tomcat web applications
   NOTE:
      This state requires the Tomcat Manager webapp to  be  installed  and
      running.

   The  following grains/pillars must be set for communication with Tomcat
   Manager to work:

      tomcat-manager:
          user: 'tomcat-manager'
          passwd: 'Passw0rd'

   Configuring Tomcat Manager
   To manage webapps via the Tomcat Manager, you'll need  to  configure  a
   valid       user      in      the      file      conf/tomcat-users.xml.
   conf/tomcat-users.xml.INDENT 0.0

       <?xml version='1.0' encoding='utf-8'?>
       <tomcat-users>
           <role rolename="manager-script"/>
           <user username="tomcat-manager" password="Passw0rd" roles="manager-script"/>
       </tomcat-users>
   * Using multiple versions  (aka.  parallel  deployments)  on  the  same
     context path is not supported.

   * More       information       about      the      Tomcat      Manager:
     http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html

   * If you use only  this  module  for  deployments  you  might  want  to
     restrict access to the manager so it's only accessible via localhost.
     For                            more                             info:
     http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access

   *

     Last tested on:

            Tomcat Version:
                   Apache Tomcat/7.0.54

            JVM Vendor:
                   Oracle Corporation

            JVM Version:
                   1.8.0_101-b13

            OS Architecture:
                   amd64

            OS Name:
                   Linux

            OS Version:
                   3.10.0-327.22.2.el7.x86_64

   salt.states.tomcat.mod_watch(name, url='http://localhost:8080/manager',
   timeout=180)
          The  tomcat  watcher  function.   When called it will reload the
          webapp in question

   salt.states.tomcat.undeployed(name,
   url='http://localhost:8080/manager', timeout=180)
          Enforce that the WAR will be undeployed from the server

          name   The context path to undeploy.

          url    http://localhost:8080/manager  The URL of the server with
                 the Tomcat Manager webapp.

          timeout
                 180 Timeout for HTTP request to the Tomcat Manager.

          Example:

             jenkins:
               tomcat.undeployed:
                 - name: /ran
                 - require:
                   - service: application-service

   salt.states.tomcat.wait(name,      url='http://localhost:8080/manager',
   timeout=180)
          Wait for the Tomcat Manager to load.

          Notice  that if tomcat is not running we won't wait for it start
          and the state will fail. This  state  can  be  required  in  the
          tomcat.war_deployed  state  to  make  sure tomcat is running and
          that the manager is running as well and ready for deployment.

          url    http://localhost:8080/manager The URL of the server  with
                 the Tomcat Manager webapp.

          timeout
                 180 Timeout for HTTP request to the Tomcat Manager.

          Example:

             tomcat-service:
               service.running:
                 - name: tomcat
                 - enable: True

             wait-for-tomcatmanager:
               tomcat.wait:
                 - timeout: 300
                 - require:
                   - service: tomcat-service

             jenkins:
               tomcat.war_deployed:
                 - name: /ran
                 - war: salt://jenkins-1.2.4.war
                 - require:
                   - tomcat: wait-for-tomcatmanager

   salt.states.tomcat.war_deployed(name,         war,         force=False,
   url='http://localhost:8080/manager',                       timeout=180,
   temp_war_location=None, version='')
          Enforce that the WAR will be deployed and started in the context
          path, while making use of WAR versions in the filename.

          NOTE:
             For more info about Tomcats file paths  and  context  naming,
             please                                                    see
             http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming

          name   The  context path to deploy (incl. forward slash) the WAR
                 to.

          war    Absolute path to WAR file (should be  accessible  by  the
                 user   running   Tomcat)  or  a  path  supported  by  the
                 salt.modules.cp.get_url function.

          force  False Force deployment even if the  version  strings  are
                 the same.  Disabled by default.

          url    http://localhost:8080/manager  The  URL of the Tomcat Web
                 Application Manager.

          timeout
                 180 Timeout for HTTP requests to the Tomcat Manager.

          temp_war_location
                 None Use another location to  temporarily  copy  the  WAR
                 file to.  By default the system's temp directory is used.

          version
                 ''   Specify  the  WAR  version.   If  this  argument  is
                 provided, it overrides the version  encoded  in  the  WAR
                 file name, if one is present.

                 New in version 2015.8.6.

                 Use  False to prevent guessing the version and keeping it
                 blank.

                 New in version 2016.PLEASE_LET_ME_KNOW.

          Example:

             jenkins:
               tomcat.war_deployed:
                 - name: /ran
                 - war: salt://jenkins-1.2.4.war
                 - require:
                   - service: application-service

          NOTE:
             Be aware that in the above example the WAR  jenkins-1.2.4.war
             will be deployed to the context path jenkins##1.2.4. To avoid
             this either specify a version yourself,  or  set  version  to
             False.

   salt.states.trafficserver
   Control Apache Traffic Server
   New in version 2015.8.0.

   salt.states.trafficserver.bounce_cluster(name)
          Bounce all Traffic Server nodes in the cluster. Bouncing Traffic
          Server shuts  down  and  immediately  restarts  Traffic  Server,
          node-by-node.

             bounce_ats_cluster:
               trafficserver.bounce_cluster

   salt.states.trafficserver.bounce_local(name, drain=False)
          Bounce Traffic Server on the local node. Bouncing Traffic Server
          shuts down and immediately restarts the Traffic Server node.

          This  option  modifies  the  behavior  of  traffic_line  -b  and
          traffic_line  -L such that traffic_server is not shut down until
          the number of active client  connections  drops  to  the  number
          given    by   the   proxy.config.restart.active_client_threshold
          configuration variable.

             bounce_ats_local:
               trafficserver.bounce_local

             bounce_ats_local:
               trafficserver.bounce_local
                 - drain: True

   salt.states.trafficserver.clear_cluster(name)
          Clears accumulated statistics on all nodes in the cluster.

             clear_ats_cluster:
               trafficserver.clear_cluster

   salt.states.trafficserver.clear_node(name)
          Clears accumulated statistics on the local node.

             clear_ats_node:
               trafficserver.clear_node

   salt.states.trafficserver.config(name, value)
          Set Traffic Server configuration variable values.

             proxy.config.proxy_name:
               trafficserver.config:
                 - value: cdn.site.domain.tld

             OR

             traffic_server_setting:
               trafficserver.config:
                 - name: proxy.config.proxy_name
                 - value: cdn.site.domain.tld

   salt.states.trafficserver.offline(name, path)
          Mark  a  cache  storage  device  as  offline.  The  storage   is
          identified  by  a path which must match exactly a path specified
          in storage.config. This removes the storage from the  cache  and
          redirects  requests  that  would have used this storage to other
          storage. This has exactly the same effect as a disk failure  for
          that  storage.  This  does  not  persist  across restarts of the
          traffic_server process.

             offline_ats_path:
               trafficserver.offline:
                 - path: /path/to/cache

   salt.states.trafficserver.refresh(name)
          Initiate a Traffic Server configuration file  reread.  Use  this
          command   to   update   the   running  configuration  after  any
          configuration file modification.

          The timestamp of the  last  reconfiguration  event  (in  seconds
          since        epoch)        is       published       in       the
          proxy.node.config.reconfigure_time metric.

             refresh_ats:
               trafficserver.refresh

   salt.states.trafficserver.restart_cluster(name)
          Restart  the  traffic_manager  process  and  the  traffic_server
          process on all the nodes in a cluster.

             restart_ats_cluster:
               trafficserver.restart_cluster

   salt.states.trafficserver.restart_local(name, drain=False)
          Restart  the traffic_manager and traffic_server processes on the
          local node.

          This  option  modifies  the  behavior  of  traffic_line  -b  and
          traffic_line  -L such that traffic_server is not shut down until
          the number of active client  connections  drops  to  the  number
          given    by   the   proxy.config.restart.active_client_threshold
          configuration variable.

             restart_ats_local:
               trafficserver.restart_local

             restart_ats_local_drain:
               trafficserver.restart_local
                 - drain: True

   salt.states.trafficserver.set_var(name, value)
          Set Traffic Server configuration variable values.

          Deprecated  since  version  Oxygen:   Use   trafficserver.config
          instead.

             proxy.config.proxy_name:
               trafficserver.set_var:
                 - value: cdn.site.domain.tld

             OR

             traffic_server_setting:
               trafficserver.set_var:
                 - name: proxy.config.proxy_name
                 - value: cdn.site.domain.tld

   salt.states.trafficserver.shutdown(name)
          Shut down Traffic Server on the local node.

             shutdown_ats:
               trafficserver.shutdown

   salt.states.trafficserver.startup(name)
          Start Traffic Server on the local node.

             startup_ats:
               trafficserver.startup

   salt.states.trafficserver.zero_cluster(name)
          Reset performance statistics to zero across the cluster.

             zero_ats_cluster:
               trafficserver.zero_cluster

   salt.states.trafficserver.zero_node(name)
          Reset performance statistics to zero on the local node.

             zero_ats_node:
               trafficserver.zero_node

   salt.states.tuned
   Interface to Red Hat tuned-adm module

   maintainer
          Syed Ali <[email protected]>

   maturity
          new

   depends
          cmd.run

   platform
          Linux

   salt.states.tuned.off(name=None)
          Turns  'tuned'  off.   Example  tuned.sls file for turning tuned
          off:

          tuned: tuned.off: []

          To see a valid list of states call execution module:
                 tuned.list

   salt.states.tuned.profile(name)
          This state module allows you to modify system tuned parameters

          Example tuned.sls file to set profile to virtual-guest

          tuned:

                 tuned:

                        * profile

                        * name: virtual-guest

          name   tuned profile name to set the system to

          To see a valid list of states call execution module:
                 tuned.list

   salt.states.uptime
   Monitor Web Server with Uptime
   Uptime is an open source remote monitoring application  using  Node.js,
   MongoDB, and Twitter Bootstrap.

   WARNING:
      This state module is beta. It might be changed later to include more
      or less automation.

   NOTE:
      This state module requires a pillar to specify the location of  your
      uptime install

          uptime:
            application_url: "http://uptime-url.example.org"

   Example:

      url:
        uptime.monitored
      url/sitemap.xml:
        uptime.monitored:
           - polling: 600 # every hour

   salt.states.uptime.monitored(name, **params)
          Makes  sure  an  URL  is  monitored  by uptime. Checks if URL is
          already monitored, and if not, adds it.

   salt.states.user
   Management of user accounts
   The user module is used to create and manage user settings,  users  can
   be set as either absent or present

      fred:
        user.present:
          - fullname: Fred Jones
          - shell: /bin/zsh
          - home: /home/fred
          - uid: 4000
          - gid: 4000
          - groups:
            - wheel
            - storage
            - games

      testuser:
        user.absent

   salt.states.user.absent(name, purge=False, force=False)
          Ensure that the named user is absent

          name   The name of the user to remove

          purge  Set  purge  to  True to delete all of the user's files as
                 well as the user, Default is False.

          force  If the user is logged in, the absent state will fail. Set
                 the  force option to True to remove the user even if they
                 are logged in. Not  supported  in  FreeBSD  and  Solaris,
                 Default is False.

   salt.states.user.present(name, uid=None, gid=None, gid_from_name=False,
   groups=None,   optional_groups=None,   remove_groups=True,   home=None,
   createhome=True,           password=None,          hash_password=False,
   enforce_password=True, empty_password=False,  shell=None,  unique=True,
   system=False,     fullname=None,    roomnumber=None,    workphone=None,
   homephone=None, loginclass=None, date=None, mindays=None, maxdays=None,
   inactdays=None,    warndays=None,    expire=None,   win_homedrive=None,
   win_profile=None, win_logonscript=None, win_description=None)
          Ensure that  the  named  user  is  present  with  the  specified
          properties

          name   The name of the user to manage

          uid    The  user  id  to  assign,  if  left  empty then the next
                 available user id will be assigned

          gid    The default group id. Also accepts group name.

          gid_from_name
                 If True, the default group id will be set to  the  id  of
                 the  group  with  the  same  name as the user, Default is
                 False.

          groups A list of groups to assign  the  user  to,  pass  a  list
                 object.  If  a group specified here does not exist on the
                 minion, the state will fail.  If set to the  empty  list,
                 the  user  will  be  removed  from  all groups except the
                 default group. If unset, salt will assume current  groups
                 are still wanted (see issue #28706).

          optional_groups
                 A  list  of  groups  to  assign  the user to, pass a list
                 object. If a group specified here does not exist  on  the
                 minion, the state will silently ignore it.

          NOTE:  If  the  same  group  is  specified  in both "groups" and
          "optional_groups", then it will be assumed to  be  required  and
          not optional.

          remove_groups
                 Remove  groups  that the user is a member of that weren't
                 specified in the state, Default is True.

          home   The custom login directory of user. Uses default value of
                 underlying  system if not set. Notice that this directory
                 does not have to exist.  This also the  location  of  the
                 home directory to create if createhome is set to True.

          createhome
                 True  If  set  to  False,  the home directory will not be
                 created if it doesn't already exist.

                 WARNING:
                    Not supported on Windows or Mac OS.

                    Additionally, parent directories will not be  created.
                    The parent directory for home must already exist.

          password
                 A  password  hash to set for the user. This field is only
                 supported  on  Linux,  FreeBSD,  NetBSD,   OpenBSD,   and
                 Solaris.  If  the  empty_password argument is set to True
                 then password is ignored.  For Windows this is the  plain
                 text password.  For Linux, the hash can be generated with
                 openssl passwd -1.

          Changed in version 0.16.0: BSD support added.

          hash_password
                 Set to True to hash the clear text password.  Default  is
                 False.

          enforce_password
                 Set  to  False to keep the password from being changed if
                 it has already been set and  the  password  hash  differs
                 from  what  is  specified  in  the "password" field. This
                 option will be ignored if "password"  is  not  specified,
                 Default is True.

          empty_password
                 Set  to  True  to  enable  password-less  login for user,
                 Default is False.

          shell  The login shell, defaults to the system default shell

          unique Require a unique UID, Default is True.

          system Choose  UID  in  the  range   of   FIRST_SYSTEM_UID   and
                 LAST_SYSTEM_UID, Default is False.

          loginclass
                 The login class, defaults to empty (BSD only)

          User  comment  field  (GECOS) support (currently Linux, BSD, and
          MacOS only):

          The below  values  should  be  specified  as  strings  to  avoid
          ambiguities  when  the  values are loaded. (Especially the phone
          and room number fields which are likely to contain numeric data)

          fullname
                 The user's full name

          roomnumber
                 The user's room number (not supported in MacOS)

          workphone
                 The user's work phone number (not supported in MacOS)

          homephone
                 The user's home phone number (not supported in MacOS)

          Changed in version 2014.7.0: Shadow attribute support added.

          Shadow attributes support (currently Linux only):

          The below values should be specified as integers.

          date   Date of last change  of  password,  represented  in  days
                 since epoch (January 1, 1970).

          mindays
                 The minimum number of days between password changes.

          maxdays
                 The maximum number of days between password changes.

          inactdays
                 The  number  of  days  after a password expires before an
                 account is locked.

          warndays
                 Number of days prior to maxdays to warn users.

          expire Date that account  expires,  represented  in  days  since
                 epoch (January 1, 1970).

          The below parameters apply to windows only:

          win_homedrive (Windows Only)
                 The  drive  letter  to use for the home directory. If not
                 specified  the  home  directory  will  be  a  unc   path.
                 Otherwise  the  home  directory  will  be  mapped  to the
                 specified drive. Must be a letter followed  by  a  colon.
                 Because  of  the  colon,  the value must be surrounded by
                 single quotes. ie: - win_homedrive: 'U:

                 Changed in version 2015.8.0.

          win_profile (Windows Only)
                 The custom profile directory of the  user.  Uses  default
                 value of underlying system if not set.

                 Changed in version 2015.8.0.

          win_logonscript (Windows Only)
                 The  full  path  to the logon script to run when the user
                 logs in.

                 Changed in version 2015.8.0.

          win_description (Windows Only)
                 A brief description of the purpose of the users account.

                 Changed in version 2015.8.0.

   salt.states.vbox_guest
   VirtualBox Guest Additions installer state

   salt.states.vbox_guest.additions_installed(name,          reboot=False,
   upgrade_os=False)
          Ensure  that  the VirtualBox Guest Additions are installed. Uses
          the CD, connected by VirtualBox.

          name   The name has no functional value and is only  used  as  a
                 tracking reference.

          reboot False Restart OS to complete installation.

          upgrade_os
                 False Upgrade OS (to ensure the latests version of kernel
                 and developer tools installed).

   salt.states.vbox_guest.additions_removed(name, force=False)
          Ensure that the VirtualBox Guest Additions are removed. Uses the
          CD, connected by VirtualBox.

          To  connect  VirtualBox Guest Additions via VirtualBox graphical
          interface press 'Host+D' ('Host' is usually 'Right Ctrl').

          name   The name has no functional value and is only  used  as  a
                 tracking reference.

          force  Force VirtualBox Guest Additions removing.

   salt.states.vbox_guest.grant_access_to_shared_folders_to(name,
   users=None)
          Grant access to auto-mounted shared folders to the users.

          User is specified by it's name.  To  grant  access  for  several
          users use argument users.

          name   Name  of  the user to grant access to auto-mounted shared
                 folders to.

          users  List of names of users to grant  access  to  auto-mounted
                 shared  folders to.  If specified, name will not be taken
                 into account.

   salt.states.victorops
   Create an Event in VictorOps
   New in version 2015.8.0.

   This state is useful for  creating  events  on  the  VictorOps  service
   during state runs.

      webserver-warning-message:
        victorops.create_event:
          - message_type: 'CRITICAL'
          - entity_id: 'webserver/diskspace'
          - state_message: 'Webserver diskspace is low.'

   salt.states.victorops.create_event(name,                  message_type,
   routing_key='everyone', **kwargs)
          Create an event on the VictorOps service

             webserver-warning-message:
               victorops.create_event:
                 - message_type: 'CRITICAL'
                 - entity_id: 'webserver/diskspace'
                 - state_message: 'Webserver diskspace is low.'

             database-server-warning-message:
               victorops.create_event:
                 - message_type: 'WARNING'
                 - entity_id: 'db_server/load'
                 - state_message: 'Database Server load is high.'
                 - entity_is_host: True
                 - entity_display_name: 'dbdserver.example.com'

          The following parameters are required:

          name   This is a short description of the event.

          message_type
                 One   of   the   following   values:    INFO,    WARNING,
                 ACKNOWLEDGEMENT, CRITICAL, RECOVERY.

          The following parameters are optional:

             routing_key
                    The  key  for  where  messages  should  be  routed. By
                    default, sent to 'everyone' route.

             entity_id
                    The name of alerting entity. If not provided, a random
                    name will be assigned.

             timestamp
                    Timestamp   of  the  alert  in  seconds  since  epoch.
                    Defaults  to  the  time  the  alert  is  received   at
                    VictorOps.

             timestamp_fmt
                    The date format for the timestamp parameter.  Defaults
                    to ''%Y-%m-%dT%H:%M:%S'.

             state_start_time
                    The  time  this  entity  entered  its  current   state
                    (seconds  since  epoch). Defaults to the time alert is
                    received.

             state_start_time_fmt
                    The date format for the timestamp parameter.  Defaults
                    to '%Y-%m-%dT%H:%M:%S'.

             state_message
                    Any additional status information from the alert item.

             entity_is_host
                    Used   within  VictorOps  to  select  the  appropriate
                    display format for the incident.

             entity_display_name
                    Used within VictorOps to display a human-readable name
                    for the entity.

             ack_message
                    A user entered comment for the acknowledgment.

             ack_author
                    The user that acknowledged the incident.

   salt.states.virt module
   Manage virt
   For  the  key  certificate  this  state uses the external pillar in the
   master to call for the  generation  and  signing  of  certificates  for
   systems running libvirt:

      libvirt_keys:
        virt.keys

   salt.states.virt.keys(name, basepath='/etc/pki')
          Manage libvirt keys.

          name   The name variable used to track the execution

          basepath
                 Defaults  to /etc/pki, this is the root location used for
                 libvirt keys on the hypervisor

   salt.states.virt.powered_off(name)
          Stops a VM by power off.

          New in version 2016.3.0.

             domain_name:
               virt.stopped

   salt.states.virt.rebooted(name)
          Reboots VMs

          New in version 2016.3.0.

          Parameters
                 name --

          Returns

   salt.states.virt.reverted(name, snapshot=None, cleanup=False)
          Deprecated since version 2016.3.0.

          Reverts to the particular snapshot.

          New in version 2016.3.0.

             domain_name:
               virt.reverted:
                 - cleanup: True

             domain_name_1:
               virt.reverted:
                 - snapshot: snapshot_name
                 - cleanup: False

   salt.states.virt.running(name, **kwargs)
          Starts an existing guest, or defines and starts a  new  VM  with
          specified arguments.

          New in version 2016.3.0.

             domain_name:
               virt.running

             domain_name:
               virt.running:
                 - cpu: 2
                 - mem: 2048
                 - eth0_mac: 00:00:6a:53:00:e3

   salt.states.virt.saved(name, suffix=None)
          Deprecated since version 2016.3.0: Use snapshot() instead.

          Takes a snapshot of a particular VM or by a UNIX-style wildcard.

          New in version 2016.3.0.

             domain_name:
               virt.saved:
                 - suffix: periodic

             domain*:
               virt.saved:
                 - suffix: periodic

   salt.states.virt.snapshot(name, suffix=None)
          Takes a snapshot of a particular VM or by a UNIX-style wildcard.

          New in version 2016.3.0.

             domain_name:
               virt.snapshot:
                 - suffix: periodic

             domain*:
               virt.snapshot:
                 - suffix: periodic

   salt.states.virt.stopped(name)
          Stops a VM by shutting it down nicely.

          New in version 2016.3.0.

             domain_name:
               virt.stopped

   salt.states.virt.unpowered(name)
          Deprecated since version 2016.3.0: Use powered_off() instead.

          Stops a VM by power off.

          New in version 2016.3.0.

             domain_name:
               virt.stopped

   salt.states.virtualenv
   Setup of Python virtualenv sandboxes.

   New in version 0.17.0.

   salt.states.virtualenv_mod.managed(name,                 venv_bin=None,
   requirements=None,    system_site_packages=False,     distribute=False,
   use_wheel=False,   clear=False,   python=None,   extra_search_dir=None,
   never_download=None, prompt=None, user=None, no_chown=False,  cwd=None,
   index_url=None,        extra_index_url=None,        pre_releases=False,
   no_deps=False,       pip_download=None,        pip_download_cache=None,
   pip_exists_action=None,     pip_ignore_installed=False,     proxy=None,
   use_vt=False,  env_vars=None,  no_use_wheel=False,   pip_upgrade=False,
   pip_pkgs=None)
          Create a virtualenv and optionally manage it with pip

          name   Path to the virtualenv.

          requirements: None
                 Path  to a pip requirements file. If the path begins with
                 salt:// the file will be transferred from the master file
                 server.

          use_wheel: False
                 Prefer wheel archives (requires pip >= 1.4).

          python None Python executable used to build the virtualenv

          user: None
                 The user under which to run virtualenv and pip.

          no_chown: False
                 When  user  is  given, do not attempt to copy and chown a
                 requirements file (needed if the requirements file refers
                 to  other files via relative paths, as the copy-and-chown
                 procedure does not account for such files)

          cwd: None
                 Path to  the  working  directory  where  pip  install  is
                 executed.

          no_deps: False
                 Pass --no-deps to pip install.

          pip_exists_action: None
                 Default  action  of  pip  when  a  path  already  exists:
                 (s)witch, (i)gnore, (w)ipe, (b)ackup.

          proxy: None
                 Proxy address which is passed to pip install.

          env_vars: None
                 Set environment variables that some  builds  will  depend
                 on.  For  example,  a Python C-module may have a Makefile
                 that needs INCLUDE_PATH set to  pick  up  a  header  file
                 while compiling.

          no_use_wheel: False
                 Force to not use wheel archives (requires pip>=1.4)

          pip_upgrade: False
                 Pass --upgrade to pip install.

          pip_pkgs: None
                 As  an  alternative  to  requirements, pass a list of pip
                 packages that should be installed.

          Also  accepts  any  kwargs  that  the  virtualenv  module  will.
          However,  some  kwargs,  such  as  the  pip  option,  require  -
          distribute: True.

             /var/www/myvirtualenv.com:
               virtualenv.managed:
                 - system_site_packages: False
                 - requirements: salt://REQUIREMENTS.txt

   salt.states.win_certutil module
   Installing of certificates to the Windows Certificate Manager
   Install certificates to the Windows Certificate Manager

      salt://certs/cert.cer:
        certutil.add_store:
          - store: TrustedPublisher

   salt.states.win_certutil.add_store(name, store, saltenv='base')
          Store a certificate to the given store

          name   The certificate to store, this can  use  local  paths  or
                 salt:// paths

          store  The store to add the certificate to

          saltenv
                 The  salt  environment to use, this is ignored if a local
                 path is specified

   salt.states.win_certutil.del_store(name, store, saltenv='base')
          Remove a certificate in the given store

          name   The certificate to remove, this can use  local  paths  or
                 salt:// paths

          store  The store to remove the certificate from

          saltenv
                 The  salt  environment to use, this is ignored if a local
                 path is specified

   salt.states.win_dacl
   Windows Object Access Control Lists

   Ensure an ACL is present

          parameters:
                 name  -   the   path   of   the   object   objectType   -
                 Registry/File/Directory  user  -  user account or SID for
                 the ace permission - permission for the ace  (see  module
                 win_acl  for  available  permissions for each objectType)
                 acetype -  Allow/Deny propagation - how  the  ACL  should
                 apply  to child objects (see module win_acl for available
                 propagation types)

             addAcl:
               win_dacl.present:
                 - name: HKEY_LOCAL_MACHINE\SOFTWARE\mykey
                 - objectType: Registry
                 - user: FakeUser
                 - permission: FullControl
                 - acetype: ALLOW
                 - propagation: KEY&SUBKEYS

   Ensure an ACL does not exist

          parameters:
                 name  -   the   path   of   the   object   objectType   -
                 Registry/File/Directory  user  -  user account or SID for
                 the ace permission - permission for the ace  (see  module
                 win_acl  for  available  permissions for each objectType)
                 acetype -  Allow/Deny propagation - how  the  ACL  should
                 apply  to child objects (see module win_acl for available
                 propagation types)

          removeAcl:

                 win_dacl.absent:

                        * name: HKEY_LOCAL_MACHINESOFTWAREmykey

                        * objectType: Registry

                        * user: FakeUser

                        * permission: FulLControl

                        * acetype: ALLOW

                        * propagation: KEY&SUBKEYS

   Ensure an object is inheriting permissions

          parameters:
                 name  -   the   path   of   the   object   objectType   -
                 Registry/File/Directory clear_existing_acl - True/False -
                 when inheritance is enabled, should the existing  ACL  be
                 kept or cleared out

          eInherit:

                 win_dacl.enableinheritance:

                        * name: HKEY_LOCAL_MACHINESOFTWAREmykey

                        * objectType: Registry

                        * clear_existing_acl: True

   Ensure an object is not inheriting permissions

          parameters:
                 name   -   the   path   of   the   object   objectType  -
                 Registry/File/Directory copy_inherited_acl - True/False -
                 if   inheritance   is   enabled,   should  the  inherited
                 permissions be copied to  the  ACL  when  inheritance  is
                 disabled

          dInherit:

                 win_dacl.disableinheritance:

                        * name: HKEY_LOCAL_MACHINESOFTWAREmykey

                        * objectType: Registry

                        * copy_inherited_acl: False

   salt.states.win_dacl.absent(name,    objectType,    user,   permission,
   acetype, propagation)
          Ensure a Linux ACL does not exist

   salt.states.win_dacl.disinherit(name,                       objectType,
   copy_inherited_acl=True)
          Ensure an object is not inheriting ACLs from its parent

   salt.states.win_dacl.inherit(name,                          objectType,
   clear_existing_acl=False)
          Ensure an object is inheriting ACLs from its parent

   salt.states.win_dacl.present(name,   objectType,   user,    permission,
   acetype, propagation)
          Ensure an ACE is present

   salt.states.win_dism module
   Installing of Windows features using DISM
   Install windows features/capabilties with DISM

      Language.Basic~~~en-US~0.0.1.0:
        dism.capability_installed

      NetFx3:
        dism.feature_installed

   salt.states.win_dism.capability_installed(name,            source=None,
   limit_access=False, image=None, restart=False)
          Install a DISM capability

          Parameters

                 * name (str) -- The capability to install

                 * source (str) -- The optional source of the capability

                 * limit_access (bool) --  Prevent  DISM  from  contacting
                   Windows Update for online images

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example

          Run dism.available_capabilities  to  get  a  list  of  available
          capabilities. This will help you get the proper name to use.

             install_dotnet35:
               dism.capability_installed:
                 - name: NetFX3~~~~

   salt.states.win_dism.capability_removed(name,               image=None,
   restart=False)
          Uninstall a DISM capability

          Parameters

                 * name (str) -- The capability to uninstall

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example

          Run  dism.installed_capabilities  to  get  a  list  of installed
          capabilities. This will help you get the proper name to use.

             remove_dotnet35:
               dism.capability_removed:
                 - name: NetFX3~~~~

   salt.states.win_dism.feature_installed(name, package=None, source=None,
   limit_access=False, enable_parent=False, image=None, restart=False)
          Install a DISM feature

          Parameters

                 * name (str) -- The feature in which to install

                 * package  (Optional[str])  -- The parent package for the
                   feature. You do not have to specify the package  if  it
                   is  the  Windows  Foundation  Package.   Otherwise, use
                   package to specify the parent package of the feature

                 * source (str) -- The optional source of the feature

                 * limit_access (bool) --  Prevent  DISM  from  contacting
                   Windows Update for online images

                 * enable_parent  (Optional[bool]) -- True will enable all
                   parent features of the specified feature

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example

          Run dism.available_features to get a list of available features.
          This will help you get the proper name to use.

             install_telnet_client:
               dism.feature_installed:
                 - name: TelnetClient

   salt.states.win_dism.feature_removed(name,        remove_payload=False,
   image=None, restart=False)
          Disables a feature.

          Parameters

                 * name (str) -- The feature to disable

                 * remove_payload (Optional[bool]) -- Remove the feature's
                   payload.  Must  supply  source  when  enabling  in  the
                   future.

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example

          Run dism.installed_features to get a list of installed features.
          This will help you get the proper name to use.

             remove_telnet_client:
               dism.feature_removed:
                 - name: TelnetClient
                 - remove_payload: True

   salt.states.win_dism.package_installed(name,        ignore_check=False,
   prevent_pending=False, image=None, restart=False)
          Install a package.

          Parameters

                 * name (str) -- The package to install.  Can  be  a  .cab
                   file, a .msu file, or a folder

                 * ignore_check  (Optional[bool])  -- Skip installation of
                   the package if the applicability checks fail

                 * prevent_pending   (Optional[bool])    --    Skip    the
                   installation of the package if there are pending online
                   actions

                 * image (Optional[str]) -- The path to the root directory
                   of  an  offline  Windows  image. If None is passed, the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example.INDENT 7.0

      install_KB123123123:
        dism.package_installed:
          - name: C:\Packages\KB123123123.cab

   salt.states.win_dism.package_removed(name, image=None, restart=False)
          Uninstall a package

          Parameters

                 * name  (str)  --  The  full  path to the package. Can be
                   either a .cab file or a folder.  Should  point  to  the
                   original  source  of the package, not to where the file
                   is installed. This can also be the name of a package as
                   listed in dism.installed_packages

                 * image (Optional[str]) -- The path to the root directory
                   of an offline Windows image. If  None  is  passed,  the
                   running operating system is targeted. Default is None.

                 * restart  (Optional[bool])  --  Reboot  the  machine  if
                   required by the install
          Example.INDENT 7.0

      # Example using source
      remove_KB1231231:
        dism.package_installed:
          - name: C:\Packages\KB1231231.cab

      # Example using name from ``dism.installed_packages``
      remove_KB1231231:
        dism.package_installed:
          - name: Package_for_KB1231231~31bf3856ad364e35~amd64~~10.0.1.3

   salt.states.win_dns_client
   Module for configuring DNS Client on Windows systems

   salt.states.win_dns_client.dns_dhcp(name,     interface='Local     Area
   Connection')
          Configure the DNS server list from DHCP Server

   salt.states.win_dns_client.dns_exists(name,               servers=None,
   interface='Local Area Connection', replace=False)
          Configure the DNS server list in the specified interface

          Example:

             config_dns_servers:
               win_dns_client.dns_exists:
                 - replace: True #remove any servers not in the "servers" list, default is False
                 - servers:
                   - 8.8.8.8
                   - 8.8.8.9

   salt.states.win_dns_client.primary_suffix(name,            suffix=None,
   updates=False)
          New in version 2014.7.0.

          Configure the global primary DNS suffix of a DHCP client.

          suffix None  The suffix which is advertised for this client when
                 acquiring a DHCP lease When none is set,  the  explicitly
                 configured DNS suffix will be removed.

          updates
                 False  Allow  syncing  the  DNS suffix with the AD domain
                 when the client's AD domain membership changes

             primary_dns_suffix:
                 win_dns_client.primary_suffix:
                     - suffix: sub.domain.tld
                     - updates: True

   salt.states.win_firewall
   State for configuring Windows Firewall

   salt.states.win_firewall.add_rule(name,   localport,    protocol='tcp',
   action='allow', dir='in')
          Add a new firewall rule (Windows only)

   salt.states.win_firewall.disabled(name='allprofiles')
          Disable all the firewall profiles (Windows only)

   salt.states.win_firewall.enabled(name='allprofiles')
          Enable all the firewall profiles (Windows only)

   salt.states.win_iis module
   Microsoft IIS site management

   This module provides the ability to add/remove websites and application
   pools from Microsoft IIS.

   New in version 2016.3.0.

   salt.states.win_iis.container_setting(name, container, settings=None)
          Set the value of the setting for an IIS container.

          Parameters

                 * name (str) -- The name of the IIS container.

                 * container (str) --  The  type  of  IIS  container.  The
                   container types are: AppPools, Sites, SslBindings

                 * settings (str) -- A dictionary of the setting names and
                   their values.

          Example of usage for the AppPools container:

             site0-apppool-setting:
                 win_iis.container_setting:
                     - name: site0
                     - container: AppPools
                     - settings:
                         managedPipelineMode: Integrated
                         processModel.maxProcesses: 1
                         processModel.userName: TestUser
                         processModel.password: TestPassword

          Example of usage for the Sites container:

             site0-site-setting:
                 win_iis.container_setting:
                     - name: site0
                     - container: Sites
                     - settings:
                         logFile.logFormat: W3C
                         logFile.period: Daily
                         limits.maxUrlSegments: 32

   salt.states.win_iis.create_app(name, site, sourcepath, apppool=None)
          Create an IIS application.

          Parameters

                 * name (str) -- The IIS application.

                 * site (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path.

                 * apppool (str) -- The name of the IIS application pool.

          Example of usage with only the required arguments:

             site0-v1-app:
                 win_iis.create_app:
                     - name: v1
                     - site: site0
                     - sourcepath: C:\inetpub\site0\v1

          Example of usage specifying all available arguments:

             site0-v1-app:
                 win_iis.create_app:
                     - name: v1
                     - site: site0
                     - sourcepath: C:\inetpub\site0\v1
                     - apppool: site0

   salt.states.win_iis.create_apppool(name)
          Create an IIS application pool.

          Parameters
                 name (str) -- The name of the IIS application pool.

          Usage:

             site0-apppool:
                 win_iis.create_apppool:
                     - name: site0

   salt.states.win_iis.create_binding(name,      site,      hostheader='',
   ipaddress='*', port=80, protocol='http', sslflags=0)
          Create an IIS binding.

          Parameters

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * protocol  (str)  --  The  application  protocol  of the
                   binding.

                 * sslflags (str) -- The  flags  representing  certificate
                   type and storage of the binding.

          Example of usage with only the required arguments:

             site0-https-binding:
                 win_iis.create_binding:
                     - site: site0

          Example of usage specifying all available arguments:

             site0-https-binding:
                 win_iis.create_binding:
                     - site: site0
                     - hostheader: site0.local
                     - ipaddress: '*'
                     - port: 443
                     - protocol: https
                     - sslflags: 0

   salt.states.win_iis.create_cert_binding(name,    site,   hostheader='',
   ipaddress='*', port=443, sslflags=0)
          Assign a certificate to an IIS binding.

          Parameters

                 * name (str) -- The thumbprint of the certificate.

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * sslflags (str) -- Flags representing  certificate  type
                   and certificate storage of the binding.

          Example of usage with only the required arguments:

             site0-cert-binding:
                 win_iis.create_cert_binding:
                     - name: 9988776655443322111000AAABBBCCCDDDEEEFFF
                     - site: site0

          Example of usage specifying all available arguments:

             site0-cert-binding:
                 win_iis.create_cert_binding:
                     - name: 9988776655443322111000AAABBBCCCDDDEEEFFF
                     - site: site0
                     - hostheader: site0.local
                     - ipaddress: 192.168.1.199
                     - port: 443
                     - sslflags: 1

          New in version 2016.11.0.

   salt.states.win_iis.create_vdir(name, site, sourcepath, app='/')
          Create an IIS virtual directory.

          Parameters

                 * name (str) -- The virtual directory name.

                 * site (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path.

                 * app (str) -- The IIS application.

          Example of usage with only the required arguments:

             site0-foo-vdir:
                 win_iis.create_vdir:
                     - name: foo
                     - site: site0
                     - sourcepath: C:\inetpub\vdirs\foo

          Example of usage specifying all available arguments:

             site0-foo-vdir:
                 win_iis.create_vdir:
                     - name: foo
                     - site: site0
                     - sourcepath: C:\inetpub\vdirs\foo
                     - app: v1

   salt.states.win_iis.deployed(name,        sourcepath,       apppool='',
   hostheader='', ipaddress='*', port=80, protocol='http')
          Ensure the website has been deployed.

          Parameters

                 * name (str) -- The IIS site name.

                 * sourcepath (str) -- The physical path of the IIS site.

                 * apppool (str) -- The name of the IIS application pool.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

                 * protocol (str)  --  The  application  protocol  of  the
                   binding.

          Example  of  usage  with  only the required arguments. This will
          default to using the default application pool assigned by IIS:

             site0-deployed:
                 win_iis.deployed:
                     - name: site0
                     - sourcepath: C:\inetpub\site0

          Example of usage specifying all available arguments:

             site0-deployed:
                 win_iis.deployed:
                     - name: site0
                     - sourcepath: C:\inetpub\site0
                     - apppool: site0
                     - hostheader: site0.local
                     - ipaddress: '*'
                     - port: 443
                     - protocol: https

   salt.states.win_iis.remove_app(name, site)
          Remove an IIS application.

          Parameters

                 * name (str) -- The application name.

                 * site (str) -- The IIS site name.

          Usage:

             site0-v1-app-remove:
                 win_iis.remove_app:
                     - name: v1
                     - site: site0

   salt.states.win_iis.remove_apppool(name)
          Remove an IIS application pool.

          Parameters
                 name (str) -- The name of the IIS application pool.

          Usage:

             defaultapppool-remove:
                 win_iis.remove_apppool:
                     - name: DefaultAppPool

   salt.states.win_iis.remove_binding(name,      site,      hostheader='',
   ipaddress='*', port=80)
          Remove an IIS binding.

          Parameters

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

          Example of usage with only the required arguments:

             site0-https-binding-remove:
                 win_iis.remove_binding:
                     - site: site0

          Example of usage specifying all available arguments:

             site0-https-binding-remove:
                 win_iis.remove_binding:
                     - site: site0
                     - hostheader: site0.local
                     - ipaddress: '*'
                     - port: 443

   salt.states.win_iis.remove_cert_binding(name,    site,   hostheader='',
   ipaddress='*', port=443)
          Remove a certificate from an IIS binding.

          Parameters

                 * name (str) -- The thumbprint of the certificate.

                 * site (str) -- The IIS site name.

                 * hostheader (str) -- The host header of the binding.

                 * ipaddress (str) -- The IP address of the binding.

                 * port (str) -- The TCP port of the binding.

          Example of usage with only the required arguments:

             site0-cert-binding-remove:
                 win_iis.remove_cert_binding:
                     - name: 9988776655443322111000AAABBBCCCDDDEEEFFF
                     - site: site0

          Example of usage specifying all available arguments:

             site0-cert-binding-remove:
                 win_iis.remove_cert_binding:
                     - name: 9988776655443322111000AAABBBCCCDDDEEEFFF
                     - site: site0
                     - hostheader: site0.local
                     - ipaddress: 192.168.1.199
                     - port: 443

          New in version 2016.11.0.

   salt.states.win_iis.remove_site(name)
          Delete a website from IIS.

          Parameters
                 name (str) -- The IIS site name.

          Usage:

             defaultwebsite-remove:
                 win_iis.remove_site:
                     - name: Default Web Site

   salt.states.win_iis.remove_vdir(name, site, app='/')
          Remove an IIS virtual directory.

          Parameters

                 * name (str) -- The virtual directory name.

                 * site (str) -- The IIS site name.

                 * app (str) -- The IIS application.

          Example of usage with only the required arguments:

             site0-foo-vdir-remove:
                 win_iis.remove_vdir:
                     - name: foo
                     - site: site0

          Example of usage specifying all available arguments:

             site0-foo-vdir-remove:
                 win_iis.remove_vdir:
                     - name: foo
                     - site: site0
                     - app: v1

   salt.states.win_license module
   Installation and activation of windows licenses
   Install and activate windows licenses

      XXXXX-XXXXX-XXXXX-XXXXX-XXXXX:
        license.activate

   salt.states.win_license.activate(name)
          Install and activate the given product key

          name   The 5x5 product key given to you by Microsoft

   salt.states.win_network
   Configuration of network interfaces on Windows hosts
   New in version 2014.1.0.

   This module  provides  the  network  state(s)  on  Windows  hosts.  DNS
   servers, IP addresses and default gateways can currently be managed.

   Below  is  an  example  of the configuration for an interface that uses
   DHCP for both DNS servers and IP addresses:

      Local Area Connection #2:
        network.managed:
          - dns_proto: dhcp
          - ip_proto: dhcp

   NOTE:
      Both the dns_proto and ip_proto arguments are required.

   Static DNS and IP addresses can be configured like so:

      Local Area Connection #2:
        network.managed:
          - dns_proto: static
          - dns_servers:
            - 8.8.8.8
            - 8.8.4.4
          - ip_proto: static
          - ip_addrs:
            - 10.2.3.4/24

   NOTE:
      IP     addresses     are     specified     using     the      format
      <ip-address>/<subnet-length>.  Salt  provides a convenience function
      called ip.get_subnet_length to calculate the subnet  length  from  a
      netmask.

   Optionally,  if  you  are  setting  a  static  IP address, you can also
   specify the default gateway using the gateway parameter:

      Local Area Connection #2:
        network.managed:
          - dns_proto: static
          - dns_servers:
            - 8.8.8.8
            - 8.8.4.4
          - ip_proto: static
          - ip_addrs:
            - 10.2.3.4/24
          - gateway: 10.2.3.1

   salt.states.win_network.managed(name, dns_proto=None, dns_servers=None,
   ip_proto=None, ip_addrs=None, gateway=None, enabled=True, **kwargs)
          Ensure that the named interface is configured properly.

          name   The name of the interface to manage

          dns_proto
                 None  Set  to static and use the dns_servers parameter to
                 provide a list of DNS nameservers. set  to  dhcp  to  use
                 DHCP to get the DNS servers.

          dns_servers
                 None A list of static DNS servers.

          ip_proto
                 None  Set to static and use the ip_addrs and (optionally)
                 gateway  parameters  to  provide  a  list  of  static  IP
                 addresses  and  the  default  gateway. Set to dhcp to use
                 DHCP.

          ip_addrs
                 None A list of static IP addresses.

          gateway
                 None A list of static IP addresses.

          enabled
                 True Set to  False  to  ensure  that  this  interface  is
                 disabled.

   salt.states.win_path
   Manage the Windows System PATH

   salt.states.win_path.absent(name)
          Remove the directory from the SYSTEM path

          index:  where  the  directory  should  be  placed  in  the  PATH
          (default: 0)

          Example:

             'C:\sysinternals':
               win_path.absent

   salt.states.win_path.exists(name, index=None)
          Add the directory to the system PATH at index location

          index:  where  the  directory  should  be  placed  in  the  PATH
          (default: None) [Note:  Providing no index will append directory
          to PATH and will not enforce its location within the PATH.]

          Example:

             'C:\python27':
               win_path.exists

             'C:\sysinternals':
               win_path.exists:
                 - index: 0

   salt.states.win_powercfg
   This module allows you to control  the  power  settings  of  a  windows
   minion via powercfg.

   New in version 2015.8.0.

      monitor:
          powercfg.set_timeout:
              - value: 30
              - power: dc

   salt.states.win_powercfg.set_timeout(name, value, power='ac')
          Set the sleep timeouts of specific items such as disk, monitor.

          CLI Example:

             monitor:
                 powercfg.set_timeout:
                     - value: 30
                     - power: dc

             disk:
                 powercfg.set_timeout:
                     - value: 12
                     - power: ac

          name   The  setting  to  change,  can  be  one of the following:
                 monitor, disk, standby, hibernate

          timeout
                 The amount of  time  in  minutes  before  the  item  will
                 timeout i.e the monitor

          power  Should  we  set  the  value for AC or DC (battery)? Valid
                 options ac,dc.

   salt.states.win_servermanager
   Manage Windows features via the ServerManager powershell module

   salt.states.win_servermanager.installed(name,            recurse=False,
   force=False, restart=False, source=None, exclude=None)
          Install the windows feature

          Parameters

                 * name  (str)  --  Short  name  of the feature (the right
                   column in win_servermanager.list_available)

                 * recurse (Optional[bool]) -- install all sub-features as
                   well

                 * force  (Optional[bool])  -- if the feature is installed
                   but one of its sub-features are not installed set  this
                   to True to force the installation of the sub-features

                 * source  (Optional[str])  -- Path to the source files if
                   missing from the target system.  None  means  that  the
                   system  will  use  windows  update services to find the
                   required files. Default is None

                 * restart (Optional[bool]) -- Restarts the computer  when
                   installation   is   complete,   if   required   by  the
                   role/feature installed. Default is False

                 * exclude (Optional[str]) -- The name of the  feature  to
                   exclude when installing the named feature.

          restart:
                 Restarts  the  computer when installation is complete, if
                 restarting is required by the role feature installed.

          NOTE:
             Some features require reboot after  un/installation.  If  so,
             until  the  server  is  restarted  other  features can not be
             installed!
          Example

          Run salt MinionName win_servermanager.list_available  to  get  a
          list  of available roles and features. Use the name in the right
          column. Do not use the role or feature names  mentioned  in  the
          PKGMGR documentation.  In this example for IIS-WebServerRole the
          name to be used is Web-Server.

             ISWebserverRole:
               win_servermanager.installed:
                 - force: True
                 - recurse: True
                 - name: Web-Server

   salt.states.win_servermanager.removed(name,       remove_payload=False,
   restart=False)
          Remove the windows feature

          Parameters

                 * name  (str)  --  Short  name  of the feature (the right
                   column in win_servermanager.list_available)

                 * remove_payload (Optional[bool]) -- True will  case  the
                   feature to be removed from the side-by-side store

                 * restart  (Optional[bool]) -- Restarts the computer when
                   uninstall is complete, if required by the  role/feature
                   removed. Default is False

          NOTE:
             Some  features  require  a reboot after uninstallation. If so
             the feature will not  be  completely  uninstalled  until  the
             server is restarted.
          Example

          Run  salt  MinionName  win_servermanager.list_installed to get a
          list of all features installed. Use the top name listed for each
          feature,  not  the  indented one. Do not use the role or feature
          names mentioned in the PKGMGR documentation.

             ISWebserverRole:
               win_servermanager.removed:
                 - name: Web-Server

   salt.states.win_smtp_server module
   Module for managing IIS SMTP server configuration on Windows servers.

   salt.states.win_smtp_server.active_log_format(name,         log_format,
   server='SmtpSvc/1')
          Manage the active log format for the SMTP server.

          Parameters

                 * log_format (str) -- The log format name.

                 * server (str) -- The SMTP server name.

          Example of usage:

             smtp-log-format:
                 win_smtp_server.active_log_format:
                     - log_format: Microsoft IIS Log File Format

   salt.states.win_smtp_server.connection_ip_list(name,    addresses=None,
   grant_by_default=False, server='SmtpSvc/1')
          Manage IP list for SMTP connections.

          Parameters

                 * addresses (str) -- A dictionary of IP + subnet pairs.

                 * grant_by_default (bool) -- Whether the addresses should
                   be a blacklist or whitelist.

                 * server (str) -- The SMTP server name.

          Example of usage for creating a whitelist:

             smtp-connection-whitelist:
                 win_smtp_server.connection_ip_list:
                     - addresses:
                         127.0.0.1: 255.255.255.255
                         172.16.1.98: 255.255.255.255
                         172.16.1.99: 255.255.255.255
                     - grant_by_default: False

          Example of usage for creating a blacklist:

             smtp-connection-blacklist:
                 win_smtp_server.connection_ip_list:
                     - addresses:
                         172.16.1.100: 255.255.255.255
                         172.16.1.101: 255.255.255.255
                     - grant_by_default: True

          Example of usage for allowing any source to connect:

             smtp-connection-blacklist:
                 win_smtp_server.connection_ip_list:
                     - addresses: {}
                     - grant_by_default: True

   salt.states.win_smtp_server.relay_ip_list(name,         addresses=None,
   server='SmtpSvc/1')
          Manage IP list for SMTP relay connections.

          Due to the unusual way that Windows stores the relay IPs, it  is
          advisable  to  retrieve the existing list you wish to set from a
          pre-configured server.

          For example, setting '127.0.0.1' as an allowed relay IP  through
          the  GUI  would  generate an actual relay IP list similar to the
          following:

             ['24.0.0.128', '32.0.0.128', '60.0.0.128', '68.0.0.128', '1.0.0.0', '76.0.0.0',
               '0.0.0.0', '0.0.0.0', '1.0.0.0', '1.0.0.0', '2.0.0.0', '2.0.0.0', '4.0.0.0',
               '0.0.0.0', '76.0.0.128', '0.0.0.0', '0.0.0.0', '0.0.0.0', '0.0.0.0',
               '255.255.255.255', '127.0.0.1']

          NOTE:
             Setting the list to None corresponds to the restrictive 'Only
             the  list  below'  GUI  parameter  with  an empty access list
             configured, and setting an empty  list/tuple  corresponds  to
             the   more   permissive  'All  except  the  list  below'  GUI
             parameter.

          Parameters

                 * addresses (str) -- A list of the relay IPs.  The  order
                   of the list is important.

                 * server (str) -- The SMTP server name.

          Example of usage:

             smtp-relay-list:
               win_smtp_server.relay_ip_list:
                 - addresses:
                     - 24.0.0.128
                     - 32.0.0.128
                     - 60.0.0.128
                     - 1.0.0.0
                     - 76.0.0.0
                     - 0.0.0.0
                     - 0.0.0.0
                     - 1.0.0.0
                     - 1.0.0.0
                     - 2.0.0.0
                     - 2.0.0.0
                     - 4.0.0.0
                     - 0.0.0.0
                     - 76.0.0.128
                     - 0.0.0.0
                     - 0.0.0.0
                     - 0.0.0.0
                     - 0.0.0.0
                     - 255.255.255.255
                     - 127.0.0.1

          Example of usage for disabling relaying:

             smtp-relay-list:
                 win_smtp_server.relay_ip_list:
                     - addresses: None

          Example of usage for allowing relaying from any source:

             smtp-relay-list:
                 win_smtp_server.relay_ip_list:
                     - addresses: []

   salt.states.win_smtp_server.server_setting(name,         settings=None,
   server='SmtpSvc/1')
          Ensure the value is set for the specified setting.

          NOTE:
             The setting names are case-sensitive.

          Parameters

                 * settings (str) -- A dictionary of the setting names and
                   their values.

                 * server (str) -- The SMTP server name.

          Example of usage:

             smtp-settings:
                 win_smtp_server.server_setting:
                     - settings:
                         LogType: 1
                         LogFilePeriod: 1
                         MaxMessageSize: 16777216
                         MaxRecipients: 10000
                         MaxSessionSize: 16777216

   salt.states.win_system
   Management of Windows system information
   New in version 2014.1.0.

   This  state  is  used to manage system information such as the computer
   name and description.

      ERIK-WORKSTATION:
        system.computer_name: []

      This is Erik's computer, don't touch!:
        system.computer_desc: []

   salt.states.win_system.computer_desc(name)
          Manage the computer's description field

          name   The desired computer description

   salt.states.win_system.computer_name(name)
          Manage the computer's name

          name   The desired computer name

   salt.states.win_system.hostname(name)
          New in version 2016.3.0.

          Manage the hostname of the computer

          name   The hostname to set

   salt.states.win_system.join_domain(name, username=None,  password=None,
   account_ou=None, account_exists=False, restart=False)
          Checks  if  a computer is joined to the Domain.  If the computer
          is not in the Domain, it will be joined.

          name:  The name of the Domain.

          username:
                 Username of  an  account  which  is  authorized  to  join
                 computers  to  the  specified  domain.  Need to be either
                 fully qualified like [email protected] or simply user.

          password:
                 Password of the  account  to  add  the  computer  to  the
                 Domain.

          account_ou:
                 The  DN  of  the  OU  below  which  the  account for this
                 computer should be created when joining the domain,  e.g.
                 ou=computers,ou=departm_432,dc=my-company,dc=com.

          account_exists:
                 Needs  to  be  set  to True to allow re-using an existing
                 computer account.

          restart:
                 Needs to be set to True to restart the computer  after  a
                 successful join.

   salt.states.win_update
   Management of the windows update agent
   New in version 2014.7.0.

   Set  windows updates to run by category. Default behavior is to install
   all updates that do not require user interaction to complete.

   Optionally set category to a category of your choice  to  only  install
   certain updates. Default is to set to install all available updates.

   The  following  example will install all Security and Critical Updates,
   and download but not install standard updates.

      updates:
        win_update.installed:
          - categories:
            - 'Critical Updates'
            - 'Security Updates'
          - skips:
            - downloaded
        win_update.downloaded:
          - categories:
            - 'Updates'
          - skips:
            - downloaded

   You can also specify a number of features about the update  to  have  a
   fine  grain  approach  to  specific  types  of  updates.  These are the
   following features/states of updates available for configuring:

      'UI' - User interaction required, skipped by default
      'downloaded' - Already downloaded, included by default
      'present' - Present on computer, skipped by default
      'installed' - Already installed, skipped by default
      'reboot' - Reboot required, included by default
      'hidden' - Skip updates that have been hidden, skipped by default
      'software' - Software updates, included by default
      'driver' - driver updates, included by default

   The following example installs all driver updates that don't require  a
   reboot:

      gryffindor:

             win_update.installed:

                    * skips:  -  driver:  True - software: False - reboot:
                      False

   To just update your windows machine, add this your sls:

      updates:
        win_update.installed

   salt.states.win_update.downloaded(name,  categories=None,   skips=None,
   retries=10)
          Cache updates for later install.

          name:  if  categories is left empty, it will be assumed that you
                 are passing the category option through the  name.  These
                 are  separate because you can only have one name, but can
                 have multiple categories.

          categories:
                 the list of categories to be downloaded. These are simply
                 strings  in  the  update's  information,  so  there is no
                 enumeration  of  the  categories  available.  Some  known
                 categories:

                    Updates
                    Windows 7
                    Critical Updates
                    Security Updates
                    Update Rollups

          skips: a  list  of features of the updates to cull by. Available
                 features:

                    'UI' - User interaction required, skipped by default
                    'downloaded' - Already downloaded, skipped by default (downloading)
                    'present' - Present on computer, included by default (installing)
                    'installed' - Already installed, skipped by default
                    'reboot' - Reboot required, included by default
                    'hidden' - skip those updates that have been hidden.
                    'software' - Software updates, included by default
                    'driver' - driver updates, skipped by default

          retries
                 Number of retries to  make  before  giving  up.  This  is
                 total, not per step.

   salt.states.win_update.installed(name,   categories=None,   skips=None,
   retries=10)
          Install specified windows updates.

          name:  if categories is left empty, it will be assumed that  you
                 are  passing  the category option through the name. These
                 are separate because you can only have one name, but  can
                 have multiple categories.

          categories:
                 the list of categories to be downloaded. These are simply
                 strings in the  update's  information,  so  there  is  no
                 enumeration  of  the  categories  available.  Some  known
                 categories:

                    Updates
                    Windows 7
                    Critical Updates
                    Security Updates
                    Update Rollups

          skips: a list of features of the updates to cull  by.  Available
                 features:

                    'UI' - User interaction required, skipped by default
                    'downloaded' - Already downloaded, skipped by default (downloading)
                    'present' - Present on computer, included by default (installing)
                    'installed' - Already installed, skipped by default
                    'reboot' - Reboot required, included by default
                    'hidden' - skip those updates that have been hidden.
                    'software' - Software updates, included by default
                    'driver' - driver updates, skipped by default

          retries
                 Number  of  retries  to  make  before  giving up. This is
                 total, not per step.

   salt.states.winrepo
   Manage Windows Package Repository

   salt.states.winrepo.genrepo(name, force=False, allow_empty=False)
          Refresh  the  winrepo.p  file  of   the   repository   (salt-run
          winrepo.genrepo)

          If  force is True no checks will be made and the repository will
          be generated if allow_empty is True  then  the  state  will  not
          return an error if there are 0 packages,

          NOTE:
             This  state  only  loads  on  minions  that  have  the roles:
             salt-master grain set.

          Example:

             winrepo:
               winrepo.genrepo

   salt.states.x509
   Manage X509 Certificates

   New in version 2015.8.0.

   depends
          M2Crypto

   This module can enable managing a complete PKI infrastructure including
   creating  private  keys,  CA's,  certificates and CRLs. It includes the
   ability  to  generate  a  private  key  on  a  server,  and  have   the
   corresponding  public  key  sent  to  a remote CA to create a CA signed
   certificate. This can be done in a secure manner,  where  private  keys
   are always generated locally and never moved across the network.

   Here is a simple example scenario. In this example ca is the ca server,
   and www is a web server that needs a certificate signed by ca.

   For remote signing, peers  must  be  permitted  to  remotely  call  the
   sign_remote_certificate function.

   /etc/salt/master.d/peer.conf

      peer:
        .*:
          - x509.sign_remote_certificate

   /srv/salt/top.sls

      base:
        '*':
          - cert
        'ca':
          - ca
        'www':
          - www

   This  state creates the CA key, certificate and signing policy. It also
   publishes the certificate to the mine where it can be easily  retrieved
   by other minions.

   /srv/salt/ca.sls

      salt-minion:
        service.running:
          - enable: True
          - listen:
            - file: /etc/salt/minion.d/signing_policies.conf

      /etc/salt/minion.d/signing_policies.conf:
        file.managed:
          - source: salt://signing_policies.conf

      /etc/pki:
        file.directory: []

      /etc/pki/issued_certs:
        file.directory: []

      /etc/pki/ca.key:
        x509.private_key_managed:
          - bits: 4096
          - backup: True
          - require:
            - file: /etc/pki

      /etc/pki/ca.crt:
        x509.certificate_managed:
          - signing_private_key: /etc/pki/ca.key
          - CN: ca.example.com
          - C: US
          - ST: Utah
          - L: Salt Lake City
          - basicConstraints: "critical CA:true"
          - keyUsage: "critical cRLSign, keyCertSign"
          - subjectKeyIdentifier: hash
          - authorityKeyIdentifier: keyid,issuer:always
          - days_valid: 3650
          - days_remaining: 0
          - backup: True
          - require:
            - x509: /etc/pki/ca.key

      mine.send:
        module.run:
          - func: x509.get_pem_entries
          - kwargs:
              glob_path: /etc/pki/ca.crt
          - onchanges:
            - x509: /etc/pki/ca.crt

   The  signing  policy  defines  properties  that  override  any property
   requested or included in a CRL. It also can define a restricted list of
   minons which are allowed to remotely invoke this signing policy.

   /srv/salt/signing_policies.conf

      x509_signing_policies:
        www:
          - minions: 'www'
          - signing_private_key: /etc/pki/ca.key
          - signing_cert: /etc/pki/ca.crt
          - C: US
          - ST: Utah
          - L: Salt Lake City
          - basicConstraints: "critical CA:false"
          - keyUsage: "critical keyEncipherment"
          - subjectKeyIdentifier: hash
          - authorityKeyIdentifier: keyid,issuer:always
          - days_valid: 90
          - copypath: /etc/pki/issued_certs/

   This  state  will  instruct all minions to trust certificates signed by
   our new CA.  Using jinja to strip newlines from the text avoids dealing
   with  newlines  in  the rendered yaml, and the  sign_remote_certificate
   state will handle properly  formatting  the  text  before  writing  the
   output.

   /srv/salt/cert.sls

      /usr/local/share/ca-certificates:
        file.directory: []

      /usr/local/share/ca-certificates/intca.crt:
        x509.pem_managed:
          - text: {{ salt['mine.get']('ca', 'x509.get_pem_entries')['ca']['/etc/pki/ca.crt']|replace('\n', '') }}

   This  state creates a private key then requests a certificate signed by
   ca according to the www policy.

   /srv/salt/www.sls

      /etc/pki/www.key:
        x509.private_key_managed:
          - bits: 4096

      /etc/pki/www.crt:
        x509.certificate_managed:
          - ca_server: ca
          - signing_policy: www
          - public_key: /etc/pki/www.key
          - CN: www.example.com
          - days_remaining: 30
          - backup: True

   salt.states.x509.certificate_managed(name,           days_remaining=90,
   backup=False, **kwargs)
          Manage a Certificate

          name:  Path to the certificate

          days_remaining:
                 The minimum number of days remaining when the certificate
                 should be recreated. Default is 90. A value of 0 disables
                 automatic renewal.

          backup:
                 When  replacing  an existing file, backup the old file on
                 the minion. Default is False.

          kwargs:
                 Any arguments supported  by  x509.create_certificate  are
                 supported.

          Examples:

             /etc/pki/ca.crt:
               x509.certificate_managed:
                 - signing_private_key: /etc/pki/ca.key
                 - CN: ca.example.com
                 - C: US
                 - ST: Utah
                 - L: Salt Lake City
                 - basicConstraints: "critical CA:true"
                 - keyUsage: "critical cRLSign, keyCertSign"
                 - subjectKeyIdentifier: hash
                 - authorityKeyIdentifier: keyid,issuer:always
                 - days_valid: 3650
                 - days_remaining: 0
                 - backup: True

             /etc/ssl/www.crt:
               x509.certificate_managed:
                 - ca_server: pki
                 - signing_policy: www
                 - public_key: /etc/ssl/www.key
                 - CN: www.example.com
                 - days_valid: 90
                 - days_remaining: 30
                 - backup: True

   salt.states.x509.crl_managed(name,                 signing_private_key,
   signing_cert=None,     revoked=None,     days_valid=100,     digest='',
   days_remaining=30, include_expired=False, backup=False)
          Manage a Certificate Revocation List

          name:  Path to the certificate

          signing_private_key:
                 The  private key that will be used to sign this crl. This
                 is usually your CA's private key.

          signing_cert:
                 The certificate of the authority that  will  be  used  to
                 sign this crl.  This is usually your CA's certificate.

          revoked:
                 A  list  of certificates to revoke. Must include either a
                 serial number or a the certificate itself. Can optionally
                 include  the  revocation  date and notAfter date from the
                 certificate. See example below for details.

          days_valid:
                 The number of days the certificate should be  valid  for.
                 Default is 100.

          digest:
                 The  digest  to  use  for  signing  the CRL.  This has no
                 effect on versions of pyOpenSSL less than 0.14

          days_remaining:
                 The crl should be automatically recreated  if  there  are
                 less  than days_remaining days until the crl expires. Set
                 to 0 to disable automatic renewal. Default is 30.

          include_expired:
                 Include expired  certificates  in  the  CRL.  Default  is
                 False.

          backup:
                 When  replacing  an existing file, backup the old file on
                 the minion. Default is False.

          Example:

             /etc/pki/ca.crl:
               x509.crl_managed:
                 - signing_private_key: /etc/pki/myca.key
                 - signing_cert: /etc/pki/myca.crt
                 - revoked:
                   - compromized_Web_key:
                     - certificate: /etc/pki/certs/badweb.crt
                     - revocation_date: 2015-03-01 00:00:00
                     - reason: keyCompromise
                   - terminated_vpn_user:
                     - serial_number: D6:D2:DC:D8:4D:5C:C0:F4
                     - not_after: 2016-01-01 00:00:00
                     - revocation_date: 2015-02-25 00:00:00
                     - reason: cessationOfOperation

   salt.states.x509.csr_managed(name, backup=False, **kwargs)
          Manage a Certificate Signing Request

          name:  Path to the CSR

          properties:
                 The properties to be added to  the  certificate  request,
                 including  items like subject, extensions and public key.
                 See above for valid properties.

          Example:

             /etc/pki/mycert.csr:
               x509.csr_managed:
                  - private_key: /etc/pki/mycert.key
                  - CN: www.example.com
                  - C: US
                  - ST: Utah
                  - L: Salt Lake City
                  - keyUsage: 'critical dataEncipherment'

   salt.states.x509.pem_managed(name, text, backup=False)
          Manage the contents of a PEM file directly with the  content  in
          text, ensuring correct formatting.

          name:  The path to the file to manage

          text:  The PEM formatted text to write.

          backup:
                 When  replacing  an existing file, backup the old file on
                 the minion. Default is False.

   salt.states.x509.private_key_managed(name,    bits=2048,     new=False,
   backup=False, verbose=True)
          Manage a private key's existence.

          name:  Path to the private key

          bits:  Key length in bits. Default 2048.

          new:   Always  create  a  new key. Defaults to False.  Combining
                 new with prereq can allow key  rotation  whenever  a  new
                 certificiate is generated.

          backup:
                 When  replacing  an existing file, backup the old file on
                 the minion.  Default is False.

          verbose:
                 Provide visual feedback on  stdout,  dots  while  key  is
                 generated.  Default is True.

                 New in version 2016.11.0.

          Example:

          The  jinja  templating  in this example ensures a private key is
          generated if the file doesn't exist and that a new  private  key
          is  generated  whenever  the  certificate  that uses it is to be
          renewed.

             /etc/pki/www.key:
               x509.private_key_managed:
                 - bits: 4096
                 - new: True
                 {% if salt['file.file_exists']('/etc/pki/ca.key') -%}
                 - prereq:
                   - x509: /etc/pki/www.crt
                 {%- endif %}

   salt.states.xmpp
   Sending Messages over XMPP
   New in version 2014.1.0.

   This state is useful for firing messages during state runs,  using  the
   XMPP protocol

      server-warning-message:
        xmpp.send_msg:
          - name: 'This is a server warning message'
          - profile: my-xmpp-account
          - recipient: [email protected]/salt

   salt.states.xmpp.send_msg(name, recipient, profile)
          Send a message to an XMPP user

             server-warning-message:
               xmpp.send_msg:
                 - name: 'This is a server warning message'
                 - profile: my-xmpp-account
                 - recipient: [email protected]/salt

          name   The message to send to the XMPP user

   salt.states.xmpp.send_msg_multi(name,     profile,     recipients=None,
   rooms=None)
          Send a message to an list of recipients or rooms

             server-warning-message:
               xmpp.send_msg:
                 - name: 'This is a server warning message'
                 - profile: my-xmpp-account
                 - recipients:
                   - [email protected]/salt
                 - rooms:
                   - [email protected]

          name   The message to send to the XMPP user

   salt.states.zabbix_host module
   Management of Zabbix hosts.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.states.zabbix_host.absent(name)
          Ensures that the host does not exists, eventually deletes host.

          New in version 2016.3.0.

          Param  name: technical name of the host

          Parameters

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

             TestHostWithInterfaces:
                 zabbix_host.absent

   salt.states.zabbix_host.present(host, groups, interfaces, **kwargs)
          Ensures that the  host  exists,  eventually  creates  new  host.
          NOTE:  please  use  argument visible_name instead of name to not
          mess with name from salt sls. This function accepts all standard
          host properties: keyword argument names differ depending on your
          zabbix                       version,                       see:
          https://www.zabbix.com/documentation/2.4/manual/api/reference/host/object#host

          New in version 2016.3.0.

          Parameters

                 * host -- technical name of the host

                 * groups -- groupids of host groups to add the host to

                 * interfaces -- interfaces to be created for the host

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

                 * visible_name -- Optional - string with visible name  of
                   the   host,   use   'visible_name'  instead  of  'name'
                   parameter to not mess with value supplied from Salt sls
                   file.

             create_test_host:
                 zabbix_host.present:
                     - host: TestHostWithInterfaces
                     - groups:
                         - 5
                         - 6
                         - 7
                     - interfaces:
                         - test1.example.com:
                             - ip: '192.168.1.8'
                             - type: 'Agent'
                             - port: 92
                         - testing2_create:
                             - ip: '192.168.1.9'
                             - dns: 'test2.example.com'
                             - type: 'agent'
                             - main: false
                         - testovaci1_ipmi:
                             - ip: '192.168.100.111'
                             - type: 'ipmi'

   salt.states.zabbix_hostgroup module
   Management of Zabbix host groups.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.states.zabbix_hostgroup.absent(name)
          Ensures  that  the  host group does not exist, eventually delete
          host group.

          New in version 2016.3.0.

          Parameters

                 * name -- name of the host group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

             delete_testing_host_group:
                 zabbix_hostgroup.absent:
                     - name: 'My hostgroup name'

   salt.states.zabbix_hostgroup.present(name)
          Ensures that the host group exists, eventually creates new  host
          group.

          New in version 2016.3.0.

          Parameters

                 * name -- name of the host group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

             create_testing_host_group:
                 zabbix_hostgroup.present:
                     - name: 'My hostgroup name'

   salt.states.zabbix_user module
   Management of Zabbix users.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.states.zabbix_user.absent(name)
          Ensures that the user does not exist, eventually delete user.

          New in version 2016.3.0.

          Parameters

                 * name -- user alias

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

             George:
                 zabbix_user.absent

   salt.states.zabbix_user.present(alias,    passwd,    usrgrps,   medias,
   password_reset=False, **kwargs)
          Ensures that the  user  exists,  eventually  creates  new  user.
          NOTE:  use argument firstname instead of name to not mess values
          with name from salt sls.

          New in version 2016.3.0.

          Parameters

                 * alias -- user alias

                 * passwd -- user's password

                 * usrgrps -- user groups to add the user to

                 * medias -- user's medias to create

                 * password_reset -- whether or not to reset  password  at
                   update

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url  --  Optional  - url of zabbix frontend
                   (can  also  be  set  in  opts,  pillar,  see   module's
                   docstring)

                 * firstname  --  string  with  firstname of the user, use
                   'firstname' instead of 'name'  parameter  to  not  mess
                   with value supplied from Salt sls file.

             make_user:
                 zabbix_user.present:
                     - alias: George
                     - passwd: donottellanyonE@456x
                     - password_reset: True
                     - usrgrps:
                         - 13
                         - 7
                     - medias:
                         - [email protected]:
                             - mediatype: mail
                             - period: '1-7,00:00-24:00'
                             - severity: NIWAHD
                         - make_jabber:
                             - active: true
                             - mediatype: jabber
                             - period: '1-5,08:00-19:00'
                             - sendto: [email protected]
                         - text_me_morning_disabled:
                             - active: false
                             - mediatype: sms
                             - period: '1-5,09:30-10:00'
                             - severity: D
                             - sendto: '+42032132588568'

   salt.states.zabbix_usergroup module
   Management of Zabbix user groups.

   codeauthor
          Jiri Kotlin <[email protected]>

   salt.states.zabbix_usergroup.absent(name)
          Ensures  that  the  user group does not exist, eventually delete
          user group.

          New in version 2016.3.0.

          Parameters

                 * name -- name of the user group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

             delete_thai_monks_usrgrp:
                 zabbix_usergroup.absent:
                     - name: 'Thai monks'

   salt.states.zabbix_usergroup.present(name, **kwargs)
          Creates new user.  NOTE: This function accepts all standard user
          group  properties:  keyword  argument  names differ depending on
          your              zabbix              version,              see:
          https://www.zabbix.com/documentation/2.0/manual/appendix/api/usergroup/definitions#user_group

          New in version 2016.3.0.

          Parameters

                 * name -- name of the user group

                 * _connection_user -- Optional - zabbix user (can also be
                   set in opts or pillar, see module's docstring)

                 * _connection_password -- Optional - zabbix password (can
                   also be set in opts or pillar, see module's docstring)

                 * _connection_url -- Optional - url  of  zabbix  frontend
                   (can   also  be  set  in  opts,  pillar,  see  module's
                   docstring)

             make_new_thai_monks_usergroup:
                 zabbix_usergroup.present:
                     - name: 'Thai monks'
                     - gui_access: 1
                     - debug_mode: 0
                     - users_status: 0

   salt.states.zcbuildout
   Management of zc.buildout
   This  module  is   inspired   from   minitage's   buildout   maker   (
   https://github.com/minitage/minitage/blob/master/src/minitage/core/makers/buildout.py)

   New in version 2016.3.0.

   NOTE:
      This state module is beta; the API  is  subject  to  change  and  no
      promise as to performance or functionality is yet present

   Available Functions
   * built

        installed1
          buildout.installed:
            - name: /path/to/buildout

        installed2
          buildout.installed:
            - name: /path/to/buildout
            - parts:
              - a
              - b
            - python: /path/to/pythonpath/bin/python
            - unless: /bin/test_something_installed
            - onlyif: /bin/test_else_installed

   salt.states.zcbuildout.installed(name,           config='buildout.cfg',
   quiet=False,   parts=None,   user=None,   env=(),    buildout_ver=None,
   test_release=False,    distribute=None,   new_st=None,   offline=False,
   newest=False,  python='/usr/bin/python',  debug=False,   verbose=False,
   unless=None, onlyif=None, use_vt=False, loglevel='debug', **kwargs)
          Install buildout in a specific directory

          It is a thin wrapper to modules.buildout.buildout

          name   directory to execute in

          quiet
             do not output console & logs

          config buildout config to use (default: buildout.cfg)

          parts  specific buildout parts to run

          user   user used to run buildout as

                 New in version 2014.1.4.

          env    environment variables to set when running

          buildout_ver
                 force a specific buildout version (1 | 2)

          test_release
                 buildout accept test release

          new_st Forcing use of setuptools >= 0.7

          distribute
                 use distribute over setuptools if possible

          offline
                 does buildout run offline

          python python to use

          debug  run buildout with -D debug flag

          onlyif Only execute cmd if statement on the host return 0

          unless Do not execute cmd if statement on the host return 0

          newest run buildout in newest mode

          verbose
                 run buildout in verbose mode (-vvvvv)

          use_vt Use the new salt VT to stream output [experimental]

          loglevel
                 loglevel for buildout commands

   salt.states.zenoss
   State to manage monitoring in Zenoss.

   New in version 2016.3.0.

   This state module depends on the 'zenoss' Salt execution module.

   Allows  for  setting a state of minions in Zenoss using the Zenoss API.
   Currently Zenoss 4.x is supported.

      enable_monitoring:
        zenoss.monitored:
          - name: web01.example.com
          - device_class: /Servers/Linux
          - collector: localhost
          - prod_state: 1000

   salt.states.zenoss.monitored(name,                   device_class=None,
   collector='localhost', prod_state=None)
          Ensure  a device is monitored. The 'name' given will be used for
          Zenoss device name and should be resolvable.

             enable_monitoring:
               zenoss.monitored:
                 - name: web01.example.com
                 - device_class: /Servers/Linux
                 - collector: localhost
                 - prod_state: 1000

   salt.states.zk_concurrency
   Control concurrency of steps within state execution using zookeeper
   This module allows you to "wrap" a state's execution  with  concurrency
   control.   This  is  useful  to  protect  against  all  hosts executing
   highstate simultaneously if your services don't all  HUP  restart.  The
   common way of protecting against this is to run in batch mode, but that
   doesn't protect from another person running the same batch command (and
   thereby having 2x the number of nodes deploying at once).

   This  module will bock while acquiring a slot, meaning that however the
   command gets called it will coordinate with zookeeper to ensure that no
   more than max_concurrency steps are executing with a single path.

      acquire_lock:
        zk_concurrency.lock:
          - name: /trafficeserver
          - zk_hosts: 'zookeeper:2181'
          - max_concurrency: 4
          - prereq:
              - service: trafficserver

      trafficserver:
        service.running:
          - watch:
            - file: /etc/trafficserver/records.config

      /etc/trafficserver/records.config:
        file.managed:
          - source: salt://records.config

      release_lock:
        zk_concurrency.unlock:
          - name: /trafficserver
          - require:
              - service: trafficserver

   This  example would allow the file state to change, but would limit the
   concurrency of the trafficserver service restart to 4.

   salt.states.zk_concurrency.lock(name,    zk_hosts,     identifier=None,
   max_concurrency=1, timeout=None, ephemeral_lease=False)
          Block state execution until you are able to get the lock (or hit
          the timeout)

   salt.states.zk_concurrency.min_party(name,     zk_hosts,     min_nodes,
   blocking=False)
          Ensure that there are min_nodes in the party at name, optionally
          blocking if not available.

   salt.states.zk_concurrency.unlock(name, zk_hosts=None, identifier=None,
   max_concurrency=1, ephemeral_lease=False)
          Remove lease from semaphore.

   salt.states.zfs
   Management zfs datasets

   maintainer
          Jorge Schrauwen <[email protected]>

   maturity
          new

   depends
          zfs

   platform
          smartos, illumos, solaris, freebsd, linux

   New in version 2016.3.0.

      test/shares/yuki:
        zfs.filesystem_present:
          - create_parent: true
          - properties:
              quota: 16G

      test/iscsi/haruhi:
        zfs.volume_present:
          - create_parent: true
          - volume_size: 16M
          - sparse: true
          - properties:
              readonly: on

      test/shares/yuki@frozen:
        zfs.snapshot_present

      moka_origin:
        zfs.hold_present
          - snapshot: test/shares/yuki@frozen

      test/shares/moka:
        zfs.filesystem_present:
          - cloned_from: test/shares/yuki@frozen

      test/shares/moka@tsukune:
        zfs.snapshot_absent

   salt.states.zfs.bookmark_absent(name, force=False, recursive=False)
          ensure bookmark is absent on the system

          name   string name of snapshot

          force  boolean  try  harder  to destroy the dataset (zfs destroy
                 -f)

          recursive
                 boolean also destroy all the child datasets (zfs  destroy
                 -r)

   salt.states.zfs.bookmark_present(name, snapshot)
          ensure bookmark exists

          name   string name of bookmark

          snapshot
                 string name of snapshot

   salt.states.zfs.filesystem_absent(name, force=False, recursive=False)
          ensure filesystem is absent on the system

          name   string name of filesystem

          force  boolean  try  harder  to destroy the dataset (zfs destroy
                 -f)

          recursive
                 boolean also destroy all the child datasets (zfs  destroy
                 -r)

          ..warning:
             If a volume with name exists, this state will succeed without
             destroying the volume  specified  by  name.  This  module  is
             dataset type sensitive.

   salt.states.zfs.filesystem_present(name,           create_parent=False,
   properties=None, cloned_from=None)
          ensure filesystem exists and has properties set

          name   string name of filesystem

          create_parent
                 boolean creates all  the  non-existing  parent  datasets.
                 any  property  specified on the command line using the -o
                 option is ignored.

          cloned_from
                 string name of snapshot to clone

          properties
                 dict additional zfs properties (-o)

          NOTE:
             cloned_from is only use if the filesystem does not exist yet,
             when  cloned_from  is set after the filesystem exists it will
             be ignored.

          NOTE:
             Properties do not get cloned, if you specify  the  properties
             in the state file they will be applied on a subsequent run.

   salt.states.zfs.hold_absent(name, snapshot, recursive=False)
          ensure hold is absent on the system

          name   string name of holdt

          snapshot
                 string name of snapshot

          recursive
                 boolean recursively releases a hold with the given tag on
                 the snapshots of all descendent file systems.

   salt.states.zfs.hold_present(name, snapshot, recursive=False)
          ensure hold is present on the system

          name   string name of holdt

          snapshot
                 string name of snapshot

          recursive
                 boolean recursively add hold with the given  tag  on  the
                 snapshots of all descendent file systems.

   salt.states.zfs.promoted(name)
          ensure a dataset is not a clone

          name   string name of fileset or volume

          ..warning:

             only one dataset can be the origin,
             if you promote a clone the original will now point to the promoted dataset

   salt.states.zfs.scheduled_snapshot(name,     prefix,    recursive=True,
   schedule=None)
          maintain a set of snapshots based on a schedule

          name   string name of filesystem or volume

          prefix string prefix for the snapshots e.g. 'test'  will  result
                 in snapshots being named 'test-YYYYMMDD_HHMM'

          recursive
                 boolean create snapshots for all children also

          schedule
                 dict  dict  holding  the schedule, the following keys are
                 available (minute, hour, day, month, and year) by default
                 all  are  set  to  0  the  value  indicated the number of
                 snapshots of that type to keep around.

          ..warning:

             snapshots will only be created and pruned every time the state runs.
             a schedule must be setup to automatically run the state. this means that if
             you run the state daily the hourly snapshot will only be made once per day!

   salt.states.zfs.snapshot_absent(name, force=False, recursive=False)
          ensure snapshot is absent on the system

          name   string name of snapshot

          force  boolean try harder to destroy the  dataset  (zfs  destroy
                 -f)

          recursive
                 boolean  also destroy all the child datasets (zfs destroy
                 -r)

   salt.states.zfs.snapshot_present(name,                 recursive=False,
   properties=None)
          ensure snapshot exists and has properties set

          name   string name of snapshot

          recursive
                 boolean  recursively  create  snapshots of all descendent
                 datasets

          properties
                 dict additional zfs properties (-o)

   salt.states.zfs.volume_absent(name, force=False, recursive=False)
          ensure volume is absent on the system

          name   string name of volume

          force  boolean try harder to destroy the  dataset  (zfs  destroy
                 -f)

          recursive
                 boolean  also destroy all the child datasets (zfs destroy
                 -r)

          ..warning:
             If a filesystem with name exists,  this  state  will  succeed
             without  destroying  the  filesystem  specified by name. This
             module is dataset type sensitive.

   salt.states.zfs.volume_present(name,     volume_size,     sparse=False,
   create_parent=False, properties=None, cloned_from=None)
          ensure volume exists and has properties set

          name   string name of volume

          volume_size
                 string size of volume

          sparse boolean create sparse volume

          create_parent
                 boolean  creates  all  the  non-existing parent datasets.
                 any property specified on the command line using  the  -o
                 option is ignored.

          cloned_from
                 string name of snapshot to clone

          properties
                 dict additional zfs properties (-o)

          NOTE:
             cloned_from  is  only  use  if the volume does not exist yet,
             when cloned_from is set after the volume exists  it  will  be
             ignored.

          NOTE:
             Properties  do  not get cloned, if you specify the properties
             in the state file they will be applied on a subsequent run.

             volume_size is considered a property, so  the  volume's  size
             will  be  corrected  when  the  properties  get updated if it
             differs from the original volume.

             The sparse parameter is ignored when using cloned_from.

   salt.states.zpool
   Management zpool

   maintainer
          Jorge Schrauwen <[email protected]>

   maturity
          new

   depends
          zpool

   platform
          smartos, illumos, solaris, freebsd, linux

   New in version 2016.3.0.

      oldpool:
        zpool.absent:
          - export: true

      newpool:
        zpool.present:
          - config:
              import: false
              force: true
          - properties:
              comment: salty storage pool
          - layout:
              mirror-0:
                /dev/disk0
                /dev/disk1
              mirror-1:
                /dev/disk2
                /dev/disk3

      simplepool:
        zpool.present:
          - config:
              import: false
              force: true
          - properties:
              comment: another salty storage pool
          - layout:
              - /dev/disk0
              - /dev/disk1

   WARNING:
      The layout will never be updated, it will only be used  at  time  of
      creation.  It's a whole lot of work to figure out if a devices needs
      to be detached, removed, ... this is best done by the sysadmin on  a
      case per case basis.

      Filesystem  properties  are also not updated, this should be managed
      by the zfs state module.

   salt.states.zpool.absent(name, export=False, force=False)
          ensure storage pool is absent on the system

          name   string name of storage pool

          export boolean export instread of destroy the zpool if present

          force  boolean force destroy or export

   salt.states.zpool.present(name,                        properties=None,
   filesystem_properties=None, layout=None, config=None)
          ensure storage pool is present on the system

          name   string name of storage pool

          properties
                 dict  optional  set  of properties to set for the storage
                 pool

          filesystem_properties
                 dict optional set of filesystem properties to set for the
                 storage pool (creation only)

          layout: dict
                 disk  layout  to use if the pool does not exist (creation
                 only)

          config dict fine grain control over this state

          NOTE:

             The following configuration properties can be toggled in  the
             config parameter.

                    * import  (true)  -  try  to  import  the  pool before
                      creating it if absent

                    * import_dirs (None) - specify additional locations to
                      scan for devices on import

                    * device_dir  (None, SunOS=/dev/rdsk) - specify device
                      directory to use if not absolute path

                    * force (false) - try to force the import or creation

          NOTE:
             Because ID's inside the layout dict must be unique they  need
             to have a suffix.

                 mirror-0:
                   /tmp/vdisk3
                   /tmp/vdisk2
                 mirror-1:
                   /tmp/vdisk0
                   /tmp/vdisk1

             The  above  yaml  will  always  result in the following zpool
             create:

                 zpool create mypool mirror /tmp/vdisk3 /tmp/vdisk2 mirror /tmp/vdisk0 /tmp/vdisk1

          WARNING:
             Pay attention to the order of your dict!

                 mirror-0:
                   /tmp/vdisk0
                   /tmp/vdisk1
                 /tmp/vdisk2:

             The above will result in the following zpool create:

                 zpool create mypool mirror /tmp/vdisk0 /tmp/vdisk1 /tmp/vdisk2

             Creating a 3-way mirror! Why you probably  expect  it  to  be
             mirror root vdev with 2 devices + a root vdev of 1 device!

   thorium modules
                    
                    check  The check Thorium state is 
                           used to create gateways to 
                           commands,  the checks make 
                           it  easy  to  make  states 
                           that  watch  registers for 
                           changes  and   then   just 
                           succeed  or  fail based on 
                           the state of the register, 
                           this  creates  the pattern 
                           of   having   a    command 
                           execution  get  gated by a 
                           check    state    via    a 
                           requisite.                 
                    
                    file   Writes  matches to disk to 
                           verify  activity,  helpful 
                           when testing               
                    
                    local  Run    remote    execution 
                           commands  via  the   local 
                           client                     
                    
                    reg    Used to manage the thorium 
                           register.                  
                    
                    timer  Allow   for   flow   based 
                           timers.                    
                    

   salt.thorium.check module
   The  check  Thorium  state  is used to create gateways to commands, the
   checks make it easy to make states that watch registers for changes and
   then  just  succeed  or  fail  based on the state of the register, this
   creates the pattern of having a command execution get gated by a  check
   state via a requisite.

   salt.thorium.check.contains(name, value)
          Only  succeed  if  the  value  in  the  given  register location
          contains the given value

          USAGE:

             foo:
               check.contains:
                 - value: itni

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.eq(name, value)
          Only succeed if the value in  the  given  register  location  is
          equal to the given value

          USAGE:

             foo:
               check.eq:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.event(name)
          Chekcs for a specific event match and returns result True if the
          match happens

          USAGE:

             salt/foo/*/bar:
               check.event

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: salt/foo/*/bar

   salt.thorium.check.gt(name, value)
          Only succeed if the value in  the  given  register  location  is
          greater than the given value

          USAGE:

             foo:
               check.gt:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.gte(name, value)
          Only  succeed  if  the  value  in the given register location is
          greater or equal than the given value

          USAGE:

             foo:
               check.gte:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.lt(name, value)
          Only succeed if the value in the given register location is less
          than the given value

          USAGE:

             foo:
               check.lt:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.lte(name, value)
          Only succeed if the value in the given register location is less
          than or equal the given value

          USAGE:

             foo:
               check.lte:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.check.ne(name, value)
          Only succeed if the value in the given register location is  not
          equal to the given value

          USAGE:

             foo:
               check.ne:
                 - value: 42

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping
                 - require:
                   - check: foo

   salt.thorium.file module
   Writes matches to disk to verify activity, helpful when testing

   Normally  this  is used by giving the name of the file (without a path)
   that the data will be saved to. If for instance  you  use  foo  as  the
   name:

   Then the file will be saved to:

   You may also provide an absolute path for the file to be saved to:

      /tmp/foo.save:
          file.save

   Files  will  be  saved  in  JSON format. However, JSON does not support
   set()``s.  If you are saving a register entry that contains a  ``set(),
   then  it  will  fail to save to JSON format. However, you may pass data
   through a filter which makes it JSON compliant:

      foo:
        file.save:
          filter: True

   Be warned that if you do this, then the file will be saved, but not  in
   a format that can be re-imported into Python.

   salt.thorium.file.save(name, filter=False)
          Save the register to <salt cachedir>/thorium/saves/<name>, or to
          an absolute path.

          USAGE:

             foo:
               file.save

             /tmp/foo:
               file.save

   salt.thorium.local module
   Run remote execution commands via the local client

   salt.thorium.local.cmd(name,  tgt,   func,   arg=(),   tgt_type='glob',
   ret='', kwarg=None, **kwargs)
          Execute a remote execution command

          USAGE:

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.ping

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.sleep
                 - arg:
                   - 30

             run_remote_ex:
               local.cmd:
                 - tgt: '*'
                 - func: test.sleep
                 - kwarg:
                   length: 30

   salt.thorium.reg module
   Used  to  manage  the  thorium  register. The thorium register is where
   compound values are stored and computed, such as averages etc.

   salt.thorium.reg.clear(name)
          Clear the namespace from the register

          USAGE:

             clearns:
               reg.clear:
                 - name: myregister

   salt.thorium.reg.delete(name)
          Delete the namespace from the register

          USAGE:

             deletens:
               reg.delete:
                 - name: myregister

   salt.thorium.reg.list(name, add, match, stamp=False, prune=0)
          Add the specified values to the named list

          If stamp is True, then the timestamp from the event will also be
          added if prune is set to an integer higher than 0, then only the
          last
             prune values will be kept in the list.

          USAGE:

             foo:
               reg.list:
                 - add: bar
                 - match: my/custom/event
                 - stamp: True

   salt.thorium.reg.mean(name, add, match)
          Accept a numeric value from  the  matched  events  and  store  a
          running  average  of  the  values  in the given register. If the
          specified value is not numeric it will be skipped

          USAGE:

             foo:
               reg.mean:
                 - add: data_field
                 - match: my/custom/event

   salt.thorium.reg.set(name, add, match)
          Add a value to the named set

          USAGE:

             foo:
               reg.set:
                 - add: bar
                 - match: my/custom/event

   salt.thorium.timer module
   Allow for flow based timers. These timers allow for a  sleep  to  exist
   across multiple runs of the flow

   salt.thorium.timer.hold(name, seconds)
          Wait  for  a  given  period of time, then fire a result of True,
          requiring this state allows for an  action  to  be  blocked  for
          evaluation based on time

          USAGE:

             hold_on_a_moment:
               timer.hold:
                 - seconds: 30

   master tops modules
         
         cobbler          Cobbler Tops                            
         
         ext_nodes        External Nodes Classifier               
         
         mongo            Read   tops  data  from  a              
                          mongodb collection                      
         
         reclass_adapter  Read  tops  data  from   a              
                          reclass database                        
         
         varstack         Use               Varstack              
                          <https://github.com/conversis/varstack> 
                          to provide tops data                    
         

   salt.tops.cobbler
   Cobbler Tops
   Cobbler  Tops  is  a  master  tops  subsystem  used  to look up mapping
   information from Cobbler via its API. The same cobbler.* parameters are
   used for both the Cobbler tops and Cobbler pillar modules.

      master_tops:
        cobbler: {}
      cobbler.url: https://example.com/cobbler_api #default is http://localhost/cobbler_api
      cobbler.user: username # default is no username
      cobbler.password: password # default is no password

   Module Documentation
   salt.tops.cobbler.top(**kwargs)
          Look up top data in Cobbler for a minion.

   salt.tops.ext_nodes
   External Nodes Classifier
   The External Nodes Classifier is a master tops subsystem that retrieves
   mapping information from major configuration management systems. One of
   the  most  common  external  nodes  classifiers  system  is provided by
   Cobbler and is called cobbler-ext-nodes.

   The cobbler-ext-nodes command can be used with this configuration:

      master_tops:
        ext_nodes: cobbler-ext-nodes

   It is noteworthy that the Salt system does not directly ingest the data
   sent  from  the  cobbler-ext-nodes  command, but converts the data into
   information that is used by a Salt top file.

   Any command can replace the  call  to  'cobbler-ext-nodes'  above,  but
   currently  the data must be formatted in the same way that the standard
   'cobbler-ext-nodes' does.

   See (admittedly degenerate and probably not complete) example:

      classes:
        - basepackages
        - database

   The  above  essentially  is  the  same  as  a  top.sls  containing  the
   following:

      base:
        '*':
          - basepackages
          - database

      base:
        '*':
          - basepackages
          - database

   salt.tops.ext_nodes.top(**kwargs)
          Run the command configured

   salt.tops.mongo
   Read tops data from a mongodb collection

   This  module  will  load tops data from a mongo collection. It uses the
   node's id for lookups.

   Salt Master Mongo Configuration
   The  module  shares  the  same  base  mongo  connection  variables   as
   salt.returners.mongo_return.  These  variables go in your master config
   file.

      * mongo.db - The mongo database to connect to. Defaults to 'salt'.

      * mongo.host - The mongo host to connect to. Supports  replica  sets
        by  specifying  all hosts in the set, comma-delimited. Defaults to
        'salt'.

      * mongo.port - The port that  the  mongo  database  is  running  on.
        Defaults to 27017.

      * mongo.user  -  The username for connecting to mongo. Only required
        if you are using mongo authentication. Defaults to ''.

      * mongo.password -  The  password  for  connecting  to  mongo.  Only
        required if you are using mongo authentication. Defaults to ''.

   Configuring the Mongo Tops Subsystem
      master_tops:
        mongo:
          collection: tops
          id_field: _id
          re_replace: ""
          re_pattern: \.example\.com
          states_field: states
          environment_field: environment

   Module Documentation
   salt.tops.mongo.top(**kwargs)
          Connect to a mongo database and read per-node tops data.

          Parameters

                 * collection  (*)  -- The mongodb collection to read data
                   from. Defaults to 'tops'.

                 * id_field (*)  --  The  field  in  the  collection  that
                   represents an individual minion id. Defaults to '_id'.

                 * re_pattern  (*)  --  If  your  naming convention in the
                   collection is shorter than the minion id, you  can  use
                   this  to  trim  the  name.   re_pattern will be used to
                   match the name, and re_replace will be used to  replace
                   it.  Backrefs  are  supported as they are in the Python
                   standard library. If None, no mangling of the name will
                   be performed - the collection will be searched with the
                   entire minion id. Defaults to None.

                 * re_replace (*) -- Use as the replacement value in  node
                   ids  matched with re_pattern. Defaults to ''. Feel free
                   to use backreferences here.

                 * states_field (*) -- The name of the field  providing  a
                   list of states.

                 * environment_field   (*)   --  The  name  of  the  field
                   providing the environment.  Defaults to environment.

   salt.tops.reclass_adapter
   Read tops data from a reclass database

   This master_tops plugin provides access to the reclass  database,  such
   that state information (top data) are retrieved from reclass.

   You     can     find     more     information    about    reclass    at
   http://reclass.pantsfullofunix.net.

   To use the plugin, add it to the master_tops list in  the  Salt  master
   config  and  tell reclass by way of a few options how and where to find
   the inventory:

      master_tops:
        reclass:
          storage_type: yaml_fs
          inventory_base_uri: /srv/salt

   This would cause reclass to read  the  inventory  from  YAML  files  in
   /srv/salt/nodes and /srv/salt/classes.

   If  you  are  also  using reclass as ext_pillar plugin, and you want to
   avoid having to specify the same information for both, use YAML anchors
   (take note of the differing data types for ext_pillar and master_tops):

      reclass: &reclass
        storage_type: yaml_fs
        inventory_base_uri: /srv/salt
        reclass_source_path: ~/code/reclass

      ext_pillar:
        - reclass: *reclass

      master_tops:
        reclass: *reclass

   If  you want to run reclass from source, rather than installing it, you
   can either let the master know via the PYTHONPATH environment variable,
   or by setting the configuration option, like in the example above.

   salt.tops.reclass_adapter.top(**kwargs)
          Query reclass for the top data (states of the minions).

   salt.tops.varstack
   Use  Varstack  <https://github.com/conversis/varstack>  to provide tops
   data

   This master_tops plugin provides access to  the  varstack  hierarchical
   yaml files, so you can user varstack as a full external node classifier
   and store state information (top data) in it.

   Configuring Varstack
   To use varstack as a  master  top  external  node  classifier,  install
   varstack as documented. Then, add to your master's configuration:

      master_tops:
        varstack: /path/to/the/config/file/varstack.yaml

   Varstack  will then use /path/to/the/config/file/varstack.yaml (usually
   /etc/varstack.yaml) to determine which configuration data to return  as
   adapter  information.  From  there  you  can  take a look at the README
   <https://github.com/conversis/varstack/blob/master/README.md>        of
   varstack  to  learn  how this file is evaluated. The ENC part will just
   return the 'states' dictionary for the node.

   Ie, if my.fqdn.yaml file contains:

      ---
      states:
        - sudo
        - openssh
        - apache
        - salt.minion

   these will  be  returned  as  {'base':  ['sudo',  'openssh',  'apache',
   'salt.minion']} and managed by salt as if given from a top.sls file.

   salt.tops.varstack.top(**kwargs)
          Query varstack for the top data (states of the minions).

   wheel modules
                 
                 config        Manage      the     master 
                               configuration file         
                 
                 error         Error generator to  enable 
                               integration   testing   of 
                               salt wheel error handling  
                 
                 file_roots    Read  in  files  from  the 
                               file_root  and  save files 
                               to the file root           
                 
                 key           Wheel system  wrapper  for 
                               the  Salt key system to be 
                               used in interactions  with 
                               the       Salt      Master 
                               programmatically.          
                 
                 minions       Wheel system  wrapper  for 
                               connected minions          
                 
                 pillar_roots  The   pillar_roots   wheel 
                               module is used  to  manage 
                               files   under  the  pillar 
                               roots directories  on  the 
                               master server.             
                 

   salt.wheel.config
   Manage the master configuration file

   salt.wheel.config.apply(key, value)
          Set a single key

          NOTE:
             This will strip comments from your config file

   salt.wheel.config.update_config(file_name, yaml_contents)
          Update master config with yaml_contents.

          Writes  yaml_contents  to  a file named file_name.conf under the
          folder specified  by  default_include.   This  folder  is  named
          master.d  by  default.  Please look at include-configuration for
          more information.

          Example low data:

             data = {
                 'username': 'salt',
                 'password': 'salt',
                 'fun': 'config.update_config',
                 'file_name': 'gui',
                 'yaml_contents': {'id': 1},
                 'client': 'wheel',
                 'eauth': 'pam',
             }

   salt.wheel.config.values()
          Return the raw values of the config file

   salt.wheel.error
   Error generator to enable  integration  testing  of  salt  wheel  error
   handling

   salt.wheel.error.error(name=None, message='')
          If name is None Then return empty dict

          Otherwise  raise  an  exception with __name__ from name, message
          from message

          CLI Example:

             salt-wheel error
             salt-wheel error.error name="Exception" message="This is an error."

   salt.wheel.file_roots
   Read in files from the file_root and save files to the file root

   salt.wheel.file_roots.find(path, saltenv='base')
          Return a dict of the files  located  with  the  given  path  and
          environment

   salt.wheel.file_roots.list_env(saltenv='base')
          Return all of the file paths found in an environment

   salt.wheel.file_roots.list_roots()
          Return all of the files names in all available environments

   salt.wheel.file_roots.read(path, saltenv='base')
          Read the contents of a text file, if the file is binary then

   salt.wheel.file_roots.write(data, path, saltenv='base', index=0)
          Write  the  named  file,  by  default  the  first  file found is
          written, but the index of the file can be specified to write  to
          a lower priority file root

   salt.wheel.key
   Wheel system wrapper for the Salt key system to be used in interactions
   with the Salt Master programmatically.

   The key module for the wheel system is meant  to  provide  an  internal
   interface  for other Salt systems to interact with the Salt Master. The
   following usage examples assume that a WheelClient is available:

      import salt.config
      import salt.wheel
      opts = salt.config.master_config('/etc/salt/master')
      wheel = salt.wheel.WheelClient(opts)

   Note that importing and using the WheelClient must be performed on  the
   same machine as the Salt Master and as the same user that runs the Salt
   Master, unless external_auth is configured and the user  is  authorized
   to execute wheel functions.

   The  function  documentation  starts  with the wheel reference from the
   code sample above and use the WheelClient functions to  show  how  they
   can be called from a Python interpreter.

   The  wheel  key  functions can also be called via a salt command at the
   CLI using the saltutil execution module.

   salt.wheel.key.accept(match,                    include_rejected=False,
   include_denied=False)
          Accept keys based on a glob match. Returns a dictionary.

          match  The glob match of keys to accept.

          include_rejected
                 To  include rejected keys in the match along with pending
                 keys, set this to True. Defaults to False.

          include_denied
                 To include denied keys in the match  along  with  pending
                 keys, set this to True. Defaults to False.

             >>> wheel.cmd('key.accept', ['minion1'])
             {'minions': ['minion1']}

   salt.wheel.key.accept_dict(match,               include_rejected=False,
   include_denied=False)
          Accept keys based on a dict of keys. Returns a dictionary.

          match  The dictionary of keys to accept.

          include_rejected
                 To include rejected keys in the match along with  pending
                 keys, set this to True. Defaults to False.

                 New in version 2016.3.4.

          include_denied
                 To  include  denied  keys in the match along with pending
                 keys, set this to True. Defaults to False.

                 New in version 2016.3.4.

          Example to move a list of keys from  the  minions_pre  (pending)
          directory to the minions (accepted) directory:

             >>> wheel.cmd('accept_dict',
             {
                 'minions_pre': [
                     'jerry',
                     'stuart',
                     'bob',
                 ],
             })
             {'minions': ['jerry', 'stuart', 'bob']}

   salt.wheel.key.delete(match)
          Delete keys based on a glob match. Returns a dictionary.

          match  The glob match of keys to delete.

             >>> wheel.cmd_async({'fun': 'key.delete', 'match': 'minion1'})
             {'jid': '20160826201244808521', 'tag': 'salt/wheel/20160826201244808521'}

   salt.wheel.key.delete_dict(match)
          Delete keys based on a dict of keys. Returns a dictionary.

          match  The dictionary of keys to delete.

             >>> wheel.cmd_async({'fun': 'key.delete_dict',
             'match': {
                 'minions': [
                     'jerry',
                     'stuart',
                     'bob',
                 ],
             })
             {'jid': '20160826201244808521', 'tag': 'salt/wheel/20160826201244808521'}

   salt.wheel.key.finger(match)
          Return the matching key fingerprints. Returns a dictionary.

          match  The key for with to retrieve the fingerprint.

             >>> wheel.cmd('key.finger', ['minion1'])
             {'minions': {'minion1': '5d:f6:79:43:5e:d4:42:3f:57:b8:45:a8:7e:a4:6e:ca'}}

   salt.wheel.key.gen(id_=None, keysize=2048)
             Generate  a key pair. No keys are stored on the master. A key
             pair is returned as a dict  containing  pub  and  priv  keys.
             Returns  a  dictionary  containing  the the pub and priv keys
             with their generated values.

             id_

                    Set a name to generate a key pair for use  with  salt.
                    If not specified, a random name will be specified.

             keysize
                    The size of the key pair to generate. The size must be
                    2048, which is the default, or greater. If  set  to  a
                    value  less than 2048, the key size will be rounded up
                    to 2048.

                 >>> wheel.cmd('key.gen')

                 {'pub': '-----BEGIN PUBLIC KEY-----
          MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC
                 ...
                 BBPfamX9gGPQTpN9e8HwcZjXQnmg8OrcUl10WHw09SDWLOlnW+ueTWugEQpPt

          iQIDAQAB
             -----END PUBLIC KEY-----', 'priv':  '-----BEGIN  RSA  PRIVATE

             KEY-----
          MIIEpAIBAAKCAQEA42Kf+w9XeZWgguzv
                 ...
                 QH3/W74X1+WTBlx4R2KGLYBiH+bCCFEQ/Zvcu4Xp4bIOPtRKozEQ==

                 -----END RSA PRIVATE KEY-----'}

   salt.wheel.key.gen_accept(id_, keysize=2048, force=False)
             Generate a key pair then accept the public key. This function
             returns  the  key  pair  in  a  dict,  only the public key is
             preserved on the master. Returns a dictionary.

             id_

                    The name of the minion for which  to  generate  a  key
                    pair.

             keysize
                    The size of the key pair to generate. The size must be
                    2048, which is the default, or greater. If  set  to  a
                    value  less than 2048, the key size will be rounded up
                    to 2048.

             force  If a public key has  already  been  accepted  for  the
                    given  minion  on  the  master,  then  the  gen_accept
                    function will  return  an  empty  dictionary  and  not
                    create  a  new  key.  This is the default behavior. If
                    force is set to True,  then  the  minion's  previously
                    accepted key will be overwritten.

                 >>> wheel.cmd('key.gen_accept', ['foo'])

                 {'pub': '-----BEGIN PUBLIC KEY-----
          MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC
                 ...
                 BBPfamX9gGPQTpN9e8HwcZjXQnmg8OrcUl10WHw09SDWLOlnW+ueTWugEQpPt

          iQIDAQAB
             -----END  PUBLIC  KEY-----',  'priv': '-----BEGIN RSA PRIVATE

             KEY-----
          MIIEpAIBAAKCAQEA42Kf+w9XeZWgguzv
                    ...
                    QH3/W74X1+WTBlx4R2KGLYBiH+bCCFEQ/Zvcu4Xp4bIOPtRKozEQ==

                    -----END RSA PRIVATE KEY-----'}

                 We  can  now  see  that  the  foo  minion's  key has been
                 accepted by the master:

                    >>> wheel.cmd('key.list', ['accepted'])
                    {'minions': ['foo', 'minion1', 'minion2', 'minion3']}

   salt.wheel.key.gen_keys(keydir=None,    keyname=None,     keysize=None,
   user=None)
          Generate minion RSA public keypair

   salt.wheel.key.gen_signature(priv,         pub,         signature_path,
   auto_create=False, keysize=None)
          Generate master public-key-signature

   salt.wheel.key.print(match)
             Return information about the key. Returns a dictionary.

             match  The key to return information about.

                 >>> wheel.cmd('key.key_str', ['minion1'])

                 {'minions': {'minion1': '-----BEGIN PUBLIC KEY-----
          MIIBIjANBgkqhkiG9w0B
                 ...  TWugEQpPt

          iQIDAQAB -----END PUBLIC KEY-----'}}

   salt.wheel.key.list(match)
          List all the keys under a named status. Returns a dictionary.

          match  The type of keys to list. The  pre,  un,  and  unaccepted
                 options   will  list  unaccepted/unsigned  keys.  acc  or
                 accepted will list accepted/signed keys. rej or  rejected
                 will  list  rejected  keys.   Finally,  all will list all
                 keys.

             >>> wheel.cmd('key.list', ['accepted'])
             {'minions': ['minion1', 'minion2', 'minion3']}

   salt.wheel.key.list_all()
          List all the keys. Returns a dictionary containing lists of  the
          minions   in   each   salt-key   category,   including  minions,
          minions_rejected, minions_denied, etc. Returns a dictionary.

             >>> wheel.cmd('key.list_all')
             {'local': ['master.pem', 'master.pub'], 'minions_rejected': [],
             'minions_denied': [], 'minions_pre': [],
             'minions': ['minion1', 'minion2', 'minion3']}

   salt.wheel.key.name_match(match)
          List all the keys based on a glob match

   salt.wheel.key.reject(match,                    include_accepted=False,
   include_denied=False)
          Reject keys based on a glob match. Returns a dictionary.

          match  The glob match of keys to reject.

          include_accepted
                 To  include accepted keys in the match along with pending
                 keys, set this to True. Defaults to False.

          include_denied
                 To include denied keys in the match  along  with  pending
                 keys, set this to True. Defaults to False.

             >>> wheel.cmd_async({'fun': 'key.reject', 'match': 'minion1'})
             {'jid': '20160826201244808521', 'tag': 'salt/wheel/20160826201244808521'}

   salt.wheel.key.reject_dict(match,               include_accepted=False,
   include_denied=False)
          Reject keys based on a dict of keys. Returns a dictionary.

          match  The dictionary of keys to reject.

          include_accepted
                 To include accepted keys in the match along with  pending
                 keys, set this to True. Defaults to False.

                 New in version 2016.3.4.

          include_denied
                 To  include  denied  keys in the match along with pending
                 keys, set this to True. Defaults to False.

                 New in version 2016.3.4.

             >>> wheel.cmd_async({'fun': 'key.reject_dict',
             'match': {
                 'minions': [
                     'jerry',
                     'stuart',
                     'bob',
                 ],
             })
             {'jid': '20160826201244808521', 'tag': 'salt/wheel/20160826201244808521'}

   salt.wheel.minions
   Wheel system wrapper for connected minions

   salt.wheel.minions.connected()
          List all connected minions on a salt-master

   salt.wheel.pillar_roots
   The pillar_roots wheel module is used to manage files under the  pillar
   roots directories on the master server.

   salt.wheel.pillar_roots.find(path, saltenv='base')
          Return  a  dict  of  the  files  located with the given path and
          environment

   salt.wheel.pillar_roots.list_env(saltenv='base')
          Return all of the file paths found in an environment

   salt.wheel.pillar_roots.list_roots()
          Return all of the files names in all available environments

   salt.wheel.pillar_roots.read(path, saltenv='base')
          Read the contents of a text file, if the file is binary then

   salt.wheel.pillar_roots.write(data, path, saltenv='base', index=0)
          Write the named  file,  by  default  the  first  file  found  is
          written,  but the index of the file can be specified to write to
          a lower priority file root

APIS

   Python client API
   Salt  provides  several  entry  points  for  interfacing  with   Python
   applications.   These  entry  points are often referred to as *Client()
   APIs. Each client accesses different parts of  Salt,  either  from  the
   master or from a minion. Each client is detailed below.

   SEE ALSO:
      There are many ways to access Salt programmatically.

      Salt can be used from CLI scripts as well as via a REST interface.

      See Salt's outputter system to retrieve structured data from Salt as
      JSON, or as shell-friendly text, or many other formats.

      See the state.event runner to utilize Salt's event  bus  from  shell
      scripts.

      Salt's  netapi  module provides access to Salt externally via a REST
      interface.   Review  the  netapi  module  documentation   for   more
      information.

   Salt's opts dictionary
   Some  clients require access to Salt's opts dictionary. (The dictionary
   representation of the master or minion config files.)

   A common pattern for fetching  the  opts  dictionary  is  to  defer  to
   environment  variables if they exist or otherwise fetch the config from
   the default location.

   salt.config.client_config(path,           env_var='SALT_CLIENT_CONFIG',
   defaults=None)
          Load Master configuration data

          Usage:

             import salt.config
             master_opts = salt.config.client_config('/etc/salt/master')

          Returns  a dictionary of the Salt Master configuration file with
          necessary options needed to communicate with  a  locally-running
          Salt  Master daemon.  This function searches for client specific
          configurations and  adds  them  to  the  data  from  the  master
          configuration.

          This is useful for master-side operations like LocalClient.

   salt.config.minion_config(path,           env_var='SALT_MINION_CONFIG',
   defaults=None,    cache_minion_id=False,     ignore_config_errors=True,
   minion_id=None)
          Reads  in  the  minion  configuration  file  and sets up special
          options

          This is useful for Minion-side operations, such  as  the  Caller
          class, and manually running the loader interface.

             import salt.config
             minion_opts = salt.config.minion_config('/etc/salt/minion')

   Salt's Loader Interface
   Modules  in  the  Salt  ecosystem are loaded into memory using a custom
   loader system. This allows modules  to  have  conditional  requirements
   (OS,  OS  version,  installed libraries, etc) and allows Salt to inject
   special variables (__salt__, __opts__, etc).

   Most  modules  can  be  manually  loaded.  This  is  often  useful   in
   third-party  Python  apps  or  when writing tests. However some modules
   require and expect a full,  running  Salt  system  underneath.  Notably
   modules  that  facilitate  master-to-minion  communication  such as the
   mine,  publish,  and  peer  execution  modules.  The  error   KeyError:
   'master_uri'  is  a  likely  indicator  for  this  situation.  In those
   instances use the Caller class to execute those modules instead.

   Each module type has a corresponding loader function.

   salt.loader.minion_mods(opts, context=None, utils=None, whitelist=None,
   initial_load=False,         loaded_base_name=None,        notify=False,
   static_modules=None, proxy=None)
          Load execution modules

          Returns a dictionary of execution modules  appropriate  for  the
          current  system by evaluating the __virtual__() function in each
          module.

          Parameters

                 * opts (dict) -- The Salt options dictionary

                 * context (dict) -- A Salt context that  should  be  made
                   present inside generated modules in __context__

                 * utils  (dict) -- Utility functions which should be made
                   available to Salt modules in __utils__.  See  utils_dir
                   in   salt.config   for   additional  information  about
                   configuration.

                 * whitelist (list) -- A list of modules which  should  be
                   whitelisted.

                 * initial_load (bool) -- Deprecated flag! Unused.

                 * loaded_base_name  (str)  --  A  string  marker  for the
                   loaded base name.

                 * notify (bool) -- Flag indicating that an  event  should
                   be fired upon completion of module loading.

             import salt.config
             import salt.loader

             __opts__ = salt.config.minion_config('/etc/salt/minion')
             __grains__ = salt.loader.grains(__opts__)
             __opts__['grains'] = __grains__
             __utils__ = salt.loader.utils(__opts__)
             __salt__ = salt.loader.minion_mods(__opts__, utils=__utils__)
             __salt__['test.ping']()

   salt.loader.raw_mod(opts, name, functions, mod='modules')
          Returns a single module loaded raw and bypassing the __virtual__
          function

             import salt.config
             import salt.loader

             __opts__ = salt.config.minion_config('/etc/salt/minion')
             testmod = salt.loader.raw_mod(__opts__, 'test', None)
             testmod['test.ping']()

   salt.loader.states(opts, functions, utils, serializers, whitelist=None)
          Returns the state modules

          Parameters

                 * opts (dict) -- The Salt options dictionary

                 * functions (dict) -- A  dictionary  of  minion  modules,
                   with module names as keys and funcs as values.

             import salt.config
             import salt.loader

             __opts__ = salt.config.minion_config('/etc/salt/minion')
             statemods = salt.loader.states(__opts__, None, None)

   salt.loader.grains(opts, force_refresh=False, proxy=None)
          Return  the  functions for the dynamic grains and the values for
          the static grains.

          Since grains are computed early in the startup  process,  grains
          functions  do  not  have  __salt__  or  __proxy__ available.  At
          proxy-minion  startup,  this  function  is   called   with   the
          proxymodule   LazyLoader   object   so   grains   functions  can
          communicate with their controlled device.

             import salt.config
             import salt.loader

             __opts__ = salt.config.minion_config('/etc/salt/minion')
             __grains__ = salt.loader.grains(__opts__)
             print __grains__['id']

   salt.loader.grain_funcs(opts, proxy=None)
          Returns the grain functions

                 import salt.config
                 import salt.loader

                 __opts__ = salt.config.minion_config('/etc/salt/minion')
                 grainfuncs = salt.loader.grain_funcs(__opts__)

   Salt's Client Interfaces
   LocalClient
   class  salt.client.LocalClient(c_path='/etc/salt/master',   mopts=None,
   skip_perm_errors=False,          io_loop=None,         keep_loop=False,
   auto_reconnect=False)
          The interface used by the salt CLI tool on the Salt Master

          LocalClient is used to send a command to Salt minions to execute
          execution modules and return the results to the Salt Master.

          Importing and using LocalClient must be done on the same machine
          as the Salt Master and it must be done using the same user  that
          the   Salt  Master  is  running  as.  (Unless  external_auth  is
          configured and authentication credentials are  included  in  the
          execution).

          NOTE:
             The LocalClient uses a Tornado IOLoop, this can create issues
             when using the LocalClient  inside  an  existing  IOLoop.  If
             creating  the  LocalClient in partnership with another IOLoop
             either create the IOLoop before creating the LocalClient,  or
             when  creating  the  IOLoop  use  ioloop.current() which will
             return the ioloop created by LocalClient.

             import salt.client

             local = salt.client.LocalClient()
             local.cmd('*', 'test.fib', [10])

          cmd(tgt, fun, arg=(),  timeout=None,  expr_form='glob',  ret='',
          jid='', kwarg=None, **kwargs)
                 Synchronously execute a command on targeted minions

                 The  cmd  method  will  execute  and wait for the timeout
                 period for all minions to reply, then it will return  all
                 minion data at once.

                    >>> import salt.client
                    >>> local = salt.client.LocalClient()
                    >>> local.cmd('*', 'cmd.run', ['whoami'])
                    {'jerry': 'root'}

                 With  extra keyword arguments for the command function to
                 be run:

                    local.cmd('*', 'test.arg', ['arg1', 'arg2'], kwarg={'foo': 'bar'})

                 Compound commands can be used for multiple executions  in
                 a  single  publish. Function names and function arguments
                 are provided in separate lists but the index values  must
                 correlate  and an empty list must be used if no arguments
                 are required.

                    >>> local.cmd('*', [
                            'grains.items',
                            'sys.doc',
                            'cmd.run',
                        ],
                        [
                            [],
                            [],
                            ['uptime'],
                        ])

                 Parameters

                        * tgt (string or list) -- Which minions to  target
                          for   the  execution.  Default  is  shell  glob.
                          Modified by the expr_form option.

                        * fun (string or list of strings) --

                          The module and function to call on the specified
                          minions of the form module.function. For example
                          test.ping or grains.items.

                          Compound commands
                                 Multiple functions may  be  called  in  a
                                 single  publish  by  passing  a  list  of
                                 commands.  This  can  dramatically  lower
                                 overhead  and  speed  up  the application
                                 communicating with Salt.

                                 This requires that the  arg  param  is  a
                                 list  of  lists. The fun list and the arg
                                 list must correlate by  index  meaning  a
                                 function  that  does  not  take arguments
                                 must still  have  a  corresponding  empty
                                 list at the expected index.

                        * arg   (list  or  list-of-lists)  --  A  list  of
                          arguments to pass to the remote function. If the
                          function  takes  no arguments arg may be omitted
                          except when executing a compound command.

                        * timeout -- Seconds to wait after the last minion
                          returns but before all minions return.

                        * expr_form --

                          The type of tgt. Allowed values:

                          * glob - Bash glob completion - Default

                          * pcre - Perl style regular expression

                          * list - Python list of hosts

                          * grain - Match based on a grain comparison

                          * grain_pcre - Grain comparison with a regex

                          * pillar - Pillar data comparison

                          * pillar_pcre  -  Pillar  data comparison with a
                            regex

                          * nodegroup - Match on nodegroup

                          * range - Use a Range server for matching

                          * compound - Pass a compound match string

                        * ret -- The returner to use. The value passed can
                          be single returner, or a comma delimited list of
                          returners to call in order on the minions

                        * kwarg -- A dictionary with keyword arguments for
                          the function.

                        * kwargs --

                          Optional   keyword   arguments.   Authentication
                          credentials   may   be   passed    when    using
                          external_auth.

                          For    example:    local.cmd('*',   'test.ping',
                          username='saltdev',          password='saltdev',
                          eauth='pam').   Or:  local.cmd('*', 'test.ping',
                          token='5871821ea51754fdcea8153c1c745433')

                 Returns
                        A dictionary with the  result  of  the  execution,
                        keyed by minion ID. A compound command will return
                        a sub-dictionary keyed by function name.

          cmd_async(tgt, fun, arg=(),  expr_form='glob',  ret='',  jid='',
          kwarg=None, **kwargs)
                 Asynchronously send a command to connected minions

                 The  function  signature  is  the  same as cmd() with the
                 following exceptions.

                 Returns
                        A job ID or 0 on failure.

                    >>> local.cmd_async('*', 'test.sleep', [300])
                    '20131219215921857715'

          cmd_batch(tgt,   fun,    arg=(),    expr_form='glob',    ret='',
          kwarg=None, batch='10%', **kwargs)
                 Iteratively  execute a command on subsets of minions at a
                 time

                 The function signature is the  same  as  cmd()  with  the
                 following exceptions.

                 Parameters
                        batch  --  The  batch  identifier  of  systems  to
                        execute on

                 Returns
                        A generator of minion returns

                    >>> returns = local.cmd_batch('*', 'state.highstate', batch='10%')
                    >>> for ret in returns:
                    ...     print(ret)
                    {'jerry': {...}}
                    {'dave': {...}}
                    {'stewart': {...}}

          cmd_iter(tgt,  fun,  arg=(),   timeout=None,   expr_form='glob',
          ret='', kwarg=None, **kwargs)
                 Yields the individual minion returns as they come in

                 The  function  signature  is  the  same as cmd() with the
                 following exceptions.

                 Returns
                        A generator yielding the individual minion returns

                    >>> ret = local.cmd_iter('*', 'test.ping')
                    >>> for i in ret:
                    ...     print(i)
                    {'jerry': {'ret': True}}
                    {'dave': {'ret': True}}
                    {'stewart': {'ret': True}}

          cmd_iter_no_block(tgt,      fun,      arg=(),      timeout=None,
          expr_form='glob',     ret='',     kwarg=None,    show_jid=False,
          verbose=False, **kwargs)

                 Yields the individual minion returns as they come in,  or
                 None
                        when no returns are available.

                 The  function  signature  is  the  same as cmd() with the
                 following exceptions.

                 Returns
                        A  generator  yielding   the   individual   minion
                        returns,  or  None  when no returns are available.
                        This allows for actions to be injected in  between
                        minion returns.

                    >>> ret = local.cmd_iter_no_block('*', 'test.ping')
                    >>> for i in ret:
                    ...     print(i)
                    None
                    {'jerry': {'ret': True}}
                    {'dave': {'ret': True}}
                    None
                    {'stewart': {'ret': True}}

          cmd_subset(tgt,    fun,    arg=(),   expr_form='glob',   ret='',
          kwarg=None, sub=3, cli=False, progress=False, **kwargs)
                 Execute a command on a  random  subset  of  the  targeted
                 systems

                 The  function  signature  is  the  same as cmd() with the
                 following exceptions.

                 Parameters
                        sub -- The number of systems to execute on

                    >>> SLC.cmd_subset('*', 'test.ping', sub=1)
                    {'jerry': True}

          get_cli_returns(jid,     minions,     timeout=None,     tgt='*',
          tgt_type='glob', verbose=False, show_jid=False, **kwargs)
                 Starts  a  watcher  looking  at  the  return  data  for a
                 specified JID

                 Returns
                        all of the information for the JID

          get_event_iter_returns(jid, minions, timeout=None)
                 Gather the return data from the event system, break  hard
                 when timeout is reached.

          run_job(tgt,     fun,    arg=(),    expr_form='glob',    ret='',
          timeout=None, jid='', kwarg=None, listen=False, **kwargs)
                 Asynchronously send a command to connected minions

                 Prep the job directory  and  publish  a  command  to  any
                 targeted minions.

                 Returns
                        A  dictionary  of (validated) pub_data or an empty
                        dictionary on failure. The pub_data  contains  the
                        job ID and a list of all minions that are expected
                        to return data.

                    >>> local.run_job('*', 'test.sleep', [300])
                    {'jid': '20131219215650131543', 'minions': ['jerry']}

   Salt Caller
   class salt.client.Caller(c_path='/etc/salt/minion', mopts=None)
          Caller is the same interface used by the salt-call  command-line
          tool on the Salt Minion.

          Changed   in   version   2015.8.0:  Added  the  cmd  method  for
          consistency with the other Salt clients.  The existing  function
          and  sminion.functions  interfaces  still  exist  but  have been
          removed from the docs.

          Importing and using Caller must be done on the same machine as a
          Salt  Minion  and  it  must be done using the same user that the
          Salt Minion is running as.

          Usage:

             import salt.client
             caller = salt.client.Caller()
             caller.cmd('test.ping')

          Note, a running master or minion daemon is not required  to  use
          this  class.   Running salt-call --local simply sets file_client
          to 'local'. The same can be achieved  at  the  Python  level  by
          including that setting in a minion config file.

          New  in  version  2014.7.0:  Pass the minion config as the mopts
          dictionary.

             import salt.client
             import salt.config
             __opts__ = salt.config.minion_config('/etc/salt/minion')
             __opts__['file_client'] = 'local'
             caller = salt.client.Caller(mopts=__opts__)

          cmd(fun, *args, **kwargs)
                 Call an execution module with  the  given  arguments  and
                 keyword arguments

                 Changed  in  version  2015.8.0:  Added the cmd method for
                 consistency with the other Salt  clients.   The  existing
                 function and sminion.functions interfaces still exist but
                 have been removed from the docs.

                    caller.cmd('test.arg', 'Foo', 'Bar', baz='Baz')

                    caller.cmd('event.send', 'myco/myevent/something',
                        data={'foo': 'Foo'}, with_env=['GIT_COMMIT'], with_grains=True)

   RunnerClient
   class salt.runner.RunnerClient(opts)
          The interface used by the salt-run CLI tool on the Salt Master

          It executes runner modules which run on the Salt Master.

          Importing and using  RunnerClient  must  be  done  on  the  same
          machine  as  the  Salt Master and it must be done using the same
          user that the Salt Master is running as.

          Salt's external_auth can be  used  to  authenticate  calls.  The
          eauth  user  must  be  authorized  to  execute  runner  modules:
          (@runner).  Only the master_call() below supports eauth.

          async(fun, low, user='UNKNOWN', pub=None)
                 Execute the function in a  multiprocess  and  return  the
                 event tag to use to watch for the return

          cmd(fun,  arg=None, pub_data=None, kwarg=None, print_event=True,
          full_return=False)
                 Execute a function

          cmd_async(low)
                 Execute  a  runner  function  asynchronously;  eauth   is
                 respected

                 This  function  requires that external_auth is configured
                 and the user is authorized to execute  runner  functions:
                 (@runner).

                    runner.eauth_async({
                        'fun': 'jobs.list_jobs',
                        'username': 'saltdev',
                        'password': 'saltdev',
                        'eauth': 'pam',
                    })

          cmd_sync(low, timeout=None)
                 Execute   a   runner  function  synchronously;  eauth  is
                 respected

                 This function requires that external_auth  is  configured
                 and  the  user is authorized to execute runner functions:
                 (@runner).

                    runner.eauth_sync({
                        'fun': 'jobs.list_jobs',
                        'username': 'saltdev',
                        'password': 'saltdev',
                        'eauth': 'pam',
                    })

   WheelClient
   class salt.wheel.WheelClient(opts=None)
          An interface to Salt's wheel modules

          Wheel modules interact with various parts of the Salt Master.

          Importing and using WheelClient must be done on the same machine
          as  the Salt Master and it must be done using the same user that
          the  Salt  Master  is  running  as.  Unless   external_auth   is
          configured   and   the  user  is  authorized  to  execute  wheel
          functions: (@wheel).

          Usage:

             import salt.config
             import salt.wheel
             opts = salt.config.master_config('/etc/salt/master')
             wheel = salt.wheel.WheelClient(opts)

          async(fun, low, user='UNKNOWN', pub=None)
                 Execute the function in a  multiprocess  and  return  the
                 event tag to use to watch for the return

          cmd(fun,  arg=None, pub_data=None, kwarg=None, print_event=True,
          full_return=False)
                 Execute a function

                    >>> wheel.cmd('key.finger', ['jerry'])
                    {'minions': {'jerry': '5d:f6:79:43:5e:d4:42:3f:57:b8:45:a8:7e:a4:6e:ca'}}

          cmd_async(low)
                 Execute a function asynchronously; eauth is respected

                 This function requires that external_auth  is  configured
                 and the user is authorized

                    >>> wheel.cmd_async({
                        'fun': 'key.finger',
                        'match': 'jerry',
                        'eauth': 'auto',
                        'username': 'saltdev',
                        'password': 'saltdev',
                    })
                    {'jid': '20131219224744416681', 'tag': 'salt/wheel/20131219224744416681'}

          cmd_sync(low, timeout=None)
                 Execute   a   wheel   function  synchronously;  eauth  is
                 respected

                 This function requires that external_auth  is  configured
                 and  the  user is authorized to execute runner functions:
                 (@wheel).

                    >>> wheel.cmd_sync({
                    'fun': 'key.finger',
                    'match': 'jerry',
                    'eauth': 'auto',
                    'username': 'saltdev',
                    'password': 'saltdev',
                    })
                    {'minions': {'jerry': '5d:f6:79:43:5e:d4:42:3f:57:b8:45:a8:7e:a4:6e:ca'}}

   CloudClient
   class  salt.cloud.CloudClient(path=None,  opts=None,   config_dir=None,
   pillars=None)
          The client class to wrap cloud interactions

          action(fun=None,   cloudmap=None,   names=None,   provider=None,
          instance=None, kwargs=None)
                 Execute a single action via the cloud plugin backend

                 Examples:

                    client.action(fun='show_instance', names=['myinstance'])
                    client.action(fun='show_image', provider='my-ec2-config',
                        kwargs={'image': 'ami-10314d79'}
                    )

          create(provider, names, **kwargs)
                 Create the named VMs, without using a profile

                 Example:

                    client.create(names=['myinstance'], provider='my-ec2-config',
                        kwargs={'image': 'ami-1624987f', 'size': 't1.micro',
                                'ssh_username': 'ec2-user', 'securitygroup': 'default',
                                'delvol_on_destroy': True})

          destroy(names)
                 Destroy the named VMs

          extra_action(names, provider, action, **kwargs)
                 Perform actions with block storage devices

                 Example:

                    client.extra_action(names=['myblock'], action='volume_create',
                        provider='my-nova', kwargs={'voltype': 'SSD', 'size': 1000}
                    )
                    client.extra_action(names=['salt-net'], action='network_create',
                        provider='my-nova', kwargs={'cidr': '192.168.100.0/24'}
                    )

          full_query(query_type='list_nodes_full')
                 Query all instance information

          list_images(provider=None)
                 List all available images in configured cloud systems

          list_locations(provider=None)
                 List all available locations in configured cloud systems

          list_sizes(provider=None)
                 List all available sizes in configured cloud systems

          low(fun, low)
                 Pass the cloud function and low data structure to run

          map_run(path, **kwargs)
                 Pass in a location for a map to execute

          min_query(query_type='list_nodes_min')
                 Query select instance information

          profile(profile, names, vm_overrides=None, **kwargs)
                 Pass in a profile to create, names is a list of vm  names
                 to allocate
                    vm_overrides  is  a special dict that will be per node
                    options overrides

                 Example:

                    >>> client= salt.cloud.CloudClient(path='/etc/salt/cloud')
                    >>> client.profile('do_512_git', names=['minion01',])
                    {'minion01': {u'backups_active': 'False',
                            u'created_at': '2014-09-04T18:10:15Z',
                            u'droplet': {u'event_id': 31000502,
                                         u'id': 2530006,
                                         u'image_id': 5140006,
                                         u'name': u'minion01',
                                         u'size_id': 66},
                            u'id': '2530006',
                            u'image_id': '5140006',
                            u'ip_address': '107.XXX.XXX.XXX',
                            u'locked': 'True',
                            u'name': 'minion01',
                            u'private_ip_address': None,
                            u'region_id': '4',
                            u'size_id': '66',
                            u'status': 'new'}}

          query(query_type='list_nodes')
                 Query basic instance information

          select_query(query_type='list_nodes_select')
                 Query select instance information

   SSHClient
   class       salt.client.ssh.client.SSHClient(c_path='/etc/salt/master',
   mopts=None)
          Create  a  client object for executing routines via the salt-ssh
          backend

          New in version 2015.5.0.

          cmd(tgt,   fun,    arg=(),    timeout=None,    expr_form='glob',
          kwarg=None, **kwargs)
                 Execute  a  single command via the salt-ssh subsystem and
                 return all routines at once

                 New in version 2015.5.0.

          cmd_iter(tgt,  fun,  arg=(),   timeout=None,   expr_form='glob',
          ret='', kwarg=None, **kwargs)
                 Execute  a  single command via the salt-ssh subsystem and
                 return a generator

                 New in version 2015.5.0.

   netapi modules
   Introduction to netapi modules
   netapi  modules   provide   API-centric   access   to   Salt.   Usually
   externally-facing  services  such  as REST or WebSockets, XMPP, XMLRPC,
   etc.

   In general netapi modules bind to a port and start a service. They  are
   purposefully  open-ended.  A  single module can be configured to run as
   well as multiple modules simultaneously.

   netapi modules are enabled by adding configuration to your Salt  Master
   config  file  and then starting the salt-api daemon. Check the docs for
   each module to see external requirements and configuration settings.

   Communication with Salt and  Salt  satellite  projects  is  done  using
   Salt's own Python API. A list of available client interfaces is below.

      salt-api

             Prior to Salt's 2014.7.0 release, netapi modules lived in the
             separate sister projected salt-api.  That  project  has  been
             merged into the main Salt project.

   SEE ALSO:
      The full list of netapi modules

   Client interfaces
   Salt's  client  interfaces  expose  executing  functions  by crafting a
   dictionary of values that are mapped to function arguments. This allows
   calling  functions  simply  by  creating a data structure. (And this is
   exactly how much of Salt's own internals work!)

   class salt.netapi.NetapiClient(opts)
          Provide  a  uniform  method  of  accessing  the  various  client
          interfaces  in Salt in the form of low-data data structures. For
          example:

          >>> client = NetapiClient(__opts__)
          >>> lowstate = {'client': 'local', 'tgt': '*', 'fun': 'test.ping', 'arg': ''}
          >>> client.run(lowstate)

          local(*args, **kwargs)
                 Run execution modules synchronously

                 See  salt.client.LocalClient.cmd()  for   all   available
                 parameters.

                 Sends  a command from the master to the targeted minions.
                 This is the same interface that Salt's own CLI uses. Note
                 the  arg  and  kwarg  parameters  are  sent  down  to the
                 minion(s) and the given function,  fun,  is  called  with
                 those parameters.

                 Returns
                        Returns the result from the execution module

          local_async(*args, **kwargs)
                 Run execution modules asynchronously

                 Wraps salt.client.LocalClient.run_job().

                 Returns
                        job ID

          local_batch(*args, **kwargs)
                 Run execution modules against batches of minions

                 Wraps salt.client.LocalClient.cmd_batch()

                 Returns
                        Returns  the  result from the exeuction module for
                        each batch of returns

          local_subset(*args, **kwargs)
                 Run execution modules against subsets of minions

                 New in version 2016.3.0.

                 Wraps salt.client.LocalClient.cmd_subset()

          runner(fun, timeout=None, **kwargs)
                 Run runner modules <all-salt.runners> synchronously

                 Wraps salt.runner.RunnerClient.cmd_sync().

                 Note that runner functions must be called  using  keyword
                 arguments.  Positional arguments are not supported.

                 Returns
                        Returns the result from the runner module

          runner_async(fun, **kwargs)
                 Run runner modules <all-salt.runners> asynchronously

                 Wraps salt.runner.RunnerClient.cmd_async().

                 Note  that  runner functions must be called using keyword
                 arguments.  Positional arguments are not supported.

                 Returns
                        event data and a job ID for the executed function.

          ssh(*args, **kwargs)
                 Run salt-ssh commands synchronously

                 Wraps salt.client.ssh.client.SSHClient.cmd_sync().

                 Returns
                        Returns the result from the salt-ssh command

          wheel(fun, **kwargs)
                 Run wheel modules synchronously

                 Wraps salt.wheel.WheelClient.master_call().

                 Note that wheel functions must be  called  using  keyword
                 arguments.  Positional arguments are not supported.

                 Returns
                        Returns the result from the wheel module

          wheel_async(fun, **kwargs)
                 Run wheel modules asynchronously

                 Wraps salt.wheel.WheelClient.master_call().

                 Note  that  wheel  functions must be called using keyword
                 arguments.  Positional arguments are not supported.

                 Returns
                        Returns the result from the wheel module

   HTTP Modules
   This tutorial demonstrates using the various HTTP modules available  in
   Salt.   These  modules  wrap  the Python tornado, urllib2, and requests
   libraries, extending them in a manner that is more consistent with Salt
   workflows.

   The salt.utils.http Library
   This  library  forms the core of the HTTP modules. Since it is designed
   to be used from the minion as an execution module, in addition  to  the
   master as a runner, it was abstracted into this multi-use library. This
   library can also be imported by  3rd-party  programs  wishing  to  take
   advantage of its extended functionality.

   Core  functionality  of  the  execution,  state,  and runner modules is
   derived from this library, so common usages between them are  described
   here. Documentation specific to each module is described below.

   This library can be imported with:

      import salt.utils.http

   Configuring Libraries
   This library can make use of either tornado, which is required by Salt,
   urllib2, which ships with Python, or requests, which can  be  installed
   separately.  By  default,  tornado  will be used. In order to switch to
   urllib2, set the following variable:

      backend: urllib2

   In order to switch to requests, set the following variable:

      backend: requests

   This can be set in the master or minion configuration file,  or  passed
   as an option directly to any http.query() functions.

   salt.utils.http.query()
   This function forms a basic query, but with some add-ons not present in
   the tornado, urllib2, and requests  libraries.  Not  all  functionality
   currently  available  in  these libraries has been added, but can be in
   future iterations.

   HTTPS Request Methods
   A basic query can be performed by calling this function  with  no  more
   than a single URL:

      salt.utils.http.query('http://example.com')

   By  default  the  query will be performed with a GET method. The method
   can be overridden with the method argument:

      salt.utils.http.query('http://example.com/delete/url', 'DELETE')

   When using the POST method (and others, such as  PUT),  extra  data  is
   usually  sent  as  well.  This  data  can be sent directly, in whatever
   format is required by the remote server (XML, JSON, plain text, etc).

      salt.utils.http.query(
          'http://example.com/delete/url',
          method='POST',
          data=json.loads(mydict)
      )

   Data Formatting and Templating
   Bear in mind that the data must be sent  pre-formatted;  this  function
   will  not  format  it  for you. However, a templated file stored on the
   local system may be passed through, along with variables to populate it
   with. To pass through only the file (untemplated):

      salt.utils.http.query(
          'http://example.com/post/url',
          method='POST',
          data_file='/srv/salt/somefile.xml'
      )

   To  pass  through  a  file  that  contains jinja + yaml templating (the
   default):

      salt.utils.http.query(
          'http://example.com/post/url',
          method='POST',
          data_file='/srv/salt/somefile.jinja',
          data_render=True,
          template_data={'key1': 'value1', 'key2': 'value2'}
      )

   To pass through a file that contains mako templating:

      salt.utils.http.query(
          'http://example.com/post/url',
          method='POST',
          data_file='/srv/salt/somefile.mako',
          data_render=True,
          data_renderer='mako',
          template_data={'key1': 'value1', 'key2': 'value2'}
      )

   Because this function  uses  Salt's  own  rendering  system,  any  Salt
   renderer  can  be used. Because Salt's renderer requires __opts__ to be
   set, an opts dictionary should be passed in. If it  is  not,  then  the
   default  __opts__  values  for the node type (master or minion) will be
   used. Because this library is intended primarily for  use  by  minions,
   the  default  node  type  is  minion.   However, this can be changed to
   master if necessary.

      salt.utils.http.query(
          'http://example.com/post/url',
          method='POST',
          data_file='/srv/salt/somefile.jinja',
          data_render=True,
          template_data={'key1': 'value1', 'key2': 'value2'},
          opts=__opts__
      )

      salt.utils.http.query(
          'http://example.com/post/url',
          method='POST',
          data_file='/srv/salt/somefile.jinja',
          data_render=True,
          template_data={'key1': 'value1', 'key2': 'value2'},
          node='master'
      )

   Headers
   Headers may  also  be  passed  through,  either  as  a  header_list,  a
   header_dict,   or   as  a  header_file.  As  with  the  data_file,  the
   header_file may also be templated. Take note that because HTTP  headers
   are  normally  syntactically-correct  YAML,  they will automatically be
   imported as an a Python dict.

      salt.utils.http.query(
          'http://example.com/delete/url',
          method='POST',
          header_file='/srv/salt/headers.jinja',
          header_render=True,
          header_renderer='jinja',
          template_data={'key1': 'value1', 'key2': 'value2'}
      )

   Because much of the data that would be templated  between  headers  and
   data  may  be  the  same,  the  template_data  is  the  same  for both.
   Correcting possible variable name collisions is up to the user.

   Authentication
   The query() function supports basic HTTP authentication. A username and
   password may be passed in as username and password, respectively.

      salt.utils.http.query(
          'http://example.com',
          username='larry',
          password=`5700g3543v4r`,
      )

   Cookies and Sessions
   Cookies are also supported, using Python's built-in cookielib. However,
   they are turned off by default. To turn  cookies  on,  set  cookies  to
   True.

      salt.utils.http.query(
          'http://example.com',
          cookies=True
      )

   By  default  cookies  are  stored  in  Salt's cache directory, normally
   /var/cache/salt, as a file called cookies.txt. However,  this  location
   may be changed with the cookie_jar argument:

      salt.utils.http.query(
          'http://example.com',
          cookies=True,
          cookie_jar='/path/to/cookie_jar.txt'
      )

   By  default,  the  format of the cookie jar is LWP (aka, lib-www-perl).
   This default was chosen because it is a human-readable  text  file.  If
   desired, the format of the cookie jar can be set to Mozilla:

      salt.utils.http.query(
          'http://example.com',
          cookies=True,
          cookie_jar='/path/to/cookie_jar.txt',
          cookie_format='mozilla'
      )

   Because  Salt  commands  are  normally  one-off commands that are piped
   together, this library cannot normally behave as a normal browser, with
   session  cookies  that  persist across multiple HTTP requests. However,
   the session can be persisted in a  separate  cookie  jar.  The  default
   filename   for   this   file,   inside   Salt's   cache  directory,  is
   cookies.session.p. This can also be changed.

      salt.utils.http.query(
          'http://example.com',
          persist_session=True,
          session_cookie_jar='/path/to/jar.p'
      )

   The format of this file is msgpack, which is consistent  with  much  of
   the  rest of Salt's internal structure. Historically, the extension for
   this file is .p. There are no current plans to make this configurable.

   Proxy
   If the  tornado  backend  is  used  (tornado  is  the  default),  proxy
   information  configured  in proxy_host, proxy_port, proxy_username, and
   proxy_password from the __opts__ dictionary  will  be  used.   Normally
   these are set in the minion configuration file.

      proxy_host: proxy.my-domain
      proxy_port: 31337
      proxy_username: charon
      proxy_password: obolus

      salt.utils.http.query(
          'http://example.com',
          opts=__opts__,
          backend='tornado'
      )

   Return Data
   NOTE:
      Return data encoding

      If  decode is set to True, query() will attempt to decode the return
      data. decode_type defaults to auto.  Set it to a specific  encoding,
      xml, for example, to override autodetection.

   Because  Salt's  http  library  was  designed  to  be  used  with  REST
   interfaces, query() will attempt to decode the data received  from  the
   remote  server  when  decode  is  set to True.  First it will check the
   Content-type header to try and find references to XML. If it  does  not
   find any, it will look for references to JSON. If it does not find any,
   it will fall back to plain text, which will not be decoded.

   JSON data is translated  into  a  dict  using  Python's  built-in  json
   library.   XML  is translated using salt.utils.xml_util, which will use
   Python's built-in XML libraries to attempt to convert the  XML  into  a
   dict.  In  order  to force either JSON or XML decoding, the decode_type
   may be set:

      salt.utils.http.query(
          'http://example.com',
          decode_type='xml'
      )

   Once translated, the return dict  from  query()  will  include  a  dict
   called dict.

   If  the  data  is  not  to  be  translated  using one of these methods,
   decoding may be turned off.

      salt.utils.http.query(
          'http://example.com',
          decode=False
      )

   If decoding is turned on, and references  to  JSON  or  XML  cannot  be
   found,  then  this  module  will  default to plain text, and return the
   undecoded data as text (even if text is set to False; see below).

   The query() function can return the HTTP status code,  headers,  and/or
   text as required. However, each must individually be turned on.

      salt.utils.http.query(
          'http://example.com',
          status=True,
          headers=True,
          text=True
      )

   The  return  from  these  will  be  found in the return dict as status,
   headers and text, respectively.

   Writing Return Data to Files
   It is possible to write either the return data or headers to files,  as
   soon  as  the response is received from the server, but specifying file
   locations via the text_out or headers_out arguments. text  and  headers
   do not need to be returned to the user in order to do this.

      salt.utils.http.query(
          'http://example.com',
          text=False,
          headers=False,
          text_out='/path/to/url_download.txt',
          headers_out='/path/to/headers_download.txt',
      )

   SSL Verification
   By  default,  this  function will verify SSL certificates. However, for
   testing or debugging purposes, SSL verification can be turned off.

      salt.utils.http.query(
          'https://example.com',
          verify_ssl=False,
      )

   CA Bundles
   The  requests  library  has  its  own  method  of  detecting  which  CA
   (certificate authority) bundle file to use. Usually this is implemented
   by the packager for the specific operating system distribution that you
   are using. However, urllib2 requires a little more work under the hood.
   By default, Salt will try to auto-detect the  location  of  this  file.
   However,  if  it  is  not  in an expected location, or a different path
   needs to be specified, it may be done so using the ca_bundle variable.

      salt.utils.http.query(
          'https://example.com',
          ca_bundle='/path/to/ca_bundle.pem',
      )

   The update_ca_bundle() function can be used to update the  bundle  file
   at  a specified location. If the target location is not specified, then
   it will attempt to auto-detect the location of the bundle file. If  the
   URL  to  download  the  bundle  from  does  not exist, a bundle will be
   downloaded from the cURL website.

   CAUTION: The target and the source should always be specified!  Failure
   to specify the target may result in the file being written to the wrong
   location on the local system. Failure to specify the source  may  cause
   the upstream URL to receive excess unnecessary traffic, and may cause a
   file to be download which is hazardous or does not meet  the  needs  of
   the user.

      salt.utils.http.update_ca_bundle(
          target='/path/to/ca-bundle.crt',
          source='https://example.com/path/to/ca-bundle.crt',
          opts=__opts__,
      )

   The  opts parameter should also always be specified. If it is, then the
   target and the source may be specified in  the  relevant  configuration
   file (master or minion) as ca_bundle and ca_bundle_url, respectively.

      ca_bundle: /path/to/ca-bundle.crt
      ca_bundle_url: https://example.com/path/to/ca-bundle.crt

   If Salt is unable to auto-detect the location of the CA bundle, it will
   raise an error.

   The update_ca_bundle() function can also be passed a string or  a  list
   of  strings  which represent files on the local system, which should be
   appended (in the specified order) to the end of  the  CA  bundle  file.
   This  is  useful  in  environments  where private certs need to be made
   available, and are not otherwise reasonable to add to the bundle file.

      salt.utils.http.update_ca_bundle(
          opts=__opts__,
          merge_files=[
              '/etc/ssl/private_cert_1.pem',
              '/etc/ssl/private_cert_2.pem',
              '/etc/ssl/private_cert_3.pem',
          ]
      )

   Test Mode
   This function may be run in test mode. This mode will perform all  work
   up until the actual HTTP request. By default, instead of performing the
   request, an empty dict will be returned. Using this function with TRACE
   logging turned on will reveal the contents of the headers and POST data
   to be sent.

   Rather than returning an empty  dict,  an  alternate  test_url  may  be
   passed  in.   If  this is detected, then test mode will replace the url
   with the test_url, set test to True in the return data, and perform the
   rest  of  the  requested  operations  as  usual.  This allows a custom,
   non-destructive URL to be used for testing when necessary.

   Execution Module
   The  http  execution  module  is  a  very  thin  wrapper   around   the
   salt.utils.http library. The opts can be passed through as well, but if
   they are not specified, the minion defaults will be used as necessary.

   Because passing complete data structures from the command line  can  be
   tricky  at best and dangerous (in terms of execution injection attacks)
   at worse, the data_file, and header_file are likely  to  see  more  use
   here.

   All  methods  for the library are available in the execution module, as
   kwargs.

      salt myminion http.query http://example.com/restapi method=POST \
          username='larry' password='5700g3543v4r' headers=True text=True \
          status=True decode_type=xml data_render=True \
          header_file=/tmp/headers.txt data_file=/tmp/data.txt \
          header_render=True cookies=True persist_session=True

   Runner Module
   Like the execution module, the  http  runner  module  is  a  very  thin
   wrapper  around  the  salt.utils.http  library.  The  only  significant
   difference is that because runners execute on the master instead  of  a
   minion, a target is not required, and default opts will be derived from
   the master config, rather than the minion config.

   All methods for the library are available  in  the  runner  module,  as
   kwargs.

      salt-run http.query http://example.com/restapi method=POST \
          username='larry' password='5700g3543v4r' headers=True text=True \
          status=True decode_type=xml data_render=True \
          header_file=/tmp/headers.txt data_file=/tmp/data.txt \
          header_render=True cookies=True persist_session=True

   State Module
   The  state  module is a wrapper around the runner module, which applies
   stateful logic to a query. All kwargs as listed above are specified  as
   usual  in  state  files,  but  two  more  kwargs are available to apply
   stateful logic. A  required  parameter  is  match,  which  specifies  a
   pattern to look for in the return text. By default, this will perform a
   string comparison of looking for the value of match in the return text.
   In Python terms this looks like:

      if match in html_text:
          return True

   If  more complex pattern matching is required, a regular expression can
   be used by specifying a match_type. By default this is set  to  string,
   but  it  can  be manually set to pcre instead. Please note that despite
   the name, this will use Python's re.search() rather than re.match().

   Therefore, the following states are valid:

      http://example.com/restapi:
        http.query:
          - match: 'SUCCESS'
          - username: 'larry'
          - password: '5700g3543v4r'
          - data_render: True
          - header_file: /tmp/headers.txt
          - data_file: /tmp/data.txt
          - header_render: True
          - cookies: True
          - persist_session: True

      http://example.com/restapi:
        http.query:
          - match_type: pcre
          - match: '(?i)succe[ss|ed]'
          - username: 'larry'
          - password: '5700g3543v4r'
          - data_render: True
          - header_file: /tmp/headers.txt
          - data_file: /tmp/data.txt
          - header_render: True
          - cookies: True
          - persist_session: True

   In addition to, or instead of a match pattern, the status  code  for  a
   URL can be checked. This is done using the status argument:

      http://example.com/:
        http.query:
          - status: '200'

   If  both  are  specified, both will be checked, but if only one is True
   and the other is False, then False will be returned. In this case,  the
   comments   in   the   return   data   will   contain   information  for
   troubleshooting.

   Because this is a monitoring state, it will return extra data  to  code
   that  expects  it.  This  data  will  always  include  text and status.
   Optionally, headers and dict may  also  be  requested  by  setting  the
   headers and decode arguments to True, respectively.

   Writing netapi modules
   netapi  modules, put simply, bind a port and start a service.  They are
   purposefully open-ended and  can  be  used  to  present  a  variety  of
   external  interfaces  to  Salt, and even present multiple interfaces at
   once.

   SEE ALSO:
      The full list of netapi modules

   Configuration
   All netapi configuration is done in the Salt master config and takes  a
   form similar to the following:

      rest_cherrypy:
        port: 8000
        debug: True
        ssl_crt: /etc/pki/tls/certs/localhost.crt
        ssl_key: /etc/pki/tls/certs/localhost.key

   The __virtual__ function
   Like  all module types in Salt, netapi modules go through Salt's loader
   interface to determine if they should be loaded into  memory  and  then
   executed.

   The  __virtual__  function  in  the module makes this determination and
   should return False or a string that will serve  as  the  name  of  the
   module.  If  the  module  raises an ImportError or any other errors, it
   will not be loaded.

   The start function
   The start() function will be called for  each  netapi  module  that  is
   loaded.  This  function  should  contain  the server loop that actually
   starts the service. This is started in a multiprocess.

   Multiple instances
   New in version 2016.11.0.

   rest_cherrypy and rest_tornado support running  multiple  instances  by
   copying  and  renaming  entire  directory of those. To start the copied
   multiple netapi modules, add configuration blocks for the copied netapi
   modules in the Salt Master config. The name of each added configuration
   block must match with the name of each directory of the  copied  netapi
   module.

   Inline documentation
   As  with  the  rest  of  Salt, it is a best-practice to include liberal
   inline documentation in the form of a module docstring  and  docstrings
   on any classes, methods, and functions in your netapi module.

   Loader "magic" methods
   The  loader makes the __opts__ data structure available to any function
   in a netapi module.

ARCHITECTURE

   If you are used to configuration management tools that require  you  to
   plan  down  to  the  last  detail  before you install anything, you are
   probably  wondering  why  this  section  doesn't  appear   before   the
   installation  instructions.  With  Salt,  you  can  switch  to  a  high
   availability architecture at any time, and add additional components to
   scale your deployment as you go.

   Since  a single Salt master can manage thousands of systems, we usually
   recommend that you start by deploying a single Salt  master,  and  then
   modifying  your  deployment  as  needed  for  redundancy,  geographical
   distribution, and scale.

   High Availability Features in Salt
   Salt  supports  several  features  for  high  availability  and   fault
   tolerance.   Brief documentation for these features is listed alongside
   their configuration parameters in Configuration file examples.

   Multimaster
   Salt minions can connect to multiple masters at one time by configuring
   the  master configuration parameter as a YAML list of all the available
   masters.  By default, all masters are "hot", meaning  that  any  master
   can direct commands to the Salt infrastructure.

   In  a  multimaster  configuration,  each  master  must  have  the  same
   cryptographic keys, and minion keys must be  accepted  on  all  masters
   separately.   The  contents  of  file_roots and pillar_roots need to be
   kept in sync with processes external to Salt as well

   A tutorial on setting up multimaster with "hot" masters is here:

   Multimaster Tutorial

   Multimaster with Failover
   Changing the master_type parameter from  str  to  failover  will  cause
   minions  to  connect  to  the  first  responding  master in the list of
   masters. Every master_alive_interval seconds the minions will check  to
   make  sure  the current master is still responding.  If the master does
   not respond, the minion will attempt to connect to the next  master  in
   the list.  If the minion runs out of masters, the list will be recycled
   in   case   dead   masters   have    been    restored.     Note    that
   master_alive_interval  must  be present in the minion configuration, or
   else the recurring job to check master status will not get scheduled.

   Failover can be combined with PKI-style encrypted keys, but PKI is  NOT
   REQUIRED to use failover.

   Multimaster with PKI and Failover is discussed in this tutorial

   master_type:  failover  can  be  combined  with master_shuffle: True to
   spread minion connections across all masters (one  master  per  minion,
   not  each  minion connecting to all masters).  Adding Salt Syndics into
   the  mix  makes  it   possible   to   create   a   load-balanced   Salt
   infrastructure.   If  a  master  fails,  minions will notice and select
   another master from the available list.

   Syndic
   Salt's Syndic feature is  a  way  to  create  differing  infrastructure
   topologies.   It  is  not strictly an HA feature, but can be treated as
   such.

   With the syndic, a Salt infrastructure can be partitioned in such a way
   that  certain  masters  control certain segments of the infrastructure,
   and "Master of Masters" nodes can control multiple segments  underneath
   them.

   Syndics are covered in depth in Salt Syndic.

   Syndic with Multimaster
   New in version 2015.5.0.

   Syndic  with  Multimaster lets you connect a syndic to multiple masters
   to provide an additional layer of redundancy in a syndic configuration.

   Syndics are covered in depth in Salt Syndic.

   Salt Syndic
   The most basic or typical Salt topology consists  of  a  single  Master
   node  controlling  a group of Minion nodes.  An intermediate node type,
   called Syndic, when used  offers  greater  structural  flexibility  and
   scalability  in  the  construction  of  Salt topologies than topologies
   constructed only out of Master and Minion node types.

   A Syndic node can be thought of as a special passthrough  Minion  node.
   A Syndic node consists of a salt-syndic daemon and a salt-master daemon
   running on the same system.  The  salt-master  daemon  running  on  the
   Syndic  node  controls  a  group  of  lower  level Minion nodes and the
   salt-syndic daemon connects higher level Master node, sometimes  called
   a Master of Masters.

   The  salt-syndic  daemon  relays  publications  and  events between the
   Master node and the local salt-master daemon.  This  gives  the  Master
   node  control  over the Minion nodes attached to the salt-master daemon
   running on the Syndic node.

   Configuring the Syndic
   To setup a Salt Syndic you need to tell the Syndic node and its  Master
   node  about  each  other.  If your Master node is located at 10.10.0.1,
   then your configurations would be:

   On the Syndic node:

      # /etc/salt/master
      syndic_master: 10.10.0.1  # may be either an IP address or a hostname

      # /etc/salt/minion

      # id is shared by the salt-syndic daemon and a possible salt-minion daemon
      # on the Syndic node
      id: my_syndic

   On the Master node:

      # /etc/salt/master
      order_masters: True

   The syndic_master option tells the Syndic node where to find the Master
   node  in  the same way that the master option tells a Minion node where
   to find a Master node.

   The id option is used by the salt-syndic daemon to  identify  with  the
   Master  node and if unset will default to the hostname or IP address of
   the Syndic just as with a Minion.

   The order_masters option configures  the  Master  node  to  send  extra
   information  with  its  publications  that  is  needed  by Syndic nodes
   connected directly to it.

   NOTE:
      Each Syndic must provide its own file_roots  directory.  Files  will
      not be automatically transferred from the Master node.

   Configuring the Syndic with Multimaster
   New in version 2015.5.0.

   Syndic  with  Multimaster lets you connect a syndic to multiple masters
   to provide an additional layer of redundancy in a syndic configuration.

   Higher level masters  should  first  be  configured  in  a  multimaster
   configuration.  See Multimaster Tutorial.

   On the syndic, the syndic_master option is populated with a list of the
   higher level masters.

   Since each syndic is connected to  each  master,  jobs  sent  from  any
   master  are  forwarded to minions that are connected to each syndic. If
   the master_id value is set in the master config  on  the  higher  level
   masters,  job  results  are  returned to the master that originated the
   request in a best effort fashion. Events/jobs without a  master_id  are
   returned to any available master.

   Running the Syndic
   The  salt-syndic  daemon is a separate process that needs to be started
   in addition to the salt-master  daemon  running  on  the  Syndic  node.
   Starting  the salt-syndic daemon is the same as starting the other Salt
   daemons.

   The Master node in many ways sees the  Syndic  as  an  ordinary  Minion
   node.   In  particular,  the  Master  will  need to accept the Syndic's
   Minion key as it would for any other Minion.

   On the Syndic node:

      # salt-syndic
      or
      # service salt-syndic start

   On the Master node:

      # salt-key -a my_syndic

   The Master node will now be able to control the Minion nodes  connected
   to the Syndic.  Only the Syndic key will be listed in the Master node's
   key registry but this also means that key activity between the Syndic's
   Minions and the Syndic does not encumber the Master node.  In this way,
   the Syndic's key on the Master node can be thought of as a  placeholder
   for  the keys of all the Minion and Syndic nodes beneath it, giving the
   Master node a clear, high level structural view on the Salt cluster.

   On the Master node:

      # salt-key -L
      Accepted Keys:
      my_syndic
      Denied Keys:
      Unaccepted Keys:
      Rejected Keys:

      # salt '*' test.ping
      minion_1:
          True
      minion_2:
          True
      minion_4:
          True
      minion_3:
          True

   Topology
   A Master node (a node which is itself not a Syndic  to  another  higher
   level  Master  node)  must  run  a  salt-master daemon and optionally a
   salt-minion daemon.

   A  Syndic  node  must  run  salt-syndic  and  salt-master  daemons  and
   optionally a salt-minion daemon.

   A Minion node must run a salt-minion daemon.

   When  a salt-master daemon issues a command, it will be received by the
   Syndic and Minion nodes directly connected to it.  A Minion  node  will
   process  the command in the way it ordinarily would.  On a Syndic node,
   the salt-syndic daemon will relay the command to the salt-master daemon
   running on the Syndic node, which then propagates the command to to the
   Minions and Syndics connected to it.

   When events and job return data are generated by  salt-minion  daemons,
   they  are  aggregated  by the salt-master daemon they are connected to,
   which  salt-master  daemon  then  relays  the  data  back  through  its
   salt-syndic  daemon  until  the  data reaches the Master or Syndic node
   that issued the command.

   Syndic wait
   NOTE:
      To reduce the amount of time the CLI waits for Minions  to  respond,
      install  a Minion on the Syndic or tune the value of the syndic_wait
      configuration.

   While it is possible to run a Syndic without a Minion installed on  the
   same  system,  it is recommended, for a faster CLI response time, to do
   so.  Without a Minion installed on the Syndic node, the  timeout  value
   of  syndic_wait  increases  significantly  -  about  three-fold. With a
   Minion installed on the Syndic, the CLI timeout resides  at  the  value
   defined in syndic_wait.

   NOTE:
      If  you  have a very large infrastructure or many layers of Syndics,
      you may find that the CLI doesn't wait long enough for  the  Syndics
      to  return their events.  If you think this is the case, you can set
      the syndic_wait value in the Master configs on the Master or  Syndic
      nodes from which commands are executed.  The default value is 5, and
      should work for the majority of deployments.

   In order for a Master or Syndic node to return information from Minions
   that  are  below  their  Syndics, the CLI requires a short wait time in
   order to allow the Syndics to gather responses from their Minions. This
   value  is defined in the syndic_wait config option and has a default of
   five seconds.

   Syndic config options
   These are the options that can be used  to  configure  a  Syndic  node.
   Note that other than id, Syndic config options are placed in the Master
   config on the Syndic node.

      * id: Syndic id (shared by the salt-syndic daemon with  a  potential
        salt-minion daemon on the same system)

      * syndic_master: Master node IP address or hostname

      * syndic_master_port: Master node ret_port

      * syndic_log_file: path to the logfile (absolute or not)

      * syndic_pidfile: path to the pidfile (absolute or not)

      * syndic_wait: time in seconds to wait on returns from this syndic

   Using Salt at scale
   The  focus  of this tutorial will be building a Salt infrastructure for
   handling large numbers of minions. This will include tuning,  topology,
   and best practices.

   For how to install the Salt Master please go here: Installing saltstack

   NOTE:
      This  tutorial  is  intended for large installations, although these
      same settings won't hurt, it may not  be  worth  the  complexity  to
      smaller installations.

      When  used  with  minions,  the  term  'many'  refers  to at least a
      thousand and 'a few' always means 500.

      For simplicity reasons, this tutorial will default to  the  standard
      ports used by Salt.

   The Master
   The most common problems on the Salt Master are:

   1. too many minions authing at once

   2. too many minions re-authing at once

   3. too many minions re-connecting at once

   4. too many minions returning at once

   5. too few resources (CPU/HDD)

   The  first  three are all "thundering herd" problems. To mitigate these
   issues we must configure the minions to back-off appropriately when the
   Master is under heavy load.

   The  fourth  is  caused  by  masters  with little hardware resources in
   combination with a possible bug in ZeroMQ.  At  least  that's  what  it
   looks like till today (Issue 118651, Issue 5948, Mail thread)

   To  fully  understand  each problem, it is important to understand, how
   Salt works.

   Very briefly, the Salt Master offers two services to the minions.

   * a job publisher on port 4505

   * an open port 4506 to receive the minions returns

   All minions are always connected to the publisher on port 4505 and only
   connect  to  the open return port 4506 if necessary. On an idle Master,
   there will only be connections on port 4505.

   Too many minions authing
   When the Minion service is first started up, it  will  connect  to  its
   Master's  publisher  on  port  4505. If too many minions are started at
   once, this can cause a "thundering herd".  This can be avoided  by  not
   starting too many minions at once.

   The  connection itself usually isn't the culprit, the more likely cause
   of master-side issues is the authentication that  the  Minion  must  do
   with the Master. If the Master is too heavily loaded to handle the auth
   request  it  will  time   it   out.   The   Minion   will   then   wait
   acceptance_wait_time  to retry. If acceptance_wait_time_max is set then
   the Minion will increase its wait time by the acceptance_wait_time each
   subsequent retry until reaching acceptance_wait_time_max.

   Too many minions re-authing
   This  is  most  likely  to  happen  in  the  testing  phase  of  a Salt
   deployment, when all Minion keys have already been  accepted,  but  the
   framework  is being tested and parameters are frequently changed in the
   Salt Master's configuration file(s).

   The Salt Master generates a new AES key to encrypt its publications  at
   certain events such as a Master restart or the removal of a Minion key.
   If you are encountering this problem of  too  many  minions  re-authing
   against  the  Master, you will need to recalibrate your setup to reduce
   the rate of  events  like  a  Master  restart  or  Minion  key  removal
   (salt-key -d).

   When the Master generates a new AES key, the minions aren't notified of
   this but will discover it on the next pub job they  receive.  When  the
   Minion  receives such a job it will then re-auth with the Master. Since
   Salt does minion-side filtering this means that all  the  minions  will
   re-auth  on  the next command published on the master-- causing another
   "thundering herd". This can be avoided by setting the

      random_reauth_delay: 60

   in the minions configuration file to a higher  value  and  stagger  the
   amount  of  re-auth  attempts.  Increasing  this  value  will of course
   increase the time it takes until all minions  are  reachable  via  Salt
   commands.

   Too many minions re-connecting
   By  default  the  zmq socket will re-connect every 100ms which for some
   larger installations may be too quick. This will  control  how  quickly
   the TCP session is re-established, but has no bearing on the auth load.

   To  tune the minions sockets reconnect attempts, there are a few values
   in the sample configuration file (default values)

      recon_default: 1000
      recon_max: 5000
      recon_randomize: True

   * recon_default: the default value the socket should  use,  i.e.  1000.
     This value is in milliseconds. (1000ms = 1 second)

   * recon_max: the max value that the socket should use as a delay before
     trying to reconnect This  value  is  in  milliseconds.  (5000ms  =  5
     seconds)

   * recon_randomize:  enables  randomization  between  recon_default  and
     recon_max

   To tune this values to an existing environment, a few decision have  to
   be made.

   1. How  long  can  one  wait,  before  the minions should be online and
      reachable via Salt?

   2. How many reconnects can the Master handle without a syn flood?

   These questions can not be answered generally. Their answers depend  on
   the hardware and the administrators requirements.

   Here  is  an  example  scenario  with  the  goal,  to  have all minions
   reconnect within a 60  second  time-frame  on  a  Salt  Master  service
   restart.

      recon_default: 1000
      recon_max: 59000
      recon_randomize: True

   Each   Minion   will   have   a   randomized  reconnect  value  between
   'recon_default' and 'recon_default + recon_max', which in this  example
   means  between  1000ms  and  60000ms (or between 1 and 60 seconds). The
   generated random-value will be doubled after each attempt to  reconnect
   (ZeroMQ default behavior).

   Lets say the generated random value is 11 seconds (or 11000ms).

      reconnect 1: wait 11 seconds
      reconnect 2: wait 22 seconds
      reconnect 3: wait 33 seconds
      reconnect 4: wait 44 seconds
      reconnect 5: wait 55 seconds
      reconnect 6: wait time is bigger than 60 seconds (recon_default + recon_max)
      reconnect 7: wait 11 seconds
      reconnect 8: wait 22 seconds
      reconnect 9: wait 33 seconds
      reconnect x: etc.

   With a thousand minions this will mean

      1000/60 = ~16

   round  about  16  connection  attempts a second. These values should be
   altered to values that match your environment.  Keep  in  mind  though,
   that  it  may  grow  over  time  and  that more minions might raise the
   problem again.

   Too many minions returning at once
   This can also happen during the  testing  phase,  if  all  minions  are
   addressed at once with

      $ salt * disk.usage

   it  may  cause  thousands of minions trying to return their data to the
   Salt Master open port 4506. Also causing a flood of  syn-flood  if  the
   Master can't handle that many returns at once.

   This can be easily avoided with Salt's batch mode:

      $ salt * disk.usage -b 50

   This  will  only  address  50 minions at once while looping through all
   addressed minions.

   Too few resources
   The masters resources always have to match the environment. There is no
   way  to  give good advise without knowing the environment the Master is
   supposed to run  in.   But  here  are  some  general  tuning  tips  for
   different situations:

   The Master is CPU bound
   Salt  uses  RSA-Key-Pairs on the masters and minions end. Both generate
   4096 bit key-pairs on first start. While the key-size for the Master is
   currently  not configurable, the minions keysize can be configured with
   different key-sizes. For example with a 2048 bit key:

      keysize: 2048

   With thousands of decryptions, the amount of time that can be saved  on
   the  masters  end should not be neglected. See here for reference: Pull
   Request 9235 how much influence the key-size can have.

   Downsizing the Salt Master's key is not  that  important,  because  the
   minions do not encrypt as many messages as the Master does.

   In  installations  with  large  or  with  complex  pillar  files, it is
   possible for the master to exhibit poor  performance  as  a  result  of
   having  to  render  many pillar files at once. This exhibit itself in a
   number of ways, both as high load on the master and  on  minions  which
   block on waiting for their pillar to be delivered to them.

   To  reduce  pillar  rendering times, it is possible to cache pillars on
   the master. To do this, see the set  of  master  configuration  options
   which are prefixed with pillar_cache.

   NOTE:
      Caching pillars on the master may introduce security considerations.
      Be certain to read caveats outlined in the master configuration file
      to  understand  how  pillar caching may affect a master's ability to
      protect sensitive data!

   The Master is disk IO bound
   By default, the Master saves every Minion's return for every job in its
   job-cache.  The  cache  can  then  be used later, to lookup results for
   previous jobs. The default directory for this is:

      cachedir: /var/cache/salt

   and then in the /proc directory.

   Each job return for every Minion is saved in a single file.  Over  time
   this  directory  can  grow  quite  large,  depending  on  the number of
   published jobs. The amount of files and directories will scale with the
   number of jobs published and the retention time defined by

      keep_jobs: 24

      250 jobs/day * 2000 minions returns = 500,000 files a day

   If no job history is needed, the job cache can be disabled:

      job_cache: False

   If the job cache is necessary there are (currently) 2 options:

   * ext_job_cache:  this  will  have  the minions store their return data
     directly into a returner (not sent through the Master)

   * master_job_cache (New in 2014.7.0): this will make the  Master  store
     the  job  data  using  a  returner (instead of the local job cache on
     disk).

   If a master has many accepted keys, it may take a long time to  publish
   a  job because the master much first determine the matching minions and
   deliver that information back to the waiting client before the job  can
   be published.

   To mitigate this, a key cache may be enabled. This will reduce the load
   on the master to a single file open instead of  thousands  or  tens  of
   thousands.

   This  cache is updated by the maintanence process, however, which means
   that minions with keys that are accepted may not  be  targeted  by  the
   master for up to sixty seconds by default.

   To  enable  the  master key cache, set key_cache: 'sched' in the master
   configuration file.

   Multi Master Tutorial
   As of Salt 0.16.0, the ability to connect minions to  multiple  masters
   has  been made available. The multi-master system allows for redundancy
   of Salt masters and facilitates multiple points of communication out to
   minions.  When using a multi-master setup, all masters are running hot,
   and any active master can be used to send commands out to the minions.

   NOTE:
      If you need failover capabilities with multiple  masters,  there  is
      also  a  MultiMaster-PKI  setup  available,  that  uses  a different
      topology MultiMaster-PKI with Failover Tutorial

   In 0.16.0, the masters do not share any information, keys  need  to  be
   accepted  on  both masters, and shared files need to be shared manually
   or use tools like  the  git  fileserver  backend  to  ensure  that  the
   file_roots are kept consistent.

   Summary of Steps
   1. Create a redundant master server

   2. Copy primary master key to redundant master

   3. Start redundant master

   4. Configure minions to connect to redundant master

   5. Restart minions

   6. Accept keys on redundant master

   Prepping a Redundant Master
   The  first  task  is  to prepare the redundant master. If the redundant
   master is already running, stop it. There is only one requirement  when
   preparing  a  redundant  master,  which  is that masters share the same
   private  key.  When  the  first  master  was  created,   the   master's
   identifying  key pair was generated and placed in the master's pki_dir.
   The default location of the master's key pair is /etc/salt/pki/master/.
   Take  the  private key, master.pem, and copy it to the same location on
   the redundant  master.  Do  the  same  for  the  master's  public  key,
   master.pub. Assuming that no minions have yet been connected to the new
   redundant master, it is  safe  to  delete  any  existing  key  in  this
   location and replace it.

   NOTE:
      There  is  no  logical limit to the number of redundant masters that
      can be used.

   Once the new key is in  place,  the  redundant  master  can  be  safely
   started.

   Configure Minions
   Since minions need to be master-aware, the new master needs to be added
   to the minion configurations. Simply update the  minion  configurations
   to list all connected masters:

      master:
        - saltmaster1.example.com
        - saltmaster2.example.com

   Now the minion can be safely restarted.

   NOTE:
      If  the  ipc_mode for the minion is set to TCP (default in Windows),
      then each minion in the multi-minion setup (one  per  master)  needs
      its own tcp_pub_port and tcp_pull_port.

      If  these  settings  are  left as the default 4510/4511, each minion
      object will receive a port 2 higher  than  the  previous.  Thus  the
      first  minion will get 4510/4511, the second will get 4512/4513, and
      so on. If these port decisions are unacceptable, you must  configure
      tcp_pub_port  and tcp_pull_port with lists of ports for each master.
      The length of these lists should match the number  of  masters,  and
      there should not be overlap in the lists.

   Now the minions will check into the original master and also check into
   the new redundant master. Both masters are first-class and have  rights
   to the minions.

   NOTE:
      Minions  can  automatically  detect  failed  masters  and attempt to
      reconnect  to  reconnect   to   them   quickly.   To   enable   this
      functionality,  set  master_alive_interval  in the minion config and
      specify a number of seconds  to  poll  the  masters  for  connection
      status.

      If  this  option  is not set, minions will still reconnect to failed
      masters but the first command sent after a master comes back up  may
      be lost while the minion authenticates.

   Sharing Files Between Masters
   Salt  does  not  automatically  share files between multiple masters. A
   number of files should be shared or sharing of these  files  should  be
   strongly considered.

   Minion Keys
   Minion  keys  can  be  accepted  the  normal way using salt-key on both
   masters.  Keys accepted, deleted, or rejected on one master will NOT be
   automatically managed on redundant masters; this needs to be taken care
   of   by   running   salt-key   on   both   masters   or   sharing   the
   /etc/salt/pki/master/{minions,minions_pre,minions_rejected} directories
   between masters.

   NOTE:
      While sharing the /etc/salt/pki/master directory will  work,  it  is
      strongly  discouraged,  since  allowing access to the master.pem key
      outside of Salt creates a SERIOUS security risk.

   File_Roots
   The file_roots contents should  be  kept  consistent  between  masters.
   Otherwise  state  runs  will  not always be consistent on minions since
   instructions managed by one master will not agree with other masters.

   The recommended way to sync these is to use a fileserver  backend  like
   gitfs or to keep these files on shared storage.

   IMPORTANT:
      If  using  gitfs/git_pillar with the cachedir shared between masters
      using GlusterFS, nfs, or another network filesystem, and the masters
      are  running  Salt 2015.5.9 or later, it is strongly recommended not
      to turn off  gitfs_global_lock/git_pillar_global_lock  as  doing  so
      will  cause  lock  files  to  be  removed  if they were created by a
      different master.

   Pillar_Roots
   Pillar roots should be given the same considerations as file_roots.

   Master Configurations
   While reasons may exist to maintain separate master configurations,  it
   is wise to remember that each master maintains independent control over
   minions.  Therefore, access controls should be in sync between  masters
   unless a valid reason otherwise exists to keep them inconsistent.

   These access control options include but are not limited to:

   * external_auth

   * publisher_acl

   * peer

   * peer_run

   Multi-Master-PKI Tutorial With Failover
   This  tutorial  will  explain,  how  to  run a salt-environment where a
   single minion can have multiple masters and fail-over between  them  if
   its current master fails.

   The individual steps are

   * setup the master(s) to sign its auth-replies

   * setup minion(s) to verify master-public-keys

   * enable multiple masters on minion(s)

   * enable master-check on  minion(s)
        Please  note,  that  it  is  advised to have good knowledge of the
        salt- authentication and communication-process to understand  this
        tutorial.   All  of  the settings described here, go on top of the
        default authentication/communication process.

   Motivation
   The default behaviour of a salt-minion is to connect to  a  master  and
   accept  the masters public key. With each publication, the master sends
   his public-key for the minion to check  and  if  this  public-key  ever
   changes,  the  minion complains and exits. Practically this means, that
   there can only be a single master at any given time.

   Would it not be much nicer, if the minion  could  have  any  number  of
   masters  (1:n)  and  jump to the next master if its current master died
   because of a network or hardware failure?

   NOTE:
      There is also a MultiMaster-Tutorial with a different  approach  and
      topology  than  this  one, that might also suite your needs or might
      even be better suited Multi-Master Tutorial

   It is also desirable, to add some sort  of  authenticity-check  to  the
   very  first  public  key  a  minion receives from a master. Currently a
   minions takes the first masters public key for granted.

   The Goal
   Setup the master to sign the public key it sends  to  the  minions  and
   enable the minions to verify this signature for authenticity.

   Prepping the master to sign its public key
   For  signing  to  work,  both  master  and minion must have the signing
   and/or verification settings enabled. If the master  signs  the  public
   key  but  the  minion  does not verify it, the minion will complain and
   exit. The same happens, when the master does not sign  but  the  minion
   tries to verify.

   The easiest way to have the master sign its public key is to set

      master_sign_pubkey: True

   After restarting the salt-master service, the master will automatically
   generate a new key-pair

      master_sign.pem
      master_sign.pub

   A custom name can be set for the signing key-pair by setting

      master_sign_key_name: <name_without_suffix>

   The master will then generate that key-pair upon restart and use it for
   creating the public keys signature attached to the auth-reply.

   The  computation  is  done  for every auth-request of a minion. If many
   minions    auth    very    often,    it    is    advised     to     use
   conf_master:master_pubkey_signature                                 and
   conf_master:master_use_pubkey_signature settings described below.

   If multiple masters are in use and should sign their auth-replies,  the
   signing  key-pair  master_sign.*  has  to  be  copied  to  each master.
   Otherwise a  minion  will  fail  to  verify  the  masters  public  when
   connecting to a different master than it did initially. That is because
   the  public  keys  signature  was  created  with  a  different  signing
   key-pair.

   Prepping the minion to verify received public keys
   The  minion  must have the public key (and only that one!) available to
   be able to verify a signature it receives. That public key (defaults to
   master_sign.pub)  must  be  copied  from  the  master  to  the  minions
   pki-directory.

      /etc/salt/pki/minion/master_sign.pub

      DO NOT COPY THE master_sign.pem FILE. IT MUST STAY ON THE MASTER AND
      ONLY THERE!

   When that is  done,  enable  the  signature  checking  in  the  minions
   configuration

      verify_master_pubkey_sign: True

   and  restart the minion. For the first try, the minion should be run in
   manual debug mode.

      salt-minion -l debug

   Upon connecting to the master, the following lines should appear on the
   output:

      [DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
      [DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
      [DEBUG   ] salt.crypt.verify_signature: Loading public key
      [DEBUG   ] salt.crypt.verify_signature: Verifying signature
      [DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub
      [INFO    ] Received signed and verified master pubkey from master 172.16.0.10
      [DEBUG   ] Decrypting the current master AES key

   If  the  signature verification fails, something went wrong and it will
   look like this

      [DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
      [DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
      [DEBUG   ] salt.crypt.verify_signature: Loading public key
      [DEBUG   ] salt.crypt.verify_signature: Verifying signature
      [DEBUG   ] Failed to verify signature of public key
      [CRITICAL] The Salt Master server's public key did not authenticate!

   In a case like this, it should be checked, that the verification pubkey
   (master_sign.pub) on the minion is the same as the one on the master.

   Once  the  verification  is  successful,  the  minion can be started in
   daemon mode again.

   For the paranoid among us, its also possible to verify the  publication
   whenever  it  is  received  from  the master. That is, for every single
   auth-attempt which can be quite frequent. For example just the start of
   the  minion  will force the signature to be checked 6 times for various
   things like auth, mine, highstate, etc.

   If that is desired, enable the setting

      always_verify_signature: True

   Multiple Masters For A Minion
   Configuring multiple masters on a minion  is  done  by  specifying  two
   settings:

   * a list of masters addresses

   * what type of master is defined

      master:
          - 172.16.0.10
          - 172.16.0.11
          - 172.16.0.12

      master_type: failover

   This tells the minion that all the master above are available for it to
   connect to. When started with  this  configuration,  it  will  try  the
   master in the order they are defined. To randomize that order, set

      master_shuffle: True

   The  master-list  will  then  be  shuffled  before the first connection
   attempt.

   The first master that accepts the minion, is used by the minion. If the
   master  does  not  yet know the minion, that counts as accepted and the
   minion stays on that master.

   For the minion to be able to detect  if  its  still  connected  to  its
   current master enable the check for it

      master_alive_interval: <seconds>

   If  the loss of the connection is detected, the minion will temporarily
   remove the failed master from the list and try one of the other masters
   defined (again shuffled if that is enabled).

   Testing the setup
   At least two running masters are needed to test the failover setup.

   Both  masters should be running and the minion should be running on the
   command line in debug mode

      salt-minion -l debug

   The minion will connect to the first master from its master list

      [DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
      [DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
      [DEBUG   ] salt.crypt.verify_signature: Loading public key
      [DEBUG   ] salt.crypt.verify_signature: Verifying signature
      [DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub
      [INFO    ] Received signed and verified master pubkey from master 172.16.0.10
      [DEBUG   ] Decrypting the current master AES key

   A test.ping on the master the minion is currently connected  to  should
   be run to test connectivity.

   If  successful,  that  master  should  be  turned  off. A firewall-rule
   denying the minions packets will also do the trick.

   Depending  on  the  configured  conf_minion:master_alive_interval,  the
   minion  will  notice  the  loss  of  the  connection  and log it to its
   logfile.

      [INFO    ] Connection to master 172.16.0.10 lost
      [INFO    ] Trying to tune in to next master from master-list

   The minion will then remove the current master from the  list  and  try
   connecting to the next master

      [INFO    ] Removing possibly failed master 172.16.0.10 from list of masters
      [WARNING ] Master ip address changed from 172.16.0.10 to 172.16.0.11
      [DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.11

   If  everything is configured correctly, the new masters public key will
   be verified successfully

      [DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
      [DEBUG   ] salt.crypt.verify_signature: Loading public key
      [DEBUG   ] salt.crypt.verify_signature: Verifying signature
      [DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub

   the authentication with the new master is successful

      [INFO    ] Received signed and verified master pubkey from master 172.16.0.11
      [DEBUG   ] Decrypting the current master AES key
      [DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
      [INFO    ] Authentication with master successful!

   and the minion can be pinged again from its new master.

   Performance Tuning
   With the setup described above, the master  computes  a  signature  for
   every   auth-request   of   a   minion.  With  many  minions  and  many
   auth-requests, that can chew up quite a bit of CPU-Power.

   To avoid that, the master  can  use  a  pre-created  signature  of  its
   public-key.   The  signature  is saved as a base64 encoded string which
   the master reads once when starting and attaches only  that  string  to
   auth-replies.

   Enabling  this  also  gives paranoid users the possibility, to have the
   signing key-pair on a different system than the actual salt-master  and
   create  the public keys signature there. Probably on a system with more
   restrictive firewall rules, without internet access, less users, etc.

   That signature can be created with

      salt-key --gen-signature

   This will create a default signature file in the master pki-directory

      /etc/salt/pki/master/master_pubkey_signature

   It is a simple text-file with the binary-signature converted to base64.

   If no signing-pair is present yet, this will  auto-create  the  signing
   pair and the signature file in one call

      salt-key --gen-signature --auto-create

   Telling the master to use the pre-created signature is done with

      master_use_pubkey_signature: True

   That  requires  the file 'master_pubkey_signature' to be present in the
   masters pki-directory with the correct signature.

   If the signature file is named differently, its name can be set with

      master_pubkey_signature: <filename>

   With many masters and many public-keys (default  and  signing),  it  is
   advised  to use the salt-masters hostname for the signature-files name.
   Signatures can be easily confused  because  they  do  not  provide  any
   information about the key the signature was created from.

   Verifying that everything works is done the same way as above.

   How the signing and verification works
   The default key-pair of the salt-master is

      /etc/salt/pki/master/master.pem
      /etc/salt/pki/master/master.pub

   To  be  able  to  create  a  signature  of  a  message  (in this case a
   public-key), another key-pair has to be added to the setup. Its default
   name is:

      master_sign.pem
      master_sign.pub

   The  combination  of  the master.* and master_sign.* key-pairs give the
   possibility of generating signatures. The signature of a given  message
   is   unique   and   can   be   verified,   if  the  public-key  of  the
   signing-key-pair is available to the recipient (the minion).

   The signature of the masters public-key in master.pub is computed with

      master_sign.pem
      master.pub
      M2Crypto.EVP.sign_update()

   This results in a binary signature which is  converted  to  base64  and
   attached to the auth-reply send to the minion.

   With the signing-pairs public-key available to the minion, the attached
   signature can be verified with

      master_sign.pub
      master.pub
      M2Cryptos EVP.verify_update().

   When running multiple masters, either the signing key-pair  has  to  be
   present  on  all  of  them,  or  the  master_pubkey_signature has to be
   pre-computed for  each  master  individually  (because  they  all  have
   different public-keys).
      DO NOT PUT THE SAME master.pub ON ALL MASTERS FOR EASE OF USE.

WINDOWS

   This  section  contains  details  on  the  Windows Package Manager, and
   specific information you need to use Salt on Windows.

   Windows Software Repository
   NOTE:
      In 2015.8.0 and later, the  Windows  Software  Repository  cache  is
      compiled  on the Salt Minion, which enables pillar, grains and other
      things to be available during compilation time. To support this  new
      functionality,   a   next-generation  (ng)  package  repository  was
      created. See See the Changes in Version 2015.8.0 for details.

   The SaltStack Windows Software Repository provides  a  package  manager
   and  software  repository similar to what is provided by yum and apt on
   Linux. This repository enables the installation of software  using  the
   installers on remote Windows systems.

   In  many  senses, the operation is similar to that of the other package
   managers salt is aware of:

   * the pkg.installed and similar states work on Windows.

   * the pkg.install and similar module functions work on Windows.

   High level differences to yum and apt are:

   * The repository metadata (SLS files) is hosted through either salt  or
     git.

   * Packages  can  be  downloaded  from within the salt repository, a git
     repository or from http(s) or ftp urls.

   * No dependencies are managed. Dependencies between packages  needs  to
     be managed manually.

   Requirements:

   * GitPython  0.3 or later, or pygit2 0.20.3 with libgit 0.20.0 or later
     installed on your Salt master. The Windows  package  definitions  are
     downloaded and updated using Git.

   Configuration
   Populate the Repository
   The  SLS  files used to install Windows packages are not distributed by
   default  with  Salt.  Run  the  following  command  to  initialize  the
   repository on your Salt master:

      salt-run winrepo.update_git_repos

   Sync Repo to Windows Minions
   Run  pkg.refresh_db  on each of your Windows minions to synchronize the
   package repository.

      salt -G 'os:windows' pkg.refresh_db

   Install Windows Software
   After completing the configuration  steps,  you  are  ready  to  manage
   software on your Windows minions.

   Show Installed Packages
      salt -G 'os:windows' pkg.list_pkgs

   Install a Package
   You  can  query  the  available version of a package using the Salt pkg
   module.

      salt winminion pkg.available_version firefox

      {'firefox': {'15.0.1': 'Mozilla Firefox 15.0.1 (x86 en-US)',
                   '16.0.2': 'Mozilla Firefox 16.0.2 (x86 en-US)',
                   '17.0.1': 'Mozilla Firefox 17.0.1 (x86 en-US)'}}

   As you can see, there are  three  versions  of  Firefox  available  for
   installation.   You  can  refer  a  software package by its name or its
   full_name surround by single quotes.

      salt winminion pkg.install 'firefox'

   The above line will install the latest version of Firefox.

      salt winminion pkg.install 'firefox' version=16.0.2

   The above line will install version 16.0.2 of Firefox.

   If a different version of the package is already installed it  will  be
   replaced  with  the  version in the winrepo (only if the package itself
   supports live updating).

   You can also specify the full name:

      salt winminion pkg.install 'Mozilla Firefox 17.0.1 (x86 en-US)'

   Uninstall Windows Software
   Uninstall software using the pkg module:

      salt winminion pkg.remove firefox
      salt winminion pkg.purge firefox

   NOTE:
      pkg.purge just executes pkg.remove on Windows. At some point in  the
      future  pkg.purge may direct the installer to remove all configs and
      settings for software packages that support that option.

   Repository Location
   Salt maintains a repository of SLS files to install a large  number  of
   Windows 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
   and /srv/salt/win/repo.

   This  location  can be changed in the master config file by setting the
   winrepo_dir_ng and winrepo_dir options.

   Maintaining Windows Repo Definitions in Git Repositories
   Windows software package definitions can be hosted in one or  more  Git
   repositories.   The  default  repositories  are  hosted  on  GitHub  by
   SaltStack. These include software definition  files  for  various  open
   source  software  projects.   These  software definition files are .sls
   files.  There  are   two   default   repositories:   salt-winrepo   and
   salt-winrepo-ng.  salt-winrepo  contains  software definition files for
   older minions (older than  2015.8.0).   salt-winrepo-ng  is  for  newer
   minions (2015.8.0 and newer).

   Each  software  definition file contains all the information salt needs
   to install that  software  on  a  minion  including  the  HTTP  or  FTP
   locations  of  the  installer files, required command-line switches for
   silent install, etc. Anyone is welcome to send a pull request  to  this
   repo  to  add  new  package definitions. The repos can be browsed here:
   salt-winrepo salt-winrepo-ng

   NOTE:
      The newer software definition  files  are  run  through  the  salt's
      parser which allows for the use of jinja.

   Configure  which  git  repositories  the  master can search for package
   definitions  by  modifying  or  extending   the   winrepo_remotes   and
   winrepo_remotes_ng options.

   IMPORTANT:
      winrepo_remotes  was  called  win_gitrepos  in Salt versions earlier
      than 2015.8.0

   Package definitions are pulled  down  from  the  online  repository  by
   running  the  winrepo.update_git_repos  runner.  This command is run on
   the master:

      salt-run winrepo.update_git_repos

   This will pull down the software definition  files  for  older  minions
   (salt-winrepo)  and  new  minions (salt-winrepo-ng). They are stored in
   the       file_roots       under       win/repo/salt-winrepo        and
   win/repo-ng/salt-winrepo-ng respectively.

   IMPORTANT:
      If  you  have  customized  software  definition  files  that  aren't
      maintained in a repository, those should be  stored  under  win/repo
      for  older minions and win/repo-ng for newer minions. The reason for
      this   is   that   the   contents   of   win/repo/salt-winrepo   and
      win/repo-ng/salt-winrepo-ng  are  wiped  out  every  time  you run a
      winrepo.update_git_repos.

      Additionally, when you run winrepo.genrepo  and  pkg.refresh_db  the
      entire  contents  under  win/repo  and  win/repo-ng,  to include all
      subdirectories, are used to create the msgpack file.

   The next step (if you have older minions) is to create the msgpack file
   for  the  repo (winrepo.p). This is done by running the winrepo.genrepo
   runner. This is also run on the master:

      salt-run winrepo.genrepo

   NOTE:
      If you have only 2015.8.0 and newer minions, you no longer  need  to
      run salt-run winrepo.genrepo on the master.

   Finally,  you  need  to  refresh  the  minion  database  by running the
   pkg.refresh_db command. This is run on the master as well:

      salt '*' pkg.refresh_db

   On older minions (older than 2015.8.0) this  will  copy  the  winrepo.p
   file  down  to  the  minion. On newer minions (2015.8.0 and newer) this
   will copy all the software definition files (.sls) down to  the  minion
   and  then  create the msgpack file (winrepo.p) locally. The reason this
   is done locally is because the jinja  needs  to  be  parsed  using  the
   minion's grains.

   IMPORTANT:
      Every  time  you modify the software definition files on the master,
      either  by  running  salt-run  winrepo.update_git_repos,   modifying
      existing  files,  or  by  creating your own, you need to refresh the
      database on your minions. For  older  minions,  that  means  running
      salt-run winrepo.genrepo and then salt '*' pkg.refresh_db. For newer
      minions (2015.8.0 and newer) it is just salt '*' pkg.refresh_db.

   NOTE:
      If the winrepo.genrepo or the pkg.refresh_db fails, it is  likely  a
      problem with the jinja in one of the software definition files. This
      will cause the operations to stop. You'll need to fix the syntax  in
      order for the msgpack file to be created successfully.

   To  disable  one of the repos, set it to an empty list [] in the master
   config. For example, to disable winrepo_remotes set  the  following  in
   the master config file:

      winrepo_remotes: []

   Creating a Package Definition SLS File
   The  package  definition  file  is  a  yaml  file that contains all the
   information needed to install  a  piece  of  software  using  salt.  It
   defines  information  about  the package to include version, full name,
   flags required for the installer and uninstaller, whether or not to use
   the  windows  task  scheduler to install the package, where to find the
   installation package, etc.

   Take a look at this example for Firefox:

      firefox:
        '17.0.1':
          installer: 'salt://win/repo/firefox/English/Firefox Setup 17.0.1.exe'
          full_name: Mozilla Firefox 17.0.1 (x86 en-US)
          locale: en_US
          reboot: False
          install_flags: '-ms'
          uninstaller: '%ProgramFiles(x86)%/Mozilla Firefox/uninstall/helper.exe'
          uninstall_flags: '/S'
        '16.0.2':
          installer: 'salt://win/repo/firefox/English/Firefox Setup 16.0.2.exe'
          full_name: Mozilla Firefox 16.0.2 (x86 en-US)
          locale: en_US
          reboot: False
          install_flags: '-ms'
          uninstaller: '%ProgramFiles(x86)%/Mozilla Firefox/uninstall/helper.exe'
          uninstall_flags: '/S'
        '15.0.1':
          installer: 'salt://win/repo/firefox/English/Firefox Setup 15.0.1.exe'
          full_name: Mozilla Firefox 15.0.1 (x86 en-US)
          locale: en_US
          reboot: False
          install_flags: '-ms'
          uninstaller: '%ProgramFiles(x86)%/Mozilla Firefox/uninstall/helper.exe'
          uninstall_flags: '/S'

   Each software definition file  begins  with  a  package  name  for  the
   software.  As  in  the example above firefox. The next line is indented
   two spaces and contains the version to be defined. As  in  the  example
   above,  a software definition file can define multiple versions for the
   same piece of software. The lines following the  version  are  indented
   two  more spaces and contain all the information needed to install that
   package.

   WARNING:
      The package name and the full_name  must  be  unique  to  all  other
      packages in the software repository.

   The  version line is the version for the package to be installed. It is
   used when you need  to  install  a  specific  version  of  a  piece  of
   software.

   WARNING:
      The  version  must  be enclosed in quotes, otherwise the yaml parser
      will remove trailing zeros.

   NOTE:
      There are unique situations where previous versions are unavailable.
      Take Google Chrome for example. There is only one url provided for a
      standalone     installation     of      Google      Chrome.       (
      https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise.msi)
      When a new version is released, the  url  just  points  to  the  new
      version.  To  handle  situations  such  as these, set the version to
      latest. Salt will install the version  of  Chrome  at  the  URL  and
      report that version. Here's an example:

      chrome:
        latest:
          full_name: 'Google Chrome'
          installer: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise.msi'
          install_flags: '/qn /norestart'
          uninstaller: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise.msi'
          uninstall_flags: '/qn /norestart'
          msiexec: True
          locale: en_US
          reboot: False

   Available parameters are as follows:

   param str full_name
          The  Full  Name  for  the  software  as  shown  in "Programs and
          Features"  in  the  control  panel.  You  can  also   get   this
          information  by installing the package manually and then running
          pkg.list_pkgs.  Here's   an   example   of   the   output   from
          pkg.list_pkgs:

      salt 'test-2008' pkg.list_pkgs
      test-2008
          ----------
          7-Zip 9.20 (x64 edition):
              9.20.00.0
          Microsoft .NET Framework 4 Client Profile:
              4.0.30319,4.0.30319
          Microsoft .NET Framework 4 Extended:
              4.0.30319,4.0.30319
          Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022:
              9.0.21022
          Mozilla Firefox 17.0.1 (x86 en-US):
              17.0.1
          Mozilla Maintenance Service:
              17.0.1
          NSClient++ (x64):
              0.3.8.76
          Notepad++:
              6.4.2
          Salt Minion 0.16.0:
              0.16.0

   Notice  the  Full Name for Firefox: Mozilla Firefox 17.0.0 (x86 en-US).
   That's exactly what's  in  the  full_name  parameter  in  the  software
   definition file.

   If  any  of  the  software  insalled  on the machine matches one of the
   software definition files in  the  repository  the  full_name  will  be
   automatically  renamed to the package name. The example below shows the
   pkg.list_pkgs for a machine that already  has  Mozilla  Firefox  17.0.1
   installed.

      test-2008:
          ----------
          7zip:
              9.20.00.0
          Microsoft .NET Framework 4 Client Profile:
              4.0.30319,4.0.30319
          Microsoft .NET Framework 4 Extended:
              4.0.30319,4.0.30319
          Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022:
              9.0.21022
          Mozilla Maintenance Service:
              17.0.1
          Notepad++:
              6.4.2
          Salt Minion 0.16.0:
              0.16.0
          firefox:
              17.0.1
          nsclient:
              0.3.9.328

   IMPORTANT:
      The  version  number  and  full_name  need  to match the output from
      pkg.list_pkgs so that  the  status  can  be  verified  when  running
      highstate.

   NOTE:
      It   is  still  possible  to  successfully  install  packages  using
      pkg.install even if they don't match. This can make  troubleshooting
      difficult so be careful.

   param str installer
          The path to the .exe or .msi to use to install the package. This
          can be a path or a URL. If it is a URL or a salt path (salt://),
          the package will be cached locally and then executed. If it is a
          path to a file on disk or a file  share,  it  will  be  executed
          directly.

   param str install_flags
          Any  flags  that  need  to be passed to the installer to make it
          perform a silent install. These can often be found by adding  /?
          or  /h when running the installer from the command-line. A great
          resource for finding these silent install flags can be found  on
          the WPKG project's wiki:

   Salt  will  not  return  if  the installer is waiting for user input so
   these are important.

   param str uninstaller
          The path to the program used to uninstall this  software.   This
          can  be  the  path  to  the  same exe or msi used to install the
          software. It can also be a GUID. You can find this value in  the
          registry under the following keys:

          * Software\Microsoft\Windows\CurrentVersion\Uninstall

          * Software\Wow6432None\Microsoft\Windows\CurrentVersion\Uninstall

   param str uninstall_flags
          Any flags that need to be passed to the uninstaller to  make  it
          perform  a  silent uninstall. These can often be found by adding
          /? or /h when running the uninstaller from the  command-line.  A
          great  resource  for  finding  these silent install flags can be
          found on the WPKG project's wiki:

   Salt will not return if the uninstaller is waiting for  user  input  so
   these are important.

   Here are some examples of installer and uninstaller settings:

      7zip:
        '9.20.00.0':
          installer: salt://win/repo/7zip/7z920-x64.msi
          full_name: 7-Zip 9.20 (x64 edition)
          reboot: False
          install_flags: '/qn /norestart'
          msiexec: True
          uninstaller: '{23170F69-40C1-2702-0920-000001000000}'
          uninstall_flags: '/qn /norestart'

   Alternatively the uninstaller can also simply repeat the URL of the msi
   file.

      7zip:
        '9.20.00.0':
          installer: salt://win/repo/7zip/7z920-x64.msi
          full_name: 7-Zip 9.20 (x64 edition)
          reboot: False
          install_flags: '/qn /norestart'
          msiexec: True
          uninstaller: salt://win/repo/7zip/7z920-x64.msi
          uninstall_flags: '/qn /norestart'

   param bool msiexec
          This tells salt to use msiexec /i to  install  the  package  and
          msiexec /x to uninstall. This is for .msi installations.

   param bool allusers
          This  parameter  is  specific  to  .msi  installations. It tells
          msiexec to install the software for all users.  The  default  is
          True.

   param bool cache_dir
          If  true,  the entire directory where the installer resides will
          be recursively cached. This is useful for installers that depend
          on other files in the same directory for installation.

   NOTE:
      Only applies to salt: installer URLs.

   Here's an example for a software package that has dependent files:

      sqlexpress:
        '12.0.2000.8':
          installer: 'salt://win/repo/sqlexpress/setup.exe'
          full_name: Microsoft SQL Server 2014 Setup (English)
          reboot: False
          install_flags: '/ACTION=install /IACCEPTSQLSERVERLICENSETERMS /Q'
          cache_dir: True

   param bool use_scheduler
          If  true,  windows  will  use  the  task  scheduler  to  run the
          installation. This is useful for running the  salt  installation
          itself  as  the installation process kills any currently running
          instances of salt.

   param str source_hash
          This tells salt to compare a hash sum of the installer

   to the provided hash sum before execution. The value can  be  formatted
   as hash_algorithm=hash_sum, or it can be a URI to a file containing the
   hash sum.   For  a  list  of  supported  algorithms,  see  the  hashlib
   documentation.

   Here's an example of source_hash usage:

      messageanalyzer:
        '4.0.7551.0':
          full_name: 'Microsoft Message Analyzer'
          installer: 'salt://win/repo/messageanalyzer/MessageAnalyzer64.msi'
          install_flags: '/quiet /norestart'
          uninstaller: '{1CC02C23-8FCD-487E-860C-311EC0A0C933}'
          uninstall_flags: '/quiet /norestart'
          msiexec: True
          source_hash: 'sha1=62875ff451f13b10a8ff988f2943e76a4735d3d4'

   param bool reboot
          Not implemented

   param str local
          Not implemented

   Examples can be found at https://github.com/saltstack/salt-winrepo-ng

   Managing Windows Software on a Standalone Windows Minion
   The  Windows  Package  Repository  functions  similar  in  a standalone
   environment, with a few differences in the configuration.

   To replace the winrepo runner that is  used  on  the  Salt  master,  an
   execution module exists to provide the same functionality to standalone
   minions. The functions are named the same as the ones  in  the  runner,
   and  are used in the same way; the only difference is that salt-call is
   used instead of salt-run:

      salt-call winrepo.update_git_repos
      salt-call winrepo.genrepo
      salt-call pkg.refresh_db

   After executing the previous commands the repository on the  standalone
   system is ready to use.

   Custom Location for Repository SLS Files
   If  file_roots  has not been modified in the minion configuration, then
   no  additional  configuration  needs  to  be  added   to   the   minion
   configuration.  The winrepo.genrepo function from the winrepo execution
   module  will  by  default  look   for   the   filename   specified   by
   winrepo_cachefile within C:\salt\srv\salt\win\repo.

   If the file_roots parameter has been modified, then winrepo_dir must be
   modified to fall within that path, at the  proper  relative  path.  For
   example,  if  the  base environment in file_roots points to D:\foo, and
   winrepo_source_dir is salt://win/repo, then winrepo_dir must be set  to
   D:\foo\win\repo  to ensure that winrepo.genrepo puts the cachefile into
   right location.

   Config Options for Minions 2015.8.0 and Later
   The  winrepo_source_dir  config  parameter  (default:  salt://win/repo)
   controls   where  pkg.refresh_db  looks  for  the  cachefile  (default:
   winrepo.p). This means  that  the  default  location  for  the  winrepo
   cachefile  would  be salt://win/repo/winrepo.p. Both winrepo_source_dir
   and winrepo_cachefile can be adjusted to match the actual  location  of
   this file on the Salt fileserver.

   Config Options for Minions Before 2015.8.0
   If  connected  to  a  master,  the  minion will by default look for the
   winrepo cachefile (the file generated by the winrepo.genrepo runner) at
   salt://win/repo/winrepo.p.  If  the cachefile is in a different path on
   the salt fileserver, then win_repo_cachefile will need to be updated to
   reflect the proper location.

   Changes in Version 2015.8.0
   Git  repository  management  for  the  Windows  Software Repository has
   changed  in  version  2015.8.0,  and   several   master/minion   config
   parameters  have been renamed to make their naming more consistent with
   each other.

   For a list of the winrepo config options, see here  for  master  config
   options,  and  here  for  configuration  options for masterless Windows
   minions.

   On the master, the winrepo.update_git_repos runner has been updated  to
   use  either  pygit2  or  GitPython  to  checkout  the  git repositories
   containing repo data. If pygit2 or  GitPython  is  installed,  existing
   winrepo git checkouts should be removed after upgrading to 2015.8.0, to
   allow them to be checked out again by running winrepo.update_git_repos.

   If neither GitPython nor pygit2 are installed, then Salt will fall back
   to  the  pre-existing  behavior  for  winrepo.update_git_repos,  and  a
   warning will be logged in the master log.

   NOTE:
      Standalone Windows minions do not support the  new  GitPython/pygit2
      functionality,  and  will  instead  use the git.latest state to keep
      repositories up-to-date. More information on how to use the  Windows
      Software Repo on a standalone minion can be found here.

   Config Parameters Renamed
   Many  of  the  legacy  winrepo configuration parameters have changed in
   version 2015.8.0 to make the naming more consistent. The old  parameter
   names will still work, but a warning will be logged indicating that the
   old name is deprecated.

   Below are the parameters which have changed for version 2015.8.0:

   Master Config
               
               Old Name                  New Name          
               
               win_repo                  winrepo_dir       
               
               win_repo_mastercachefile  winrepo_cachefile 
               
               win_gitrepos              winrepo_remotes   
               

   NOTE:
      winrepo_cachefile is no longer used by 2015.8.0 and  later  minions,
      and  the  winrepo_dir  setting  is  replaced  by  winrepo_dir_ng for
      2015.8.0 and later minions.

   See here for detailed information on all master config options for  the
   Windows Repo.

   Minion Config
                  
                  Old Name            New Name          
                  
                  win_repo            winrepo_dir       
                  
                  win_repo_cachefile  winrepo_cachefile 
                  
                  win_gitrepos        winrepo_remotes   
                  

   See  here for detailed information on all minion config options for the
   Windows Repo.

   pygit2/GitPython Support for Maintaining Git Repos
   The  winrepo.update_git_repos  runner  (and  the  corresponding  remote
   execution  function  for  standalone minions) now makes use of the same
   underlying code used by the Git Fileserver  Backend  and  Git  External
   Pillar  to maintain and update its local clones of git repositories. If
   a compatible version of either pygit2 (0.20.3 and later)  or  GitPython
   (0.3.0 or later) is installed, then Salt will use it instead of the old
   method (which invokes the git.latest state).

   NOTE:
      If compatible versions of both pygit2 and GitPython  are  installed,
      then  Salt  will  prefer  pygit2,  to override this behavior use the
      winrepo_provider configuration parameter:

          winrepo_provider: gitpython

      The winrepo  execution  module  (discussed  above  in  the  Managing
      Windows  Software  on  a Standalone Windows Minion section) does not
      yet officially support the new pygit2/GitPython  functionality,  but
      if  either  pygit2  or  GitPython  is  installed into Salt's bundled
      Python then  it  should  work.  However,  it  should  be  considered
      experimental at this time.

   To  minimize  potential issues, it is a good idea to remove any winrepo
   git repositories that  were  checked  out  by  the  old  (pre-2015.8.0)
   winrepo  code  when  upgrading the master to 2015.8.0 or later, and run
   winrepo.update_git_repos  to  clone  them  anew  after  the  master  is
   started.

   Additional  added  features include the ability to access authenticated
   git repositories (NOTE: pygit2 only),  and  to  set  per-remote  config
   settings.  An example of this would be the following:

      winrepo_remotes:
        - https://github.com/saltstack/salt-winrepo.git
        - [email protected]:myuser/myrepo.git:
          - pubkey: /path/to/key.pub
          - privkey: /path/to/key
          - passphrase: myaw3s0m3pa$$phr4$3
        - https://github.com/myuser/privaterepo.git:
          - user: mygithubuser
          - password: CorrectHorseBatteryStaple

   NOTE:
      Per-remote  configuration  settings work in the same fashion as they
      do in gitfs,  with  global  parameters  being  overridden  by  their
      per-remote  counterparts  (for  instance, setting winrepo_passphrase
      would set a global passphrase for winrepo that would  apply  to  all
      SSH-based  remotes,  unless  overridden  by  a passphrase per-remote
      parameter).

      See here for more a more  in-depth  explanation  of  how  per-remote
      configuration works in gitfs, the same principles apply to winrepo.

   There  are  a  couple other changes in how Salt manages git repos using
   pygit2/GitPython. First of all, a clean argument has been added to  the
   winrepo.update_git_repos  runner,  which (if set to True) will tell the
   runner to dispose of directories under the winrepo_dir  which  are  not
   explicitly  configured. This prevents the need to manually remove these
   directories when a repo is removed from the config file. To clean these
   old directories, just pass clean=True, like so:

      salt-run winrepo.update_git_repos clean=True

   However,  if a mix of git and non-git Windows Repo definition files are
   being used, then this should  not  be  used,  as  it  will  remove  the
   directories containing non-git definitions.

   The  other  major  change is that collisions between repo names are now
   detected, and the winrepo.update_git_repos runner will not  proceed  if
   any are detected. Consider the following configuration:

      winrepo_remotes:
        - https://foo.com/bar/baz.git
        - https://mydomain.tld/baz.git
        - https://github.com/foobar/baz

   The  winrepo.update_git_repos  runner will refuse to update repos here,
   as all three of these repos would be checked out to the same directory.
   To  work around this, a per-remote parameter called name can be used to
   resolve these conflicts:

      winrepo_remotes:
        - https://foo.com/bar/baz.git
        - https://mydomain.tld/baz.git:
          - name: baz_junior
        - https://github.com/foobar/baz:
          - name: baz_the_third

   Troubleshooting
   Incorrect name/version
   If the package seems to install properly, but salt  reports  a  failure
   then it is likely you have a version or full_name mismatch.

   Check  the  exact  full_name  and  version  used  by  the  package. Use
   pkg.list_pkgs to check that the names and version exactly match what is
   installed.

   Changes to sls files not being picked up
   Ensure  you  have  (re)generated  the  repository cache file (for older
   minions) and then updated the repository cache on the relevant minions:

      salt-run winrepo.genrepo
      salt winminion pkg.refresh_db

   Packages management under Windows 2003
   On Windows server 2003, you need to install optional Windows  component
   "wmi  windows  installer  provider"  to  have  full  list  of installed
   packages. If  you  don't  have  this,  salt-minion  can't  report  some
   installed software.

   How Success and Failure are Reported
   The  install state/module function of the Windows package manager works
   roughly as follows:

   1. Execute pkg.list_pkgs and store the result

   2. Check if any action  needs  to  be  taken.  (i.e.  compare  required
      package and version against pkg.list_pkgs results)

   3. If so, run the installer command.

   4. Execute  pkg.list_pkgs  and compare to the result stored from before
      installation.

   5. Success/Failure/Changes will be reported based  on  the  differences
      between the original and final pkg.list_pkgs results.

   If there are any problems in using the package manager it is likely due
   to the data in your sls files not matching the difference  between  the
   pre and post pkg.list_pkgs results.

   Windows-specific Behaviour
   Salt  is  capable  of  managing Windows systems, however due to various
   differences between the operating systems, there are  some  things  you
   need to keep in mind.

   This  document  will  contain  any  quirks  that  apply  across Salt or
   generally  across  multiple  module  functions.  Any   Windows-specific
   behavior  for  particular  module  functions  will be documented in the
   module function documentation. Therefore this document should  be  read
   in conjunction with the module function documentation.

   Group parameter for files
   Salt  was  originally  written  for  managing  Unix-based  systems, and
   therefore the file module functions were designed around that  security
   model.  Rather  than  trying to shoehorn that model on to Windows, Salt
   ignores these parameters  and  makes  non-applicable  module  functions
   unavailable instead.

   One  of  the  commonly  ignored  parameters  is the group parameter for
   managing files. Under Windows, while files do have  a  'primary  group'
   property,  this  is  rarely  used.   It  generally  has  no  bearing on
   permissions unless intentionally configured and is most  commonly  used
   to provide Unix compatibility (e.g.  Services For Unix, NFS services).

   Because  of  this,  any  file module functions that typically require a
   group, do not under Windows.  Attempts  to  directly  use  file  module
   functions  that  operate  on  the group (e.g. file.chgrp) will return a
   pseudo-value and cause a log message to  appear.  No  group  parameters
   will be acted on.

   If  you  do  want to access and change the 'primary group' property and
   understand the implications, use the file.get_pgid  or  file.get_pgroup
   functions or the pgroup parameter on the file.chown module function.

   Dealing with case-insensitive but case-preserving names
   Windows  is  case-insensitive,  but however preserves the case of names
   and it is this preserved form that is returned from  system  functions.
   This  causes  some  issues  with Salt because it assumes case-sensitive
   names. These issues generally occur in  the  state  functions  and  can
   cause bizarre looking errors.

   To  avoid such issues, always pretend Windows is case-sensitive and use
   the right case for names, e.g. specify  user=Administrator  instead  of
   user=administrator.

   Follow issue 11801 for any changes to this behavior.

   Dealing with various username forms
   Salt  does  not understand the various forms that Windows usernames can
   come in, e.g. username,  mydomain\username,  [email protected]  can
   all  refer to the same user. In fact, Salt generally only considers the
   raw username value, i.e.  the  username  without  the  domain  or  host
   information.

   Using  these  alternative  forms will likely confuse Salt and cause odd
   errors to happen. Use only the raw username value in the  correct  case
   to avoid problems.

   Follow issue 11801 for any changes to this behavior.

   Specifying the None group
   Each  Windows  system  has  built-in  _None_ group. This is the default
   'primary group' for files for users not on a domain environment.

   Unfortunately, the word _None_ has special meaning in Python - it is  a
   special  value  indicating  'nothing',  similar to null or nil in other
   languages.

   To specify the None group, it must be specified in quotes, e.g.  ./salt
   '*' file.chpgrp C:\path\to\file "'None'".

   Symbolic link loops
   Under  Windows, if any symbolic link loops are detected or if there are
   too many levels of symlinks  (defaults  to  64),  an  error  is  always
   raised.

   For  some functions, this behavior is different to the behavior on Unix
   platforms. In general, avoid symlink loops on either platform.

   Modifying security properties (ACLs) on files
   There is no support in  Salt  for  modifying  ACLs,  and  therefore  no
   support   for   changing   file   permissions,  besides  modifying  the
   owner/user.

DEVELOPING SALT

   Overview
   In its most typical use,  Salt  is  a  software  application  in  which
   clients,  called  "minions"  can  be  commanded  and  controlled from a
   central command server called a "master".

   Commands are normally issued to the minions (via the master) by calling
   a client script simply called, 'salt'.

   Salt  features  a  pluggable  transport system to issue commands from a
   master to minions. The default transport is ZeroMQ.

   Salt Client
   Overview
   The salt client is run on the same  machine  as  the  Salt  Master  and
   communicates  with the salt-master to issue commands and to receive the
   results and display them to the user.

   The primary abstraction for the salt client is called 'LocalClient'.

   When LocalClient wants to publish a command to minions, it connects  to
   the master by issuing a request to the master's ReqServer (TCP: 4506)

   The  LocalClient  system  listens  to  responses  for  its  requests by
   listening to the master event bus publisher (master_event_pub.ipc).

   Salt Master
   Overview
   The salt-master daemon runs on the designated Salt master and  performs
   functions  such  as  authenticating  minions,  sending,  and  receiving
   requests from connected minions and sending and receiving requests  and
   replies to the 'salt' CLI.

   Moving Pieces
   When a Salt master starts up, a number of processes are started, all of
   which are called 'salt-master' in a process-list but have various  role
   categories.

   Among those categories are:

      * Publisher

      * EventPublisher

      * MWorker

   Publisher
   The  Publisher  process  is  responsible  for sending commands over the
   designated transport to connected minions. The Publisher  is  bound  to
   the following:

      * TCP: port 4505

      * IPC: publish_pull.ipc

   Each salt minion establishes a connection to the master Publisher.

   EventPublisher
   The  EventPublisher publishes events onto the event bus. It is bound to
   the following:

      * IPC: master_event_pull.ipc

      * IPC: master_event_pub.ipc

   MWorker
   Worker processes manage the back-end operations for the Salt Master.

   The number of workers is equivalent to the number  of  'worker_threads'
   specified in the master configuration and is always at least one.

   Workers are bound to the following:

      * IPC: workers.ipc

   ReqServer
   The  Salt  request  server  takes  requests  and  distributes  them  to
   available MWorker processes for processing. It  also  receives  replies
   back from minions.

   The ReqServer is bound to the following:

          * TCP: 4506

          * IPC: workers.ipc

   Each salt minion establishes a connection to the master ReqServer.

   Job Flow
   The  Salt  master  works by always publishing commands to all connected
   minions and the minions decide if the command  is  meant  for  them  by
   checking themselves against the command target.

   The  typical lifecycle of a salt job from the perspective of the master
   might be as follows:

   1. A command is  issued  on  the  CLI.  For  example,  'salt  my_minion
      test.ping'.

   2)  The  'salt'  command  uses LocalClient to generate a request to the
   salt master by connecting to the ReqServer on TCP:4506 and issuing  the
   job.

   3)  The  salt-master  ReqServer  sees  the  request and passes it to an
   available MWorker over workers.ipc.

   4) A worker picks up the request and handles it. First,  it  checks  to
   ensure  that  the  requested user has permissions to issue the command.
   Then, it sends the publish command to all connected  minions.  For  the
   curious, this happens in ClearFuncs.publish().

   5)  The  worker  announces  on the master event bus that it is about to
   publish a job to connected minions. This happens by placing  the  event
   on   the   master   event   bus   (master_event_pull.ipc)   where   the
   EventPublisher picks it up and distributes it to  all  connected  event
   listeners on master_event_pub.ipc.

   6)  The  message  to the minions is encrypted and sent to the Publisher
   via IPC on publish_pull.ipc.

   7) Connected minions have a TCP session established with the  Publisher
   on TCP port 4505 where they await commands. When the Publisher receives
   the job over publish_pull, it sends the jobs across  the  wire  to  the
   minions for processing.

   8)  After  the minions receive the request, they decrypt it and perform
   any requested work, if they determine that they are targeted to do so.

   9) When the minion is ready to respond, it publishes the result of  its
   job  back  to  the  master  by sending the encrypted result back to the
   master on TCP 4506 where it is again picked up  by  the  ReqServer  and
   forwarded  to an available MWorker for processing. (Again, this happens
   by passing this message across workers.ipc to an available worker.)

   10) When the MWorker receives the job it decrypts it and fires an event
   onto  the  master  event  bus  (master_event_pull.ipc).  (Again for the
   curious, this happens in AESFuncs._return().

   11) The EventPublisher sees this event and re-publishes it on  the  bus
   to   all   connected   listeners   of   the   master   event   bus  (on
   master_event_pub.ipc). This is where the LocalClient has been  waiting,
   listening  to  the event bus for minion replies. It gathers the job and
   stores the result.

   12) When all targeted minions have replied  or  the  timeout  has  been
   exceeded,  the  salt client displays the results of the job to the user
   on the CLI.

   Salt Minion
   Overview
   The salt-minion is a single process that sits on machines to be managed
   by  Salt.  It  can either operate as a stand-alone daemon which accepts
   commands locally via 'salt-call' or it can connect back to a master and
   receive commands remotely.

   When  starting  up,  salt minions connect _back_ to a master defined in
   the minion config file. The connect to two ports on the master:

      *

        TCP: 4505
               This is the connection to the master Publisher.  It  is  on
               this port that the minion receives jobs from the master.

      *

        TCP: 4506
               This  is  the  connection to the master ReqServer. It is on
               this port that the minion sends job  results  back  to  the
               master.

   Event System
   Similar  to  the  master,  a  salt-minion has its own event system that
   operates over IPC by default. The minion event  system  operates  on  a
   push/pull system with IPC files at minion_event_<unique_id>_pub.ipc and
   minion_event_<unique_id>_pull.ipc.

   The astute reader might ask why  have  an  event  bus  at  all  with  a
   single-process  daemon.  The  answer  is  that the salt-minion may fork
   other processes as required to do the work without  blocking  the  main
   salt-minion  process  and  this necessitates a mechanism by which those
   processes can communicate with each other. Secondarily, this provides a
   bus  by which any user with sufficient permissions can read or write to
   the bus as a common interface with the salt minion.

   Job Flow
   When a salt minion starts up, it attempts to connect to  the  Publisher
   and  the ReqServer on the salt master. It then attempts to authenticate
   and once the minion has successfully authenticated, it  simply  listens
   for jobs.

   Jobs  normally  come  either  come from the 'salt-call' script run by a
   local user on the salt minion or they can come directly from a master.

   Master Job Flow
   1) A master publishes a job that is received by a minion as outlined by
   the master's job flow above.

   2)  The  minion  is  polling its receive socket that's connected to the
   master Publisher (TCP 4505 on master).  When  it  detects  an  incoming
   message, it picks it up from the socket and decrypts it.

   3)  A  new  minion  process  or thread is created and provided with the
   contents of the  decrypted  message.  The  _thread_return()  method  is
   provided with the contents of the received message.

   4)  The  new  minion  thread  is created. The _thread_return() function
   starts up and actually calls out to the requested function contained in
   the job.

   5. The requested function runs and returns a result. [Still in thread.]

   6)  The  result of the function that's run is encrypted and returned to
   the master's ReqServer (TCP 4506 on master). [Still in thread.]

   7) Thread exits. Because the main thread was only blocked for the  time
   that it took to initialize the worker thread, many other requests could
   have been received and processed during this time.

   A Note on ClearFuncs vs. AESFuncs
   A common source of confusion is determining when messages are passed in
   the  clear  and  when  they  are passed using encryption. There are two
   rules governing this behaviour:

   1) ClearFuncs is used for intra-master  communication  and  during  the
   initial authentication handshake between a minion and master during the
   key exhange.

   2. AESFuncs is used everywhere else.

   Contributing
   There is a great  need  for  contributions  to  Salt  and  patches  are
   welcome!  The goal here is to make contributions clear, make sure there
   is a trail for where the code has come from, and most  importantly,  to
   give credit where credit is due!

   There are a number of ways to contribute to Salt development.

   For  details  on  how  to  contribute documentation improvements please
   review Writing Salt Documentation.

   Salt Coding Style
   SaltStack has its own coding style guide that informs  contributors  on
   various   coding  approaches.  Please  review  the  Salt  Coding  Style
   documentation for information about Salt's particular coding patterns.

   Within the Salt Coding Style documentation, there is  a  section  about
   running   Salt's  .pylintrc  file.  SaltStack  recommends  running  the
   .pylintrc  file  on  any  files  you  are  changing  with   your   code
   contribution  before  submitting  a  pull request to Salt's repository.
   Please see the Linting documentation for more information.

   Sending a GitHub pull request
   Sending pull requests on GitHub is the preferred method  for  receiving
   contributions. The workflow advice below mirrors GitHub's own guide and
   is well worth reading.

   1. Fork saltstack/salt on GitHub.

   2. Make a local clone of your fork.

         git clone [email protected]:my-account/salt.git
         cd salt

   3. Add saltstack/salt as a git remote.

         git remote add upstream https://github.com/saltstack/salt.git

   4. Create a new branch in your clone.

      NOTE:
         A branch should have one purpose. For example, "Fix  bug  X,"  or
         "Add feature Y".  Multiple unrelated fixes and/or features should
         be isolated into separate branches.

      If you're working on a bug or documentation fix, create your  branch
      from the oldest release branch that contains the bug or requires the
      documentation update. See Which Salt Branch?.

         git fetch upstream
         git checkout -b fix-broken-thing upstream/2016.3

      If you're working on a feature, create your branch from the  develop
      branch.

         git fetch upstream
         git checkout -b add-cool-feature upstream/develop

   5. Edit and commit changes to your branch.

         vim path/to/file1 path/to/file2
         git diff
         git add path/to/file1 path/to/file2
         git commit

      Write  a short, descriptive commit title and a longer commit message
      if necessary.

      NOTE:
         If your change fixes a bug or implements a feature already  filed
         in  the  issue  tracker, be sure to reference the issue number in
         the commit message body.

         Fix broken things in file1 and file2

         Fixes #31337

         # Please enter the commit message for your changes. Lines starting
         # with '#' will be ignored, and an empty message aborts the commit.
         # On branch fix-broken-thing
         # Changes to be committed:
         #       modified:   path/to/file1
         #       modified:   path/to/file2

      If you get stuck, there  are  many  introductory  Git  resources  on
      http://help.github.com.

   6. Push your locally-committed changes to your GitHub fork.

         git push -u origin fix-broken-thing

      or

         git push -u origin add-cool-feature

      NOTE:
         You  may  want to rebase before pushing to work out any potential
         conflicts:

             git fetch upstream
             git rebase upstream/2016.3 fix-broken-thing
             git push -u origin fix-broken-thing

         or

             git fetch upstream
             git rebase upstream/develop add-cool-feature
             git push -u origin add-cool-feature

         If  you  do  rebase,  and   the   push   is   rejected   with   a
         (non-fast-forward)  comment, then run git status. You will likely
         see a message about the branches diverging:

             On branch fix-broken-thing
             Your branch and 'origin/fix-broken-thing' have diverged,
             and have 1 and 2 different commits each, respectively.
               (use "git pull" to merge the remote branch into yours)
             nothing to commit, working tree clean

         Do NOT perform a git pull or git merge here. Instead, add --force
         to  the  end of the git push command to get the changes pushed to
         your fork. Pulling  or  merging,  while  they  will  resolve  the
         non-fast-forward issue, will likely add extra commits to the pull
         request which were not part of your changes.

   7. Find the branch on your GitHub salt fork.

      https://github.com/my-account/salt/branches/fix-broken-thing

   8. Open a new pull request.

      Click on Pull Request on the right near the top of the page,

      https://github.com/my-account/salt/pull/new/fix-broken-thing

      1. If your branch is a fix for a release branch, choose that as  the
         base branch (e.g. 2016.3),

         https://github.com/my-account/salt/compare/saltstack:2016.3...fix-broken-thing

         If your branch is a feature, choose develop as the base branch,

         https://github.com/my-account/salt/compare/saltstack:develop...add-cool-feature

      2. Review that the proposed changes are what you expect.

      3. Write  a  descriptive  comment.   Include links to related issues
         (e.g.  'Fixes #31337.') in the comment field.

      4. Click Create pull request.

   9. Salt project members will review your  pull  request  and  automated
      tests will run on it.

      If you recognize any test failures as being related to your proposed
      changes or if a reviewer asks for modifications:

      1. Make the new changes in  your  local  clone  on  the  same  local
         branch.

      2. Push  the  branch  to  GitHub  again  using  the same commands as
         before.

      3. New and updated  commits  will  be  added  to  the  pull  request
         automatically.

      4. Feel free to add a comment to the discussion.

   NOTE:
      Jenkins

      Pull  request  against  saltstack/salt are automatically tested on a
      variety of operating systems and configurations.  On  average  these
      tests  take  30  minutes.   Depending  on  your  GitHub notification
      settings you may also  receive  an  email  message  about  the  test
      results.

      Test     progress     and     results     can     be     found    at
      http://jenkins.saltstack.com/.

   Which Salt branch?
   GitHub will open pull requests against Salt's main branch, develop,  by
   default.  Ideally,  features  should  go into develop and bug fixes and
   documentation changes should  go  into  the  oldest  supported  release
   branch  affected  by  the  bug  or documentation update.  See Sending a
   GitHub pull request.

   If you have a bug fix or  doc  change  and  have  already  forked  your
   working  branch from develop and do not know how to rebase your commits
   against another branch, then submit it to develop anyway and  we'll  be
   sure to back-port it to the correct place.

   The current release branch
   The  current  release  branch  is  the most recent stable release. Pull
   requests containing bug  fixes  should  be  made  against  the  release
   branch.

   The branch name will be a date-based name such as 2016.3.

   Bug  fixes  are  made  on this branch so that minor releases can be cut
   from this branch without introducing surprises and new  features.  This
   approach maximizes stability.

   The  Salt  development  team will "merge-forward" any fixes made on the
   release branch to the develop branch once the  pull  request  has  been
   accepted.  This  keeps  the  fix in isolation on the release branch and
   also keeps the develop branch up-to-date.

   NOTE:
      Closing GitHub issues from commits

      This "merge-forward" strategy requires that the  magic  keywords  to
      close  a  GitHub  issue  appear in the commit message text directly.
      Only including the text in a pull request will not close the issue.

      GitHub will close the referenced issue once  the  commit  containing
      the  magic  text  is  merged  into the default branch (develop). Any
      magic text input only into the pull request description will not  be
      seen  at  the  Git-level  when  those commits are merged-forward. In
      other words, only the commits are merged-forward and  not  the  pull
      request.

   The develop branch
   The  develop  branch  is  unstable  and  bleeding-edge.  Pull  requests
   containing feature additions or  non-bug-fix  changes  should  be  made
   against the develop branch.

   The  Salt  development team will back-port bug fixes made to develop to
   the current release branch if the contributor cannot  create  the  pull
   request against that branch.

   Keeping Salt Forks in Sync
   Salt  is  advancing  quickly. It is therefore critical to pull upstream
   changes from upstream into your fork on a  regular  basis.  Nothing  is
   worse than putting hard work into a pull request only to see bunches of
   merge conflicts because it has diverged too far from upstream.

   SEE ALSO:
      GitHub Fork a Repo Guide

   The following assumes origin is the name of your fork and  upstream  is
   the name of the main saltstack/salt repository.

   1. View existing remotes.

         git remote -v

   2. Add the upstream remote.

         # For ssh github
         git remote add upstream [email protected]:saltstack/salt.git

         # For https github
         git remote add upstream https://github.com/saltstack/salt.git

   3. Pull upstream changes into your clone.

         git fetch upstream

   4. Update your copy of the develop branch.

         git checkout develop
         git merge --ff-only upstream/develop

      If Git complains that a fast-forward merge is not possible, you have
      local commits.

      * Run git pull --rebase origin develop to rebase your changes on top
        of the upstream changes.

      * Or,  run git branch <branch-name> to create a new branch with your
        commits. You will then need to reset your  develop  branch  before
        updating it with the changes from upstream.

      If  Git  complains  that  local  files will be overwritten, you have
      changes to files in your working directory. Run git  status  to  see
      the files in question.

   5. Update your fork.

         git push origin develop

   6. Repeat  the previous two steps for any other branches you work with,
      such as the current release branch.

   Posting patches to the mailing list
   Patches will also be  accepted  by  email.  Format  patches  using  git
   format-patch  and  send  them  to  the  salt-users  mailing  list.  The
   contributor will then get credit for the patch, and the Salt  community
   will have an archive of the patch and a place for discussion.

   Backporting Pull Requests
   If  a  bug  is  fixed  on  develop  and  the  bug  is also present on a
   currently-supported release branch it will need to  be  back-ported  to
   all applicable branches.

   NOTE:
      Most Salt contributors can skip these instructions

      These  instructions do not need to be read in order to contribute to
      the Salt project! The SaltStack team will back-port fixes on  behalf
      of contributors in order to keep the contribution process easy.

      These  instructions  are  intended  for  frequent Salt contributors,
      advanced Git users, SaltStack employees, or  independent  souls  who
      wish to back-port changes themselves.

   It is often easiest to fix a bug on the oldest supported release branch
   and then merge that branch forward into develop (as  described  earlier
   in  this  document).  When  that  is  not  possible  the  fix  must  be
   back-ported, or copied, into any other affected branches.

   These steps assume a pull request #1234 has been merged  into  develop.
   And upstream is the name of the remote pointing to the main Salt repo.

   1. Identify the oldest supported release branch that is affected by the
      bug.

   2. Create a new branch for the back-port by  reusing  the  same  branch
      from the original pull request.

      Name  the  branch  bp-<NNNN> and use the number of the original pull
      request.

         git fetch upstream refs/pull/1234/head:bp-1234
         git checkout bp-1234

   3. Find the parent commit of the original pull request.

      The parent commit of the original pull  request  must  be  known  in
      order  to rebase onto a release branch. The easiest way to find this
      is on GitHub.

      Open the original pull request on GitHub and find the  first  commit
      in the list of commits. Select and copy the SHA for that commit. The
      parent of that commit can be specified by appending ~1 to the end.

   4. Rebase the new branch on top of the release branch.

      * <release-branch> is the branch identified in step #1.

      * <orig-base> is the SHA identified in step #3 --  don't  forget  to
        add ~1 to the end!

         git rebase --onto <release-branch> <orig-base> bp-1234

      Note,  release branches prior to 2016.3 will not be able to make use
      of rebase and must use cherry-picking instead.

   5. Push the back-port branch to GitHub and open a new pull request.

      Opening a pull request for the back-port allows for the  test  suite
      and normal code-review process.

         git push -u origin bp-1234

   Issue and Pull Request Labeling System
   SaltStack  uses  several  labeling  schemes  to  help  facilitate  code
   contributions  and  bug  resolution.  See  the  Labels  and  Milestones
   documentation for more information.

   Deprecating Code
   Salt   should  remain  backwards  compatible,  though  sometimes,  this
   backwards compatibility needs to be broken because a  specific  feature
   and/or solution is no longer necessary or required.  At first one might
   think, let me change this code, it seems that it's  not  used  anywhere
   else so it should be safe to remove.  Then, once there's a new release,
   users complain about functionality which was  removed  and  they  where
   using  it,  etc.  This  should, at all costs, be avoided, and, in these
   cases, that specific code should be deprecated.

   In order to give users  enough  time  to  migrate  from  the  old  code
   behavior  to  the  new  behavior,  the deprecation time frame should be
   carefully determined based on the significance and  complexity  of  the
   changes required by the user.

   Salt feature releases are based on the Periodic Table. Any new features
   going into the develop branch will be named after the next  element  in
   the Periodic Table. For example, Beryllium was the feature release name
   of the develop branch before the 2015.8  branch  was  tagged.  At  that
   point  in  time,  any  new features going into the develop branch after
   2015.8 was branched were part of the Boron feature release.

   A deprecation warning should  be  in  place  for  at  least  two  major
   releases  before  the  deprecated code and its accompanying deprecation
   warning are removed.  More  time  should  be  given  for  more  complex
   changes.   For  example,  if  the  current release under development is
   Sodium, the deprecated code and associated warnings  should  remain  in
   place and warn for at least Aluminum.

   To  help in this deprecation task, salt provides salt.utils.warn_until.
   The idea behind this helper function is to show the deprecation warning
   to the user until salt reaches the provided version. Once that provided
   version is equaled  salt.utils.warn_until  will  raise  a  RuntimeError
   making  salt  stop  its execution. This stoppage is unpleasant and will
   remind the developer that the deprecation limit has  been  reached  and
   that the code can then be safely removed.

   Consider the following example:

      def some_function(bar=False, foo=None):
          if foo is not None:
              salt.utils.warn_until(
                  'Aluminum',
                  'The \'foo\' argument has been deprecated and its '
                  'functionality removed, as such, its usage is no longer '
                  'required.'
              )

   Development begins on the Aluminum release when the Magnesium branch is
   forked from the develop branch.  Once this  occurs,  all  uses  of  the
   warn_until  function  targeting  Aluminum, along with the code they are
   warning about should be removed from the code.

   Dunder Dictionaries
   Salt provides several special "dunder" dictionaries  as  a  convenience
   for  Salt  development.  These include __opts__, __context__, __salt__,
   and others. This document will  describe  each  dictionary  and  detail
   where  they  exist  and  what  information  and/or  functionality  they
   provide.

   __opts__
   Available in
   * All loader modules

   The __opts__ dictionary contains all  of  the  options  passed  in  the
   configuration file for the master or minion.

   NOTE:
      In  many  places  in  salt,  instead  of  pulling  raw data from the
      __opts__ dict, configuration data should be pulled from the salt get
      functions        such        as        config.get,       aka       -
      __salt__['config.get']('foo:bar') The get functions also  allow  for
      dict  traversal  via  the : delimiter.  Consider using get functions
      whenever using __opts__ or __pillar__  and  __grains__  (when  using
      grains for configuration data)

   The  configuration  file data made available in the __opts__ dictionary
   is the configuration data  relative  to  the  running  daemon.  If  the
   modules  are  loaded  and  executed  by  the  master,  then  the master
   configuration data is available, if the modules  are  executed  by  the
   minion,  then  the  minion  configuration  is available. Any additional
   information passed into the  respective  configuration  files  is  made
   available

   __salt__
   Available in
   * Execution Modules

   * State Modules

   * Returners

   * Runners

   __salt__  contains  the execution module functions. This allows for all
   functions to be called as they have been set up by the salt loader.

      __salt__['cmd.run']('fdisk -l')
      __salt__['network.ip_addrs']()

   NOTE:
      When used in runners, __salt__ references other runner modules,  and
      not execution modules.

   __grains__
   Available in
   * Execution Modules

   * State Modules

   * Returners

   * External Pillar

   The  __grains__  dictionary  contains  the grains data generated by the
   minion that is currently being worked with. In execution modules, state
   modules  and  returners  this  is  the grains of the minion running the
   calls, when generating the external pillar the __grains__ is the grains
   data from the minion that the pillar is being generated for.

   __pillar__
   Available in
   * Execution Modules

   * State Modules

   * Returners

   The  __pillar__  dictionary  contains  the  pillar  for  the respective
   minion.

   __context__
   __context__ exists in state modules and execution modules.

   During a state run  the  __context__  dictionary  persists  across  all
   states that are run and then is destroyed when the state ends.

   When running an execution module __context__ persists across all module
   executions  until   the   modules   are   refreshed;   such   as   when
   saltutil.sync_all or state.apply are executed.

   A  great  place to see how to use __context__ is in the cp.py module in
   salt/modules/cp.py. The fileclient authenticates with the  master  when
   it is instantiated and then is used to copy files to the minion. Rather
   than create a new fileclient for each file that is to be  copied  down,
   one  instance  of  the  fileclient  is  instantiated in the __context__
   dictionary and is reused  for  each  file.  Here  is  an  example  from
   salt/modules/cp.py:

      if not 'cp.fileclient' in __context__:
          __context__['cp.fileclient'] = salt.fileclient.get_file_client(__opts__)

   NOTE:
      Because  __context__  may  or may not have been destroyed, always be
      sure to check for the  existence  of  the  key  in  __context__  and
      generate the key before using it.

   External Pillars
   Salt  provides  a  mechanism  for  generating  pillar  data  by calling
   external pillar interfaces. This document will describe an  outline  of
   an ext_pillar module.

   Location
   Salt  expects to find your ext_pillar module in the same location where
   it looks for other python modules. If the extension_modules  option  in
   your  Salt  master  configuration  is  set, Salt will look for a pillar
   directory under there and load all the modules it finds. Otherwise,  it
   will look in your Python site-packages salt/pillar directory.

   Configuration
   The  external  pillars  that  are  called  when  a minion refreshes its
   pillars is controlled by the  ext_pillar  option  in  the  Salt  master
   configuration. You can pass a single argument, a list of arguments or a
   dictionary of arguments to your pillar:

      ext_pillar:
        - example_a: some argument
        - example_b:
          - argumentA
          - argumentB
        - example_c:
            keyA: valueA
            keyB: valueB

   The Module
   Imports and Logging
   Import modules your external pillar  module  needs.  You  should  first
   include generic modules that come with stock Python:

      import logging

   And  then start logging. This is an idiomatic way of setting up logging
   in Salt:

      log = logging.getLogger(__name__)

   Finally, load modules that are specific to  what  you  are  doing.  You
   should catch import errors and set a flag that the __virtual__ function
   can use later.

      try:
          import weird_thing
          EXAMPLE_A_LOADED = True
      except ImportError:
          EXAMPLE_A_LOADED = False

   Options
   If you define an __opts__  dictionary,  it  will  be  merged  into  the
   __opts__  dictionary handed to the ext_pillar function later. This is a
   good place to put default configuration items.  The  convention  is  to
   name things modulename.option.

      __opts__ = { 'example_a.someconfig': 137 }

   Initialization
   If  you  define  an  __init__  function,  it  will  be  called with the
   following signature:

      def __init__( __opts__ ):
          # Do init work here

   Note: The __init__ function is  ran  every  time  a  particular  minion
   causes   the   external  pillar  to  be  called,  so  don't  put  heavy
   initialization code here.  The __init__ functionality is a  side-effect
   of  the  Salt loader, so it may not be as useful in pillars as it is in
   other Salt items.

   __virtual__
   If you define a __virtual__ function, you can control  whether  or  not
   this  module  is  visible.  If  it returns False then Salt ignores this
   module. If it returns a string, then  that  string  will  be  how  Salt
   identifies  this  external  pillar  in its ext_pillar configuration. If
   you're not renaming the module, simply return True in  the  __virtual__
   function,  which  is  the same as if this function did not exist, then,
   the name Salt's ext_pillar will use to  identify  this  module  is  its
   conventional name in Python.

   This  is  useful  to  write  modules  that can be installed on all Salt
   masters, but will only be visible if a  particular  piece  of  software
   your module requires is installed.

      # This external pillar will be known as `example_a`
      def __virtual__():
          if EXAMPLE_A_LOADED:
              return True
          return False

      # This external pillar will be known as `something_else`
      __virtualname__ = 'something_else'

      def __virtual__():
          if EXAMPLE_A_LOADED:
              return __virtualname__
          return False

   ext_pillar
   This  is  where  the  real  work of an external pillar is done. If this
   module is active and has  a  function  called  ext_pillar,  whenever  a
   minion updates its pillar this function is called.

   How  it  is  called  depends on how it is configured in the Salt master
   configuration.  The  first  argument  is  always  the  current   pillar
   dictionary,  this  contains  pillar items that have already been added,
   starting with the data from pillar_roots, and then from any already-ran
   external pillars.

   Using our example above:

      ext_pillar( id, pillar, 'some argument' )                   # example_a
      ext_pillar( id, pillar, 'argumentA', 'argumentB' )          # example_b
      ext_pillar( id, pillar, keyA='valueA', keyB='valueB' } )    # example_c

   In  the  example_a  case,  pillar  will  contain  the  items  from  the
   pillar_roots, in example_b pillar  will contain  that  plus  the  items
   added  by example_a, and in example_c pillar will contain that plus the
   items added by example_b. In all three cases, id will contain the ID of
   the minion making the pillar request.

   This  function  should  return  a dictionary, the contents of which are
   merged in with all of the other pillars and  returned  to  the  minion.
   Note:  this  function  is  called once for each minion that fetches its
   pillar data.

      def ext_pillar( minion_id, pillar, *args, **kwargs ):

          my_pillar = {'external_pillar': {}}

          my_pillar['external_pillar'] = get_external_pillar_dictionary()

          return my_pillar

   You can call pillar with the dictionary's  top  name  to  retrieve  its
   data.   From  above  example,  'external_pillar'  is the top dictionary
   name. Therefore:

      salt-call '*' pillar.get external_pillar

   You shouldn't just add items to pillar and return that, since that will
   cause  Salt  to merge data that already exists. Rather, just return the
   items you are adding or changing. You could,  however,  use  pillar  in
   your  module  to  make  some decision based on pillar data that already
   exists.

   This function has access to some useful globals:

   __opts__
          A dictionary of mostly Salt configuration options. If you had an
          __opts__ dictionary defined in your module, those values will be
          included.

   __salt__
          A dictionary of Salt module functions, useful so you don't  have
          to    duplicate    functions    that    already    exist.   E.g.
          __salt__['cmd.run']( 'ls -l' ) Note, runs on the master

   __grains__
          A dictionary of the grains of  the  minion  making  this  pillar
          call.

   Example configuration
   As  an  example,  if you wanted to add external pillar via the cmd_json
   external pillar, add something like this to your master config:

      ext_pillar:
        - cmd_json: 'echo {\"arg\":\"value\"}'

   Reminder
   Just as with traditional pillars, external pillars must be refreshed in
   order for minions to see any fresh data:

      salt '*' saltutil.refresh_pillar

   Installing Salt for development
   Clone the repository using:

      git clone https://github.com/saltstack/salt

   NOTE:
      tags

      Just  cloning  the  repository  is enough to work with Salt and make
      contributions.  However,  fetching  additional  tags  from  git   is
      required  to  have Salt report the correct version for itself. To do
      this, first add the git repository as an upstream source:

          git remote add upstream https://github.com/saltstack/salt

      Fetching tags is done with the git 'fetch' utility:

          git fetch --tags upstream

   Create a new virtualenv:

      virtualenv /path/to/your/virtualenv

   Avoid making your virtualenv path too long.

   On Arch Linux, where Python 3 is the default  installation  of  Python,
   use the virtualenv2 command instead of virtualenv.

   On  Gentoo  you  must  use  --system-site-packages  to  enable  pkg and
   portage_config functionality

   NOTE:
      Using system Python modules in the virtualenv

      To use already-installed python modules in  virtualenv  (instead  of
      having   pip   download   and  compile  new  ones),  run  virtualenv
      --system-site-packages Using this method eliminates the  requirement
      to install the salt dependencies again, although it does assume that
      the listed modules are all installed in the system PYTHONPATH at the
      time of virtualenv creation.

   NOTE:
      Python development package

      Be sure to install python devel package in order to install required
      Python  modules.  In  Debian/Ubuntu  run  sudo  apt-get  install  -y
      python-dev. In RedHat based system install python-devel

   Activate the virtualenv:

      source /path/to/your/virtualenv/bin/activate

   Install Salt (and dependencies) into the virtualenv:

      pip install M2Crypto    # Don't install on Debian/Ubuntu (see below)
      pip install pyzmq PyYAML pycrypto msgpack-python jinja2 psutil futures tornado
      pip install -e ./salt   # the path to the salt git clone from above

   NOTE:
      Installing M2Crypto

      swig and libssl-dev are required to build M2Crypto. To fix the error
      command 'swig' failed with exit status 1 while installing  M2Crypto,
      try installing it with the following command:

          env SWIG_FEATURES="-cpperraswarn -includeall -D__`uname -m`__ -I/usr/include/openssl" pip install M2Crypto

      Debian  and  Ubuntu  systems  have  modified  openssl  libraries and
      mandate that a patched version of M2Crypto be installed. This  means
      that M2Crypto needs to be installed via apt:

          apt-get install python-m2crypto

      This  also  means  that  pulling in the M2Crypto installed using apt
      requires using --system-site-packages when creating the virtualenv.

      If you're using a platform other than Debian or Ubuntu, and you  are
      installing  M2Crypto  via  pip instead of a system package, then you
      will also need the gcc compiler.

   NOTE:
      Installing psutil

      Python header files are required to build this module, otherwise the
      pip  install  will fail. If your distribution separates binaries and
      headers into separate packages, make sure that you have the  headers
      installed.  In most Linux distributions which split the headers into
      their own package, this can be done by installing the python-dev  or
      python-devel  package.  For other platforms, the package will likely
      be similarly named.

   NOTE:
      Installing dependencies on OS X.

      You can install needed  dependencies  on  OS  X  using  homebrew  or
      macports.  See OS X Installation

   WARNING:
      Installing on RedHat-based Distros

      If  installing  from pip (or from source using setup.py install), be
      advised that the yum-utils package is  needed  for  Salt  to  manage
      packages on RedHat-based systems.

   Running a self-contained development version
   During  development it is easiest to be able to run the Salt master and
   minion that are installed in the virtualenv you created above, and also
   to  have  all  the configuration, log, and cache files contained in the
   virtualenv as well.

   Copy the master and minion config files into your virtualenv:

      mkdir -p /path/to/your/virtualenv/etc/salt
      cp ./salt/conf/master ./salt/conf/minion /path/to/your/virtualenv/etc/salt/

   Edit the master config file:

   1. Uncomment and change the user: root value to your own user.

   2. Uncomment  and  change  the  root_dir:   /   value   to   point   to
      /path/to/your/virtualenv.

   3. If  you  are  running version 0.11.1 or older, uncomment, and change
      the   pidfile:   /var/run/salt-master.pid   value   to   point    to
      /path/to/your/virtualenv/salt-master.pid.

   4. If  you  are also running a non-development version of Salt you will
      have to change the publish_port and ret_port values as well.

   Edit the minion config file:

   1. Repeat the edits you made in the master  config  for  the  user  and
      root_dir values as well as any port changes.

   2. If  you  are  running version 0.11.1 or older, uncomment, and change
      the   pidfile:   /var/run/salt-minion.pid   value   to   point    to
      /path/to/your/virtualenv/salt-minion.pid.

   3. Uncomment and change the master: salt value to point at localhost.

   4. Uncomment  and  change  the  id: value to something descriptive like
      "saltdev". This isn't strictly necessary but  it  will  serve  as  a
      reminder of which Salt installation you are working with.

   5. If  you  changed the ret_port value in the master config because you
      are also running a non-development version of Salt,  then  you  will
      have to change the master_port value in the minion config to match.

   NOTE:
      Using salt-call with a Standalone Minion

      If  you  plan  to run salt-call with this self-contained development
      environment in a masterless setup, you should invoke salt-call  with
      -c  /path/to/your/virtualenv/etc/salt  so  that  salt  can  find the
      minion config file. Without the -c option,  Salt  finds  its  config
      files in /etc/salt.

   Start  the  master and minion, accept the minion's key, and verify your
   local Salt installation is working:

      cd /path/to/your/virtualenv
      salt-master -c ./etc/salt -d
      salt-minion -c ./etc/salt -d
      salt-key -c ./etc/salt -L
      salt-key -c ./etc/salt -A
      salt -c ./etc/salt '*' test.ping

   Running the master and  minion  in  debug  mode  can  be  helpful  when
   developing.  To  do  this, add -l debug to the calls to salt-master and
   salt-minion.  If you would like to log to the console instead of to the
   log file, remove the -d.

   NOTE:
      Too long socket path?

      Once the minion starts, you may see an error like the following:

          zmq.core.error.ZMQError: ipc path "/path/to/your/virtualenv/
          var/run/salt/minion/minion_event_7824dcbcfd7a8f6755939af70b96249f_pub.ipc"
          is longer than 107 characters (sizeof(sockaddr_un.sun_path)).

      This  means  that  the path to the socket the minion is using is too
      long. This is a system limitation, so  the  only  workaround  is  to
      reduce  the  length  of  this  path.  This  can  be done in a couple
      different ways:

      1. Create your virtualenv in a path that is short enough.

      2. Edit the sock_dir minion config variable and reduce  its  length.
         Remember  that  this  path  is  relative  to the value you set in
         root_dir.

      NOTE: The socket path is limited to 107 characters  on  Solaris  and
      Linux, and 103 characters on BSD-based systems.

   NOTE:
      File descriptor limits

      Ensure that the system open file limit is raised to at least 2047:

          # check your current limit
          ulimit -n

          # raise the limit. persists only until reboot
          # use 'limit descriptors 2047' for c-shell
          ulimit -n 2047

      To  set  file  descriptors  on  OSX,  refer to the OS X Installation
      instructions.

   Changing Default Paths
   Instead of updating your configuration files to point to the  new  root
   directory  and  having  to pass the new configuration directory path to
   all of Salt's CLI tools, you can explicitly tweak  the  default  system
   paths that Salt expects:

      GENERATE_SALT_SYSPATHS=1 pip install --global-option='--salt-root-dir=/path/to/your/virtualenv/' \
          -e ./salt   # the path to the salt git clone from above

   You can now call all of Salt's CLI tools without explicitly passing the
   configuration directory.

   Additional Options
   In case you want to distribute your virtualenv, you probably don't want
   to  include  Salt's  clone .git/ directory, and, without it, Salt won't
   report the accurate version. You can  tell  setup.py  to  generate  the
   hardcoded version information which is distributable:

      GENERATE_SALT_SYSPATHS=1 WRITE_SALT_VERSION=1 pip install --global-option='--salt-root-dir=/path/to/your/virtualenv/' \
          -e ./salt   # the path to the salt git clone from above

   Instead of passing those two environmental variables, you can just pass
   a single one which will trigger the other two:

      MIMIC_SALT_INSTALL=1 pip install --global-option='--salt-root-dir=/path/to/your/virtualenv/' \
          -e ./salt   # the path to the salt git clone from above

   This last one  will  grant  you  an  editable  salt  installation  with
   hardcoded system paths and version information.

   Installing Salt from the Python Package Index
   If  you  are  installing  using easy_install, you will need to define a
   USE_SETUPTOOLS environment variable, otherwise dependencies will not be
   installed:

      USE_SETUPTOOLS=1 easy_install salt

   Editing and previewing the documentation
   You  need sphinx-build command to build the docs. In Debian/Ubuntu this
   is provided in the python-sphinx package. Sphinx can also be  installed
   to a virtualenv using pip:

      pip install Sphinx==1.3.1

   Change to salt documentation directory, then:

      cd doc; make html

   * This  will build the HTML docs. Run make without any arguments to see
     the available make targets, which include html, man, and text.

   * The docs then are built within the docs/_build/ folder. To update the
     docs after making changes, run make again.

   * The  docs  use  reStructuredText  for  markup.   See  a  live demo at
     http://rst.ninjs.org/.

   * The help information on each module  or  state  is  culled  from  the
     python  code  that runs for that piece. Find them in salt/modules/ or
     salt/states/.

   * To build the docs  on  Arch  Linux,  the  python2-sphinx  package  is
     required.  Additionally,  it  is necessary to tell make where to find
     the proper sphinx-build binary, like so:

      make SPHINXBUILD=sphinx-build2 html

   * To build the docs on RHEL/CentOS 6, the python-sphinx10 package  must
     be installed from EPEL, and the following make command must be used:

      make SPHINXBUILD=sphinx-build html

   Once  you've  updated  the  documentation,  you  can  run the following
   command to launch a simple Python HTTP server to see your changes:

      cd _build/html; python -m SimpleHTTPServer

   Running unit and integration tests
   Run the test suite with following command:

      ./setup.py test

   See here for more information regarding the test suite.

   Issue and Pull Request Labeling System
   SaltStack  uses  several  labeling  schemes  to  help  facilitate  code
   contributions  and  bug  resolution.  See  the  Labels  and  Milestones
   documentation for more information.

   GitHub Labels and Milestones
   SaltStack uses several label categories,  as  well  as  milestones,  to
   triage  incoming  issues and pull requests in the GitHub issue tracker.
   Labels are used to sort issues by  type,  priority,  severity,  status,
   functional  area,  functional  group,  and  targeted  release  and pull
   requests by status, functional area, functional group, type of  change,
   and  test  status.  Milestones are used to indicate whether an issue is
   fully triaged or is scheduled to be fixed by SaltStack in  an  upcoming
   sprint.

   Milestones
   All  issues  are  assigned  to  a  milestone, whereas pull requests are
   almost never assigned to a milestone  as  the  mean  lifetime  of  pull
   requests  is  short  enough  that  there  is  no  need  to  track  them
   temporally.

   SaltStack uses milestones to  indicate  which  issues  are  blocked  on
   submitter  or  upstream  actions,  are approved, or are scheduled to be
   fixed or implemented in  an  upcoming  sprint.   If  an  issue  is  not
   attached  to  a sprint milestone, you are welcome to work on it at your
   own desire and convenience.  If it is attached to  a  sprint  milestone
   and  you have already begun working on it or have a solution in mind or
   have other ideas related to the issue, you are encouraged to coordinate
   with  the  assignee  via  the  GitHub  issue tracker to create the best
   possible solution or implementation.

   Approved
          The issue has been validated and has all necessary information.

   Blocked
          The issue is waiting on actions by parties outside of SaltStack,
          such  as  receiving  more  information  from  the  submitter  or
          resolution of an upstream  issue.   This  milestone  is  usually
          applied  in  conjunction  with the labels Info Needed, Question,
          Expected Behavior, Won't Fix For Now, or Upstream Bug.

   Under Review
          The issue is having  further  validation  done  by  a  SaltStack
          engineer.

   <Sprint>
          The  issue  is being actively worked on by a SaltStack engineer.
          Sprint milestones names are constructed from the chemical symbol
          of  the  next release's codename and the number of sprints until
          that release is made.  For example, if the next release codename
          is  Neon  and  there  are  five  sprints until that release, the
          corresponding  sprint  milestone  will  be  called  Ne  5.   See
          <topics/releases/version_numbers>  for  a  discussion  of Salt's
          release codenames.

   Labels
   Labels are used to sort and describe issues and  pull  requests.   Some
   labels  are  usually  reserved for one or the other, though most labels
   may be applied to both.

   New issues will receive at least one label and  a  milestone,  and  new
   pull  requests  will  receive  at  least  one  label.   Except  for the
   functional area and functional  group  label  categories,  issues  will
   generally receive only up to one label per category.

   Type
   Issues  are  categorized  into  one  of several types.  Type labels are
   almost never used for pull requests.  GitHub treats pull requests  like
   issues  in  many  ways,  so a pull request could be considered an issue
   with an implicit Pull Request type label applied.

   Feature
          The issue is a request for new functionality including  changes,
          enhancements, refactors, etc.

   Bug    The  issue  documents  broken, incorrect, or confusing behavior.
          This label is always accompanied by a severity label.

   Duplicate
          The issue is a duplicate  of  another  feature  request  or  bug
          report.

   Upstream Bug
          The issue is a result of an upstream issue.

   Question
          The  issue is more of a question than a request for new features
          or a report of  broken  features,  but  can  sometimes  lead  to
          further  discussion  or  changes  of  confusing  or  incongruous
          behavior or documentation.

   Expected Behavior
          The issue is a bug report of intended functionality.

   Priority
   An issue's priority is relative to  its  functional  area.   If  a  bug
   report, for example, about gitfs indicates that all users of gitfs will
   encounter this bug, then a P1 label will be applied, even though  users
   who  are  not  using gitfs will not encounter the bug.  If a feature is
   requested by many users, it may be given a high priority.

   P1     The issue will be seen by all users.

   P2     The issue will be seen by most users.

   P3     The issue will be seen by about half of users.

   P4     The issue will not be seen by most users.  Usually the issue  is
          a very specific use case or corner case.

   Severity
   Severity labels are almost always only applied to issues labeled Bug.

   Blocker
          The issue is blocking an impending release.

   Critical
          The  issue  causes  data  loss, crashes or hangs salt processes,
          makes the system unresponsive, etc.

   High Severity
          The issue reports incorrect functionality, bad functionality,  a
          confusing user experience, etc.

   Medium Severity
          The  issue reports cosmetic items, formatting, spelling, colors,
          etc.

   Functional Area
   Many major components of Salt have corresponding GitHub labels.   These
   labels  are  applied  to  all issues and pull requests as is reasonably
   appropriate.  They are useful in organizing issues  and  pull  requests
   according  to  the  source  code  relevant to issues or the source code
   changed by pull requests.

   * Execution Module

   * File Servers

   * Grains

   * Multi-Master

   * Packaging  Related to packaging  of  Salt,  not  Salt's  support  for
     package management.

   * Pillar

   * RAET

   * Returners

   * Runners

   * SPM

   * Salt-API

   * Salt-Cloud

   * Salt-SSH

   * Salt-Syndic

   * State Module

   * Tests

   * Transport

   * Windows

   * ZMQ

   Functional Group
   These  labels  sort  issues and pull requests according to the internal
   SaltStack engineering teams.

   Core   The issue or pull request relates to code  that  is  central  or
          existential to Salt itself.

   Platform
          The  issue  or  pull  request relates to support and integration
          with various platforms like  traditional  operating  systems  as
          well  as  containers, platform-based utilities like filesystems,
          command schedulers, etc.,  and  system-based  applications  like
          webservers, databases, etc.

   RIoT   The  issue  or  pull  request relates to support and integration
          with various abstract systems like cloud providers, hypervisors,
          API-based services, etc.

   Console
          The  issue  or  pull request relates to the SaltStack enterprise
          console.

   Documentation
          The issue or pull request relates to documentation.

   Status
   Status labels are used to define and track the state of issues and pull
   requests.   Not  all potential statuses correspond to a label, but some
   statuses are common enough that labels have been created for them.   If
   an  issue  has  not been moved beyond the Blocked milestone, it is very
   likely that it will only have a status label.

   Bugfix - back-port
          The pull request needs to be back-ported  to  an  older  release
          branch.   This  is  done  by recreating the pull request against
          that branch.  Once the back-port is  completed,  this  label  is
          replaced  with  a  Bugfix - [Done] back-ported label.  Normally,
          new features should go into the develop and bug fixes  into  the
          oldest supported release branch, see <which-salt-branch>.

   Bugfix - [Done] back-ported
          The pull request has been back-ported to an older branch.

   Cannot Reproduce
          The  issue  is  a  bug  and  has  been  reviewed  by a SaltStack
          engineer,  but  it  cannot  be  replicated  with  the   provided
          information  and context.  Those involved with the bug will need
          to work through additional ideas until the bug can  be  isolated
          and verified.

   Confirmed
          The  issue  is  a  bug  and  has  been  confirmed by a SaltStack
          engineer, who often documents a  minimal  working  example  that
          reproduces the bug.

   Fixed Pending Verification
          The  issue  is  a  bug  and  has  been fixed by one or more pull
          requests, which should link to the issue.  Closure of the  issue
          is   contingent   upon   confirmation  of  resolution  from  the
          submitter.  If the submitter reports  a  negative  confirmation,
          this  label  is  removed.   If  no response is given after a few
          weeks, then the issue will be assumed fixed and closed.

   Info Needed
          The issue needs more information before it can be  verified  and
          resolved.   For a feature request this may include a description
          of the use cases.  Almost all bug reports  need  to  include  at
          least the versions of salt and its dependencies, the system type
          and version, commands used,  debug  logs,  error  messages,  and
          relevant configs.

   Pending Changes
          The  pull  request  needs  additional  changes  before it can be
          merged.

   Pending Discussion
          The issue or pull request needs more discussion before it can be
          closed  or  merged.   The status of the issue or pull request is
          not clear or apparent enough for definite action to be taken, or
          additional input from SaltStack, the submitter, or another party
          has been requested.

          If the issue is not a pull  request,  once  the  discussion  has
          arrived  at  a cogent conclusion, this label will be removed and
          the issue will be accepted.   If  it  is  a  pull  request,  the
          results  of  the  discussion  may require additional changes and
          thus, a Pending Changes label.

   Won't Fix for Now
          The issue is legitimate, but it is not something  the  SaltStack
          team  is  currently able or willing to fix or implement.  Issues
          having this label may be revisited in the future.

   Type of Change
   Every pull request should receive a change label.  These labels measure
   the  quantity of change as well as the significance of the change.  The
   amount of change and the  importance  of  the  code  area  changed  are
   considered,  but  often the depth of secondary code review required and
   the potential repercussions of the change may  also  advise  the  label
   choice.

   Core  code  areas  include:  state  compiler, crypto engine, master and
   minion  and  syndic  daemons,  transport,  pillar  rendering,   loader,
   transport  layer,  event  system,  salt.utils,  client,  cli,  logging,
   netapi, runner engine, templating engine, top  file  compilation,  file
   client, file server, mine, salt-ssh, test runner, etc.

   Non-core  code usually constitutes the specific set of plugins for each
   of the several  plugin  layers  of  Salt:  execution  modules,  states,
   runners, returners, clouds, etc.

   Minor Change

          * Less than 64 lines changed, or

          * Less than 8 core lines changed

   Medium Change

          * Less than 256 lines changed, or

          * Less than 64 core lines changed

   Master Change

          * More than 256 lines changed, or

          * More than 64 core lines changed

   Expert Change

          * Needs specialized, in-depth review

   Test Status
   These  labels  relate  to the status of the automated tests that run on
   pull requests.  If the tests  on  a  pull  request  fail  and  are  not
   overridden  by one of these labels, the pull request submitter needs to
   update the code and/or tests so  that  the  tests  pass  and  the  pull
   request can be merged.

   Lint   The  pull  request has passed all tests except for the code lint
          checker.

   Tests Passed
          The pull request has passed all  tests  even  though  some  test
          results   are   negative.    Sometimes   the  automated  testing
          infrastructure will encounter internal errors unrelated  to  the
          code  change  in  the pull request that cause test runs to fail.
          These errors can be caused by cloud host and network issues  and
          also  Jenkins  issues  like  erroneously  accumulating workspace
          artifacts, resource exhaustion, and bugs that  arise  from  long
          running Jenkins processes.

   Other
   These  labels  indicate  miscellaneous issue types or statuses that are
   common or important enough to be tracked and sorted with labels.

   Awesome
          The pull request implements an especially well crafted solution,
          or a very difficult but necessary change.

   Help Wanted
          The issue appears to have a simple solution.  Issues having this
          label should be a good starting place for  new  contributors  to
          Salt.

   Needs Testcase
          The  issue  or pull request relates to a feature that needs test
          coverage.   The  pull  request  containing  the   tests   should
          reference the issue or pull request having this label, whereupon
          the label should be removed.

   Regression
          The issue is a bug that breaks functionality known  to  work  in
          previous releases.

   Story  The  issue  is used by a SaltStack engineer to track progress on
          multiple related issues in a single place.

   Stretch
          The issue is an optional goal for the current sprint but may not
          be delivered.

   ZD     The issue is related to a Zendesk customer support ticket.

   <Release>
          The  issue  is  scheduled  to  be implemented by <Release>.  See
          <topics/releases/version_numbers> for  a  discussion  of  Salt's
          release codenames.

   Logging Internals
   TODO

   Modular Systems
   When  first  working with Salt, it is not always clear where all of the
   modular components are and what they do. Salt comes  loaded  with  more
   modular  systems than many users are aware of, making Salt very easy to
   extend in many places.

   The most commonly  used  modular  systems  are  execution  modules  and
   states.  But  the  modular  systems  extend well beyond the more easily
   exposed components and are often added to Salt  to  make  the  complete
   system more flexible.

   Execution Modules
   Execution modules make up the core of the functionality used by Salt to
   interact with client systems. The execution  modules  create  the  core
   system  management  library used by all Salt systems, including states,
   which interact with minion systems.

   Execution modules are completely open ended in  their  execution.  They
   can  be  used  to  do  anything  required  on a minion, from installing
   packages to detecting information about the system. The only  restraint
   in execution modules is that the defined functions always return a JSON
   serializable object.

   For a list of all built in execution modules, click here

   For information on writing execution modules, see this page.

   Interactive Debugging
   Sometimes debugging with print() and extra logs sprinkled everywhere is
   not the best strategy.

   IPython  is  a  helpful  debug  tool  that  has  an  interactive python
   environment which can be embedded in python programs.

   First the system will require IPython to be installed.

      # Debian
      apt-get install ipython

      # Arch Linux
      pacman -Syu ipython2

      # RHEL/CentOS (via EPEL)
      yum install python-ipython

   Now, in the troubling python  module,  add  the  following  line  at  a
   location where the debugger should be started:

      test = 'test123'
      import IPython; IPython.embed_kernel()

   After  running  a  Salt command that hits that line, the following will
   show up in the log file:

      [CRITICAL] To connect another client to this kernel, use:
      [IPKernelApp] --existing kernel-31271.json

   Now on the system that invoked embed_kernel, run the following  command
   from a shell:

      # NOTE: use ipython2 instead of ipython for Arch Linux
      ipython console --existing

   This  provides a console that has access to all the vars and functions,
   and even supports tab-completion.

      print(test)
      test123

   To exit IPython and continue running Salt, press Ctrl-d to logout.

   State Modules
   State modules are used to define the  state  interfaces  used  by  Salt
   States.   These  modules  are  restrictive  in  that they must follow a
   number of rules to function properly.

   NOTE:
      State modules define the available routines in sls files. If calling
      an  execution  module directly is desired, take a look at the module
      state.

   Auth
   The auth module system allows for external authentication  routines  to
   be easily added into Salt. The auth function needs to be implemented to
   satisfy the requirements of an auth module. Use the pam  module  as  an
   example.

   Fileserver
   The fileserver module system is used to create fileserver backends used
   by the Salt Master. These modules need to implement the functions  used
   in the fileserver subsystem. Use the gitfs module as an example.

   Grains
   Grain  modules  define  extra  routines  to  populate  grains data. All
   defined public functions will be executed and MUST return a Python dict
   object. The dict keys will be added to the grains made available to the
   minion.

   Output
   The output modules supply the outputter system with routines to display
   data  in  the  terminal. These modules are very simple and only require
   the output function to execute. The default  system  outputter  is  the
   nested module.

   Pillar
   Used  to  define optional external pillar systems. The pillar generated
   via the filesystem pillar is passed  into  external  pillars.  This  is
   commonly  used as a bridge to database data for pillar, but is also the
   backend to  the  libvirt  state  used  to  generate  and  sign  libvirt
   certificates on the fly.

   Renderers
   Renderers  are  the  system used to render sls files into salt highdata
   for the state compiler. They can be as simple as the py renderer and as
   complex as stateconf and pydsl.

   Returners
   Returners  are  used  to  send  data  from minions to external sources,
   commonly databases. A full returner will implement all routines  to  be
   supported  as  an  external  job  cache.  Use  the redis returner as an
   example.

   Runners
   Runners are purely master-side execution sequences.

   Tops
   Tops modules are used to convert external data sources  into  top  file
   data for the state system.

   Wheel
   The  wheel  system  is  used to manage master side management routines.
   These routines are primarily intended for  the  API  to  enable  master
   configuration.

   Package Providers
   This page contains guidelines for writing package providers.

   Package Functions
   One of the most important features of Salt is package management. There
   is no shortage of package managers, so in the interest of  providing  a
   consistent  experience  in pkg states, there are certain functions that
   should be present in a package provider. Note that these are subject to
   change as new features are added or existing features are enhanced.

   list_pkgs
   This function should declare an empty dict, and then add packages to it
   by calling pkg_resource.add_pkg, like so:

      __salt__['pkg_resource.add_pkg'](ret, name, version)

   The last thing that should be  done  before  returning  is  to  execute
   pkg_resource.sort_pkglist. This function does not presently do anything
   to the return dict, but will be used in future versions of Salt.

      __salt__['pkg_resource.sort_pkglist'](ret)

   list_pkgs returns a dictionary of installed  packages,  with  the  keys
   being  the  package  names  and the values being the version installed.
   Example return data:

      {'foo': '1.2.3-4',
       'bar': '5.6.7-8'}

   latest_version
   Accepts an arbitrary number of arguments. Each argument  is  a  package
   name.  The  return  value  for a package will be an empty string if the
   package is not found or if the package is up-to-date. The only case  in
   which a non-empty string is returned is if the package is available for
   new installation (i.e. not already installed) or if there is an upgrade
   available.

   If  only  one  argument  was  passed,  this  function  return a string,
   otherwise a dict of name/version pairs is returned.

   This function must also  accept  **kwargs,  in  order  to  receive  the
   fromrepo  and  repo keyword arguments from pkg states. Where supported,
   these arguments should be used to find the install/upgrade candidate in
   the  specified  repository.  The  fromrepo  kwarg takes precedence over
   repo, so if both of those kwargs are present, the repository  specified
   in  fromrepo  should  be  used.  However,  if  repo  is used instead of
   fromrepo, it should still work,  to  preserve  backwards  compatibility
   with older versions of Salt.

   version
   Like  latest_version,  accepts  an  arbitrary  number  of arguments and
   returns a string if a single package name was  passed,  or  a  dict  of
   name/value  pairs  if  more than one was passed. The only difference is
   that the return values are the currently-installed versions of whatever
   packages  are  passed. If the package is not installed, an empty string
   is returned for that package.

   upgrade_available
   Deprecated and destined to be removed. For  now,  should  just  do  the
   following:

      return __salt__['pkg.latest_version'](name) != ''

   install
   The following arguments are required and should default to None:

   1. name (for single-package pkg states)

   2. pkgs (for multiple-package pkg states)

   3. sources (for binary package file installation)

   The    first   thing   that   this   function   should   do   is   call
   pkg_resource.parse_targets (see below). This function will convert  the
   SLS    input    into    a    more   easily   parsed   data   structure.
   pkg_resource.parse_targets may need to be modified to support your  new
   package provider, as it does things like parsing package metadata which
   cannot be done for every package management system.

      pkg_params, pkg_type = __salt__['pkg_resource.parse_targets'](name,
                                                                    pkgs,
                                                                    sources)

   Two values will be returned to the install function. The first of  them
   will  be  a  dictionary.  The  keys  of this dictionary will be package
   names, though  the  values  will  differ  depending  on  what  kind  of
   installation is being done:

   * If  name was provided (and pkgs was not), then there will be a single
     key in the dictionary, and its value will be None. Once the data  has
     been  returned, if the version keyword argument was provided, then it
     should replace the None value in the dictionary.

   * If pkgs was provided, then name is ignored, and the  dictionary  will
     contain  one  entry  for each package in the pkgs list. The values in
     the dictionary will be None if a version was not  specified  for  the
     package,  and  the  desired  version  if  specified. See the Multiple
     Package Installation Options section of the pkg.installed  state  for
     more info.

   * If  sources  was  provided,  then name is ignored, and the dictionary
     values will be the path/URI for the package.

   The second return value will be a  string  with  two  possible  values:
   repository  or  file.  The  install  function  can  use  this value (if
   necessary)  to  build  the  proper  command  to  install  the  targeted
   package(s).

   Both  before  and  after  the  installing the target(s), you should run
   list_pkgs to obtain a list of the installed packages. You  should  then
   return the output of salt.utils.compare_dicts()

      return salt.utils.compare_dicts(old, new)

   remove
   Removes the passed package and return a list of the packages removed.

   Package Repo Functions
   There  are some functions provided by pkg which are specific to package
   repositories, and not to packages themselves. When writing modules  for
   new  package  managers,  these  functions  should  be made available as
   stated below, in order to provide compatibility with the pkgrepo state.

   All repo functions should accept a basedir option, which defines  which
   directory  repository configuration should be found in. The default for
   this is dictated by the repo manager that is  being  used,  and  rarely
   needs to be changed.

      basedir = '/etc/yum.repos.d'
      __salt__['pkg.list_repos'](basedir)

   list_repos
   Lists the repositories that are currently configured on this system.

      __salt__['pkg.list_repos']()

   Returns a dictionary, in the following format:

      {'reponame': 'config_key_1': 'config value 1',
                   'config_key_2': 'config value 2',
                   'config_key_3': ['list item 1 (when appropriate)',
                                    'list item 2 (when appropriate)]}

   get_repo
   Displays all local configuration for a specific repository.

      __salt__['pkg.get_repo'](repo='myrepo')

   The information is formatted in much the same way as list_repos, but is
   specific to only one repo.

      {'config_key_1': 'config value 1',
       'config_key_2': 'config value 2',
       'config_key_3': ['list item 1 (when appropriate)',
                        'list item 2 (when appropriate)]}

   del_repo
   Removes the local configuration for a specific repository.  Requires  a
   repo  argument,  which  must  match  the  locally configured name. This
   function returns a string, which informs the user as to whether or  not
   the operation was a success.

      __salt__['pkg.del_repo'](repo='myrepo')

   mod_repo
   Modify  the local configuration for one or more option for a configured
   repo.  This is also the way to create new repository  configuration  on
   the  local  system; if a repo is specified which does not yet exist, it
   will be created.

   The options specified for this function are  specific  to  the  system;
   please  refer  to  the documentation for your specific repo manager for
   specifics.

      __salt__['pkg.mod_repo'](repo='myrepo', url='http://myurl.com/repo')

   Low-Package Functions
   In general, the standard package functions as describes above will meet
   your  needs.  These functions use the system's native repo manager (for
   instance, yum or the apt tools). In most cases,  the  repo  manager  is
   actually  separate  from  the  package  manager.  For  instance, yum is
   usually a front-end for rpm, and apt is usually a front-end  for  dpkg.
   When  possible,  the  package functions that use those package managers
   directly should do so through the low package functions.

   It is normal and sane for pkg to make calls to lowpkgs, but lowpkg must
   never  make  calls to pkg. This is affects functions which are required
   by both pkg and lowpkg, but the technique in  pkg  is  more  performant
   than  what  is  available  to lowpkg. When this is the case, the lowpkg
   function that  requires  that  technique  must  still  use  the  lowpkg
   version.

   list_pkgs
   Returns  a  dict  of packages installed, including the package name and
   version.  Can accept a list of packages; if none  are  specified,  then
   all installed packages will be listed.

      installed = __salt__['lowpkg.list_pkgs']('foo', 'bar')

   Example output:

      {'foo': '1.2.3-4',
       'bar': '5.6.7-8'}

   verify
   Many  (but  not all) package management systems provide a way to verify
   that the files installed by  the  package  manager  have  or  have  not
   changed.  This  function  accepts  a  list  of  packages;  if  none are
   specified, all packages will be included.

      installed = __salt__['lowpkg.verify']('httpd')

   Example output:

      {'/etc/httpd/conf/httpd.conf': {'mismatch': ['size', 'md5sum', 'mtime'],
                                      'type': 'config'}}

   file_list
   Lists all of the files installed by  all  packages  specified.  If  not
   packages  are  specified,  then  all  files  for all known packages are
   returned.

      installed = __salt__['lowpkg.file_list']('httpd', 'apache')

   This function does not return which files belong to which packages; all
   files  are  returned  as  one  giant list (hence the file_list function
   name. However, This information is still returned inside of a dict,  so
   that it can provide any errors to the user in a sane manner.

      {'errors': ['package apache is not installed'],
        'files': ['/etc/httpd',
                  '/etc/httpd/conf',
                  '/etc/httpd/conf.d',
                  '...SNIP...']}

   file_dict
   Lists  all  of  the  files  installed by all packages specified. If not
   packages are specified, then all  files  for  all  known  packages  are
   returned.

      installed = __salt__['lowpkg.file_dict']('httpd', 'apache', 'kernel')

   Unlike  file_list,  this function will break down which files belong to
   which packages. It will also  return  errors  in  the  same  manner  as
   file_list.

      {'errors': ['package apache is not installed'],
       'packages': {'httpd': ['/etc/httpd',
                              '/etc/httpd/conf',
                              '...SNIP...'],
                    'kernel': ['/boot/.vmlinuz-2.6.32-279.el6.x86_64.hmac',
                               '/boot/System.map-2.6.32-279.el6.x86_64',
                               '...SNIP...']}}

   Reporting Bugs
   Salt uses GitHub to track open issues and feature requests.

   To  file  a  bug,  please  navigate  to the new issue page for the Salt
   project.

   In an issue report, please include the following information:

      * The output of salt --versions-report from the  relevant  machines.
        This  can  also  be  gathered  remotely  by  using  salt  <my_tgt>
        test.versions_report.

      * A description of the problem including steps taken  to  cause  the
        issue to occur and the expected behaviour.

      * Any steps taken to attempt to remediate the problem.

      * Any  configuration options set in a configuration file that may be
        relevant.

      * A reproduceable test case. This may be as simple as  an  SLS  file
        that  illustrates  a  problem  or it may be a link to a repository
        that contains a number of SLS files that can be used  together  to
        re-produce   a   problem.   If  the  problem  is  transitory,  any
        information that can be used to try and reproduce the  problem  is
        helpful.

      * [Optional]  The  output of each salt component (master/minion/CLI)
        running with the -ldebug flag set.

      NOTE:
          Please be certain to scrub any logs or SLS files  for  sensitive
          data!

   Salt Topology
   Salt  is  based  on  a  powerful,  asynchronous, network topology using
   ZeroMQ. Many ZeroMQ systems are in place to enable  communication.  The
   central idea is to have the fastest communication possible.

   Servers
   The  Salt  Master  runs  2  network  services.  First is the ZeroMQ PUB
   system. This service by default runs on port 4505 and can be configured
   via the publish_port option in the master configuration.

   Second  is the ZeroMQ REP system. This is a separate interface used for
   all bi-directional communication with minions. By default  this  system
   binds to port 4506 and can be configured via the ret_port option in the
   master.

   PUB/SUB
   The commands sent out via the salt client  are  broadcast  out  to  the
   minions  via  ZeroMQ  PUB/SUB.  This is done by allowing the minions to
   maintain a connection back to the Salt Master and then all  connections
   are  informed to download the command data at once. The command data is
   kept extremely small (usually less than 1K) so it is not  a  burden  on
   the network.

   Return
   The  PUB/SUB  system  is  a one way communication, so once a publish is
   sent out the PUB interface on the master has no  further  communication
   with the minion.  The minion, after running the command, then sends the
   command's return data back to the master via the ret_port.

   Translating Documentation
   If you wish to help translate the Salt documentation to your  language,
   please head over to the Transifex website and signup for an account.

   Once  registered, head over to the Salt Translation Project, and either
   click on Request Language if you  can't  find  yours,  or,  select  the
   language for which you wish to contribute and click Join Team.

   Transifex  provides  some  useful  reading  resources  on their support
   domain, namely, some useful articles directed to translators.

   Building A Localized Version of the Documentation
   While you're working on your translation on Transifex, you  might  want
   to have a look at how it's rendering.

   Install The Transifex Client
   To interact with the Transifex web service you will need to install the
   transifex-client:

      pip install transifex-client

   Configure The Transifex Client
   Once installed, you will need to set it up on your computer. We created
   a script to help you with that:

      .scripts/setup-transifex-config

   Download Remote Translations
   There's  a  little  script which simplifies the download process of the
   translations(which isn't that complicated in  the  first  place).   So,
   let's   assume   you're  translating  pt_PT,  Portuguese(Portugal).  To
   download the translations, execute from the doc/ directory of your Salt
   checkout:

      make download-translations SPHINXLANG=pt_PT

   To download pt_PT, Portuguese(Portugal), and nl, Dutch, you can use the
   helper script directly:

      .scripts/download-translation-catalog pt_PT nl

   Build Localized Documentation
   After the download process finishes, which might take a while, the next
   step  is  to build a localized version of the documentation.  Following
   the pt_PT example above:

      make html SPHINXLANG=pt_PT

   View Localized Documentation
   Open your browser, point it to the local documentation path  and  check
   the localized output you've just build.

   Developing Salt Tutorial
   This tutorial assumes you have:

   * a web browser

   * a GitHub account (<my_account>)

   * a command line (CLI)

   * git

   * a text editor

   Fork
   In your browser, navigate to the saltstack/salt GitHub repository.

   Click                    on                   Fork                   (
   https://github.com/saltstack/salt/#fork-destination-box).

   NOTE:
      If you have more than one GitHub presence, for example if you are  a
      member of a team, GitHub will ask you into which area to clone Salt.
      If you don't know where, then select your personal GitHub account.

   Clone
   In your CLI, navigate to the directory into which you  want  clone  the
   Salt codebase and submit the following command:

      $ git clone https://github.com/<my_account>/salt.git

   where <my_account> is the name of your GitHub account.  After the clone
   has completed, add SaltStack as a second remote and fetch  any  changes
   from upstream.

      $ cd salt
      $ git remote add upstream https://github.com/saltstack/salt.git
      $ git fetch upstream

   For  this  tutorial,  we  will  be working off from the develop branch,
   which is the default branch for the  SaltStack  GitHub  project.   This
   branch needs to track upstream/develop so that we will get all upstream
   changes when they happen.

      $ git checkout develop
      $ git branch --set-upstream-to upstream/develop

   Fetch
   Fetch any upstream changes on the develop branch and sync them to  your
   local copy of the branch with a single command:

      $ git pull --rebase

   NOTE:
      For  an  explanation  on  pull  vs pull --rebase and other excellent
      points, see this article by Mislav Marohni.

   Branch
   Now we are ready to get to work.  Consult the sprint beginner bug  list
   and  select  an execution module whose __virtual__ function needs to be
   updated.  I'll select the alternatives module.

   Create a new branch off from develop.  Be sure  to  name  it  something
   short and descriptive.

      $ git checkout -b virt_ret

   Edit
   Edit  the  file  you  have  selected,  and  verify that the changes are
   correct.

      $ vim salt/modules/alternatives.py
      $ git diff
      diff --git a/salt/modules/alternatives.py b/salt/modules/alternatives.py
      index 1653e5f..30c0a59 100644
      --- a/salt/modules/alternatives.py
      +++ b/salt/modules/alternatives.py
      @@ -30,7 +30,7 @@ def __virtual__():
               '''
               if os.path.isdir('/etc/alternatives'):
                       return True
      -        return False
      +        return (False, 'Cannot load alternatives module: /etc/alternatives dir not found')

       def _get_cmd():

   Commit
   Stage and commit the changes.  Write a descriptive commit summary,  but
   try to keep it less than 50 characters.  Review your commit.

      $ git add salt/modules/alternatives.py
      $ git commit -m 'modules.alternatives: __virtual__ return err msg'
      $ git show

   NOTE:
      If  you  need  more room to describe the changes in your commit, run
      git commit (without  the  -m,  message,  option)  and  you  will  be
      presented  with an editor.  The first line is the commit summary and
      should still be 50 characters or less.  The following paragraphs you
      create are free form and will be preserved as part of the commit.

   Push
   Push your branch to your GitHub account.  You will likely need to enter
   your GitHub username and password.

      $ git push origin virt_ret
      Username for 'https://github.com': <my_account>
      Password for 'https://<my_account>@github.com':

   NOTE:
      If authentication over https does not work,  you  can  alternatively
      setup  ssh keys.  Once you have done this, you may need add the keys
      to your git repository configuration

          $ git config ssh.key ~/.ssh/<key_name>

      where <key_name> is the file name of the private key you created.

   Merge
   In your  browser,  navigate  to  the  new  pull  request  page  on  the
   saltstack/salt  GitHub  repository  and  click on compare across forks.
   Select <my_account> from the list of head forks and the branch you  are
   wanting to merge into develop (virt_ret in this case).

   When  you  have  finished  reviewing  the  changes,  click  Create pull
   request.

   If your pull request contains only  a  single  commit,  the  title  and
   comment will be taken from that commit's summary and message, otherwise
   the branch name is used for the title.  Edit these fields as  necessary
   and click Create pull request.

   NOTE:
      Although  these  instructions  seem  to be the official pull request
      procedure on github's website, here are two alternative methods that
      are simpler.

      * If     you     navigate     to     your     clone     of     salt,
        https://github.com/<my_account>/salt, depending on  how  old  your
        branch  is  or  how  recently you pushed updates on it, you may be
        presented with a button to create a pull request with your branch.

      * I find it easiest to edit the following URL:

        https://github.com/saltstack/salt/compare/develop...<my_account>:virt_ret

   Resources
   GitHub  offers  many great tutorials on various aspects of the git- and
   GitHub-centric development workflow:

   https://help.github.com/

   There are many topics covered by the Salt Developer documentation:

   https://docs.saltstack.com/en/latest/topics/development/index.html

   The  contributing  documentation  presents  more  details  on  specific
   contributing topics:

   https://docs.saltstack.com/en/latest/topics/development/contributing.html

   Salt Extend
   salt-extend is a templating tool for  extending  SaltStack.  If  you're
   looking  to add a module to SaltStack, then the salt-extend utility can
   guide you through the process.

   You can use Salt Extend to quickly create templated modules for  adding
   new behaviours to some of the module subsystems within Salt.

   Salt  Extend  takes a template directory and merges it into a SaltStack
   source code directory.

   Command line usage
   See salt-extend

   Choosing a template
   The following templates are available:

   module
   Creates a new execution module within salt/modules/{{module_name}}.py

   module_unit
   Creates   a   new   execution   module   unit   test    suite    within
   tests/unit/modules/{{module_name}}_test.py

   state
   Creates a new state module within salt/states/{{module_name}}.py

   state_unit
   Creates    a    new    state    module    unit    test   suite   within
   tests/unit/states/{{module_name}}_test.py

   Adding templates
   1. Create a directory under <src>/templates

   2. Create a file template.yml containing properties for

      * description - a description of the template

      * questions - a collection of additional questions to ask the  user,
        the  name  of  the  item  will  be  used as the key in the context
        dictionary within the jinja template.

        * question - The question to ask the user, as a string

        * default - (optional)  the  default  value,  can  contain  Jinja2
          template syntax and has access to the default context properties

   Example template.yml
      description: "Execution module"
      questions:
          depending_libraries:
              question: "What libraries does this module depend upon?"
          virtual_name:
              question: "What module virtual name to use?"
              default: "{{module_name}}"

   3. Create the files within <src>/templates/<your template> to match the
      target

   NOTE:
      File   names   can   contain   Jinja   2   template   syntax,   e.g.
      '{{module_name}}.py}}'

   Example file in the template directory
      print('Hello {{module_name}}')
      __virtual__ = '{{__virtual_name__}}'

   Default context properties
   The default context provides the following properties

   * description - A description of the template

   * short_description  -  A short description of the module as entered by
     the user

   * version - The version name of the next release

   * module_name - The module name as entered by the user

   * release_date - The current date in the format YYYY-MM-DD

   * year - The current year in the format YYYY

   As well as any additional properties entered from the questions section
   of template.yml

   API
   SaltStack Extend
   A templating tool for extending SaltStack.

   Takes  a  template directory and merges it into a SaltStack source code
   directory. This tool uses Jinja2 for templating.

   This tool is accessed using salt-extend

      codeauthor

             :email:`Anthony Shaw <[email protected]>`

   salt.utils.extend.apply_template(template_dir, output_dir, context)
          Apply the template from the template  directory  to  the  output
          using the supplied context dict.

          Parameters

                 * src (str) -- The source path

                 * dst (str) -- The destination path

                 * context  (dict)  --  The  dictionary to inject into the
                   Jinja template as context

   salt.utils.extend.run(extension=None,   name=None,    description=None,
   salt_dir=None, merge=False, temp_dir=None)
          A template factory for extending the salt ecosystem

          Parameters

                 * extension  (str)  -- The extension type, e.g. 'module',
                   'state', if omitted, user will be prompted

                 * name (str) -- Python-friendly name for the  module,  if
                   omitted, user will be prompted

                 * description (str) -- A description of the extension, if
                   omitted, user will be prompted

                 * salt_dir (str) -- The targeted Salt source directory

                 * merge (bool) -- Merge with  salt  directory,  False  to
                   keep seperate, True to merge trees.

                 * temp_dir  (str) -- The directory for generated code, if
                   omitted, system temp will be used

   Salt's Test Suite
   Salt comes with a powerful integration and unit test suite allowing for
   the  fully automated run of integration and/or unit tests from a single
   interface.

   To learn the basics of how Salt's test suite works, be  sure  to  check
   out the Salt's Test Suite: An Introduction tutorial.

   Test Directory Structure
   Salt's  test  suite  is  located  in the tests directory in the root of
   Salt's codebase. The test suite is divided into two main groups:

   * Integration Tests

   * Unit Tests

   Within each of these groups, the directory  structure  roughly  mirrors
   the structure of Salt's own codebase. Notice that there are directories
   for states, modules, runners, output, and more in each testing group.

   The files that are housed in the modules directory of either  the  unit
   or  the  integration testing factions contain respective integration or
   unit test files for Salt execution modules.

   Integration Tests
   The Integration section of Salt's test suite start up a number of  Salt
   daemons  to  test  functionality  in  a live environment. These daemons
   include two Salt Masters, one Syndic, and two Minions. This allows  the
   Syndic  interface  to  be  tested and Master/Minion communication to be
   verified. All of the  integration  tests  are  executed  as  live  Salt
   commands sent through the started daemons.

   Integration tests are particularly good at testing modules, states, and
   shell commands, among other segments of Salt's ecosystem. By  utilizing
   the integration test daemons, integration tests are easy to write. They
   are also SaltStack's generally preferred method of adding new tests.

   The discussion in the Integration  vs.  Unit  section  of  the  testing
   tutorial  is  beneficial  in  learning  why  you  might  want  to write
   integration tests vs. unit tests. Both  testing  arenas  add  value  to
   Salt's test suite and you should consider adding both types of tests if
   possible and appropriate when contributing to Salt.

   * Integration Test Documentation

   Unit Tests
   Unit tests do not spin up any Salt  daemons,  but  instead  find  their
   value  in  testing  singular  implementations  of individual functions.
   Instead of testing against specific interactions, unit tests should  be
   used  to  test  a  function's  logic  as  well  as any return or raises
   statements.   Unit  tests  also  rely  heavily  on   mocking   external
   resources.

   The  discussion  in  the  Integration  vs.  Unit section of the testing
   tutorial is useful in determining when you should consider writing unit
   tests   instead   of,   or  in  addition  to,  integration  tests  when
   contributing to Salt.

   * Unit Test Documentation

   Running The Tests
   There are requirements, in addition to Salt's requirements, which  need
   to  be  installed  in  order  to run the test suite. Install one of the
   lines below, depending on the relevant Python version:

      pip install -r requirements/dev_python26.txt
      pip install -r requirements/dev_python27.txt

   NOTE:
      In Salt 0.17, testing libraries were migrated into their  own  repo.
      To install them:

          pip install git+https://github.com/saltstack/salt-testing.git#egg=SaltTesting

      Failure  to install SaltTesting will result in import errors similar
      to the following:

          ImportError: No module named salttesting

   Once all requirements are installed, use tests/runtests.py to  run  all
   of the tests included in Salt's test suite:

      python tests/runtests.py

   For  more  information  about options you can pass the test runner, see
   the --help option:

      python tests/runtests.py --help

   An alternative way of invoking the test suite is available in setup.py:

      ./setup.py test

   Running Test Subsections
   Instead of running the entire test suite all at once, which can take  a
   long  time, there are several ways to run only specific groups of tests
   or individual tests:

   * Run unit tests only: ./tests/runtests.py --unit-tests

   * Run  unit  and  integration  tests  for  states:  ./tests/runtests.py
     --state

   * Run  integration  tests for an individual module: ./tests/runtests.py
     -n integration.modules.virt

   * Run unit tests  for  an  individual  module:  ./tests/runtests.py  -n
     unit.modules.virt_test

   * Run an individual test by using the class and test name (this example
     is    for    the     test_default_kvm_profile     test     in     the
     integration.module.virt):            ./tests/runtests.py           -n
     integration.module.virt.VirtTest.test_default_kvm_profile

   For more specific examples of how to run various  test  subsections  or
   individual  tests,  please see the Test Selection Options documentation
   or the Running Specific Tests section of  the  Salt's  Test  Suite:  An
   Introduction tutorial.

   Running Unit Tests Without Integration Test Daemons
   Since  the  unit tests do not require a master or minion to execute, it
   is often useful to be able to run unit  tests  individually,  or  as  a
   whole  group,  without  having  to  start  up  the  integration testing
   daemons. Starting up the master, minion, and syndic daemons takes a lot
   of  time  before the tests can even start running and is unnecessary to
   run unit tests. To run unit tests without invoking the integration test
   daemons, simple remove the /tests portion of the runtests.py command:

      ./runtests.py --unit

   All  of  the  other  options to run individual tests, entire classes of
   tests, or entire test modules still apply.

   Running Destructive Integration Tests
   Salt is used to change the settings and behavior of systems.  In  order
   to  effectively  test  Salt's functionality, some integration tests are
   written to make actual changes to the underlying  system.  These  tests
   are  referred  to  as "destructive tests". Some examples of destructive
   tests are changes may be testing the addition of a user  or  installing
   packages.  By  default,  destructive  tests  are  disabled  and will be
   skipped.

   Generally, destructive  tests  should  clean  up  after  themselves  by
   attempting  to  restore the system to its original state. For instance,
   if a new user is created during a test,  the  user  should  be  deleted
   after  the  related  test(s) have completed. However, no guarantees are
   made that test clean-up will complete successfully. Therefore,  running
   destructive tests should be done with caution.

   NOTE:
      Running  destructive  tests  will  change the underlying system. Use
      caution when running destructive tests.

   To run tests marked as destructive, set the --run-destructive flag:

      ./tests/runtests.py --run-destructive

   Running Cloud Provider Tests
   Salt's testing suite also includes  integration  tests  to  assess  the
   successful  creation  and  deletion of cloud instances using Salt-Cloud
   for providers supported by Salt-Cloud.

   The cloud  provider  tests  are  off  by  default  and  run  on  sample
   configuration               files              provided              in
   tests/integration/files/conf/cloud.providers.d/. In order  to  run  the
   cloud  provider  tests,  valid  credentials, which differ per provider,
   must be supplied.  Each  credential  item  that  must  be  supplied  is
   indicated  by  an  empty  string value and should be edited by the user
   before running the tests. For example, DigitalOcean requires  a  client
   key  and  an  api key to operate. Therefore, the default cloud provider
   configuration file for DigitalOcean looks like this:

      digitalocean-config:
        driver: digital_ocean
        client_key: ''
        api_key: ''
        location: New York 1

   As indicated by the empty string values, the client_key and the api_key
   must be provided:

      digitalocean-config:
        driver: digital_ocean
        client_key: wFGEwgregeqw3435gDger
        api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
        location: New York 1

   NOTE:
      When    providing   credential   information   in   cloud   provider
      configuration files, do not include the single quotes.

   Once all of the valid credentials for  the  cloud  provider  have  been
   supplied,   the  cloud  provider  tests  can  be  run  by  setting  the
   --cloud-provider-tests flag:

      ./tests/runtests.py --cloud-provider-tests

   Running The Tests In A Docker Container
   The test suite can be executed  under  a  docker  container  using  the
   --docked  option flag. The docker container must be properly configured
   on the system invoking the tests and the container must have access  to
   the internet.

   Here's a simple usage example:

      tests/runtests.py --docked=ubuntu-12.04 -v

   The full docker container repository can also be provided:

      tests/runtests.py --docked=salttest/ubuntu-12.04 -v

   The  SaltStack  team  is  creating  some containers which will have the
   necessary dependencies pre-installed.  Running  the  test  suite  on  a
   container allows destructive tests to run without making changes to the
   main system. It also enables the test suite to run  under  a  different
   distribution than the one the main system is currently using.

   The current list of test suite images is on Salt's docker repository.

   Custom  docker  containers can be provided by submitting a pull request
   against Salt's docker Salt test containers repository.

   Automated Test Runs
   SaltStack maintains a Jenkins server to  allow  for  the  execution  of
   tests  across  supported  platforms.  The  tests  executed  from Salt's
   Jenkins server create fresh virtual machines for each  test  run,  then
   execute destructive tests on the new, clean virtual machine.

   SaltStack's  Jenkins  server  continuously  runs the entire test suite,
   including destructive tests, on an array of various supported operating
   systems  throughout  the  day. Each actively supported branch of Salt's
   repository runs the tests located in the respective branch's code. Each
   set of branch tests also includes a pylint run. These branch tests help
   ensure the viability of Salt code at any given point in  time  as  pull
   requests are merged into branches throughout the day.

   In addition to branch tests, SaltStack's Jenkins server also runs tests
   on pull requests. These pull request tests include  a  smaller  set  of
   virtual  machines that run on the branch tests. The pull request tests,
   like the branch tests, include a pylint test as well.

   When a pull request is submitted to Salt's repository  on  GitHub,  the
   suite  of  pull  request  tests are started by Jenkins. These tests are
   used to gauge  the  pull  request's  viability  to  merge  into  Salt's
   codebase. If these initial tests pass, the pull request can then merged
   into the Salt branch by one of Salt's core  developers,  pending  their
   discretion.  If  the  initial  tests  fail, core developers may request
   changes to the pull request. If the failure is unrelated to the changes
   in  question,  core  developers  may merge the pull request despite the
   initial failure.

   As soon as the pull request is merged, the changes will be added to the
   next branch test run on Jenkins.

   For  a  full  list  of  currently  running  test  environments,  go  to
   http://jenkins.saltstack.com.

   Using Salt-Cloud on Jenkins
   For testing Salt on Jenkins,  SaltStack  uses  Salt-Cloud  to  spin  up
   virtual  machines.  The  script  using Salt-Cloud to accomplish this is
   open       source       and       can       be       found        here:
   https://github.com/saltstack/salt/blob/develop/tests/jenkins.py

   Writing Tests
   The  salt  testing infrastructure is divided into two classes of tests,
   integration  tests  and  unit  tests.  These  terms  may   be   defined
   differently in other contexts, but for Salt they are defined this way:

   * Unit  Test:  Tests  which  validate  isolated  code blocks and do not
     require external interfaces such as salt-call  or  any  of  the  salt
     daemons.

   * Integration   Test:   Tests   which  validate  externally  accessible
     features.

   Salt testing uses  unittest2  from  the  python  standard  library  and
   MagicMock.

   * Writing integration tests

   * Writing unit tests

   Naming Conventions
   Any  function  in either integration test files or unit test files that
   is doing the actual testing, such as functions  containing  assertions,
   must start with test_:

      def test_user_present(self):

   When functions in test files are not prepended with test_, the function
   acts as a normal, helper function and is not run as a test by the  test
   suite.

   Submitting New Tests
   Which  branch of the Salt codebase should new tests be written against?
   The location of where new tests should be submitted depends largely  on
   the reason you're writing the tests.

   Tests for New Features
   If you are adding new functionality to Salt, please write the tests for
   this new feature in the same pull  request  as  the  new  feature.  New
   features should always be submitted to the develop branch.

   If  you have already submitted the new feature, but did not write tests
   in the original pull request that has already been merged, please  feel
   free  to submit a new pull request containing tests. If the feature was
   recently added to Salt's develop branch, then the tests should be added
   there  as  well. However, if the feature was added to develop some time
   ago and is already present in one  or  more  release  branches,  please
   refer to the Tests for Entire Files or Functions section below for more
   details about where to submit tests for functions or files that do  not
   already have tests.

   Tests to Accompany a Bugfix
   If  you  are  writing  tests  for code that fixes a bug in Salt, please
   write the test in the same pull request as the bugfix. If you're unsure
   of where to submit your bugfix and accompanying test, please review the
   Which Salt Branch? documentation in Salt's Contributing guide.

   Tests for Entire Files or Functions
   Sometimes entire files in Salt are  completely  untested.  If  you  are
   writing  tests  for  a file that doesn't have any tests written for it,
   write your test against the  earliest  supported  release  branch  that
   contains the file or function you're testing.

   Once  your tests are submitted in a pull request and is merged into the
   branch in question, the tests  you  wrote  will  be  merged-forward  by
   SaltStack  core engineers and the new tests will propagate to the newer
   release branches. That way the  tests  you  wrote  will  apply  to  all
   current and relevant release branches, and not just the develop branch,
   for example. This methodology will help protect against regressions  on
   older files in Salt's codebase.

   There  may  be  times  when the tests you write against an older branch
   fail in the merge-forward process because functionality has changed  in
   newer  release  branches.   In  these  cases, a Salt core developer may
   reach out to you for advice on  the  tests  in  question  if  the  path
   forward is unclear.

   NOTE:
      If  tests  are written against a file in an older release branch and
      then merged forward, there may be new functionality in the file that
      is  present  in  the new release branch that is untested.It would be
      wise to see if new functionality could use additional  testing  once
      the test file has propagated to newer release branches.

   raet
   # RAET # Reliable Asynchronous Event Transport Protocol

   SEE ALSO:
      RAET Overview

   Protocol
   Layering:

   OSI Layers

   7:  Application: Format: Data (Stack to Application interface buffering
   etc) 6: Presentation: Format: Data (Encrypt-Decrypt convert to  machine
   independent format) 5: Session: Format: Data (Interhost communications.
   Authentication.  Groups)  4:  Transport:  Format:  Segments   (Reliable
   delivery  of  Message,  Transactions,  Segmentation, Error checking) 3:
   Network:  Format:  Packets/Datagrams  (Addressing  Routing)  2:   Link:
   Format:  Frames  (  Reliable per frame communications connection, Media
   access  controller  )  1:  Physical:  Bits  (Transceiver  communication
   connection not reliable)

   Link  is  hidden  from  Raet  Network  is  IP host address and Udp Port
   Transport is Raet transactions,  service  kind,  tail  error  checking,
   Could  include  header  signing  as part of transport reliable delivery
   serialization of header Session is session id key exchange for signing.
   Grouping  is  Road  (like  852 channel) Presentation is Encrypt Decrypt
   body Serialize Deserialize Body Application is body data dictionary

   Header signing spans both the Transport and Session layers.

   Header
   JSON Header (Tradeoff some processing speed for extensibility, ease  of
   use, readability)

   Body initially JSON but support for "packed" binary body

   Packet
   Header  ASCII  Safe JSON Header termination: Empty line given by double
   pair of carriage return linefeed /r/n/r/n 10 13 10 13  ADAD  1010  1101
   1010 1101

   In  json carriage return and newline characters cannot appear in a json
   encoded string unless they are escaped with backslash, so  the  4  byte
   combination  is  illegal  in  valid  json that does not have multi-byte
   unicode characters.

   These means the header must  be  ascii  safe   so  no  multibyte  utf-8
   strings allowed in header.

   Following Header Terminator is variable length signature block. This is
   binary and the length is provided in the header.

   Following the signature block is the packet body  or  data.   This  may
   either  be  JSON  or  packed  binary.   The format is given in the json
   header

   Finally is an optional tail block  for  error  checking  or  encryption
   details

   Header Fields
   In UDP header

   sh  =  source  host  sp  =  source  port  dh  =  destination  host dp =
   destination port

   In RAET Header

   hk = header kind hl = header length

   vn = version number

   sd = Source Device ID dd = Destination Device ID cf = Corresponder Flag
   mf = Multicast Flag

   si = Session ID ti = Transaction ID

   sk  = Service Kind pk = Packet Kind bf = Burst Flag  (Send all Segments
   or Ordered packets without interleaved acks)

   oi = Order Index dt = DateTime Stamp

   sn = Segment Number sc = Segment Count

   pf = Pending Segment Flag af = All Flag   (Resent all Segments not just
   one)

   nk = Auth header kind nl = Auth header length

   bk = body kind bl = body length

   tk = tail kind tl = tail length

   fg = flags packed (Flags) Default '00' hex string
          2  byte Hex string with bits (0, 0, af, pf, 0, bf, mf, cf) Zeros
          are TBD flags

   Session Bootstrap
   Minion sends packet with SID of Zero with public key of minions  Public
   Private Key pair Master acks packet with SID of Zero to let minion know
   it received the request

   Some time later Master sends packet with SID of zero that  accepts  the
   Minion

   Minion

   Session
   Session  is  important  for  security. Want one session opened and then
   multiple transactions within session.

   Session ID SID sid

   GUID hash to guarantee uniqueness since  no  guarantee  of  nonvolatile
   storage or require file storage to keep last session ID used.

   Service Types or Modular Services
   Four Service Types

   A. One or more maybe (unacknowledged repeat) maybe means no guarantee

   B.

      Exactly   one  at  most  (ack  with  retries)  (duplicate  detection
      idempotent)
             at most means fixed number of retries has finite  probability
             of  failing  B1)  finite  retries  B2)  infinite retries with
             exponential back-off up to a maximum delay

   C.

      Exactly one of sequence at most (sequence numbered)
             Receiver requests retry of missing packet with same B1 or  B2
             retry type

   D.

      End to End (Application layer Request Response)
             This is two B sub transactions

   Initially unicast messaging Eventually support for Multicast

   The  use  case for C) is to fragment large packets as once a UDP packet
   exceeds the frame size its  reliability  goes  way  down  So  its  more
   reliable to fragment large packets.

   Better approach might be to have more modularity.  Services Levels

      1.

         Maybe one or more

                A.

                   Fire and forget
                          no transaction either side

                B.

                   Repeat, no ack, no dupdet
                          repeat  counter  send  side,  no  transaction on
                          receive side

                C.

                   Repeat, no Ack, dupdet
                          repeat  counter   send   side,   dup   detection
                          transaction receive side

      2.

         More or Less Once

                A.

                   retry finite, ack no dupdet
                          retry  timer send side, finite number of retires
                          ack receive side no dupdet

      3.

         At most Once

                A.

                   retry finite, ack, dupdet
                          retry timer send side, finite number of  retires
                          ack receive side dupdet

      4.

         Exactly once

                A.

                   ack retry
                          retry   timer   send  side,  ack  and  duplicate
                          detection receive  side  Infinite  retries  with
                          exponential backoff

      5.

         Sequential sequence number

                A. reorder escrow

                B. Segmented packets

      6. request response to application layer

   Service Features

   1. repeats

   2. ack retry transaction id

   3. sequence   number   duplicate  detection   out  of  order  detection
      sequencing

   4. rep-req

   Always include transaction id since multiple transactions on same  port
   So  get  duplicate  detection for free if keep transaction alive but if
   use

   A) Maybe one or more B1) At  Least  One  B2)  Exactly  One  C)  One  of
   sequence D) End to End

   A)  Sender  creates  transaction  id for number of repeats but receiver
   does not keep transaction alive

   B1) Sender creates transaction id   keeps  it  for  retries.   Receiver
   keeps  it  to  send  ack  then  kills  so  retry could be duplicate not
   detected

   B2) Sender creates transaction id keeps for retries Receiver keeps  tid
   for acks on any retires so no duplicates.

   C)  Sender creates TID and Sequence Number.  Receiver checks for out of
   order sequence and can request retry.

   D) Application  layer  sends  response.  So  question  is  do  we  keep
   transaction  open  or have response be new transaction. No because then
   we need a rep-req ID so might as well use the same transaction id. Just
   keep alive until get response.

   Little advantage to B1 vs B2 not having duplicates.

   So 4 service types

   A. Maybe one or more (unacknowledged repeat)

   B. Exactly  One  (At  most  one)  (ack with retry) (duplicate detection
      idempotent)

   C. One of Sequence (sequence numbered)

   D. End to End

   Also multicast or unicast

   Modular Transaction Table

   Sender Side:
          Transaction  ID  plus  transaction  source  sender  or  receiver
          generated  transaction  id  Repeat  Counter  Retry  Timer  Retry
          Counter  (finite  retries)  Redo  Timer  (infinite  redos   with
          exponential  backoff)  Sequence  number  without  acks (look for
          resend requests) Sequence with ack (wait for ack before  sending
          next in sequence) Segmentation

   Receiver Side:
          Nothing  just  accept packet Acknowledge (can delete transaction
          after acknowledge) No duplicate  detection  Transaction  timeout
          (keep   transaction  until  timeout)  Duplicate  detection  save
          transaction id duplicate detection  timeout  Request  resend  of
          missing  packet  in  sequence  Sequence  reordering  with escrow
          timeout wait  escrow  before  requesting  resend  Unsegmentation
          (request resends of missing segment)

   SaltStack Git Policy
   The  SaltStack  team  follows  a  git  policy to maintain stability and
   consistency with the repository.

   The git policy has been developed to encourage contributions  and  make
   contributing  to  Salt  as  easy  as  possible.  Code  contributors  to
   SaltStack projects DO NOT NEED  TO  READ  THIS  DOCUMENT,  because  all
   contributions  come  into  SaltStack via a single gateway to make it as
   easy as possible for contributors to give us code.

   The primary rule of git management in SaltStack is to make life easy on
   contributors  and  developers  to  send in code. Simplicity is always a
   goal!

   New Code Entry
   All new SaltStack code should be submitted against either  the  develop
   branch  or  a  point  release  branch,  depending  on the nature of the
   submission. Please  see  the  Which  Salt  Branch?  section  of  Salt's
   Contributing  documentation  or  the  Release Branching section section
   below for more information.

   Release Branching
   SaltStack maintains two types of releases, Feature Releases  and  Point
   Releases  (also  commonly  referred  to  as  Bugfix Releases. A feature
   release is managed by incrementing the first or  second  release  point
   number,  so  2015.5.5  ->  2015.8.0  signifies  a  feature  release and
   2015.8.0 -> 2015.8.1 signifies a point release.

   Feature Release Branching
   Each feature release is maintained in a dedicated  git  branch  derived
   from  the  last  applicable release commit on develop. All file changes
   relevant to the feature release will be completed in the develop branch
   prior  to  the  creation  of  the  feature  release branch. The feature
   release branch will be named after the relevant numbers to the  feature
   release,  which  constitute  the first two numbers. This means that the
   release branch for the 2015.8.0 series is named 2015.8.

   A feature release branch is created with the following command:

      # git checkout -b 2015.8 # From the develop branch
      # git push origin 2015.8

   Point Releases
   Each  point  release  is  derived  from  its  parent  release   branch.
   Constructing  point  releases  is a critical aspect of Salt development
   and is managed by members of the core development team. Point  releases
   comprise  bug and security fixes. Bug fixes can be made against a point
   release branch in one of  two  ways:  the  bug  fix  can  be  submitted
   directly against the point release branch, or an attempt can be made to
   back-port the fix to the point release branch.

   Bug fixes should be made against the earliest supported release  branch
   on which the bug is present. The Salt development team regularly merges
   older point release branches forward into newer point release branches.
   That  way,  the  bug fixes that are submitted to older release branches
   can cascade up through all related release branches.

   For more information, please see the Which  Salt  Branch?   section  of
   Salt's Contributing documentation.

   Determining  when  a  point  release  is  going to be made is up to the
   project leader (Thomas Hatch). Generally point releases are made  every
   2-4 weeks or if there is a security fix they can be made sooner.

   The  point  release  is  only  designated  by tagging the commit on the
   release branch with a release  number  using  the  existing  convention
   (version  2015.8.1  is tagged with v2015.8.1). From the tag point a new
   source tarball is generated  and  published  to  PyPI,  and  a  release
   announcement is made.

   Salt Conventions
   Writing Salt Documentation
   Salt's documentation is built using the Sphinx documentation system. It
   can be built in a large variety of output formats including HTML,  PDF,
   ePub, and manpage.

   All  the  documentation  is  contained  in  the  main  Salt repository.
   Speaking broadly, most of  the  narrative  documentation  is  contained
   within      the      https://github.com/saltstack/salt/blob/develop/doc
   subdirectory and most of the reference and API documentation is written
   inline with Salt's Python code and extracted using a Sphinx extension.

   Style
   The Salt project recommends the IEEE style guide as a general reference
   for writing guidelines. Those guidelines are not strictly enforced  but
   rather  serve as an excellent resource for technical writing questions.
   The NCBI style guide is another very approachable resource.

   Point-of-view
   Use third-person perspective  and  avoid  "I",  "we",  "you"  forms  of
   address.   Identify  the  addressee  specifically e.g., "users should",
   "the compiler does", etc.

   Active voice
   Use active voice and present-tense. Avoid filler words.

   Title capitalization
   Document titles and section titles within a page should  follow  normal
   sentence  capitalization rules. Words that are capitalized as part of a
   regular sentence should be capitalized in a title and otherwise left as
   lowercase.  Punctuation can be omitted unless it aids the intent of the
   title (e.g., exclamation points or question marks).

   For example:

      This is a main heading
      ======================

      Paragraph.

      This is an exciting sub-heading!
      --------------------------------

      Paragraph.

   Serial Commas
   According to Wikipedia: In  English  punctuation,  a  serial  comma  or
   series  comma  (also  called Oxford comma and Harvard comma) is a comma
   placed immediately before the coordinating conjunction (usually  "and",
   "or", or "nor") in a series of three or more terms. For example, a list
   of three countries might be punctuated either as  "France,  Italy,  and
   Spain"  (with  the  serial  comma),  or  as  "France,  Italy and Spain"
   (without the serial comma)."

   When writing a list that includes three or more items, the serial comma
   should always be used.

   Documenting modules
   Documentation  for  Salt's  various module types is inline in the code.
   During the documentation build process it is  extracted  and  formatted
   into the final HTML, PDF, etc format.

   Inline documentation
   Python  has  special  multi-line strings called docstrings as the first
   element in a function or class. These strings  allow  documentation  to
   live  alongside  the  code  and  can  contain  special  formatting. For
   example:

      def my_function(value):
          '''
          Upper-case the given value

          Usage:

          .. code-block:: python

              val = 'a string'
              new_val = myfunction(val)
              print(new_val) # 'A STRING'

          :param value: a string
          :return: a copy of ``value`` that has been upper-cased
          '''
          return value.upper()

   Specify a release for additions or changes
   New functions or changes to existing functions should include a  marker
   that denotes what Salt release will be affected. For example:

      def my_function(value):
          '''
          Upper-case the given value

          .. versionadded:: 2014.7.0

          <...snip...>
          '''
          return value.upper()

   For changes to a function:

      def my_function(value, strip=False):
          '''
          Upper-case the given value

          .. versionchanged:: 2016.3.0
              Added a flag to also strip whitespace from the string.

          <...snip...>
          '''
          if strip:
              return value.upper().strip()
          return value.upper()

   Adding module documentation to the index
   Each  module  type  has  an index listing all modules of that type. For
   example: all-salt.modules,  all-salt.states,  all-salt.renderers.   New
   modules must be added to the index manually.

   1. Edit the file for the module type: execution modules, state modules,
      renderer modules, etc.

   2. Add the new module to the alphebetized list.

   3. Build the documentation which will generate an .rst file for the new
      module in the same directory as the index.rst.

   4. Commit  the  changes  to  index.rst and the new .rst file and send a
      pull request.

   Cross-references
   The  Sphinx  documentation  system   contains   a   wide   variety   of
   cross-referencing capabilities.

   Glossary entries
   Link  to glossary entries using the term role. A cross-reference should
   be added the first time a Salt-specific term is used in a document.

      A common way to encapsulate master-side functionality is by writing a
      custom :term:`Runner Function`. Custom Runner Functions are easy to write.

   Index entries
   Sphinx automatically generates many kinds of index entries, but  it  is
   occasionally useful to manually add items to the index.

   One  method is to use the index directive above the document or section
   that should appear in the index.

      .. index:: ! Event, event bus, event system
          see: Reactor; Event

   Another method is to use the index  role  inline  with  the  text  that
   should  appear  in the index. The index entry is created and the target
   text is left otherwise intact.

      Information about the :index:`Salt Reactor`
      -------------------------------------------

      Paragraph.

   Documents and sections
   Each document should contain a unique top-level label of the form:

      .. _my-page:

      My page
      =======

      Paragraph.

   Unique  labels  can  be  linked  using  the  ref  role.   This   allows
   cross-references to survive document renames or movement.

      For more information see :ref:`my-page`.

   Note, the :doc: role should not be used to link documents together.

   Modules
   Cross-references  to  Salt  modules  can be added using Sphinx's Python
   domain roles. For example, to create a link to the test.ping function:

      A useful execution module to test active communication with a minion is the
      :py:func:`test.ping <salt.modules.test.ping>` function.

   Salt modules can be referenced as well:

      The :py:mod:`test module <salt.modules.test>` contains many useful
      functions for inspecting an active Salt connection.

   The same syntax works for all modules types:

      One of the workhorse state module functions in Salt is the
      :py:func:`file.managed <salt.states.file.managed>` function.

   Settings
   Individual settings in the Salt Master  or  Salt  Minion  configuration
   files  are  cross-referenced  using  two custom roles, conf_master, and
   conf_minion.

      The :conf_minion:`minion ID <id>` setting is a unique identifier for a
      single minion.

   Documentation Changes and Fixes
   Documentation changes and fixes should be  made  against  the  earliest
   supported  release  branch  that the update applies to. The practice of
   updating a release branch instead of making all  documentation  changes
   against Salt's main, default branch, develop, is necessary in order for
   the docs to be as up-to-date as possible when the docs are built.

   The workflow mentioned above is also in line with  the  recommendations
   outlined  in  Salt's  contributing page. You can read more about how to
   choose  where  to   submit   documentation   fixes   by   reading   the
   which-salt-branch section.

   For  an  explanation of how to submit changes against various branches,
   see the github-pull-request  section.  Specifically,  see  the  section
   describing how to Create a new branch and the steps that follow.

   Building the documentation
   1. Install  Sphinx  using  a system package manager or pip. The package
      name is  often  of  the  form  python-sphinx.  There  are  no  other
      dependencies.

   2. Build  the documentation using the provided Makefile or .bat file on
      Windows.

         cd /path/to/salt/doc
         make html

   3. The   generated   documentation   will    be    written    to    the
      doc/_build/<format> directory.

   4. A  useful  method  of  viewing  the HTML documentation locally is to
      start Python's built-in HTTP server:

         cd /path/to/salt/doc/_build/html
         python -m SimpleHTTPServer

      Then   pull   up   the   documentation   in   a   web   browser   at
      http://localhost:8000/.

   Salt Formulas
   Formulas  are  pre-written  Salt States. They are as open-ended as Salt
   States themselves and can be  used  for  tasks  such  as  installing  a
   package,  configuring,  and  starting  a  service,  setting up users or
   permissions, and many other common tasks.

   All official Salt Formulas are found as separate  Git  repositories  in
   the "saltstack-formulas" organization on GitHub:

   https://github.com/saltstack-formulas

   As  a  simple  example, to install the popular Apache web server (using
   the normal defaults for  the  underlying  distro)  simply  include  the
   apache-formula from a top file:

      base:
        'web*':
          - apache

   Installation
   Each Salt Formula is an individual Git repository designed as a drop-in
   addition to an existing Salt State tree. Formulas can be  installed  in
   the following ways.

   Adding a Formula as a GitFS remote
   One  design  goal  of Salt's GitFS fileserver backend was to facilitate
   reusable States. GitFS is a quick and natural way to use Formulas.

   1. Install and configure GitFS.

   2. Add  one  or  more  Formula  repository  URLs  as  remotes  in   the
      gitfs_remotes list in the Salt Master configuration file:

         gitfs_remotes:
           - https://github.com/saltstack-formulas/apache-formula
           - https://github.com/saltstack-formulas/memcached-formula

      We  strongly  recommend  forking  a formula repository into your own
      GitHub account to avoid unexpected changes to your infrastructure.

      Many Salt Formulas  are  highly  active  repositories  so  pull  new
      changes  with  care. Plus any additions you make to your fork can be
      easily sent back upstream with a quick pull request!

   3. Restart the Salt master.

   Adding a Formula directory manually
   Formulas are simply directories that can be copied onto the local  file
   system  by  using  Git  to  clone  the repository or by downloading and
   expanding a tarball or  zip  file  of  the  repository.  The  directory
   structure  is  designed  to  work  with  file_roots  in the Salt master
   configuration.

   1. Clone or download the repository into a directory:

         mkdir -p /srv/formulas
         cd /srv/formulas
         git clone https://github.com/saltstack-formulas/apache-formula.git

         # or

         mkdir -p /srv/formulas
         cd /srv/formulas
         wget https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
         tar xf apache-formula-master.tar.gz

   2. Add the new directory to file_roots:

         file_roots:
           base:
             - /srv/salt
             - /srv/formulas/apache-formula

   3. Restart the Salt Master.

   Usage
   Each Formula is intended to be immediately usable  with  sane  defaults
   without   any   additional   configuration.   Many  formulas  are  also
   configurable by including data in Pillar; see the  pillar.example  file
   in each Formula repository for available options.

   Including a Formula in an existing State tree
   Formula  may  be included in an existing sls file. This is often useful
   when a state you are writing needs to require or extend a state defined
   in the formula.

   Here  is  an example of a state that uses the epel-formula in a require
   declaration which directs Salt to  not  install  the  python26  package
   until after the EPEL repository has also been installed:

      include:
        - epel

      python26:
        pkg.installed:
          - require:
            - pkg: epel

   Including a Formula from a Top File
   Some  Formula  perform completely standalone installations that are not
   referenced from other state files. It is usually  cleanest  to  include
   these Formula directly from a Top File.

   For  example  the  easiest  way  to set up an OpenStack deployment on a
   single machine is to include the openstack-standalone-formula  directly
   from a top.sls file:

      base:
        'myopenstackmaster':
          - openstack

   Quickly  deploying  OpenStack  across  several dedicated machines could
   also be done directly from a Top File and may look something like this:

      base:
        'controller':
          - openstack.horizon
          - openstack.keystone
        'hyper-*':
          - openstack.nova
          - openstack.glance
        'storage-*':
          - openstack.swift

   Configuring Formula using Pillar
   Salt Formulas are designed to work out of the box  with  no  additional
   configuration.  However,  many Formula support additional configuration
   and customization through Pillar. Examples of available options can  be
   found  in  a  file  named  pillar.example in the root directory of each
   Formula repository.

   Using Formula with your own states
   Remember that Formula are regular Salt States and can be used with  all
   Salt's  normal  state  mechanisms.  Formula  can be required from other
   States with requisites-require declarations, they can be modified using
   extend, they can made to watch other states with requisites-watch-in.

   The  following example uses the stock apache-formula alongside a custom
   state to create a vhost on a Debian/Ubuntu system  and  to  reload  the
   Apache service whenever the vhost is changed.

      # Include the stock, upstream apache formula.
      include:
        - apache

      # Use the watch_in requisite to cause the apache service state to reload
      # apache whenever the my-example-com-vhost state changes.
      my-example-com-vhost:
        file:
          - managed
          - name: /etc/apache2/sites-available/my-example-com
          - watch_in:
            - service: apache

   Don't be shy to read through the source for each Formula!

   Reporting problems & making additions
   Each Formula is a separate repository on GitHub. If you encounter a bug
   with a Formula please file an issue in the respective repository!  Send
   fixes  and  additions  as  a  pull  request. Add tips and tricks to the
   repository wiki.

   Writing Formulas
   Each  Formula  is  a  separate  repository  in  the  saltstack-formulas
   organization on GitHub.

   NOTE:
      Get involved creating new Formulas

      The best way to create new Formula repositories for now is to create
      a repository in your own account on GitHub and  notify  a  SaltStack
      employee  when it is ready. We will add you to the contributors team
      on the saltstack-formulas organization and  help  you  transfer  the
      repository  over.  Ping  a  SaltStack  employee  on  IRC  (#salt  on
      Freenode) or send an email to the salt-users mailing list.

      There are a lot of repositories in that organization!  Team  members
      can  manage  which  repositories  they are subscribed to on GitHub's
      watching page: https://github.com/watching.

   Style
   Maintainability, readability, and reusability are all marks of  a  good
   Salt sls file. This section contains several suggestions and examples.

      # Deploy the stable master branch unless version overridden by passing
      # Pillar at the CLI or via the Reactor.

      deploy_myapp:
        git.latest:
          - name: [email protected]/myco/myapp.git
          - version: {{ salt.pillar.get('myapp:version', 'master') }}

   Use a descriptive State ID
   The ID of a state is used as a unique identifier that may be referenced
   via other states in requisites. It must  be  unique  across  the  whole
   state tree (it is a key in a dictionary, after all).

   In  addition a state ID should be descriptive and serve as a high-level
   hint  of  what  it  will  do,  or  manage,  or  change.  For   example,
   deploy_webapp, or apache, or reload_firewall.

   Use module.function notation
   So-called  "short-declaration"  notation  is  preferred for referencing
   state modules and state functions. It provides a consistent pattern  of
   module.function shared between Salt States, the Reactor, Salt Mine, the
   Scheduler, as well as with the CLI.

      # Do
      apache:
        pkg.installed:
          - name: httpd

      # Don't
      apache:
        pkg:
          - installed
          - name: httpd

   Salt's state compiler  will  transform  "short-decs"  into  the  longer
   format  when  compiling the human-friendly highstate structure into the
   machine-friendly lowstate structure.

   Specify the name parameter
   Use a unique and permanent identifier for the state ID and reserve name
   for data with variability.

   The  name  declaration is a required parameter for all state functions.
   The state ID will implicitly be used as name if it  is  not  explicitly
   set in the state.

   In many state functions the name parameter is used for data that varies
   such as OS-specific  package  names,  OS-specific  file  system  paths,
   repository  addresses,  etc.  Any  time  the  ID of a state changes all
   references to that ID must also be changed. Use  a  permanent  ID  when
   writing a state the first time to future-proof that state and allow for
   easier refactors down the road.

   Comment state files
   YAML allows comments at  varying  indentation  levels.  It  is  a  good
   practice  to  comment  state files. Use vertical whitespace to visually
   separate different concepts or actions.

      # Start with a high-level description of the current sls file.
      # Explain the scope of what it will do or manage.

      # Comment individual states as necessary.
      update_a_config_file:
        # Provide details on why an unusual choice was made. For example:
        #
        # This template is fetched from a third-party and does not fit our
        # company norm of using Jinja. This must be processed using Mako.
        file.managed:
          - name: /path/to/file.cfg
          - source: salt://path/to/file.cfg.template
          - template: mako

        # Provide a description or explanation that did not fit within the state
        # ID. For example:
        #
        # Update the application's last-deployed timestamp.
        # This is a workaround until Bob configures Jenkins to automate RPM
        # builds of the app.
        cmd.run:
          # FIXME: Joe needs this to run on Windows by next quarter. Switch these
          # from shell commands to Salt's file.managed and file.replace state
          # modules.
          - name: |
              touch /path/to/file_last_updated
              sed -e 's/foo/bar/g' /path/to/file_environment
          - onchanges:
            - file: a_config_file

   Be careful to use Jinja comments for commenting  Jinja  code  and  YAML
   comments for commenting YAML code.

      # BAD EXAMPLE
      # The Jinja in this YAML comment is still executed!
      # {% set apache_is_installed = 'apache' in salt.pkg.list_pkgs() %}

      # GOOD EXAMPLE
      # The Jinja in this Jinja comment will not be executed.
      {# {% set apache_is_installed = 'apache' in salt.pkg.list_pkgs() %} #}

   Easy on the Jinja!
   Jinja templating provides vast flexibility and power when building Salt
   sls files. It can also create an unmaintainable  tangle  of  logic  and
   data.  Speaking  broadly,  Jinja  is best used when kept apart from the
   states (as much as is possible).

   Below are guidelines and examples of how Jinja can be used effectively.

   Know the evaluation and execution order
   High-level knowledge of how Salt states are compiled and run is  useful
   when writing states.

   The default renderer setting in Salt is Jinja piped to YAML.  Each is a
   separate step. Each step is not aware  of  the  previous  or  following
   step.  Jinja  is  not  YAML aware, YAML is not Jinja aware; they cannot
   share variables or interact.

   * Whatever the Jinja step produces must be valid YAML.

   * Whatever the YAML step  produces  must  be  a  valid  highstate  data
     structure.  (This  is  also  true  of  the  final step for any of the
     alternate renderers in Salt.)

   * Highstate can be thought of as a human-friendly data structure;  easy
     to write and easy to read.

   * Salt's  state compiler validates the highstate and compiles it to low
     state.

   * Low state can be thought of as a machine-friendly data structure.  It
     is a list of dictionaries that each map directly to a function call.

   * Salt's  state  system  finally starts and executes on each "chunk" in
     the low state. Remember that requisites are evaluated at runtime.

   * The  return  for  each  function  call  is  added  to  the  "running"
     dictionary which is the final output at the end of the state run.

   The full evaluation and execution order:

      Jinja -> YAML -> Highstate -> low state -> execution

   Avoid changing the underlying system with Jinja
   Avoid  calling  commands  from Jinja that change the underlying system.
   Commands run via Jinja do not respect Salt's dry-run mode  (test=True)!
   This  is  usually in conflict with the idempotent nature of Salt states
   unless the command being run is also idempotent.

   Inspect the local system
   A common use for Jinja in Salt states is to  gather  information  about
   the  underlying  system.  The  grains dictionary available in the Jinja
   context is a great example of common data points that Salt  itself  has
   already  gathered.   Less  common  values  are  often  found by running
   commands. For example:

      {% set is_selinux_enabled = salt.cmd.run('sestatus') == '1' %}

   This is usually best done  with  a  variable  assignment  in  order  to
   separate the data from the state that will make use of the data.

   Gather external data
   One of the most common uses for Jinja is to pull external data into the
   state file. External data can come from  anywhere  like  API  calls  or
   database  queries,  but  it  most commonly comes from flat files on the
   file system or Pillar data from the Salt Master. For example:

      {% set some_data = salt.pillar.get('some_data', {'sane default': True}) %}

      {# or #}

      {% import_yaml 'path/to/file.yaml' as some_data %}

      {# or #}

      {% import_json 'path/to/file.json' as some_data %}

      {# or #}

      {% import_text 'path/to/ssh_key.pub' as ssh_pub_key %}

      {# or #}

      {% from 'path/to/other_file.jinja' import some_data with context %}

   This is usually best done  with  a  variable  assignment  in  order  to
   separate the data from the state that will make use of the data.

   Light conditionals and looping
   Jinja  is  extremely  powerful  for  programmatically  generating  Salt
   states. It is also easy to overuse. As a rule of thumb, if it  is  hard
   to read it will be hard to maintain!

   Separate  Jinja  control-flow  statements from the states as much as is
   possible to create readable states. Limit Jinja within states to simple
   variable lookups.

   Below is a simple example of a readable loop:

      {% for user in salt.pillar.get('list_of_users', []) %}

      {# Ensure unique state IDs when looping. #}
      {{ user.name }}-{{ loop.index }}:
        user.present:
          - name: {{ user.name }}
          - shell: {{ user.shell }}

      {% endfor %}

   Avoid  putting  a Jinja conditionals within Salt states where possible.
   Readability suffers and the correct YAML indentation  is  difficult  to
   see  in the surrounding visual noise. Parametrization (discussed below)
   and variables are both useful techniques to avoid this. For example:

      {# ---- Bad example ---- #}

      apache:
        pkg.installed:
          {% if grains.os_family == 'RedHat' %}
          - name: httpd
          {% elif grains.os_family == 'Debian' %}
          - name: apache2
          {% endif %}

      {# ---- Better example ---- #}

      {% if grains.os_family == 'RedHat' %}
      {% set name = 'httpd' %}
      {% elif grains.os_family == 'Debian' %}
      {% set name = 'apache2' %}
      {% endif %}

       apache:
        pkg.installed:
          - name: {{ name }}

      {# ---- Good example ---- #}

      {% set name = {
          'RedHat': 'httpd',
          'Debian': 'apache2',
      }.get(grains.os_family) %}

       apache:
        pkg.installed:
          - name: {{ name }}

   Dictionaries are useful to  effectively  "namespace"  a  collection  of
   variables.   This  is  useful  with  parametrization (discussed below).
   Dictionaries are also easily combined  and  merged.  And  they  can  be
   directly  serialized  into  YAML  which  is often easier than trying to
   create valid YAML through templating. For example:

      {# ---- Bad example ---- #}

      haproxy_conf:
        file.managed:
          - name: /etc/haproxy/haproxy.cfg
          - template: jinja
          {% if 'external_loadbalancer' in grains.roles %}
          - source: salt://haproxy/external_haproxy.cfg
          {% elif 'internal_loadbalancer' in grains.roles %}
          - source: salt://haproxy/internal_haproxy.cfg
          {% endif %}
          - context:
              {% if 'external_loadbalancer' in grains.roles %}
              ssl_termination: True
              {% elif 'internal_loadbalancer' in grains.roles %}
              ssl_termination: False
              {% endif %}

      {# ---- Better example ---- #}

      {% load_yaml as haproxy_defaults %}
      common_settings:
        bind_port: 80

      internal_loadbalancer:
        source: salt://haproxy/internal_haproxy.cfg
        settings:
          bind_port: 8080
          ssl_termination: False

      external_loadbalancer:
        source: salt://haproxy/external_haproxy.cfg
        settings:
          ssl_termination: True
      {% endload %}

      {% if 'external_loadbalancer' in grains.roles %}
      {% set haproxy = haproxy_defaults['external_loadbalancer'] %}
      {% elif 'internal_loadbalancer' in grains.roles %}
      {% set haproxy = haproxy_defaults['internal_loadbalancer'] %}
      {% endif %}

      {% do haproxy.settings.update(haproxy_defaults.common_settings) %}

      haproxy_conf:
        file.managed:
          - name: /etc/haproxy/haproxy.cfg
          - template: jinja
          - source: {{ haproxy.source }}
          - context: {{ haproxy.settings | yaml() }}

   There is still room for improvement in the above example. For  example,
   extracting  into  an external file or replacing the if-elif conditional
   with a function call  to  filter  the  correct  data  more  succinctly.
   However,  the  state itself is simple and legible, the data is separate
   and also simple and legible.  And those suggested improvements  can  be
   made at some future date without altering the state at all!

   Avoid heavy logic and programming
   Jinja  is not Python. It was made by Python programmers and shares many
   semantics and some syntax but it does not  allow  for  abitrary  Python
   function  calls  or  Python  imports.  Jinja  is  a  fast and efficient
   templating language but the syntax can be verbose and visually noisy.

   Once Jinja use within an sls file becomes slightly complicated --  long
   chains    of   if-elif-elif-else   statements,   nested   conditionals,
   complicated dictionary merges, wanting to use sets -- instead  consider
   using a different Salt renderer, such as the Python renderer. As a rule
   of thumb, if it is hard to read it will be hard to maintain  --  switch
   to a format that is easier to read.

   Using  alternate renderers is very simple to do using Salt's "she-bang"
   syntax at the top of the file. The Python renderer must  simply  return
   the  correct highstate data structure. The following example is a state
   tree of two sls files, one simple and one complicated.

   /srv/salt/top.sls:

      base:
        '*':
          - common_configuration
          - roles_configuration

   /srv/salt/common_configuration.sls:

      common_users:
        user.present:
          - names: [larry, curly, moe]

   /srv/salt/roles_configuration:

      #!py
      def run():
          list_of_roles = set()

          # This example has the minion id in the form 'web-03-dev'.
          # Easily access the grains dictionary:
          try:
              app, instance_number, environment = __grains__['id'].split('-')
              instance_number = int(instance_number)
          except ValueError:
              app, instance_number, environment = ['Unknown', 0, 'dev']

          list_of_roles.add(app)

          if app == 'web' and environment == 'dev':
              list_of_roles.add('primary')
              list_of_roles.add('secondary')
          elif app == 'web' and environment == 'staging':
              if instance_number == 0:
                  list_of_roles.add('primary')
              else:
                  list_of_roles.add('secondary')

          # Easily cross-call Salt execution modules:
          if __salt__['myutils.query_valid_ec2_instance']():
              list_of_roles.add('is_ec2_instance')

          return {
              'set_roles_grains': {
                  'grains.present': [
                      {'name': 'roles'},
                      {'value': list(list_of_roles)},
                  ],
              },
          }

   Jinja Macros
   In Salt sls files Jinja macros are useful for one thing and  one  thing
   only:  creating  mini  templates  that  can  be  reused and rendered on
   demand. Do not fall into the trap of thinking of macros  as  functions;
   Jinja is not Python (see above).

   Macros  are  useful  for  creating  reusable, parameterized states. For
   example:

      {% macro user_state(state_id, user_name, shell='/bin/bash', groups=[]) %}
      {{ state_id }}:
        user.present:
          - name: {{ user_name }}
          - shell: {{ shell }}
          - groups: {{ groups | json() }}
      {% endmacro %}

      {% for user_info in salt.pillar.get('my_users', []) %}
      {{ user_state('user_number_' ~ loop.index, **user_info) }}
      {% endfor %}

   Macros are also useful for  creating  one-off  "serializers"  that  can
   accept  a  data  structure  and  write  that  out  as a domain-specific
   configuration file. For example, the following macro could be  used  to
   write a php.ini config file:

   /srv/salt/php.sls:

      php_ini:
        file.managed:
          - name: /etc/php.ini
          - source: salt://php.ini.tmpl
          - template: jinja
          - context:
              php_ini_settings: {{ salt.pillar.get('php_ini', {}) | json() }}

   /srv/pillar/php.sls:

      php_ini:
        PHP:
          engine: 'On'
          short_open_tag: 'Off'
          error_reporting: 'E_ALL & ~E_DEPRECATED & ~E_STRICT'

   /srv/salt/php.ini.tmpl:

      {% macro php_ini_serializer(data) %}
      {% for section_name, name_val_pairs in data.items() %}
      [{{ section_name }}]
      {% for name, val in name_val_pairs.items() -%}
      {{ name }} = "{{ val }}"
      {% endfor %}
      {% endfor %}
      {% endmacro %}

      ; File managed by Salt at <{{ source }}>.
      ; Your changes will be overwritten.

      {{ php_ini_serializer(php_ini_settings) }}

   Abstracting static defaults into a lookup table
   Separate  data that a state uses from the state itself to increases the
   flexibility and reusability of a state.

   An obvious and common example  of  this  is  platform-specific  package
   names  and  file  system paths. Another example is sane defaults for an
   application, or common  settings  within  a  company  or  organization.
   Organizing  such  data  as  a  dictionary  (aka hash map, lookup table,
   associative array) often provides a lightweight namespacing and  allows
   for  quick and easy lookups. In addition, using a dictionary allows for
   easily merging and overriding static values within a lookup table  with
   dynamic values fetched from Pillar.

   A  strong  convention  in  Salt  Formulas is to place platform-specific
   data, such as package names and file system paths, into  a  file  named
   map.jinja that is placed alongside the state files.

   The   following   is   an   example   from   the  MySQL  Formula.   The
   grains.filter_by function performs a lookup on  that  table  using  the
   os_family grain (by default).

   The  result  is  that the mysql variable is assigned to a subset of the
   lookup table for the current platform. This allows states to reference,
   for  example,  the  name  of  a  package  without  worrying  about  the
   underlying  OS.  The  syntax  for  referencing  a  value  is  a  normal
   dictionary  lookup  in  Jinja,  such  as  {{ mysql['service'] }} or the
   shorthand {{ mysql.service }}.

   map.jinja:

      {% set mysql = salt['grains.filter_by']({
          'Debian': {
              'server': 'mysql-server',
              'client': 'mysql-client',
              'service': 'mysql',
              'config': '/etc/mysql/my.cnf',
              'python': 'python-mysqldb',
          },
          'RedHat': {
              'server': 'mysql-server',
              'client': 'mysql',
              'service': 'mysqld',
              'config': '/etc/my.cnf',
              'python': 'MySQL-python',
          },
          'Gentoo': {
              'server': 'dev-db/mysql',
              'client': 'dev-db/mysql',
              'service': 'mysql',
              'config': '/etc/mysql/my.cnf',
              'python': 'dev-python/mysql-python',
          },
      }, merge=salt['pillar.get']('mysql:lookup')) %}

   Values defined in the map file can be fetched for the current  platform
   in any state file using the following syntax:

      {% from "mysql/map.jinja" import mysql with context %}

      mysql-server:
        pkg.installed:
          - name: {{ mysql.server }}
        service.running:
          - name: {{ mysql.service }}

   Organizing Pillar data
   It   is  considered  a  best  practice  to  make  formulas  expect  all
   formula-related parameters to be placed under second-level lookup  key,
   within  a  main  namespace  designated  for holding data for particular
   service/software/etc, managed by the formula:

      mysql:
        lookup:
          version: 5.7.11

   Collecting common values
   Common values can be collected into a base dictionary.  This  minimizes
   repetition   of   identical   values   in   each   of  the  lookup_dict
   sub-dictionaries.  Now only the values that are different from the base
   must be specified by the alternates:

   map.jinja:

      {% set mysql = salt['grains.filter_by']({
          'default': {
              'server': 'mysql-server',
              'client': 'mysql-client',
              'service': 'mysql',
              'config': '/etc/mysql/my.cnf',
              'python': 'python-mysqldb',
          },
          'Debian': {
          },
          'RedHat': {
              'client': 'mysql',
              'service': 'mysqld',
              'config': '/etc/my.cnf',
              'python': 'MySQL-python',
          },
          'Gentoo': {
              'server': 'dev-db/mysql',
              'client': 'dev-db/mysql',
              'python': 'dev-python/mysql-python',
          },
      },
      merge=salt['pillar.get']('mysql:lookup'), base='default') %}

   Overriding values in the lookup table
   Allow  static  values  within lookup tables to be overridden. This is a
   simple pattern which once again increases flexibility  and  reusability
   for state files.

   The  merge argument in filter_by specifies the location of a dictionary
   in Pillar that can be used to override values returned from the  lookup
   table. If the value exists in Pillar it will take precedence.

   This  is  useful  when  software or configuration files is installed to
   non-standard locations or on unsupported platforms.  For  example,  the
   following Pillar would replace the config value from the call above.

      mysql:
        lookup:
          config: /usr/local/etc/mysql/my.cnf

   NOTE:
      Protecting Expansion of Content with Special Characters

      When  templating keep in mind that YAML does have special characters
      for quoting, flows, and other special structure and content.  When a
      Jinja   substitution  may  have  special  characters  that  will  be
      incorrectly parsed by YAML care must be taken.  It is a good  policy
      to use the yaml_encode or the yaml_dquote Jinja filters:

          {%- set foo = 7.7 %}
          {%- set bar = none %}
          {%- set baz = true %}
          {%- set zap = 'The word of the day is "salty".' %}
          {%- set zip = '"The quick brown fox . . ."' %}

          foo: {{ foo|yaml_encode }}
          bar: {{ bar|yaml_encode }}
          baz: {{ baz|yaml_encode }}
          zap: {{ zap|yaml_encode }}
          zip: {{ zip|yaml_dquote }}

      The above will be rendered as below:

          foo: 7.7
          bar: null
          baz: true
          zap: "The word of the day is \"salty\"."
          zip: "\"The quick brown fox . . .\""

   The  filter_by  function  performs  a simple dictionary lookup but also
   allows for fetching data from Pillar and overriding data stored in  the
   lookup  table. That same workflow can be easily performed without using
   filter_by; other dictionaries besides data  from  Pillar  can  also  be
   used.

      {% set lookup_table = {...} %}
      {% do lookup_table.update(salt.pillar.get('my:custom:data')) %}

   When to use lookup tables
   The  map.jinja  file  is  only  a convention within Salt Formulas. This
   greater pattern is useful for a wide variety of data in a wide  variety
   of  workflows.   This  pattern  is  not  limited to pulling data from a
   single file or data source.  This pattern is useful in  States,  Pillar
   and the Reactor, for example.

   Working with a data structure instead of, say, a config file allows the
   data to be cobbled together from multiple sources (local files,  remote
   Pillar, database queries, etc), combined, overridden, and searched.

   Below  are  a  few examples of what lookup tables may be useful for and
   how they may be used and represented.

   Platform-specific information
   An obvious pattern and one used heavily in Salt Formulas is  extracting
   platform-specific  information  such  as  package names and file system
   paths in a file named map.jinja. The pattern  is  explained  in  detail
   above.

   Sane defaults
   Application  settings can be a good fit for this pattern. Store default
   settings along with  the  states  themselves  and  keep  overrides  and
   sensitive settings in Pillar. Combine both into a single dictionary and
   then write the application config or settings file.

   The example below stores most of  the  Apache  Tomcat  server.xml  file
   alongside  the  Tomcat  states  and then allows values to be updated or
   augmented via Pillar. (This example  uses  the  BadgerFish  format  for
   transforming JSON to XML.)

   /srv/salt/tomcat/defaults.yaml:

      Server:
        '@port': '8005'
        '@shutdown': SHUTDOWN
        GlobalNamingResources:
          Resource:
            '@auth': Container
            '@description': User database that can be updated and saved
            '@factory': org.apache.catalina.users.MemoryUserDatabaseFactory
            '@name': UserDatabase
            '@pathname': conf/tomcat-users.xml
            '@type': org.apache.catalina.UserDatabase
        # <...snip...>

   /srv/pillar/tomcat.sls:

      appX:
        server_xml_overrides:
          Server:
            Service:
              '@name': Catalina
              Connector:
                '@port': '8009'
                '@protocol': AJP/1.3
                '@redirectPort': '8443'
                # <...snip...>

   /srv/salt/tomcat/server_xml.sls:

      {% import_yaml 'tomcat/defaults.yaml' as server_xml_defaults %}
      {% set server_xml_final_values = salt.pillar.get(
          'appX:server_xml_overrides',
          default=server_xml_defaults,
          merge=True)
      %}

      appX_server_xml:
        file.serialize:
          - name: /etc/tomcat/server.xml
          - dataset: {{ server_xml_final_values | json() }}
          - formatter: xml_badgerfish

   The  file.serialize  state  can  provide  a shorthand for creating some
   files from data structures. There are also many  examples  within  Salt
   Formulas of creating one-off "serializers" (often as Jinja macros) that
   reformat a data  structure  to  a  specific  config  file  format.  For
   example,
   `Nginx vhosts`__
    or the
   `php.ini`__

   __:
   https://github.com/saltstack-formulas/nginx-formula/blob/5cad4512/nginx/ng/vhosts_config.sls
   __:
   https://github.com/saltstack-formulas/php-formula/blob/82e2cd3a/php/ng/files/php.ini

   Environment specific information
   A  single  state can be reused when it is parameterized as described in
   the section below, by separating the data the state will use  from  the
   state  that  performs  the  work.  This  can  be the difference between
   deploying Application X and Application Y, or  the  difference  between
   production and development. For example:

   /srv/salt/app/deploy.sls:

      {# Load the map file. #}
      {% import_yaml 'app/defaults.yaml' as app_defaults %}

      {# Extract the relevant subset for the app configured on the current
         machine (configured via a grain in this example). #}
      {% app = app_defaults.get(salt.grains.get('role') %}

      {# Allow values from Pillar to (optionally) update values from the lookup
         table. #}
      {% do app_defaults.update(salt.pillar.get('myapp', {}) %}

      deploy_application:
        git.latest:
          - name: {{ app.repo_url }}
          - version: {{ app.version }}
          - target: {{ app.deploy_dir }}

      myco/myapp/deployed:
        event.send:
          - data:
              version: {{ app.version }}
          - onchanges:
            - git: deploy_application

   /srv/salt/app/defaults.yaml:

      appX:
        repo_url: [email protected]/myco/appX.git
        target: /var/www/appX
        version: master
      appY:
        repo_url: [email protected]/myco/appY.git
        target: /var/www/appY
        version: v1.2.3.4

   Single-purpose SLS files
   Each  sls  file  in  a Formula should strive to do a single thing. This
   increases the reusability of this file by keeping unrelated tasks  from
   getting coupled together.

   As  an  example, the base Apache formula should only install the Apache
   httpd server and start the httpd service. This is the  basic,  expected
   behavior  when  installing  Apache.  It  should  not perform additional
   changes such as set the Apache configuration file or create vhosts.

   If a formula is single-purpose as in the example above, other formulas,
   and  also other states can include and use that formula with requisites
   without also including undesirable or unintended side-effects.

   The following is a best-practice example for a reusable Apache formula.
   (This  skips  platform-specific  options  for  brevity.  See  the  full
   apache-formula for more.)

      # apache/init.sls
      apache:
        pkg.installed:
          [...]
        service.running:
          [...]

      # apache/mod_wsgi.sls
      include:
        - apache

      mod_wsgi:
        pkg.installed:
          [...]
          - require:
            - pkg: apache

      # apache/conf.sls
      include:
        - apache

      apache_conf:
        file.managed:
          [...]
          - watch_in:
            - service: apache

   To illustrate a bad example, say the  above  Apache  formula  installed
   Apache  and  also created a default vhost. The mod_wsgi state would not
   be able to include the Apache formula to create  that  dependency  tree
   without also installing the unneeded default vhost.

   Formulas should be reusable. Avoid coupling unrelated actions together.

   Parameterization
   Parameterization  is  a  key feature of Salt Formulas and also for Salt
   States. Parameterization allows a single Formula to  be  reused  across
   many operating systems; to be reused across production, development, or
   staging environments; and to be reused by many people all with  varying
   goals.

   Writing  states,  specifying ordering and dependencies is the part that
   takes the longest to write and to test. Filling those states  out  with
   data such as users or package names or file locations is the easy part.
   How many users, what those users are named, or where the files live are
   all   implementation   details   that  should  be  parameterized.  This
   separation between a state and the data that populates a state  creates
   a reusable formula.

   In  the  example  below the data that populates the state can come from
   anywhere -- it can be hard-coded at the top of the state, it  can  come
   from  an  external  file,  it can come from Pillar, it can come from an
   execution function call, or it can come  from  a  database  query.  The
   state  itself  doesn't  change regardless of where the data comes from.
   Production data will vary from development data  will  vary  from  data
   from one company to another, however the state itself stays the same.

      {% set user_list = [
          {'name': 'larry', 'shell': 'bash'},
          {'name': 'curly', 'shell': 'bash'},
          {'name': 'moe', 'shell': 'zsh'},
      ] %}

      {# or #}

      {% set user_list = salt['pillar.get']('user_list') %}

      {# or #}

      {% load_json "default_users.json" as user_list %}

      {# or #}

      {% set user_list = salt['acme_utils.get_user_list']() %}

      {% for user in list_list %}
      {{ user.name }}:
        user.present:
          - name: {{ user.name }}
          - shell: {{ user.shell }}
      {% endfor %}

   Configuration
   Formulas  should strive to use the defaults of the underlying platform,
   followed by defaults  from  the  upstream  project,  followed  by  sane
   defaults for the formula itself.

   As  an  example,  a  formula  to  install  Apache should not change the
   default Apache configuration file installed by the OS package. However,
   the  Apache  formula  should  include a state to change or override the
   default configuration file.

   Pillar overrides
   Pillar lookups must use the safe  get()  and  must  provide  a  default
   value. Create local variables using the Jinja set construct to increase
   redability and to avoid potentially hundreds or thousands  of  function
   calls across a large state tree.

      {% from "apache/map.jinja" import apache with context %}
      {% set settings = salt['pillar.get']('apache', {}) %}

      mod_status:
        file.managed:
          - name: {{ apache.conf_dir }}
          - source: {{ settings.get('mod_status_conf', 'salt://apache/mod_status.conf') }}
          - template: {{ settings.get('template_engine', 'jinja') }}

   Any  default  values used in the Formula must also be documented in the
   pillar.example file in the root of the repository. Comments  should  be
   used  liberally  to  explain the intent of each configuration value. In
   addition, users should be able copy-and-paste the contents of this file
   into their own Pillar to make any desired changes.

   Scripting
   Remember  that both State files and Pillar files can easily call out to
   Salt execution modules and have access to  all  the  system  grains  as
   well.

      {% if '/storage' in salt['mount.active']() %}
      /usr/local/etc/myfile.conf:
        file:
          - symlink
          - target: /storage/myfile.conf
      {% endif %}

   Jinja  macros  to  encapsulate logic or conditionals are discouraged in
   favor of writing custom execution modules in Python.

   Repository structure
   A basic Formula repository should have the following layout:

      foo-formula
      |-- foo/
      |   |-- map.jinja
      |   |-- init.sls
      |   `-- bar.sls
      |-- CHANGELOG.rst
      |-- LICENSE
      |-- pillar.example
      |-- README.rst
      `-- VERSION

   SEE ALSO:
      template-formula

      The template-formula repository has a pre-built layout  that  serves
      as  the  basic structure for a new formula repository. Just copy the
      files from there and edit them.

   README.rst
   The README should detail each available .sls file by explaining what it
   does, whether it has any dependencies on other formulas, whether it has
   a target platform, and any other installation or usage instructions  or
   tips.

   A sample skeleton for the README.rst file:

      ===
      foo
      ===

      Install and configure the FOO service.

      .. note::

          See the full `Salt Formulas installation and usage instructions
          <http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.

      Available states
      ================

      .. contents::
          :local:

      ``foo``
      -------

      Install the ``foo`` package and enable the service.

      ``foo.bar``
      -----------

      Install the ``bar`` package.

   CHANGELOG.rst
   The  CHANGELOG.rst  file  should  detail the individual versions, their
   release date and a set of bullet points for each  version  highlighting
   the overall changes in a given version of the formula.

   A sample skeleton for the CHANGELOG.rst file:

   CHANGELOG.rst:

      foo formula
      ===========

      0.0.2 (2013-01-01)

      - Re-organized formula file layout
      - Fixed filename used for upstart logger template
      - Allow for pillar message to have default if none specified

   Versioning
   Formula    are    versioned    according    to   Semantic   Versioning,
   http://semver.org/.

   NOTE:
      Given a version number MAJOR.MINOR.PATCH, increment the:

      1. MAJOR version when you make incompatible API changes,

      2. MINOR   version    when    you    add    functionality    in    a
         backwards-compatible manner, and

      3. PATCH version when you make backwards-compatible bug fixes.

      Additional  labels  for pre-release and build metadata are available
      as extensions to the MAJOR.MINOR.PATCH format.

   Formula versions are tracked using Git tags as well as the VERSION file
   in  the  formula  repository.  The  VERSION  file  should  contain  the
   currently released version of the particular formula.

   Testing Formulas
   A smoke-test for invalid Jinja, invalid YAML, or an invalid Salt  state
   structure can be performed by with the state.show_sls function:

      salt '*' state.show_sls apache

   Salt  Formulas  can  then  be  tested  by  running  each  .sls file via
   state.apply and checking the output for the success or failure of  each
   state in the Formula. This should be done for each supported platform.

   SaltStack Packaging Guide
   Since  Salt  provides  a  powerful  toolkit  for  system management and
   automation, the package can be spit into a number of  sub-tools.  While
   packaging  Salt  as  a  single  package  containing  all  components is
   perfectly acceptable, the split packages should follow this convention.

   Patching Salt For Distributions
   The occasion may arise where Salt source and default configurations may
   need to be patched. It is preferable if Salt is only patched to include
   platform specific  additions  or  to  fix  release  time  bugs.  It  is
   preferable  that  configuration  settings  and operations remain in the
   default state, as changes here lowers the  user  experience  for  users
   moving across distributions.

   In  the  event  where  a  packager  finds  a need to change the default
   configuration it is advised  to  add  the  files  to  the  master.d  or
   minion.d directories.

   Source Files
   Release  packages  should  always  be  built  from  the  source tarball
   distributed via pypi. Release packages should NEVER use a git  checkout
   as the source for distribution.

   Single Package
   Shipping  Salt  as  a single package, where the minion, master, and all
   tools  are  together  is  perfectly   acceptable   and   practiced   by
   distributions such as FreeBSD.

   Split Package
   Salt   Should  always  be  split  in  a  standard  way,  with  standard
   dependencies, this  lowers  cross  distribution  confusion  about  what
   components  are  going  to  be  shipped  with  specific packages. These
   packages can be defined from the Salt Source as of Salt 2014.1.0:

   Salt Common
   The salt-common or salt package should contain the  files  provided  by
   the  salt  python  package,  or  all  files  distributed from the salt/
   directory  in  the  source  distribution  packages.  The  documentation
   contained  under  the  doc/ directory can be a part of this package but
   splitting out a doc package is preferred.  Since salt-call is the entry
   point  to  utilize  the  libs and is useful for all salt packages it is
   included in the salt-common package.

   Name
   * salt OR salt-common

   Files
   * salt/*

   * man/salt.7

   * scripts/salt-call

   * tests/*

   * man/salt-call.1

   Depends
   * Python 2.6-2.7

   * PyYAML

   * Jinja2

   Salt Master
   The salt-master package contains the applicable  scripts,  related  man
   pages and init information for the given platform.

   Name
   * salt-master

   Files
   * scripts/salt-master

   * scripts/salt

   * scripts/salt-run

   * scripts/salt-key

   * scripts/salt-cp

   * pkg/<master init data>

   * man/salt.1

   * man/salt-master.1

   * man/salt-run.1

   * man/salt-key.1

   * man/salt-cp.1

   * conf/master

   Depends
   * Salt Common

   * ZeroMQ >= 3.2

   * PyZMQ >= 2.10

   * PyCrypto

   * M2Crypto

   * Python MessagePack (Messagepack C lib, or msgpack-pure)

   Salt Syndic
   The  Salt  Syndic package can be rolled completely into the Salt Master
   package.  Platforms  which  start  services  as  part  of  the  package
   deployment  need  to maintain a separate salt-syndic package (primarily
   Debian based platforms).

   The Syndic may optionally not depend on the anything more than the Salt
   Master since the master will bring in all needed dependencies, but fall
   back to the platform specific packaging guidelines.

   Name
   * salt-syndic

   Files
   * scripts/salt-syndic

   * pkg/<syndic init data>

   * man/salt-syndic.1

   Depends
   * Salt Common

   * Salt Master

   * ZeroMQ >= 3.2

   * PyZMQ >= 2.10

   * PyCrypto

   * M2Crypto

   * Python MessagePack (Messagepack C lib, or msgpack-pure)

   Salt Minion
   The Minion is a standalone package and should not be split  beyond  the
   salt-minion and salt-common packages.

   Name
   * salt-minion

   Files
   * scripts/salt-minion

   * pkg/<minion init data>

   * man/salt-minion.1

   * conf/minion

   Depends
   * Salt Common

   * ZeroMQ >= 3.2

   * PyZMQ >= 2.10

   * PyCrypto

   * M2Crypto

   * Python MessagePack (Messagepack C lib, or msgpack-pure)

   Salt SSH
   Since Salt SSH does not require the same dependencies as the minion and
   master, it should be split out.

   Name
   * salt-ssh

   Files
   * scripts/salt-ssh

   * man/salt-ssh.1

   * conf/cloud*

   Depends
   * Salt Common

   * Python MessagePack (Messagepack C lib, or msgpack-pure)

   Salt Cloud
   As of Salt 2014.1.0 Salt Cloud is included in the same  repo  as  Salt.
   This  can be split out into a separate package or it can be included in
   the salt-master package.

   Name
   * salt-cloud

   Files
   * scripts/salt-cloud

   * man/salt-cloud.1

   Depends
   * Salt Common

   * apache libcloud >= 0.14.0

   Salt Doc
   The documentation package is very distribution optional.  A  completely
   split  package  will  split  out  the  documentation, but some platform
   conventions do not prefer this.  If the documentation is not split out,
   it should be included with the Salt Common package.

   Name
   * salt-doc

   Files
   * doc/*

   Optional Depends
   * Salt Common

   * Python Sphinx

   * Make

   Salt Release Process
   The  goal  for Salt projects is to cut a new feature release every four
   to six months. This document outlines the process for  these  releases,
   and the subsequent bug fix releases which follow.

   Feature Release Process
   When  a  new  release  is  ready  to be cut, the person responsible for
   cutting the release will follow the following steps (written using  the
   0.16 release as an example):

   1. All open issues on the release milestone should be moved to the next
      release milestone.  (e.g.  from  the  0.16  milestone  to  the  0.17
      milestone)

   2. Release  notes  should be created documenting the major new features
      and bugfixes in the release.

   3. Create an annotated tag  with  only  the  major  and  minor  version
      numbers,  preceded  by  the  letter  v.  (e.g. v0.16)  This tag will
      reside on the develop branch.

   4. Create a branch for the new release, using only the major and  minor
      version numbers.  (e.g. 0.16)

   5. On  this  new branch, create an annotated tag for the first revision
      release, which is generally  a  release  candidate.   It  should  be
      preceded by the letter v.  (e.g. v0.16.0rc1)

   6. The  release should be packaged from this annotated tag and uploaded
      to PyPI as well as the GitHub releases page for this tag.

   7. The packagers should be notified on the salt-packagers mailing  list
      so  they  can  create  packages for all the major operating systems.
      (note that release candidates should go in the testing repositories)

   8. After the packagers have been  given  a  few  days  to  compile  the
      packages, the release is announced on the salt-users mailing list.

   9. Log  into  RTD  and  add  the  new  release  there.   (Have to do it
      manually)

   Maintenance and Bugfix Releases
   Once a feature release branch has been cut  from  develop,  the  branch
   moves  into a "feature freeze" state. The new release branch enters the
   merge-forward chain and only bugfixes should be applied against the new
   branch. Once major bugs have been fixed, a bugfix release can be cut:

   1. On  the  release branch (i.e. 0.16), create an annotated tag for the
      revision release.  It should be preceded by  the  letter  v.   (e.g.
      v0.16.2)  Release candidates are unnecessary for bugfix releases.

   2. The  release should be packaged from this annotated tag and uploaded
      to PyPI.

   3. The packagers should be notified on the salt-packagers mailing  list
      so they can create packages for all the major operating systems.

   4. After  the  packagers  have  been  given  a  few days to compile the
      packages, the release is announced on the salt-users mailing list.

   For more information about the difference between  the  develop  branch
   and  bugfix  release  branches,  please refer to the Which Salt Branch?
   section of Salt's Contributing documentation.

   Salt Coding Style
   Salt is developed with a certain  coding  style,  while  the  style  is
   dominantly PEP 8 it is not completely PEP 8. It is also noteworthy that
   a few development techniques are also employed which should be  adhered
   to. In the end, the code is made to be "Salty".

   Most  importantly  though, we will accept code that violates the coding
   style and KINDLY ask the contributor to fix it, or go ahead and fix the
   code  on  behalf  of  the contributor. Coding style is NEVER grounds to
   reject code contributions, and is never grounds to talk down to another
   member  of  the community (There are no grounds to treat others without
   respect, especially people working to improve Salt)!!

   Linting
   Most Salt style conventions are  codified  in  Salt's  .pylintrc  file.
   Salt's pylint file has two dependencies: pylint and saltpylint. You can
   install these dependencies with pip:

      pip install pylint
      pip install saltpylint

   The .pylintrc file is found in the root of the Salt project and can  be
   passed as an argument to the pylint program as follows:

      pylint --rcfile=/path/to/salt/.pylintrc salt/dir/to/lint

   Variables
   Variables should be a minimum of three characters and should provide an
   easy-to-understand name of the object being represented.

   When keys and values are iterated over,  descriptive  names  should  be
   used to represent the temporary variables.

   Multi-word variables should be separated by an underscore.

   Variables which are two-letter words should have an underscore appended
   to them to pad them to three characters.

   Strings
   Salt follows a few rules when formatting strings:

   Single Quotes
   In Salt, all strings use single quotes unless there is  a  good  reason
   not to.  This means that docstrings use single quotes, standard strings
   use single quotes etc.:

      def foo():
          '''
          A function that does things
          '''
          name = 'A name'
          return name

   Formatting Strings
   All strings which require formatting  should  use  the  .format  string
   method:

      data = 'some text'
      more = '{0} and then some'.format(data)

   Make  sure  to use indices or identifiers in the format brackets, since
   empty brackets are not supported by python 2.6.

   Please do NOT use printf formatting.

   Docstring Conventions
   Docstrings should always add a newline, docutils takes care of the  new
   line and it makes the code cleaner and more vertical:

   GOOD:

      def bar():
          '''
          Here lies a docstring with a newline after the quotes and is the salty
          way to handle it! Vertical code is the way to go!
          '''
          return

   BAD:

      def baz():
          '''This is not ok!'''
          return

   When  adding  a  new  function  or  state,  where possible try to use a
   versionadded directive to denote when the function or state was added.

      def new_func(msg=''):
          '''
          .. versionadded:: 0.16.0

          Prints what was passed to the function.

          msg : None
              The string to be printed.
          '''
          print msg

   If you are uncertain what version should be used, either consult a core
   developer  in IRC or bring this up when opening your pull request and a
   core developer will add the proper version once your pull  request  has
   been  merged.  Bugfixes  will  be  available  in a bugfix release (i.e.
   0.17.1, the first bugfix release for 0.17.0), while  new  features  are
   held  for  feature  releases,  and this will affect what version number
   should be used in the versionadded directive.

   Similar to the above, when an existing function or  state  is  modified
   (for example, when an argument is added), then under the explanation of
   that new argument a versionadded directive should be used to  note  the
   version  in which the new argument was added. If an argument's function
   changes significantly, the versionchanged  directive  can  be  used  to
   clarify this:

      def new_func(msg='', signature=''):
          '''
          .. versionadded:: 0.16.0

          Prints what was passed to the function.

          msg : None
              The string to be printed. Will be prepended with 'Greetings! '.

          .. versionchanged:: 0.17.1

          signature : None
              An optional signature.

          .. versionadded 0.17.0
          '''
          print 'Greetings! {0}\n\n{1}'.format(msg, signature)

   Dictionaries
   Dictionaries should be initialized using {} instead of dict().

   See here for an in-depth discussion of this topic.

   Imports
   Salt code prefers importing modules and not explicit functions. This is
   both a style  and  functional  preference.  The  functional  preference
   originates  around  the  fact  that  the  module  import system used by
   pluggable modules will include callable objects (functions) that  exist
   in  the  direct  module  namespace.  This  is  not  only messy, but may
   unintentionally expose code python libs to the Salt interface and  pose
   a security problem.

   To say this more directly with an example, this is GOOD:

      import os

      def minion_path():
          path = os.path.join(self.opts['cachedir'], 'minions')
          return path

   This on the other hand is DISCOURAGED:

      from os.path import join

      def minion_path():
          path = join(self.opts['cachedir'], 'minions')
          return path

   The  time  when  this is changed is for importing exceptions, generally
   directly importing exceptions is preferred:

   This is a good way to import exceptions:

      from salt.exceptions import CommandExecutionError

   Absolute Imports
   Although absolute imports seems like an awesome idea, please do not use
   it.   Extra  care  would be necessary all over salt's code in order for
   absolute imports to work as supposed. Believe it,  it  has  been  tried
   before  and,  as  a  tried  example, by renaming salt.modules.sysmod to
   salt.modules.sys, all other salt modules which  needed  to  import  sys
   would have to also import absolute_import, which should be avoided.

   NOTE:
      An  exception to this rule is the absolute_import from __future__ at
      the top of each  file  within  the  Salt  project.  This  import  is
      necessary  for  Py3 compatibility. This particular import looks like
      this:

          from __future__ import absolute_import

      This import is required for all new Salt files and is a good idea to
      add  to  any  custom  states  or  modules.  However, the practice of
      avoiding absolute imports still applies to all  other  cases  as  to
      avoid a name conflict.

   Vertical is Better
   When  writing  Salt code, vertical code is generally preferred. This is
   not a hard rule but more of a guideline. As PEP 8 specifies, Salt  code
   should  not  exceed  79  characters  on  a line, but it is preferred to
   separate  code  out  into  more  newlines  in  some  cases  for  better
   readability:

      import os

      os.chmod(
              os.path.join(self.opts['sock_dir'],
                  'minion_event_pub.ipc'),
              448
              )

   Where   there  are  more  line  breaks,  this  is  also  apparent  when
   constructing a function with many arguments, something very  common  in
   state functions for instance:

      def managed(name,
              source=None,
              source_hash='',
              user=None,
              group=None,
              mode=None,
              template=None,
              makedirs=False,
              context=None,
              replace=True,
              defaults=None,
              saltenv=None,
              backup='',
              **kwargs):

   NOTE:
      Making  function  and class definitions vertical is only required if
      the  arguments  are  longer  then  80  characters.  Otherwise,   the
      formatting is optional and both are acceptable.

   Line Length
   For  function definitions and function calls, Salt adheres to the PEP-8
   specification of at most 80 characters per line.

   Non function definitions or function calls, please adopt a  soft  limit
   of  120  characters  per  line.  If  breaking the line reduces the code
   readability, don't break it. Still,  try  to  avoid  passing  that  120
   characters limit and remember, vertical is better...  unless it isn't

   Indenting
   Some  confusion  exists in the python world about indenting things like
   function  calls,  the  above  examples  use  8  spaces  when  indenting
   comma-delimited constructs.

   The confusion arises because the pep8 program INCORRECTLY flags this as
   wrong, where PEP 8, the document, cites only using  4  spaces  here  as
   wrong, as it doesn't differentiate from a new indent level.

   Right:

      def managed(name,
              source=None,
              source_hash='',
              user=None)

   WRONG:

      def managed(name,
          source=None,
          source_hash='',
          user=None)

   Lining up the indent is also correct:

      def managed(name,
                  source=None,
                  source_hash='',
                  user=None)

   This also applies to function calls and other hanging indents.

   pep8  and  Flake8  (and,  by  extension, the vim plugin Syntastic) will
   complain about the double indent for hanging indents.  This is a  known
   conflict  between  pep8 (the script) and the actual PEP 8 standard.  It
   is recommended  that  this  particular  warning  be  ignored  with  the
   following lines in ~/.config/flake8:

      [flake8]
      ignore = E226,E241,E242,E126

   Make  sure your Flake8/pep8 are up to date.  The first three errors are
   ignored by default and are present here to keep the behavior the  same.
   This will also work for pep8 without the Flake8 wrapper -- just replace
   all instances of 'flake8' with 'pep8', including the filename.

   Code Churn
   Many pull requests have been submitted that only churn code in the name
   of  PEP  8.  Code  churn  is  a  leading source of bugs and is strongly
   discouraged.  While style fixes are encouraged they should be  isolated
   to  a  single file per commit, and the changes should be legitimate, if
   there are any questions about whether  a  style  change  is  legitimate
   please   reference   this   document   and   the   official  PEP  8  (
   http://legacy.python.org/dev/peps/pep-0008/) document  before  changing
   code.  Many  claims  that  a  change is PEP 8 have been invalid, please
   double check before committing fixes.

   Salt code and internals
   Reference documentation on Salt's internal code.

   Contents
   salt.aggregation
   salt.utils.aggregation
   This library makes it possible  to  introspect  dataset  and  aggregate
   nodes when it is instructed.

   NOTE:
      The  following  examples with be expressed in YAML for convenience's
      sake:

      * !aggr-scalar will refer to Scalar python function

      * !aggr-map will refer to Map python object

      * !aggr-seq will refer for Sequence python object

   How to instructs merging
   This yaml document has duplicate keys:

      foo: !aggr-scalar first
      foo: !aggr-scalar second
      bar: !aggr-map {first: foo}
      bar: !aggr-map {second: bar}
      baz: !aggr-scalar 42

   but tagged values instruct Salt that overlapping  values  they  can  be
   merged together:

      foo: !aggr-seq [first, second]
      bar: !aggr-map {first: foo, second: bar}
      baz: !aggr-seq [42]

   Default merge strategy is keep untouched
   For  example, this yaml document still has duplicate keys, but does not
   instruct aggregation:

      foo: first
      foo: second
      bar: {first: foo}
      bar: {second: bar}
      baz: 42

   So the late found values prevail:

      foo: second
      bar: {second: bar}
      baz: 42

   Limitations
   Aggregation is permitted between tagged objects  that  share  the  same
   type.  If not, the default merge strategy prevails.

   For example, these examples:

      foo: {first: value}
      foo: !aggr-map {second: value}

      bar: !aggr-map {first: value}
      bar: 42

      baz: !aggr-seq [42]
      baz: [fail]

      qux: 42
      qux: !aggr-scalar fail

   are interpreted like this:

      foo: !aggr-map{second: value}

      bar: 42

      baz: [fail]

      qux: !aggr-seq [fail]

   Introspection
   TODO: write this part

   salt.utils.aggregation.aggregate(obj_a,       obj_b,       level=False,
   map_class=<class  'salt.utils.aggregation.Map'>,  sequence_class=<class
   'salt.utils.aggregation.Sequence'>)
          Merge obj_b into obj_a.

          >>> aggregate('first', 'second', True) == ['first', 'second']
          True

   class salt.utils.aggregation.Aggregate
          Aggregation base.

   class salt.utils.aggregation.Map(*args, **kwds)
          Map aggregation.

   salt.utils.aggregation.Scalar(obj)
          Shortcut for Sequence creation

          >>> Scalar('foo') == Sequence(['foo'])
          True

   class salt.utils.aggregation.Sequence
          Sequence aggregation.

   Exceptions
   Salt-specific  exceptions  should be thrown as often as possible so the
   various interfaces to Salt (CLI, API,  etc)  can  handle  those  errors
   appropriately and display error messages appropriately.

               
               salt.exceptions  This  module  is a central 
                                location  for   all   salt 
                                exceptions                 
               

   salt.exceptions
   This module is a central location for all salt exceptions

   exception salt.exceptions.AuthenticationError(message='')
          If sha256 signature fails during decryption

   exception salt.exceptions.AuthorizationError(message='')
          Thrown when runner or wheel execution fails due to permissions

   exception salt.exceptions.CommandExecutionError(message='', info=None)
          Used  when  a  module  runs a command which returns an error and
          wants to show the user the output gracefully instead of dying

   exception salt.exceptions.CommandNotFoundError(message='')
          Used in  modules  or  grains  when  a  required  binary  is  not
          available

   exception salt.exceptions.EauthAuthenticationError(message='')
          Thrown when eauth authentication fails

   exception  salt.exceptions.FileLockError(msg,  time_start=None,  *args,
   **kwargs)
          Used when an error occurs obtaining a file lock

   exception salt.exceptions.FileserverConfigError(message='')
          Used when invalid fileserver settings are detected

   exception    salt.exceptions.GitLockError(errno,    strerror,    *args,
   **kwargs)
          Raised  when  an uncaught error occurs in the midst of obtaining
          an update/checkout lock in salt.utils.gitfs.

          NOTE: While this uses the errno param  similar  to  an  OSError,
          this exception class is not as subclass of OSError. This is done
          intentionally, so that this exception class can be caught  in  a
          try/except without being caught as an OSError.

   exception salt.exceptions.LoaderError(message='')
          Problems loading the right renderer

   exception salt.exceptions.MasterExit
          Rise when the master exits

   exception salt.exceptions.MinionError(message='')
          Minion problems reading uris such as salt:// or http://

   exception salt.exceptions.NotImplemented(message='')
          Used  when  a  module  runs a command which returns an error and
          wants to show the user the output gracefully instead of dying

   exception salt.exceptions.PkgParseError(message='')
          Used when of the pkg modules cannot correctly parse  the  output
          from the CLI tool (pacman, yum, apt, aptitude, etc)

   exception salt.exceptions.PublishError(message='')
          Problems encountered when trying to publish a command

   exception salt.exceptions.SaltCacheError(message='')
          Thrown  when  a  problem was encountered trying to read or write
          from the salt cache

   exception salt.exceptions.SaltClientError(message='')
          Problem reading the master root key

   exception   salt.exceptions.SaltClientTimeout(msg,   jid=None,   *args,
   **kwargs)
          Thrown  when  a  job  sent  through one of the Client interfaces
          times out

          Takes the jid as a parameter

   exception salt.exceptions.SaltCloudConfigError(message='')
          Raised when a configuration setting  is  not  found  and  should
          exist.

   exception salt.exceptions.SaltCloudException(message='')
          Generic Salt Cloud Exception

   exception salt.exceptions.SaltCloudExecutionFailure(message='')
          Raised    when   too   much   failures   have   occurred   while
          querying/waiting for data.

   exception salt.exceptions.SaltCloudExecutionTimeout(message='')
          Raised when too much time has passed while querying/waiting  for
          data.

   exception salt.exceptions.SaltCloudNotFound(message='')
          Raised  when  some  cloud  provider  function cannot find what's
          being searched.

   exception salt.exceptions.SaltCloudPasswordError(message='')
          Raise when virtual terminal password input failed

   exception salt.exceptions.SaltCloudSystemExit(message, exit_code=1)
          This exception is raised when the execution should be stopped.

   exception salt.exceptions.SaltConfigurationError(message='')
          Configuration error

   exception salt.exceptions.SaltDaemonNotRunning(message='')
          Throw when a running master/minion/syndic is not running but  is
          needed to perform the requested operation (e.g., eauth).

   exception salt.exceptions.SaltException(message='')
          Base   exception  class;  all  Salt-specific  exceptions  should
          subclass this

          pack() Pack this exception into a serializable  dictionary  that
                 is safe for transport via msgpack

   exception salt.exceptions.SaltInvocationError(message='')
          Used  when  the wrong number of arguments are sent to modules or
          invalid arguments are specified on the command line

   exception salt.exceptions.SaltMasterError(message='')
          Problem reading the master root key

   exception salt.exceptions.SaltNoMinionsFound(message='')
          An attempt to retrieve a list of minions failed

   exception    salt.exceptions.SaltRenderError(message,    line_num=None,
   buf='', marker=' <======================', trace=None)
          Used when a renderer needs to raise an explicit error. If a line
          number and buffer string are passed, get_context will be invoked
          to get the location of the error.

   exception salt.exceptions.SaltReqTimeoutError(message='')
          Thrown  when  a  salt master request call fails to return within
          the timeout

   exception salt.exceptions.SaltRunnerError(message='')
          Problem in runner

   exception salt.exceptions.SaltSyndicMasterError(message='')
          Problem while proxying a request in the syndication master

   exception salt.exceptions.SaltSystemExit(code=0, msg=None)
          This exception is raised when an unsolvable  problem  is  found.
          There's nothing else to do, salt should just exit.

   exception salt.exceptions.SaltWheelError(message='')
          Problem in wheel

   exception salt.exceptions.TimedProcTimeoutError(message='')
          Thrown  when  a  timed  subprocess does not terminate within the
          timeout, or if the specified timeout is not an int or a float

   exception salt.exceptions.TokenAuthenticationError(message='')
          Thrown when token authentication fails

   exception salt.exceptions.VMwareApiError(message='', info=None)
          Used when a VMware object cannot be retrieved

   exception salt.exceptions.VMwareConnectionError(message='', info=None)
          Used when the client fails to  connect  to  a  either  a  VMware
          vCenter server or to a ESXi host

   exception salt.exceptions.VMwareSaltError(message='', info=None)
          Used when a VMware object cannot be retrieved

   salt.exceptions.get_error_message(error)
          Get human readable message from Python Exception

   Salt opts dictionary
   It  is  very  common  in the Salt codebase to see opts referred to in a
   number of contexts.

   For example, it can be seen as __opts__ in certain cases, or simply  as
   opts as an argument to a function in others.

   Simply  put,  this  data  structure  is  a dictionary of Salt's runtime
   configuration information that's passed around in order  for  functions
   to know how Salt is configured.

   When  writing  Python code to use specific parts of Salt, it may become
   necessary to initialize a copy of opts from scratch in order to have it
   available for a given function.

   To do so, use the utility functions available in salt.config.

   As  an  example,  here  is  how one might generate and print an options
   dictionary for a minion instance:

      import salt.config
      opts = salt.config.minion_config('/etc/salt/minion')
      print(opts)

   To generate and display opts for a master, the process is similar:

      import salt.config
      opts = salt.config.master_config('/etc/salt/master')
      print(opts)

   Unicode in Salt
   Though Unicode handling in large projects can often  be  complex,  Salt
   adheres  to  several  basic  rules  to  help  developers handle Unicode
   correctly.

   (For a  basic  introduction  to  this  problem,  see  Ned  Batchelder's
   excellent          intoroduction          to          the         topic
   <http://nedbatchelder.com/text/unipain/unipain.html>.

   Salt's basic workflow for Unicode handling is as follows:

   1) Salt should convert whatever data is passed on CLI/API  to  Unicode.
   Internally,  everything  that  Salt does should be Unicode unless it is
   printing to the screen or writing to storage.

   2. Modules  and  various  Salt  pluggable  systems  use  incoming  data
      assuming Unicode.
         2.1)  For  Salt  modules  that  query  an  API; the module should
         convert the data received from the API into Unicode.

         2.2) For Salt modules that shell out to get  output;  the  module
         should  convert  data received into Unicode. (This does not apply
         if using the cmd execution module, which should handle  this  for
         you.

         2.3)  For  Salt  modules which print directly to the console (not
         via an outputter) or which  write  directly  to  disk,  a  string
         should  be  encoded  when appropriate. To handle this conversion,
         the global variable __salt_system_encoding__ is available,  which
         declares the locale of the system that Salt is running on.

   3. When a function in a Salt module returns, it should return Unicode.

   4) When Salt delivers the data to an outputter or a returner, it is the
   job  of  the  outputter  or  returner  to  encode  the  Unicode  before
   displaying it on the console or writing it to storage.

   Salt Community Projects
   This  page contains links to Salt-related projects created by community
   members.  If you come across a useful project  please  add  it  to  the
   list!

   Hubblestack
   Hubble is a modular, open-source security compliance framework built on
   top  of  SaltStack.  The  project  provides   on-demand   profile-based
   auditing,    real-time    security   event   notifications,   automated
   remediation, alerting and reporting.

   http://hubblestack.io/

   alkali
   alkali is a collections  of  SaltStack  states  and  pillar  data  that
   provide  just  the  basics for provisioning Linux instances that may be
   built upon. alkali is a starter kit of sorts,  to  help  new  users  to
   SaltStack  get up-and-running quickly with the most commonly used, core
   packages.

   https://github.com/zulily/alkali

   buoyant
   buoyant leverages  docker  to  provide  an  alternative  to  VM-centric
   SaltStack  development  environments. buoyant containers may be spun up
   nearly instantly, once an initial docker image has been built.

   https://github.com/zulily/buoyant

   Salt Sandbox
   Salt Sandbox is a multi-VM Vagrant-based Salt  development  environment
   used  for  creating  and testing new Salt state modules outside of your
   production environment. It's also a great way to learn firsthand  about
   Salt and its remote execution capabilities.

   https://github.com/elasticdog/salt-sandbox

   Salt Vagrant Demo
   A Salt Demo using Vagrant.

   https://github.com/UtahDave/salt-vagrant-demo

   Salt's Test Suite: An Introduction
   NOTE:
      This tutorial makes a couple of assumptions. The first assumption is
      that you have a basic knowledge of Salt. To get up to  speed,  check
      out the Salt Walkthrough.

      The  second  assumption is that your Salt development environment is
      already configured and  that  you  have  a  basic  understanding  of
      contributing  to the Salt codebase. If you're unfamiliar with either
      of these topics, please refer to the Installing Salt for Development
      and the Contributing pages, respectively.

   Salt  comes  with  a powerful integration and unit test suite. The test
   suite allows for the fully automated run  of  integration  and/or  unit
   tests from a single interface.

   Salt's  test  suite is located under the tests directory in the root of
   Salt's code base and is divided into two  main  types  of  tests:  unit
   tests  and  integration tests. The unit and integration sub-test-suites
   are located in the tests directory, which  is  where  the  majority  of
   Salt's test cases are housed.

   Getting Set Up For Tests
   There are a couple of requirements, in addition to Salt's requirements,
   that need to be installed in order to run Salt's test  suite.  You  can
   install  these  additional  requirements using the files located in the
   salt/requirements directory, depending  on  your  relevant  version  of
   Python:

      pip install -r requirements/dev_python26.txt
      pip install -r requirements/dev_python27.txt

   Test Directory Structure
   As  noted  in  the  introduction to this tutorial, Salt's test suite is
   located in the tests directory in the root of Salt's  code  base.  From
   there,  the  tests  are  divided  into two groups integration and unit.
   Within each of  these  directories,  the  directory  structure  roughly
   mirrors  the  directory structure of Salt's own codebase.  For example,
   the files inside tests/integration/modules contains tests for the files
   located within salt/modules.

   NOTE:
      tests/integration  and tests/unit are the only directories discussed
      in this tutorial. With the exception of the tests/runtests.py  file,
      which is used below in the Running the Test Suite section, the other
      directories and files located in tests are outside the scope of this
      tutorial.

   Integration vs. Unit
   Given  that  Salt's  test  suite  contains  two  powerful,  though very
   different, testing approaches, when should you write integration  tests
   and when should you write unit tests?

   Integration  tests use Salt masters, minions, and a syndic to test salt
   functionality directly and focus on testing the  interaction  of  these
   components.  Salt's  integration  test runner includes functionality to
   run Salt execution modules, runners, states, shell  commands,  salt-ssh
   commands,  salt-api  commands,  and  more.  This  provides a tremendous
   ability to use Salt to test itself  and  makes  writing  such  tests  a
   breeze.   Integration  tests  are  the preferred method of testing Salt
   functionality when possible.

   Unit tests do not spin up any Salt  daemons,  but  instead  find  their
   value  in  testing  singular  implementations  of individual functions.
   Instead of testing against specific interactions, unit tests should  be
   used  to  test  a function's logic. Unit tests should be used to test a
   function's exit point(s) such as any return or raises statements.

   Unit tests are also useful in cases where writing an  integration  test
   might  not  be  possible. While the integration test suite is extremely
   powerful, unfortunately at this time, it does not cover all  functional
   areas  of  Salt's  ecosystem. For example, at the time of this writing,
   there is not a way to write integration tests for Proxy Minions.  Since
   the  test  runner  will need to be adjusted to account for Proxy Minion
   processes, unit tests can still provide some  testing  support  in  the
   interim by testing the logic contained inside Proxy Minion functions.

   Running the Test Suite
   Once all of the requirements are installed, the runtests.py file in the
   salt/tests directory is used to instantiate Salt's test suite:

      python tests/runtests.py [OPTIONS]

   The command above, if executed without any options, will run the entire
   suite  of  integration and unit tests. Some tests require certain flags
   to run, such as destructive tests. If these  flags  are  not  included,
   then  the  test  suite  will  only perform the tests that don't require
   special attention.

   At the end of the test run, you will see a summary output of the  tests
   that passed, failed, or were skipped.

   The  test  runner  also  includes a --help option that lists all of the
   various command line options:

      python tests/runtests.py --help

   You can also call the test runner as an executable:

      ./tests/runtests.py --help

   Running Integration Tests
   Salt's  set  of  integration  tests  use  Salt  to  test  itself.   The
   integration  portion  of  the  test  suite  includes some built-in Salt
   daemons that will spin up in preparation of the test run. This list  of
   Salt daemon processes includes:

   * 2 Salt Masters

   * 2 Salt Minions

   * 1 Salt Syndic

   These   various   daemons   are  used  to  execute  Salt  commands  and
   functionality within the test suite, allowing you  to  write  tests  to
   assert against expected or unexpected behaviors.

   A  simple example of a test utilizing a typical master/minion execution
   module  command  is  the  test  for  the  test_ping  function  in   the
   tests/integration/modules/test.py file:

      def test_ping(self):
          '''
          test.ping
          '''
          self.assertTrue(self.run_function('test.ping'))

   The test above is a very simple example where the test.ping function is
   executed by Salt's test suite runner and is asserting that  the  minion
   returned with a True response.

   Test Selection Options
   If you look in the output of the --help command of the test runner, you
   will see a section called Tests Selection Options.  The  options  under
   this  section contain various subsections of the integration test suite
   such as --modules, --ssh, or --states. By selecting any  one  of  these
   options, the test daemons will spin up and the integration tests in the
   named subsection will run.

      ./tests/runtests.py --modules

   NOTE:
      The testing subsections listed in the Tests Selection Options of the
      --help  output  only apply to the integration tests. They do not run
      unit tests.

   Running Unit Tests
   While ./tests/runtests.py executes the entire test suite  (barring  any
   tests requiring special flags), the --unit flag can be used to run only
   Salt's unit tests. Salt's unit tests include the tests located  in  the
   tests/unit directory.

   The  unit  tests  do  not  spin  up  any  Salt  testing  daemons as the
   integration  tests  do  and  execute  very  quickly  compared  to   the
   integration tests.

      ./tests/runtests.py --unit

   Running Specific Tests
   There  are  times  when  a  specific  test  file, test class, or even a
   single, individual test need to be executed, such as when  writing  new
   tests. In these situations, the --name option should be used.

   For  running a single test file, such as the pillar module test file in
   the integration test directory, you must provide the file path using  .
   instead of / as separators and no file extension:

      ./tests/runtests.py --name=integration.modules.pillar
      ./tests/runtests.py -n integration.modules.pillar

   Some  test  files  contain  only  one test class while other test files
   contain multiple test classes. To run a specific test class within  the
   file, append the name of the test class to the end of the file path:

      ./tests/runtests.py --name=integration.modules.pillar.PillarModuleTest
      ./tests/runtests.py -n integration.modules.pillar.PillarModuleTest

   To  run  a  single test within a file, append both the name of the test
   class the individual test belongs to, as well as the name of  the  test
   itself:

      ./tests/runtests.py --name=integration.modules.pillar.PillarModuleTest.test_data
      ./tests/runtests.py -n integration.modules.pillar.PillarModuleTest.test_data

   The  --name  and  -n  options  can  be  used  for unit tests as well as
   integration tests. The following  command  is  an  example  of  how  to
   execute a single test found in the tests/unit/modules/cp_test.py file:

      ./tests/runtests.py -n unit.modules.cp_test.CpTestCase.test_get_template_success

   Writing Tests for Salt
   Once  you're comfortable running tests, you can now start writing them!
   Be sure to review the Integration vs. Unit section of this tutorial  to
   determine  what  type  of test makes the most sense for the code you're
   testing.

   NOTE:
      There  are   many   decorators,   naming   conventions,   and   code
      specifications required for Salt test files. We will not be covering
      all of the these specifics in this tutorial.  Please  refer  to  the
      testing  documentation  links listed below in the Additional Testing
      Documentation section to learn more about these requirements.

      In the following sections, the test examples assume the  "new"  test
      is  added  to  a  test  file  that  is already present and regularly
      running  in  the  test  suite  and  is  written  with  the   correct
      requirements.

   Writing Integration Tests
   Since  integration  tests  validate  against  a running environment, as
   explained in the Running Integration Tests section  of  this  tutorial,
   integration  tests  are  very  easy  to  write  and  are  generally the
   preferred method of writing Salt tests.

   The following integration test is an example  taken  from  the  test.py
   file  in  the  tests/integration/modules  directory. This test uses the
   run_function  method  to  test  the  functionality  of  a   traditional
   execution module command.

   The  run_function method uses the integration test daemons to execute a
   module.function command as you would with Salt.  The  minion  runs  the
   function  and  returns. The test also uses Python's Assert Functions to
   test that the minion's return is expected.

      def test_ping(self):
          '''
          test.ping
          '''
          self.assertTrue(self.run_function('test.ping'))

   Args can be passed in to the run_function method as well:

      def test_echo(self):
          '''
          test.echo
          '''
          self.assertEqual(self.run_function('test.echo', ['text']), 'text')

   The next example is taken from the tests/integration/modules/aliases.py
   file and demonstrates how to pass kwargs to the run_function call. Also
   note that this test uses another salt function to  ensure  the  correct
   data  is present (via the aliases.set_target call) before attempting to
   assert what the aliases.get_target call should return.

      def test_set_target(self):
          '''
          aliases.set_target and aliases.get_target
          '''
          set_ret = self.run_function(
                  'aliases.set_target',
                  alias='fred',
                  target='bob')
          self.assertTrue(set_ret)
          tgt_ret = self.run_function(
                  'aliases.get_target',
                  alias='fred')
          self.assertEqual(tgt_ret, 'bob')

   Using  multiple  Salt  commands  in  this  manor  provides  two  useful
   benefits.  The  first  is that it provides some additional coverage for
   the aliases.set_target function.  The second benefit  is  the  call  to
   aliases.get_target  is not dependent on the presence of any aliases set
   outside of this test. Tests should not be  dependent  on  the  previous
   execution,  success, or failure of other tests. They should be isolated
   from other tests as much as possible.

   While it might be tempting to build out a test file where tests  depend
   on  one  another  before  running,  this  should  be avoided. SaltStack
   recommends that each test should test a single  functionality  and  not
   rely  on other tests. Therefore, when possible, individual tests should
   also be broken up into singular pieces.  These  are  not  hard-and-fast
   rules, but serve more as recommendations to keep the test suite simple.
   This helps with debugging code and related tests  when  failures  occur
   and  problems are exposed. There may be instances where large tests use
   many asserts to set up a  use  case  that  protects  against  potential
   regressions.

   NOTE:
      The examples above all use the run_function option to test execution
      module functions in a traditional master/minion environment. To  see
      examples  of  how  to  test  other  common  Salt  components such as
      runners, salt-api, and more, please refer to  the  Integration  Test
      Class Examples documentation.

   Destructive vs Non-destructive Tests
   Since  Salt  is  used  to  change the settings and behavior of systems,
   often, the best approach to run tests is to make actual changes  to  an
   underlying   system.    This   is  where  the  concept  of  destructive
   integration tests comes into play.  Tests can be written to  alter  the
   system  they  are  running on. This capability is what fills in the gap
   needed to properly test  aspects  of  system  management  like  package
   installation.

   To  write  a  destructive  test,  import  and  use  the destructiveTest
   decorator for the test method:

      import integration
      from salttesting.helpers import destructiveTest

      class PkgTest(integration.ModuleCase):
          @destructiveTest
          def test_pkg_install(self):
              ret = self.run_function('pkg.install', name='finch')
              self.assertSaltTrueReturn(ret)
              ret = self.run_function('pkg.purge', name='finch')
              self.assertSaltTrueReturn(ret)

   Writing Unit Tests
   As explained in the Integration vs.  Unit  section  above,  unit  tests
   should  be  written  to  test  the  logic  of a function. This includes
   focusing on testing return and raises  statements.  Substantial  effort
   should  be  made  to  mock external resources that are used in the code
   being tested.

   External resources that should be mocked include, but are  not  limited
   to,  APIs,  function  calls, external data either globally available or
   passed in through function arguments, file  data,  etc.  This  practice
   helps  to isolate unit tests to test Salt logic. One handy way to think
   about writing  unit  tests  is  to  "block  all  of  the  exits".  More
   information  about how to properly mock external resources can be found
   in Salt's Unit Test documentation.

   Salt's unit tests utilize Python's mock class as well as MagicMock. The
   @patch decorator is also heavily used when "blocking all the exits".

   A  simple  example  of  a  unit  test  currently  in use in Salt is the
   test_get_file_not_found test in the tests/unit/modules/cp_test.py file.
   This test uses the @patch decorator and MagicMock to mock the return of
   the call to Salt's cp.hash_file execution module function. This ensures
   that  we're  testing  the  cp.get_file  function  directly,  instead of
   inadvertently testing the  call  to  cp.hash_file,  which  is  used  in
   cp.get_file.

      @patch('salt.modules.cp.hash_file', MagicMock(return_value=False))
      def test_get_file_not_found(self):
          '''
          Test if get_file can't find the file.
          '''
          path = 'salt://saltines'
          dest = '/srv/salt/cheese'
          ret = ''
          self.assertEqual(cp.get_file(path, dest), ret)

   Note  that  Salt's  cp module is imported at the top of the file, along
   with all of the other necessary testing imports. The get_file  function
   is  then  called directed in the testing function, instead of using the
   run_function method as the integration test examples do above.

   The call to cp.get_file returns an empty string when a hash_file  isn't
   found.   Therefore,  the example above is a good illustration of a unit
   test "blocking the exits" via the @patch decorator, as well as  testing
   logic via asserting against the return statement in the if clause.

   There  are  more examples of writing unit tests of varying complexities
   available in the following docs:

   * Simple Unit Test Example

   * Complete Unit Test Example

   * Complex Unit Test Example

   NOTE:
      Considerable care should be  made  to  ensure  that  you're  testing
      something  useful  in  your  test functions. It is very easy to fall
      into a situation where you have  mocked  so  much  of  the  original
      function  that  the  test results in only asserting against the data
      you have provided. This results in a poor and fragile unit test.

   Checking for Log Messages
   To test to see if a given log message has been emitted,  the  following
   pattern can be used

      # Import logging handler
      from salttesting.helpers import TestsLoggingHandler

      # .. inside test
      with TestsLoggingHandler() as handler:
          for message in handler.messages:
              if message.startswith('ERROR: This is the error message we seek'):
                  break
              else:
                  raise AssertionError('Did not find error message')

   Automated Test Runs
   SaltStack   maintains   a   Jenkins  server  which  can  be  viewed  at
   https://jenkins.saltstack.com. The tests  executed  from  this  Jenkins
   server  create  fresh  virtual machines for each test run, then execute
   the destructive tests on the new, clean virtual  machine.  This  allows
   for the execution of tests across supported platforms.

   Additional Testing Documentation
   In  addition  to  this tutorial, there are some other helpful resources
   and documentation that go  into  more  depth  on  Salt's  test  runner,
   writing  tests for Salt code, and general Python testing documentation.
   Please see the follow references for more information:

   * Salt's Test Suite Documentation

   * Integration Tests

   * Unit Tests

   * MagicMock

   * Python Unittest

   * Python's Assert Functions

RELEASE NOTES

   See the version numbers page for more  information  about  the  version
   numbering scheme.

   Latest Branch Release
   Release Candidate

   Previous Releases
   Salt 2016.11.0 Release Notes - Codename Carbon
   New Features
   Docker Introspection and Configuration
   Major  additions have been made to the Docker support in 2016.11.0. The
   new addition allows Salt to  be  executed  within  a  Docker  container
   without  a  minion  running  or installed in the container. This allows
   states to be run inside a container, but  also  all  of  Salt's  remote
   execution  commands  to  be  run inside docker containers as well. This
   makes container introspection simple and powerful. See the tutorial  on
   using this new feature here:

   See Salt in Docker Containers.

   Advanced Ceph Control
   Our friends over at SUSE have delivered a powerful new tool to make the
   deployment of Ceph storage systems using Salt very easy. These new Ceph
   tools  allow  for  a  storage system to be easily defined using the new
   ceph.quorum state.

   Thorium Additions and Improvements
   The Thorium  advanced  reactor  has  undergone  extensive  testing  and
   updates.   These updates include many more Thorium states, a system for
   automating key management, the ability to use Thorium to easily replace
   old reactors and a great deal of stability and bug fixes.

   State Rollback Using Snapper
   Rollback  has been one of the most prevalent requests for Salt. We have
   researched it extensively and concluded that the only way to accomplish
   truly reliable rollback would be to execute it at the filesystem layer.
   To accomplish this we have introduced  Snapper  integration  into  Salt
   States.

   Snapper is a tool which allows for simple and reliable snapshots of the
   filesystem to be made. With the new snapper_states option set  to  True
   in  the  minion  config  a snapshot will be made before and after every
   Salt State run.

   These snapshots can be viewed, managed  and  rolled  back  to  via  the
   snapper execution module.

   Preserve File Perms in File States
   This  feature  has  been requested for years, the ability to set a flag
   and use the same file permissions for files deployed to a minion as the
   permissions  set  to  the  file  on  the master. Just set the keep_mode
   option on any file management state to True.

   Ponies!
   We all agreed that cowsay was just not good enough, install the ponysay
   command and the new pony outputter will work. Fun for the whole family!

   Additional Features
   * Minions  can  run  in  stand-alone  mode  to  use beacons and engines
     without having to connect to a master. (Thanks @adelcast!)

   * Added a salt runner to allow running salt modules via salt-run.

            salt-run salt.cmd test.ping
            # call functions with arguments and keyword arguments
            salt-run salt.cmd test.arg 1 2 3 a=1

   * Added SSL support to Cassandra CQL returner.  SSL can be  enabled  by
     setting  ssl_options  for  the  returner.   Also  added  support  for
     specifying protocol_version when establishing cluster connection.

   * The mode parameter in  the  file.managed  state,  and  the  file_mode
     parameter  in the file.recurse state, can both now be set to keep and
     the minion will keep the mode of the file from the  Salt  fileserver.
     This works only with files coming from sources prefixed with salt://,
     or files local to the minion (i.e. those which are absolute paths, or
     are prefixed with file://). For example:

        /etc/myapp/myapp.conf:
          file.managed:
            - source: salt://conf/myapp/myapp.conf
            - mode: keep

        /var/www/myapp:
          file.recurse:
            - source: salt://path/to/myapp
            - dir_mode: 755
            - file_mode: keep

   * The  junos  state  module  is now available. It has all the functions
     that are present in the junos execution module.

   * The  minion  data  cache  is  a  pluggable  data  store   now.   It's
     configurable with cache option. Default is localfs.

   * User names in client_acl support glob matching now.

   New Top File Merging Strategy for States
   A  new strategy called merge_all has been added to provide a new way of
   merging  top  file  matches  when  executing  a  highstate.   See   the
   top_file_merging_strategy documentation for further information.

   In   addition,  the  same  merging  strategy  was  not  functioning  as
   documented.  This has now been corrected. While this is  technically  a
   bugfix, we decided to hold a change in top file merging until a feature
   release to minimize user impact.

   Improved Archive Extraction Support
   The  archive.extracted  state  has  been  overhauled.  Notable  changes
   include the following:

   * When  enforcing ownership (with the user and/or group arguments), the
     if_missing argument no longer has any  connection  to  which  path(s)
     have  ownership enforced. Instead, the paths are determined using the
     either the newly-added  archive.list  function,  or  the  newly-added
     enforce_ownership_on argument.

   * if_missing  also is no longer required to skip extraction, as Salt is
     now able to tell which paths would be present  if  the  archive  were
     extracted. It should, in most cases, only be necessary in cases where
     a semaphore file is used to  conditionally  skip  extraction  of  the
     archive.

   * Password-protected  ZIP  archives are now detected before extraction,
     and the state fails without attempting to extract the archive  if  no
     password was specified.

   * By  default,  a  single  top-level  directory  is  enforced, to guard
     against 'tar-bombs'. This enforcement  can  be  disabled  by  setting
     enforce_toplevel to False.

   * The  tar_options  and  zip_options  arguments have been deprecated in
     favor of a single options argument.

   * The archive_format argument is now optional. The ending of the source
     argument  is  used  to guess whether it is a tar, zip or rar file. If
     the archive_format cannot  be  guessed,  then  it  will  need  to  be
     specified, but in many cases it can now be omitted.

   * Ownership enforcement is now performed irrespective of whether or not
     the archive needed to be extracted. This means that the state can  be
     re-run  after  the archive has been fully extracted to repair changes
     to ownership.

   A number of new arguments were also added. See  the  docs  py:func:docs
   for  the  archive.extracted  state  <salt.states.archive.extracted> for
   more information.

   Additionally, the following changes  have  been  made  to  the  archive
   execution module:

   * A new function (archive.list) has been added. This function lists the
     files/directories in an archive file, and supports a verbose argument
     that  gives a more detailed breakdown of which paths are files, which
     are directories, and which paths are at the top level of the archive.

   * A new function (archive.is_encrypted) has been added.  This  function
     will  return  True  if  the archive is a password-protected ZIP file,
     False if not. If the archive is not a ZIP  file,  an  error  will  be
     raised.

   * archive.cmd_unzip  now  supports  passing  a password, bringing it to
     feature parity with  archive.unzip.  Note  that  this  is  still  not
     considered to be secure, and archive.unzip is recommended for dealing
     with password-protected ZIP archives.

   * The default value for the extract_perms argument to archive.unzip has
     been changed to True.

   Improved Checksum Handling in file.managed, archive.extracted States
   When  the  source_hash  argument  for  these  states  refers  to a file
   containing checksums, Salt now looks for checksums matching the name of
   the  source URI, as well as the file being managed. Prior releases only
   looked for checksums matching the filename being managed. Additionally,
   a new argument (source_hash_name) has been added, which allows the user
   to disambiguate ambiguous matches when more than one matching  checksum
   is found in the source_hash file.

   A  more  detailed explanation of this functionality can be found in the
   file.managed documentation, in the section for the new source_hash_name
   argument.

   NOTE:
      This  improved functionality is also available in the 2016.3 (Boron)
      release cycle, starting with the 2016.3.5 release.

   Config Changes
   The following default config values were changed:

   * gitfs_ssl_verify: Changed from False to True

   * git_pillar_ssl_verify: Changed from False to True

   * winrepo_ssl_verify: Changed from False to True

   Grains Changes
   * All core grains containing VMWare have been changed to VMware,  which
     is  the  official  capitalization.   Additionally,  all references to
     VMWare in the documentation have been changed to VMware issue  30807.
     Environments  using  versions of Salt before and after Salt 2016.11.0
     should employ case-insensitive grain matching on these grains.

        {% set on_vmware = grains['virtual'].lower() == 'vmware' %}

   * On Windows the cpu_model grain has been changed to provide the actual
     cpu model name and not the cpu family.

     Old behavior:

        root@master:~# salt 'testwin200' grains.item cpu_model
        testwin200:
            ----------
            cpu_model:
                Intel64 Family 6 Model 58 Stepping 9, GenuineIntel

     New behavior:

        root@master:~# salt 'testwin200' grains.item cpu_model
        testwin200:
            ----------
            cpu_model:
                Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz

   Beacons Changes
   * The  loadavg  beacon  now  outputs  averages  as  integers instead of
     strings.  (Via issue 31124.)

   Runner Changes
   * Runners can now call out to utility modules via __utils__.

   * ref:Utility    modules    <writing-utility-modules>    (placed     in
     salt://_utils/)  are  now  able to be synced to the master, making it
     easier to use them in custom runners. A saltutil.sync_utils  function
     has  been  added  to  the saltutil runner to faciliate the syncing of
     utility modules to the master.

   Pillar Changes
   * Thanks to the new saltutil.sync_utils runner, it is now easier to get
     ref:utility  modules  <writing-utility-modules> synced to the correct
     location on the Master  so  that  they  are  available  in  execution
     modules called from Pillar SLS files.

   Network Automation: NAPALM
   Beginning  with  2016.11.0, network automation is inclued by default in
   the core of Salt. It is based on a  the  NAPALM  library  and  provides
   facilities  to  manage the configuration and retrieve data from network
   devices running widely used operating systems such: JunOS, IOS-XR, eOS,
   IOS, NX-OS etc.  - see the complete list of supported devices.

   The connection is established via the NAPALM proxy.

   In the current release, the following modules were included:

   * NAPALM grains - Select network devices based on their characteristics

   * NET execution module - Networking basic features

   * NTP execution module

   * BGP execution module

   * Routes execution module

   * SNMP execution module

   * Users execution module

   * Probes execution module

   * NTP peers management state

   * SNMP configuration management state

   * Users management state

   Junos Module Changes
   * The following new functionalities were added to the junos module

     * facts - Displays the facts gathered during the connection.

     * shutdown - Shut down or reboot a device running Junos OS.

     * install_config - Modify the configuration of a Junos device.

     * install_os - Install Junos OS software package.

     * zeroize  -  Remove  all  configuration  information  on the Routing
       Engines and reset all key values on a device.

     * file_copy - Copy file from proxy to the Junos device.

   Returner Changes
   * Any returner which implements a save_load function is now required to
     accept a minions keyword argument. All returners which ship with Salt
     have been modified to do so.

   Renderer Changes
   Added the  ability  to  restrict  allowed  renderers.  Two  new  config
   parameters,  renderer_whitelist  and  renderer_blacklist are introduced
   for this purpose.

   eAuth Changes
   * External auth modules' auth method can return an  ACL  list  for  the
     given  username  instead  of  True.  This  list should be in the same
     format as described in the eAuth documentation. It will be  used  for
     the user instead of one set in master config.

     Example  of  the  auth  method  return  that allows a user to execute
     functions in the test and network modules on the minions  that  match
     the web* target and allow access to wheel and runner modules:

        [{'web*': ['test.*',
                   'network.*']},
         '@wheel',
         '@runner']

   * External  auth  is  supported by salt-run and salt-key now. Note that
     master must be started to use them with eAuth.

   External Module Packaging
   Modules may  now  be  packaged  via  entry-points  in  setuptools.  See
   external module packaging tutorial for more information.

   Functionality Changes
   * The  onfail  requisite now uses OR logic instead of AND logic.  issue
     22370

   * The  consul  external  pillar  now  strips   leading   and   trailing
     whitespace.  issue 31165

   * The  win_system.py  state  is  now case sensitive for computer names.
     Previously computer names set with a  state  were  converted  to  all
     caps.  If  you  have  a  state setting computer names with lower case
     letters in the name that has been applied, the computer name will  be
     changed again to apply the case sensitive name.

   * The  mac_user.list_groups  function  in the mac_user execution module
     now lists  all  groups  for  the  specified  user,  including  groups
     beginning  with an underscore. In previous releases, groups beginning
     with an underscore were excluded from the list of groups.

   * The junos.call_rpc function in the junos execution module can now  be
     used   to   call  any  valid  rpc.  Earlier  it  used  to  call  only
     "get_software_information".

   * A new option for minions called master_tries  has  been  added.  This
     specifies  the  number  of times a minion should attempt to contact a
     master to attempt a  connection.   This  allows  better  handling  of
     occasional master downtime in a multi-master topology.

   * The  default hash_type is now sha256 instead of md5. You will need to
     make sure both your master and minion share the same hash_type.

   * Nodegroups consisting of a simple list of minion IDs can now also  be
     declared as a yaml list. The below two examples are equivalent:

        # Traditional way
        nodegroups:
          - group1: L@host1,host2,host3

        # New way (optional)
        nodegroups:
          - group1:
            - host1
            - host2
            - host3

   New Azure ARM Cloud Driver
   A  new  cloud  driver  has  been  added  for  Azure ARM, aka, the Azure
   Resource Manager. The older Azure driver is still required to work with
   the  older  Azure  API.  This  new driver works with the newer ARM API,
   which is managed via the newer Azure Portal website.

   New Modules
   Beacons
   * salt.beacons.avahi_announce

   * salt.beacons.bonjour_announce

   * salt.beacons.haproxy

   * salt.beacons.status

   Clouds
   * salt.cloud.clouds.azurearm

   Engines
   * salt.engines.hipchat

   Modules
   * salt.modules.boto_cloudwatch_event

   * salt.modules.celery

   * salt.modules.ceph

   * salt.modules.influx08

   * salt.modules.inspectlib.entities

   * salt.modules.inspectlib.fsdb

   * salt.modules.inspectlib.kiwiproc

   * salt.modules.inspector

   * salt.modules.libcloud_dns

   * salt.modules.openstack_mng

   * salt.modules.servicenow

   * salt.modules.testinframod

   * salt.modules.win_lgpo

   * salt.modules.win_pki

   * salt.modules.win_psget

   * salt.modules.win_snmp

   * salt.modules.xbpspkg

   Outputters
   * salt.output.pony

   Pillar
   * salt.pillar.csvpillar

   * salt.pillar.http_json

   * salt.pillar.makostack

   Returners
   * salt.returners.zabbix_return

   Runners
   * salt.runners.auth

   * salt.runners.event

   * salt.runners.smartos_vmadm

   * salt.runners.vistara

   SDB
   * salt.sdb.env

   States
   * salt.states.boto_cloudwatch_event

   * salt.states.csf

   * salt.states.ethtool

   * salt.states.influxdb08_database

   * salt.states.influxdb08_user

   * salt.states.libcloud_dns

   * salt.states.snapper

   * salt.states.testinframod

   * salt.states.win_lgpo

   * salt.states.win_pki

   * salt.states.win_snmp

   Thorium
   * salt.thorium.calc

   * salt.thorium.key

   * salt.thorium.runner

   * salt.thorium.status

   * salt.thorium.wheel

   Deprecations
   General Deprecations
   * env to saltenv

     All occurrences of env and some occurrences  of  __env__  marked  for
     deprecation  in Salt 2016.11.0 have been removed.  The new way to use
     the salt environment setting is with a variable called saltenv:

        def fcn(msg='', env='base', refresh=True, saltenv='base', **kwargs):

     has been changed to

        def fcn(msg='', refresh=True, saltenv='base', **kwargs):

     * 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.

          def fcn(msg='', refresh=True, saltenv='base', **kwargs):

          # will result in a warning log message
          fcn(msg='add more salt', env='prod', refresh=False)

     * If env (or __env__) is supplied as a keyword argument to a function
       that does not accept arbitrary keyword arguments, then python  will
       issue an error.

          def fcn(msg='', refresh=True, saltenv='base'):

          # will result in a python TypeError
          fcn(msg='add more salt', env='prod', refresh=False)

     * If  env  (or  __env__)  is  supplied  as a positional argument to a
       function, then undefined behavior will occur, as the removal of env
       and   __env__   from  the  function's  argument  list  changes  the
       function's signature.

          def fcn(msg='', refresh=True, saltenv='base'):

          # will result in refresh evaluating to True and saltenv likely not being a string at all
          fcn('add more salt', 'prod', False)

   * Deprecations in minion.py:

     * The salt.minion.parse_args_and_kwargs function  has  been  removed.
       Please use the salt.minion.load_args_and_kwargs function instead.

   Cloud Deprecations
   * The  vsphere  cloud  driver  has  been removed. Please use the vmware
     cloud driver instead.

   * The private_ip option in the linode cloud driver  is  deprecated  and
     has been removed. Use the assign_private_ip option instead.

   * The  create_dns_record and delete_dns_record functions are deprecated
     and  have  been  removed  from  the  digital_ocean  driver.  Use  the
     post_dns_record function instead.

   Execution Module Deprecations
   * The blockdev execution module had four functions removed:

     * dump

     * tune

     * resize2fs

     * wipe

     The disk module should be used instead with the same function names.

   * The   boto_vpc   execution   module   had   two   functions  removed,
     boto_vpc.associate_new_dhcp_options_to_vpc                        and
     boto_vpc.associate_new_network_acl_to_subnet in favor of more concise
     function        names,        boto_vpc.create_dhcp_options        and
     boto_vpc.create_network_acl, respectively.

   * The data execution module had getval and getvals functions removed in
     favor of one function, get, which combines the functionality  of  the
     removed functions.

   * File module deprecations:

     * The  contains_regex_multiline function was removed. Use file.search
       instead.

     * Additional command line options for file.grep should be passed  one
       at a time.  Please do not pass more than one in a single argument.

   * The lxc execution module has the following changes:

     * The run_cmd function was removed. Use lxc.run instead.

     * The  nic  argument  was  removed  from  the  lxc.init function. Use
       network_profile instead.

     * The clone argument was removed  from  the  lxc.init  function.  Use
       clone_from instead.

     * passwords  passed  to  the  lxc.init function will be assumed to be
       hashed, unless password_encrypted=False.

     * The restart argument for lxc.start  was  removed.  Use  lxc.restart
       instead.

     * The  old  style of defining lxc containers has been removed. Please
       use keys under which LXC profiles  should  be  configured  such  as
       lxc.container_profile.profile_name.

   * The  env  and  activate  keyword arguments have been removed from the
     install function in the pip execution  module.  The  use  of  bin_env
     replaces both of these options.

   * reg execution module

     Functions  in  the  reg execution module had misleading and confusing
     names for dealing with the Windows registry. They failed  to  clearly
     differentiate  between  hives,  keys, and name/value pairs. Keys were
     treated like value names.  There was no way to delete a key.

     New functions  were  added  in  2015.5  to  properly  work  with  the
     registry.  They  also  made it possible to edit key default values as
     well as delete an entire key tree recursively. With the new functions
     in place, the following functions have been deprecated:

     * read_key

     * set_key

     * create_key

     * delete_key

     Use the following functions instead:

     * for read_key use read_value

     * for set_key use set_value

     * for create_key use set_value with no vname and no vdata

     * for  delete_key  use  delete_key_recursive.  To delete a value, use
       delete_value.

   * The  hash_hostname  option  was  removed  from  the  salt.modules.ssh
     execution module. The hash_known_hosts option should be used instead.

   * The human_readable option was removed from the uptime function in the
     status execution module. The function was also updated in 2015.8.9 to
     return  a  more complete offering of uptime information, formatted as
     an easy-to-read dictionary. This updated function replaces  the  need
     for the human_readable option.

   * The  persist kwarg was removed from the win_useradd execution module.
     This option is no longer  supported  for  Windows.  persist  is  only
     supported as part of user management in UNIX/Linux.

   * The  zpool_list  function  in the zpool execution module was removed.
     Use list instead.

   Outputter Module Deprecations
   * The compact outputter has been removed. Set  state_verbose  to  False
     instead.

   Runner Module Deprecations
   * The  grains.cache  runner  no  longer  accepts outputter or minion as
     keyword arguments.  Users will need to specify an outputter using the
     --out option. tgt is replacing the minion kwarg.

   * The  fileserver  runner  no  longer  accepts  the  outputter  keyword
     argument. Users will need to specify an  outputter  using  the  --out
     option.

   * The  jobs  runner  no  longer  accepts the ouputter keyword argument.
     Users will need to specify an outputter using the --out option.

   * virt runner module:

     * The hyper  kwarg  was  removed  from  the  init,  list,  and  query
       functions.  Use the host option instead.

     * The  next_hyper  function  was  removed. Use the next_host function
       instead.

     * The hyper_info function was removed.  Use  the  host_info  function
       instead.

   State Module Deprecations
   * The  env  and  activate  keyword  arguments  were  removed  from  the
     installed function in the  pip  state  module.  The  use  of  bin_env
     replaces both of these options.

   * reg state module

     The  reg  state module was modified to work with the new functions in
     the execution module. Some logic was left in the reg.present and  the
     reg.absent  functions  to  handle  existing state files that used the
     final key in the name as the value name. That logic has been  removed
     so you now must specify value name (vname) and, if needed, value data
     (vdata).

     For example, a state file that adds the version  value/data  pair  to
     the  Software\Salt  key  in  the HKEY_LOCAL_MACHINE hive used to look
     like this:

        HKEY_LOCAL_MACHINE\\Software\\Salt\\version:
          reg.present:
            - value: 2016.3.1

     Now it should look like this:

        HKEY_LOCAL_MACHINE\\Software\\Salt
          reg.present:
            - vname: version
            - vdata: 2016.3.1

     A state file for removing the  same  value  added  above  would  have
     looked like this:

        HKEY_LOCAL_MACHINE\\Software\\Salt\\version:
          reg.absent:

     Now it should look like this:

        HKEY_LOCAL_MACHINE\\Software\\Salt
          reg.absent:
            - vname: version

     This  new  structure  is important as it allows salt to deal with key
     default values which was not possible before. If vname is not passed,
     salt will work with the default value for that hivekey.

     Additionally,  since  you  could only delete a value from a the state
     module, a new function (key_absent) has been added to  allow  you  to
     delete   a   registry  key  and  all  subkeys  and  name/value  pairs
     recursively. It uses the new delete_key_recursive function.

     For  additional  information  see  the  documentation  for  the   reg
     execution and state modules.

   * lxc  state  module: The following functions were removed from the lxc
     state module:

     * created: replaced by the present state.

     * started: replaced by the running state.

     * cloned: replaced by the present state. Use the clone_from  argument
       to set the name of the clone source.

   * The     hash_hostname     option     was     removed     from     the
     salt.states.ssh_known_hosts state. The hash_known_hosts option should
     be used instead.

   * The  always  kwarg  used  in the built function of the pkgbuild state
     module was removed. Use force instead.

   Utils Module Deprecations
   * The use of jid_dir and jid_load were removed from the salt.utils.jid.
     jid_dir  functionality  for  job_cache  management  was  moved to the
     local_cache  returner.  jid_load  data  is  now  retrieved  from  the
     master_job_cache.

   * ip_in_subnet  function in salt.utils.network.py has been removed. Use
     the in_subnet function instead.

   * The    iam    utils    module    had    two    functions     removed:
     salt.utils.iam.get_iam_region  and salt.utils.iam.get_iam_metadata in
     favor        of        the        aws         utils         functions
     salt.utils.aws.get_region_from_metadata   and   salt.utils.aws.creds,
     respectively.

   Salt 2016.11.1 Release Notes
   Version 2016.11.1 is a bugfix release for 2016.11.0.

   Changes for v2016.11.0..v2016.11.1
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-12-09T21:54:17Z

   Statistics:

   * Total Merges: 89

   * Total Issue references: 55

   * Total PR references: 155

   Changes:

   * PR #38182: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-12-09T21:25:47Z

     * PR  #38177:  (vutny)  Correct  cp.get_file_str  docstring  and  add
       integration tests

     * PR #38163: (Ch3LL) enabled ec2 cloud tests

     * PR #38153: (vutny) Master config includes may contain errors and be
       safely skipped

     * 23c0393 Merge pull request #38182 from rallytime/merge-2016.11

     * 627242a Merge branch '2016.3' into '2016.11'

       * 65b2ad7 Merge pull request #38163 from Ch3LL/enabled_ec2_cloud

         * be74c45 enabled ec2 cloud tests

       * b63f74e Merge pull request #38177 from vutny/fix-cp-get-file-str

         * a449980 Correct cp.get_file_str docstring and  add  integration
           tests

       * 7596313       Merge       pull      request      #38153      from
         vutny/master-includes-error-tolerance

         * cd0154e Master config includes may contain errors and be safely
           skipped

   * PR  #38158:  (cachedout)  Fix  type  problem  in  grains.filter_by  @
     2016-12-09T21:24:40Z

     * ISSUE #38094: (bartuss7) TypeError: object of type 'float'  has  no
       len() in grains.filter_by | refs: #38158

     * 8355adc Merge pull request #38158 from cachedout/issue_38094

     * e8196e2 Lint, remove set literal

     * 9f4ebb3 Fix type problem in grains.filter_by

   * PR  #38156:  (terminalmage) Remove rtag when windows minion refreshes
     early in state @ 2016-12-09T21:15:01Z

     * ISSUE #38090: (jf) pkg.installed does not seem to refresh the  repo
       database, no matter what | refs: #38113 #38156

     * 31a157d       Merge       pull       request       #38156      from
       terminalmage/fix-windows-refresh

     * 258bd4c Remove rtag when windows minion refreshes early in state

   * PR  #38183:  (cro)  Fix  bad   set   operations   when   setting   up
     securitygroups in AWS.  @ 2016-12-09T21:12:10Z

     * ISSUE  #37981:  (tazaki)  Salt-cloud ec2 vpc securitygroupid always
       returning default | refs: #38183

     * PR #37891: (isbm) rsync port to 2015.8

     * c638952 Merge pull request #38183 from cro/fix_37891

     * 0527d6f Fix bad set operations when setting  up  securitygroups  in
       AWS.  Fixes #37891.

   * fc95045  Reset  socket  default  timeout to None (fixes daemons_tests
     failures) (#38181)

     * PR #38181: (rallytime) Reset socket default timeout to None  (fixes
       daemons_tests failures)

   * PR #38148: (whiteinge) Remove ssh_async from NetapiClient clients; it
     is not implemented @ 2016-12-09T18:49:42Z

     * 7ccbedd      Merge       pull       request       #38148       from
       whiteinge/no-ssh-async-client

     * cb58cd4  Remove  ssh_async  from  NetapiClient  clients;  it is not
       implemented

   * PR  #38160:  (terminalmage)  Update  information  about  xz-utils  in
     archive state/module docs @ 2016-12-09T18:34:03Z

     * 8d4e194       Merge       pull       request       #38160      from
       terminalmage/update-archive-docs

     * 8e4ad3c Update information about xz-utils in  archive  state/module
       docs

   * PR   #38164:   (techhat)   Add   Azure   ARM  docs  for  2016.11.0  @
     2016-12-09T18:00:22Z

     * ISSUE #38024: (Ch3LL) 2016.11.0 release  notes  missing  azure  arm
       reference | refs: #38164

     * 05136f0 Merge pull request #38164 from techhat/azuredocs

     * 71b787e Add Azure ARM docs for 2016.11.0

   * PR  #38173:  (rallytime)  Bump  some  win*  module  deprecations from
     Nitrogen to Oxygen @ 2016-12-09T16:57:29Z

     * e3c858c      Merge       pull       request       #38173       from
       rallytime/update-win-deprecation-versions

     * 09a50b2 Bump some win* module deprecations from Nitrogen to Oxygen

   * PR   #38036:  (terminalmage)  archive.extracted:  fix  problems  with
     overwrite arg @ 2016-12-08T19:08:41Z

     * PR #37889: (isbm)  Allow  overwrite  archives  extraction  |  refs:
       #38036

     * 827bf59       Merge       pull       request       #38036      from
       terminalmage/archive-extracted-override

     * a1c70c7 archive.extracted: fix problems with overwrite arg

   * PR #38133: (terminalmage) Fix edge case in creation of trans tar  for
     salt-thin @ 2016-12-08T17:47:26Z

     * 50773a5 Merge pull request #38133 from terminalmage/zd1067

     * 71e0bd0 Fix edge case in creation of trans tar for salt-thin

   * PR #38138: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-12-07T20:15:56Z

     * PR #38134: (rallytime) Skip  daemon  unit  tests  when  running  on
       Python 2.6

     * 6026cb2 Merge pull request #38138 from rallytime/merge-2016.11

     * 28b56ea Merge branch '2016.3' into '2016.11'

     * 86091db Skip daemon unit tests when running on Python 2.6 (#38134)

   * PR #38130: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-12-07T20:11:19Z

     * ISSUE         #38091:         (tjyang)          [WARNING          ]
       salt.loaded.int.module.zenoss.__virtual__()  is  wrongly  returning
       None.  | refs: #38102

     * ISSUE #36707: (do3meli) slow FreeBSD sysctl module with test=true |
       refs: #36794

     * PR #38104: (rallytime) Back-port #36794 to 2016.3

     * PR  #38102: (rallytime) Add False + msg tuple return if requests is
       missing for zenoss module

     * PR #36794: (do3meli) FreeBSD sysctl module now handels  config_file
       parameter in show method | refs: #38104

     * 90478ef Merge pull request #38130 from rallytime/merge-2016.11

     * 4d7d9ab Merge branch '2016.3' into '2016.11'

       * d3d98fd4 Merge pull request #38102 from rallytime/fix-38091

         * 4f79d5a Add False + msg tuple return if requests is missing for
           zenoss module

       * 8c8cbc2 Merge pull request #38104 from rallytime/bp-36794

         * c906c8a Pylint fixes

         * da3ebf8 FreeBSD sysctl module now handels config_file parameter
           in show method

   * 1a42e24 Fix beacon index (#38129)

     * PR #38129: (Ch3LL) Fix beacon index

   * bbdfcab Add versionadded tags for network module funcs (#38127)

     * PR  #38127:  (rallytime)  Add  versionadded tags for network module
       funcs

   * PR #38043: (MTecknology) Debian networking fix @ 2016-12-07T17:32:18Z

     * ISSUE #38042: (MTecknology)  [2016.11.0]  Invalid  interfaces  file
       produced by debian_ip module | refs: #38043

     * fd06bab Merge pull request #38043 from MTecknology/2016.11

     * 6d5e132 Removing trailing whitespace from previous commit

     * f882674 Adding some options that are valid for inet6 blocks.

     * 81cb688 Better check for dual stack.

     * 525c746 May Cthulhu take mercy on my soul for this commit.

     * 300ca60 I guess this makes the previous commit a bit redundant, but
       I'm not sure if I want to remove it.

     * 6e7fc39 This now seems absurdly obvious, but  I'm  not  ruling  out
       that I'll break everything.

     * 82d2b89 Rolling back unit test.

     * b3edbcf Adding larger and more complete debian_ip unit test.

     * 3afd7b6 Adding the valid/documented 'slaves' option.

     * b6b1adc Typo: missing closing parenthesis

     * 756e41c Fixing a typo; line should not be commented

     * 32a1374 Corrects expected return value

     * 88f9d9f Mostly whitespace & comment changes

     * 41ffb8d Removing redundant line

     * 3a81686  Ensure  iface_dict  not being populated will not produce a
       stacktrace

     * 4de2cb2 Corrects regression in debian_ip/debian_eth.jinja

   * PR #38107: (cachedout) Status beacon should raise proper exception  @
     2016-12-07T17:21:49Z

     * PR  #38088:  (dmurphy18)  Updated  to  match formulas and allow for
       missing functions | refs: #38107

     * 4b9a7f2 Merge pull request #38107 from cachedout/supercede_38088

     * 73d7248 Change to log.debug per Tom

     * da135b1 Fix docs

     * 792b422 Pylint fix

     * 88e03bb Fix typo

     * a8ce153 Status beacon should raise proper exception

   * PR #38101: (lorengordon) Clarifies file.replace behavior on  symlinks
     @ 2016-12-07T13:27:11Z

     * da8f5ac       Merge       pull       request       #38101      from
       lorengordon/file-replace-note

     * 345990f Clarifies file.replace behavior on symlinks

   * PR #38113: (terminalmage) Revert  changes  to  refresh  tag  for  pkg
     states @ 2016-12-07T13:11:14Z

     * ISSUE  #38090: (jf) pkg.installed does not seem to refresh the repo
       database, no matter what | refs: #38113 #38156

     * d47761f Merge pull request #38113 from terminalmage/issue38090

     * 9f347df Revert changes to refresh tag for pkg states

   * PR #38120: (Da-Juan)  Fix  status  beacon  config  default  values  @
     2016-12-07T13:08:33Z

     * ISSUE #37976: (t0nyhays) Error when status beacon fires (2016.11.0)
       | refs: #38120

     * d4c34e0 Merge pull request #38120 from Da-Juan/2016.11

     * 7e4a35e Fix status beacon config default values

   * PR #38114: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-12-07T12:45:04Z

     * ISSUE  #38037:  (dmurphy18)  pkg.latest  and  yumpkg.latest_version
       return incorrect package versions 2016.3 and 2016.11 | refs: #38045

     * ISSUE #37939: (Talkless)  file.comment  always  report  changes  in
       test=True mode | refs: #38039

     * ISSUE  #35342:  (morganwillcock) win_pkg: refresh_db doesn't remove
       cached items which have been renamed or removed | refs: #38083

     * PR #38083: (twangboy) Only delete .sls files  from  winrepo-ng  [DO
       NOT MERGE FORWARD]

     * PR  #38059:  (rallytime)  Call  exec_test  for the Syndic daemon in
       tests.unit.daemons_test.py

     * PR #38057: (rallytime)  [2016.11]  Merge  forward  from  2016.3  to
       2016.11 | refs: #38059

     * PR  #38045:  (terminalmage)  yumpkg.py:  don't  include non-upgrade
       versions found by "yum list available"

     * PR #38039: (rallytime) Check to see if a line is already  commented
       before moving on

     * PR #38034: (cachedout) Modify daemons test to use multiprocessing |
       refs: #38059

     * 6868089 Merge pull request #38114 from rallytime/merge-2016.11

     * fec9dec Merge branch '2016.3' into '2016.11'

       * fbc8776 Merge pull request #38083 from twangboy/fix_refresh_db

         * 978af6d Remove only .sls files from the cached winrepo-ng

       * 9dcfdee Merge pull request #38059 from rallytime/daemons-test-fix

         * eb372b2 Add missing  "not"  statement:  The  last  syndic  test
           should assertFalse()

         * 4e10f8e    Call    exec_test   for   the   Syndic   daemon   in
           tests.unit.daemons_test.py

       * 9cd42b9 Merge pull request #38039 from rallytime/fix-37939

         * 1da7aac Update unit tests to account for additional file.search
           call

         * 8a685b1  Check  to  see  if  a line is already commented before
           moving on

         * f2c0455 Write an integration test demonstrating the issue

       * a34a763 Merge pull request #38045 from terminalmage/issue38037

         * 6528950 Simplify logic  for  matching  desired  pkg  arch  with
           actual pkg arch

         * 3babbcd  yumpkg.py: don't include non-upgrade versions found by
           "yum list available"

   * PR  #38109:   (gtmanfred)   mode   needs   to   be   an   integer   @
     2016-12-07T11:58:24Z

     * b9920e5 Merge pull request #38109 from gtmanfred/2016.11

     * 7546760 mode needs to be an integer

   * PR    #38103:    (rallytime)    Back-port   #37283   to   2016.11   @
     2016-12-06T23:12:59Z

     * PR #37283: (jeanpralo) Handle docker-compose up to version 1.9.0  |
       refs: #38103

     * PR #37215: (mschneider82) removed version check | refs: #37283

     * fd77dcb Merge pull request #38103 from rallytime/bp-37283

     * 11944df handle up to version 1.9.0

   * PR #38057: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     | refs: #38059 @ 2016-12-06T23:11:41Z

     * ISSUE  #37945:  (gstachowiak)   Missing   exception   handling   in
       salt.master.Maintenance. Process never completes.  | refs: #37961

     * ISSUE  #37867:  (tobiasBora) Bug into lsb_release that crash salt |
       refs: #37962

     * ISSUE #37737: (b-harper) python  client  api  CloudClient  multiple
       calls needed | refs: #37928

     * ISSUE #37059: (basepi) Beacon fileserver operations cause scheduled
       jobs with fileserver operations to hang | refs: #37899

     * ISSUE #35088: (Modulus)  salt/cloud/ec2.py  encoding  problems.   |
       refs: #37912

     * PR #38034: (cachedout) Modify daemons test to use multiprocessing |
       refs: #38059

     * PR #38002: (laleocen) fix broken yaml code block

     * PR #37995: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

     * PR   #37978:   (terminalmage)   Add    clarifying    language    to
       ext_pillar_first docs

     * PR  #37964: (terminalmage) Add clarification on expr_form usage and
       future deprecation

     * PR #37962: (cachedout) Catch possible exception from lsb_release

     * PR #37961: (cachedout) Handle empty tokens safely

     * PR #37950: (vutny) Set default Salt Master  address  for  a  Syndic
       (like for a Minion)

     * PR #37929: (gtmanfred) add list_nodes_min to nova driver

     * PR #37928: (techhat) Don't modify self.opts directly

     * PR   #37926:   (kontrolld)   Fixes   no   IPv6   functionality   in
       /etc/sysconfig/network

     * PR #37925: (kontrolld) Fix missing ipv6 options centos network

     * PR #37924: (cachedout) Update test for new gem ver

     * PR #37921: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

     * PR #37918: (rallytime)  [2015.8]  Update  version  numbers  in  doc
       config for 2016.11.0 release

     * PR  #37914:  (terminalmage)  Update  earlier release channels' docs
       with Carbon release notes

     * PR #37912: (attiasr) fix encoding problem aws responses

     * PR #37899: (DmitryKuzmenko) Clear  functions  context  in  schedule
       tasks for ZeroMQ.

     * PR  #37272:  (vutny)  Get  default  logging level and log file from
       default opts dict

     * 5d9d6b9 Merge pull request #38057 from rallytime/merge-2016.11

     * 3428840 Fix SaltKeyOptionParserTestCase test failures

     * 186e2d0   Don't   allow   libcloud   mock   module   injection   in
       unit/states/libcloud_dns_test.py either

     * d513a60 Do not allow libcloud to be injected as a mock value in the
       libcloud_dns_test

     * 74a417e Update the mocked cloud  configs  to  also  include  master
       configs

     * f2c8cb1 Better merge conflict resolution from the initial merge

     * 8fd53a4 Merge branch '2016.3' into '2016.11'

       * 6724fe4 Modify daemons test to use multiprocessing (#38034)

       * 6942d5d Merge pull request #37995 from rallytime/merge-2016.3

         * b44e179 Merge branch '2015.8' into '2016.3'

           * 7a7e367      Merge      pull      request     #37978     from
             terminalmage/ext_pillar_first-docs

             * 61ed9a8 Add clarifying language to ext_pillar_first docs

       * cd66c17 fix broken yaml code block (#38002)

       * 3dd45fb      Merge      pull      request       #37912       from
         attiasr/fix_aws_response_encoding

         * ba4ec4e use Requests result encoding to encode the text

         * abe4eb3 fix encoding problem aws responses

       * 69a74a4       Merge       pull      request      #37950      from
         vutny/fix-starting-up-syndic

         * 7d9bc9a syndic_master: correct default value, documentation and
           example config

         * 92a7c7e  Set default Salt Master address for a Syndic (like for
           a Minion)

       * 7f269bc  Add  clarification  on  expr_form   usage   and   future
         deprecation (#37964)

       * 1001987 Catch possible exception from lsb_release (#37962)

       * 330021c Handle empty tokens safely (#37961)

       * ea46639       Merge       pull      request      #37272      from
         vutny/fix-getting-default-logging-opts

         * e5ce523 Fix description in the Salt Syndic usage info

         * 518a3dd Add unit tests  for  Salt  parsers  processing  logging
           options

         * 83d6a44   Add   ssh_log_file   option   to  master  config  and
           documentation

         * c8a0915  Fix  configuration  example  and   documentation   for
           syndic_log_file option

         * e64dd3e Correct default attributes for various parser classes

         * 82a2e21 Fix default usage string for Salt command line programs

         * 45dffa2  Fix  readding  and updating logfile and pidfile config
           options for Salt API

         * f47253c  Fix  reading   and   applying   Salt   Cloud   default
           configuration

         * fad5bec Work with a copy of default opts dictionaries

         * b7c2481 Fix log_level_logfile config value type

         * 1bd76a1 Fix setting temporary log level if CLI option omitted

         * 121848c Fix obtaining log_granular_levels config setting

         * 44cf07f  Make  CLI  options  take  precedence  for  setting  up
           logfile_logger

         * 61afaf1 Fix setting option attributes when processing log_level
           and log_file

         * 3c60e23 Fix processing of log_level_logfile config setting

         * 55a0af5 Use attribute functions for getting/setting options and
           config values

         * c25f2d0 Fix getting Salt API default logfile option

         * f242237  Remove   processing   of   unused   and   undocumented
           cli_*_log_* config options

         * 2065e83  Get  default  logging level and file from default opts
           dict

       * f2f957d      Merge      pull      request       #37925       from
         kontrolld/add-ipv6-centos-network

         * ac2b477     Adding     IPv6     functionality     for    CentOS
           /etc/sysconfig/network

       * c07ad11      Merge      pull      request       #37899       from
         DSRCorporation/bugs/37059_schedule_task_hang

         * 9497748 Clear functions context in schedule tasks for ZeroMQ.

       * a55519d Merge pull request #37928 from techhat/issue37737

         * a09a60e Don't modify self.opts directly

       * 9d17f1c Merge pull request #37929 from gtmanfred/2016.3

         * c7d2c73 add list_nodes_min to nova driver

       * 3bb743b       Merge       pull      request      #37926      from
         kontrolld/fix-ipv6-centos-network

         * 3ed42e5 updated

         * 3b3bc4f Fixes no IPv6 functionality in /etc/sysconfig/network

       * 271170a Merge pull request #37921 from rallytime/merge-2016.3

         * 523a67c Merge branch '2015.8' into '2016.3'

           * 4cdc6cf Update earlier release  channels'  docs  with  Carbon
             release notes (#37914)

           * d31491a  [2015.8]  Update  version  numbers in doc config for
             2016.11.0 release (#37918)

       * 6cd6429 Merge pull request #37924 from cachedout/fix_gem_states

         * 894cca3 Update test for new gem ver

   * 9969544 Account for case where vim install already exists and  is  at
     an older version (#38112)

     * PR  #38112:  (rallytime) Account for case where vim install already
       exists and is at an older version

   * PR  #38021:  (mateiw)  Add  master_tops   support   in   salt-ssh   @
     2016-12-06T14:26:22Z

     * ISSUE  #19502: (kt97679) salt-ssh fails to run state.highstate with
       custom master_tops | refs: #38021

     * f8c67a9 Merge pull request #38021 from mateiw/salt-ssh_master_tops

     * 65a0f10 Add/remove newlines

     * 7037fa1 Add master_tops support in salt-ssh

   * 1bb31bb Start release notes file for 2016.11.1 release (#38084)

     * PR #38084: (rallytime)  Start  release  notes  file  for  2016.11.1
       release

   * PR  #37878:  (kstreee)  Makes  threads  avoid  blocking waiting while
     communicating using Zeromq.  @ 2016-12-05T19:50:46Z

     * 7829551 Merge pull request #37878 from kstreee/2016.11

     * 9103878 Fixes blocking waiting through implementing a  socket  pool
       class.

   * PR  #37987:  (rbjorklin)  consul_pillar  support  for limiting pillar
     exposure via minion targeting @ 2016-12-05T19:48:20Z

     * PR #37985: (rbjorklin) consul_pillar support  for  limiting  pillar
       exposure via minion targeting | refs: #37987

     * 0809ccd       Merge       pull       request       #37987      from
       rbjorklin/consul-pillar-target

     * 5d0454a Ignore W1401 (anomalous-backslash-in-string)

     * 2e929a5 Linting fixes

     * 171cab1 Fixed possible  incorrect  behavior  if  target  wasn't  on
       start/end of str

     * 7440582  consul_pillar  support  for  limiting  pillar exposure via
       minion targeting

   * PR  #38067:  (terminalmage)  Remove   virtual   funcs   for   archive
     state/module @ 2016-12-05T16:37:23Z

     * ISSUE  #38062:  (UtahDave)  archive execution module not loading on
       Windows in 2016.11.0 | refs: #38067

     * 83dcfe8 Merge pull request #38067 from terminalmage/issue38062

     * 2e0f26a Remove virtual funcs for archive state/module

   * PR #38058: (rallytime) Remove initdb dependency in postgres module  @
     2016-12-04T04:19:02Z

     * ISSUE  #38001:  (tomlaredo)  Regression  on  postgres_group.present
       ('postgres_group' __virtual__ returned False) | refs: #38023

     * ISSUE #37986: (marek-obuchowicz)  Module  postgres  -  wrong  docs,
       doesn't work with debian 8.5 | refs: #38023

     * ISSUE  #37935: (ipmb) Postgres module regression on 2016.11 | refs:
       #37946 #37993 #38023 #38058

     * PR #38023: (gtmanfred) Expand error message for postgres  states  |
       refs: #38058

     * PR  #37993:  (ticosax) Remove initdb dependency to consume postgres
       module.  | refs: #38058

     * c993367 Merge pull request #38058 from rallytime/remove-init-db-dep

     * c1ceeca Remove initdb dependency in postgres module

   * PR #38004: (terminalmage)  Fix  regression  in  user/group  mgmt  for
     archive.extracted @ 2016-12-02T18:28:49Z

     * ISSUE #37969: (lordcirth) Archive.extracted fails if -user: root is
       specified | refs: #38004

     * 1ac53e5 Merge pull request #38004 from terminalmage/issue37969

     * 23bb90a Add integration test for archive.extracted with  user/group
       set to root

     * e5ee721 Don't use simple boolean check on uid/gid

   * PR  #38051:  (Ch3LL)  add  docs  for  hash_type  change  to  sha256 @
     2016-12-02T18:11:36Z

     * ISSUE #37941: (L4rS6) Outdated documentation for 2016.11.x |  refs:
       #38051

     * e90cbbe Merge pull request #38051 from Ch3LL/fix_hash_docs

     * e95f88f add docs for hash_type change to sha256

   * PR  #38028:  (terminalmage)  Pass  full_return  to  saltutil.runner @
     2016-12-02T09:49:31Z

     * ISSUE #38000: (morganwillcock) 2016.11.0: saltutil.runner returns a
       different  dict  structure  and  breaks  template rendering | refs:
       #38028

     * 1b52289 Merge pull request #38028 from terminalmage/issue38000

     * 9bf13d5 Pass full_return to saltutil.runner

   * PR    #38044:    (terminalmage)    Remove    debugging     code     @
     2016-12-02T09:43:44Z

     * ISSUE  #37980:  (tveastman) Having 'git' in fileserver_backends and
       no gitfs_remotes defined causes a crash | refs: #38044

     * 41c44ff Merge pull request #38044 from terminalmage/issue37980

     * f70a040 Remove debugging code

   * PR #38035:  (dmurphy18)  Updated  to  return  status  from  make_repo
     similar to rpmbuild.py @ 2016-12-01T22:30:53Z

     * 9661258 Merge pull request #38035 from dmurphy18/fix_debbuild

     * 3bca96e   Updated  to  return  status  from  make_repo  similar  to
       rpmbuild.py

   * PR #38023: (gtmanfred) Expand error message  for  postgres  states  |
     refs: #38058 @ 2016-12-01T22:05:06Z

     * ISSUE  #38001:  (tomlaredo)  Regression  on  postgres_group.present
       ('postgres_group' __virtual__ returned False) | refs: #38023

     * ISSUE #37986: (marek-obuchowicz)  Module  postgres  -  wrong  docs,
       doesn't work with debian 8.5 | refs: #38023

     * ISSUE  #37935: (ipmb) Postgres module regression on 2016.11 | refs:
       #37946 #37993 #38023 #38058

     * 141b5c5 Merge pull request #38023 from gtmanfred/2016.11

     * 1aa43eb Expand error message for postgres states

     * ac72ee6 Revert "Updated the bins_dir to default to pg_bin #37935"

   * PR   #38026:   (rallytime)   Back-port   #38015    to    2016.11    @
     2016-12-01T19:16:15Z

     * PR #38015: (morsik) Typo fix | refs: #38026

     * 7948642 Merge pull request #38026 from rallytime/bp-38015

     * 11becf3 Typo fix

   * e51448f  Added Carbon release notes. Fixed sphinx errors in the file.
     (#38022)

     * PR #38022:  (DmitryKuzmenko)  Added  Carbon  release  notes.  Fixed
       sphinx errors in the file.

   * 6f34332 Adjust code examples to use the actual bootstrap-salt.sh file
     name (#38011)

     * PR #38011: (rallytime) Adjust  code  examples  to  use  the  actual
       bootstrap-salt.sh file name

   * PR  #37954:  (gtmanfred)  use  sleep from path for docker.sls_build @
     2016-11-30T18:08:45Z

     * ISSUE  #37940:  (alex-zel)   dockerng.sls_build   fails   on   some
       distributions | refs: #37954

     * 0a04127 Merge pull request #37954 from gtmanfred/2016.11

     * 9caf0b4 use sleep from path for docker.sls_build

   * PR  #37993:  (ticosax)  Remove  initdb dependency to consume postgres
     module.  | refs: #38058 @ 2016-11-30T18:08:13Z

     * ISSUE #37935: (ipmb) Postgres module regression on 2016.11 |  refs:
       #37946 #37993 #38023 #38058

     * 4ef5c98       Merge       pull       request       #37993      from
       ticosax/remove-initdb-requirement

     * c5c7a53 Remove initdb dependency to consume postgres module.

   * PR   #37997:   (cachedout)   Update   gem   test   for   2016.11    @
     2016-11-30T17:13:45Z

     * 2e55656 Merge pull request #37997 from cachedout/gem_test_carbon

     * 1d221aa Update gem test for 2016.11

   * PR      #37979:      (terminalmage)      Revert      addition      of
     pillar_roots_override_ext_pillar @ 2016-11-30T14:34:24Z

     * ISSUE #36723: (white-hat)  ext_pillar_first  option  is  broken  in
       2016.3 | refs: #36807

     * ISSUE #24501: (astehlik) Order in top.sls file is not respected for
       pillar data in local mode | refs: #31316

     * ISSUE #19332: (QuinnyPig) Nondeterminism in Pillar | refs: #31316

     * PR #36807: (terminalmage) Fix pillar merging when  ext_pillar_first
       is enabled | refs: #37979 #37979

     * PR  #31316:  (kraney)  Let  ext_pillar_first determine the override
       order | refs: #37979 #37979

     * ca3a948      Merge       pull       request       #37979       from
       terminalmage/revert-pillar-change

     * 6135dfa Revert addition of pillar_roots_override_ext_pillar

   * 186b3c7 Fix RST link format (#37958) (#37970)

     * PR #37970: (rallytime) Back-port #37958 to 2016.11

     * PR  #37958:  (mirceaulinic)  Fix  RST link format in Carbon release
       notes | refs: #37970

   * 6976be4 Pylint fix (#37971)

     * PR #37971: (rallytime) Lint 2016.11 sooner rather than later

     * PR #37955: (rallytime)  [2016.11]  Merge  forward  from  2016.3  to
       2016.11 | refs: #37971

   * PR  #37946:  (scott-w)  Updated  the  bins_dir to default to pg_bin @
     2016-11-29T16:48:27Z

     * ISSUE #37935: (ipmb) Postgres module regression on 2016.11 |  refs:
       #37946 #37993 #38023 #38058

     * 36f9140 Merge pull request #37946 from scott-w/37935-fix-bin-dir

     * d33d403 Restored missing initdb #37935

     * a041b9f Use Salt deprecation warning #37935

     * a967893 Updated the bins_dir to default to pg_bin #37935

   * PR  #37889: (isbm) Allow overwrite archives extraction | refs: #38036
     @ 2016-11-29T16:18:57Z

     * d8650c5 Merge pull request #37889 from isbm/isbm-states-archive-fix

     * e67706b Document the behaviour.

     * 1970814 Prevent crash during externally changed archive permissions

     * 91b4257 Add overwrite option so the extraction of the  archive  can
       be always performed.

     * e6958f7  Remove nonsense comment and react on generally absent path
       name

   * PR #37869: (isbm) Input sanitation (16.11) @ 2016-11-29T16:17:16Z

     * e2b9e58      Merge       pull       request       #37869       from
       isbm/isbm-input-sanitation-16.11

     * f9ec5d6 Use six instead of builtins

     * 203dfcb Use American spelling instead

     * 91ed307 Sanitise input for the keys and IDs

     * 86623f9  Add  a  stub  for  ID  sanitiser  (at  the  moment same as
       hostname)

     * 637144c Rename "general.py" to "sanitisers.py"

     * f2571fc Add hostname sanitiser

     * 3ae086a Add filename sanitiser

     * 816b1d1 Add general sanitisers

   * PR #37884: (isbm) Do not include "gpg-pubkey" packages, filtering  by
     their name @ 2016-11-28T21:11:37Z

     * e539a94       Merge       pull       request       #37884      from
       isbm/isbm-zypper-gpgkey-pkg-filter

     * 038374a Do not include "gpg-pubkey" packages,  filtering  by  their
       name

   * PR  #37882:  (attiasr) multiple issues in boto_rds state and module @
     2016-11-28T21:09:11Z

     * eb3d81a Merge pull request #37882 from attiasr/fix_missing_tags

     * 73b3c5f Add newline

     * 166c42b fix boto_rds.describe

     * ddd88ba fix boto_rds.describe  parameters and subnetgroup_present

     * bfe7f92 fix missing tags in call to boto_rds.exists

   * 8f986b2 Remove release candidate doc ref from 2016.11.0 release notes
     (#37931)

     * PR  #37931:  (rallytime)  Remove  release  candidate  doc  ref from
       2016.11.0 release notes

   * PR #37930: (cachedout) Remove dictionary comprehension in netusers  @
     2016-11-28T20:27:06Z

     * 3d2dabc Merge pull request #37930 from cachedout/fix_comp

     * 670e832 Remove dictionary comprehension in netusers

   * PR #37923: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-11-28T19:55:03Z

     * ISSUE #37870: (fj40crawler) salt.states.augeas.change returns  None
       when test=True | refs: #37895

     * ISSUE  #37732:  (dhaines)  list_semod()  (from  modules/selinux.py)
       incompatible with policycoreutils-2.5 (RHEL 7.3) | refs: #37736

     * ISSUE  #37287:  (AaronM-Cloudtek)  salt.states.ddns.present:   'NS'
       record type always returns as changed | refs: #37785

     * ISSUE  #32829:  (tyhunt99)  Dockerng appears to not be using docker
       registries pillar data | refs: #36893 #36893

     * PR #37916: (rallytime)  [2016.3]  Update  version  numbers  in  doc
       config for 2016.11.0 release

     * PR #37907: (Talkless) Fix server trust in test run of svn.latest

     * PR #37896: (toanju) rh networking: add missing values

     * PR     #37895:    (fj40crawler)    Change    return    value    for
       salt/states/augeas.py to be True instead of N...

     * PR #37886: (bdrung) Fix various spelling mistakes

     * PR #37866: (meaksh) Backport #37149 #36938 and #36784 to 2016.3

     * PR #37863: (rallytime) Back-port #36893 to 2016.3

     * PR #37857: (meaksh) Backport #37149 and #36938 to  2015.8  |  refs:
       #37866

     * PR #37856: (meaksh) Backport #36784 to 2015.8 | refs: #37866

     * PR  #37847:  (laleocen)  add  multiline encryption documentation to
       nacl

     * PR #37797: (clan) check count of columns after split

     * PR #37785: (AaronM-Cloudtek) respect  trailing  dot  in  ddns  name
       parameter

     * PR #37762: (twangboy) Add pre_versions to chocolatey.installed

     * PR #37736: (dhaines) handle semodule version >=2.4 (#37732) and fix
       typo

     * PR #37149: (dincamihai) Fix pkg.latest_version when latest  already
       installed | refs: #37866 #37857

     * PR  #36938:  (wanparo)  acl.delfacl:  fix  position of -X option to
       setfacl | refs: #37866 #37857

     * PR #36893: (tyhunt99) add option to force a  reauth  for  a  docker
       registry | refs: #37863

     * PR  #36784:  (moio)  OS  grains  for  SLES Expanded Support | refs:
       #37866 #37856

     * 0f8b187 Merge pull request #37923 from rallytime/merge-2016.11

     * da7f551 Don't let 2016.3 doc config changes overwrite  the  2016.11
       changes

     * dfedd11 Merge branch '2016.3' into '2016.11'

       * c35ba1f       Merge       pull      request      #37916      from
         rallytime/doc-update-2016.3

         * bd40592 [2016.3] Update  version  numbers  in  doc  config  for
           2016.11.0 release

       * e13a248       Merge       pull      request      #37785      from
         Cloudtek/ddns-respect-trailing-dot

         * 262e3b3 respect trailing dot in ddns name parameter

       * c03b389      Merge      pull      request       #37895       from
         fj40crawler/fix-augeas-return-for-test

         * ddc238d  Fixed  augeas_test.py  to  match  True  v.s.  None for
           test_change_in_test_mode

         * ef75c45 Merge branch '2016.3' of github.com:saltstack/salt into
           fix-augeas-return-for-test

         * b0fe0cd  Change  return  value  for salt/states/augeas.py to be
           True  instead  of  None  for  cases  where  salt  is  run  with
           test=True. Fixes #37870

       * fdbc31e Merge pull request #37907 from Talkless/patch-2

         * 072a319 Fix server trust in test run of svn.latest

       * f39fdf4 Merge pull request #37896 from toanju/2016.3

         * c953041 rh networking: add missing values

       * ea935c5 Merge pull request #37886 from bdrung/fix-typos

         * 9a51ba5 Fix various spelling mistakes

       * 371b0a8 Merge pull request #37736 from dhaines/issue-37732

         * 7ef590a Update selinux.py

         * 516a67e fix indexing error

         * 4e49c1e fix typo

         * b16f2d8 handle semodule version >=2.4 (#37732) and fix typo

       * 87aeb66 Merge pull request #37797 from clan/extfs

         * acf0f96 check count of columns after split

       * f7c7109       Merge       pull      request      #37762      from
         twangboy/fix_chocolatey_state

         * 9696b6d Use keyword args instead of relying on ordering

         * 398eaa0 Add pre_versions to the available arguments

       * 56baa92  Merge   pull   request   #37866   from   meaksh/2016.3-
         bp-37149-36938-36784

         * 9d8d578 Fix pkg.latest_version when latest already installed

         * ffca0d4 - acl.delfacl: fix position of -X option to setfacl

         * 3dfed6b Adjust linux_acl unit test argument ordering

         * f185ecd core.py: quote style fixed

         * 8404d13  Setting up OS grains for SLES Expanded Support (SUSE's
           Red Hat compatible platform)

       * d0cc7f0 Merge pull request #37863 from rallytime/bp-36893

         * 4c70534 Add versionadded to reauth option in dockerng module

         * 5ca2c38 added documentation for the new reuth option in  docker
           registry configuration

         * 5b0c11a add option to force a reauth for a docker registry

       * b17a118 add multiline encryption documentation to nacl (#37847)

   * 1427115  Add  a release notes reference to the docker-sls tutorial (
     #37927)

     * PR  #37927:  (thatch45)  Add  a  release  notes  reference  to  the
       docker-sls tutorial

   * d204099  [2016.11] Update version numbers in doc config for 2016.11.0
     release (#37917)

     * PR #37917: (rallytime) [2016.11]  Update  version  numbers  in  doc
       config for 2016.11.0 release

   * PR  #37890:  (bbinet)  Fix  support  for  extra_mods='six' to add six
     module to a thin.tgz tarball @ 2016-11-28T13:53:06Z

     * ee00592 Merge pull request #37890 from bbinet/fix-genthin-six

     * 7fceaa3 Fix support for extra_mods='six' to add  six  module  to  a
       thin.tgz tarball

   * 47d21d9  Don't skip pillar compilation when master_type=='disable' (
     #37843)

     * ISSUE #37713: (aboe76) masterless  minion  can't  call  pillar.item
       from pillar stack (development branch) | refs: #37843

     * PR  #37843:  (terminalmage)  Don't  skip  pillar  compilation  when
       master_type=='disable'

     * PR #32521: (adelcast) Fix salt-call on  standalone  minion  case  |
       refs: #37843

   * 16ce844 Eliminate warning when 'ssl' not set (#37849)

     * ISSUE  #37449:  (thatch45) Allow TLS connections in the Tornado TCP
       transport | refs: #37776 #37859

     * PR #37849: (skizunov) Eliminate warning when 'ssl' not set

     * PR  #37776:  (DmitryKuzmenko)  Full  TLS/SSL  options  support   as
       provided by Tornado TCPServer.  | refs: #37849

   * 0c607cc An example configuration for TLS/SSL. (#37859)

     * ISSUE  #37449:  (thatch45) Allow TLS connections in the Tornado TCP
       transport | refs: #37776 #37859

     * PR #37859: (DmitryKuzmenko) TLS example config

   * 7c1cfa8 Clarify the master_type docs (#37841)

     * PR #37841: (terminalmage) Clarify the master_type docs

   * 2bc42b8 PY3: Fix exception when handling  connect  exception  in  TCP
     transport (#37831)

     * PR  #37831:  (skizunov)  PY3:  Fix  exception when handling connect
       exception in TCP transport

   * PR #37829: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-11-22T15:26:00Z

     * ISSUE   #37787:   (elyulka)  user.present  state  fails  to  change
       loginclass on FreeBSD | refs: #37827

     * ISSUE #37751: (freach) Documentation  salt.states.dockerng.running:
       "privileged" property undocumented | refs: #37789

     * ISSUE  #37653:  (gravyboat)  Salt.cron  docs don't wrap @hourly and
       @daily correctly in quotes for the examples | refs: #37816

     * ISSUE #37383: (edwardsdanielj) Orchestration arguments (kwarg)  not
       being   interperted   /  How  I  learned  to  stop  worrying  about
       documentation and love experimenting | refs: #37817

     * ISSUE  #31953:  (sjorge)  Documentation  for  salt.states.cron   is
       incorrect | refs: #32157

     * ISSUE  #19269:  (markuskramerIgitt) Undocumented  feature names: of
       file.directory | refs: #37823

     * ISSUE  #15697:  (arthurlogilab)  keystone.user_present  should  not
       re-set the password when user exists | refs: #37821

     * ISSUE #5999: (pille) libvirt.keys does not work | refs: #37820

     * PR #37827: (silenius) add missing chloginclass

     * PR #37826: (rallytime) Update branch refs to more relevant branch

     * PR #37823: (rallytime) Add "names" option to file state docs: point
       users to highstate doc examples

     * PR #37822: (laleocen) add  documenation  for  multiline  encryption
       using nacl | refs: #37826

     * PR #37821: (rallytime) Clarify keystone.user_present password state
       docs with default behavior

     * PR #37820: (rallytime) Add some dependency documentation to libvirt
       docs

     * PR  #37817:  (rallytime)  Update  orchestrate  runner file.copy doc
       example

     * PR #37816: (rallytime) Back-port #32157 to 2016.3

     * PR #37812: (rallytime) Back-port #37790 to 2016.3

     * PR #37811: (rallytime) Back-port #37789 to 2016.3

     * PR #37810: (rallytime) Back-port #37775 to 2016.3

     * PR #37790: (sofixa) Update cloud/proxmox.rst with more options  and
       LXC | refs: #37812

     * PR #37789: (fedusia) issue: 37751 | refs: #37811

     * PR     #37775:     (calve)     Document    python    argument    in
       salt.states.virtualenv_mod | refs: #37810

     * PR #37772: (bdrung) Support initializing OpenSSL 1.1

     * PR #32157: (cachedout) Add quotes to cron doc | refs: #37816

     * dd81d2f Merge pull request #37829 from rallytime/merge-2016.11

     * 3d6d32e Merge branch '2016.3' into '2016.11'

     * aa37487 add missing chloginclass (#37827)

     * 0e74bad Update branch refs to more relevant branch (#37826)

     * 6a9b49c Add "names" option to  file  state  docs:  point  users  to
       highstate doc examples (#37823)

     * aaf587d  Clarify  keystone.user_present  password  state  docs with
       default behavior (#37821)

     * c300863 Add some dependency documentation to libvirt docs (#37820)

     * 485270f Merge pull request #37772 from bdrung/openssl1.1

       * 819c965 Support initializing OpenSSL 1.1

     * 4910912 Update orchestrate runner file.copy doc example (#37817)

     * c5d3d8b Merge pull request #37816 from rallytime/bp-32157

       * d9c2971 Add quotes to cron doc

     * 97e6b6a Merge pull request #37812 from rallytime/bp-37790

       * ca3b6e7 Update proxmox.rst with more options and LXC

     * 27703c5 Merge pull request #37811 from rallytime/bp-37789

       * ba3fef4  fix comment

       * a021f76 issue: 37751 Add documentation for option privileged

     * adac9d7 Merge pull request #37810 from rallytime/bp-37775

       * 2bed914 Document python argument in salt.states.virtualenv_mod

   * c66b51b network.routes should not raise exception if no interface  (
     #37794)

     * PR #37794: (sjorge) network.routes should not raise exception if no
       interface

   * PR #37815: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-11-21T20:22:49Z

     * ISSUE   #37742:  (blaketmiller)  Cannot  match  on  nodegroup  when
       checking minions | refs: #37763

     * ISSUE  #37725:  (secumod)  salt-call  incorrectly   parses   master
       hostname:port from minion config | refs: #37766

     * PR #37766: (cachedout) Fix ip/port issue with salt-call

     * PR #37763: (cachedout) Add nodegroup check to ckminions

     * 628c4a3 Merge pull request #37815 from rallytime/merge-2016.11

     * c6b5fd3 Merge branch '2016.3' into '2016.11'

       * 7de7844 Add nodegroup check to ckminions (#37763)

       * d674369 Fix ip/port issue with salt-call (#37766)

   * PR  #37776: (DmitryKuzmenko) Full TLS/SSL options support as provided
     by Tornado TCPServer.  | refs: #37849 @ 2016-11-21T20:11:52Z

     * ISSUE #37449: (thatch45) Allow TLS connections in the  Tornado  TCP
       transport | refs: #37776 #37859

     * 0b30b93       Merge       pull       request       #37776      from
       DSRCorporation/features/37449_tls

     * 6857b9b Documented new TLS/SSL settings.

     * e42898f  Full  TLS/SSL  options  support  as  provided  by  Tornado
       TCPServer.

   * PR #37773: (rallytime) [2016.11] Merge forward from 2016.3 to 2016.11
     @ 2016-11-18T19:18:42Z

     * ISSUE #36629: (yhekma) The pillar run module does not honor saltenv
       | refs: #37738

     * ISSUE #33709: (msummers42) Any/All Salt-SSH invocations in 2016.3.0
       Fails  with  AttributeError:  'module'  object  has  no   attribute
       'BASE_THORIUM_ROOTS_DIR' | refs: #37767

     * PR #37767: (cachedout) Add thorium path to syspaths

     * PR #37760: (hu-dabao) Fix couchbase returner and add couple of more
       features

     * PR #37745: (cro) Switch default filter tag for ONE  resources  from
       user only to all resources

     * PR #37738: (terminalmage) Allow pillar.get to retrieve fresh pillar
       data when saltenv passed

     * 3835f91 Merge pull request #37773 from rallytime/merge-2016.11

     * c859fc9 Merge branch '2016.3' into '2016.11'

     * c62ff6b Add thorium path to syspaths (#37767)

     * bff949f Merge pull request #37760 from hu-dabao/fix_cb_returner

       * de372f2 1. returner no need to check whether the jid  exists  for
         external  job  cache  setup 2. add full_ret to return doc so that
         the document  will  be  informative  3.  make  ttl  as  a  config
         attribute  because  salt-minion does not have keep_jobs attribute
         4. add password into config attribute  5.  update  the  documents
         accordingly

     * 1f976ac Merge pull request #37738 from terminalmage/issue36629

       * da46678  Allow  pillar.get  to  retrieve  fresh  pillar data when
         saltenv passed

     * 7aee7fc Switch default filter tag for ONE resources from user  only
       to all resources (#37745)

   * PR   #37764:   (mirceaulinic)   Doc   fixes  and  replace  feature  @
     2016-11-18T03:15:31Z

     * 6f0f70c Merge pull request #37764 from cloudflare/NET-UPDATE

     * c3f0202 Replace feature and doc fixes

   Salt 2016.3.0 Release Notes - Codename Boron
   Known Issues
   WARNING:
      Some Salt Masters may need to apply a patch for Default Job Cache to
      prevent a possible crash

      An  issue  exists  that  prevents  the Salt master from cleaning the
      default job cache.  This  issue  can  cause  an  overconsumption  of
      resources  resulting  in a crash. 2016.3.0 Salt masters should apply
      the patch in
      :PR:`33555`
      . This issue will be addressed in 2016.3.1.

   * issue  33516:  When  upgrading  from   2015.8.10   to   2016.3.0   on
     centos7/redhat7 salt-minion must be restarted twice.

   * issue 33517: SPM does not work on amazon linux 2015 in 2016.3.0.

   Backwards-incompatible Changes
   * The  default  path for the extension_modules master config option has
     been changed.  Prior to this release, the location  was  a  directory
     named extmods in the Salt cachedir. On most platforms, this would put
     the extension_modules directory in /var/cache/salt/extmods.   It  has
     been  moved  one  directory  down,  into the master cachedir. On most
     platforms, this is /var/cache/salt/master/extmods. Most  users  won't
     have  to  worry  about this, but those who have been manually placing
     custom runners  into  /var/cache/salt/extmods/runners,  or  ouputters
     into  /var/cache/salt/extmods/output,  etc. will be affected by this.
     To transition, it is recommended  not  to  simply  move  the  extmods
     directory into /var/cache/salt/master, but to copy the custom modules
     into the salt fileserver under salt://_runners, salt://_output,  etc.
     and sync them using the functions in the new saltutil runner.

   * The pkg.check_db function has been removed for yum/dnf.

   Core Changes
   * The onchanges requisite now fires if any watched state changes. issue
     19592.

   * The ext_pillar functions must now accept a minion  ID  as  the  first
     argument.  This  stops  the  deprecation path started in Salt 0.17.x.
     Before this minion ID first argument was introduced,  the  minion  ID
     could  be  retrieved accessing __opts__['id'] losing the reference to
     the master ID initially set in opts. This  is  no  longer  the  case,
     __opts__['id'] will be kept as the master ID.

   * Custom  types  can now be synced to the master using the new saltutil
     runner.  Before,  these  needed  to  manually  be  placed  under  the
     extension_modules  directory. This allows custom modules to easily be
     synced to the master to make them  available  when  compiling  Pillar
     data.   Just   place  custom  runners  into  salt://_runners,  custom
     outputters into salt://_output, etc. and use the functions  from  the
     saltutil runner to sync them.

   * The client_acl configuration options were renamed to publisher_acl.

   * Added a new --config-dump option (issue 26639).

   * TCP  Transport  presence  events  were updated to work with a NAT (PR
     30629).

   * A minion_pillar_cache setting was added to save rendered pillar  data
     to  cachedir  for  later  use  when  file_client  is set to local (PR
     30428).

   * Added the ability for binary data (such  as  a  license  key)  to  be
     distributed via pillar using the file.managed (issue 9569).

   * Scheduled jobs now include success and retcode (issue 24237).

   * The  saltversioninfo  grain  was  changed  from a string to a list to
     enable reading values by index. (PR 30082).

   * A pillar_merge_lists option was added to enable  recursively  merging
     pillar  lists  by  aggregating  them  instead  of  replacing them (PR
     30062).

   * Grain values reported  by  Debian  8  (jessie)  when  lsb-release  is
     installed were updated for consistency (PR 28649).

   * A  new  option  for  minions called master_tries has been added. This
     specifies the number of times a minion should attempt  to  contact  a
     master  to  attempt  a  connection.  This  allows  better handling of
     occasional master downtime in a multi-master topology.

   * The default directory for deploying the salt-thin tarball has changed
     for salt-ssh. It is now /var/tmp instead of /tmp. Users may also wish
     to delete any directories in /tmp ending with _salt/. (issue 32771)

   External Module Packaging
   Modules may  now  be  packaged  via  entry-points  in  setuptools.  See
   external module packaging tutorial for more information.

   Cloud Changes
   * Refactored  the  OpenNebula  driver and added numerous --function and
     --action commands  to  enhance  Salt  support  for  image,  template,
     security  group,  virtual  network  and virtual machine management in
     OpenNebula.

   * Added execution/state  modules  to  support  the  deployment  of  AWS
     cognito identity pools (PR 31094).

   * Added  ability  to  set  tags  and listener policies on a AWS ELB (PR
     27552).

   Platform Changes
   * Renamed modules related to OS X. The following module filenames  were
     changed.  The virtual name remained unchanged.

   * PR #30558: renamed osxdesktop.py to mac_desktop.py

   * PR #30557: renamed macports.py to mac_ports.py

   * PR #30556: renamed darwin_sysctl.py to mac_sysctl.py

   * PR #30555: renamed brew.py to mac_brew.py

   * PR #30552: renamed darwin_pkgutil.py to mac_pkgutil.py

   Package Support
   * Ubuntu  Xenial:  Packages for Ubuntu Xenial (16.04) are available for
     2016.3.0 and onwards. See repo.saltstack.com  for  more  information.
     Note  that  Xenial  comes  with  Debian's  packaged  version  of Salt
     2015.8.8 and official repo.saltstack.com packages are  available  for
     2015.8 releases beginning with Salt 2015.8.11.

   Proxy Minion Changes
   The deprecated config option enumerate_proxy_minions has been removed.

   As  mentioned  in  earlier  documentation,  the add_proxymodule_to_opts
   configuration variable defaults to False in this release.   This  means
   if    you    have    proxymodules    or    other    code   looking   in
   __opts__['proxymodule'] you will need to  set  this  variable  in  your
   /etc/salt/proxy file, or modify your code to use the __proxy__ injected
   variable.

   The __proxyenabled__ directive now only applies  to  grains  and  proxy
   modules  themselves.   Standard execution modules and state modules are
   not prevented from loading for proxy minions.

   Support has been added to Salt's loader allowing custom proxymodules to
   be placed in salt://_proxy.  Proxy minions that need these modules will
   need to be restarted to pick up any changes.  A  corresponding  utility
   function,  saltutil.sync_proxymodules,  has  been  added  to sync these
   modules to minions.

   Enhancements  in  grains  processing  have  made  the  __proxyenabled__
   directive  somewhat  redundant  in  dynamic  grains  code.  It is still
   required, but best practices for the  __virtual__  function  in  grains
   files  have  changed.   It  is  now  recommended  that  the __virtual__
   functions check to make sure they are  being  loaded  for  the  correct
   proxytype, example below:

      def __virtual__():
          '''
          Only work on proxy
          '''
          try:
              if salt.utils.is_proxy() and \
                 __opts__['proxy']['proxytype'] == 'ssh_sample':
                  return __virtualname__
          except KeyError:
              pass

          return False

   The  try/except  block  above  exists because grains are processed very
   early in the proxy minion startup process, sometimes earlier  than  the
   proxy key in the __opts__ dictionary is populated.

   Grains  are  loaded so early in startup that no dunder dictionaries are
   present, so __proxy__, __salt__, etc. are not available.  Custom grains
   located  in  /srv/salt/_grains and in the salt install grains directory
   can now take a single argument, proxy, that is identical to  __proxy__.
   This enables patterns like

      def get_ip(proxy):
          '''
          Ask the remote device what IP it has
          '''
          return {'ip':proxy['proxymodulename.get_ip']()}

   Then  the  grain  ip  will  contain  the result of calling the get_ip()
   function in the proxymodule called proxymodulename.

   Proxy  modules  now  benefit   from   including   a   function   called
   initialized().   This function should return True if the proxy's init()
   function has been successfully called.  This is needed to  make  grains
   processing easier.

   Finally,  if  there  is a function called grains in the proxymodule, it
   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 False  in
   this  release.  It will default to True in the release after next.  The
   next release is codenamed Carbon, the following is Nitrogen.

   The example proxy minions rest_sample and ssh_sample have been  updated
   to reflect these changes.

   Syndic Updates
   A  major  performance  and  management issue was found and fixed in the
   syndic. This makes the Salt  Syndic  substantially  more  reliable  and
   performant.  Please make sure that the syndic and the master of masters
   which syndics attach to are updated, otherwise the syndic  fixes  alone
   can  cause  minor  performance  issues  with  older  master of masters.
   Please update masters first, then syndics.  Minions do not need  to  be
   updated for this fix to work.

   Module Changes
   * file   execution   module:   show_diff  is  deprecated  in  favor  of
     show_changes. (PR 30988)

   * reg execution module:

     * Removed the following deprecated functions from the reg module  (PR
       30956):

       * read_key

       * set_key

       * create_key

       * delete_key

     * Removed force parameter from reg state module

     * Fixed virtual function in state

     * Improved error information for reg.delete_value function

   * jboss7   execution  module:  deployed  function  was  decoupled  from
     Artifactory by  removing  Artifactory-specific  functionality.   Note
     that  the  changes  in  some of the function arguments break existing
     state files, see issue 30515 and PR 3080 for details.

   * pkg state module: The wait function was  removed,  the  functionality
     was replaced with the onchanges requisite (PR 30297).

   * firewalld state module: A permanent argument was added add_port. Note
     that permanent defaults to True, which changes previous behavior  (PR
     30275).  A  bind function was also added that allows binding zones to
     interfaces and sources (PR 29497).

   * journald beacon module: The event string was  updated  to  include  a
     tag.  Note  this  this  might  impact existing reactors based on this
     beacon.  (PR 30116).

   * postgres_privileges state module: The default value  of  the  prepend
     argument was changed from None to public.

   * zenoss  execution  module: The add_device function was updated with a
     default value of 1000 for prod_state to match the  documentation  (PR
     28924).

   * The  etcd  execution  module, state module, returner module, and util
     module were refactor (PR 28599). This refactor changes error  returns
     for several functions (primarily edge cases):

     * get: Used to return '' on key-not-found. Now returns None.

     * set: Used to return '' on issues setting keys. Now returns None.

     * ls: Used to return {path: {}} on key-not-found. Now returns None.

     * Tree: Used to return {} on key-not-found. Now returns None.

   * smartos_virt  execution  module:  Updated  to  use  most  of  the new
     smartos_vmadm (PR 28284).

   * apache_conf state module, apache_module state module, and apache_site
     state  module:  the  enable  and  disable  functions  were renamed to
     enabled and disabled, respectively.  In  PR  33562,  these  functions
     were  readded  and  properly  deprecated  and will be removed in Salt
     Nitrogen.  This fix will be available in 2016.3.1.  As a  workaround,
     try

        apache_module.enable{{ 'd' if grains.saltversioninfo == [2016, 3, 0] else '' }}

   New Features
   Thorium - Provisional New Reactor
   The  2016.3 release introduces the new Thorium Reactor. This reactor is
   an  experimental  new  feature  that  implements  a  flow   programming
   interface  using  the  salt state system as the engine. This means that
   the Thorium reactor uses a classic state  tree  approach  to  create  a
   reactor  that  can  aggregate event data from multiple sources and make
   aggregate decisions about executing reactions.

   This feature is both experimental and provisional, it  may  be  removed
   and  APIs may be changed. This system should be considered as ambitious
   as the Salt State System in that the scope  of  adding  a  programmable
   logic engine of this scale into the event systems is non trivial.

   See Thorium Complex Reactor.

   Improved Mac OS Support
   Improved Solaris Support
   A  lot  of work was done to improve support for SmartOS. This work also
   resulted in improvements for Solaris and illumos as SmartOS.

   * rewrite of vmadm module (SmartOS)

   * rewrite of imgadm module (SmartOS)

   * deprecation of virt module in favor of vmadm (SmartOS)

   * implemented smartos state (SmartOS)

   * improved zpool module add SmartOS, illumos and Solaris support

   * improved zfs module add SmartOS, illumos and Solaris support

   * implemented zpool state

   * implemented zfs state implemented  solaris_system  system  module  to
     provide better Solaris support (PR 30519)

   * other minor fixes to grains, localmod, ...

   Tornado Transport
   IMPORTANT:
      The Tornado Transport wire protocol was changed in 2016.3, making it
      incompatible with 2015.8 (PR 29339).

   Windows DSC Integration (Experiemental)
   Dimension Data Cloud Support
   A SaltStack Cloud driver for Dimension Data Public Cloud, provides  the
   driver  functionality  to  service  automation for any of the Dimension
   Data Public Cloud locations:

   * Deploy new virtual machines

   * List and query virtual machine images

   * Destroy and query virtual machines

   Documentation of the Dimension Data SaltStack integration is  found  on
   developer.dimensiondata.com

   Minion Blackout
   During  a  blackout,  minions  will  not  execute  any remote execution
   commands, except for  saltutil.refresh_pillar.  Blackouts  are  enabled
   using a special pillar key, minion_blackout set to True.

   See Minion Blackout.

   Splunk Returner
   A  Splunk  Returner that uses HTTP Event Collector is now available (PR
   30718).

   SQLCipher Pillar Module
   Support was added for retrieving pillar data via  queries  to  SQLCiper
   databases (PR 29782).

   New Modules
   The  following  list  contains  a link to the new modules added in this
   release.

   Beacons
   * beacons.adb

   * beacons.glxinfo

   * beacons.memusage

   * beacons.network_settings

   * beacons.proxy_example

   * beacons.salt_proxy

   Engines
   * engines.docker_events

   * engines.redis_sentinel

   * engines.slack

   * engines.sqs_events

   * engines.thorium

   Execution Modules
   * modules.bcache

   * modules.beacons

   * modules.boto_cloudtrail

   * modules.boto_datapipeline

   * modules.boto_iot

   * modules.boto_lambda

   * modules.boto_s3_bucket

   * modules.chronos

   * modules.cytest

   * modules.dockercompose

   * modules.dsc

   * modules.ethtool

   * modules.github

   * modules.infoblox

   * modules.iwtools

   * modules.jenkins

   * modules.linux_ip

   * modules.mac_assistive

   * modules.mac_brew

   * modules.mac_defaults

   * modules.mac_desktop

   * modules.mac_keychain

   * modules.mac_pkgutil

   * modules.mac_ports

   * modules.mac_power

   * modules.mac_service

   * modules.mac_shadow

   * modules.mac_softwareupdate

   * modules.mac_sysctl

   * modules.mac_system

   * modules.mac_timezone

   * modules.mac_xattr

   * modules.marathon

   * modules.minion

   * modules.openvswitch

   * modules.opkg

   * modules.philips_hue

   * modules.proxy

   * modules.pushbullet

   * modules.restartcheck

   * modules.s6

   * modules.salt_proxy

   * modules.ssh_package

   * modules.ssh_service

   * modules.sysfs

   * modules.vboxmanage

   * modules.win_certutil

   * modules.win_dism

   * modules.win_dism

   * modules.win_license

   * modules.win_iis

   * modules.win_task

   * modules.zabbix

   Pillar
   * pillar.http_yaml

   * pillar.stack

   Proxy
   * proxy.chronos

   * proxy.junos

   * proxy.marathon

   * proxy.phillips_hue

   * proxy.ssh_sample

   Roster
   * roster.range

   States
   * states.apache_conf

   * states.apache_site

   * states.boto_cloudtrail

   * states.boto_datapipeline

   * states.boto_iot

   * states.boto_lamda

   * states.boto_s3_bucket

   * states.chocolatey

   * states.chronos_job

   * states.firewall

   * states.github

   * states.gpg

   * states.grafana_dashboard

   * states.grafana_datasource

   * states.infoblox

   * states.jenkins

   * states.mac_assistive

   * states.mac_defaults

   * states.mac_keychain

   * states.mac_xattr

   * states.marathon_app

   * states.openvswitch_bridge

   * states.openvswitch_port

   * states.postgres_cluster

   * states.proxy

   * states.salt_proxy

   * states.virt

   * states.win_certutil

   * states.win_dism

   * states.win_license

   * states.zabbix_host

   * states.zabbix_hostgroup

   * states.zabbix_user

   * states.zabbix_usergroup

   Salt 2016.3.1 Release Notes
   Version 2016.3.1 is a bugfix release for 2016.3.0.

   Final Release of Debian 7 Packages

   Regular security support for Debian 7 ended on April 25th  2016.  As  a
   result, 2016.3.1 and 2015.8.10 will be the last Salt releases for which
   Debian 7 packages are created.

   Changes for v2016.3.0..v2016.3.1
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-06-08T22:43:50Z

   Total Merges: 87

   Changes:

   * PR #33866: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #33860:  (cachedout)  Allow  socket  closes  when  the  socket is
     disconnected

   * b183a36 Set master and cloud to log level warning (#33861)

   * PR #33698: (opdude) Vsphere fixes

   * PR #33771: (twangboy) Additional functionality to win_dism.py

   * PR #33851: (ticosax) [dockerng] Add support for edge  case  when  Cmd
     and Entrypoint can't be blanked

   * PR #33821: (cachedout) Restore default log level to warning

   * PR  #33767:  (amontalban)  Fix  #33604 implementation when 'geom disk
     list' does not output rotat...

   * PR #33806: (cachedout) Work around upstream cherrypy bug

   * PR #33776: (danslimmon) Fixed ACL user comparison. Resolves
     `#33754`_
     .

   * PR #33763: (abednarik) Insert --no-refresh before install in Zypper.

   * PR #33764: (terminalmage) Merge instead of update pillar overrides

   * PR #33772: (danslimmon) Fixed spelling of "through"

   * PR #33651: (cachedout) Restore grains context to renderers

   * PR #33757: (cachedout) Reminder not to return  non-serializable  data
     from states

   * PR   #33670:   (rallytime)   Handle   non-ascii   package   names  in
     state.format_log

   * PR #33723: (rallytime) Back-port #33641 to 2016.3

   * PR #33748: (ticosax) HostConfig has been  introduced  by  docker  api
     version 1.15

   * PR #33745: (eliasp) Typo (privilages  privileges)

   * PR #33562: (jfindlay) states.apache_*: readd and deprecate enable and
     disable

   * PR #33659: (danslimmon) Added test mode to states.dockerng. Resolves
     `#33632`_
     .

   * PR #33696:  (clburlison)  Update  mac  native  package  for  upcoming
     release

   * PR #33710: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * e87c310 backport #33599 to 2016.3 (#33682)

   * 377556a Undo __repr__() and __str__() parts of d5a7dcc (#33688)

   * 778b290 Remove explicit PW column default from mysql_user (#33690)

   * PR #33680: (rallytime) Back-port #32942 to 2016.3

   * PR #33677: (twangboy) Pass kwargs to cmd.run

   * PR  #33648: (terminalmage) salt.modules.pkgng: Fix incorrect usage of
     _pkg()

   * PR #33646: (jfindlay) Fix more tmp paths on MacOS

   * PR #33656: (cachedout) Fix indentation error in minion.py

   * PR #33637: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * b7230bd Back-port #33613 to 2016.3 (#33638)

   * PR #33606: (danslimmon) Fixed ini.options_absent. Resolves
     `#33590`_
     .

   * PR #33604: (kev009) Fix
     `#33578`_
      disks grain

   * 259529e Use correct state name in libvirt formula doc (#33631)

   * PR #33603: (sjorge) allow esky packages to be build on base64 2015Q4

   * PR #33576: (tomlaredo) Fix
     `#33565`_
      (typo causes invalid syntax)

   * PR #33549: (thatch45) Fix for
     `#33530`_

   * PR #33538: (anlutro) Fix a KeyError if group is provided but not user
     in cmd states

   * PR #33550: (jacobhammons) Fixes display of thorium docs

   * PR #33509: (twangboy) Detect System Architecture for Mac Build

   * PR  #33522: (jfindlay) rework modules.mac_brew.latest_version to work
     around brew version inconsistency

   * PR #33519: (jacobhammons) New doc site layout, 2016.3.0 release  note
     known issue additions

   * PR #33508: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #33505: (twangboy) Fix build script where pip didn't work

   * PR   #33076:   (cachedout)   Avoid  second  grains  load  on  windows
     multiprocessing

   Salt 2016.3.2 Release Notes
   Version 2016.3.2 is a bugfix release for 2016.3.0.

   Returner Changes
      * Any returner which implements a save_load function is now required
        to  accept  a  minions  keyword argument. All returners which ship
        with Salt have been modified to do so.

   Changes for v2016.3.1..2016.3.2
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-07-27T15:47:45Z

   Statistics:

   * Total Merges: 198

   Changes:

   * PR  #34946: (anlutro) Fix virtualenv behavior when requirements files
     are in subdirectories

   * PR #34957: (sjmh) Don't fall through to checking auth entries

   * PR #34971: (cachedout) Increase timeout for grains test

   * PR #34951: (vutny) Fix #34873

   * PR #34935: (rallytime) Avoid UnboundLocalError in beacons module

   * PR #34956: (cachedout) Increase all run_script timeouts to 30s

   * PR #34933: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34916: (cachedout) Master performance improvement

   * PR #34911: (cachedout) Backport #34906

   * PR #34906: (cachedout) Set timeout for run_salt in test suite

   * PR  #34898:  (hrumph)  Stop  multiple  refreshes   during   call   to
     pkg.list_upgrades

   * PR   #34915:   (abednarik)  Update  service_rh  provider  to  exclude
     XenServer >= 7.

   * PR #34926: (rallytime) Lint #34923

   * PR #34923: (eliasp) Handle  exception  when  no  Slack  API  key  was
     provided

   * PR #34910: (cachedout) Fix grains error on proxy minions

   * PR #34864: (jmacfar) Check for version in list of installed versions

   * PR #34902: (rallytime) Back-port #34878 to 2016.3

   * PR #34878: (abednarik) Add VirtuozzoLinux is yumpkg enable list.

   * PR  #34901:  (rallytime)  Add  VirtuozzoLinux  to the list of enabled
     distros for rpm.py

   * PR #34900: (rallytime) Add VirtuozzoLinux to enabled  platforms  list
     in rh_service.py

   * PR #34887: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34869:  (terminalmage)  Fail  git.latest states with uncommitted
     changes when force_reset=False

   * PR #34862: (thatch45) Fix salt-ssh cacheing issue

   * PR #34859: (cachedout) Fix wheel test

   * PR #34632: (eliasp) Try to create the log directory when not  present
     yet

   * PR #34854: (rallytime) Remove string_types import from state compiler

   * PR #34865: (thatch45) This needs discussion, since this breaks SUSE

   * PR #34858: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34847:  (cachedout)  Add  an  option to skip the verification of
     client_acl users

   * PR #34833: (rallytime) Back-port #28521 to 2015.8

   * PR #34828: (thatch45) Fix #34648

   * PR #34827: (thatch45) fix beacon list to include  all  beacons  being
     processed

   * PR #34823: (rallytime) Back-port #25276 to 2015.8

   * PR #34822: (thatch45) Fix salt-ssh state.high and state.low

   * PR  #28521:  (gongled)  SPM:  packaging  doesn't  work in Python 2.6.
     Fixed.

   * PR #25276: (jacobhammons) copy spm.1 man page during setup

   * PR #34852: (rallytime) Skip GCE unit tests -  causes  test  suite  to
     hang

   * PR  #34844: (vutny) Fix getting total available memory without psutil
     installed

   * PR #34837: (thatch45) Fix #34345

   * PR  #34838:  (thatch45)  Check  if  a  valid  value  is   passed   to
     unlyif/unless

   * PR   #34840:   (thatch45)   update   the  state  wrapper  to  include
     show_low_sls

   * PR #34842: (sjorge) 2016.3 zpool cleanup and fixes

   * PR #34770: (aphor) zpool state module needs  support  for  disk  vdev
     #34762

   * PR  #34825:  (thatch45)  keep  this  beacon from stack tracing at the
     loader

   * PR #34824: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34818: (jtand)  Skip  mysql  state  test  if  mysqladmin  is  not
     available

   * PR #34803: (junovitch) salt/state.py: set
     `chunk['order'] = 0' with `order: first'; fixes `#24744`_

   * PR  #34642: (jtand) Check that mysqladmin exists before running mysql
     integration tests

   * PR #34670: (isbm) Add "osmajorrelease" grain (2016.3)

   * PR #34683: (cachedout) Fix publisher leak

   * PR #34791: (sjorge) salt.state.zpool tweaks

   * PR #34784: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34773: (randomed) Bugfix: Startup states on minions are not being
     written to mysql returner

   * PR #34754: (cachedout) Disable test

   * PR #34751: (cachedout) Remove unnedeed config test

   * PR #34741: (rallytime) Back-port #34726 to 2015.8

   * PR  #34726:  (martinhoefling)  Always  loop  over updated keys in non
     recursive update

   * PR #34606: (isbm) Bugfix: Exit on configuration read (backport)

   * PR #34756: (jacobhammons) Rebuild man pages

   * PR #34746: (rallytime) Update azure lib  dep  to  match  the  one  in
     cloud.clouds.msazure

   * PR #34744: (jtand) Test valid docs fix

   * PR #34740: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34721: (rallytime) Add output_file option to master config docs

   * PR #34607: (isbm) Bugfix: Exit on configuration read (backport)

   * PR #34739: (cachedout) Remove unnedeed config test

   * PR #34607: (isbm) Bugfix: Exit on configuration read (backport)

   * PR #34722: (rallytime) Various spelling fixes

   * PR #34714: (sjmh) Fix ldap auth for function matches

   * PR #34720: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34695:  (isbm) Bugfix: Zypper pkg.list_products returns False on
     some empty values (2015.8)

   * PR #34689: (Azidburn) fix  second  run  problems  with  pkg.installed
     using sources

   * PR #34682: (jfindlay) update 2015.8.11 release notes

   * PR  #34707:  (rallytime)  Add  versionadded  to  "special"  option in
     cron.present state

   * PR #34696: (isbm) Bugfix: Zypper pkg.list_products returns  False  on
     some empty values (2016.3)

   * PR #34702: (farcaller) Fixed dockerng.list_tags

   * PR #34681: (rallytime) Back-port #34549 to 2016.3

   * PR #34549: (Inveracity) fixes multiple values in mof configuration

   * PR #34679: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34676:  (cachedout)  Revert  "Modify  lodaer  global test to use
     populated dunders"

   * PR #34651: (rallytime) Lint 34644

   * PR #34647: (cachedout) Adjust the mine test a little bit to give it a
     better chance of success

   * PR #34644: (cachedout) Cleanup loader errors

   * PR  #34642: (jtand) Check that mysqladmin exists before running mysql
     integration tests

   * PR #34618: (jtand) Network state integration test test=True

   * PR #34601: (lorengordon) Clarifies the proper way to reference states

   * PR #34605: (gtmanfred) catch error if no dns domains exist

   * PR #34557: (jacobweinstock) handle jboss cli expression type  in  the
     parsing of output

   * PR #34652: (rallytime) Spelling fixes found in sqlite3 pillar docs

   * PR #34565: (Ch3LL) add num_cpus grain to freebsd

   * PR #34621: (jtand) Suse Leap doesn't have 'man'

   * PR #34619: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34617: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34593: (rallytime) Back-port #33851 to 2015.8

   * PR #34592: (jtand) Update github IP for ssh state integration tests

   * PR #34591: (jtand) Gate docker unit test to check for docker

   * PR   #34590:   (oeuftete)   [2015.8]   dockerng:  When  sorting  list
     actual_data, make it a list

   * PR #34584: (rallytime) [2015.5] Avoid circular imports  when  calling
     salt.utils functions

   * PR  #34560:  (terminalmage)  Add  a bunch of documentation on getting
     files from other environments

   * PR #34545:  (terminalmage)  Handle  cases  where  Docker  Remote  API
     returns an empty ExecutionDriver

   * PR  #34531:  (terminalmage)  Support ignore_epoch argument in version
     comparisons

   * PR #33851: (ticosax) [dockerng] Add support for edge  case  when  Cmd
     and Entrypoint can't be blanked

   * PR  #34585:  (rallytime)  [2016.3]  Avoid salt.utils circular imports
     when using "from"

   * PR #34616: (jacobhammons)  Adds  a  mock  required  for  the  network
     settings beacon

   * PR #34553: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR    #34546:   (rallytime)   Rename   unit.states.boto_secgroup   to
     unit.states.boto_secgroup_test

   * PR    #34537:     (rallytime)     Rename     tests.unit.simple     to
     tests.unit.simple_test

   * PR  #34527:  (rallytime)  [2015.8]  Update bootstrap script to latest
     stable

   * PR #34521: (cachedout) Prevent many  errors  in  the  test  suite  in
     loader tests

   * PR #34518: (terminalmage) Fix pkg.latest integration test for non-LTS
     ubuntu

   * PR #34507: (AAbouZaid) Fix wrong order of retention_policy_exists.

   * PR #34569: (eliasp) Minor doc fixes for PostgreSQL states

   * PR  #34524:  (terminalmage)  yumpkg:  Avoid   spurious   logging   in
     pkg.upgrade

   * PR #34490: (cachedout) Fix master crash on ctl-c for long-running job

   * PR #34520: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34513:  (cachedout) Lower the log level for modules which cannot
     be loaded to trace

   * PR #34505: (terminalmage) Improve top file merging documentation

   * PR #34503: (rallytime) Rename some unit test files by adding _test

   * PR #34498: (rallytime) Use -O in the wget example  in  the  bootstrap
     tutorial for the develop branch

   * PR  #34492:  (zer0def)  Gracefully handle non-XML output in GlusterFS
     execution module.

   * PR #34489: (jtand) Use skipTest for network state integration test

   * PR #34488: (rallytime) Update dnsmasq.get_config docs to use  correct
     config_file param.

   * PR  #34499: (gtmanfred) remove unnecessary block parsing ip addrs for
     nova

   * PR #34468: (twangboy) Use Python 2.7.12 for Windows Build

   * PR #34493: (twangboy) Use Python 2.7.12 for Mac Build

   * PR #34486: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34467: (rallytime) Back-port #34457 to 2015.8

   * PR #34462: (terminalmage) Use --always when available to git describe

   * PR #34457: (ryan-lane) Only access  key  metadata  if  we  found  key
     metadata

   * PR #34455: (cro) Forgot reference to inotify

   * PR #34432: (twangboy) Fix file.append

   * PR #34429: (terminalmage) Skip version checking for targeted packages
     in pkg.latest state

   * PR #34459: (terminalmage) Ignore retcode  when  formatting  highstate
     output

   * PR  #34463: (terminalmage) states/git: pass required cwd parameter to
     git.describe.

   * PR #34466: (rallytime) Back-port #34436 to 2016.3

   * PR #34436: (artxki)  Fix  #34395  Nonfunctional  default_password  in
     states.postgres_user.present

   * PR   #34453:   (jtand)   Arch   linux  does  not  have  osrelease  or
     osmajorrelease grains

   * PR #34456: (thatch45) Be more careful when making the SMinion

   * PR #34452: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34451: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34435: (cachedout) Backport change to integraiton test suite

   * PR #34426: (cro) Document that inotify is Linux only

   * PR #34401: (terminalmage) Use rpmdev-vercmp as a fallback for version
     comparison on RHEL5

   * PR #34366: (steverweber) Update service.py

   * PR  #34427:  (twangboy)  Automated  signing  fixes  for Ubuntu 16.04,
     14.04, 12.04 (for dmurphy)

   * PR #34400: (cachedout) Fix uninitialized value

   * PR #34404: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34392: (cro) Clarify that salt-cloud  doesn't  get  installed  by
     bootstrap

   * PR  #34377:  (terminalmage)  Optimize pkg integration tests and add a
     couple new tests

   * PR #34373: (jtand) Network state integration test

   * PR #34292: (twangboy) Fix runas function for System Account

   * PR #34388: (rallytime) Back-port #34378 to 2016.3

   * PR #34378: (adelcast) network_settings.py: fix documentation

   * PR #34352: (cro) Esxi dvs

   * PR #34386: (rallytime) Beacon network docs

   * PR #34376: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34368: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34344: (rallytime) Back-port #34324 to 2015.8

   * PR #34342: (rallytime) Back-port #34316 to 2015.8

   * PR #34324: (cachedout) Test custom grains matcher

   * PR #34316: (edgan) Making salt-ssh pass proper return codes for jinja
     rendering errors

   * PR  #34252:  (gtmanfred)  return  list  of  nodes for lxc driver when
     called directly

   * PR #34365: (sjorge) fixes computenode_*  grains  on  SmartOS  compute
     nodes

   * PR    #34353:    (cro)    Remove    proxy    check   and   additional
     GetConnection--this makes the proxy...

   * PR #34348: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34339: (terminalmage) Revert py3modernize lint changes

   * PR #34335: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34325: (terminalmage) Remove unnecessarily-disabled sanity check

   * PR  #34323:  (jacobhammons)  Doc  clarifications  to  file   modules,
     addition of new profile log lev...

   * PR #34319: (rallytime) Back-port #34244 to 2015.8

   * PR  #34313:  (rallytime)  [2015.5]  Update to latest bootstrap script
     v2016.06.27

   * PR #34312: (rallytime) [2015.8] Update  to  latest  bootstrap  script
     v2016.06.27

   * PR #34307: (rallytime) Fix test example in integration testing docs

   * PR  #34306:  (ghedo)  Fix iptables.flush state: Do not force 'filter'
     table when flushing

   * PR #34244: (the-glu) Typo in dockerio doc

   * PR #34343: (rallytime) Back-port #34256 to 2016.3

   * PR #34256: (tmehlinger) detect running  from  master  in  State.event
     method

   * PR #34338: (themalkolm) Add listen/listen_in support to stateconf.py

   * PR #34283: (sjorge) 2016.3 mount vfstab support

   * PR #34322: (Ch3LL) add osmajorrelease grain for raspbian

   * PR  #34337:  (clinta) Change merge-if-exists logic to properly report
     changes

   * PR #34300: (vutny) Make apache.configfile state  handle  the  Options
     list correctly

   * PR #34333: (rallytime) Back-port #33734 to 2016.3

   * PR #34304: (rallytime) Back-port #33734 to 2016.3

   * PR  #33734:  (glomium)  modules/rabbitmq.py  version  checking  had a
     logical error

   * PR #34330: (clinta) fix #34329

   * PR #34318: (rallytime) Back-port #32182 to 2016.3

   * PR #32182: (dongweiming) Fix psutil.cpu_times unpack error

   * PR #34311: (rallytime) [2016.3] Update  to  latest  bootstrap  script
     v2016.06.27

   * PR  #34284:  (rallytime)  Don't require 'domain' to be present before
     checking fqdn_ip* grains

   * PR #34296: (sjorge) 2016.3 status module now works  on  Solaris  like
     platforms

   * PR #34281: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34274: (clinta) Don't escape source before calling managed

   * PR #34258: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34257: (rallytime) Use 'config_dir' setting instead of CONFIG_DIR
     in gpg renderer

   * PR #34233: (thegoodduke) ipset: fix the comment containing blank

   * PR #34232: (thegoodduke) ipset: fix commont containing blank

   * PR #34225: (richardscollin) Fix win_system.set_system_date_time

   * PR #34271: (opdude) Fixed symlinks on windows where the slashes don't
     match

   * PR #34254: (sjorge) Fix for #14915

   * PR #34259: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34136: (meaksh) Fixed behavior for SUSE OS grains in 2015.8

   * PR #34134: (meaksh) Fixed behavior for SUSE OS grains in 2016.3

   * PR #34093: (terminalmage) Catch CommandExecutionError in pkg states

   * PR  #33903:  (meaksh)  Fetching  grains['os'] from /etc/os-release on
     SUSE systems if it is possible

   * PR #34134: (meaksh) Fixed behavior for SUSE OS grains in 2016.3

   * PR #33903: (meaksh) Fetching  grains['os']  from  /etc/os-release  on
     SUSE systems if it is possible

   * PR #34159: (christoe) Fixes to the win_task module

   * PR #34223: (peterdemin) Fixed typo in filtering LDAP's potential_ous

   * PR #34239: (vutny) file.find module: fix handling of broken symlinks

   * PR #34229: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34218: (terminalmage) Fix a pair of gitfs bugs

   * PR  #34208: (lomeroe) fix regression from #33681 which causes pulling
     a list of s3 objects ...

   * PR #34206: (terminalmage) Change target for dockerng assuming default
     status to Nitrogen release

   * PR  #34188:  (terminalmage)  Clarify pkg.list_repo_pkgs docstring for
     held packages

   * PR #34182: (rallytime) Handle child PIDs differently depending on the
     availability of psutils

   * PR #33942: (cachedout) ZD 762

   * PR #33681: (rallytime) Back-port #33599 to 2015.8

   * PR #33599: (lomeroe) Fix s3 large file download

   * PR  #34214:  (rallytime) Update saltutil.wheel docs to specify remote
     vs local minion behavior

   * PR #34209: (lomeroe) fix regression in s3.query from #33682

   * PR #33682: (lomeroe) backport #33599 to 2016.3

   * PR #33599: (lomeroe) Fix s3 large file download

   * PR #34222: (cachedout) Lint 34200

   * PR #34200: (secumod) Fix parted module set CLI example

   * PR #34197: (eliasp) Make module.ssh.recv_known_host() more  resilient
     against hosts not returning a key

   * PR  #34201:  (DarkKnightCZ)  Suffix  temp  file  with  .sr1  and  add
     mandatory argument when executing PowerShell script

   * PR #34198: (DarkKnightCZ) Don't use binary mode for cmdmod.exec_code

   * PR #34198: (DarkKnightCZ) Don't use binary mode for cmdmod.exec_code

   * PR #34172: (dmurphy18) Support for building with  local  packages  on
     Debian and Ubuntu

   * PR  #34194:  (vutny)  Correct  the  docstrings formatting in pkgbuild
     modules and state

   * PR #34056:  (vutny)  Make  rpmbuild  module  work  on  non-RPM  based
     GNU/Linux systems

   * PR #34186: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34184: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #34179:  (terminalmage)  Raise  the  correct exception when gitfs
     lockfile is empty

   * PR #34178: (terminalmage) Remove unnecesssary comment

   * PR #34176: (rallytime) Back-port #34103 to 2015.8

   * PR #34175: (rallytime) Back-port #34128 to 2015.8

   * PR #34174: (rallytime) Back-port #34066 to 2015.8

   * PR #34165: (mcalmer) fix  salt  --summary  to  count  not  responding
     minions correctly

   * PR #34141: (jtand) Fixed boto_vpc_test failure

   * PR #34128: (bebehei) doc: add missing dot

   * PR #34103: (morganwillcock) Fix diskusage beacon

   * PR #34077: (rallytime) Add some grains targeting tests

   * PR #34066: (complexsplit) Typo fix

   * PR #33474: (cachedout) Fix diskusage beacon

   * PR #34173: (rallytime) Update docs to match log_level default

   * PR #34095: (rallytime) Back-port #32396 to 2016.3

   * PR #32396: (eradman) Unbreak cron.file

   * PR #34108: (l2ol33rt) Make dockerng.absent state honor test=true

   * PR #34133: (rallytime) Back-port #34057 to 2016.3

   * PR  #34057:  (ajacoutot)  _active_mounts_openbsd:  unbreak output for
     special filesystems

   * PR #34156: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34142: (isbm) Move log message from INFO to DEBUG.

   * PR #34100: (terminalmage) Update documentation on "refresh"  behavior
     in pkg states

   * PR  #34072:  (jfindlay)  modules.pkg  int tests: skip refresh_db upon
     error

   * PR #34110: (garethgreenaway) Fixes  to  git  module  &  state  module
     related to identity file

   * PR  #34138: (rallytime) Update package dep note to systemd-python for
     RHEL7 install

   * PR #34166: (vutny) Fix YAML indentation in Apache state docstrings

   * PR #34098: (terminalmage) Restore old refresh logic

   * PR  #34087:  (bbinet)  Encourage  to  report   issues   to   upstream
     PillarStack project

   * PR #34075: (jfindlay) modules.inspectlib.kiwiproc: import gate lxml

   * PR  #34056:  (vutny)  Make  rpmbuild  module  work  on  non-RPM based
     GNU/Linux systems

   * PR #34073: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34069: (rallytime) Add a test to check  for  disconnected  minion
     messaging

   * PR  #34051:  (tegbert)  Fixed  a bug in the consul.py module that was
     preventing services

   * PR #34048: (terminalmage) RFC: proposed fix for  multiple  fileserver
     updates in masterless runs

   * PR #34045: (jacobhammons) Updated latest release version

   * PR  #34030:  (vutny)  More  YAML  indentation  fixes  in state module
     examples

   * PR #34020: (twangboy) Always make changes to  minion  config  if  set
     (2015.8)

   * PR #34018: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34011: (rallytime) Back-port #33948 and #34009 to 2015.8

   * PR #34009: (rallytime) Back-port #33948 to 2016.3 + add log message

   * PR #34005: (rallytime) Lint fix for #34000

   * PR #34003: (vutny) states.file: fix indentation in YAML examples

   * PR #34002: (lorengordon) Remove loader test for pam module

   * PR #34000: (cachedout) Fix incorrectly written test

   * PR  #33990: (jacobhammons) Adds links to several current Salt-related
     projects

   * PR #33985: (rallytime) Write some more simple batch command tests

   * PR #33984: (jfindlay) Add docs and tests to disk state

   * PR #33983: (twangboy) Clarify the account_exists parameter

   * PR  #33953:  (whiteinge)  Add  loader.utils()  example   to   calling
     minion_mods

   * PR #33951: (jfindlay) modules.gem int tests: more fixes

   * PR  #33948: (cachedout) Save an entire minion cache traversal on each
     master pub

   * PR #33904: (rallytime) Back-port #33806 to 2015.5

   * PR   #33880:   (terminalmage)   pkg.uptodate:    Pass    kwargs    to
     pkg.list_upgrades

   * PR #33806: (cachedout) Work around upstream cherrypy bug

   * PR #33684: (jfindlay) add acl unit tests

   * PR  #34010:  (terminalmage)  Do  not  cache  remote files if they are
     already cached

   * PR #34009: (rallytime) Back-port #33948 to 2016.3 + add log message

   * PR #33948: (cachedout) Save an entire minion cache traversal on  each
     master pub

   * PR #33941: (cachedout) Don't call os.getppid() on Windows

   * PR #34067: (jacobhammons) Fixes doc refresh bug on chrome mobile.

   * PR #34050: (rallytime) Back-port #34026 to 2016.3

   * PR #34026: (bensherman) removed method that doesn't exist

   * PR #33987: (isbm) inspectlib cleanup

   * PR #34042: (sjorge) fix #34038

   * PR #34025: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34044: (jacobhammons) Updated latest release to 2016.3.1

   * PR #34014: (jnhmcknight) fix launch config creation params

   * PR  #34021:  (twangboy)  Always  make changes to minion config if set
     (2016.3)

   * PR #34031: (eliasp) states.postgres_privileges expects a  real  list,
     not a comma-separated string

   * PR  #33995:  (jacobhammons)  Understanding  Jinja  topic,  Jinja  doc
     issues.

   * PR #33900: (amendlik) Document sudo  policy  for  gitfs  post-recieve
     hook

   * PR #33980: (twangboy) Use full path to python.exe

   * PR #33993: (s0undt3ch) Call sys.exit() instead of exit()

   * PR #33976: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #33962:  (jacobhammons) Adds a "Generated on <timestamp>" line to
     the html footer

   * PR #33952: (rallytime) Add base argument to salt-ssh  grains  wrapper
     for filter_by func

   * PR #33946: (rallytime) Back-port #33698 to 2015.8

   * PR #33942: (cachedout) ZD 762

   * PR #33698: (opdude) Vsphere fixes

   * PR  #33912:  (abalashov)  utils/schedule.py:handle_func()  -  Fix for
     accessing returner configur...

   * PR #33945: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #33936: (rallytime)  Add  connecting_settings  to  boto_elb  state
     attributes list

   * PR #33917: (techhat) Wait for up to a minute for sync_after_install

   * PR #33888: (jfindlay) random.org checks

   * PR #33877: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR   #33833:   (terminalmage)   Support  syncing  pillar  modules  to
     masterless minions

   * PR #33829: (terminalmage) Update versionchanged directive

   * PR #33814:  (terminalmage)  Support  extraction  of  XZ  archives  in
     archive.extracted state

   * PR #33778: (sodium-chloride) Fix minor docstring issues

   * PR  #33765: (cachedout) Correct issue with ping on rotate with minion
     cache

   * PR #33726: (jtand) glance.warn_until shouldn't be checked for  a  doc
     string

   * PR #33611: (rolffokkens) 2015.5

   * PR  #33960:  (mecarus) Fix mongo get_load to return full mongo record
     instead of non-existant 'load' key

   * PR #33961: (jacobhammons) 2016.3.0 known issues update

   * PR  #33908:  (ticosax)  [boto_lambda]  handle   omitted   Permissions
     parameter

   * PR #33896: (DmitryKuzmenko) Don't deep copy context dict values.

   * PR #33905: (rallytime) Back-port #33847 to 2016.3

   * PR #33910: (cachedout) Ensure tht pillar have freshest grains

   * PR  #33870:  (rallytime)  Add  note about Xenial packages to 2016.3.0
     release notes

   * PR #33847: (whiteinge) Add docs for arg/kwarg eauth matching

   * PR  #33076:  (cachedout)  Avoid  second  grains   load   on   windows
     multiprocessing

   * PR #29153: (DmitryKuzmenko) ACL limit args

   Salt 2016.3.3 Release Notes
   Version 2016.3.3 is a bugfix release for 2016.3.0.

   Known Issues
   issue  36055:  Salt  Cloud events (salt/cloud) are not generated on the
   master event bus when provisioning cloud systems.

   Bootstrap Issue #973: python-futures is not installed  when  installing
   from  a git tag on RedHat-based distributions. Python futures is needed
   when running Salt with the TCP transport. This is fixed on the  develop
   branch  of  the salt-bootstrap repo and the fix will be included in the
   upcoming release of salt-bootstrap, but  is  a  bug  in  the  bootstrap
   release   that  ships  with  this  version  of  Salt.  Please  see  the
   salt-bootstrap  repo  for  more  information  on  how  to  update  your
   bootstrap version.

   Changes for v2016.3.2..2016.3.3
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-08-19T16:17:34Z

   Total Merges: 134

   Changes:

   * PR #35580: (twangboy) Fix mac_service  attempts  to  parse  non-plist
     files

   * PR    #35586:    (hu-dabao)   Fix   35420,    add   run_on_start   in
     build_schedule_item

   * PR #35583: (terminalmage) Fix localemod tests

   * PR #35579: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35577: (terminalmage) Unit file changes for 2015.8.12, 2016.3.3

   * PR #35571: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35566: (rallytime) Back-port #35545 to 2015.8

   * PR #35546: (whiteinge) Salt api eauth fail gracefully

   * PR #35545: (hu-dabao) fix-35384, fix cmd.run unless

   * PR #35540: (rallytime) Whitespace fix for 2015.8

   * PR #35525: (UtahDave) add missing glob import

   * PR #35510: (terminalmage) Better systemd integration

   * PR #35492: (terminalmage) Clarify config.get docstring

   * PR #35483: (gtmanfred) use __utils__ in salt.cloud

   * PR #35573: (rallytime) Back-port #33337 to 2016.3

   * PR #33337: (mzupan) adding the () to make changes work

   * PR #35572: (terminalmage) Fix poor formatting in pkg state docs

   * PR #35545: (hu-dabao) fix-35384, fix cmd.run unless

   * PR #35489: (rallytime) Back-port #35463 to 2016.3

   * PR #35463: (skizunov) Make auth_timeout user configurable again

   * PR #35538: (thatch45) Treat python XML as an optdep

   * PR #35526: (thatch45) Always deploy the thin to /var/tmp

   * PR #35522: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35513: (cachedout) Might be a good idea to be  able  to  download
     the software we make

   * PR #35512: (cachedout) Fixup 35419

   * PR #35508: (terminalmage) Add Carbon to versionadded for git.diff

   * PR #35497: (deepakhj) Fixes spacing in requirements files

   * PR #35302: (Ch3LL) Add job cache test

   * PR #35516: (rallytime) Back-port #34441 to 2016.3

   * PR  #34441: (markuskramerIgitt) Copy and delete silently, do not list
     each file

   * PR #35517: (rallytime) Back-port #34502 to 2016.3

   * PR #34502: (markuskramerIgitt) Windows installer build  scripts  will
     exit on error

   * PR #35429: (tankywoo) Fix iptables target options with no arguments

   * PR  #35495:  (rallytime) Use correct deprecated notation instead of a
     warning for apache_module.enable state function.

   * PR #35498: (rallytime) Add supported templates list to  all  template
     doc references in file state

   * PR #35406: (rallytime) Provide links to the renderers in the template
     docs

   * PR #35360:  (rallytime)  Add  all  template  registery  templates  to
     file.managed docs

   * PR #35487: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #35486:  (rallytime)  Update  bootstrap  script  to latest stable
     (2016.08.16)

   * PR #35476: (cachedout) Fixup SSH bug where  sudo  without  sudo  user
     would break

   * PR  #35471: (terminalmage) win_pkg: Fix traceback when package is not
     installed

   * PR #35460: (rallytime) [2015.8] Update  bootstrap  script  to  latest
     stable (2016.08.15)

   * PR #35459: (thatch45) Ensure that output for salt-ssh gets back

   * PR #35453: (theothergraham) fixes #34279 - disk cache ttl expiry

   * PR #35451: (isbm) Bugfix: zypper mod repo unchanged

   * PR #35448: (isbm) Add ignore_repo_failure option to suppress zypper's
     exit code 106 on ...

   * PR #35413: (cachedout) Resolve path issues with cp.push

   * PR #35446: (cachedout) Make  salt-client  aware  of  edge-case  where
     saltutil might be broken

   * PR  #35449:  (dkruger)  aptpkg  will  specify --install-recommends if
     enabled by the SLS

   * PR #35467: (rallytime) Back-port #33518 to 2016.3

   * PR #35235: (rallytime) Back-port #33518 to 2016.3

   * PR #33518: (tonybaloney) Fix libcloud bug #33367

   * PR #35461: (rallytime) [2016.3] Update  bootstrap  script  to  latest
     stable (2016.08.15)

   * PR #35456: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35442: (cachedout) Fix cp.push_dir pushing empty dirs

   * PR #35436: (cachedout) Minor doc fixup

   * PR  #35132:  (sjorge)  fixes , causing lots of mayham (onchange) with
     2016.3.2 for me

   * PR #35447: (ticosax) [dockerng] RepoTags can be  also  be  None  with
     docker 1.12

   * PR #35308: (farcaller) Actually fixed dockerng.list_tags

   * PR #34702: (farcaller) Fixed dockerng.list_tags

   * PR  #35427:  (cachedout)  Correct errant call to argspec from master.
     Fix ext_job_cache.

   * PR  #35428:  (cachedout)  Resolve  stacktrace  logged  by   highstate
     outputter if sls cannot be found

   * PR #35412: (s0undt3ch) Only allow one sync read to happen at a time.

   * PR #35406: (rallytime) Provide links to the renderers in the template
     docs

   * PR #35360:  (rallytime)  Add  all  template  registery  templates  to
     file.managed docs

   * PR #35393: (deniszh) No need to run ddns update every time

   * PR  #35407:  (hu-dabao)  [Fix-35094] None will not be added to grains
     which generate [none]

   * PR  #35411:  (eliasp)  modules.event.send():  Prevent  backtrace  for
     masterless Minions

   * PR #35395: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35394: (rallytime) Back-port #34573 to 2015.8

   * PR #35359: (terminalmage) Clean up open filehandles

   * PR  #35357:  (twangboy) Fix file.recurse with clean: True  on Windows
     (2015.8)

   * PR #35339: (isbm) Bugfix: Prevent continuous restart, if a dependency
     wasn't installed

   * PR #34573: (cedwards) Update freebsd.rst

   * PR #35373: (cachedout) Raise SaltRenderError on bad requisite

   * PR  #35352:  (twangboy) Fix file.recurse with clean: True  on Windows
     (2016.3)

   * PR #35356: (jfindlay) document log levels and  warn  on  all  logging
     below info

   * PR #35358: (twangboy) Update libsodium deps

   * PR  #35360:  (rallytime)  Add  all  template  registery  templates to
     file.managed docs

   * PR #35362: (rallytime) Correct deprecation version tags

   * PR #35361: (rallytime) Blockdev deprecations

   * PR #25267: (jfindlay) Disk module improvements

   * PR #24893: (The-Loeki) Contribution: Disk module improvements

   * PR #35347: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35325: (kev009) Fix freebsd netstat route on fbsd 10+

   * PR #35323: (thatch45) Fix issue with bad error check in salt-vt

   * PR #35309: (terminalmage) file.recurse: Do  not  convert  octal  mode
     string to int

   * PR #35301: (bobrik) Pass port to ssh.check_known_host, closes #35264

   * PR #35334: (cachedout) Restore random_master functionality

   * PR  #35331:  (hu-dabao)  fix 35165, salt-run jobs.exit_success jid is
     broken

   * PR #35318: (rallytime) Remove legacy  compat  docs  in  mysql  pillar
     since the code was removed already

   * PR #30913: (jtand) Deprecated code removed.

   * PR #35329: (hu-dabao) sys.doc will skip all not connected minions

   * PR #35306: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #35290:  (terminalmage)  Resolve  a  couple bugs in orchestration
     output

   * PR #35229: (lubyou) Ignore import error for pwd module in mac_shadow

   * PR #35227: (isbm) Isbm osfinger ubuntu fix

   * PR #35286: (hu-dabao) fix 34425, a bug  that  sys.doc  cannot  output
     format

   * PR #35275: (rallytime) Back-port #35213 to 2016.3

   * PR #35213: (gtmanfred) add identity v3 support to openstack driver

   * PR #35278: (dmurphy18) Increase timeout for siging to 10 seconds when
     signing rpm packages

   * PR #35276: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35271: (bobrik) Default state_output_profile to True  everywhere,
     closes #35166

   * PR #35249: (terminalmage) Fix regression in git.latest

   * PR #35245: (rallytime) Back-port #35039 to 2015.8

   * PR #35241: (terminalmage) Ensure max recursion in gitfs results in no
     blob object being returned.

   * PR #35240: (derekmaciel) Backport #35225 to 2015.8

   * PR #35236: (rallytime) Back-port #35119 to 2015.8

   * PR #35233: (terminalmage) Do not attempt to get  fqdn_ip{4,6}  grains
     when ipv{4,6} grains are empty

   * PR #35225: (derekmaciel) Add missing documentation for pkg.installed

   * PR #35211: (cachedout) Alternative sudo users for salt-ssh

   * PR  #35202: (multani) doc: fix broken links in the test documentation
     page

   * PR #35119: (derekmaciel) Assume two EVRs are equal if  E  and  V  are
     equal but one R is missing.

   * PR #35039: (whiteinge) Add saltenv support to module.run

   * PR #35274: (rallytime) Lint fixes for 2016.3 branch

   * PR  #35232:  (theredcat)  fix  rabbitmq  version  detection  using  a
     package-agnostic version

   * PR #35269: (meaksh) Checksum validation for  zypper  pkg.download  in
     2016.3 and develop

   * PR  #35197:  (vutny)  Make  pkgbuild.repo  state recognize createrepo
     command return code

   * PR #35178: (cro) Add append_minionid_config_dirs option

   * PR #35259: (cachedout) Fixup 35253

   * PR #35253: (abednarik) Fix disk.wipe missing option.

   * PR #35253: (abednarik) Fix disk.wipe missing option.

   * PR #35206:  (hu-dabao)  Make  the  log  level  back  to  warning  for
     unclassified exc

   * PR #35196: (isbm) Deprecate status.uptime one version later

   * PR  #35207:  (eliasp)  Handle  exceptions  in  _get_virtual()  and in
     _get_virtual() consumers

   * PR  #35232:  (theredcat)  fix  rabbitmq  version  detection  using  a
     package-agnostic version

   * PR #35244: (rallytime) Back-port #31677 to 2016.3

   * PR  #31677:  (miihael) Return correct value for services that must be
     enabled in Systemd

   * PR #35182: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35174: (rallytime) Back-port #35146 to 2015.8

   * PR #35173: (rallytime) Back-port #35135 to 2015.8

   * PR #35146: (cachedout) Don't  discard  running  beacons  config  when
     listing becaons

   * PR #35145: (jacobhammons) doc version update to 2015.8.11, updates to
     release notes

   * PR #35135: (rallytime) Add missing CLI  Examples  to  aws_sqs  module
     funcs

   * PR  #34827:  (thatch45)  fix beacon list to include all beacons being
     processed

   * PR #35150: (rallytime) Start release notes for 2016.3.3

   * PR #35157: (hu-dabao) master returned from func should be a string as
     designed so far

   * PR #35147: (jacobhammons) doc version updated to 2016.3.2

   * PR  #35136: (s0undt3ch) Don't restart processes if the manager is not
     set to restart them

   * PR #35133: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #35114:  (terminalmage)  Add  clarification  docs  on  a   common
     git_pillar misconfiguration

   * PR #35043: (rallytime) Start release notes file for 2015.8.12

   * PR #34768: (hrumph) Fixes #34767

   * PR #35120: (kstreee) The '_handle_event_socket_recv' function in Salt
     Api is missing first data of stream.

   * PR #35131: (rallytime) Back-port #35011 to 2016.3

   * PR #35011: (nishigori) Fix docstring for code-block of rst

   * PR #35110: (hu-dabao) Do not return job status  back  to  master  for
     master_alive and master_failback schedules

   * PR #35104: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #35066:  (jfindlay) returners.postgres_local_cache: do not log in
     __virtual__

   * PR   #35050:   (terminalmage)   [orchestration]    Properly    handle
     runner/wheel funcs which accept a 'saltdev' argument

   * PR  #35026:  (cachedout)  Expressly  deny a minion if a key cannot be
     found

   * PR #35024: (bobrik) Cache systemd unit update check per unit,  closes
     #34927

   * PR   #35105:   (rallytime)   Update   2016.3.0   release  notes  with
     repo.saltstack.com Xenial pkg availability

   * PR #33870: (rallytime) Add note about  Xenial  packages  to  2016.3.0
     release notes

   * PR  #35059:  (vutny)  Add  fun_args  field  to  events  generated  by
     execution of Master modules

   * PR #34955: (lubyou) force dism to always output english text

   * PR  #35078:  (jacobweinstock)  added  missing  non-keyword   argument
     skip_verify to __get_artifact func...

   * PR  #35008:  (hu-dabao)  Fix  multimaster  failover  on more than two
     masters and failback behaviour

   * PR #35055: (galet) #33536 pkgrepo.managed does not disable a yum repo
     with "disabled: True"

   * PR #35039: (whiteinge) Add saltenv support to module.run

   * PR #35046: (eliasp) Prevent backtrace in salt.states.network

   * PR  #35054:  (lubyou)  Only fail user lookup is the user parameter is
     required

   * PR #35029: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35000: (rallytime) Back-port #33875 and #34999 to 2015.8

   * PR #34994: (rallytime) Back-port #34835 to 2015.8

   * PR #34835: (thatch45) Make the mine and publish  combine  minion  and
     master opts in salt-ssh

   * PR #33875: (jmesquita) Fix naive fileserver map diff algorithm

   * PR  #35021:  (terminalmage)  Don't  add  '.'  to strerror when passed
     string ends in ? or !

   * PR  #34983:  (eliasp)   modules.slack.post_message:   Allow   sending
     messages to direct-message ...

   * PR #34996: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34991: (cachedout) SSH timeout

   * PR #34976: (cachedout) Refine errors in client

   * PR  #34831:  (thatch45)  If  the  thin does not match, then redeploy,
     don't error

   * PR #34987: (eliasp) salt.states.slack: check correct result attribute

   * PR #34835: (thatch45) Make the mine and publish  combine  minion  and
     master opts in salt-ssh

   * PR #34988: (rallytime) Update release notes with new changes

   * PR  #34946: (anlutro) Fix virtualenv behavior when requirements files
     are in subdirectories

   * PR #34957: (sjmh) Don't fall through to checking auth entries

   * PR #34971: (cachedout) Increase timeout for grains test

   * PR #34951: (vutny) Fix #34873

   * PR #34935: (rallytime) Avoid UnboundLocalError in beacons module

   * PR #34894: (rallytime) [develop] Merge forward from 2016.3 to develop

   * PR #34956: (cachedout) Increase all run_script timeouts to 30s

   * PR #34933: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #34916: (cachedout) Master performance improvement

   * PR #34911: (cachedout) Backport #34906

   * PR #34906: (cachedout) Set timeout for run_salt in test suite

   * PR  #34898:  (hrumph)  Stop  multiple  refreshes   during   call   to
     pkg.list_upgrades

   * PR #34606: (isbm) Bugfix: Exit on configuration read (backport)

   * PR   #34915:   (abednarik)  Update  service_rh  provider  to  exclude
     XenServer >= 7.

   * PR #34926: (rallytime) Lint #34923

   * PR #34923: (eliasp) Handle  exception  when  no  Slack  API  key  was
     provided

   * PR #34910: (cachedout) Fix grains error on proxy minions

   * PR #34864: (jmacfar) Check for version in list of installed versions

   * PR #34902: (rallytime) Back-port #34878 to 2016.3

   * PR #34878: (abednarik) Add VirtuozzoLinux is yumpkg enable list.

   * PR  #34901:  (rallytime)  Add  VirtuozzoLinux  to the list of enabled
     distros for rpm.py

   * PR #34900: (rallytime) Add VirtuozzoLinux to enabled  platforms  list
     in rh_service.py

   * PR #34887: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34869:  (terminalmage)  Fail  git.latest states with uncommitted
     changes when force_reset=False

   * PR #34862: (thatch45) Fix salt-ssh cacheing issue

   * PR #34859: (cachedout) Fix wheel test

   * PR #34632: (eliasp) Try to create the log directory when not  present
     yet

   * PR #34854: (rallytime) Remove string_types import from state compiler

   * PR #34865: (thatch45) This needs discussion, since this breaks SUSE

   * PR #34858: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #34847:  (cachedout)  Add  an  option to skip the verification of
     client_acl users

   * PR #34833: (rallytime) Back-port #28521 to 2015.8

   * PR #34828: (thatch45) Fix #34648

   * PR #34827: (thatch45) fix beacon list to include  all  beacons  being
     processed

   * PR #34823: (rallytime) Back-port #25276 to 2015.8

   * PR #34822: (thatch45) Fix salt-ssh state.high and state.low

   * PR  #28521:  (gongled)  SPM:  packaging  doesn't  work in Python 2.6.
     Fixed.

   * PR #25276: (jacobhammons) copy spm.1 man page during setup

   * PR #34852: (rallytime) Skip GCE unit tests -  causes  test  suite  to
     hang

   Salt 2016.3.4 Release Notes
   Version 2016.3.4 is a bugfix release for 2016.3.0.

   Known Issues
   The  Salt  Minion  does  not  clean  up  files  in  /tmp when rendering
   templates. This potentially results in either running out of disk space
   or running out of inodes. Please see Issue #37541 for more information.
   This bug was fixed with Pull Request #37540, which will be available in
   the 2016.3.5 release of Salt.

   The  release  of  the  bootstrap-salt.sh  script  that is included with
   2016.3.4 release has a bug in it that fails to install  salt  correctly
   for  git  installs  using  tags in the 2015.5 branch.  This bug has not
   been fixed in the  salt-bootstrap  repository  yet,  but  the  previous
   bootstrap release (v2016.08.16) does not contain this bug.

   Changes
   * The  disk.wipe execution module function has been modified so that it
     correctly wipes a disk.

   * Add ability to clone from a snapshot to the VMWare salt-cloud driver.

   * Add ability to specify disk backing mode in  the  VMWare  salt  cloud
     profile.

   Changes for v2016.3.3..v2016.3.4
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-10-27T16:10:53Z

   Total Merges: 274

   Changes:

   * PR #37282: (thatch45) add cpub to raet event for compat

   * PR #37278: (jfindlay) update 2016.3.4 release notes

   * PR #37252: (vutny) Set logging level to 'info' for message about init
     system detection

   * 47290d8 Update man pages for the 2016.3 branch (#37259)

   * PR #37257: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #37254: (DmitryKuzmenko) Bugs/37191 minion hangs

   * PR #37218: (darkalia) Issue
     `#37187`_
      Do not parse first /proc/1/cmdline binary if it's not
     *
     b...

   * PR #37239: (Ch3LL) Fix cloud tests timeout

   * PR #37244: (rallytime) Update bootstrap release to 2016.10.25

   * PR #37245: (rallytime) Back-port #36334 to 2016.3

   * PR #37233: (rallytime) Back-port #37154 to 2016.3

   * PR #37232: (rallytime) Back-port #37153 to 2016.3

   * PR #37228: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #37213: (cachedout) More salttesting fixes

   * PR #37207: (cachedout) Correct documentation for mine_functions

   * PR  #37208:  (cachedout) Give multimion a process manager and its own
     destroy method

   * PR #37206: (cachedout) Address transport test hang

   * PR #37179: (isbm) Fix Salt-API ssh crash (2016.3)

   * PR #37183: (gtmanfred) load tags should  reference  the  actual  load
     tags

   * PR #37188: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * d7e28d2 Pylint fix for 2016.3 (#37186)

   * PR #37175: (cachedout) Fix test hang

   * PR  #37144:  (DmitryKuzmenko)  Bugs/36866  salt  minion communication
     broken 2016.3

   * PR #37158: (jfindlay) add mock for status.uptime unit test

   * PR #37161: (rallytime) Back-port #37098 to 2016.3

   * PR #37159: (rallytime) Back-port #37107 to 2016.3

   * PR #37163: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 2bc5ded Allow the minion test daemons a couple of tries to connect to
     the master (#37150)

   * ec7ad9e  Add  note  about  salt-bootstrap known issue for 2016.3.4 (
     #37152)

   * PR  #37135:  (AaronM-Cloudtek)  Fix   example   signing   policy   in
     salt.states.x509 docs

   * PR    #37140:   (vutny)   pkgbuild.repo:   fix   GPG   signing   with
     use_passphrase=False

   * PR #37071: (vutny) pkgbuild.repo: add timeout parameter  for  waiting
     passphrase prompt

   * PR #37115: (DmitryKuzmenko) Backport/36720 fix race condition

   * PR #37119: (jfindlay) log.setup: only assign user if defined

   * f22c686 fix digital ocean image name in profile (#37126)

   * 4263849 add 2016.3.4 release notes (#37125)

   * PR #37120: (rallytime) Back-port #36246 to 2016.3

   * PR    #37103:    (cachedout)    Remove    unnecessary    sleep   from
     unit.utils.process_test.TestProcessMana...

   * PR #36823: (terminalmage) Update debian systemd  unit  files  to  use
     default KillMode, Type=notify

   * PR #37030: (isbm) Fix status.uptime for Solaris 9, 10 and 11.

   * PR #37101: (rallytime) [2016.3] Merge forward from 2016.3 to carbon

   * PR #36958: (twangboy) Fix bug where cmd.powershell fails to return

   * PR  #37086:  (cachedout)  Make  salt-call  a  first-class citizen for
     multi-master

   * PR #36898: (clinta) X509 fixes

   * PR #37025: (cro) Make salt.utils.minion._check_cmdline work  on  OSes
     without /proc.

   * PR  #37050:  (twangboy)  Fix  service state for Windows (DO NOT MERGE
     FORWARD)

   * PR #37076: (jfindlay) Document proxy settings

   * PR #37081: (terminalmage) Fix  archive.extracted  remote  source_hash
     verification

   * PR #37064: (cachedout) Unify job check in scheduler

   * PR #37072: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #37049:  (terminalmage)  Further clarification on new grains docs
     from #37028

   * PR #37057: (rallytime) [2016.3] Update salt.utils.cloud references to
     __utils__ for cache funcs

   * PR #36977: (twangboy) Remove whitespace from string commands

   * PR #37048: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR   #37028:   (damon-atkins)   Update   topics/grains   doco,  about
     considerations before adding a Grain

   * PR #37012: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 519e1dc opkg: Support ignore_epoch argument in version comparisons (
     #37007)

   * PR #36808: (gtmanfred) allow for closing stuff in beacons

   * a02868b Make helper funcs private (#36993)

   * PR #36986: (jfindlay) modules.archive.unzip: zipfile is stdlib

   * PR  #36981:  (rallytime) Skip pkg.upgrades test on distros other that
     Suse in 2016.3

   * PR #36755:  (terminalmage)  systemd.py:  check  retcode  for  service
     availability in systemd >= 231

   * PR  #36750:  (terminalmage)  Add the CLI client and pub_data as class
     attributes

   * PR #36241: (hrumph) Fixes
     `#36240`_

   * PR #36950: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36948: (rallytime) Back-port #36943 to 2016.3

   * PR #36946: (rallytime) Back-port #36892 to 2016.3

   * PR #36945: (rallytime) Back-port #35199 to 2016.3

   * 7565ed6 Fix versionadded (#36949)

   * 4d8fb03 return opennebula errors to user (#36930)

   * PR         #36929:         (rallytime)         [yumpkg]          Skip
     test_pkg_upgrade_has_pending_upgrades if there are no upgrades

   * 288f437 [2016.3] Remove "Targeting with Executions" section from docs
     (#36926)

   * PR #36915: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 0ebf7a4 modules: debian_ip: override params  early  to  fix  diff  (
     #36820)

   * a23ce84 states.schedule: splay is not ordereddict (#36894)

   * PR #36885: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 1c0ba80  salt-ssh: Try "command -v" before falling back to "which" (
     #36889)

   * 85eea4d fileclient: Change queryarg comparison from  None  to  simple
     boolean check (#36830)

   * PR #36853: (rallytime) Back-port #33939 to 2016.3

   * PR #36852: (rallytime) Back-port #36743 to 2016.3

   * PR #36844: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36835: (jfindlay) unify and expand beacon documentation

   * PR  #36789:  (maximeguillet)  Fix  behavior  of  psql  -c option with
     postgresql 9.6

   * PR #36797: (cachedout) Error on reaction with missing SLS file

   * PR #36803: (gtmanfred) do not load  libvirt  pillar  if  certtool  is
     unavailable

   * PR #36815: (BenoitKnecht) Fix glance.image_present state

   * PR  #36754:  (terminalmage)  Base  rpmdev-vercmp comparison result on
     retcode

   * PR #36785: (cachedout) Fixup merge forward #36728

   * PR #36768: (gtmanfred) add __utils__ to vultr cloud provider

   * PR #36764: (cachedout) Another bit of detection for failed pip tests

   * PR #36747: (jfindlay) modules.archive integration  tests:  check  for
     gzip, rar

   * PR  #36744:  (cachedout)  Fix  issue  where  test suite could hang on
     shutdown

   * PR #36696: (cro) pass __proxy__ in state.sls_id

   * PR #36716: (vutny) salt.modules.ini_manage: fix creating  options  in
     empty file

   * PR #36724: (rallytime) Back-port #36628 to 2016.3

   * PR #36725: (rallytime) Back-port #36643 to 2016.3

   * PR #36726: (rallytime) Back-port #36722 to 2016.3

   * 48d2b01 fix python26 archive zip module (#36719)

   * PR #36699: (cachedout) Fix error in test

   * PR #36670: (jackywu) fix bug for including loopback addr

   * PR  #36694:  (lorengordon)  Exposes ignore_if_missing to file.replace
     state module

   * PR #36686: (jfindlay) log levels doc: try long form table

   * PR #36690: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36680: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36659: (terminalmage) Support dynamic env in new-style git_pillar

   * PR #36538: (clinta) daemon-reload on call to service.avaliable

   * PR #36616: (cro) Zypper fix test

   * PR #36621: (terminalmage) Fix shadowed builtins

   * PR #36636: (rallytime) Back-port #36618 to 2016.3

   * PR #36648: (jfindlay) Integration tests for archive execution module

   * PR #36650: (rallytime) Revert "Pr 36386"

   * PR  #36646:  (rallytime)  Provide  an  error  message  when   invalid
     transport is set

   * PR #36635: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #36620:  (rallytime)  Don't allow mercurial states to return True
     with errors

   * PR #36622: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36520: (twangboy) Fix cmd.script runas for Windows

   * PR #36564: (DmitryKuzmenko) Improve and fix _check_cache_minions

   * PR #36606: (danlsgiga) Add support for ACL  Tokens  in  consul_pillar
     with the option consul.token

   * PR  #36613:  (slinn0)  Remove  file.check_managed_changes   when  not
     needed (backport of PR #36589 to 2016.3)

   * PR #36609: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36595: (cachedout) Remove tests which no longer apply

   * PR #36594: (cachedout) Update boostrap docs  to  recent  versions  of
     Ubuntu

   * PR #36585: (twangboy) Add pyOpenSSL to req file for Windows

   * f205d5f Fix salt.utils.rm_rf to delete files too (#36572)

   * PR #36495: (cro) Fix pkg.upgrade for zypper

   * PR #36539: (jfindlay) Prefer archive.cmd_unzip

   * PR  #36546:  (rallytime)  Mercurial  Module:  Pass  the identity_path
     portion as own arg

   * PR #36555: (DmitryKuzmenko) Bugs/35480 master shutdown

   * PR #36542: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 5548ed7 Back-port #36435 to 2016.3 (#36532)

   * fe377b3 Be explicit about the salt.utils.templates import (#36535)

   * fcc50c9   Wrap   the   entire   GrainsAppendTestCase    class    with
     destructiveTest (#36537)

   * PR #36529: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36483: (dmurphy18) Isolate sun IPv6 fix to Sun OS only

   * PR #36280: (alertedsnake) Feature/2016.3 better postgresql grants

   * PR #36508: (twangboy) Fix chocolatey

   * PR #36519: (terminalmage) Rewrite minionfs walkthrough

   * PR #36505: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36496: (cachedout) Add repr to namespacedict

   * PR #36474: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR    #36478:    (rallytime)   Add   the   "bash"   option   to   the
     "code-block"directive.

   * PR #36484: (terminalmage) Fix for  temp  files  being  left  over  by
     salt-cloud execution

   * PR  #36486:  (terminalmage)  Improve  the rebase docs in contributing
     guidelines

   * PR #36455: (twangboy) Update docs for Windows

   * PR #36459: (cachedout) Pr 36426

   * PR #36442: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36310: (thatch45) Fix bug where the client will destroy the loop

   * PR #36394: (oba11) fix  accound_id  in  boto_iam  and  get_region  in
     boto_sns

   * PR #36424: (jfindlay) skip some mac_timezone tests

   * PR #36428: (terminalmage) A couple fixes for Antergos Linux

   * PR  #36425:  (whiteinge)  Check for dictionary explicitly since we're
     accessing it as one

   * PR #36199: (thatch45) skip all failhards if test=True

   * PR #36418: (rallytime) Back-port #36246 to 2016.3

   * PR #36419: (rallytime) Back-port #36329 to 2016.3

   * PR #36420: (rallytime) Back-port #36365 to 2016.3

   * PR #36413: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36305: (gtmanfred) cache query args with url as well

   * PR #36389: (cachedout) Pr 36386

   * 5737b1c Update versionadded and release notes (#36352)

   * PR #36369: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * fbbe9ec Quote postgres privilege target names (#36249)

   * 9451141 set __virtualname__ to 'service' (#36330)

   * fee3be4 Use infoblox_* values if present in arguments (#36339)

   * 19eb848 remove help message from glance module (#36345)

   * a4bbd5e Add resize2fs unit test from blockdev_test  to  disk_test  (
     #36346)

   * PR  #36350:  (terminalmage) Add note about yumpkg.check_db removal in
     Boron

   * PR #36344: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 3a37fe5 merge error overwrites correct ssh_host with  stale  data  in
     ip_address (#36312)

   * PR  #36299:  (rallytime) Gate the pkg.group_installed state test: not
     all pkg modules have group_install

   * b3aac0e Back-port #36273 to 2016.3 (#36295)

   * 7296179 Back-port #36124 to 2016.3 (#36296)

   * PR #36297: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 7684ebd Filter out pub kwargs from cloud runner (#36178)

   * PR #36238: (pass-by-value) Add ability to clone from  a  snapshot  to
     salt-cloud vmware driver

   * a0bbb0f Integration tests fixes for 2016.3 (#36263)

   * PR #36264: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR  #35688:  (cachedout)  Splat  serializer  default configs into the
     serializer kwargs

   * PR #36025: (mirceaulinic) Potential fix for
     `#36021`_

   * 449c298 Fix timezones states on OS X (#36183)

   * PR #36235: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36137: (cachedout) Allow highstate outputter to show all results

   * 1b12940 Docs clarification for module sync and state.apply (#36217)

   * PR #36184: (DmitryKuzmenko) Disable signal  handling  while  handling
     signal

   * PR #36203: (xiaoanyunfei) fix owner of MultiprocessingLoggingQueue

   * b586ed7  if  the  backend stack traces when it should return an empty
     string (#36193)

   * PR #36188: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35907: (rallytime) Catch CommandExecutionError when the group  in
     group_installed doesn't exist

   * PR  #36068:  (rallytime)  Remove grains type deprecation warning from
     2016.3

   * PR #36152: (cachedout) Remove unnecessary unpack

   * PR #36158: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 3445a33 Remove unclosed backticks in walkthrough doc (#36170)

   * PR #36161: (jacobhammons) Adds
     `#36055`_
      to release notes

   * PR #36139: (meaksh) Fixing unit tests for 2016.3

   * PR #36143: (multani) doc: fix doc formatting for salt.states.mount

   * PR #36070: (rallytime) Use __utils__ instead of  salt.utils.cloud  in
     opennebula driver

   * PR  #36089:  (terminalmage)  Support running git states / remote exec
     funcs as a different user in Windows

   * PR #35923: (kstreee) Fixes a bug that Ctrl-c not working on Salt CLI.

   * PR #36078: (thatch45) Failhard test=True fix

   * PR #34529: (Ch3LL) Add skip_verify for archive.extracted

   * PR #36073: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * a86e36c Add docs for new kwargs added to  the  wheel  key  module  (
     #36040)

   * 2934fc1 Doc cherrypy deemphasize urlencoded (#36047)

   * PR #36039: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 1d90c42 Back-port #35824 to 2016.3 (#36038)

   * 65b6734 catch unicode encoding errors in json outputter (#36033)

   * 822481e  modules.service:  Do  not  default to OpenRC on Gentoo, also
     allow systemd (#36010)

   * b68d293 fix redis_return's clean_old_jobs. (#36014)

   * 95591c2 Add documentation about salt_interface to EC2 docs (#36015)

   * PR #36019: (meaksh) Back-port #36000 to 2016.3

   * b9fc51a Fix error when profiling  is  turned  on  and  minions  don't
     return (#36028)

   * 20a361d Add include_* kwargs to the
     *
     _dict key functions (#36030)

   * PR  #36024: (DmitryKuzmenko) Don't subscribe to events if not sure it
     would read them.

   * PR #36023: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #36004: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35952: (twangboy) Load UserProfile when using RunAs (2016.3)

   * PR #35959: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35955: (jacobhammons) Version docs to 2016.3.3

   * 9910b9c Fix incremental doc builds - OS  X,  postgres  returner,  tcp
     transport doc updates (#35865)

   * 24f9d33 Speed up FreeBSD pkg install process for pkg.latest since pkg
     command by default tries to update repository DB on each  search:  (
     #35904)

   * b87e4f1  Salt Cloud: add centos default user for official CentOS AMIs
     (#35931)

   * 580e0d4 Mention that docker image names must be given with repository
     (#35926)

   * PR  #35868:  (rallytime)  Add  more  helpful return messages for drac
     runner

   * PR #35903: (rallytime) [2016.3] Merge forward from 2015.8 into 2016.3

   * PR #35855: (vutny) [REGRESSION] salt-cloud: fix path to  Salt  Master
     socket dir

   * PR  #35881:  (whiteinge)  Add fail-safe in case Salt gives us data we
     can't serialize

   * 9679266 Add engines to list of extension  module  options  in  master
     config docs (#35864)

   * 40bcb7d  Fix  IAM  roles  statement  to  be  boto version specific in
     sqs_events (#35861)

   * ee45a88 Fix doc formatting for sqs_events engine  example  config  (
     #35860)

   * PR #35859: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35849: (theredcat) Fix potential infinite loop with no error when
     using recursive makedirs

   * PR #35682: (vutny) [BACKPORT] Fix empty  fun_agrs  field  in  Reactor
     generated events

   * PR  #35792:  (DmitryKuzmenko) Reconnect syndic to event bus if master
     disappeared.

   * PR #35817: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * b89f455 fix 34241, webutil.useradd_all is deprecated (#35788)

   * 2be5daf Bump the deprecation warning in pkgrepo state to Nitrogen  (
     #35810)

   * 083d836  Fix  misuse of HTTP credentials in modjk execution module (
     #35796)

   * 0247867 Adds mock for tornado.locks (#35807)

   * e4dfc21 Trivial documentation spelling fix (#35800)

   * PR #35763: (isbm) Sphinx crash: documentation config fix

   * cd90052 Documentation spelling fixes (#35773)

   * PR #35767: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR          #35753:          (rallytime)          Fixup           the
     unit.client_test.LocalClientTestCase.test_cmd_subset from #35720

   * dab8428  Add versionadded for enabled function in apache_module state
     (#35732)

   * PR #35737: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35729: (cachedout) Remove docs mocks for msgpack and psutils

   * PR #35628: (jf) Fix user.present  state  reporting  for  groups  when
     remove_groups=false

   * PR #35696: (xiaoanyunfei) fix maximum recursion depth bug

   * PR  #35720:  (hu-dabao)  fix  20575, make subset really return random
     subset

   * PR #35700: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * PR #35634: (hu-dabao)  fix  34922,  StopIteration  should  not  throw
     exception out

   * PR #35679: (twangboy) Revert to vcredist 12 (2013)

   * PR #35662: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   * 64974c8 Backport #35627 to 2016.3 (#35661)

   * PR  #35615:  (hu-dabao)  fix  35591, verify the acl file exist before
     proceed

   * PR #35485: (cro) Cassandra returner bugfixes and documentation.

   * PR #35520: (morganwillcock) Check for all  success  return  codes  in
     win_dism state

   * PR #35616: (xbglowx) Remove duplicate auth_tries in minion docs

   * PR  #35552:  (DmitryKuzmenko)  Syndic  fix: don't strip 'retcode' and
     'success' from events.

   * PR #35559: (Jlin317) Fix highstate outputter when it's given multiple
     results

   * PR #35605: (rallytime) Back-port #32739 to 2016.3

   * PR #35606: (rallytime) [2016.3] Merge forward from 2015.8 to 2016.3

   Salt 2016.3.5 Release Notes
   Version 2016.3.5 is a bugfix release for 2016.3.0.

   Improved Checksum Handling in file.managed, archive.extracted States
   When  the  source_hash  argument  for  these  states  refers  to a file
   containing checksums, Salt now looks for checksums matching the name of
   the  source URI, as well as the file being managed. Prior releases only
   looked for checksums matching the filename being managed. Additionally,
   a new argument (source_hash_name) has been added, which allows the user
   to disambiguate ambiguous matches when more than one matching  checksum
   is found in the source_hash file.

   A  more  detailed explanation of this functionality can be found in the
   file.managed documentation, in the section for the new source_hash_name
   argument.

   Salt 2015.8.0 Release Notes - Codename Beryllium
   2015.8.0 Detailed Change List
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs)

   Generated at: 2015-09-09T18:15:43Z

   This list includes all pull requests  merged  into  the  2015.8  branch
   between  the  forking  of  the  branch  from develop and the release of
   2015.8.0.

   Statistics:

   * Total Merges: 682

   * Total Issue references: 342

   * Total PR references: 866

   Pull Requests:

   * #26993: (whiteinge) Backport #26975

   * #26970: (cachedout) Revert "better path query parsing in fileserver"

   * #26980: (terminalmage) Use human-readable cachedirs for  gitfs-backed
     winrepo

   * #26969: (TheBigBear) URL of salt windows downloads has changed

   * #26968: (TheBigBear) URL of salt windows downloads has changed

   * #26958:  (s0undt3ch)  Bradthurber  bootstrap  command  line  help doc
     update

   * #26949: (rallytime) Back-port #25148 to 2015.8

   * #26914: (cro) Add salt-proxy script and manpage to setup.py  so  they
     will get installed.

   * #26909: (terminalmage) Don't try to git clone from /tmp on Windows

   * #26910: (s0undt3ch) Sometimes the event system is just too fast

   * #26905: (s0undt3ch) Exit the loop if run_once is true

   * #26897: (msteed) spm file hash part deux

   * #26900:  (s0undt3ch) If no tag is passed, don't actually subscribe to
     anything.

   * #26880:    (s0undt3ch)    Restore    backwards    compatibility    to
     salt.utils.event

   * #26896: (msteed) spm remove: use pkgfiles to calculate file hashes

   * #26891: (jtand) Fixed an unboundlocalerror

   * #26892: (cachedout) Make the testing ioloop the current one

   * #26886:  (jtand)  Gets  the  azure  version correctly on python-azure
     1.0.0

   * #26870: (rallytime) Back-port #26834 to 2015.8

   * #26865: (dmurphy18) Fix apt preferences for apts, repos for  pbuilder
     building for Debian

   * #26873: (terminalmage) Properly handle getting local config values in
     older git versions

   * #26869: (rallytime) Fix provider --> driver change for salt-cloud lxc

   * #26858: (terminalmage) Fix a couple version checks for git state  and
     execution module

   * #26853: (UtahDave) Fix salt-cloud on windows

   * #26852:  (basepi)  [2015.8]  Only  reference  msgpack  if it imported
     successfully

   * #26835: (terminalmage) Backport #26572 to 2015.8

   * #26836: (jacobhammons) Added rst  source  for  salt-proxy  man  page,
     added build and copy lines ...

   * #26818: (terminalmage) Support empty repositories in git.latest

   * #26819:  (rallytime)  Make  sure  we're calling _validate_name in the
     correct place in 2015.8 Linode driver

   * #26841: (l2ol33rt) Fix reference before assignment in sqs engine

   * #26822:  (terminalmage)  Add  some  missing  imports  for  masterless
     winrepo

   * #26831: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26826: (techhat) Pass a package name to unregister_file()

   * #26757: (cachedout) Fix various filehandle leaks

   * #26816: (gtmanfred) rev defaults to HEAD

   * #26801:  (jacobhammons)  Added  doc for dockerng minion configuration
     options

   * #26808: (anlutro) Fix git init argument formatting

   * #26807:     (terminalmage)     Move     salt.utils.itersplit()     to
     salt.utils.itertools.split()

   * #26796: (jacobhammons) Add doc for __states__

   * #26764:  (sjorge)  salt.utils.is_proxy()  is no longer always true on
     SunOS/Illumos/SmartOS

   * #26772: (sjorge) pull in smartos 'virt' module from develop

   * #26726: (terminalmage) Redact HTTPS Basic Auth in states/funcs  which
     deal with git remotes

   * #26769:  (terminalmage)  Use  --track to set tracking branch on older
     git versions

   * #26765: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26761: (sjorge) fix SPM paths on smartos/illumos esky

   * #26751: (terminalmage) Fixes for masterless winrepo

   * #26745: (rallytime) Make sure  pyrax  configs  are  in  place  before
     checking for deps

   * #26746:  (rallytime)  Make  sure nova configs are set before checking
     for dependencies

   * #26750: (basepi) [2015.8] Add __utils__ to state modules

   * #26752: (cro) Fix typo in some diagram labels

   * #26747: (basepi)  [2015.8]  Add  __states__  to  state  modules,  for
     cross-calling states

   * #26744: (basepi) [2015.8] Fix issue from #26717

   * #26737:  (dmurphy18)  Fix to allow for package naming other than just
     salt

   * #26742: (rallytime) Only warn about vsphere deprecation if vsphere is
     configured

   * #26733: (sjorge) Refactor of smartos_vmadm module

   * #26735: (s0undt3ch) Add .hg and .cvs to spm_build_exclude

   * #26720:  (UtahDave)  Updates  for winrepo in 2015.8 to support jinja,
     while maintaining backwards compat

   * #26719: (jodv) Backport 26532 to 2015.8

   * #26721: (rallytime) Linode Driver Cleanup

   * #26707: (techhat) Add top_level_dir to FORMULAs

   * #26723: (s0undt3ch) Handle SPM paths in the setup script

   * #26717: (basepi) [2015.8] Revert loader changes from #26645

   * #26712: (techhat) Move SPM paths around

   * #26680: (TheBigBear) add more python libs info in '--versions-report'

   * #26716: (terminalmage) Allow git identity to be a list

   * #26691: (garethgreenaway) Fixes to ipset module for 2015.8

   * #26701: (kev009) Ignore the first element of kern.disks split,  which
     is the sysctl name (new disks grain)

   * #26678:  (terminalmage) Restructure git.latest rewrite to work better
     when following HEAD

   * #26679: (rallytime) Back-port #26661 to 2015.8

   * #26684: (techhat) Add reactor formulas to spm

   * #26682: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26671: (rallytime) Warn  users  if  cloud  driver  dependencies  are
     missing.

   * #26674: (rallytime) Back-port #26583 to 2015.8

   * #26670: (techhat) Set up SPM to install -conf packages

   * #26657: (jfindlay) top file compilation fixes

   * #26659: (TheBigBear) minor doc edits - spelling

   * #26654: (jfindlay) merge
     `#26650`_

   * #26567: (jtand) Added git version check to git module

   * #26649: (twangboy) Fixed Lint for real in win_repo.py

   * #26608: (jacobhammons) 2015.8.0 release notes and doc/conf.py updates

   * #26646: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26645: (rallytime) Back-port #26390 to 2015.8

   * #26642: (twangboy) Added function to render winrepo Jinja

   * #26625: (twangboy) Correctly detect packages with no version, docs

   * #26575: (msteed) Update spm for integration into raas

   * #26635: (cro) Don't report windows as a proxy.

   * #26622:  (rallytime)  [2015.8]  Also  add -Z to script args for cloud
     tests

   * #26619: (rallytime) Apply cloud test fixes from 2015.5 to 2015.8

   * #26603: (terminalmage) Fixes for git.latest, git  module  integration
     tests, etc.

   * #26577: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26534: (cachedout) Bump required Tornado version to 4.2.1

   * #26566:  (cachedout)  Don't  stacktrace  trying  to publish without a
     master

   * #26541: (terminalmage) Make winrepo execution  module  use  the  same
     code as the runner

   * #26530: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26570: (cachedout) Fix haproxy docs to be valid

   * #26562: (cachedout) Fix suprious error message with systemd-detect

   * #26557: (jfindlay) add docs to #26550

   * #26544:  (nmadhok) Do not raise KeyError when calling avail_images if
     VM/template is in disconnected state

   * #26501: (terminalmage) Update git_pillar docs, add git.list_worktrees
     function

   * #26521: (terminalmage) Work around upstream git bug when cloning repo
     as root

   * #26518: (krak3n) Fix for
     `#25492`_

   * #26514: (evverx) Unmask a runtime masked services too

   * #26529: (mnalt) bugfix: fix service.enable for missing rc.conf

   * #26516: (techhat) Move more path operations into SPM loader

   * #26533: (cachedout) Fix too aggressive even init check

   * #26522: (cro) Do not load package provider if its not a proxy

   * #26531: (cachedout) Fix failing event tests and modify event init

   * #26433: (cro) Add support for default proxy  config  options,  change
     default  location  of  proxy  config  and  log to /etc/salt/proxy and
     /var/log/proxy

   * #26504: (nmadhok) [Backport] Adding ability to  specify  the  virtual
     hardware version when creating VM

   * #26517: (cachedout) Better fix for opensuse tornado httpclient

   * #26479:  (rallytime)  Don't  allow  VMs  with  duplicate  names to be
     created in EC2/AWS

   * #26488: (cachedout) Don't pass unsupported kwarg to tornado

   * #26451: (terminalmage) Use 'rpm -qa' instead  of  repoquery  to  list
     installed packages

   * #26491:  (jacobhammons) doc site css fix for tiny fonts that appeared
     in code or pre tags in ...

   * #26442: (rallytime) Hide API Key from debug logs for Linode Driver

   * #26441: (rallytime) Refactor a few linode functions to be useful with
     salt-cloud command

   * #26485: (s0undt3ch) One more missed typo

   * #26495: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26492: (cachedout) Fix schedule test error on py26

   * #26489: (cachedout) Fixing more tarfile tests on py2.6

   * #26475: (cachedout) Better object checking on asyncreq cleanup

   * #26477:                        (cachedout)                        Fix
     integration.modules.git.GitModuleTest.test_archive on py26

   * #26469: (jtand) --annotate and  --message  aren't  valid  options  in
     older versions of git.

   * #26439: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26464: (rallytime) Back-port #26456 to 2015.8

   * #26463: (rallytime) Back-port #26455 to 2015.8

   * #26449:  (s0undt3ch)  The  CLI  options  are  not  meant  to  include
     underscores.

   * #26270: (sjorge) salt.modules.network now supports SmartOS and  SunOS
     < Solaris 11

   * #26436: (TheBigBear) minor edits

   * #26410: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26427:  (anlutro)  git.latest  with  no rev: fix concatenation error
     (NoneType and str)

   * #26307: (cachedout) Fix bug in top file ordering

   * #26428: (cro) Update docs to reflect new pillar structure

   * #26429: (cachedout) Add  release  note  regarding  tcp  transport  on
     freebsd

   * #26418: (driskell) Fix forward-merged caching from 2015.5 into 2015.8
     to be compatible with the new match_func

   * #26252: (DmitryKuzmenko) Issues/24048 http client 2015.8

   * #26413: (evverx) Fix service.{start,restart,reload,force-reload}  for
     masked services

   * #26393: (dmurphy18) Added option parameters to make_repo to allow for
     configuration settings

   * #26422: (TheBigBear) no dots in SLS filename __AND__ any  directories
     (incl git repos)

   * #26323: (0xf10e) Fix Credentials used in glance Exec Module

   * #26341: (terminalmage) Rewrite git state and execution modules

   * #26419: (terminalmage) Only use pygit2.errors if it exists

   * #26423: (eliasp) doc - Correct function name for peer configuration

   * #26401: (cachedout) Adapt proxy minion to tornado (w/lint)

   * #26400: (rallytime) Back-port #26318 to 2015.8

   * #26397:  (s0undt3ch)  A  single  isinstance()  check for all types is
     enough

   * #26385: (gtmanfred) don't require volume endpoint in nova driver

   * #26287: (techhat) Break out SPM components into loaders

   * #26384: (TheBigBear)  Fix shell quoting for cmd.run

   * #26391: (rallytime) Back-port #26367 to 2015.8

   * #26383: (rallytime) Allow the creation of a VM without a profile

   * #26375: (s0undt3ch) [2015.8] Schema DictItem required attribute fixes

   * #26363: (garethgreenaway) Fixes to mount state 2015.8

   * #26347:  (0xf10e)  Load  'pkgng'  as  'pkg'   on   FreeBSD   9   when
     providers:pkg == 'pkgng'

   * #26361: (TronPaul) sign security token

   * #26346: (TronPaul) Fix s3 using IAM credentials

   * #26331: (mnalt) fix bug in sysrc to allow for empty rc variables

   * #26334:  (rallytime)  Call  salt.utils.cloud.bootstrap  in GCE Driver
     provisioning

   * #26308:  (dmurphy18)  Support  for  environment  overrides   building
     packages

   * #26279:   (TheScriptSage)   Merge   changes   for  pull`#26083`_  and
     pull`#25632`_ into 2015.8

   * #26224:  (cachedout)  Cleanup   of   a   few   cases   to   move   to
     salt.utils.fopen

   * #26260: (nmadhok) Correct spelling of integration in docs

   * #26226: (rallytime) Fix
     `#25463`_

   * #26248:  (nmadhok)  Initial  commit  of  unit  tests for vmware cloud
     driver

   * #26228: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26244: (nmadhok) Backport additions  to  VMware  cloud  driver  from
     develop to 2015.8 branch

   * #26235:     (sjorge)     salt.utils.is_smartos_zone,    inverse    of
     is_smartos_globalzone

   * #26221: (sjorge) SmartOS grain fixes

   * #26218: (terminalmage) Add warning about file.recurse unicode  errors
     with vim swap files.

   * #26214: (rallytime) Back-port #24878 to 2015.8

   * #26211: (techhat) Move SPM to its own directory

   * #26197: (TronPaul) Fix GitFS when whitelisting base

   * #26200: (anlutro) Make it possible to run salt-cloud as current user

   * #26201:  (kev009)  Avoid VBOX storage emulation bugs in FreeBSD disks
     grain

   * #26188: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26194: (basepi)  Allow  virtual  grains  to  be  generated  even  if
     virt-what is not available

   * #26176: (rallytime) Back-port #26165 to 2015.8

   * #26169:  (terminalmage)  Fix  attribute  error  in  gitfs'  find_file
     functions

   * #26170: (nmadhok) [Backport]  Make  sure  variable  is  a  dictionary
     before popping something from it.

   * #26143: (nmadhok) VMware cloud driver fixes [forward port from 2015.5
     into 2015.8]

   * #26173: (jacobhammons) Updates to  cloud  docs  for  the  provider  >
     driver change

   * #26125:   (evverx)  Use  timedatectl  set-timezone  to  tzsetting  if
     available

   * #26145: (sjorge) smartos_imgadm cleanup

   * #26148: (terminalmage) Refactor winrepo support

   * #26128: (sjorge) imgadm.avail should return multiple results

   * #26109: (jfindlay) fix quote indent

   * #26089: (anlutro) User state/module: fix coercing of None into string
     "None" in GECOS

   * #26081: (cachedout) Move invocation routine up

   * #26086: (rallytime) Back-port #26019 to 2015.8

   * #26087: (rallytime) Back-port #26059 to 2015.8

   * #26052: (jtand) Rh_ip fix

   * #26078: (cachedout) Fix missing key in error return

   * #26074: (basepi) [2015.8] Re-apply #25358 in 2015.8

   * #26069: (jfindlay) fix win_firewall.delete_rule

   * #26066:  (s0undt3ch)  [2015.8]  Update  to  latest  bootstrap  stable
     release v2015.06.08

   * #26049: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #26026: (anlutro) Fix httpasswd result false positive in test mode

   * #26037: (rallytime) Back-port #25489 to 2015.8

   * #26004: (techhat) Allow updating a single SPM repo at a time

   * #26012: (cachedout) Merge kwargs into opts for tcp client

   * #26007: (anlutro) file.managed: wrap os.remove in  if  isfile,  don't
     remove on success

   * #26009:  (terminalmage)  Add  winrepo  and  dockerng  information  to
     2015.8.0 release notes

   * #26006: (basepi) Revert #25727 in favor of #25645

   * #26001: (cachedout) Fix failing tests

   * #25978: (anlutro) Correct service state changes in test mode

   * #25982: (sjorge) salt.modules.smartos_* limit to global zone only

   * #25989: (rallytime) Back-port #25832 to 2015.8

   * #25988: (cachedout) Move #25642 to 2015.8

   * #25999: (s0undt3ch) Include subschema defaults

   * #25997: (s0undt3ch) Allow getting a defaults dictionary  from  schema
     defaults

   * #25979: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25902: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25956: (anlutro) Fix user argument to cron functions

   * #25946: (sjorge) Fix for salt.utils.decorators under esky

   * #25957:  (anlutro)  Remove  temporary  file  after  file.managed with
     checkcmd

   * #25874: (rallytime) Back-port #25668 to 2015.8

   * #25929: (sjorge) salt.module.pkgin's __virtual__() should not  return
     None if pkg_info is not present

   * #25952:  (garethgreenaway)  Log when event.fire and event.fire_master
     fail 2015.8

   * #25944: (sjorge) Smartos libcrypto nonesky fix

   * #25906: (dmurphy18) Cherry-pick  of  pkgbuild  changes  from  develop
     branch

   * #25925:   (sjorge)  Create  default  log  location  in  smartos  esky
     buildscript

   * #25928: (cachedout) Fix stacktrace for non-existant states

   * #25922: (jacksontj) Correct max_wait -> max_auth_wait in MultiMinion

   * #25907: (rallytime) Back-port #25892 to 2015.8

   * #25910: (terminalmage) Pass osarch to check_32()

   * #25849: (basepi) Repress template error for GPG renderer (can't  seek
     an OrderedDict)

   * #25868: (rallytime) Back-port #25404 to 2015.8

   * #25896: (cachedout) Lint

   * #25876: (jacksontj) Fixes for 2015.8

   * #25867: (rallytime) Back-port #25370 to 2015.8

   * #25845: (jacobhammons) updated versionadded

   * #25836: (jacksontj) Keep track of SyncWrapper's IOLoop usage

   * #25859: (0xf10e) warn_until(Carbon,...) instead of Boron

   * #25505: (0xf10e) Glance state module for 2015.8 "Beryllium"

   * #25843: (jtand) Fixed a lint error in parsers.py

   * #25835: (techhat) spm update_repo doesn't always require arguments

   * #25837: (jacobhammons) regenerated man pages

   * #25830: (sjorge) Loading of libcrypto on smartos esky fixed

   * #25808:  (jfindlay)  add highstate opts to config/__init__.py, update
     docs

   * #25820: (sjorge) Prerequisite to fix the smartos libcrypto loading

   * #25781: (anlutro) Fix iptables.build_rule

   * #25764: (gtmanfred) allow use of cloudnetworks in ssh_interface

   * #25736: (jfindlay) insert explicit formatter number

   * #25742: (rallytime) Back-port #25731 to 2015.8

   * #25741: (rallytime) Back-port #25727 to 2015.8

   * #25712: (cachedout) Fix outputter for state.apply

   * #25698: (rallytime) Back-port #25659 to 2015.8

   * #25690: (anlutro) Fix highstate duration alignment (again)

   * #25684: (davidjb) Fix doc around Include/Exclude for states

   * #25549: (techhat) Switch Scaleway to salt.utils.cloud.bootstrap()

   * #25667: (jfindlay) add 2015.8.0rc2 autogenerated changelog

   * #25653: (anlutro) Properly align highstate duration sum

   * #25663: (rallytime) Back-port #25638 to 2015.8

   * #25639: (terminalmage) Don't do pre-flight check on git_pillar if  it
     is not configured

   * #25587: (cachedout) Fix prereq in salt.state

   * #25628:  (anlutro) Highstate output: show duration in seconds instead
     of milliseconds when appropriate

   * #25631: (basepi) Remove trailing whitespace

   * #25627: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25626: (basepi) Fix the highstate outputter  if  'duration'  is  not
     present

   * #25601:  (terminalmage)  Fix error message when local bin pkg path is
     not absolute

   * #25595: (terminalmage) Bring git_pillar up  to  feature  parity  with
     gitfs

   * #25619: (cachedout) Lint stateconf changes

   * #25578: (davidjb) Allow parent relative includes in state files

   * #25610:  (s0undt3ch)  [2015.8]  Update the bootstrap script to latest
     release v2015.07.22

   * #25599: (jfindlay) fix transport settings in #25596

   * #25596: (jfindlay) Tcp test

   * #25591: (garethgreenaway) Return data for scheduled  jobs  in  2015.8
     default to True.

   * #25588: (basepi) Fix some of the retcode work from #23105

   * #25583: (jtand) Fixed lint error where pprint wasn't imported.

   * #25572: (rallytime) Back-port #25570 to 2015.8

   * #25575:  (rallytime) Make Sure Scaleway driver works with deprecation
     paths

   * #25564: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25566: (techhat) Fix download process for SPM repo updates

   * #25553: (techhat) Switch SoftLayer to salt.utils.cloud.bootstrap()

   * #25552: (techhat) Update pricing for SoftlayerHW

   * #25547: (techhat) Switch Parallels to salt.utils.cloud.bootstrap()

   * #25548: (techhat) Switch Proxmox to salt.utils.cloud.bootstrap()

   * #25543: (techhat) Switch GCE to salt.utils.cloud.bootstrap()

   * #25546: (techhat) Switch CloudStack to salt.utils.cloud.bootstrap()

   * #25558: (cachedout) Lint config_test

   * #25515: (s0undt3ch) salt.utils.schema fixes

   * #25514: (garethgreenaway)  fixes  to  schedule.add  documentation  in
     2015.8

   * #25508: (s0undt3ch) [2015.8] Update bootstrap script to latest stable
     release, v2015.07.17

   * #25501: (basepi)  Add  optional  job  end  time  to  the  local_cache
     returner

   * #25491: (s0undt3ch) Let's call it for what it is!

   * #25462:  (rallytime)  Wrap is_profile_configrured calls in try/except
     block

   * #25439: (rallytime) Reduce digital_ocean API call frequency

   * #25451: (s0undt3ch) Salt-SSH Scan roster bugfixes (And Py3 support)

   * #25449: (ruzarowski) Exclude dotfiles and directories from minion key
     lists (Fixes
     `#25448`_
     )

   * #25421: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25412: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25415: (bechtoldt) [docs] declare YAML as code block

   * #25407: (rallytime) Back-port #23236 to 2015.8

   * #25409: (rallytime) Back-port #24422 to 2015.8

   * #25394: (rallytime) Back-port #25355 to 2015.8

   * #25393: (rallytime) Back-port #25289 to 2015.8

   * #25387: (cachedout) Lint #25319

   * #25319:   (ruzarowski)   [cloud:EC2]   Move   SourceDest   logic   to
     _update_enis and add  alias for delete_interface_on_terminate

   * #25310: (anlutro) Add an "is list" test to the jinja environment

   * #25264: (ruzarowski) Fix AttributeError in fileserver update_opts

   * #25372: (rallytime) Don't stacktrace when provisioning instances with
     softlayer* drivers

   * #25315:     (ruzarowski)     [cloud:EC2]     Move     handling     of
     AssociatePublicIpAddress  to   associate_eip/allocate_new_eip   logic
     depending on value type

   * #25312:  (ruzarowski)  [cloud:EC2] Introduce eni Name property to set
     name tag value after its creation

   * #25311: (ruzarowski) [cloud:EC2] Add ability to  attach  an  existing
     eni

   * #25280: (rallytime) Remove deprecation warnings for Beryllium

   * #25329: (twangboy) Fixed some documentation errors

   * #25300: (s0undt3ch) Fix ordering issue & Added requirements support

   * #25283: (jfindlay) ensure ret is always defined

   * #25252:   (jfindlay)  make  args  optional  with  default  values  in
     win_firewall.delete_rule

   * #25257: (notpeter) Document SourceDestCheck added in #25242.

   * #25298: (twangboy) Continue if profile not found

   * #25296: (twangboy) Fixed file.comment for windows

   * #25254:  (rallytime)  Change  versionadded/changed  references   from
     Beryllium to 2015.8.0

   * #25285: (thusoy) Remove error logging of missing victorops keys

   * #25266:  (ruzarowski)  cloud:  EC2  eni property SourceDestCheck is a
     AttributeBooleanValue

   * #25216: (jfindlay) replace shell code with native python code

   * #25278: (rallytime) Don't require size for  all  cloud  drivers  when
     checking profile configs

   * #25271: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25263: (techhat) Allow non-standard HTTP requests on tornado

   * #25253:  (s0undt3ch)  Remove  the deprecation warning. The driver has
     been renamed.

   * #25248: (techhat) Do not resize while iterating

   * #25244: (rallytime) Remove parted deprecations and fix failing tests

   * #25242: (ruzarowski) Make SourceDestCheck flag available  to  network
     interface definition

   * #25226: (nmadhok) Backporting fix for issue
     `#25223`_
      on 2015.8 branch

   * #25234:  (krak3n)  Fix:  Bug  in  boto_asg  state argument passing to
     boto_asg module

   * #25222: (rallytime) Back-port #25219 to 2015.8

   * #25188: (rallytime) Use linode status descriptions  instead  of  ints
     when logging status to CLI

   * #25203: (s0undt3ch) Added DictConfig with tests & More tests

   * #25189: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * #25184: (rallytime) Back-port #25126 to 2015.8

   * #25172:  (s0undt3ch)  Comment  out  imports  while  the  YAML and RST
     rendering is not in-place.

   * #25158: (s0undt3ch) Comment out not implemented code

   * #25145: (s0undt3ch) Implement oneOf, anyOf, allOf and not  with  unit
     tests

   * #25140: (s0undt3ch) Make the detection code work under Python 3.4

   * #25131: (s0undt3ch) Array support in salt.utils.config

   * #25130: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   The  2015.8.0  feature  release  of  Salt  contains  several  major new
   features. As usual the release notes are not exhaustive  and  primarily
   include  the  most notable additions and improvements. Hundreds of bugs
   have been fixed and many modules have been  substantially  updated  and
   added.

   New SaltStack Installation Repositories
   SaltStack now provides installation repositories for several platforms,
   with more to come.  See the following links for instructions:

   * Red Hat / CentOS 5, 6, 7

   * Debian 8

   * Windows

   * FreeBSD

   Send Event on State Completion
   A fire_event global state keyword argument was added  that  allows  any
   state to send an event upon completion. Useful for custom progress bars
   and checking in on long state runs. See fire_event.

   ZeroMQ socket monitoring
   If zmq_monitor is enabled, log all ZMQ  events  for  socket  monitoring
   purposes. Verbose, but useful.

   SPM (Salt Package Manager)
   Allows Salt formulas to be packaged for ease of deployment. See spm.

   NOTE:
      The spm executable was not included in the Debian or Ubuntu packages
      for the 2015.8.0 or the 2015.8.1 releases. This executable  will  be
      included  in  an  upcoming  release.  As  a workaround, copy the SPM
      script from the salt library  installation  into  /usr/local/bin  or
      your local equivalent.

   Specify a Single Environment for Top Files
   A  new  default_top  option was added to load the state top file from a
   single, specific environment, rather than merging top data  across  all
   environments.  Additionally,  new top_file_merge_strategy and env_order
   options were added for more control over top file merging. See The  Top
   File.

   Tornado TCP Transport
   Implemented  a  pure-TCP transport, in addition to ZeroMQ and RAET. The
   new transport uses Tornado, which allows Salt to use a standardized set
   of  libraries  for  asynchronous behavior, which should greatly improve
   reliability and performance.

   NOTE:
      Tornado is considered expiremental in this  release.  The  following
      known issues were being investigated at the time of release:

          * TCP tests show performance degredation over time (issue 26051)

          * TCP  transport  stacktrace on windows minion: Future exception
            was never retrieved (issue 25718)

          * [freebsd] TCP transport  not  working  in  2015.8.0rc3  (issue
            26364)

   Proxy Minion Enhancements
   Proxy  Minions  have  undergone  a  significant overhaul in 2015.8, see
   Proxy Minion Enhancements.

   Engines
   Salt engines are long-running, external processes that  leverage  Salt.
   See Salt Engines.

   Core Changes
   * Add  system  version  info  to versions_report, which appears in both
     salt --versions-report and salt '*' test.versions_report. Also  added
     is an alias test.versions to test.versions_report. (issue 21906)

   * Add  colorized  console  logging support.  This is activated by using
     %(colorlevel)s,  %(colorname)s,  %(colorprocess)s,  %(colormsg)s   in
     log_fmt_console   in   the   config  file  for  any  of  salt-master,
     salt-minion, and salt-cloud.

   Git Pillar
   The git external pillar has been rewritten to bring it  up  to  feature
   parity with gitfs. Support for
   pygit2_
    has  been  added, bringing with it the ability to access authenticated
   repositories.

   Using the new features will  require  updates  to  the  git  ext_pillar
   configuration,  further  details  can be found in the pillar.git_pillar
   docs.

   Salt Cloud Improvements
   * Pricing  data  from  several  cloud  providers  (GCE,   DigitalOcean,
     SoftLayer_HW, EC2)

   * All cloud providers now use standardized bootstrapping code.

   * Modified  the  Linode  Salt  Cloud  driver to use Linode's native API
     instead of depending on apache-libcloud or linode-python.

   Salt Cloud Changes
   * Changed the default behavior of rename_on_destroy to be set  to  True
     in the EC2 and AWS drivers.

   * Changed  the  default  behavior  of the EC2 and AWS drivers to always
     check for duplicate names of VMs before trying to create  a  new  VM.
     Will  now  throw  an error similarly to other salt-cloud drivers when
     trying to create a VM of the same name, even if  the  VM  is  in  the
     terminated state.

   * When  querying  for  VMs  in  digital_ocean.py,  the number of VMs to
     include in a page was changed from 20 (default) to 200 to reduce  the
     number of API calls to Digital Ocean.Ocean.

   State and Execution Module Improvements
   * New  and  improved  Docker  state  and  execution  modules (state and
     execution module).

   Git State and Execution Modules Rewritten
   The git state and execution modules  have  gone  through  an  extensive
   overhaul.

   Changes in the git.latest State
   * The branch argument has been added, allowing for a custom branch name
     to be used in the local checkout maintained by the git.latest  state.
     This  can be helpful in avoiding ambiguous refs in the local checkout
     when a tag is used as the rev argument. If no  branch  is  specified,
     then the state uses the value of rev as the branch name.

   * The  always_fetch  argument  no  longer  has  any effect, and will be
     removed in a future release. The state now detects whether or  not  a
     fetch  is  needed  based  on  comparisons  made between the local and
     remote repositories.

   * The force_fetch argument has been added to force a fetch if the fetch
     is  not a fast-forward (for instance, if someone has done a reset and
     force-pushed to the remote repository).

   * The remote_name argument has been deprecated and renamed to remote.

   * The force argument has been deprecated and renamed to force_clone  to
     reduce ambiguity with the other "force" arguments.

   * Using  SHA1  hashes  (full  or  shortened) in the rev argument is now
     properly supported.

   * Non-fast-forward merges are now detected  before  the  repository  is
     updated,  and  the state will not update the repository if the change
     is not a fast-forward. Non-fast-forward updates  must  be  overridden
     with  the  force_reset  argument.  If force_reset is set to True, the
     state will only reset the repository if it cannot be  fast-forwarded.
     This  is  in  contrast to the earlier behavior, in which a hard-reset
     would be performed every time the state was run  if  force_reset  was
     set to True.

   * A  git pull is no longer performed by this state, dropped in favor of
     a fetch-and-merge (or fetch-and-reset) workflow.

   git.config_unset state added
   This state allows for configuration  values  (or  entire  keys)  to  be
   unset. See here for more information and example SLS.

   git.config State Renamed to git.config_set
   To  reduce  confusion  after  the  addition  of  git.config_unset,  the
   git.config state has been renamed to git.config_set. The old config.get
   name will still work for a couple releases, allowing time for SLS files
   to be updated.

   In  addition,  this  state   now   supports   managing   multivar   git
   configuration values. See here for more information and example SLS.

   Initial Support for Git Worktrees in Execution Module
   Several  functions  have  been  added to the execution module to manage
   worktrees (a feature new to Git 2.5.0). State support  does  not  exist
   yet, but will follow soon.

   New Functions in Git Execution Module
   * git.config_get_regexp

   * git.config_unset

   * git.is_worktree

   * git.list_branches

   * git.list_tags

   * git.list_worktrees

   * git.merge_base

   * git.merge_tree

   * git.rev_parse

   * git.version

   * git.worktree_rm

   * git.worktree_add

   * git.worktree_prune

   Changes to Functions in Git Execution Module
   git.add
   * --verbose is now implied when running the git add command, to provide
     a list of the files added in the return data.

   git.archive
   * Now returns True when the git archive  command  was  successful,  and
     otherwise raises an error.

   * The  overwrite argument has been added to prevent an existing archive
     from being overwritten by this function.

   * The fmt argument has been deprecated and renamed to format.

   * Trailing slash no longer implied in prefix argument, must be included
     if this argument is passed.

   git.checkout
   * The  rev  argument  is  now  optional  when  using  -b or -B in opts,
     allowing for a branch to be created (or  reset)  using  HEAD  as  the
     starting point.

   git.clone
   * The name argument has been added to specify the name of the directory
     in which to clone the repository. If this option is  specified,  then
     the  clone  will  be  made within the directory specified by the cwd,
     instead of at that location.

   * The repository argument has been deprecated and renamed to url.

   git.config_get
   * The setting_name argument has been deprecated and renamed to key.

   * The  global  argument  has  been  added,  to  query  the  global  git
     configuration

   * The  all  argument  has been added to return a list of all values for
     the specified key, allowing for  all  values  in  a  multivar  to  be
     returned.

   * The cwd argument is now optional if global is set to True

   git.config_set
   * The value(s) of the key being set are now returned

   * The setting_name argument has been deprecated and renamed to key.

   * The setting_value argument has been deprecated and renamed to value.

   * The is_global argument has been deprecated and renamed to global.

   * The  multivar  argument has been added to specify a list of values to
     set for the specified key. The value argument is not compatible  with
     multivar.

   * The  add  argument  has  been  added  to  add  a value to a key (this
     essentially just adds an --add to the git config command that is  run
     to set the value).

   git.fetch
   * The force argument has been added to force the fetch when it is not a
     fast-forward. This could have been achieved in previous Salt versions
     by  including --force in the opts argument, this argument is just for
     convenience and to match the usage  of  other  functions  with  force
     arguments.

   * The  refspecs  argument  has  been  added  to  allow  for one or more
     refspecs to be provided which override the one(s)  specified  by  the
     remote.remote_name.fetch git configuration option.

   git.ls_remote
   * The repository argument has been deprecated and renamed to remote.

   * The branch argument has been deprecated and renamed to ref.

   * The  opts argument has been added to allow for additional CLI options
     to be passed to the git ls-remote command.

   git.merge
   * The branch argument has been deprecated and renamed to rev.

   git.status
   * Return data has been changed from a list of  lists  to  a  dictionary
     containing  lists  of  files  in  the  modified,  added, deleted, and
     untracked states.

   git.submodule
   * Added the command argument to allow for operations other than  update
     to  be  run  on submodules, and deprecated the init argument. To do a
     submodule update with init=True moving  forward,  use  command=update
     opts='--init'.

   * OpenStack Glance API V2 execution module

   * Amazon VPC state module

   * RallyDev execution module

   * BambooHR execution module

   * Stormpath execution, state modules

   * Remove unused argument timeout in jboss7.status.

   * Deprecate enabled argument in pkgrepo.managed in favor of disabled.

   * Archive  module  changes:  In  the  archive.tar and archive.cmd_unzip
     module functions, remove  the  arbitrary  prefixing  of  the  options
     string  with  -.  An  options  string beginning with a --long-option,
     would have uncharacteristically needed its first - removed under  the
     former scheme.  Also, tar will parse its options differently if short
     options are used with or without a preceding -, so it  is  better  to
     not  confuse  the user into thinking they're using the non- - format,
     when really they are using the with- - format.

   * Added __states__ to state modules,  for  cross-calling  states.  This
     enables  using  existing states when writing custom states. See cross
     calling states.

   Windows Improvements
   * Enhanced the windows minion silent  installation  with  command  line
     parameters  to  configure the salt master and minion name. See Silent
     Installer Options.

   * Improved user management with additional  capabilities  in  the  user
     module for Windows.

   * Improved  patch  management  with  a  new module for managing windows
     updates (win_wua).

   * Turned  on  multi-processing  by  default  for  windows   in   minion
     configuration.

   Windows Software Repo Changes
   A  next-generation (ng) windows software repo is available for 2015.8.0
   and later minions. When using this new repository, the  repo  cache  is
   compiled  on  the  Salt  Minion, which enables pillar, grains and other
   things to be available during compilation time.

   See the Windows Software Repository documentation for more information.

   Changes to legacy Windows repository
   If you have pre 2015.8 Windows minions connecting to your  2015.8  Salt
   master, you can continue to use the legacy Windows repository for these
   Salt minions.

   If you were  previously  using  this  repository  and  have  customized
   settings,  be  aware  that  several config options have been renamed to
   make their naming more consistent.

   See the Windows Software Repository documentation for more information.

   Win System Module
   The unit of the timeout parameter in the system.halt,  system.poweroff,
   system.reboot,   and  system.shutdown  functions  has been changed from
   seconds to minutes in order to be consistent  with  the  linux  timeout
   setting. (issue 24411)  Optionally, the unit can be reverted to seconds
   by specifying in_seconds=True.

   Other Improvements
   * Sanitize sensitive fields in http.query

   * Allow authorization to be read from Django and eauth

   * Add templating to SMTP returner

   * New REST module for SDB

   * Added rest_timeout config option and timeout  argument  to  jobs  api
     call

   * Provide  config  options for Raet lane and road buffer count. (Useful
     for BSD kernels)

   * Implemented ZeroMQ socket monitor for master and minion

   * Add end time to master job cache for jobs (optional, off by default)

   * Tornado is now the default backend for http.request

   * Support pillarenv selection as it's done for saltenv

   * salt was updated to use python-crypto version  2.6.1,  which  removes
     the dependency on python-m2crypto.

   Deprecations
   * The  digital_ocean.py  Salt  Cloud driver was removed in favor of the
     digital_ocean_v2.py driver as DigitalOcean has  removed  support  for
     APIv1.   The  digital_ocean_v2.py was renamed to digital_ocean.py and
     supports DigitalOcean's APIv2.

   * The vsphere.py Salt Cloud driver has been deprecated in favor of  the
     vmware.py driver.

   * The  openstack.py  Salt  Cloud driver has been deprecated in favor of
     the nova.py driver.

   * 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:

      my-ec2-cloud-config:
        id: 'HJGRYCILJLKJYG'
        key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
        private_key: /etc/salt/my_test_key.pem
        keyname: my_test_key
        securitygroup: default
        driver: ec2

   * The use of  lock  has  been  deprecated  and  from  salt.utils.fopen.
     salt.utils.flopen should be used instead.

   * The    following    args    have    been    deprecated    from    the
     rabbitmq_vhost.present state: user, owner,  conf,  write,  read,  and
     runas.

   * The  use  of runas has been deprecated from the rabbitmq_vhost.absent
     state.

   * Support for output in mine.get was  removed.  --out  should  be  used
     instead.

   * The  use  of  delim  was  removed from the following functions in the
     match execution module: pillar_pcre, pillar, grain_pcre,

   Security Fixes
   CVE-2015-6918 - Git modules leaking HTTPS auth credentials to debug log

   Updated the Git state and execution modules to no longer display  HTTPS
   basic  authentication  credentials in loglevel debug output on the Salt
   master. These credentials are now replaced with REDACTED in  the  debug
   output. Thanks to Andreas Stieger <[email protected]> for bringing this
   to our attention.

   Major Bug Fixes
   * Fixed minion failover to next master on DNS errors (issue 21082)

   * Fixed memory consumption in SaltEvents (issue 25557)

   * Don't lookup outside system path in which() util (issue 24085)

   * Fixed broken jobs rest api call (issue 23408)

   * Fixed stale grains data using in modules (issue 24073)

   * Added  ssh_identities_only  config  flag  for  ssh-agent   configured
     environments (issue 24096)

   * Fixed  "object  has  no  attribute"  errors for Raet transport (issue
     21640)

   * Flush event returners before master exit (issue 22814)

   * Fix CommandExecutionError in grains generation with lspci missing  (
     issue 23342)

   * Fix  salt-ssh  against  CentOS 7 when python-zmq not installed (issue
     23503)

   * Fix salt-ssh issues related to out-of-date six module (issue 20949)

   * Fix salt-ssh thin generation after previous run  was  interrupted  (
     issue 24376)

   * Use  proper line endings on Windows with "file.managed" w/contents (
     issue 25675)

   * Fixed broken comment/uncomment functions in file.py (issue 24620)

   * Fixed problem with unicode when changing computer description  (issue
     12255)

   * Fixed problem with chocolatey module not loading (issue 25717)

   * Fixed  problem  adding users to groups with spaces in the name (issue
     25144)

   * Fixed problem adding full name to user account (issue 25206)

   * Fixed gem module stack trace (issue 21041)

   * Fixed problem with file.managed when test=True (issue 20441)

   * Fixed problem with powershell hanging while waiting for user input (
     issue 13943)

   * Fixed  problem  where  the salt-minion service would not consistently
     start (issue 25272)

   * Fixed problem  where  pkg.refresh_db  would  return  True  even  when
     winrepo.p was not found (issue 18919)

   * Could someone please provide end to end example for Proxy Minion with
     REST (issue 25500)

   * Proxy minions stopped working between 2014.7 and 2015.5 (issue 25053)

   * Proxy minion  documentation  includes  outdated  code  sample  (issue
     24018)

   * Proxy Minion documentation missing grains example (issue 18273)

   * Improve process management in proxy minion (issue 12024)

   * Proxy  minion  never  comes  up  with message ' I am XXX and I am not
     supposed to start any proxies.' (issue 25908)

   * Fixed an issue that caused an exception when  using  Salt  mine  from
     pillar. (issue 11509)

   Salt 2015.8.1 Release Notes
   Version 2015.8.1 is a bugfix release for 2015.8.0.

   Security Fixes
   CVE-2015-6941  - win_useradd module and salt-cloud display passwords in
   debug log

   Updated the win_useradd module return data to  no  longer  include  the
   password  of  the newly created user. The password is now replaced with
   the string XXX-REDACTED-XXX.  Updated the Salt Cloud debug output to no
   longer    display   win_password   and   sudo_password   authentication
   credentials. Also updated  the  Linode  driver  to  no  longer  display
   authentication  credentials  in  debug  logs. These credentials are now
   replaced with REDACTED in the debug output.

   CVE-2015-6918 - Git modules leaking HTTPS auth credentials to debug log

   Updated the Git state and execution modules to no longer display  HTTPS
   basic  authentication  credentials in loglevel debug output on the Salt
   master. These credentials are now replaced with REDACTED in  the  debug
   output. Thanks to Andreas Stieger <[email protected]> for bringing this
   to our attention.

   Major Bug Fixes
   * Add support for spm.d/*.conf configuration of SPM (issue 27010)

   * Fix proxy grains breakage for non-proxy minions (issue 27039)

   * Fix global key management for git state

   * Fix passing http auth to util.http from state.file (issue 21917)

   * Fix multiprocessing: True in windows (on by default`)

   * Add pkg.info to pkg modules

   * Fix name of serial grain (this was accidentally renamed in 2015.8.0`)

   * Merge config values from master.d/minion.d conf  files  (rather  than
     flat update`)

   * Clean grains cache on grains sync (issue 19853)

   * Remove  streamed  response  for  fileclient to avoid HTTP redirection
     problems (issue 27093)

   * Fixed incorrect warning about osrelease grain (issue 27065)

   * Fix authentication via Salt-API with tokens (issue 27270)

   * Fix winrepo downloads from https locations (issue 27081)

   * Fix potential error with salt-call as non-root user (issue 26889)

   * Fix global minion provider overrides (issue 27209)

   * Fix backward compatibility issues for pecl modules

   * Fix Windows  uninstaller  to  only  remove  ./bin,  salt*,  nssm.exe,
     uninst.exe (issue 27383)

   * Fix misc issues with mongo returner.

   * Add sudo option to cloud config files (issue 27398)

   * Fix regression in RunnerClient argument handling (issue 25107)

   * Fix  dockerng.running  replacing  creation  hostconfig  with  runtime
     hostconfig (issue 27265)

   * Fix  dockerng.running  replacing  creation  hostconfig  with  runtime
     hostconfig (issue 27265)

   * Increased  performance  on  boto  asg/elb  states  due  to __states__
     integration

   * Windows minion no longer requires powershell to restart (issue 26629)

   * Fix x509 module to support recent versions of OpenSSL (issue 27326)

   * Some issues with proxy minions were corrected.

   Known Issues:

   * Proxy minions currently cannot execute a highstate because of the way
     the  proxymodule is being loaded internally.  This will be fixed in a
     future release.

   Changes for v2015.8.0..v2015.8.1
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-10-01T04:45:02Z

   Total Merges: 200

   Changes:

   * PR  #27584:  (jacobhammons)  added  changes  list to 2015.8.1 release
     notes

   * PR #27575: (rallytime) Don't report  existing  instances  as  running
     only if they're actually terminated in EC2

   * PR  #27573:  (basepi)  [2015.8]  Use  the  custom yaml serializer for
     minion_opts for salt-ssh

   * PR #27514: (clinta) Recent Versions of OpenSSL don't allow  importing
     incomplete PEMs

   * PR #27564: (jacobhammons) Man pages

   * PR  #27522:  (twangboy)  Removed  dependency on powershell to restart
     salt-minion

   * PR #27550: (rallytime) [2015.8] Clean up salt-cloud logging and  make
     it more useful

   * PR #27517: (jacobhammons) Updated install docs

   * PR  #27526: (eliasp) Add missing newlines before param listing to fix
     doc rendering

   * PR #27525: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27513: (terminalmage) Fix integration tests for worktree addition
     in git >= 2.6

   * PR #27510: (rallytime) Merge #27475 with test fixes

   * PR  #27451:  (ticosax)  [dockerng]  Enforce  usage of host_config and
     require docker-py>=1.4.0

   * PR #27461: (cachedout) Only clean context if it exists

   * PR #27473: (terminalmage) salt.utils.gitfs: Don't use  close_fds=True
     on Windows

   * PR #27496: (blueyed) Fix version reporting of gitpython

   * PR #27502: (ticosax) Add test to check we don't call inspect_image on
     absent images.

   * PR  #27497:  (blueyed)  dockerng:  fix  image_present   for   forced,
     non-existent image

   * PR  #27411:  (terminalmage)  Fix  invocation  of  git.config_get  and
     git.config_set

   * PR #27477: (terminalmage) Don't append role to hash_cachedir

   * PR #27474: (whiteinge) Add fake pymongo  version  attribute  for  the
     docs

   * PR  #27466:  (blueyed)  Fix  version  reporting  of  python-gnupg and
     mysql-python

   * PR #27465: (ticosax) Fix usage of dockerng "cmd" was #27459

   * PR #27417: (whiteinge) Backport #25243 into 2015.8

   * PR #27423: (dmurphy18) Changes to support configurable repository for
     Debian / Ubuntu

   * PR #27428: (rallytime) Back-port #27398 to 2015.8

   * PR #27429: (rallytime) Back-port #27344 to 2015.8

   * PR #27450: (ticosax) [dockerng] Fix typo in docstring

   * PR      #27430:     (jacksontj)     Fix     bug     introduced     in
     eee0291ff8b65ff1e22f4dc2447a74aa28a3ce7f

   * PR  #27418:  (terminalmage)  Don't  always  remove   dest   path   in
     salt.utils.files.rename()

   * PR  #27383:  (twangboy)  Uninstaller  only removes specific files and
     dirs

   * PR #27416: (rallytime) Back-port #27399 to 2015.8

   * PR #27394: (jacksontj) Remove streamed  response  for  fileclient  to
     avoid HTTP redirection problems

   * PR #27415: (ryan-lane) Backwards compat fixes for pecl module

   * PR #27407: (meggiebot) Adding stretch label definition

   * PR #27388: (basepi) [2015.8] Fix global provider overrides

   * PR  #27386:  (rallytime)  Document tty: True usage in salt-ssh roster
     file

   * PR #27380: (jtand) Skipping Async tests

   * PR #27382: (terminalmage) Revert "fixes
     `#27217`_
      clear_old_remotes clears wrong directory (gitfs)"

   * PR #27361: (cro) Correct some issues with proxy minions

   * PR #27364: (ruzarowski) SaltCloud[EC2]  Fix  missing  credentials  in
     modify_eni_properties api call

   * PR #27349: (jfindlay) add freebsd install docs to release notes

   * PR #27343: (cachedout) Close io loop before deleting attribute

   * PR #27337: (rallytime) [2015.8] Fixup salt-cloud logging

   * PR #27332: (terminalmage) Adjust dockerng/dockerio docstrings

   * PR #27353: (cachedout) Fix case where var not set in config

   * PR #27350: (rallytime) Allow IP-forwarding in GCE driver

   * PR  #27305:  (cachedout) Re-init logging system on Windows when using
     multiprocessing

   * PR #27331: (terminalmage) dockerng: Allow both cmd and command to  be
     used to specify command

   * PR #27327: (isbm) Fix a typo in the RPM output

   * PR #27312: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR   #27303:   (jacobhammons)   Updated   module   doc   index  using
     https://github.com/saltstack/salt/pull...

   * PR #27301: (twangboy) Pass ca_bundle for windows (fixes SSL Error)

   * PR #27300: (rallytime) Back-port #27287 to 2015.8

   * PR #27288: (rallytime) Filter  on  'name',  not  'id',  when  listing
     images

   * PR #27283: (jtand) __grains__['osrelease'] returns a string

   * PR #27276: (rallytime) Back-port #27218 to 2015.8

   * PR #27275: (rallytime) Back-port #27213 to 2015.8

   * PR #27274: (rallytime) Back-port #27272 to 2015.8

   * PR #27271: (isbm) Bugfix: crash on token authentication via API

   * PR  #27251:  (rallytime)  Add support for post_uri in SoftLayer cloud
     drivers

   * PR #27260: (bechtoldt) add missing module doc references

   * PR #27254: (jfindlay) 2015.2,2015.8,Beryllium -> 2015.8.0

   * PR #27245: (rallytime) If two ssh keynames are found in DigitalOcean,
     abort and warn the user.

   * PR #27241: (jfindlay) osrelease is only an integer for fedora

   * PR #27234: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27240: (isbm) Backport of the fix of 'pkg.info*' for Beryllium

   * PR  #27223:  (pprkut)  Support firewalld per interface zone config on
     rh7 systems

   * PR #27238: (bechtoldt)  salt.modules.disk.percent()  throws  KeyError
     when partition doesn't exist

   * PR #27232: (basepi) [2015.8] Add stub release notes for 2015.8.1

   * PR  #27199:  (rallytime)  Avoid RunTimeError (dictionary changed size
     during iteration) with keys()

   * PR #27206: (rallytime) Don't repeat GCE setup instructions, and  make
     the use of .json files clearer

   * PR #27210: (rallytime) Refactor some digital ocean functions

   * PR #27197: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #27195:  (jacobhammons)  Fixed  sphinx / latex build warnings and
     errors

   * PR #27182: (bernieke) fix restart_on_error

   * PR #27163: (terminalmage) Workaround upstream tornado  bug  affecting
     redirects

   * PR #27177: (rallytime) Remove note - incorrect info

   * PR  #27173:  (rallytime) Add the ability to specify multiple disks on
     the SoftLayer driver

   * PR  #27164:  (rallytime)   Make   sure   changes   from   #26824   to
     digital_ocean_v2.py driver make it to digital_ocean.py in 2015.8

   * PR #27143: (cachedout) Clean grains cache on grains sync

   * PR  #27150:  (cachedout)  Merge  config values from master.d/minion.d
     conf files

   * PR #27137: (jfindlay) revert serial grain regression

   * PR      #27144:      (rallytime)      Don't       stacktrace       on
     softlayer_hw.show_all_prices if a code isn't supplied

   * PR #27139: (jacobhammons) Updated key instruction on rhel7

   * PR #27134: (isbm) Backport to 2015.8: "pkg.info"

   * PR  #27119:  (l2ol33rt)  Boto dynamodb module should be using layer 2
     abstractions

   * PR #27092: (perfinion) salt/master: chdir to root not homedir

   * PR #27131: (jacobhammons) Install docs

   * PR #27124: (jfindlay) Backport #27123

   * PR #27111: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27122: (terminalmage) Fix broken link to git-config(1) docs

   * PR #27115: (jacobhammons) Release docs

   * PR #27110: (rallytime) Make  sure  -Q  output  is  consistent  across
     salt-cloud drivers

   * PR #27050: (twangboy) Turned multiprocessing on

   * PR #27086: (techhat) Document development of SPM loader modules

   * PR #26941: (msteed) Make elasticsearch work as master job cache

   * PR #27080: (bechtoldt) [Proposal] Add Github SPM label for issues

   * PR #27064: (twangboy) Fixed user docs

   * PR #27072: (rallytime) Back-port #26840 to 2015.8

   * PR  #27060:  (cro)  Fix  grains  breakage  when  hosts are not Linux,
     Windows, or SunOS

   * PR #27051: (rallytime) Back-port #26953 to 2015.8

   * PR #26864: (terminalmage) Only  do  git_pillar  preflight  checks  on
     new-style git_pillar configs

   * PR #26967: (TheBigBear) new URL for windows salt downloads

   * PR  #26921: (terminalmage) Get rid of error in legacy git pillar when
     using branch mapping notation

   * PR #26923: (rallytime) Code clean up of cloud drivers and files

   * PR #27010: (rallytime) Back-port #26988 to 2015.8

   * PR #26985: (rallytime) Fix versionadded tag

   Salt 2015.8.10 Release Notes
   Version 2015.8.10 is a bugfix release for 2015.8.0.

   Final Release of Debian 7 Packages

   Regular security support for Debian 7 ended on April 25th  2016.  As  a
   result, 2016.3.1 and 2015.8.10 will be the last Salt releases for which
   Debian 7 packages are created.

      Mint Linux: Important Post-Upgrade Instructions

             As a result of some upstream changes, the os  grain  on  Mint
             Linux  is  now being detected as LinuxMint (issue 33295). Run
             the following command after you upgrade to 2015.8.10 to reset
             the os grain to Mint and the os_family grain to Debian:

          salt -G 'os:LinuxMint' grains.setvals "{'os': 'Mint', 'os_family': 'Debian'}"

   Changes for v2015.8.9..v2015.8.10
   Salt  2015.8.10  includes  fixes  for  the  following  known  issues in
   2015.8.9:

   * issue 33376: pip state broken in 2015.8.9 with pip <6.0

   * PR 33386: Fix traceback in logging for config validation

   Since 2015.8.10 includes only two fixes, the 2015.8.9 changes  list  is
   included below for convenience:

   Changes for v2015.8.8..v2015.8.9
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-05-17T17:09:39Z

   Total Merges: 145

   Changes:

   * PR #33293: (twangboy) Fix minion start retry on Windows (2015.8)

   * 22c4331 linux_acl:  Allow  '-'  as  a  separation  character  in  ACL
     permissions. Fixes
     `#31270`_
      (#33172) (#33305)

   * 7a181f2 Handle more ipv6 error as an exception
     `#33299`_
      (#33300)

   * eb47a15 Ignore retcode when checking service's status (#33294)

   * PR #33274: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 4f3596a  Add  comment  for  test=true w/o changes ret and add changes
     dict example (#33254)

   * 2a30c48 Update Git Policy docs to match Contribution guide (#33252)

   * 056c273 Fix
     `#33238`_
      (#33239)

   * 1cd34ab Properly report on invalid gitfs/git_pillar/winrepo repos  (
     #33245)

   * PR #33253: (rallytime) Update the release process docs

   * 8c2c5b1 update 2015.8.9 release notes (#33251)

   * 8ee8ee3 Handle ipv6 error as an exception (#33246)

   * 855bed3 Check rendered YAML for invalid keys (#33213)

   * 6fb25a8  Make  note  of  files  that  begin  with  '_' in master.d or
     minion.d dirs (#33224)

   * a6dc0d2 Gate jnpr imports in salt.proxy.junos.py (#33150)

   * 64a89c4 Add docs for the http state (#33222)

   * 0a32163 Don't stacktrace when using  --out=highstate  at  CLI  during
     staterun. (#33215)

   * 04d714d propagate opts to salt.util.http call (#33219)

   * c8236c0 update 2015.8.9 release notes (#33237)

   * PR #33217: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 730bec1 [2015.8] Merge forward from 2015.5 to 2015.8 (#33207)

   * 379b151  Add a fetch when compiling git_pillar for masterless minions
     (#33204)

   * b3805d8 cloud.clouds.ec2: cache each named node (#33164)

   * 86db5df Properly handle failed git commands when redirect_stderr=True
     (#33203)

   * 8a0950d  Don't  force use of global ssh_config when git identity file
     is specified (#33152)

   * ce07133 update 2015.8.9 release notes (#33198)

   * PR #33188: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * e9108e0 add 2015.8.9 release notes (#33161)

   * 2d9919e [2015.8] Update to latest  bootstrap  script  v2016.05.10  (
     #33156)

   * 033bef2 Hash fileclients by opts (#33142)

   * f520fa3 Back-port #31769 to 2015.8 (#33139)

   * PR #33144: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #33140: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * ad607ef If cache_jobs: True is set, populate the local job cache when
     running salt-call (#33100)

   * 64689a6 Fix broken parsing of usermgmt.conf on OpenBSD (#33135)

   * 06a382e Add a check that the cmdline of the  found  proc  matches  (
     #33129)

   * 10018e9  salt.utils.gitfs:  fix  formatting  for  warning messages (
     #33064)

   * d45b599 Fix 33058 (#33099)

   * PR #33106: (abednarik) Moved _finger_fail method to parent class.

   * 20c7e10 clarify docs that map is designed to  be  run  once.  is  not
     stateful (#33102)

   * 558561d cloud.query needs to define mapper.opts (#33098)

   * PR #33096: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 22a327b salt-cloud: fix ipv6-only virtual machines (#32865)

   * e788f7e modules.npm: do not log npm --version at info level (#33084)

   * PR #33081: (jfindlay) ssh docs: install py-2.6 for RHEL 5

   * PR  #33088:  (isbm)  Bugfix:  Restore  boolean  values  from the repo
     configuration

   * 2c6326f fix tests for file.blockplace to remove newline (#33082)

   * PR #32892: (isbm) Resolve Zypper locks on asynchronous calls

   * 3e0bf23 Add fun_args to scheduled return data (part of
     `#24237`_
     ) (#33039)

   * 264c0d4 Don't  append  a  newline  when  creating  new  content  with
     blockreplace (#33049)

   * 54b783a  Pass  all  data to batch.run() call when using --failhard (
     #33048)

   * 2dbfa55 Display command  output  when  command  fails  with  batch  +
     failhard options (#33050)

   * add9199 Allow security_groups kwarg for boto_elb.present to be string
     or list (#33053)

   * 111701c [2015.8] Merge forward from 2015.5 to 2015.8 (#33054)

   * 1066063 File and User test fixes for 2015.8 on Fedora23  (#33056)

   * f97b5d5 Back-port #33030 to 2015.8 (#33040)

   * e90a501  Update  the  docs   for   saltutil.find_job   to   be   more
     clear/accurate (#33017)

   * d3d77ce Add saltenv to the cmd.script state function (#33031)

   * 3434f44 Fix syndic regression (#33021)

   * 4bb3ca5 Compare uid and gid instead of name and group (#32674)

   * 9ca5b02  Allow batch mode to use verbose option, as well as show_jid.
     (#32996)

   * 81c0fa4 Fixed glusterfs.peered output (#32955)

   * 8c70d7a Clarify some arg docs (#32994)

   * 00fbeab Fix boto_secgroup_test (#32986)

   * 3362367 fix user cron on solarish operating systems (#32970)

   * 07e38bc salt.log.setup: process user args before format (#32796)

   * b2d7c81 doc.ref.states.ordering: clarify requisite change (#32934)

   * df41d5d mode should default to 'text' (#32928)

   * f581a82 Remove FileClient class references from  docs  -  it  doesn't
     exist. (#32925)

   * 31b96de Update contents_grains option with relevant docs (#32922)

   * PR #32926: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 1cd6a45 specify volume tags in profile configuration (#32908)

   * 85ca86d  Update  docs  to warn users that -1 isn't valid for iptables
     insert state (#32906)

   * cb68706 Allow profile options to be specified in provider  file  when
     using maps (#32900)

   * 1a55fcb   Clarify   service  state  opening  docs  -  uses  'service'
     virtualname (#32880)

   * PR #32884: (terminalmage) Fix incorrect deprecation notice

   * PR #32878: (jacobhammons) added note  about  updating  the  bootstrap
     script in salt-cloud using th...

   * PR  #32869:  (rallytime)  Use  correct config setting in cloud syndic
     docs

   * PR #32844: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * eb8fb6b Back-port #31139 to 2015.8 (#32868)

   * 4bb5545 backport PR #32732 for issue
     `#23714`_
      (#32847)

   * 5ea003b Add pyvmomi version warning to Getting  Started  with  VMware
     docs (#32845)

   * 44f08d0 Pass None as memory limit. (#32841)

   * feebe69 Back-port #32813 to 2015.8 (#32839)

   * 3b81031 various improvements on cloud deploy script docs (#32659)

   * bf85987 update bootstrap to 2016.04.18 release (#32668)

   * 83dee63 Back-port #29322 to 2015.8 (#32785)

   * PR #32787: (rallytime) Back-port #32722 to 2015.8

   * PR #32786: (rallytime) Back-port #32703 to 2015.8

   * a6a42740 Merge branch 'pr-32775' into 2015.8

   * cda00f4 Improve documentation on pygit2 versions (#32779)

   * 1d6d234 Properly handle minion failback failure. (#32749)

   * 3751a27 Document pillar cache options (#32643)

   * 35c8af3 modules.win_dacl: consistent case of dacl constants (#32720)

   * 2cd0817 Update external auth documentation to list supported matcher.
     (#32733)

   * bba089d Check dependencies type  before  appling  str  operations  (
     #32693)

   * 3aa0605   Handle   when   beacon   not   configured  and  we  try  to
     enable/disable them (#32692)

   * PR #32718: (garethgreenaway) Fixes to schedule.list in 2015.8

   * PR #32684: (captaininspiration) Fix routes for redhat < 6

   * 7cdd512 Handle a couple of arguments better (Azure) (#32683)

   * aaa03bc Fix for issue 32523 (#32672)

   * 21081b1 Don't access deprecated Exception.message attribute. (#32556)

   * 5d1e9a4 Lower log level for pillar cache (#32655)

   * PR #32588: (anlutro) Fix salt-ssh module function call argument  type
     juggling by JSON encoding them

   * 5e7edfc  yumpkg:  Ignore  epoch  in  version  comparison for explicit
     versions without an epoch (#32563)

   * fea6056 Fixing critical bug to remove only the specified Host instead
     of the entire Host cluster (#32640)

   * 0477f66 align OS grains from older SLES with current one (#32649)

   * 8d46244  Prevent crash if pygit2 package is requesting re-compilation
     of the e (#32652)

   * PR #32614: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32616: (rallytime) Back-port #32547 to 2015.8

   * 3047471 Fix comments value in salt.states.pkgrepo example (#32604)

   * ab9da90 Revert PR #32480 and apply #32314 with fixes /  documentation
     (#32558)

   * c84c921  Better  log  message on minion restart if master couldn't be
     reached. (#32576)

   * 3c81798 Don't return None from eval_master (#32555)

   * PR #32536: (rallytime) Back-port #31898 to 2015.8

   * d12a1c2 Fix binary search and replace (#32542)

   * PR #32539: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR    #32531:     (ticosax)     [dockerng]     Fix     support     of
     dockerng.volume_present when no volume is on present.

   * 5d73d54  Enhance  dockerng.wait() to control success on exit_code and
     on already stopped containers (#32475)

   * 214f01e Bugfix: salt-key crashes if tries to  generate  keys  to  the
     directory w/o write access (#32436)

   * 288839f Turn on exc_info when logging failed minion startup (#32515)

   * 08a8020   Add  ignore_epoch  option  to  pkg.installed/removed/purged
     states (#32520)

   * 492ebfc Isbm zypper list products sles11 crash (#32505)

   * ae89882 Clear VCS fsbackend and git_pillar locks on master  start  (
     #32480)

   * a6482a3 Use win32api to get Total System Memory (#32491)

   * PR   #32487:   (terminalmage)   Add   explanation  of  nonzero  epoch
     requirement to pkg.installed state documentation

   * PR #32482: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * f5bd6bd Backport 31164 and 31364 (#32474)

   * PR #32450: (cachedout) Pass parser options into batch mode

   * b299835 Issue
     `#28706`_
     : Fix state user.present behavior. (#32448)

   * cef33d5 Argument name in docs should match actual arg name (#32445)

   * PR #32432: (ticosax) [dockerng] Fix Domainname introspection

   * PR #32427: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32423: (jtand) Update glusterfs_test to be inline with #32312

   * PR #32425: (cachedout) Fix salt-cloud parallel provisioning

   * 51fb2ac FreeBSD supports packages  in  format  java/openjdk7  so  the
     prior  commit broke that functionality. Check freebsd/pkg`#1409`_ for
     more info.

   * 709410a Improve git_pillar documentation/logging

   * c53efc3 Update master config docs

   * PR #32323: (mcalmer) fix sorting by latest version when  called  with
     an attribute

   * PR #32376: (amontalban) Fixes saltstack/salt`#28262`_

   * 0d9a06b Cleaner deprecation process with decorators

   * 6979fda Correcty index glusterfs bricks

   * PR  #32393:  (jfindlay) modules.win_timezone: don't list all zones in
     debug log

   * PR #32372: (rallytime) Back-port #32358 to 2015.8

   * PR #32392: (multani)  Fix  documentation  on  boto_asg  and  boto_elb
     modules and states

   * PR #32373: (cachedout) Resolve memory leak in authentication

   * PR  #32126:  (cro)  Add  a  couple  CLI  examples  for  the highstate
     outputter.

   * PR #32353: (mcalmer) Prevent metadata download when listing installed
     products

   * PR #32321: (abednarik) Better message when minion fail to start

   * PR #32345: (nmadhok) [2015.8] Check if profile key exists in
     vm_
      dict

   * PR #32343: (Ferbla) Fixed win_wua example documentation

   * PR   #32360:   (rallytime)   Make  sure  hash_type  is  lowercase  in
     master/minion config files

   * PR #32361: (cro) SDB is no longer experimental

   * PR #32336: (rallytime) Back-port #28639 to 2015.8

   * PR #32332: (rallytime) Don't unsubscribe from open events on the  CLI
     too early on long-running commands

   * PR #32333: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #32289:  (rallytime)  New salt-cloud instances should not use old
     hash_type default.

   * PR #32291: (twangboy) Fix bad output for chocolatey.version (fixes
     `#14277`_
     )

   * PR     #32295:     (rallytime)     Test     the      contents      of
     'deploy_scripts_search_path' in salt.config.cloud_config

   * PR #32315: (ahus1) fixing file.managed with requests lib

   * PR #32316: (vutny) Update Salt Bootstrap tutorial

   * PR #32325: (bdrung) Re-add shebang to ssh-id-wrapper shell script

   * PR #32326: (bdrung) Fix typos

   * PR #32300: (twangboy) Add documentation to disable winrepo/winrepo_ng

   * PR #32288: (terminalmage) use dictupdate.merge instead of dict.update
     to merge CLI pillar overrides

   * PR #32243: (isbm) Ensure latest pkg.info_installed ensure latest

   * PR #32268: (ticosax) [dockerng] Improve detection for older  versions
     of docker-py

   * PR   #32258:   (jacobhammons)   Replaces   incorrect   reference   to
     master_alive_check

   * PR   #32254:   (twangboy)   Fix   Display   Name   with   spaces   in
     win_servermanager

   * PR #32248: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #32230:  (terminalmage)  systemd.py: Support both update-rc.d and
     chkconfig as managers of sysv services

   * PR #32249: (jacobhammons) Fixes windows download paths to account for
     patch

   * PR  #32221:  (dmurphy18)  Fix version check, fix extracting Major and
     Minor versions from __ver...

   * PR #32227: (twangboy) Remove list2cmdline usage from win_service.py

   * PR #32239: (anlutro) Add state file name to warning log line

   * PR #32215: (DmitryKuzmenko) rhel oscodename

   * PR #32217: (jacobhammons) 2015.8.8.2 release notes

   * PR #32212: (rallytime) Back-port #32197 to 2015.8

   * PR #32211: (rallytime) Back-port #32210 to 2015.8

   * PR #32209: (rallytime) Back-port #32208 to 2015.8

   * PR #32204: (ticosax) [dockerng] Consider labels carried by the  image
     when comparing user defined labels.

   * PR  #32186: (rallytime) Add some "best practices" information to test
     documentation

   * PR #32176: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32163: (rallytime) Update  nacl.config  docs  to  use  key  value
     instead of 'None'

   * PR  #32166: (vutny) salt.states.file: correct examples with multiline
     YAML string

   * PR #32168: (rallytime) Lint 2015.8

   * PR #32165: (terminalmage)  Make  __virtual__  for  rhservice.py  more
     robust

   * PR #32160: (cachedout) Fix beacon tutorial docs

   * PR #32145: (paclat) fixes 29817

   * PR  #32133:  (basepi)  Pass  eauth  user/groups  through  salt-api to
     destination functions

   * PR #32127: (rallytime) Add runners to __salt__ docs

   * PR #32143: (DmitryKuzmenko) Set auth retry count to 0 if  multimaster
     mode is failover.

   * PR #32134: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32091: (clarkperkins) Fixed the regression in 410da78

   * PR  #32135:  (rallytime) [2015.8] Support multiple valid option types
     when performing type checks

   * PR #31760: (sakateka) SMinion need wait future from eval_master

   * PR #32106: (jfindlay) update suse master service patch

   * PR #32130: (jacobhammons) Added  known  issues  32004  and  32044  to
     2015.8.8 release notes

   * PR #32105: (clarkperkins) Fixed invalid deploy_scripts_search_path

   * PR #32117: (tomlaredo) Fixed validation type for file_ignore_glob

   * PR #32113: (sakateka) Fix log message for AsyncAuth initialization

   * PR  #32116:  (ticosax)  Obtain  default value of memory_swap from the
     container.

   * PR #32098: (rallytime) Back-port #32083 to 2015.8

   * PR #32099: (jacobhammons) 2015.8.8 release docs

   * PR #32088: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32074: (Xiami2012) Fix code for proto args in modules.iptables

   * PR #32053: (basepi) [2015.8] Fix rabbitmq_user.present tag handling

   * PR #32023: (sbreidba) Move constant declaration into member  variable
     to avoid issues when m...

   * PR  #32026:  (techhat)  Don't  require the decode_out file to already
     exist

   * PR #32019: (rallytime) Back-port #32012 to 2015.8

   * PR #32015: (ticosax) [dockerng] Fix ports exposition when protocol is
     passed.

   * PR  #31999:  (jacobhammons)  Fixes  a  doc  build exception caused by
     missing mocks for modules.win_dacl

   * PR #31992: (notpeter) salt-cloud: add D2 and G2 EC2 instance types

   * PR #31981: (lloydoliver) include rotational  disks  in  grains  under
     linux

   * PR #31970: (twangboy) Add apply_template_on_contents for windows

   * PR #31960: (aletourneau) fixed ec2 get_console_output

   * PR #31958: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 3934c66 Merge branch '2015.5' into '2015.8'

   * PR #31935: (twangboy) Back port nullsoft build script from 2015.8

   * PR #31912: (jfindlay) log.mixins: remove extermporaneous .record

   Salt 2015.8.11 Release Notes
   Version 2015.8.11 is a bugfix release for 2015.8.0.

   Returner Changes
   * Any returner which implements a save_load function is now required to
     accept a minions keyword argument. All returners which ship with Salt
     have been modified to do so.

   New Configuration Parameter: rotate_aes_key
   * Rotate_aes_key  causes  Salt  to  generate  a  new AES key whenever a
     minion key is deleted.  This eliminates the  chance  that  a  deleted
     minion  could continue to eavesdrop on communications with the master
     if it continues to run after its key is deleted.  See  the  entry  in
     the documentation for
     `rotate_aes_key`_
     .

   Ubuntu 16.04 Packages
   SaltStack  is  now  providing  official Salt 2015.8 packages for Ubuntu
   16.04.

   Changes for v2015.8.10..v2015.8.11
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-07-14T21:16:18Z

   Total Merges: 122

   Changes:

   * PR  #34676:  (cachedout)  Revert  "Modify  lodaer  global test to use
     populated dunders"

   * PR #34601: (lorengordon) Clarifies the proper way to reference states

   * bc63f25 Lint 34644 (#34651)

   * 5036026 Adjust the mine test a little bit to give it a better  chance
     of success (#34647)

   * PR  #34642: (jtand) Check that mysqladmin exists before running mysql
     integration tests

   * PR #34618: (jtand) Network state integration test test=True

   * PR #34617: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * b90ae40 Add support for edge case when Cmd and  Entrypoint  can't  be
     blanked (#34593)

   * 12b579c When sorting list actual_data, make it a list (#34590)

   * 7dd8035 Gate docker unit test to check for docker (#34591)

   * ae38c87  Add  a  bunch  of  documentation on getting files from other
     environments (#34560)

   * PR #34531: (terminalmage) Support ignore_epoch  argument  in  version
     comparisons

   * PR  #34545:  (terminalmage)  Handle  cases  where  Docker  Remote API
     returns an empty ExecutionDriver

   * PR   #34546:   (rallytime)   Rename   unit.states.boto_secgroup    to
     unit.states.boto_secgroup_test

   * PR     #34537:     (rallytime)     Rename     tests.unit.simple    to
     tests.unit.simple_test

   * fbab2f8 [2015.8] Update bootstrap script to latest stable (#34527)

   * 6b8c76a Prevent many errors in the test  suite  in  loader  tests  (
     #34521)

   * c2f296c Fix wrong order of retention_policy_exists (#34507)

   * PR #34518: (terminalmage) Fix pkg.latest integration test for non-LTS
     ubuntu

   * PR #34513: (cachedout) Lower the log level for modules  which  cannot
     be loaded to trace

   * PR  #34498:  (rallytime)  Use -O in the wget example in the bootstrap
     tutorial for the develop branch

   * 3ebba02 Rename some unit test files by adding _test (#34503)

   * 8722257 Improve top file merging documentation (#34505)

   * 6ce7cb9 Gracefully  handle  non-XML  output  in  GlusterFS  execution
     module. (#34492)

   * 7529945 Use skipTest for network state integration test (#34489)

   * 0f3f87f  Update  dnsmasq.get_config  docs  to use correct config_file
     param. (#34488)

   * PR #34462: (terminalmage) Use --always when available to git describe

   * PR #34467: (rallytime) Back-port #34457 to 2015.8

   * PR #34432: (twangboy) Fix file.append

   * PR #34429: (terminalmage) Skip version checking for targeted packages
     in pkg.latest state

   * 0a26459 Forgot reference to inotify (#34455)

   * PR #34451: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34401: (terminalmage) Use rpmdev-vercmp as a fallback for version
     comparison on RHEL5

   * PR #34366: (steverweber) Update service.py

   * PR #34426: (cro) Document that inotify is Linux only

   * PR #34392: (cro) Clarify that salt-cloud  doesn't  get  installed  by
     bootstrap

   * PR #34373: (jtand) Network state integration test

   * d6af1de  Optimize pkg integration tests and add a couple new tests (
     #34377)

   * PR #34368: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 94e0946 Back-port #34324 to 2015.8 (#34344)

   * 11dc020 Making salt-ssh pass proper return codes for jinja  rendering
     errors (#34342)

   * f6bd1ad Revert py3modernize lint changes (#34339)

   * PR  #34306:  (ghedo)  Fix iptables.flush state: Do not force 'filter'
     table when flushing

   * 0c60fea Doc clarifications to file modules, addition of  new  profile
     log level to docs, fixed example in dnsmasq (#34323)

   * b793426 Remove unnecessarily-disabled sanity check (#34325)

   * PR #34335: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * a6d3cc6 Typo in dockerio doc (#34319)

   * PR  #34312:  (rallytime)  [2015.8]  Update to latest bootstrap script
     v2016.06.27

   * PR #34307: (rallytime) Fix test example in integration testing docs

   * PR #34233: (thegoodduke) ipset: fix the comment containing blank

   * PR #34257: (rallytime) Use 'config_dir' setting instead of CONFIG_DIR
     in gpg renderer

   * PR #34274: (clinta) Don't escape source before calling managed

   * PR #34258: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34093: (terminalmage) Catch CommandExecutionError in pkg states

   * PR #34136: (meaksh) Fixed behavior for SUSE OS grains in 2015.8

   * 56c7267  fix regression from #33681 which causes pulling a list of s3
     objects via s3.query to fail (#34208)

   * 02eb331 Fix a pair of gitfs bugs (#34218)

   * PR #34182: (rallytime) Handle child PIDs differently depending on the
     availability of psutils

   * 5d3ec31  Clarify  pkg.list_repo_pkgs  docstring  for held packages (
     #34188)

   * 5bca5c4  Change  target  for  dockerng  assuming  default  status  to
     Nitrogen release (#34206)

   * PR #34184: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #34176: (rallytime) Back-port #34103 to 2015.8

   * PR  #34179:  (terminalmage)  Raise  the  correct exception when gitfs
     lockfile is empty

   * PR #34178: (terminalmage) Remove unnecesssary comment

   * 6387d16 fix salt --summary to count not responding minions  correctly
     (#34165)

   * e5949ea doc: add missing dot (#34175)

   * 47595d6 Typo fix (#34174)

   * PR #34077: (rallytime) Add some grains targeting tests

   * PR #34142: (isbm) Move log message from INFO to DEBUG.

   * 79a719b  Update  documentation on "refresh" behavior in pkg states (
     #34100)

   * 6d0d52f modules.pkg int tests: skip refresh_db upon error (#34072)

   * PR #34069: (rallytime) Add a test to check  for  disconnected  minion
     messaging

   * PR  #34048:  (terminalmage) RFC: proposed fix for multiple fileserver
     updates in masterless runs

   * PR #34011: (rallytime) Back-port #33948 and #34009 to 2015.8

   * bca4371 Fixed a bug in  the  consul.py  module  that  was  preventing
     services (#34051)

   * PR #34045: (jacobhammons) Updated latest release version

   * f9bfcde Always make changes to minion config if set (#34020)

   * e25dba4 More YAML indentation fixes in state module examples (#34030)

   * PR #34018: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 7d940ae states.file: fix indentation in YAML examples (#34003)

   * 4c7fac0 Remove loader test for pam module (#34002)

   * PR  #33990: (jacobhammons) Adds links to several current Salt-related
     projects

   * PR #33983: (twangboy) Clarify the account_exists parameter

   * PR #33951: (jfindlay) modules.gem int tests: more fixes

   * PR #33984: (jfindlay) Add docs and tests to disk state

   * PR #33985: (rallytime) Write some more simple batch command tests

   * 6080846 acl.ClientACL: add unit tests (#33684)

   * a74f1b8 ZD 762 (#33942)

   * PR #33946: (rallytime) Back-port #33698 to 2015.8

   * PR #33952: (rallytime) Add base argument to salt-ssh  grains  wrapper
     for filter_by func

   * 4a80649  Adds a "Generated on <timestamp>" line to the footer of each
     doc html page in the doc (#33962)

   * b3ec39d Correct issue with ping on rotate with minion cache (#33765)

   * PR #33888: (jfindlay) random.org checks

   * 2dc1914 Add connecting_settings to boto_elb state attributes list  (
     #33936)

   * 91a2184 Wait for up to a minute for sync_after_install (#33917)

   * PR #33877: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #33827: (cachedout) Fix broken locate.locate function

   * PR   #33839:   (cachedout)   Fix  another  unit  test  stacktrace  in
     pkg_resource

   * PR #33840: (cachedout) Remove matcher tests

   * PR #33836: (cachedout) Fixing more stupid unit tests

   * PR  #33805:  (jfindlay)  states.pkg  int  tests:  skip  if  pkg   mgr
     unavailable

   * PR   #33808:  (jfindlay)  fix  some  problems  with  the  gem  module
     integration tests

   * PR #33770: (jfindlay) service state integration tests

   * PR #33691: (jtand) Gem integration test

   * PR #33777: (sodium-chloride) Fix minor docstring issue of  arg  being
     missing

   * PR #33759: (cachedout) Catch no minions exception in batch mode

   * PR #33719: (cachedout) Catch oserror for race condition

   * PR  #33712:  (meaksh)  Fix  for groupadd execution module failures in
     SLES11 systems

   * PR #33718: (rallytime) Back-port #33700 to 2015.8

   * PR #33727: (terminalmage) Fix git_pillar edge case for  remote  repos
     without a master branch

   * PR  #33728:  (jfindlay)  Make configurable_test_state configurable in
     test mode

   * PR #33729: (twangboy) Add exclude option to win_servermanager

   * PR #33743: (vutny)  Debian  installation  docs:  drop  section  about
     community-maintained repo

   * 56c0a42 Create missing jid dir if it doesn't exist (#33653)

   * PR #33654: (twangboy) Fix win servermanager

   * PR  #33679: (terminalmage) Only compile the template contents if they
     evaluate to True

   * PR #33685: (jfindlay) modules.cp.get_url: add test for https://

   * PR #33581: (dincamihai) Call zypper refresh after adding/modifying  a
     repository

   * PR #33681: (rallytime) Back-port #33599 to 2015.8

   * PR #33396: (babilen) Issue 33393

   * PR #33652: (terminalmage) Lower the log level for failed auths

   * PR  #33615:  (danslimmon)  Fix  crash  on  unconnectable MySQL server
     (resolves
     `#33582`_
     )

   * PR #33558: (twangboy) Fix win servermanager

   * PR #33555: (cachedout) Fix crashing Maintenence process

   * PR   #33501:   (meaksh)   unit   tests   for    rpm.checksum()    and
     zypper.download()

   * PR #33513: (rallytime) Add a section to the jinja docs about escaping
     jinja

   * PR #33520: (jacobhammons) Updated version numbers in the docs for the
     2016.3.0 release

   * PR #33507: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR   #33503:  (rallytime)  Add  docs  about  minion  config  file  in
     standalone minion docs

   * PR #33474: (cachedout) Fix diskusage beacon

   * PR #33465: (meaksh) jobs.exit_success allow one to check if a job has
     executed and exit successfully

   * PR  #33487:  (jtand)  Add docstring examples to glance.py and nova.py
     [2015.8]

   * PR #33481: (rallytime) Fix docs about etcd  config  options  and  add
     pillar_opts doc

   * PR #33490: (rallytime) Document the postgres.psql_query function

   * PR #33480: (jfindlay) states.service: minor doc updates

   * 4f96cc1 Return full pending computer name (#33483)

   * a89be5e Use six.string_types in jobs runner (#33499)

   * PR   #33491:   (BlaineAtAffirm)   fix   jobs.list_jobs  failing  with
     search_target

   * PR #33478: (rallytime) Back-port #32484 to 2015.8

   * PR #33457: (rallytime) Make doc formatting consistent and use correct
     versionadded

   * 1dfa956 Don't allow a "repo" kwarg for pkgrepo.managed (#33477)

   * b4071b0  Allow for config entry to be a list in a dict for beacons (
     #33476)

   * PR #33469: (meaksh) check the RPM signature  of  zypper  pkg.download
     packages and report errors

   * 00f9090 Add docs about PyYAML's 1024 character limitations for simple
     keys (#33459)

   * 3b12f39 Prevent several minion processes on the same machine (#33464)

   * c8b4f33 Make  --gpg-auto-import-keys  a  global  param  when  calling
     zypper (#33432)

   * 0c4e38c Fix the saltutil.wheel function and add integration tests  (
     #33414)

   * e4f00f9 Make sure the path we're removing is present first - avoid an
     OSError (#33440)

   * 93fd00b Avoid a syntax error by using " instead of escaped ' (#33443)

   * ec60b9c Fix virtual function (#33436)

   * PR #33438: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * c9d0de4 Documentation update in file.serialize. (#33421)

   * f8a90eb  Fix  LVM  parameter  devices as a pure list. Comma separated
     lists are c (#33398)

   * 3989e5b Spelling correction. (#33406)

   * 9accb53 Update windows pkg.[install|remove] error logic (#33321)

   * 04ac89d Add note about reload_modules functionality for pkg.installed
     (#33374)

   * 637c2af Add note to absolute_imports practice about __future__ import
     (#33377)

   * d35b81d Document how to set the alias file location for  alias  state
     (#33380)

   * PR #33403: (jacobhammons) 2015.8.10 release notes

   * PR #33381: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 946d27e Fix traceback in logging for config validation (#33386)

   * 38fbcf8 Add note about name parameter in git_pillar docs (#33369)

   * 4925199  Add  win_pkg  to  list  of modules that support "version" in
     pkg.installed (#33362)

   * 7a400a9 Add note to docs about api settings for  Hipchat  API  v2  (
     #33365)

   * 37e1930  Add initscripts, SystemD service units and environment files
     for Debian (#32857)

   * PR #33370: (jacobhammons) Update docs version to 2015.8.9

   * PR #33366: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * f248003 Remove mentions of windows not supporting pkgs param (#33361)

   * 4fdb097 Update job_cache and keep_jobs docs to be  more  specific  to
     their behavior (#33328)

   * 2f06918 Properly detect newer Linux Mint distros (#33359)

   * d85096c Fix UnboundLocalError in git.latest (#33340)

   * e602446 Describes parameters in register_instances function (#33339)

   * 5c29c65 Fix some link errors in the test writing tutorial (#33347)

   * e532e58 Fix network.managed for windows (#33312)

   * 11a2525 Bp 28467 calm mine (#33327)

   * b897f2c import ps from psutil_compat in beacons (#33334)

   * 089c1a2  remove  redundant, incorrect sudo_runas config documentation
     (#33318)

   * 1f7fda2 Disambiguate non-exact matches when checking if sysv  service
     is enabled (#33324)

   * 8c1f19a Allow concurrency mode in state runs if using sudo (#33325)

   * ed14ef2  Fix  master hanging after a request from minion with removed
     key. (#33333)

   * daafa27 Cleanup comments in smbios.get output (fixes
     `#33266`_
     ) (#33306)

   * bfe12d9 Fix iptables --match-set (
     `#23643`_
     ) (#33314)

   * PR #33308: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   Salt 2015.8.12 Release Notes
   Version 2015.8.12 is a bugfix release for 2015.8.0.

   Changes for v2015.8.11..v2015.8.12
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-08-19T16:06:27Z

   Total Merges: 57

   Changes:

   * PR  #35611:  (rallytime*) Everything in the sample master config file
     should be commented out

   * PR #35569: (
     *
     rallytime) Write test for multiple  unless  commands  where  1st  cmd
     passes and 2nd fails

   * PR #35600: (
     *
     rallytime) Update release notes for 2015.8.12

   * PR #35599: (rallytime) Update release notes for 2015.8.12

   * PR  #35584:  (terminalmage)  Update linux_sysctl tests to reflect new
     context key

   * PR #35575: (terminalmage) Add warning  about  AWS  flagging  of  nmap
     usage

   * PR #35577: (terminalmage) Unit file changes for 2015.8.12, 2016.3.3

   * PR #35566: (rallytime) Back-port #35545 to 2015.8

   * PR #35545: (hu-dabao) fix-35384, fix cmd.run unless

   * PR #35492: (terminalmage) Clarify config.get docstring

   * PR #35483: (gtmanfred) use __utils__ in salt.cloud

   * PR #35546: (whiteinge) Salt api eauth fail gracefully

   * PR #35525: (UtahDave) add missing glob import

   * PR #35540: (rallytime) Whitespace fix for 2015.8

   * PR #35510: (terminalmage) Better systemd integration

   * PR  #35513:  (cachedout)  Might be a good idea to be able to download
     the software we make

   * PR #35302: (Ch3LL) Add job cache test

   * PR #35512: (cachedout) Fixup 35419

   * PR #35497: (deepakhj) Fixes spacing in requirements files

   * PR #35508: (terminalmage) Add Carbon to versionadded for git.diff

   * PR #35486: (rallytime)  Update  bootstrap  script  to  latest  stable
     (2016.08.16)

   * PR #35413: (cachedout) Resolve path issues with cp.push

   * PR  #35476:  (cachedout)  Fixup  SSH bug where sudo without sudo user
     would break

   * PR #35471: (terminalmage) win_pkg: Fix traceback when package is  not
     installed

   * PR #35448: (isbm) Add ignore_repo_failure option to suppress zypper's
     exit code 106 on ...

   * PR #35451: (isbm) Bugfix: zypper mod repo unchanged

   * PR #35453: (theothergraham) fixes #34279 - disk cache ttl expiry

   * PR #35459: (thatch45) Ensure that output for salt-ssh gets back

   * PR #35460: (rallytime) [2015.8] Update  bootstrap  script  to  latest
     stable (2016.08.15)

   * PR #35442: (cachedout) Fix cp.push_dir pushing empty dirs

   * PR #35436: (cachedout) Minor doc fixup

   * PR  #35132:  (sjorge)  fixes , causing lots of mayham (onchange) with
     2016.3.2 for me

   * PR #35394: (rallytime) Back-port #34573 to 2015.8

   * PR #34573: (cedwards) Update freebsd.rst

   * PR #35359: (terminalmage) Clean up open filehandles

   * PR #35339: (isbm) Bugfix: Prevent continuous restart, if a dependency
     wasn't installed

   * PR  #35357:  (twangboy) Fix file.recurse with clean: True  on Windows
     (2015.8)

   * PR #35323: (thatch45) Fix issue with bad error check in salt-vt

   * PR #35325: (kev009) Fix freebsd netstat route on fbsd 10+

   * PR #35301: (bobrik) Pass port to ssh.check_known_host, closes #35264

   * PR #35309: (terminalmage) file.recurse: Do  not  convert  octal  mode
     string to int

   * PR  #35290:  (terminalmage)  Resolve  a  couple bugs in orchestration
     output

   * PR #35211: (cachedout) Alternative sudo users for salt-ssh

   * PR #35271: (bobrik) Default state_output_profile to True  everywhere,
     closes #35166

   * PR  #35233:  (terminalmage) Do not attempt to get fqdn_ip{4,6} grains
     when ipv{4,6} grains are empty

   * PR #35202: (multani) doc: fix broken links in the test  documentation
     page

   * PR #35236: (rallytime) Back-port #35119 to 2015.8

   * PR  #35119:  (derekmaciel)  Assume  two EVRs are equal if E and V are
     equal but one R is missing.

   * PR #35240: (derekmaciel) Backport #35225 to 2015.8

   * PR #35225: (derekmaciel) Add missing documentation for pkg.installed

   * PR #35241: (terminalmage) Ensure max recursion in gitfs results in no
     blob object being returned.

   * PR #35245: (rallytime) Back-port #35039 to 2015.8

   * PR #35039: (whiteinge) Add saltenv support to module.run

   * PR #35249: (terminalmage) Fix regression in git.latest

   * PR #35174: (rallytime) Back-port #35146 to 2015.8

   * PR  #35146:  (cachedout)  Don't  discard  running beacons config when
     listing becaons

   * PR #34827: (thatch45) fix beacon list to include  all  beacons  being
     processed

   * PR #35173: (rallytime) Back-port #35135 to 2015.8

   * PR  #35135:  (rallytime)  Add  missing CLI Examples to aws_sqs module
     funcs

   * PR #35145: (jacobhammons) doc version update to 2015.8.11, updates to
     release notes

   * PR   #35114:  (terminalmage)  Add  clarification  docs  on  a  common
     git_pillar misconfiguration

   * PR #34768: (hrumph) Fixes #34767

   * PR #35043: (rallytime) Start release notes file for 2015.8.12

   * PR   #35050:   (terminalmage)   [orchestration]    Properly    handle
     runner/wheel funcs which accept a 'saltdev' argument

   * PR  #35066:  (jfindlay) returners.postgres_local_cache: do not log in
     __virtual__

   * PR #35024: (bobrik) Cache systemd unit update check per unit,  closes
     #34927

   * PR  #35026:  (cachedout)  Expressly  deny a minion if a key cannot be
     found

   * PR #35000: (rallytime) Back-port #33875 and #34999 to 2015.8

   * PR #33875: (jmesquita) Fix naive fileserver map diff algorithm

   * PR #34994: (rallytime) Back-port #34835 to 2015.8

   * PR #34835: (thatch45) Make the mine and publish  combine  minion  and
     master opts in salt-ssh

   * PR #34991: (cachedout) SSH timeout

   * PR #34976: (cachedout) Refine errors in client

   * PR  #34831:  (thatch45)  If  the  thin does not match, then redeploy,
     don't error

   * PR #34916: (cachedout) Master performance improvement

   * PR #34911: (cachedout) Backport #34906

   * PR #34906: (cachedout) Set timeout for run_salt in test suite

   * PR  #34898:  (hrumph)  Stop  multiple  refreshes   during   call   to
     pkg.list_upgrades

   * PR #34606: (isbm) Bugfix: Exit on configuration read (backport)

   * PR #34862: (thatch45) Fix salt-ssh cacheing issue

   * PR  #34869:  (terminalmage)  Fail  git.latest states with uncommitted
     changes when force_reset=False

   * PR #34859: (cachedout) Fix wheel test

   * PR #34822: (thatch45) Fix salt-ssh state.high and state.low

   * PR #34847: (cachedout) Add an option  to  skip  the  verification  of
     client_acl users

   * PR  #34827:  (thatch45)  fix beacon list to include all beacons being
     processed

   * PR #34833: (rallytime) Back-port #28521 to 2015.8

   * PR #28521: (gongled) SPM:  packaging  doesn't  work  in  Python  2.6.
     Fixed.

   * PR #34823: (rallytime) Back-port #25276 to 2015.8

   * PR #25276: (jacobhammons) copy spm.1 man page during setup

   * PR #34828: (thatch45) Fix #34648

   * PR  #34818:  (jtand)  Skip  mysql  state  test  if  mysqladmin is not
     available

   * PR #34642: (jtand) Check that mysqladmin exists before running  mysql
     integration tests

   * PR #34803: (junovitch) salt/state.py: set
     `chunk['order'] = 0' with `order: first'; fixes `#24744`_

   * PR #34773: (randomed) Bugfix: Startup states on minions are not being
     written to mysql returner

   * PR #34751: (cachedout) Remove unnedeed config test

   * PR #34606: (isbm) Bugfix: Exit on configuration read (backport)

   * PR #34754: (cachedout) Disable test

   * PR #34741: (rallytime) Back-port #34726 to 2015.8

   * PR #34726: (martinhoefling) Always loop  over  updated  keys  in  non
     recursive update

   * PR #34721: (rallytime) Add output_file option to master config docs

   * PR  #34689:  (Azidburn)  fix  second  run problems with pkg.installed
     using sources

   * PR #34695: (isbm) Bugfix: Zypper pkg.list_products returns  False  on
     some empty values (2015.8)

   Salt 2015.8.2 Release Notes
   NOTE:
      A  significant  orchestrate  issue  #29110 was discovered during the
      release process of 2015.8.2, so it has not been officially released.
      Please use 2015.8.3 instead.

   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-11-13T17:24:04Z

   Total Merges: 378

   Changes:

   * PR #28730: (garethgreenaway)  Fixes to how return_job is  handled  in
     the scheduler for the salt master.

   * PR #28848: (cro) Lint

   * PR #28842: (cachedout) Add transport setting to shell test

   * PR #28837: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28827: (jacksontj) Cleanup virtual_timer in loader

   * PR #28836: (cachedout) Cast to dict to fix wheel tests in tcp

   * PR #28834: (cachedout) Fix breakage in tcp server

   * PR #28804: (cachedout) TCP test fixes

   * PR #28826: (basepi) [2015.8] Add new tornado deps to salt-ssh thin

   * PR #28759: (jfindlay) simplify stdin use of stdin in at.present state

   * PR #28824: (rallytime) Back-port #28778 and #28820 to 2015.8

   * PR #28803: (jfindlay) decode strings to utf-8

   * PR #28782: (rallytime) Fixes to rabbitmq user state

   * PR  #28789: (nmadhok) Provide ability to enable/disable customization
     for newly create VMs using VMware salt-cloud driver

   * PR #28768: (mrosedale) 2015.8

   * PR #28772: (rallytime) rabbitmq.list_user_permissions returns a dict,
     not a list. Don't expect a list.

   * PR #28774: (rallytime) Back-port #28725 to 2015.8

   * PR #28775: (rallytime) Back-port #28740 to 2015.8

   * PR  #28755:  (rallytime)  Move most vmware driver list_* functions to
     use salt.utils.vmware functions

   * PR #28744: (jfindlay) import gate elementtree

   * PR #28758: (jfindlay) remove redundant  logic  in  useradd  execution
     module

   * PR #28757: (mbarrien) Bug fix: pip command to not quote spaces in cmd
     line args

   * PR #28764: (multani) Various documentation fixes

   * PR #28752: (aboe76) Update openSUSE grain for tumbleweed

   * PR #28713: (hexedpackets) Rename consul.list to consul.list_keys.

   * PR #28719: (jacobhammons) removed dependencies info from docs

   * PR #28709: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28710: (rallytime)  Pass  kwargs  correctly  to  _get_group  from
     get_group_id

   * PR #28698: (rallytime) Back-port #28530 to 2015.8

   * PR #28700: (rallytime) Back-port #28679 to 2015.8

   * PR  #28695:  (s0undt3ch)  [2015.8]  Update to latest bootstrap script
     v2015.11.09

   * PR #28656: (clarkperkins)
     `#28526`_
      fixed yumpkg module issue with pkg.installed

   * PR #28672: (jfindlay) add OS grain support for SuSE Leap

   * PR #28673: (jfindlay) add hidden_opts to mount.mounted

   * PR #28667: (cro) saltutil.sync_all should sync proxymodules  as  well
     as the rest.

   * PR #28665: (jfindlay) fixes to windows execution and state modules

   * PR #28660: (techhat) Don't sign empty regions

   * PR    #28632:    (terminalmage)    Fixes/improvements   to   pkgbuild
     state/modules

   * PR #28658: (techhat) Remove _pkgdb_fun() references

   * PR   #28653:   (rallytime)   Provide    possible    parameters    for
     boto_rds.present engine values

   * PR #28649: (bdrung) Fix OS related grains on Debian

   * PR #28646: (rallytime) Back-port #28614 to 2015.8

   * PR #28647: (rallytime) Back-port #28624 to 2015.8

   * PR #28648: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR  #28638:  (anlutro)  Salt-SSH:  Return more concise error when SSH
     command fails

   * PR #28644: (pass-by-value) Make sure versionchanged is correct

   * PR #28615: (The-Loeki) Fixes to FreeBSD pkg

   * PR #28613: (cachedout) Add facility  to  deepcopy  bound  methods  in
     Py2.6 and apply to grains

   * PR  #28612:  (rallytime) Remove unsupported storage_type argument for
     parity with boto_rds module

   * PR #28611: (rallytime) [2015.8] Be explicit  about  salt.utils.vmware
     function calls

   * PR #28610: (pass-by-value) Lxc config additions

   * PR  #28602:  (nasenbaer13)  Allow setting of custom dimensions in asg
     alarm specification

   * PR #28596: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR  #28593:  (blueyed)   doc:   fix   typo   with   salt.states.file:
     s/preseve/preserve/

   * PR #28578: (twangboy) Fixed the script... something got broke...

   * PR #28579: (jfindlay) fix __virtual__ returns: tls,uptime mods

   * PR  #28584:  (rallytime)  If AssociatePublicIpAddress is set to True,
     don't auto-assign eip.

   * PR #28576: (jacksontj) Only encode the zmq message once

   * PR #28587: (cachedout) Reset yaml rendering hooks to avoid leaks

   * PR #28581: (basepi) Revert b4875e585a165482c4c1ddc8987d76b0a71ef1b0

   * PR #28573: (jacksontj) Add body to salt.utils.http.query returns

   * PR #28564: (s0undt3ch) [2015.8] Update  to  latest  bootstrap  script
     v2015.11.04

   * PR #28561: (Oro) Issue
     `#28527`_
      boto_rds.create does not work

   * PR #28560: (bdrung) Fix various typos

   * PR  #28550:  (jfindlay)  check timedatectl errno and return stdout on
     failure

   * PR #28545:  (jfindlay)  pass  on  concurrent  create  of  jid_dir  in
     local_cache

   * PR  #28544:  (rallytime)  Start  moving some vmware.py cloud funcs to
     utils/vmware.py

   * PR  #28543:  (gtmanfred)  clean  up  changes  for  pkg.uptodate   and
     supervisord.dead

   * PR #28538: (jfindlay) decode path and url to utf-8 in url.create

   * PR #28533: (jfindlay) decode highstate error messages to utf-8

   * PR #28547: (nmadhok) [Backport] [2015.8] Tasks can be in queued state
     instead of running

   * PR #28535: (techhat) Fail gracefully if 169.254* isn't available

   * PR #28536: (cro) Default configuration file for proxy minions.

   * PR #28534: (rallytime) Add versionadded directive for vpc_name arg in
     boto_secgroup.present

   * PR #28516: (rallytime) Back-port #28489 to 2015.8

   * PR  #28506:  (basepi)  [2015.8]  Log  minion list for all rosters, at
     debug level

   * PR #28514: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28502: (cachedout) Lint #28427

   * PR #28464: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28486: (rallytime) Back-port #26945 to 2015.8

   * PR #28472: (gtmanfred) overwrite more than one value with names

   * PR #28493: (rallytime) Back-port #28492 to 2015.8

   * PR #28494: (whiteinge) Fix filter_by passing incorrect parameters  to
     match functions

   * PR #28491: (rallytime) Back-port #28388 to 2015.8

   * PR #28465: (twangboy) Fix
     `#12363`_
     : Password Expiration in Windows

   * PR #28485: (nasenbaer13) Fix invalid usage of _get_conn causing
     `#28484`_

   * PR  #28454:  (sdm24) Fixed nodegroup doc formatting to correctly link
     to pillar_opts in the master config

   * PR #28487: (cachedout) Lint 28456

   * PR  #28457:  (sdm24)  Clarified  comments  for   grains/core.py   for
     ip_interfaces, ip4_interfac...

   * PR #28473: (anlutro) Show check_cmd output on failure

   * PR #28460: (jtand) Skipped wipefs test if wipefs does not exist on OS

   * PR   #28426:  (terminalmage)  pkgbuild.built:  make  template  engine
     optional

   * PR #28422: (cachedout) Handle windows logging on thread_multi [WIP]

   * PR #28425: (twangboy) Fix
     `#13513`_
      - Reflection

   * PR #28417: (rallytime) Add note about azure sdk  version  to  getting
     started docs

   * PR      #28410:      (jacksontj)      Add      retries     to     the
     zeromq.AsyncReqMessageClient

   * PR #28404: (rallytime) Back-port #28395 to 2015.8

   * PR #28405: (opdude) Detect legacy versions of chocolatey correctly

   * PR #28187: (sjansen) fix at.present

   * PR #28375: (merll) Merge pillar includes correctly

   * PR  #28376:  (ryan-lane)  Support  update  of  route53  records  with
     multiple values

   * PR  #28377:  (terminalmage) Deprecate 'always' in favor of 'force' in
     pkgbuild.built

   * PR #28380: (cro) Add missing call for service provider

   * PR #28348: (jfindlay) salt.utils.alias informs user they are using  a
     renamed function

   * PR #28364: (jtand) In CentOS 5 the .split() causes a stacktrace.

   * PR #28361: (rallytime) Back-port #28087 to 2015.8

   * PR #28360: (multani) Various documentation fixes

   * PR #28370: (rallytime) Back-port #28276 to 2015.8

   * PR #28353: (merll) Consider each pillar match only once.

   * PR #28334: (anlutro) iptables needs -m comment for --comment to work

   * PR #28340: (jfindlay) sdecode file and dir lists in fileclient

   * PR #28344: (ryan-lane) Fix iptables state for non-filter tables

   * PR #28343: (rallytime) Back-port #28342 to 2015.8

   * PR #28330: (rallytime) Back-port #28305 to 2015.8

   * PR  #28270:  (rallytime)  Refactor RabbitMQ Plugin State to correctly
     use test=true and format errors

   * PR #28269: (rallytime) Refactor rabbitmq_user state to use  test=True
     correctly

   * PR  #28299:  (rallytime)  Add  test  for  availability_zone  check to
     boto_vpc_tests

   * PR #28306: (sdm24) Updated the  Nodegroup  docs  to  include  how  to
     target nodegroups in SLS Jinja

   * PR   #28308:   (rallytime)   Firewalld   state  services  should  use
     --add-service, not --new-service

   * PR #28302: (DmitryKuzmenko) Always close socket even if there  is  no
     stream.

   * PR #28282: (keesbos) Fix for __env__ in legacy git_pillar

   * PR #28258: (pass-by-value) Add service module for ssh proxy example

   * PR #28294: (bechtoldt) correct a bad default value in http utility

   * PR  #28185:  (jtand)  Added single package return for latest_version,
     fixed other bug.

   * PR #28297: (cachedout) Lint fix proxy junos

   * PR #28210: (terminalmage) Fix for ext_pillar being compiled twice  in
     legacy git_pillar code

   * PR #28265: (jfindlay) fix blockdev execution and state modules

   * PR #28266: (rallytime) Back-port #28260 to 2015.8

   * PR #28253: (rallytime) Back-port #28063 to 2015.8

   * PR  #28231:  (rallytime)  Make  sure  we're  compairing  strings when
     getting images in the DO driver

   * PR #28224: (techhat) Optimize create_repo for large packages

   * PR #28214: (rallytime) Don't stacktrace if  invalid  credentials  are
     passed to boto_route53 state

   * PR #28228: (rallytime) Back-port #27562 to 2015.8

   * PR  #28232: (rallytime) Add documentation to supply the ssh_username:
     freebsd config to DO docs

   * PR #28198: (jacobhammons) Added note regarding  missing  spm  exe  on
     Debian/Ubuntu

   * PR #28182: (erchn) Some fixes for nova driver for Rackspace

   * PR #28181: (rallytime) Revamp firewalld state to be more stateful.

   * PR #28176: (cro) Add ping function

   * PR #28167: (The-Loeki) file.serialize needs to add a final newline to
     serialized files

   * PR #28168: (rallytime) Make sure availability  zone  gets  passed  in
     boto_vpc module when creating subnet

   * PR #28148: (basepi) [2015.8] Only expand nodegroups to lists if there
     is a nested nodegroup

   * PR #28155: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28149: (pass-by-value) Add clarification  to  cloud  profile  doc
     about host

   * PR #28146: (cachedout) Lint dracr.py

   * PR #28141: (rallytime) Don't use RAM for root disk size in linode.py

   * PR #28143: (jtand) Removed blank line at end of chassis.py

   * PR #28021: (blueyed) Handle includes in include_config recursively

   * PR #28095: (rallytime) Back-port #28001 to 2015.8

   * PR #28096: (rallytime) Back-port #28061 to 2015.8

   * PR #28139: (rallytime) Back-port #28103 to 2015.8

   * PR  #28098:  (jacksontj)  For  all  multi-part  messages,  check  the
     headers. If the header is not ...

   * PR #28134: (bernieke) fix unicode pillar values
     `#3436`_

   * PR #28076: (redmcg) Replace option 'i' with an explicit queryformat

   * PR #28119: (jacksontj) Check if the remote exists before casting to a
     string.

   * PR #28105: (jfindlay) add reason for not loading localemod

   * PR #28108: (cachedout) Set logfile permsissions correctly

   * PR #27922: (cro) WIP States/Modules for managing Dell FX2 chassis via
     salt-proxy

   * PR #28104: (pass-by-value) Add documentation for proxy minion ssh

   * PR #28020: (DmitryKuzmenko) LazyLoader deepcopy fix.

   * PR #27933: (eliasp) Provide all git pillar dirs in opts[pillar_roots]

   * PR #28013: (rallytime) Back-port #27891 to 2015.8

   * PR #28018: (rallytime) Add example to Writing Grains  of  how  grains
     can be loaded twice

   * PR #28084: (cachedout) #28069 with lint

   * PR  #28079:  (The-Loeki)  Fix  for  trace dump on failing imports for
     win32com & pythoncom 4 win_task

   * PR #28081: (The-Loeki) fix for glance state  trace  error  on  import
     failure

   * PR  #28066:  (jacksontj) Use the generic text attribute, not .body of
     the handler

   * PR #28019: (rallytime) Clean up version added and deprecated msgs  to
     be accurate

   * PR #28058: (rallytime) Back-port #28041 to 2015.8

   * PR #28055: (rallytime) Back-port #28043 to 2015.8

   * PR #28046: (pass-by-value) Add pkg install and remove functions

   * PR  #28050:  (ryan-lane)  Use  a  better method for checking dynamodb
     table existence

   * PR  #28042:  (jfindlay)  fix  repo  path   in   ubuntu   installation
     documentation

   * PR #28033: (twangboy) Fixed win_useradd.py

   * PR #28027: (cro) Make ssh conn persistent.

   * PR  #28029:  (jacobhammons) Updated release notes with additional CVE
     information

   * PR #28022: (jacobhammons) Updated Debian and Ubuntu repo  paths  with
     new structure for 2015.8.1

   * PR  #27983:  (rallytime)  Pip  state  run result should be False, not
     None, if installation error occurs.

   * PR #27991: (twangboy) Fix for
     `#20678`_

   * PR #27997: (rallytime) Remove note about pip bug with pip v1  vs  pip
     v2 return codes

   * PR #27994: (jtand) Fix schedule_test failure

   * PR #27992: (cachedout) Make load beacon config into list

   * PR #28003: (twangboy) Fix
     `#26336`_

   * PR #27984: (rallytime) Versionadded for clean_file option for pkgrepo

   * PR  #27989:  (ryan-lane)  Do  not  try to remove the main route table
     association

   * PR #27982: (pass-by-value) Add example for salt-proxy over SSH

   * PR #27985: (jacobhammons) Changed current release to  8.1  and  added
     CVEs to release notes

   * PR #27979: (cachedout) Fix regression with key whitespace

   * PR #27977: (cachedout) Decode unicode names in fileclient/server

   * PR #27981: (jtand) Fixed trailing whitespace lint

   * PR #27969: (jeffreyctang) fix parse of { on next line

   * PR #27978: (terminalmage) Add note about dockerng.inspect_image usage

   * PR #27955: (pass-by-value) Bp 27868

   * PR #27953: (The-Loeki) Fix CloudStack cloud for new 'driver' syntax

   * PR #27965: (ryan-lane) Fail in boto_asg.present if alarms fail

   * PR #27958: (twangboy) Added new functionality to win_task.py

   * PR #27959: (techhat) Change __opts__ to self.opts

   * PR #27943: (rallytime) Back-port #27910 to 2015.8

   * PR #27944: (rallytime) Back-port #27909 to 2015.8

   * PR #27946: (jtand) Changed grain to look at osmajorrelease instead of
     osrelease

   * PR #27914: (rallytime) Use eipalloc instead of eni in  EC2  interface
     properties example

   * PR #27926: (rallytime) Back-port #27905 to 2015.8

   * PR  #27927:  (ryan-lane) Do not manage ingress or egress rules if set
     to None

   * PR #27928: (rallytime) Back-port #27908 to 2015.8

   * PR #27676: (ticosax) [dockerng] WIP No more runtime  args  passed  to
     docker.start()

   * PR #27885: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27882: (twangboy) Created win_task.py module

   * PR #27802: (terminalmage) Correct warning logging when update lock is
     present for git_pillar/winrepo,  add  runner  function  for  clearing
     git_pillar/winrepo locks

   * PR  #27886: (rallytime) Handle group lists as well as comma-separated
     group strings.

   * PR #27746: (anlutro) timezone module: handle timedatectl errors

   * PR  #27816:  (anlutro)  Make  system.reboot  use  shutdown  -r   when
     available

   * PR #27874: (rallytime) Add mention of Periodic Table naming scheme to
     deprecation docs

   * PR #27883: (terminalmage) Work around --is-ancestor not being present
     in git-merge-base before git 1.8.0

   * PR #27877: (rallytime) Back-port #27774 to 2015.8

   * PR #27878: (rallytime) Use apache2ctl binary on SUSE in apache module

   * PR #27879: (cro) Add docs for 2015.8.2+ changes to proxies

   * PR #27731: (cro) Add __proxy__ to replace opts['proxymodule']

   * PR #27745: (anlutro) Add pip_upgrade arg to virtualenv.managed state

   * PR #27809: (ticosax) [dockerng] Remove dockerng.ps caching

   * PR #27859: (ticosax) [dockerng] Clarify doc port bindings

   * PR #27748: (multani) Fix
     `#8646`_

   * PR #27850: (rallytime) Back-port #27722 to 2015.8

   * PR #27851: (rallytime) Back-port #27771 to 2015.8

   * PR #27833: (jfindlay) decode path before string ops in fileclient

   * PR #27837: (jfindlay) reverse truth in python_shell documentation

   * PR  #27860: (flavio) Fix OS related grains on openSUSE and SUSE Linux
     Enterprise

   * PR #27768: (rallytime) Clean up bootstrap  function  to  be  slightly
     cleaner

   * PR #27797: (isbm) Zypper module clusterfix

   * PR  #27849:  (rallytime)  Don't  require a size parameter for proxmox
     profiles

   * PR #27827: (techhat) Add additional error checking to SPM

   * PR #27826: (martinhoefling) Fixes
     `#27825`_

   * PR #27824: (techhat) Update Azure errors

   * PR #27795: (eguven) better change reporting for postgres_user groups

   * PR #27799: (terminalmage) Fix usage of identity file in git.latest

   * PR #27717: (pass-by-value) Proxy beacon example

   * PR #27793: (anlutro) update code that changes log level  of  salt-ssh
     shim command

   * PR  #27761:  (terminalmage)  Merge  git  pillar data instead of using
     dict.update()

   * PR #27741: (ticosax) [dockerng] pass filters argument to dockerng.ps

   * PR #27760: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27757: (jfindlay) fix virtual fcn return doc indentation

   * PR #27754: (rallytime) Change test.nop version directive to 2015.8.1

   * PR #27734: (jacobhammons) Updated saltstack2 theme to add  SaltConf16
     banner

   * PR #27727: (rallytime) Merge #27719 w/pylint fix

   * PR #27724: (jfindlay) update __virtual__ return documentation

   * PR #27725: (basepi) Fix global injection for state cross calls

   * PR  #27628:  (ticosax) [dockerng] Add support of labels parameter for
     dockerng

   * PR #27704: (jacobhammons) Update compound matcher docs to clarify the
     usage of alternate delimi...

   * PR #27705: (rallytime) Merge #27602 with final pylint fix

   * PR  #27691:  (notpeter)  Faster  timeout  (3s  vs  2min) for instance
     metadata lookups.
     `#13850`_
     .

   * PR #27696: (blueyed) loader.proxy: call _modules_dirs only once

   * PR #27630: (ticosax) Expose container_id in mine.get_docker

   * PR #27600: (blueyed) dockerng: use docker.version=auto by default

   * PR #27689: (rallytime) Merge #27448 with test fixes

   * PR #27693: (jacobhammons) initial engines topic, updates  to  windows
     repo docs

   * PR #27601: (blueyed) dockerng: handle None in container.Names

   * PR #27596: (blueyed) gitfs: fix UnboundLocalError for 'msg'

   * PR  #27651:  (eliasp) Check for existence of 'subnetId' key in subnet
     dict

   * PR #27639: (rallytime) Docement version  added  for  new  artifactory
     options

   * PR #27677: (rallytime) Back-port #27675 to 2015.8

   * PR #27637: (rallytime) Back-port #27604 to 2015.8

   * PR #27657: (garethgreenaway) Fix to pkg state module

   * PR #27632: (rallytime) Back-port #27539 to 2015.8

   * PR #27633: (rallytime) Back-port #27559 to 2015.8

   * PR   #27579:   (rallytime)  Change  boto_route53  region  default  to
     'universal' to avoid problems with boto library

   * PR  #27581:  (tkwilliams)  Add  support   for   'vpc_name'   tag   in
     boto_secgroup module and state

   * PR  #27624: (nasenbaer13) Wait for sync is not passed to boto_route53
     state

   * PR #27614: (blueyed) doc: minor fixes to doc and comments

   * PR #27627: (eyj) Fix crash in boto_asg.get_instances if the requested
     attribute is None

   * PR #27616: (jacobhammons) Updated windows software repository docs

   * PR  #27569:  (lomeroe)  boto_vpc.get_subnet_association now returns a
     dict w/key of vpc_id, a...

   * PR #27567: (whiteinge) Use getattr to fetch psutil.version_info

   * PR #27583: (tkwilliams) Fixup zypper module

   * PR    #27597:    (blueyed)    gitfs:    remove    unused     variable
     "bad_per_remote_conf"

   * PR #27585: (ryan-lane) Fix undefined variable in cron state module

   Salt 2015.8.3 Release Notes
   Security Fix
   CVE-2015-8034:  Saving  state.sls  cache  data  to  disk  with insecure
   permissions

   This affects users of the state.sls function. The state  run  cache  on
   the  minion  was  being  created  with incorrect permissions. This file
   could potentially contain sensitive data that was  inserted  via  jinja
   into  the  state SLS files. The permissions for this file are now being
   set correctly. Thanks to  @zmalone  for  bringing  this  issue  to  our
   attention.

   Changes
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-11-25T00:03:40Z

   Merges: 452

   Changes:

   * PR #29172: (basepi) [2015.8] Backport new philips_hue proxy  features
     from develop

   * PR #29167: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #29141:  (optix2000)  Add  test  case  for require: sls with only
     import statements

   * PR #29072: (terminalmage) Several gitfs/git_pillar fixes

   * PR #29118: (ticosax) [dockerng] Add networking capabilities

   * PR #29145: (anlutro) Remove duplicate import of salt.utils.s3

   * PR   #29148:   (lomeroe)   correcting   parameter   calls   to   boto
     get_zone/create_zone functions in ...

   * PR #29108: (lorengordon) Enforce length as an int, fixes
     `#29107`_

   * PR #29125: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29126: (fcrozat) Fix deployment when umask is non-standard

   * PR #29124: (rallytime) Back-port #28130 to 2015.8

   * PR  #29076: (RealKelsar) We can't query installed use flags for a non
     installed pkg

   * PR #29097: (rallytime) Back-port #29070 to 2015.8

   * PR #29090: (gtmanfred) clean up novaclient module

   * PR #29095: (terminalmage) Add warning about pygit2 API instability

   * PR #28919: (cro) Update Philips Hue proxy minion to support __proxy__
     instead of proxymodule stored in __opts__

   * PR  #29065:  (cachedout) Handle failures inside python's inspect if a
     module is reloaded

   * PR #29057: (paulnivin) Add local file support for file.managed source
     list

   * PR #29017: (jfindlay) pagerduty runner: add missing salt.utils import

   * PR   #29039:   (anlutro)  Allow  passing  list  of  pip  packages  to
     virtualenv.managed

   * PR  #29047:  (schwing)  Fix  salt.modules.gpg.import_key   exception:
     'GPG_1_3_1 referenced before assignment'

   * PR  #29050:  (terminalmage) Make git_pillar global config option docs
     more prominent

   * PR #29048: (nmadhok) Fix incorrect debug log statement

   * PR #29024: (jfindlay) cache runner test: add new unit tests

   * PR #28967: (cro) Fix some issues with password changes

   * PR #29020: (basepi) [2015.8] Add special list-only nodegroup  support
     to salt-ssh

   * PR #28970: (terminalmage) Properly handle non-string saltenvs

   * PR  #28959:  (rallytime)  Add blade password example and make note of
     timeout

   * PR #29000: (kiorky) [Mergeable] Fix up LXC

   * PR #29014: (jfindlay) systemd module: remove unneeded col command

   * PR #28983: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28969: (rallytime) Back-port #28825 to 2015.8

   * PR #28787: (chrigl) closes
     `#28784`_

   * PR #28944: (rallytime)  The  ret  result  must  contain  'name',  not
     'chassis_name' for the state compiler.

   * PR #28957: (terminalmage) Fix version number for new state option

   * PR #28950: (DmitryKuzmenko) PR 28812 which test fix

   * PR #28812: (isbm) Enhance 'which' decorator reliability

   * PR  #28934:  (terminalmage)  git.latest:  Add  update_head  option to
     prevent local HEAD from being updated

   * PR #28937:  (rallytime)  Update  dellchassis  state  example  to  use
     correct jinja syntax

   * PR  #28889:  (jfindlay)  state  compiler: relax aggregate conditional
     check

   * PR #28921: (rallytime) Back-port #25470 to 2015.8

   * PR #28922: (rallytime) Change 2015.8.2 release note title to  reflect
     proper version

   * PR    #28891:    (jfindlay)   rh_service   module:   fix   logic   in
     _chkconfig_is_enabled

   * PR  #28892:  (jfindlay)  grains.core:  correctly  identify  SLES   11
     distrib_id

   * PR #28910: (lorengordon) Fix winrepo command in windows pkg mgmt doc

   * PR #28896: (rallytime) Back-port #28855 to 2015.8

   * PR #28895: (rallytime) Back-port #28823 to 2015.8

   * PR #28885: (kt97679) fix for: service.enabled fails on xen server
     `#28754`_

   * PR #28880: (terminalmage) Add "profile" loglevel

   * PR #28882: (basepi) [2015.8] salt-ssh: Check return type to make sure
     it's an error

   * PR #28867: (rallytime) [fx2 grains] Grains  functions  should  return
     dictionaries

   * PR #28863: (mhoogendoorn) Fix ebuild.install causing extra refresh_db
     calls.

   * PR #28865: (jfindlay) add 2015.8.2 release notes

   * PR #28730: (garethgreenaway)  Fixes to how return_job is  handled  in
     the scheduler for the salt master.

   * PR #28848: (cro) Lint

   * PR #28842: (cachedout) Add transport setting to shell test

   * PR #28837: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28827: (jacksontj) Cleanup virtual_timer in loader

   * PR #28836: (cachedout) Cast to dict to fix wheel tests in tcp

   * PR #28834: (cachedout) Fix breakage in tcp server

   * PR #28804: (cachedout) TCP test fixes

   * PR #28826: (basepi) [2015.8] Add new tornado deps to salt-ssh thin

   * PR #28759: (jfindlay) simplify stdin use of stdin in at.present state

   * PR #28824: (rallytime) Back-port #28778 and #28820 to 2015.8

   * PR #28803: (jfindlay) decode strings to utf-8

   * PR #28782: (rallytime) Fixes to rabbitmq user state

   * PR  #28789: (nmadhok) Provide ability to enable/disable customization
     for newly create VMs using VMware salt-cloud driver

   * PR #28768: (mrosedale) 2015.8

   * PR #28772: (rallytime) rabbitmq.list_user_permissions returns a dict,
     not a list. Don't expect a list.

   * PR #28774: (rallytime) Back-port #28725 to 2015.8

   * PR #28775: (rallytime) Back-port #28740 to 2015.8

   * PR  #28755:  (rallytime)  Move most vmware driver list_* functions to
     use salt.utils.vmware functions

   * PR #28744: (jfindlay) import gate elementtree

   * PR #28758: (jfindlay) remove redundant  logic  in  useradd  execution
     module

   * PR #28757: (mbarrien) Bug fix: pip command to not quote spaces in cmd
     line args

   * PR #28764: (multani) Various documentation fixes

   * PR #28752: (aboe76) Update openSUSE grain for tumbleweed

   * PR #28713: (hexedpackets) Rename consul.list to consul.list_keys.

   * PR #28719: (jacobhammons) removed dependencies info from docs

   * PR #28709: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28710: (rallytime)  Pass  kwargs  correctly  to  _get_group  from
     get_group_id

   * PR #28698: (rallytime) Back-port #28530 to 2015.8

   * PR #28700: (rallytime) Back-port #28679 to 2015.8

   * PR  #28695:  (s0undt3ch)  [2015.8]  Update to latest bootstrap script
     v2015.11.09

   * PR #28656: (clarkperkins)
     `#28526`_
      fixed yumpkg module issue with pkg.installed

   * PR #28672: (jfindlay) add OS grain support for SuSE Leap

   * PR #28673: (jfindlay) add hidden_opts to mount.mounted

   * PR #28667: (cro) saltutil.sync_all should sync proxymodules  as  well
     as the rest.

   * PR #28665: (jfindlay) fixes to windows execution and state modules

   * PR #28660: (techhat) Don't sign empty regions

   * PR    #28632:    (terminalmage)    Fixes/improvements   to   pkgbuild
     state/modules

   * PR #28658: (techhat) Remove _pkgdb_fun() references

   * PR   #28653:   (rallytime)   Provide    possible    parameters    for
     boto_rds.present engine values

   * PR #28649: (bdrung) Fix OS related grains on Debian

   * PR #28646: (rallytime) Back-port #28614 to 2015.8

   * PR #28647: (rallytime) Back-port #28624 to 2015.8

   * PR #28648: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR  #28638:  (anlutro)  Salt-SSH:  Return more concise error when SSH
     command fails

   * PR #28644: (pass-by-value) Make sure versionchanged is correct

   * PR #28615: (The-Loeki) Fixes to FreeBSD pkg

   * PR #28613: (cachedout) Add facility  to  deepcopy  bound  methods  in
     Py2.6 and apply to grains

   * PR  #28612:  (rallytime) Remove unsupported storage_type argument for
     parity with boto_rds module

   * PR #28611: (rallytime) [2015.8] Be explicit  about  salt.utils.vmware
     function calls

   * PR #28610: (pass-by-value) Lxc config additions

   * PR  #28602:  (nasenbaer13)  Allow setting of custom dimensions in asg
     alarm specification

   * PR #28596: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR  #28593:  (blueyed)   doc:   fix   typo   with   salt.states.file:
     s/preseve/preserve/

   * PR #28578: (twangboy) Fixed the script... something got broke...

   * PR #28579: (jfindlay) fix __virtual__ returns: tls,uptime mods

   * PR  #28584:  (rallytime)  If AssociatePublicIpAddress is set to True,
     don't auto-assign eip.

   * PR #28576: (jacksontj) Only encode the zmq message once

   * PR #28587: (cachedout) Reset yaml rendering hooks to avoid leaks

   * PR #28581: (basepi) Revert b4875e585a165482c4c1ddc8987d76b0a71ef1b0

   * PR #28573: (jacksontj) Add body to salt.utils.http.query returns

   * PR #28564: (s0undt3ch) [2015.8] Update  to  latest  bootstrap  script
     v2015.11.04

   * PR #28561: (Oro) Issue
     `#28527`_
      boto_rds.create does not work

   * PR #28560: (bdrung) Fix various typos

   * PR  #28550:  (jfindlay)  check timedatectl errno and return stdout on
     failure

   * PR #28545:  (jfindlay)  pass  on  concurrent  create  of  jid_dir  in
     local_cache

   * PR  #28544:  (rallytime)  Start  moving some vmware.py cloud funcs to
     utils/vmware.py

   * PR  #28543:  (gtmanfred)  clean  up  changes  for  pkg.uptodate   and
     supervisord.dead

   * PR #28538: (jfindlay) decode path and url to utf-8 in url.create

   * PR #28533: (jfindlay) decode highstate error messages to utf-8

   * PR #28547: (nmadhok) [Backport] [2015.8] Tasks can be in queued state
     instead of running

   * PR #28535: (techhat) Fail gracefully if 169.254* isn't available

   * PR #28536: (cro) Default configuration file for proxy minions.

   * PR #28534: (rallytime) Add versionadded directive for vpc_name arg in
     boto_secgroup.present

   * PR #28516: (rallytime) Back-port #28489 to 2015.8

   * PR  #28506:  (basepi)  [2015.8]  Log  minion list for all rosters, at
     debug level

   * PR #28514: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28502: (cachedout) Lint #28427

   * PR #28464: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28486: (rallytime) Back-port #26945 to 2015.8

   * PR #28472: (gtmanfred) overwrite more than one value with names

   * PR #28493: (rallytime) Back-port #28492 to 2015.8

   * PR #28494: (whiteinge) Fix filter_by passing incorrect parameters  to
     match functions

   * PR #28491: (rallytime) Back-port #28388 to 2015.8

   * PR #28465: (twangboy) Fix
     `#12363`_
     : Password Expiration in Windows

   * PR #28485: (nasenbaer13) Fix invalid usage of _get_conn causing
     `#28484`_

   * PR  #28454:  (sdm24) Fixed nodegroup doc formatting to correctly link
     to pillar_opts in the master config

   * PR #28487: (cachedout) Lint 28456

   * PR  #28457:  (sdm24)  Clarified  comments  for   grains/core.py   for
     ip_interfaces, ip4_interfac...

   * PR #28473: (anlutro) Show check_cmd output on failure

   * PR #28460: (jtand) Skipped wipefs test if wipefs does not exist on OS

   * PR   #28426:  (terminalmage)  pkgbuild.built:  make  template  engine
     optional

   * PR #28422: (cachedout) Handle windows logging on thread_multi [WIP]

   * PR #28425: (twangboy) Fix
     `#13513`_
      - Reflection

   * PR #28417: (rallytime) Add note about azure sdk  version  to  getting
     started docs

   * PR      #28410:      (jacksontj)      Add      retries     to     the
     zeromq.AsyncReqMessageClient

   * PR #28404: (rallytime) Back-port #28395 to 2015.8

   * PR #28405: (opdude) Detect legacy versions of chocolatey correctly

   * PR #28187: (sjansen) fix at.present

   * PR #28375: (merll) Merge pillar includes correctly

   * PR  #28376:  (ryan-lane)  Support  update  of  route53  records  with
     multiple values

   * PR  #28377:  (terminalmage) Deprecate 'always' in favor of 'force' in
     pkgbuild.built

   * PR #28380: (cro) Add missing call for service provider

   * PR #28348: (jfindlay) salt.utils.alias informs user they are using  a
     renamed function

   * PR #28364: (jtand) In CentOS 5 the .split() causes a stacktrace.

   * PR #28361: (rallytime) Back-port #28087 to 2015.8

   * PR #28360: (multani) Various documentation fixes

   * PR #28370: (rallytime) Back-port #28276 to 2015.8

   * PR #28353: (merll) Consider each pillar match only once.

   * PR #28334: (anlutro) iptables needs -m comment for --comment to work

   * PR #28340: (jfindlay) sdecode file and dir lists in fileclient

   * PR #28344: (ryan-lane) Fix iptables state for non-filter tables

   * PR #28343: (rallytime) Back-port #28342 to 2015.8

   * PR #28330: (rallytime) Back-port #28305 to 2015.8

   * PR  #28270:  (rallytime)  Refactor RabbitMQ Plugin State to correctly
     use test=true and format errors

   * PR #28269: (rallytime) Refactor rabbitmq_user state to use  test=True
     correctly

   * PR  #28299:  (rallytime)  Add  test  for  availability_zone  check to
     boto_vpc_tests

   * PR #28306: (sdm24) Updated the  Nodegroup  docs  to  include  how  to
     target nodegroups in SLS Jinja

   * PR   #28308:   (rallytime)   Firewalld   state  services  should  use
     --add-service, not --new-service

   * PR #28302: (DmitryKuzmenko) Always close socket even if there  is  no
     stream.

   * PR #28282: (keesbos) Fix for __env__ in legacy git_pillar

   * PR #28258: (pass-by-value) Add service module for ssh proxy example

   * PR #28294: (bechtoldt) correct a bad default value in http utility

   * PR  #28185:  (jtand)  Added single package return for latest_version,
     fixed other bug.

   * PR #28297: (cachedout) Lint fix proxy junos

   * PR #28210: (terminalmage) Fix for ext_pillar being compiled twice  in
     legacy git_pillar code

   * PR #28265: (jfindlay) fix blockdev execution and state modules

   * PR #28266: (rallytime) Back-port #28260 to 2015.8

   * PR #28253: (rallytime) Back-port #28063 to 2015.8

   * PR  #28231:  (rallytime)  Make  sure  we're  compairing  strings when
     getting images in the DO driver

   * PR #28224: (techhat) Optimize create_repo for large packages

   * PR #28214: (rallytime) Don't stacktrace if  invalid  credentials  are
     passed to boto_route53 state

   * PR #28228: (rallytime) Back-port #27562 to 2015.8

   * PR  #28232: (rallytime) Add documentation to supply the ssh_username:
     freebsd config to DO docs

   * PR #28198: (jacobhammons) Added note regarding  missing  spm  exe  on
     Debian/Ubuntu

   * PR #28182: (erchn) Some fixes for nova driver for Rackspace

   * PR #28181: (rallytime) Revamp firewalld state to be more stateful.

   * PR #28176: (cro) Add ping function

   * PR #28167: (The-Loeki) file.serialize needs to add a final newline to
     serialized files

   * PR #28168: (rallytime) Make sure availability  zone  gets  passed  in
     boto_vpc module when creating subnet

   * PR #28148: (basepi) [2015.8] Only expand nodegroups to lists if there
     is a nested nodegroup

   * PR #28155: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #28149: (pass-by-value) Add clarification  to  cloud  profile  doc
     about host

   * PR #28146: (cachedout) Lint dracr.py

   * PR #28141: (rallytime) Don't use RAM for root disk size in linode.py

   * PR #28143: (jtand) Removed blank line at end of chassis.py

   * PR #28021: (blueyed) Handle includes in include_config recursively

   * PR #28095: (rallytime) Back-port #28001 to 2015.8

   * PR #28096: (rallytime) Back-port #28061 to 2015.8

   * PR #28139: (rallytime) Back-port #28103 to 2015.8

   * PR  #28098:  (jacksontj)  For  all  multi-part  messages,  check  the
     headers. If the header is not ...

   * PR #28134: (bernieke) fix unicode pillar values
     `#3436`_

   * PR #28076: (redmcg) Replace option 'i' with an explicit queryformat

   * PR #28119: (jacksontj) Check if the remote exists before casting to a
     string.

   * PR #28105: (jfindlay) add reason for not loading localemod

   * PR #28108: (cachedout) Set logfile permsissions correctly

   * PR #27922: (cro) WIP States/Modules for managing Dell FX2 chassis via
     salt-proxy

   * PR #28104: (pass-by-value) Add documentation for proxy minion ssh

   * PR #28020: (DmitryKuzmenko) LazyLoader deepcopy fix.

   * PR #27933: (eliasp) Provide all git pillar dirs in opts[pillar_roots]

   * PR #28013: (rallytime) Back-port #27891 to 2015.8

   * PR #28018: (rallytime) Add example to Writing Grains  of  how  grains
     can be loaded twice

   * PR #28084: (cachedout) #28069 with lint

   * PR  #28079:  (The-Loeki)  Fix  for  trace dump on failing imports for
     win32com & pythoncom 4 win_task

   * PR #28081: (The-Loeki) fix for glance state  trace  error  on  import
     failure

   * PR  #28066:  (jacksontj) Use the generic text attribute, not .body of
     the handler

   * PR #28019: (rallytime) Clean up version added and deprecated msgs  to
     be accurate

   * PR #28058: (rallytime) Back-port #28041 to 2015.8

   * PR #28055: (rallytime) Back-port #28043 to 2015.8

   * PR #28046: (pass-by-value) Add pkg install and remove functions

   * PR  #28050:  (ryan-lane)  Use  a  better method for checking dynamodb
     table existence

   * PR  #28042:  (jfindlay)  fix  repo  path   in   ubuntu   installation
     documentation

   * PR #28033: (twangboy) Fixed win_useradd.py

   * PR #28027: (cro) Make ssh conn persistent.

   * PR  #28029:  (jacobhammons) Updated release notes with additional CVE
     information

   * PR #28022: (jacobhammons) Updated Debian and Ubuntu repo  paths  with
     new structure for 2015.8.1

   * PR  #27983:  (rallytime)  Pip  state  run result should be False, not
     None, if installation error occurs.

   * PR #27991: (twangboy) Fix for
     `#20678`_

   * PR #27997: (rallytime) Remove note about pip bug with pip v1  vs  pip
     v2 return codes

   * PR #27994: (jtand) Fix schedule_test failure

   * PR #27992: (cachedout) Make load beacon config into list

   * PR #28003: (twangboy) Fix
     `#26336`_

   * PR #27984: (rallytime) Versionadded for clean_file option for pkgrepo

   * PR  #27989:  (ryan-lane)  Do  not  try to remove the main route table
     association

   * PR #27982: (pass-by-value) Add example for salt-proxy over SSH

   * PR #27985: (jacobhammons) Changed current release to  8.1  and  added
     CVEs to release notes

   * PR #27979: (cachedout) Fix regression with key whitespace

   * PR #27977: (cachedout) Decode unicode names in fileclient/server

   * PR #27981: (jtand) Fixed trailing whitespace lint

   * PR #27969: (jeffreyctang) fix parse of { on next line

   * PR #27978: (terminalmage) Add note about dockerng.inspect_image usage

   * PR #27955: (pass-by-value) Bp 27868

   * PR #27953: (The-Loeki) Fix CloudStack cloud for new 'driver' syntax

   * PR #27965: (ryan-lane) Fail in boto_asg.present if alarms fail

   * PR #27958: (twangboy) Added new functionality to win_task.py

   * PR #27959: (techhat) Change __opts__ to self.opts

   * PR #27943: (rallytime) Back-port #27910 to 2015.8

   * PR #27944: (rallytime) Back-port #27909 to 2015.8

   * PR #27946: (jtand) Changed grain to look at osmajorrelease instead of
     osrelease

   * PR #27914: (rallytime) Use eipalloc instead of eni in  EC2  interface
     properties example

   * PR #27926: (rallytime) Back-port #27905 to 2015.8

   * PR  #27927:  (ryan-lane) Do not manage ingress or egress rules if set
     to None

   * PR #27928: (rallytime) Back-port #27908 to 2015.8

   * PR #27676: (ticosax) [dockerng] WIP No more runtime  args  passed  to
     docker.start()

   * PR #27885: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27882: (twangboy) Created win_task.py module

   * PR #27802: (terminalmage) Correct warning logging when update lock is
     present for git_pillar/winrepo,  add  runner  function  for  clearing
     git_pillar/winrepo locks

   * PR  #27886: (rallytime) Handle group lists as well as comma-separated
     group strings.

   * PR #27746: (anlutro) timezone module: handle timedatectl errors

   * PR  #27816:  (anlutro)  Make  system.reboot  use  shutdown  -r   when
     available

   * PR #27874: (rallytime) Add mention of Periodic Table naming scheme to
     deprecation docs

   * PR #27883: (terminalmage) Work around --is-ancestor not being present
     in git-merge-base before git 1.8.0

   * PR #27877: (rallytime) Back-port #27774 to 2015.8

   * PR #27878: (rallytime) Use apache2ctl binary on SUSE in apache module

   * PR #27879: (cro) Add docs for 2015.8.2+ changes to proxies

   * PR #27731: (cro) Add __proxy__ to replace opts['proxymodule']

   * PR #27745: (anlutro) Add pip_upgrade arg to virtualenv.managed state

   * PR #27809: (ticosax) [dockerng] Remove dockerng.ps caching

   * PR #27859: (ticosax) [dockerng] Clarify doc port bindings

   * PR #27748: (multani) Fix
     `#8646`_

   * PR #27850: (rallytime) Back-port #27722 to 2015.8

   * PR #27851: (rallytime) Back-port #27771 to 2015.8

   * PR #27833: (jfindlay) decode path before string ops in fileclient

   * PR #27837: (jfindlay) reverse truth in python_shell documentation

   * PR  #27860: (flavio) Fix OS related grains on openSUSE and SUSE Linux
     Enterprise

   * PR #27768: (rallytime) Clean up bootstrap  function  to  be  slightly
     cleaner

   * PR #27797: (isbm) Zypper module clusterfix

   * PR  #27849:  (rallytime)  Don't  require a size parameter for proxmox
     profiles

   * PR #27827: (techhat) Add additional error checking to SPM

   * PR #27826: (martinhoefling) Fixes
     `#27825`_

   * PR #27824: (techhat) Update Azure errors

   * PR #27795: (eguven) better change reporting for postgres_user groups

   * PR #27799: (terminalmage) Fix usage of identity file in git.latest

   * PR #27717: (pass-by-value) Proxy beacon example

   * PR #27793: (anlutro) update code that changes log level  of  salt-ssh
     shim command

   * PR  #27761:  (terminalmage)  Merge  git  pillar data instead of using
     dict.update()

   * PR #27741: (ticosax) [dockerng] pass filters argument to dockerng.ps

   * PR #27760: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #27757: (jfindlay) fix virtual fcn return doc indentation

   * PR #27754: (rallytime) Change test.nop version directive to 2015.8.1

   * PR #27734: (jacobhammons) Updated saltstack2 theme to add  SaltConf16
     banner

   * PR #27727: (rallytime) Merge #27719 w/pylint fix

   * PR #27724: (jfindlay) update __virtual__ return documentation

   * PR #27725: (basepi) Fix global injection for state cross calls

   * PR  #27628:  (ticosax) [dockerng] Add support of labels parameter for
     dockerng

   * PR #27704: (jacobhammons) Update compound matcher docs to clarify the
     usage of alternate delimi...

   * PR #27705: (rallytime) Merge #27602 with final pylint fix

   * PR  #27691:  (notpeter)  Faster  timeout  (3s  vs  2min) for instance
     metadata lookups.
     `#13850`_
     .

   * PR #27696: (blueyed) loader.proxy: call _modules_dirs only once

   * PR #27630: (ticosax) Expose container_id in mine.get_docker

   * PR #27600: (blueyed) dockerng: use docker.version=auto by default

   * PR #27689: (rallytime) Merge #27448 with test fixes

   * PR #27693: (jacobhammons) initial engines topic, updates  to  windows
     repo docs

   * PR #27601: (blueyed) dockerng: handle None in container.Names

   * PR #27596: (blueyed) gitfs: fix UnboundLocalError for 'msg'

   * PR  #27651:  (eliasp) Check for existence of 'subnetId' key in subnet
     dict

   * PR #27639: (rallytime) Docement version  added  for  new  artifactory
     options

   * PR #27677: (rallytime) Back-port #27675 to 2015.8

   * PR #27637: (rallytime) Back-port #27604 to 2015.8

   * PR #27657: (garethgreenaway) Fix to pkg state module

   * PR #27632: (rallytime) Back-port #27539 to 2015.8

   * PR #27633: (rallytime) Back-port #27559 to 2015.8

   * PR   #27579:   (rallytime)  Change  boto_route53  region  default  to
     'universal' to avoid problems with boto library

   * PR  #27581:  (tkwilliams)  Add  support   for   'vpc_name'   tag   in
     boto_secgroup module and state

   * PR  #27624: (nasenbaer13) Wait for sync is not passed to boto_route53
     state

   * PR #27614: (blueyed) doc: minor fixes to doc and comments

   * PR #27627: (eyj) Fix crash in boto_asg.get_instances if the requested
     attribute is None

   * PR #27616: (jacobhammons) Updated windows software repository docs

   * PR  #27569:  (lomeroe)  boto_vpc.get_subnet_association now returns a
     dict w/key of vpc_id, a...

   * PR #27567: (whiteinge) Use getattr to fetch psutil.version_info

   * PR #27583: (tkwilliams) Fixup zypper module

   * PR    #27597:    (blueyed)    gitfs:    remove    unused     variable
     "bad_per_remote_conf"

   * PR #27585: (ryan-lane) Fix undefined variable in cron state module

   Salt 2015.8.4 Release Notes
   Known Issues
   in_ requisites (issue 30820)

   This  issue affects all users targeting an explicit - name: <name> with
   a _in requisite (such as watch_in or require_in). If you are not  using
   explicit  -  name:  <name>  arguments,  are targeting with the state ID
   instead of the name, or are not using _in requisites, then  you  should
   be safe to upgrade to 2015.8.4.

   This issue is resolved in the 2015.8.5 release.

   Security Fix
   CVE-2016-1866: Improper handling of clear messages on the minion, which
   could result in executing commands not sent by the master.

   This issue affects only the 2015.8.x releases of Salt. In order for  an
   attacker  to  use  this  attack  vector,  they  would have to execute a
   successful attack on an existing  TCP  connection  between  minion  and
   master  on  the  pub  port.  It  does not allow an external attacker to
   obtain the shared secret  or  decrypt  any  encrypted  traffic  between
   minion  and  master.  Thank you to Sebastian Krahmer <[email protected]>
   for bringing this issue to our attention.

   We recommend everyone upgrade to 2015.8.4 as soon as possible.

   Core Changes
   * PR #28994: timcharper Salt S3 module has learned how  to  assume  IAM
     roles

   * Added  option  mock=True  for  state.sls  and  state.highstate.  This
     allows the salt state compiler to process sls data  in  a  state  run
     without actually calling the state functions, thus providing feedback
     on the validity of the arguments used for the  functions  beyond  the
     preprocessing  validation provided by state.show_sls (issue 30118 and
     issue 30189).

        salt '*' state.sls core,edit.vim mock=True
        salt '*' state.highstate mock=True
        salt '*' state.apply edit.vim mock=True

   Changes for v2015.8.3..v2015.8.4
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-01-25T17:48:35Z

   Total Merges: 320

   Changes:

   * PR #30613: (basepi) Fix minion/syndic clearfuncs

   * PR #30609: (seanjnkns) Fix documentation for pillar_merge_lists which
     default is False, not ...

   * PR #30584:  (julianbrost)  file.line  state:  add  missing  colon  in
     docstring

   * PR #30589: (terminalmage) Merge 2015.5 into 2015.8

   * PR #30599: (multani) Documentation formatting fixes

   * PR  #30554:  (rallytime)  Make  the  salt-cloud  actions  output more
     verbose and helpful

   * PR #30549: (techhat) Salt Virt cleanup

   * PR #30553: (techhat) AWS: Support 17-character IDs

   * PR #30532: (whiteinge) Add execution module for working in sls files

   * PR #30529: (terminalmage) Merge 2015.5 into 2015.8

   * PR #30526: (twangboy) Added FlushKey to make sure  it's  changes  are
     saved to disk

   * PR #30521: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30485: (jtand) Updated pip_state to work with pip 8.0 on 2015.8

   * PR  #30494:  (isbm)  Zypper: info_installed --- 'errors' flag change to
     type 'boolean'

   * PR #30506: (jacksontj) Properly remove  newlines  after  reading  the
     file

   * PR #30508: (rallytime) Fix Linode driver cloning functionality

   * PR  #30522:  (terminalmage) Update git.list_worktree tests to reflect
     new return data

   * PR  #30483:  (borgstrom)  Pyobjects  recursive  import  support  (for
     2015.8)

   * PR #30491: (jacksontj) Add multi-IP support to network state

   * PR #30496: (anlutro) Fix KeyError when adding ignored pillars

   * PR  #30359:  (kingsquirrel152) Removes suspected copy/paste error for
     zmq_filtering functionailty

   * PR #30448: (cournape) Fix osx scripts location

   * PR #30457: (rallytime) Remove fsutils references from modules list

   * PR #30453: (rallytime) Make sure private AND public  IPs  are  listed
     for Linode driver

   * PR #30458: (rallytime) Back-port #30062 to 2015.8

   * PR  #30468:  (timcharper) make note of s3 role assumption in upcoming
     changelog

   * PR #30470: (whiteinge)  Add  example  of  the  match_dict  format  to
     accept_dict wheel function

   * PR #30450: (gtmanfred) fix extension loading in novaclient

   * PR #30212: (abednarik) Fix incorrect file permissions in file.line

   * PR #29947: (jfindlay) fileclient: decode file list from master

   * PR  #30363:  (terminalmage)  Use native "list" subcommand to list git
     worktrees

   * PR #30445: (jtand) Boto uses False for is_default instead of None

   * PR   #30406:   (frioux)   Add   an   example   of    how    to    use
     file.managed/check_cmd

   * PR #30424: (isbm) Check if byte strings are properly encoded in UTF-8

   * PR #30405: (jtand) Updated glusterfs.py for python2.6 compatibility.

   * PR #30396: (pass-by-value) Remove hardcoded val

   * PR #30391: (jtand) Added else statements

   * PR  #30375: (rallytime) Wrap formatted log statements with six.u() in
     cloud/__init__.py

   * PR #30384: (isbm) Bugfix: info_available does not work  correctly  on
     SLE 11 series

   * PR #30376: (pritambaral) Fix FLO_DIR path in 2015.8

   * PR #30389: (jtand) Older versions of ipset don't support comments

   * PR #30373: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #30372:  (jacobhammons)  Updated  man pages for 2015.8.4, updated
     copyright to 2016

   * PR #30370: (rallytime) Remove incomplete function

   * PR #30366: (rallytime) Back-port #28702 to 2015.8

   * PR #30361: (cro) Flip the sense of the test for proxymodule  imports,
     add more fns for esxi proxy

   * PR  #30267:  (isbm) Fix RPM issues with the date/time and add package
     attributes filtering

   * PR #30360: (jfindlay) file.remove, file.absent: mention recursive dir
     removal

   * PR #30221: (mbarrien) No rolcatupdate for user_exist in Postgres>=9.5
     `#26845`_

   * PR #30358: (terminalmage) Add libgit2 version to versions-report

   * PR #30346: (pass-by-value) Prevent orphaned volumes

   * PR #30349: (rallytime) Back-port #30347 to 2015.8

   * PR #30354: (anlutro) Make sure all ignore_missing SLSes are caught

   * PR #30356: (nmadhok) Adding code author

   * PR  #30340:  (jtand)  Updated  seed_test.py  for changes made to seed
     module

   * PR #30339: (jfindlay) Backport #26511

   * PR #30343: (rallytime) Fix 2015.8 from incomplete back-port

   * PR #30342: (eliasp) Correct whitespace placement in error message

   * PR #30308: (rallytime) Back-port #30257 to 2015.8

   * PR #30187: (rallytime) Back-port #27606 to 2015.8

   * PR #30223: (serge-p) adding support for DragonFly BSD

   * PR #30238: (rallytime) Reinit crypto before calling RSA.generate when
     generating keys.

   * PR #30246: (dmacvicar) Add missing return data to scheduled jobs (
     `#24237`_
     )

   * PR #30292: (thegoodduke) ipset: fix test=true & add comment for every
     entry

   * PR #30275: (abednarik) Add permanent argument in firewalld.

   * PR #30328: (cachedout) Fix file test

   * PR #30310: (pass-by-value) Empty bucket fix

   * PR #30211: (techhat) Execute choot on the correct path

   * PR #30309: (rallytime) Back-port #30304 to 2015.8

   * PR #30278: (nmadhok) If datacenter is specified in the  config,  then
     look for managed objects under it

   * PR  #30305:  (jacobhammons) Changed examples to use the "example.com"
     domain instead of "mycompan...

   * PR #30249:  (mpreziuso)  Fixes  performance  and  timeout  issues  on
     win_pkg.install

   * PR  #30217: (pass-by-value) Make sure cloud actions can be called via
     salt run

   * PR #30268: (terminalmage) Optimize file_tree  ext_pillar  and  update
     file.managed to allow for binary contents

   * PR  #30245:  (rallytime)  Boto  secgroup/iam_role:  Add  note stating
     us-east-1 is default region

   * PR #30299: (rallytime) ESXi  Proxy  minions  states  are  located  at
     salt.states.esxi, not vsphere.

   * PR #30202: (opdude) Fixed the periodic call to beacons

   * PR  #30303:  (jacobhammons)  Changed notes to indicate that functions
     are matched using regular ex...

   * PR #30284: (terminalmage) salt.utils.gitfs: Fix Dulwich env detection
     and submodule handling

   * PR #30280: (jfindlay) add state mocking to release notes

   * PR #30273: (rallytime) Back-port #30121 to 2015.8

   * PR #30301: (cachedout) Accept whatever comes into hightstate mock for
     state tests

   * PR #30282: (cachedout) Fix file.append logic

   * PR #30289: (cro) Fix problems with targeting proxies by grains

   * PR #30293: (cro) Ensure we don't log stuff we shouldn't

   * PR #30279: (cachedout) Allow modules to be packed into boto utils

   * PR #30186: (rallytime) Update CLI  Examples  in  boto_ec2  module  to
     reflect correct arg/kwarg positioning

   * PR    #30156:    (abednarik)    Add    option   in   file.append   to
     ignore_whitespace.

   * PR #30189: (rallytime) Back-port #30185 to 2015.8

   * PR #30215: (jacobhammons) Assorted doc bug fixes

   * PR #30206: (cachedout) Revert  "Fix  incorrect  file  permissions  in
     file.line"

   * PR #30190: (jacobhammons) Updated doc site banners

   * PR  #30180:  (jfindlay)  modules.x509._dec2hex: add fmt index for 2.6
     compat

   * PR #30179: (terminalmage) Backport #26962 to 2015.8 branch

   * PR #29693: (abednarik) Handle missing source file in ssh_auth.

   * PR #30155: (rallytime) Update boto_secgroup and boto_iam_role docs to
     only use region OR profile

   * PR    #30158:    (rallytime)    Move    _option(value)    calls    to
     __salt__['config.option'] in boto utils

   * PR #30160: (dmurphy18) Fix parsing disk usage for line with no number
     and AIX values in Kilos

   * PR  #30162:  (rallytime)  Update list_present and append grains state
     function docs to be more clear.

   * PR #30163: (rallytime) Add  warning  about  using  "="  in  file.line
     function

   * PR #30164: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30168: (abednarik) Fix incorrect file permissions in file.line

   * PR #30154: (Oro) Fix file serialize on windows

   * PR  #30144:  (rallytime) Added generic ESXCLI command ability to ESXi
     Proxy Minion

   * PR #30142: (terminalmage) Fix dockerng.push, and allow  for  multiple
     images

   * PR #30075: (joejulian) Convert glusterfs module to use xml

   * PR #30129: (optix2000) Clean up _uptodate() in git state

   * PR #30139: (rallytime) Back-port #29589 to 2015.8

   * PR #30124: (abednarik) Update regex to detect ip alias in OpenBSD.

   * PR #30133: (stanislavb) Fix typo in gpgkey URL

   * PR #30126: (stanislavb) Log S3 API error message

   * PR #30128: (oeuftete) Log retryable transport errors as warnings

   * PR #30096: (cachedout) Add rm_special to crontab module

   * PR #30106: (techhat) Ensure last dir

   * PR  #30101:  (gtmanfred)  fix  bug  where  nova  driver exits with no
     adminPass

   * PR #30090: (techhat) Add argument to isdir()

   * PR #30094: (rallytime) Fix doc formatting for cloud.create example in
     module.py state

   * PR  #30095:  (rallytime) Add the list_nodes_select function to linode
     driver

   * PR #30082: (abednarik) Fixed saltversioninfo grain return

   * PR #30084: (rallytime) Back-port #29987 to 2015.8

   * PR #30071: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR     #30067:      (ryan-lane)      Pass      in      kwargs      to
     boto_secgroup.convert_to_group_ids explicitly

   * PR #30069: (techhat) Ensure that pki_dir exists

   * PR #30064: (rallytime) Add Syndic documentation to miscellaneous Salt
     Cloud config options

   * PR #30049: (rallytime) Add some  more  unit  tests  for  the  vsphere
     execution module

   * PR #30060: (rallytime) Back-port #27104 to 2015.8

   * PR  #30048:  (jacobhammons)  Remove  internal APIs from rest_cherrypy
     docs.

   * PR   #30043:   (rallytime)   Be   explicit   about   importing   from
     salt.utils.jinja to avoid circular imports

   * PR #30038: (rallytime) Back-port #30017 to 2015.8

   * PR #30036: (rallytime) Back-port #29995 to 2015.8

   * PR #30035: (rallytime) Back-port #29895 to 2015.8

   * PR #30034: (rallytime) Back-port #29893 to 2015.8

   * PR #30033: (rallytime) Back-port #29876 to 2015.8

   * PR  #30029:  (terminalmage)  git.latest:  Fix handling of nonexistent
     branches

   * PR #30016: (anlutro) Properly normalize locales in locale.gen_locale

   * PR #30015: (anlutro) locale module: don't escape the slash in \n

   * PR #30022: (gqgunhed) Two minor typos fixed

   * PR #30026: (anlutro) states.at: fix wrong variable being used

   * PR  #29966:  (multani)  Fix  bigip   state/module   documentation   +
     serializers documentation

   * PR #29904: (twangboy) Improvements to osx packaging scripts

   * PR  #29950:  (multani) boto_iam: fix deletion of IAM users when using
     delete_keys=true

   * PR #29937: (multani) Fix states.boto_iam group users

   * PR #29934: (multani) Fix state.boto_iam virtual name

   * PR #29943: (cachedout) Check args correctly in boto_rds

   * PR #29924: (gqgunhed) fixed: uptime now working on non-US Windows

   * PR #29883: (serge-p) fix for nfs mounts in _active_mounts_openbsd()

   * PR #29894: (techhat) Support Saltfile in SPM

   * PR  #29856:  (rallytime)  Added  some  initial  unit  tests  for  the
     salt.modules.vsphere.py file

   * PR #29855: (rallytime) Back-port #29740 to 2015.8

   * PR #29890: (multani) Various documentation fixes

   * PR #29850: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29811: (anlutro) influxdb: add retention policy module functions

   * PR #29814: (basepi) [2015.8][Windows] Fix multi-master on windows

   * PR #29819: (rallytime) Add esxi module and state to docs build

   * PR #29832: (jleimbach) Fixed typo in order to use the keyboard module
     for RHEL without systemd

   * PR #29803: (rallytime) Add vSphere module to doc ref module tree

   * PR #29767: (abednarik) Hosts file update in mod_hostname.

   * PR #29772: (terminalmage) pygit2:  skip  submodules  when  traversing
     tree

   * PR #29765: (gtmanfred) allow nova driver to be boot from volume

   * PR  #29773:  (l2ol33rt)  Append  missing  wget in debian installation
     guide

   * PR #29800: (rallytime) Back-port #29769 to 2015.8

   * PR #29775: (paulnivin) Change listen requisite resolution  from  name
     to ID declaration

   * PR #29754: (rallytime) Back-port #29719 to 2015.8

   * PR #29713: (The-Loeki) Pillar-based cloud providers still forcing use
     of deprecated 'provider'

   * PR  #29729:  (rallytime)  Further  clarifications  on  "unless"   and
     "onlyif" requisites.

   * PR #29737: (akissa) fix pillar sqlite3 documentation examples

   * PR #29743: (akissa) fix pillar sqlite not honouring config options

   * PR  #29723:  (rallytime)  Clarify  db_user and db_password kwargs for
     postgres_user.present state function

   * PR #29722: (rallytime) Link "stateful" kwargs to definition  of  what
     "stateful" means for cmd state.

   * PR #29724: (rallytime) Add examples of using multiple matching levels
     to Pillar docs

   * PR #29726: (cachedout) Disable some boto tests per resolution of moto
     issue

   * PR  #29708:  (lagesag)  Fix test=True for file.directory with recurse
     ignore_files/ignore_dirs.

   * PR  #29642:  (cachedout)  Correctly  restart  deamonized  minions  on
     failure

   * PR #29599: (cachedout) Clean up minion shutdown

   * PR #29675: (clinta) allow returning all refs

   * PR  #29683:  (rallytime)  Catch more specific error to pass the error
     message through elegantly.

   * PR #29687: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29681: (clinta) fix bare/mirror in git.latest

   * PR #29644: (rallytime) Fixed a couple more ESXi proxy minion bugs

   * PR #29645: (rallytime) Back-port #29558 to 2015.8

   * PR #29632: (jfindlay)  reduce  severity  of  tls  module  __virtual__
     logging

   * PR #29606: (abednarik) Fixed duplicate mtu entry in RedHat 7  network
     configuration.

   * PR #29613: (rallytime) Various ESXi Proxy Minion Bug Fixes

   * PR #29628: (DmitryKuzmenko) Don't create io_loop before fork

   * PR #29609: (basepi) [2015.8][salt-ssh] Add ability  to  set  salt-ssh
     command umask in roster

   * PR #29603: (basepi) Fix orchestration failure-checking

   * PR  #29597:  (terminalmage)  dockerng:  Prevent  exception  when  API
     response contains empty dictionary

   * PR #29596: (rallytime) Back-port #29587 to 2015.8

   * PR #29588: (rallytime) Added ESXi Proxy Minion Tutorial

   * PR  #29572:  (gtmanfred)  [nova]  use  old   discover_extensions   if
     available

   * PR  #29545:  (terminalmage)  git.latest:  init  submodules if not yet
     initialized

   * PR #29548: (rallytime) Back-port #29449 to 2015.8

   * PR #29547: (rallytime) Refactored ESXCLI-based functions to accept  a
     list of esxi_hosts

   * PR   #29563:   (anlutro)   Fix   a   call  to  deprecated  method  in
     python-influxdb

   * PR #29565: (bdrung) Fix typos and missing release note

   * PR #29540: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29499: (rallytime) Initial commit of ESXi Proxy Minion

   * PR #29526: (jfindlay)  2015.8.2  notes:  add  note  about  not  being
     released

   * PR #29531: (jfindlay) grains.core: handle undefined variable

   * PR  #29538:  (basepi)  [2015.8] [salt-ssh] Remove umask around actual
     execution for salt-ssh

   * PR #29505: (rallytime) Update boto_rds state docs  to  include  funky
     yaml syntax for "tags" option.

   * PR #29513: (bdrung) Drop obsolete syslog.target from systemd services

   * PR #29500: (rallytime) Back-port #29467 to 2015.8

   * PR #29463: (abednarik) Add
     **
     kwargs to debconf.set.

   * PR  #29399:  (jfindlay)  modules.status: add human_readable option to
     uptime

   * PR #29433: (cro) Files for building .pkg files for MacOS X

   * PR #29455: (jfindlay) modules.nova.__init__: do not return None

   * PR #29454: (jfindlay)  rh_service  module  __virtual__  return  error
     messages

   * PR   #29476:   (tbaker57)   Doc   fix   -  route_table_present  needs
     subnet_names (not subnets) as a key

   * PR #29487: (rallytime) Back-port #29450 to 2015.8

   * PR #29441: (rallytime)  Make  sure  docs  line  up  with  blade_idrac
     function specs

   * PR #29440: (rallytime) Back-port #28925 to 2015.8

   * PR  #29435:  (galet)  Grains  return  wrong  OS  version and other OS
     related values for Oracle Linux

   * PR #29430: (rall0r) Fix host.present state limitation

   * PR #29417: (jacobhammons) Repo install updates

   * PR #29402: (techhat) Add rate limiting to linode

   * PR #29400: (twangboy) Fix #19332

   * PR #29398: (cachedout) Lint 29288

   * PR #29331: (DmitryKuzmenko) Bugfix - #29116 raet dns error

   * PR #29390: (jacobhammons) updated version numbers in documentation

   * PR #29381: (nmadhok) No need to deepcopy since six.iterkeys() creates
     a copy

   * PR #29349: (cro) Fix mis-setting chassis names

   * PR #29334: (rallytime) Back-port #29237 to 2015.8

   * PR  #29300: (ticosax) [dockerng] Add support for volume management in
     dockerng

   * PR #29218: (clan) check service enable state in test mode

   * PR #29315: (jfindlay) dev tutorial doc: fix markup errors

   * PR #29317: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29240: (clan) handle acl_type [[d]efault:][user|group|mask|other]

   * PR #29305: (lorengordon) Add 'file' as a source_hash proto

   * PR #29272: (jfindlay) win_status  module:  handle  12  hour  time  in
     uptime

   * PR  #29289:  (terminalmage) file.managed: Allow local file sources to
     use source_hash

   * PR  #29264:  (anlutro)  Prevent  ssh_auth.absent  from  running  when
     test=True

   * PR #29277: (terminalmage) Update git_pillar runner to support new git
     ext_pillar config schema

   * PR #29283: (cachedout) Single-quotes and use format

   * PR #29139: (thomaso-mirodin) [salt-ssh] Add a range roster and  range
     targeting options for the flat roster

   * PR #29282: (cachedout) dev docs: add development tutorial

   * PR #28994: (timcharper) add support to s3 for aws role assumption

   * PR #29278: (techhat) Add verify_log to SPM

   * PR  #29067:  (jacksontj) Fix infinite recursion in state compiler for
     prereq of SLSs

   * PR #29207: (jfindlay) do not shadow ret function argument

   * PR #29215: (rallytime) Back-port #29192 to 2015.8

   * PR #29217: (clan) show duration only if state_output_profile is False

   * PR #29221: (ticosax) [dokcerng] Docu network mode

   * PR #29269: (jfindlay) win_status module: fix function names in docs

   * PR #29213: (rallytime) Move _wait_for_task func from vmware cloud  to
     vmware utils

   * PR #29271: (techhat) Pass full path for digest (SPM)

   * PR #29244: (isbm) List products consistently across all SLES systems

   * PR #29255: (garethgreenaway) fixes to consul module

   * PR #29208: (whytewolf) Glance more profile errors

   * PR #29200: (jfindlay) mount state: unmount by device is optional

   * PR #29205: (trevor-h) Fixes #29187 - using winrm on EC2

   * PR #29170: (cachedout) Migrate pydsl tests to integration test suite

   * PR #29198: (jfindlay) rh_ip module: only set the mtu once

   * PR  #29135: (jfindlay) ssh_known_hosts.present state: catch not found
     exc

   * PR  #29196:  (s0undt3ch)  We  need  novaclient  imported  to  compare
     versions

   * PR #29059: (terminalmage) Work around upstream pygit2 bug

   * PR    #29112:    (eliasp)    Prevent    backtrace    (KeyError)    in
     ssh_known_hosts.present state

   * PR   #29178:   (whytewolf)    Profile    not    being    passed    to
     keystone.endpoint_get in _auth. so if a p...

   Salt 2015.8.5 Release Notes
      About this Release

             Salt  2015.8.5  is identical to the 2015.8.4 release with the
             addition of a fix for issue 30820, fixed by  PR  #30833.  For
             convenience,  the  content from the 2015.8.4 release notes is
             included below.

   Known Issue in boto_* execution modules
   This release contains an issue that causes the boto_* execution modules
   to  display a __salt__ not defined error (issue 30300). This issue will
   be fixed in an upcoming  release,  but  can  be  manually  resolved  by
   completing the following:

   1. Download  the boto_* execution modules that you would like to update
      from the 2015.8 branch of Salt. A complete list of affected  modules
      with the specific changes is available in PR #30867.

      A simple way to get the updated modules is to download a zip file of
      the 2015.8 branch from  GitHub.  The  updated  modules  are  in  the
      salt\modules directory.

   2. Copy  the boto_* modules to the \srv\salt\_modules directory on your
      Salt master.

   3. Run the following command to sync these modules to all Salt minions:

         salt '*' saltutil.sync_modules

                                    ----

   2015.8.4 Release Notes

   Security Fix
   CVE-2016-1866: Improper handling of clear messages on the minion, which
   could result in executing commands not sent by the master.

   This  issue affects only the 2015.8.x releases of Salt. In order for an
   attacker to use this attack  vector,  they  would  have  to  execute  a
   successful  attack  on  an  existing  TCP connection between minion and
   master on the pub port. It does  not  allow  an  external  attacker  to
   obtain  the  shared  secret  or  decrypt  any encrypted traffic between
   minion and master. Thank you to  Sebastian  Krahmer  <[email protected]>
   for bringing this issue to our attention.

   We recommend everyone upgrade to 2015.8.4 as soon as possible.

   Core Changes
   * PR  #28994:  timcharper  Salt S3 module has learned how to assume IAM
     roles

   * Added option  mock=True  for  state.sls  and  state.highstate.   This
     allows  the  salt  state  compiler to process sls data in a state run
     without actually calling the state functions, thus providing feedback
     on  the  validity  of the arguments used for the functions beyond the
     preprocessing validation provided by state.show_sls (issue 30118  and
     issue 30189).

        salt '*' state.sls core,edit.vim mock=True
        salt '*' state.highstate mock=True
        salt '*' state.apply edit.vim mock=True

   Changes for v2015.8.3..v2015.8.4
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-01-25T17:48:35Z

   Total Merges: 320

   Changes:

   * PR #30613: (basepi) Fix minion/syndic clearfuncs

   * PR #30609: (seanjnkns) Fix documentation for pillar_merge_lists which
     default is False, not ...

   * PR  #30584:  (julianbrost)  file.line  state:  add  missing  colon in
     docstring

   * PR #30589: (terminalmage) Merge 2015.5 into 2015.8

   * PR #30599: (multani) Documentation formatting fixes

   * PR #30554:  (rallytime)  Make  the  salt-cloud  actions  output  more
     verbose and helpful

   * PR #30549: (techhat) Salt Virt cleanup

   * PR #30553: (techhat) AWS: Support 17-character IDs

   * PR #30532: (whiteinge) Add execution module for working in sls files

   * PR #30529: (terminalmage) Merge 2015.5 into 2015.8

   * PR  #30526:  (twangboy)  Added FlushKey to make sure it's changes are
     saved to disk

   * PR #30521: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30485: (jtand) Updated pip_state to work with pip 8.0 on 2015.8

   * PR #30494: (isbm) Zypper: info_installed --- 'errors'  flag  change  to
     type 'boolean'

   * PR  #30506:  (jacksontj)  Properly  remove newlines after reading the
     file

   * PR #30508: (rallytime) Fix Linode driver cloning functionality

   * PR #30522: (terminalmage) Update git.list_worktree tests  to  reflect
     new return data

   * PR  #30483:  (borgstrom)  Pyobjects  recursive  import  support  (for
     2015.8)

   * PR #30491: (jacksontj) Add multi-IP support to network state

   * PR #30496: (anlutro) Fix KeyError when adding ignored pillars

   * PR #30359: (kingsquirrel152) Removes suspected copy/paste  error  for
     zmq_filtering functionailty

   * PR #30448: (cournape) Fix osx scripts location

   * PR #30457: (rallytime) Remove fsutils references from modules list

   * PR  #30453:  (rallytime)  Make sure private AND public IPs are listed
     for Linode driver

   * PR #30458: (rallytime) Back-port #30062 to 2015.8

   * PR #30468: (timcharper) make note of s3 role assumption  in  upcoming
     changelog

   * PR  #30470:  (whiteinge)  Add  example  of  the  match_dict format to
     accept_dict wheel function

   * PR #30450: (gtmanfred) fix extension loading in novaclient

   * PR #30212: (abednarik) Fix incorrect file permissions in file.line

   * PR #29947: (jfindlay) fileclient: decode file list from master

   * PR #30363: (terminalmage) Use native "list" subcommand  to  list  git
     worktrees

   * PR #30445: (jtand) Boto uses False for is_default instead of None

   * PR    #30406:    (frioux)    Add   an   example   of   how   to   use
     file.managed/check_cmd

   * PR #30424: (isbm) Check if byte strings are properly encoded in UTF-8

   * PR #30405: (jtand) Updated glusterfs.py for python2.6 compatibility.

   * PR #30396: (pass-by-value) Remove hardcoded val

   * PR #30391: (jtand) Added else statements

   * PR #30375: (rallytime) Wrap formatted log statements with six.u()  in
     cloud/__init__.py

   * PR  #30384:  (isbm) Bugfix: info_available does not work correctly on
     SLE 11 series

   * PR #30376: (pritambaral) Fix FLO_DIR path in 2015.8

   * PR #30389: (jtand) Older versions of ipset don't support comments

   * PR #30373: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30372: (jacobhammons) Updated man  pages  for  2015.8.4,  updated
     copyright to 2016

   * PR #30370: (rallytime) Remove incomplete function

   * PR #30366: (rallytime) Back-port #28702 to 2015.8

   * PR  #30361: (cro) Flip the sense of the test for proxymodule imports,
     add more fns for esxi proxy

   * PR #30267: (isbm) Fix RPM issues with the date/time and  add  package
     attributes filtering

   * PR #30360: (jfindlay) file.remove, file.absent: mention recursive dir
     removal

   * PR #30221: (mbarrien) No rolcatupdate for user_exist in Postgres>=9.5
     `#26845`_

   * PR #30358: (terminalmage) Add libgit2 version to versions-report

   * PR #30346: (pass-by-value) Prevent orphaned volumes

   * PR #30349: (rallytime) Back-port #30347 to 2015.8

   * PR #30354: (anlutro) Make sure all ignore_missing SLSes are caught

   * PR #30356: (nmadhok) Adding code author

   * PR #30340: (jtand) Updated seed_test.py  for  changes  made  to  seed
     module

   * PR #30339: (jfindlay) Backport #26511

   * PR #30343: (rallytime) Fix 2015.8 from incomplete back-port

   * PR #30342: (eliasp) Correct whitespace placement in error message

   * PR #30308: (rallytime) Back-port #30257 to 2015.8

   * PR #30187: (rallytime) Back-port #27606 to 2015.8

   * PR #30223: (serge-p) adding support for DragonFly BSD

   * PR #30238: (rallytime) Reinit crypto before calling RSA.generate when
     generating keys.

   * PR #30246: (dmacvicar) Add missing return data to scheduled jobs (
     `#24237`_
     )

   * PR #30292: (thegoodduke) ipset: fix test=true & add comment for every
     entry

   * PR #30275: (abednarik) Add permanent argument in firewalld.

   * PR #30328: (cachedout) Fix file test

   * PR #30310: (pass-by-value) Empty bucket fix

   * PR #30211: (techhat) Execute choot on the correct path

   * PR #30309: (rallytime) Back-port #30304 to 2015.8

   * PR  #30278:  (nmadhok) If datacenter is specified in the config, then
     look for managed objects under it

   * PR #30305: (jacobhammons) Changed examples to use  the  "example.com"
     domain instead of "mycompan...

   * PR  #30249:  (mpreziuso)  Fixes  performance  and  timeout  issues on
     win_pkg.install

   * PR #30217: (pass-by-value) Make sure cloud actions can be called  via
     salt run

   * PR  #30268:  (terminalmage)  Optimize file_tree ext_pillar and update
     file.managed to allow for binary contents

   * PR #30245:  (rallytime)  Boto  secgroup/iam_role:  Add  note  stating
     us-east-1 is default region

   * PR  #30299:  (rallytime)  ESXi  Proxy  minions  states are located at
     salt.states.esxi, not vsphere.

   * PR #30202: (opdude) Fixed the periodic call to beacons

   * PR #30303: (jacobhammons) Changed notes to  indicate  that  functions
     are matched using regular ex...

   * PR #30284: (terminalmage) salt.utils.gitfs: Fix Dulwich env detection
     and submodule handling

   * PR #30280: (jfindlay) add state mocking to release notes

   * PR #30273: (rallytime) Back-port #30121 to 2015.8

   * PR #30301: (cachedout) Accept whatever comes into hightstate mock for
     state tests

   * PR #30282: (cachedout) Fix file.append logic

   * PR #30289: (cro) Fix problems with targeting proxies by grains

   * PR #30293: (cro) Ensure we don't log stuff we shouldn't

   * PR #30279: (cachedout) Allow modules to be packed into boto utils

   * PR  #30186:  (rallytime)  Update  CLI  Examples in boto_ec2 module to
     reflect correct arg/kwarg positioning

   * PR   #30156:   (abednarik)   Add    option    in    file.append    to
     ignore_whitespace.

   * PR #30189: (rallytime) Back-port #30185 to 2015.8

   * PR #30215: (jacobhammons) Assorted doc bug fixes

   * PR  #30206:  (cachedout)  Revert  "Fix  incorrect file permissions in
     file.line"

   * PR #30190: (jacobhammons) Updated doc site banners

   * PR #30180: (jfindlay) modules.x509._dec2hex: add fmt  index  for  2.6
     compat

   * PR #30179: (terminalmage) Backport #26962 to 2015.8 branch

   * PR #29693: (abednarik) Handle missing source file in ssh_auth.

   * PR #30155: (rallytime) Update boto_secgroup and boto_iam_role docs to
     only use region OR profile

   * PR    #30158:    (rallytime)    Move    _option(value)    calls    to
     __salt__['config.option'] in boto utils

   * PR #30160: (dmurphy18) Fix parsing disk usage for line with no number
     and AIX values in Kilos

   * PR #30162: (rallytime) Update list_present and  append  grains  state
     function docs to be more clear.

   * PR  #30163:  (rallytime)  Add  warning  about  using "=" in file.line
     function

   * PR #30164: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30168: (abednarik) Fix incorrect file permissions in file.line

   * PR #30154: (Oro) Fix file serialize on windows

   * PR #30144: (rallytime) Added generic ESXCLI command ability  to  ESXi
     Proxy Minion

   * PR  #30142:  (terminalmage) Fix dockerng.push, and allow for multiple
     images

   * PR #30075: (joejulian) Convert glusterfs module to use xml

   * PR #30129: (optix2000) Clean up _uptodate() in git state

   * PR #30139: (rallytime) Back-port #29589 to 2015.8

   * PR #30124: (abednarik) Update regex to detect ip alias in OpenBSD.

   * PR #30133: (stanislavb) Fix typo in gpgkey URL

   * PR #30126: (stanislavb) Log S3 API error message

   * PR #30128: (oeuftete) Log retryable transport errors as warnings

   * PR #30096: (cachedout) Add rm_special to crontab module

   * PR #30106: (techhat) Ensure last dir

   * PR #30101: (gtmanfred) fix  bug  where  nova  driver  exits  with  no
     adminPass

   * PR #30090: (techhat) Add argument to isdir()

   * PR #30094: (rallytime) Fix doc formatting for cloud.create example in
     module.py state

   * PR #30095: (rallytime) Add the list_nodes_select function  to  linode
     driver

   * PR #30082: (abednarik) Fixed saltversioninfo grain return

   * PR #30084: (rallytime) Back-port #29987 to 2015.8

   * PR #30071: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR      #30067:      (ryan-lane)      Pass      in      kwargs     to
     boto_secgroup.convert_to_group_ids explicitly

   * PR #30069: (techhat) Ensure that pki_dir exists

   * PR #30064: (rallytime) Add Syndic documentation to miscellaneous Salt
     Cloud config options

   * PR  #30049:  (rallytime)  Add  some  more  unit tests for the vsphere
     execution module

   * PR #30060: (rallytime) Back-port #27104 to 2015.8

   * PR #30048: (jacobhammons) Remove  internal  APIs  from  rest_cherrypy
     docs.

   * PR   #30043:   (rallytime)   Be   explicit   about   importing   from
     salt.utils.jinja to avoid circular imports

   * PR #30038: (rallytime) Back-port #30017 to 2015.8

   * PR #30036: (rallytime) Back-port #29995 to 2015.8

   * PR #30035: (rallytime) Back-port #29895 to 2015.8

   * PR #30034: (rallytime) Back-port #29893 to 2015.8

   * PR #30033: (rallytime) Back-port #29876 to 2015.8

   * PR #30029: (terminalmage) git.latest:  Fix  handling  of  nonexistent
     branches

   * PR #30016: (anlutro) Properly normalize locales in locale.gen_locale

   * PR #30015: (anlutro) locale module: don't escape the slash in \n

   * PR #30022: (gqgunhed) Two minor typos fixed

   * PR #30026: (anlutro) states.at: fix wrong variable being used

   * PR   #29966:   (multani)   Fix  bigip  state/module  documentation  +
     serializers documentation

   * PR #29904: (twangboy) Improvements to osx packaging scripts

   * PR #29950: (multani) boto_iam: fix deletion of IAM users  when  using
     delete_keys=true

   * PR #29937: (multani) Fix states.boto_iam group users

   * PR #29934: (multani) Fix state.boto_iam virtual name

   * PR #29943: (cachedout) Check args correctly in boto_rds

   * PR #29924: (gqgunhed) fixed: uptime now working on non-US Windows

   * PR #29883: (serge-p) fix for nfs mounts in _active_mounts_openbsd()

   * PR #29894: (techhat) Support Saltfile in SPM

   * PR  #29856:  (rallytime)  Added  some  initial  unit  tests  for  the
     salt.modules.vsphere.py file

   * PR #29855: (rallytime) Back-port #29740 to 2015.8

   * PR #29890: (multani) Various documentation fixes

   * PR #29850: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29811: (anlutro) influxdb: add retention policy module functions

   * PR #29814: (basepi) [2015.8][Windows] Fix multi-master on windows

   * PR #29819: (rallytime) Add esxi module and state to docs build

   * PR #29832: (jleimbach) Fixed typo in order to use the keyboard module
     for RHEL without systemd

   * PR #29803: (rallytime) Add vSphere module to doc ref module tree

   * PR #29767: (abednarik) Hosts file update in mod_hostname.

   * PR  #29772:  (terminalmage)  pygit2:  skip submodules when traversing
     tree

   * PR #29765: (gtmanfred) allow nova driver to be boot from volume

   * PR #29773: (l2ol33rt) Append  missing  wget  in  debian  installation
     guide

   * PR #29800: (rallytime) Back-port #29769 to 2015.8

   * PR  #29775:  (paulnivin) Change listen requisite resolution from name
     to ID declaration

   * PR #29754: (rallytime) Back-port #29719 to 2015.8

   * PR #29713: (The-Loeki) Pillar-based cloud providers still forcing use
     of deprecated 'provider'

   * PR   #29729:  (rallytime)  Further  clarifications  on  "unless"  and
     "onlyif" requisites.

   * PR #29737: (akissa) fix pillar sqlite3 documentation examples

   * PR #29743: (akissa) fix pillar sqlite not honouring config options

   * PR #29723: (rallytime) Clarify db_user  and  db_password  kwargs  for
     postgres_user.present state function

   * PR  #29722:  (rallytime) Link "stateful" kwargs to definition of what
     "stateful" means for cmd state.

   * PR #29724: (rallytime) Add examples of using multiple matching levels
     to Pillar docs

   * PR #29726: (cachedout) Disable some boto tests per resolution of moto
     issue

   * PR #29708: (lagesag) Fix test=True for  file.directory  with  recurse
     ignore_files/ignore_dirs.

   * PR  #29642:  (cachedout)  Correctly  restart  deamonized  minions  on
     failure

   * PR #29599: (cachedout) Clean up minion shutdown

   * PR #29675: (clinta) allow returning all refs

   * PR #29683: (rallytime) Catch more specific error to  pass  the  error
     message through elegantly.

   * PR #29687: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29681: (clinta) fix bare/mirror in git.latest

   * PR #29644: (rallytime) Fixed a couple more ESXi proxy minion bugs

   * PR #29645: (rallytime) Back-port #29558 to 2015.8

   * PR  #29632:  (jfindlay)  reduce  severity  of  tls module __virtual__
     logging

   * PR #29606: (abednarik) Fixed duplicate mtu entry in RedHat 7  network
     configuration.

   * PR #29613: (rallytime) Various ESXi Proxy Minion Bug Fixes

   * PR #29628: (DmitryKuzmenko) Don't create io_loop before fork

   * PR  #29609:  (basepi)  [2015.8][salt-ssh] Add ability to set salt-ssh
     command umask in roster

   * PR #29603: (basepi) Fix orchestration failure-checking

   * PR  #29597:  (terminalmage)  dockerng:  Prevent  exception  when  API
     response contains empty dictionary

   * PR #29596: (rallytime) Back-port #29587 to 2015.8

   * PR #29588: (rallytime) Added ESXi Proxy Minion Tutorial

   * PR   #29572:   (gtmanfred)  [nova]  use  old  discover_extensions  if
     available

   * PR #29545: (terminalmage) git.latest:  init  submodules  if  not  yet
     initialized

   * PR #29548: (rallytime) Back-port #29449 to 2015.8

   * PR  #29547: (rallytime) Refactored ESXCLI-based functions to accept a
     list of esxi_hosts

   * PR  #29563:  (anlutro)  Fix  a   call   to   deprecated   method   in
     python-influxdb

   * PR #29565: (bdrung) Fix typos and missing release note

   * PR #29540: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29499: (rallytime) Initial commit of ESXi Proxy Minion

   * PR  #29526:  (jfindlay)  2015.8.2  notes:  add  note  about not being
     released

   * PR #29531: (jfindlay) grains.core: handle undefined variable

   * PR #29538: (basepi) [2015.8] [salt-ssh] Remove  umask  around  actual
     execution for salt-ssh

   * PR  #29505:  (rallytime)  Update boto_rds state docs to include funky
     yaml syntax for "tags" option.

   * PR #29513: (bdrung) Drop obsolete syslog.target from systemd services

   * PR #29500: (rallytime) Back-port #29467 to 2015.8

   * PR #29463: (abednarik) Add
     **
     kwargs to debconf.set.

   * PR #29399: (jfindlay) modules.status: add  human_readable  option  to
     uptime

   * PR #29433: (cro) Files for building .pkg files for MacOS X

   * PR #29455: (jfindlay) modules.nova.__init__: do not return None

   * PR  #29454:  (jfindlay)  rh_service  module  __virtual__ return error
     messages

   * PR  #29476:  (tbaker57)   Doc   fix   -   route_table_present   needs
     subnet_names (not subnets) as a key

   * PR #29487: (rallytime) Back-port #29450 to 2015.8

   * PR  #29441:  (rallytime)  Make  sure  docs  line  up with blade_idrac
     function specs

   * PR #29440: (rallytime) Back-port #28925 to 2015.8

   * PR #29435: (galet) Grains  return  wrong  OS  version  and  other  OS
     related values for Oracle Linux

   * PR #29430: (rall0r) Fix host.present state limitation

   * PR #29417: (jacobhammons) Repo install updates

   * PR #29402: (techhat) Add rate limiting to linode

   * PR #29400: (twangboy) Fix #19332

   * PR #29398: (cachedout) Lint 29288

   * PR #29331: (DmitryKuzmenko) Bugfix - #29116 raet dns error

   * PR #29390: (jacobhammons) updated version numbers in documentation

   * PR #29381: (nmadhok) No need to deepcopy since six.iterkeys() creates
     a copy

   * PR #29349: (cro) Fix mis-setting chassis names

   * PR #29334: (rallytime) Back-port #29237 to 2015.8

   * PR #29300: (ticosax) [dockerng] Add support for volume management  in
     dockerng

   * PR #29218: (clan) check service enable state in test mode

   * PR #29315: (jfindlay) dev tutorial doc: fix markup errors

   * PR #29317: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29240: (clan) handle acl_type [[d]efault:][user|group|mask|other]

   * PR #29305: (lorengordon) Add 'file' as a source_hash proto

   * PR  #29272:  (jfindlay)  win_status  module:  handle  12 hour time in
     uptime

   * PR #29289: (terminalmage) file.managed: Allow local file  sources  to
     use source_hash

   * PR  #29264:  (anlutro)  Prevent  ssh_auth.absent  from  running  when
     test=True

   * PR #29277: (terminalmage) Update git_pillar runner to support new git
     ext_pillar config schema

   * PR #29283: (cachedout) Single-quotes and use format

   * PR  #29139: (thomaso-mirodin) [salt-ssh] Add a range roster and range
     targeting options for the flat roster

   * PR #29282: (cachedout) dev docs: add development tutorial

   * PR #28994: (timcharper) add support to s3 for aws role assumption

   * PR #29278: (techhat) Add verify_log to SPM

   * PR #29067: (jacksontj) Fix infinite recursion in state  compiler  for
     prereq of SLSs

   * PR #29207: (jfindlay) do not shadow ret function argument

   * PR #29215: (rallytime) Back-port #29192 to 2015.8

   * PR #29217: (clan) show duration only if state_output_profile is False

   * PR #29221: (ticosax) [dokcerng] Docu network mode

   * PR #29269: (jfindlay) win_status module: fix function names in docs

   * PR  #29213: (rallytime) Move _wait_for_task func from vmware cloud to
     vmware utils

   * PR #29271: (techhat) Pass full path for digest (SPM)

   * PR #29244: (isbm) List products consistently across all SLES systems

   * PR #29255: (garethgreenaway) fixes to consul module

   * PR #29208: (whytewolf) Glance more profile errors

   * PR #29200: (jfindlay) mount state: unmount by device is optional

   * PR #29205: (trevor-h) Fixes #29187 - using winrm on EC2

   * PR #29170: (cachedout) Migrate pydsl tests to integration test suite

   * PR #29198: (jfindlay) rh_ip module: only set the mtu once

   * PR #29135: (jfindlay) ssh_known_hosts.present state: catch not  found
     exc

   * PR  #29196:  (s0undt3ch)  We  need  novaclient  imported  to  compare
     versions

   * PR #29059: (terminalmage) Work around upstream pygit2 bug

   * PR    #29112:    (eliasp)    Prevent    backtrace    (KeyError)    in
     ssh_known_hosts.present state

   * PR    #29178:    (whytewolf)    Profile    not    being   passed   to
     keystone.endpoint_get in _auth. so if a p...

   Salt 2015.8.7 Release Notes
   NOTE:
      Salt 2015.8.4, 2015.8.5, and 2015.8.7 were  all  released  within  a
      short  period  due  to  regressions found soon after the releases of
      2015.8.4 and 2015.8.5.  These  release  notes  contain  all  of  the
      changes  since 2015.8.3 to make it easier to see everything that has
      changed recently.

   Changes for v2015.8.4..v2015.8.7
   For pkg.installed states, on Linux  distributions  which  use  yum/dnf,
   packages  which have a non-zero epoch in the version number now require
   this epoch to be included  when  specifying  an  exact  version  for  a
   package. For example:

      vim-enhanced:
        pkg.installed:
          - version: 2:7.4.160-1.el7

   The  pkg.latest_version and pkg.list_repo_pkgs functions can be used to
   get the correct version string to use, as they  will  now  contain  the
   epoch when it is non-zero.

   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-02-11T22:13:51Z

   Statistics:

   * Total Merges: 2

   * Total Issue references: 0

   * Total PR references: 3

   Changes:

   * PR  #31111:  (jtand)   Fixes   failing   npm   test   on   arch.    @
     2016-02-10T21:51:47Z

     * 8d84c63 Merge pull request #31111 from jtand/8_4_npm_fix

     * b0a48e5 Fixes failing npm test on arch.

     * 733c6ab  Some  3rd-party  modules  (e.g.  gnupg)  define custom log
       levels that emit at INFO level and  above.   This  patch  sets  the
       color  data  lookups  to default to TextFormat('reset') rather than
       producing a stack trace every time a log message is generated  from
       an affected module.

     * 3f71fd0 Revert #30217

       * PR  #30217: (pass-by-value) Make sure cloud actions can be called
         via salt run

   * PR #31092: (terminalmage) Apply PR  #31031  to  2015.8.4.follow_up  @
     2016-02-10T20:54:37Z

     * 5a6a93e       Merge       pull       request       #31092      from
       terminalmage/issue31014-2015.8.4.follow_up * 2767a4e  Don't  handle
       epoch specially for dnf

       * e5dfcc0 More efficient way to add the epoch before version number

       * ed74627 include possible epoch in version for rpm

     * 6c6b66a Comment multiprocessing line in minion config

     * 1f7dfef Set multiprocessing to true in config.py

     * 433c645 Fix remove placeholder files

     * 7103756 Remove placeholder files

     * 20b381f Set overwrite to off

     * ca50f56 Fix boto_secgroup

     * fd571d2 Fix boto test failures

     * cfb6588  Fix  regression  when contents_pillar/contents_grains is a
       list.

     * 881d866 utils.aws: use time lib to conver to epoch seconds

     * 3141292 The call to cp.get_url needs the saltenv, if  you're  using
       environments other than base, it will fail.

     * a869401  Fix  regression  in  git_pillar  when multiple remotes are
       configured

     * 2243f25 Properly set the default value for pillar_merge_lists

     * c7472ff Lint

     * d868711 Fix failing boto_vpc module unit tests

     * ed09516 Fix failing state module tests

     * fd0e940 Pylint fix

     * bc780a7 Don't use pack=pack. Just pass in pack=__salt__ always.

     * 1ae022d Pass in 'pack' variable to utils.boto.assign_funcs function
       from ALL boto modules.

     * 1efaff1 Remove bad symlinks in osx pkg dirs

     * c7db435 Fix regression in scanning for state with 'name' param

                                    ----

   Security Fix
   CVE-2016-1866: Improper handling of clear messages on the minion, which
   could result in executing commands not sent by the master.

   This issue affects only the 2015.8.x releases of Salt. In order for  an
   attacker  to  use  this  attack  vector,  they  would have to execute a
   successful attack on an existing  TCP  connection  between  minion  and
   master  on  the  pub  port.  It  does not allow an external attacker to
   obtain the shared secret  or  decrypt  any  encrypted  traffic  between
   minion  and  master.  Thank you to Sebastian Krahmer <[email protected]>
   for bringing this issue to our attention.

   We recommend everyone upgrade to 2015.8.4 as soon as possible.

   Core Changes
   * PR #28994: timcharper Salt S3 module has learned how  to  assume  IAM
     roles

   * Added  option  mock=True  for  state.sls  and  state.highstate.  This
     allows the salt state compiler to process sls data  in  a  state  run
     without actually calling the state functions, thus providing feedback
     on the validity of the arguments used for the  functions  beyond  the
     preprocessing  validation provided by state.show_sls (issue 30118 and
     issue 30189).

        salt '*' state.sls core,edit.vim mock=True
        salt '*' state.highstate mock=True
        salt '*' state.apply edit.vim mock=True

   Changes for v2015.8.3..v2015.8.4
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-01-25T17:48:35Z

   Total Merges: 320

   Changes:

   * PR #30613: (basepi) Fix minion/syndic clearfuncs

   * PR #30609: (seanjnkns) Fix documentation for pillar_merge_lists which
     default is False, not ...

   * PR #30584:  (julianbrost)  file.line  state:  add  missing  colon  in
     docstring

   * PR #30589: (terminalmage) Merge 2015.5 into 2015.8

   * PR #30599: (multani) Documentation formatting fixes

   * PR  #30554:  (rallytime)  Make  the  salt-cloud  actions  output more
     verbose and helpful

   * PR #30549: (techhat) Salt Virt cleanup

   * PR #30553: (techhat) AWS: Support 17-character IDs

   * PR #30532: (whiteinge) Add execution module for working in sls files

   * PR #30529: (terminalmage) Merge 2015.5 into 2015.8

   * PR #30526: (twangboy) Added FlushKey to make sure  it's  changes  are
     saved to disk

   * PR #30521: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30485: (jtand) Updated pip_state to work with pip 8.0 on 2015.8

   * PR  #30494:  (isbm)  Zypper: info_installed --- 'errors' flag change to
     type 'boolean'

   * PR #30506: (jacksontj) Properly remove  newlines  after  reading  the
     file

   * PR #30508: (rallytime) Fix Linode driver cloning functionality

   * PR  #30522:  (terminalmage) Update git.list_worktree tests to reflect
     new return data

   * PR  #30483:  (borgstrom)  Pyobjects  recursive  import  support  (for
     2015.8)

   * PR #30491: (jacksontj) Add multi-IP support to network state

   * PR #30496: (anlutro) Fix KeyError when adding ignored pillars

   * PR  #30359:  (kingsquirrel152) Removes suspected copy/paste error for
     zmq_filtering functionailty

   * PR #30448: (cournape) Fix osx scripts location

   * PR #30457: (rallytime) Remove fsutils references from modules list

   * PR #30453: (rallytime) Make sure private AND public  IPs  are  listed
     for Linode driver

   * PR #30458: (rallytime) Back-port #30062 to 2015.8

   * PR  #30468:  (timcharper) make note of s3 role assumption in upcoming
     changelog

   * PR #30470: (whiteinge)  Add  example  of  the  match_dict  format  to
     accept_dict wheel function

   * PR #30450: (gtmanfred) fix extension loading in novaclient

   * PR #30212: (abednarik) Fix incorrect file permissions in file.line

   * PR #29947: (jfindlay) fileclient: decode file list from master

   * PR  #30363:  (terminalmage)  Use native "list" subcommand to list git
     worktrees

   * PR #30445: (jtand) Boto uses False for is_default instead of None

   * PR   #30406:   (frioux)   Add   an   example   of    how    to    use
     file.managed/check_cmd

   * PR #30424: (isbm) Check if byte strings are properly encoded in UTF-8

   * PR #30405: (jtand) Updated glusterfs.py for python2.6 compatibility.

   * PR #30396: (pass-by-value) Remove hardcoded val

   * PR #30391: (jtand) Added else statements

   * PR  #30375: (rallytime) Wrap formatted log statements with six.u() in
     cloud/__init__.py

   * PR #30384: (isbm) Bugfix: info_available does not work  correctly  on
     SLE 11 series

   * PR #30376: (pritambaral) Fix FLO_DIR path in 2015.8

   * PR #30389: (jtand) Older versions of ipset don't support comments

   * PR #30373: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #30372:  (jacobhammons)  Updated  man pages for 2015.8.4, updated
     copyright to 2016

   * PR #30370: (rallytime) Remove incomplete function

   * PR #30366: (rallytime) Back-port #28702 to 2015.8

   * PR #30361: (cro) Flip the sense of the test for proxymodule  imports,
     add more fns for esxi proxy

   * PR  #30267:  (isbm) Fix RPM issues with the date/time and add package
     attributes filtering

   * PR #30360: (jfindlay) file.remove, file.absent: mention recursive dir
     removal

   * PR #30221: (mbarrien) No rolcatupdate for user_exist in Postgres>=9.5
     `#26845`_

   * PR #30358: (terminalmage) Add libgit2 version to versions-report

   * PR #30346: (pass-by-value) Prevent orphaned volumes

   * PR #30349: (rallytime) Back-port #30347 to 2015.8

   * PR #30354: (anlutro) Make sure all ignore_missing SLSes are caught

   * PR #30356: (nmadhok) Adding code author

   * PR  #30340:  (jtand)  Updated  seed_test.py  for changes made to seed
     module

   * PR #30339: (jfindlay) Backport #26511

   * PR #30343: (rallytime) Fix 2015.8 from incomplete back-port

   * PR #30342: (eliasp) Correct whitespace placement in error message

   * PR #30308: (rallytime) Back-port #30257 to 2015.8

   * PR #30187: (rallytime) Back-port #27606 to 2015.8

   * PR #30223: (serge-p) adding support for DragonFly BSD

   * PR #30238: (rallytime) Reinit crypto before calling RSA.generate when
     generating keys.

   * PR #30246: (dmacvicar) Add missing return data to scheduled jobs (
     `#24237`_
     )

   * PR #30292: (thegoodduke) ipset: fix test=true & add comment for every
     entry

   * PR #30275: (abednarik) Add permanent argument in firewalld.

   * PR #30328: (cachedout) Fix file test

   * PR #30310: (pass-by-value) Empty bucket fix

   * PR #30211: (techhat) Execute choot on the correct path

   * PR #30309: (rallytime) Back-port #30304 to 2015.8

   * PR #30278: (nmadhok) If datacenter is specified in the  config,  then
     look for managed objects under it

   * PR  #30305:  (jacobhammons) Changed examples to use the "example.com"
     domain instead of "mycompan...

   * PR #30249:  (mpreziuso)  Fixes  performance  and  timeout  issues  on
     win_pkg.install

   * PR  #30217: (pass-by-value) Make sure cloud actions can be called via
     salt run

   * PR #30268: (terminalmage) Optimize file_tree  ext_pillar  and  update
     file.managed to allow for binary contents

   * PR  #30245:  (rallytime)  Boto  secgroup/iam_role:  Add  note stating
     us-east-1 is default region

   * PR #30299: (rallytime) ESXi  Proxy  minions  states  are  located  at
     salt.states.esxi, not vsphere.

   * PR #30202: (opdude) Fixed the periodic call to beacons

   * PR  #30303:  (jacobhammons)  Changed notes to indicate that functions
     are matched using regular ex...

   * PR #30284: (terminalmage) salt.utils.gitfs: Fix Dulwich env detection
     and submodule handling

   * PR #30280: (jfindlay) add state mocking to release notes

   * PR #30273: (rallytime) Back-port #30121 to 2015.8

   * PR #30301: (cachedout) Accept whatever comes into hightstate mock for
     state tests

   * PR #30282: (cachedout) Fix file.append logic

   * PR #30289: (cro) Fix problems with targeting proxies by grains

   * PR #30293: (cro) Ensure we don't log stuff we shouldn't

   * PR #30279: (cachedout) Allow modules to be packed into boto utils

   * PR #30186: (rallytime) Update CLI  Examples  in  boto_ec2  module  to
     reflect correct arg/kwarg positioning

   * PR    #30156:    (abednarik)    Add    option   in   file.append   to
     ignore_whitespace.

   * PR #30189: (rallytime) Back-port #30185 to 2015.8

   * PR #30215: (jacobhammons) Assorted doc bug fixes

   * PR #30206: (cachedout) Revert  "Fix  incorrect  file  permissions  in
     file.line"

   * PR #30190: (jacobhammons) Updated doc site banners

   * PR  #30180:  (jfindlay)  modules.x509._dec2hex: add fmt index for 2.6
     compat

   * PR #30179: (terminalmage) Backport #26962 to 2015.8 branch

   * PR #29693: (abednarik) Handle missing source file in ssh_auth.

   * PR #30155: (rallytime) Update boto_secgroup and boto_iam_role docs to
     only use region OR profile

   * PR    #30158:    (rallytime)    Move    _option(value)    calls    to
     __salt__['config.option'] in boto utils

   * PR #30160: (dmurphy18) Fix parsing disk usage for line with no number
     and AIX values in Kilos

   * PR  #30162:  (rallytime)  Update list_present and append grains state
     function docs to be more clear.

   * PR #30163: (rallytime) Add  warning  about  using  "="  in  file.line
     function

   * PR #30164: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30168: (abednarik) Fix incorrect file permissions in file.line

   * PR #30154: (Oro) Fix file serialize on windows

   * PR  #30144:  (rallytime) Added generic ESXCLI command ability to ESXi
     Proxy Minion

   * PR #30142: (terminalmage) Fix dockerng.push, and allow  for  multiple
     images

   * PR #30075: (joejulian) Convert glusterfs module to use xml

   * PR #30129: (optix2000) Clean up _uptodate() in git state

   * PR #30139: (rallytime) Back-port #29589 to 2015.8

   * PR #30124: (abednarik) Update regex to detect ip alias in OpenBSD.

   * PR #30133: (stanislavb) Fix typo in gpgkey URL

   * PR #30126: (stanislavb) Log S3 API error message

   * PR #30128: (oeuftete) Log retryable transport errors as warnings

   * PR #30096: (cachedout) Add rm_special to crontab module

   * PR #30106: (techhat) Ensure last dir

   * PR  #30101:  (gtmanfred)  fix  bug  where  nova  driver exits with no
     adminPass

   * PR #30090: (techhat) Add argument to isdir()

   * PR #30094: (rallytime) Fix doc formatting for cloud.create example in
     module.py state

   * PR  #30095:  (rallytime) Add the list_nodes_select function to linode
     driver

   * PR #30082: (abednarik) Fixed saltversioninfo grain return

   * PR #30084: (rallytime) Back-port #29987 to 2015.8

   * PR #30071: (rallytime) Merge branch '2015.5' into '2015.8'

   * PR     #30067:      (ryan-lane)      Pass      in      kwargs      to
     boto_secgroup.convert_to_group_ids explicitly

   * PR #30069: (techhat) Ensure that pki_dir exists

   * PR #30064: (rallytime) Add Syndic documentation to miscellaneous Salt
     Cloud config options

   * PR #30049: (rallytime) Add some  more  unit  tests  for  the  vsphere
     execution module

   * PR #30060: (rallytime) Back-port #27104 to 2015.8

   * PR  #30048:  (jacobhammons)  Remove  internal APIs from rest_cherrypy
     docs.

   * PR   #30043:   (rallytime)   Be   explicit   about   importing   from
     salt.utils.jinja to avoid circular imports

   * PR #30038: (rallytime) Back-port #30017 to 2015.8

   * PR #30036: (rallytime) Back-port #29995 to 2015.8

   * PR #30035: (rallytime) Back-port #29895 to 2015.8

   * PR #30034: (rallytime) Back-port #29893 to 2015.8

   * PR #30033: (rallytime) Back-port #29876 to 2015.8

   * PR  #30029:  (terminalmage)  git.latest:  Fix handling of nonexistent
     branches

   * PR #30016: (anlutro) Properly normalize locales in locale.gen_locale

   * PR #30015: (anlutro) locale module: don't escape the slash in \n

   * PR #30022: (gqgunhed) Two minor typos fixed

   * PR #30026: (anlutro) states.at: fix wrong variable being used

   * PR  #29966:  (multani)  Fix  bigip   state/module   documentation   +
     serializers documentation

   * PR #29904: (twangboy) Improvements to osx packaging scripts

   * PR  #29950:  (multani) boto_iam: fix deletion of IAM users when using
     delete_keys=true

   * PR #29937: (multani) Fix states.boto_iam group users

   * PR #29934: (multani) Fix state.boto_iam virtual name

   * PR #29943: (cachedout) Check args correctly in boto_rds

   * PR #29924: (gqgunhed) fixed: uptime now working on non-US Windows

   * PR #29883: (serge-p) fix for nfs mounts in _active_mounts_openbsd()

   * PR #29894: (techhat) Support Saltfile in SPM

   * PR  #29856:  (rallytime)  Added  some  initial  unit  tests  for  the
     salt.modules.vsphere.py file

   * PR #29855: (rallytime) Back-port #29740 to 2015.8

   * PR #29890: (multani) Various documentation fixes

   * PR #29850: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29811: (anlutro) influxdb: add retention policy module functions

   * PR #29814: (basepi) [2015.8][Windows] Fix multi-master on windows

   * PR #29819: (rallytime) Add esxi module and state to docs build

   * PR #29832: (jleimbach) Fixed typo in order to use the keyboard module
     for RHEL without systemd

   * PR #29803: (rallytime) Add vSphere module to doc ref module tree

   * PR #29767: (abednarik) Hosts file update in mod_hostname.

   * PR #29772: (terminalmage) pygit2:  skip  submodules  when  traversing
     tree

   * PR #29765: (gtmanfred) allow nova driver to be boot from volume

   * PR  #29773:  (l2ol33rt)  Append  missing  wget in debian installation
     guide

   * PR #29800: (rallytime) Back-port #29769 to 2015.8

   * PR #29775: (paulnivin) Change listen requisite resolution  from  name
     to ID declaration

   * PR #29754: (rallytime) Back-port #29719 to 2015.8

   * PR #29713: (The-Loeki) Pillar-based cloud providers still forcing use
     of deprecated 'provider'

   * PR  #29729:  (rallytime)  Further  clarifications  on  "unless"   and
     "onlyif" requisites.

   * PR #29737: (akissa) fix pillar sqlite3 documentation examples

   * PR #29743: (akissa) fix pillar sqlite not honouring config options

   * PR  #29723:  (rallytime)  Clarify  db_user and db_password kwargs for
     postgres_user.present state function

   * PR #29722: (rallytime) Link "stateful" kwargs to definition  of  what
     "stateful" means for cmd state.

   * PR #29724: (rallytime) Add examples of using multiple matching levels
     to Pillar docs

   * PR #29726: (cachedout) Disable some boto tests per resolution of moto
     issue

   * PR  #29708:  (lagesag)  Fix test=True for file.directory with recurse
     ignore_files/ignore_dirs.

   * PR  #29642:  (cachedout)  Correctly  restart  deamonized  minions  on
     failure

   * PR #29599: (cachedout) Clean up minion shutdown

   * PR #29675: (clinta) allow returning all refs

   * PR  #29683:  (rallytime)  Catch more specific error to pass the error
     message through elegantly.

   * PR #29687: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29681: (clinta) fix bare/mirror in git.latest

   * PR #29644: (rallytime) Fixed a couple more ESXi proxy minion bugs

   * PR #29645: (rallytime) Back-port #29558 to 2015.8

   * PR #29632: (jfindlay)  reduce  severity  of  tls  module  __virtual__
     logging

   * PR #29606: (abednarik) Fixed duplicate mtu entry in RedHat 7  network
     configuration.

   * PR #29613: (rallytime) Various ESXi Proxy Minion Bug Fixes

   * PR #29628: (DmitryKuzmenko) Don't create io_loop before fork

   * PR #29609: (basepi) [2015.8][salt-ssh] Add ability  to  set  salt-ssh
     command umask in roster

   * PR #29603: (basepi) Fix orchestration failure-checking

   * PR  #29597:  (terminalmage)  dockerng:  Prevent  exception  when  API
     response contains empty dictionary

   * PR #29596: (rallytime) Back-port #29587 to 2015.8

   * PR #29588: (rallytime) Added ESXi Proxy Minion Tutorial

   * PR  #29572:  (gtmanfred)  [nova]  use  old   discover_extensions   if
     available

   * PR  #29545:  (terminalmage)  git.latest:  init  submodules if not yet
     initialized

   * PR #29548: (rallytime) Back-port #29449 to 2015.8

   * PR #29547: (rallytime) Refactored ESXCLI-based functions to accept  a
     list of esxi_hosts

   * PR   #29563:   (anlutro)   Fix   a   call  to  deprecated  method  in
     python-influxdb

   * PR #29565: (bdrung) Fix typos and missing release note

   * PR #29540: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29499: (rallytime) Initial commit of ESXi Proxy Minion

   * PR #29526: (jfindlay)  2015.8.2  notes:  add  note  about  not  being
     released

   * PR #29531: (jfindlay) grains.core: handle undefined variable

   * PR  #29538:  (basepi)  [2015.8] [salt-ssh] Remove umask around actual
     execution for salt-ssh

   * PR #29505: (rallytime) Update boto_rds state docs  to  include  funky
     yaml syntax for "tags" option.

   * PR #29513: (bdrung) Drop obsolete syslog.target from systemd services

   * PR #29500: (rallytime) Back-port #29467 to 2015.8

   * PR #29463: (abednarik) Add
     **
     kwargs to debconf.set.

   * PR  #29399:  (jfindlay)  modules.status: add human_readable option to
     uptime

   * PR #29433: (cro) Files for building .pkg files for MacOS X

   * PR #29455: (jfindlay) modules.nova.__init__: do not return None

   * PR #29454: (jfindlay)  rh_service  module  __virtual__  return  error
     messages

   * PR   #29476:   (tbaker57)   Doc   fix   -  route_table_present  needs
     subnet_names (not subnets) as a key

   * PR #29487: (rallytime) Back-port #29450 to 2015.8

   * PR #29441: (rallytime)  Make  sure  docs  line  up  with  blade_idrac
     function specs

   * PR #29440: (rallytime) Back-port #28925 to 2015.8

   * PR  #29435:  (galet)  Grains  return  wrong  OS  version and other OS
     related values for Oracle Linux

   * PR #29430: (rall0r) Fix host.present state limitation

   * PR #29417: (jacobhammons) Repo install updates

   * PR #29402: (techhat) Add rate limiting to linode

   * PR #29400: (twangboy) Fix #19332

   * PR #29398: (cachedout) Lint 29288

   * PR #29331: (DmitryKuzmenko) Bugfix - #29116 raet dns error

   * PR #29390: (jacobhammons) updated version numbers in documentation

   * PR #29381: (nmadhok) No need to deepcopy since six.iterkeys() creates
     a copy

   * PR #29349: (cro) Fix mis-setting chassis names

   * PR #29334: (rallytime) Back-port #29237 to 2015.8

   * PR  #29300: (ticosax) [dockerng] Add support for volume management in
     dockerng

   * PR #29218: (clan) check service enable state in test mode

   * PR #29315: (jfindlay) dev tutorial doc: fix markup errors

   * PR #29317: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #29240: (clan) handle acl_type [[d]efault:][user|group|mask|other]

   * PR #29305: (lorengordon) Add 'file' as a source_hash proto

   * PR #29272: (jfindlay) win_status  module:  handle  12  hour  time  in
     uptime

   * PR  #29289:  (terminalmage) file.managed: Allow local file sources to
     use source_hash

   * PR  #29264:  (anlutro)  Prevent  ssh_auth.absent  from  running  when
     test=True

   * PR #29277: (terminalmage) Update git_pillar runner to support new git
     ext_pillar config schema

   * PR #29283: (cachedout) Single-quotes and use format

   * PR #29139: (thomaso-mirodin) [salt-ssh] Add a range roster and  range
     targeting options for the flat roster

   * PR #29282: (cachedout) dev docs: add development tutorial

   * PR #28994: (timcharper) add support to s3 for aws role assumption

   * PR #29278: (techhat) Add verify_log to SPM

   * PR  #29067:  (jacksontj) Fix infinite recursion in state compiler for
     prereq of SLSs

   * PR #29207: (jfindlay) do not shadow ret function argument

   * PR #29215: (rallytime) Back-port #29192 to 2015.8

   * PR #29217: (clan) show duration only if state_output_profile is False

   * PR #29221: (ticosax) [dokcerng] Docu network mode

   * PR #29269: (jfindlay) win_status module: fix function names in docs

   * PR #29213: (rallytime) Move _wait_for_task func from vmware cloud  to
     vmware utils

   * PR #29271: (techhat) Pass full path for digest (SPM)

   * PR #29244: (isbm) List products consistently across all SLES systems

   * PR #29255: (garethgreenaway) fixes to consul module

   * PR #29208: (whytewolf) Glance more profile errors

   * PR #29200: (jfindlay) mount state: unmount by device is optional

   * PR #29205: (trevor-h) Fixes #29187 - using winrm on EC2

   * PR #29170: (cachedout) Migrate pydsl tests to integration test suite

   * PR #29198: (jfindlay) rh_ip module: only set the mtu once

   * PR  #29135: (jfindlay) ssh_known_hosts.present state: catch not found
     exc

   * PR  #29196:  (s0undt3ch)  We  need  novaclient  imported  to  compare
     versions

   * PR #29059: (terminalmage) Work around upstream pygit2 bug

   * PR    #29112:    (eliasp)    Prevent    backtrace    (KeyError)    in
     ssh_known_hosts.present state

   * PR   #29178:   (whytewolf)    Profile    not    being    passed    to
     keystone.endpoint_get in _auth. so if a p...

   Salt 2015.8.8 Release Notes
   IMPORTANT:
      2015.8.8.2  was released shortly after 2015.8.8 to fix several known
      issues. If you installed 2015.8.8 before 03/30/2016, you likely have
      installed  2015.8.8  and  can  optionally  upgrade  (find  out which
      version you have installed using salt --version. The latest  version
      is 2015.8.8.2).

   Salt 2015.8.8.2
   Salt  2015.8.8.2  includes  fixes  for  the  following  known issues in
   2015.8.8:

   * issue 32044: Key master with value [...] has an invalid type of  list
     Error

   * issue 32004: Failed to import module win_dacl Error

   * 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
   Security Fix
   CVE-2016-3176:  Insecure  configuration  of PAM external authentication
   service

   This issue affects all Salt versions prior to  2015.8.8/2015.5.10  when
   PAM  external authentication is enabled. This issue involves passing an
   alternative PAM authentication service with a command that is  sent  to
   LocalClient,   enabling   the   attacker   to   bypass  the  configured
   authentication service. Thank you to  Dylan  Frese  <[email protected]>
   for bringing this issue to our attention.

   This  update  defines  the  PAM  eAuth  service that users authenticate
   against in the Salt Master configuration.

   Read Before Upgrading Debian 7 (Wheezy) from 2015.8.7 to 2015.8.8
   Before you upgrade  from  2015.8.7  on  Debian  7,  you  must  run  the
   following commands to remove previous packages:

      sudo apt-get remove python-pycrypto
      sudo apt-get remove python-apache-libcloud

   Note that python-pycrypto will likely remove python-apache-libcloud, so
   the second command might not be necessary. These have been replaced  by
   python-crypto and python-libcloud with ~bpo70+1 moniker.

   Read  Before  Upgrading  Debian  8 (Jessie) from Salt Versions Earlier than
   2015.8.4
   Salt systemd service files are missing the following statement in these
   versions:

      [Service]
      KillMode=process

   This  statement  must be added to successfully upgrade on these earlier
   versions of Salt.

   Changes for v2015.8.7..v2015.8.8
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-03-17T21:03:44Z

   Total Merges: 312

   Changes:

   * PR  #31947: (cro) Move proxymodule assignment earlier in proxy minion
     init

   * PR #31948: (rallytime) Revert "not not" deletion and add  comment  as
     to why that is there

   * PR #31952: (rallytime) Fix lint for 2015.8 branch

   * PR #31933: (rallytime) Fix linking syntax in testing docs

   * PR #31930: (cro) Backport changes from 2016.3

   * PR #31924: (jfindlay) update 2015.8.8 release notes

   * PR #31922: (cachedout) For 2015.8 head

   * PR #31904: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR   #31906:   (sbreidba)   Win_dacl   module:   fix   FULLCONTROL  /
     FILE_ALL_ACCESS definition

   * PR #31745: (isbm) Fix the always-false behavior on checking state

   * PR #31911: (rallytime) Merge #31903 with pylint fix

   * PR #31883: (paiou) Fix scaleway cloud provider and manage x86 servers

   * PR #31903: (terminalmage) Use remote_ref instead of local_ref to  see
     if checkout is necessary

   * PR  #31845:  (sakateka) Now a check_file_meta deletes temporary files
     when test=True

   * PR #31901: (rallytime) Back-port #31846 to 2015.8

   * PR #31905: (terminalmage) Update versionadded directive

   * PR #31902: (rallytime) Update versionadded tag for new funcs

   * PR #31888: (terminalmage) Fix salt.utils.decorators.Depends

   * PR  #31857:  (sjorge)  gen_password  and  del_password  missing  from
     solaris_shadow

   * PR #31879: (cro) Clarify some comments

   * PR #31815: (dr4Ke) Fix template on contents 2015.8

   * PR  #31818: (anlutro) Prevent event logs from writing huge amounts of
     data

   * PR #31836: (terminalmage) Fix git_pillar race condition

   * PR #31824: (rallytime) Back-port #31819 to 2015.8

   * PR #31856: (szeestraten) Adds missing docs for  Virtual  Network  and
     Subnet options in salt-cloud Azure cloud profile

   * PR #31839: (jfindlay) add 2015.8.8 release notes

   * PR  #31828:  (gtmanfred)  Remove  ability  of  authenticating user to
     specify pam service

   * PR #31787: (anlutro) Fix user_create and db_create for  new  versions
     of influxdb

   * PR #31800: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR   #31797:   (Ch3LL)   Change   pkg   name   to   less   for   suse
     pkg.info_installed test

   * PR #31793: (xopher-mc) fixing init system detection on sles 11, refs
     `#31617`_

   * PR #31786: (isbm) Bugfix: zypper doesn't detect base product on SLE11
     series

   * PR #31780: (gtmanfred) use already created vsphere connection

   * PR  #31779:  (sbreidba) win_dacl state & module: return comment field
     as strings, not lists.

   * PR #31723: (sjorge) file_ignore_regex is a list, not bool

   * PR #31747: (techhat)  Use  get_local_client  with  MASTER  opts,  not
     MINION

   * PR #31688: (whiteinge) Various SMTP returner fixes

   * PR #31752: (rallytime) Back-port #31686 to 2015.8

   * PR #31733: (jacobhammons) docs to clarify cloud configuration

   * PR #31775: (techhat) Show correct provider/driver name

   * PR #31754: (techhat) Check all providers, not just the current one

   * PR #31735: (rallytime) Add reboot, start, and stop actions to digital
     ocean driver

   * PR #31770: (anlutro) Fix influxdb user functionality for version 0.9+

   * PR #31743: (Talkless) Fix parentheses mismatch in documentation

   * PR #31162: (isbm) Remove MD5 digest from everywhere  and  default  to
     SHA256

   * PR  #31670:  (terminalmage) Write lists of minions targeted by syndic
     masters to job cache

   * PR #31711: (ticosax) [dockerng] Port  and  Volume  comparison  should
     consider Dockerfile

   * PR  #31719:  (techhat)  Don't  worry  about  KeyErrors if the node is
     already removed

   * PR #31713: (ticosax)  [dockerng]  Fix  dockerng.network_present  when
     container is given by name

   * PR #31705: (peripatetic-sojourner) Foreman pillar

   * PR #31702: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #31700: (s0undt3ch) It's a function!

   * PR  #31679:  (cro)  Fix  bad  link  to  the  sample  REST endpoint in
     salt-contrib.

   * PR #31668: (rallytime) Some more testing documentation improvements

   * PR #31653: (DmitryKuzmenko) Don't  attempt  to  verify  token  if  it
     wasn't sent to master.

   * PR #31629: (darix) Fix services on sles

   * PR  #31641:  (rallytime)  Improve  Salt Testing tutorial to be a more
     comprehensive intro

   * PR #31651: (dr4Ke) test case: test_list_present_nested_already

   * PR #31643: (opdude) Make sure we are really  updating  the  mercurial
     repository

   * PR  #31598: (terminalmage) Remove limitations on validation types for
     eauth targets

   * PR #31627: (jakehilton) Handling error from using gevent 1.1.

   * PR #31630: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #31594: (rallytime) Back-port #31589 to 2015.8

   * PR #31604: (joejulian) Workaround for non-xml output from gluster cli
     when not tty

   * PR #31583: (vutny) Remove trailing white spaces

   * PR #31592: (rallytime) Back-port #31546 to 2015.8

   * PR #31593: (rallytime) Back-port #31570 to 2015.8

   * PR   #31567:   (cachedout)   Restore   FIPS   compliance  when  using
     master_finger

   * PR #31568: (twangboy) Grant permissions using SID instead of name

   * PR #31561: (jtand) Skipped test

   * PR    #31550:    (rallytime)    Correct    versionadded    tag    for
     win_service.config

   * PR #31549: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #31544: (DmitryKuzmenko) Protect getattr from recursion

   * PR #31525: (DmitryKuzmenko) Issues/30643 merge forward fixes

   * PR #31536: (virtualguy) Remove debian repo from raspbian installation

   * PR  #31528:  (vutny)  Correct Salt Cloud documentation about updating
     Salt Bootstrap script

   * PR #31539: (DmitryKuzmenko) Added temporary workaround for  CentOS  7
     os-release id bug.

   * PR #31508: (mcalmer) Zypper correct exit code checking

   * PR  #31510:  (vutny)  Add  installation guide for Raspbian (Debian on
     Raspberry Pi)

   * PR #31498: (Ch3LL) rename methods in pkg states test

   * PR #31471: (cachedout) Correct issue where duplicate items in  grains
     list during state run will result in duplicate grains

   * PR #31455: (ticosax) [dockerng] Disable notset check

   * PR #31488: (isbm) Unit Test for Zypper's "remove" and "purge"

   * PR  #31485:  (jacobhammons)  Fixed  transport description in minion /
     master config

   * PR #31411: (jtand) Added some beacons  execution  module  integration
     tests

   * PR #31475: (jacobhammons) Assorted doc issues

   * PR #31477: (vutny) Correct installation documentation for Ubuntu

   * PR #31479: (isbm) Zypper unit tests & fixes

   * PR  #31445:  (rallytime)  Only use LONGSIZE in rpm.info if available.
     Otherwise, use SIZE.

   * PR #31464: (Ch3LL) integartion test: ensure decorator  only  runs  on
     one method and not class

   * PR #31458: (vutny) Correct installation documentation for Debian

   * PR #31457: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #31439: (rallytime) Fix lowpkg.info function for Ubuntu 12 - make
     sure we have a pkg name

   * PR  #31456:   (RabidCicada)   Clarified   the   form   of   requisite
     targets/requisite-references

   * PR  #31453:  (DmitryKuzmenko)  Backport cp_geturl fix for large files
     into 2015.8

   * PR  #31444:  (jacobhammons)  Documentation  updates  -  ddns   state,
     file.line state/exe function, installation dependencies

   * PR #31341: (twangboy) Clarification on Windows Package Manager docs

   * PR #31380: (kiorky) Bring up ext_pillar rendering errors as well

   * PR  #31418: (terminalmage) Fix core grains when Debian OS detected as
     'Debian GNU/Linux'

   * PR #31429: (mcalmer) fix argument handling for pkg.download

   * PR #31432: (ticosax) [dockerng] Hotfix docker 1.10.2

   * PR #31420: (twangboy) Handle Unversioned Packages

   * PR  #31417:  (jacobhammons)  ddns  state  docs  updated  with   notes
     regarding the name, zone, and keyfile.

   * PR #31391: (redmcg) Added sanity check: is 'pillar' in self.opts

   * PR #31376: (cro) Some distros don't have a /lib/systemd

   * PR  #31352:  (ticosax)  [dockerng]  Pull  missing images when calling
     dockerng.running

   * PR #31378: (mcalmer) Zypper refresh handling

   * PR #31373: (terminalmage) Use --set-upstream instead  of  --track  to
     set upstream on older git

   * PR #31390: (abednarik) Fix Logrotate module.

   * PR #31354: (ticosax) [dockerng] Don't require auth for all registries

   * PR #31368: (whiteinge) Update list of netapi clients for autoclass

   * PR #31367: (techhat) Add docs on how to actually use SDB

   * PR #31357: (ticosax) [dockerng] Support docker inconsistencies

   * PR #31353: (ticosax) [dockerng] Fix when ports are integers

   * PR #31346: (ticosax) Backport #31130 to 2015.8

   * PR  #31332: (terminalmage) Clarify documentation for gitfs/hgfs/svnfs
     mountpoint and root options

   * PR  #31305:  (mcalmer)  call  zypper  with  option  --non-interactive
     everywhere

   * PR #31337: (jacobhammons) Release notes and versioning for 2015.8.7

   * PR #31326: (ticosax) [dockerng ] Detect settings removal

   * PR  #31292:  (twangboy)  Fix  dunder  virtual  to  check  for  Remote
     Administration Tools

   * PR #31287: (joejulian) Rework tests  and  fix  reverse  peering  with
     gluster 3.7

   * PR #31196: (sakateka) Here are a few fixes utils.network

   * PR  #31299:  (rallytime) Allow state-output and state-verbose default
     settings to be set from CLI

   * PR #31317: (terminalmage) Fix versonadded directive

   * PR #31301: (terminalmage) Corrected fix for
     `#30999`_

   * PR #31302: (terminalmage) Audit CLI opts used in git states

   * PR #31312: (terminalmage) Merge 2015.5 into 2015.8

   * PR #31225: (pprince) Fix in file_tree pillar (Fixes
     `#31223`_
     .)

   * PR #31233: (mcalmer) implement version_cmp for zypper

   * PR #31273: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #31253: (gtmanfred) allow  for  nova  servers  to  be  built  with
     premade volumes

   * PR #31271: (rallytime) Back-port #30689 to 2015.8

   * PR #31255: (jacobhammons) Fixes
     `#30461`_

   * PR #31189: (dmacvicar) Fix crash with scheduler and runners (
     `#31106`_
     )

   * PR  #31201:  (The-Loeki)  Utilize  prepared grains var in master-side
     ipcidr matching

   * PR #31239: (terminalmage) Improve logging when master cannot decode a
     payload

   * PR #31190: (twangboy) Clear minion cache before caching from master

   * PR #31226: (pprince) Minor docs fix: file_tree pillar (Fixes #31124)

   * PR #31234: (mcalmer) improve doc for list_pkgs

   * PR #31237: (mcalmer) add handling for OEM products

   * PR #31182: (rallytime) Back-port #31172 to 2015.8

   * PR #31191: (rallytime) Make sure doc example matches kwarg

   * PR #31171: (Ch3LL) added logic to check for installed package

   * PR #31177: (Ch3LL) add integration test for issue
     `#30934`_

   * PR #31181: (cachedout) Lint 2015.8 branch

   * PR #31169: (rallytime) Back-port #29718 to 2015.8

   * PR #31170: (rallytime) Back-port #31157 to 2015.8

   * PR #31147: (cro) Documentation clarifications.

   * PR  #31153:  (edencrane)  Fixed  invalid  host  causing 'reference to
     variable before assignment'

   * PR #31152: (garethgreenaway) fixes to beacon module, state module and
     friends

   * PR #31149: (jfindlay) add 2015.8.7 release notes

   * PR #31134: (isbm) Fix types in the output data and return just a list
     of products

   * PR #31120: (gtmanfred) Clean up some bugs in the nova driver

   * PR #31132: (rallytime)  Make  sure  required  profile  configurations
     passed in a map file work

   * PR #31131: (Ch3LL) integration test for issue
     `#31014`_

   * PR #31133: (cachedout) Fixup 31121

   * PR  #31125: (isbm) Force-kill websocket's child processes faster than
     default two minutes.

   * PR #31119: (sakateka) fixes for ipv6-only multi-master faliover

   * PR #31107: (techhat) Don't try to add a non-existent IP address

   * PR #31108: (jtand) Changed npm integration test to install request.

   * PR #31105: (cachedout) Lint 30975

   * PR #31100: (jfindlay) states.x509: docs: peer.sls -> peer.conf

   * PR #31103: (twangboy) Point to reg.delete_key_recursive

   * PR #31093: (techhat) Ensure double directories don't get created

   * PR #31095: (jfindlay)  modules.file,  states.file:  explain  symbolic
     links

   * PR  #31061:  (rallytime)  Revert  #30217  - was causing salt-cloud -a
     breakage

   * PR #31090: (rallytime) Back-port #30542 to 2015.8

   * PR #31085: (jacksontj) Correctly remove path we added after loader is
     completed

   * PR  #31037:  (vutny) Update RHEL installation guide to reflect latest
     repo changes

   * PR #31050: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #31053: (cachedout) Fix boto test failures

   * PR #31029: (twangboy) Windows defaults to multiprocessing true

   * PR #30998: (dmacvicar) add_key/reject_key: do not crash  w/Permission
     denied: '/var/cache/salt/master/.dfn' (
     `#27796`_
     )

   * PR #31049: (twangboy) Fix versionadded in win_service.config

   * PR  #30987:  (youngnick) Changed glusterfs.peer() module so state can
     handle localhost peering attempts.

   * PR #31042: (moltob) Allow using  Windows  path  in  archive.extracted
     name attribute

   * PR  #31012:  (terminalmage)  Fix gitfs/git_pillar/winrepo provider to
     allow lowercase values

   * PR #31024: (jfindlay)  modules.aptpkg.upgrade:  clarify  dist-upgrade
     usage

   * PR #31028: (twangboy) Fix config overwrite by windows installer

   * PR #31031: (terminalmage) More complete fix for
     `#31014`_

   * PR      #31026:      (terminalmage)      Fix      regression     when
     contents_pillar/contents_grains is a list.

   * PR #30978: (garethgreenaway) fixes to state.py in 2015.8

   * PR #30893: (bdrung) Make build reproducible

   * PR #30945: (cachedout) Note that pillar cli args are sent via pub

   * PR #31002: (rmtmckenzie) Fix  lxc  cloud  provided  minion  reporting
     present

   * PR #31007: (jtand) Fixed rabbitmq_vhost test failure.

   * PR #31004: (rallytime) Remove overstate docs and a few references.

   * PR #30965: (anlutro) Fix rabbitmq_vhost.present result when test=True

   * PR #30955: (Ch3LL) docs: add clarification when source is not defined

   * PR #30941: (rallytime) Back-port #30879 to 2015.8

   * PR #30940: (twangboy) Fix Build Process for OSX

   * PR #30944: (jacobhammons) 2015.8.5 release notes linking and clean up

   * PR  #30905:  (joejulian)  Add realpath to lvm.pvdisplay and use it in
     vg_present

   * PR #30924: (youngnick) Fix small  bug  with  starting  volumes  after
     creation.

   * PR #30910: (cro) fix iDRAC state

   * PR #30919: (garethgreenaway) Fixes to ssh_auth state module

   * PR #30920: (jacobhammons) Versioned to 2015.8.5, added known issue
     `#30300`_
      to release notes

   * PR  #30894:  (terminalmage)  git  module/state: Handle identity files
     more gracefully

   * PR #30750: (jfindlay) extract whole war version

   * PR #30884: (rallytime) Move checks for private_key file existence and
     permissions to create function

   * PR #30888: (ticosax) Backport #30797 to 2015.8

   * PR #30895: (bdrung) Fix various typos

   * PR   #30889:   (anlutro)  Make  msgpack  an  optional  dependency  in
     salt.utils.cache

   * PR #30896: (vutny) Update nodegroups  parameter  examples  in  master
     config example and docs

   * PR #30898: (abednarik) Fix pkg install with version.

   * PR    #30867:    (rallytime)    Pass    in    'pack'    variable   to
     utils.boto.assign_funcs function from ALL boto modules

   * PR #30849: (jfindlay) utils.aws: use time  lib  to  conver  to  epoch
     seconds

   * PR  #30874: (terminalmage) Fix regression in git_pillar when multiple
     remotes are configured

   * PR #30850: (jfindlay) modules.dpkg._get_pkg_info:  allow  for  ubuntu
     12.04

   * PR #30852: (replicant0wnz) Added more descriptive error message

   * PR #30847: (terminalmage) Backport #30844 to 2015.8 branch

   * PR  #30860: (vutny) Correct installation documentation for RHEL-based
     distributions

   * PR #30841: (jacobhammons) Release notes for 2015.8.5

   * PR #30835: (terminalmage) Integration test for
     `#30820`_

   * PR #30837: (jacobhammons) Added known issue
     `#30820`_
      to release notes

   * PR #30832: (rallytime) Add grains modules to salt modindex

   * PR #30822: (rallytime) Make  sure  setting  list_user_permissions  to
     ['', '', ''] doesn't stacktrace

   * PR  #30833:  (terminalmage) Fix regression in scanning for state with
     'name' param

   * PR #30823: (yannis666) Fix for mine to merge configuration on update.

   * PR #30827: (jacobhammons) Version to 2015.8.4, added CVE 2016-1866 to
     release notes

   * PR   #30813:   (anlutro)   Properly   set   the   default  value  for
     pillar_merge_lists

   * PR #30826: (cachedout) Fix 30682

   * PR #30818: (rallytime) Back-port #30790 to 2015.8

   * PR #30815: (vutny) Pick right  user  argument  for  updating  reactor
     function's low data

   * PR #30747: (jfindlay) modules.lxc.running_systemd: use command -v not
     which

   * PR #30800: (twangboy) Ability to handle special case installations

   * PR #30794: (rallytime) A spelling fix and some spacing fixes for  the
     boto_ec2 module docs

   * PR  #30756:  (basepi)  [2015.8]  Fix  two  error  conditions  in  the
     highstate outputter

   * PR #30788: (rallytime) Fix  incorrect  doc  example  for  dellchassis
     blade_idrac state

   * PR   #30791:   (Ch3LL)  do  not  shadow  ret  function  argument  for
     salt.function

   * PR #30726: (sjmh) Fix improper use of yield in generator

   * PR #30752: (terminalmage) Backport systemd and yum/dnf  optimizations
     from develop into 2015.8

   * PR #30759: (thusoy) Allow managing empty files

   * PR  #30758:  (thusoy) Support mounting labelled volumes with multiple
     drives

   * PR #30686: (cachedout) Master-side pillar caching

   * PR #30675: (jfindlay) handle non-ascii minion IDs

   * PR #30691: (rallytime) Make sure  we  use  the  "instance"  kwarg  in
     cloud.action.

   * PR #30713: (rallytime) Fix-up autodoc proxy modules for consistency

   * PR #30741: (jfindlay) states.locale.__virtual__: return exec mod load
     err

   * PR #30751: (basepi) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #30720: (clinta) x509.pem_managed does not return changes dict

   * PR #30687: (clarkperkins) Setting  'del_root_vol_on_destroy'  changes
     the root volume type to 'standard'

   * PR  #30673:  (terminalmage)  Properly  derive the git_pillar cachedir
     from the id instead of the URL

   * PR #30666: (cachedout) Fix grains cache

   * PR #30623: (twangboy) Added service.config function

   * PR #30678: (rallytime) Back-port #30668 to 2015.8

   * PR #30677: (clarkperkins) Fix EC2 volume creation logic

   * PR #30680: (cro) Merge forward from 2015.5, primarily for #30671

   * PR #30663: (isbm) Zypper: latest version  bugfix  and  epoch  support
     feature

   * PR #30652: (mew1033) Fix sh beacon

   * PR #30657: (jfindlay) [2015.8] Backport #30378 and #29650

   * PR #30656: (rallytime) [2015.8] Merge 2015.5 into 2015.8

   * PR #30644: (tbaker57) Another go at fixing 30573

   * PR #30611: (isbm) Bugfix: Zypper pkg.latest crash fix

   * PR  #30631:  (rallytime)  Refactor  rabbitmq_cluster  states  to  use
     test=true functionality correctly

   * PR  #30628:  (rallytime)  Refactor  rabbitmq_policy  states  to   use
     test=true functionality correctly

   * PR #30624: (cro) Remove bad symlinks from osx pkg dir

   * PR #30622: (rallytime) Add glance state to list of state modules

   * PR #30618: (rallytime) Back-port #30591 to 2015.8

   * PR #30625: (jfindlay) doc.topics.eauth: clarify client_acl vs eauth

   Salt 2015.8.9 Release Notes
   Version 2015.8.9 is a bugfix release for 2015.8.0.

      Mint Linux: Important Post-Upgrade Instructions

             As  a  result  of some upstream changes, the os grain on Mint
             Linux is now being detected as LinuxMint (issue  33295).  Run
             the  following command after you upgrade to 2015.8.9 to reset
             the os grain to Mint and the os_family grain to Debian:

          salt -G 'os:LinuxMint' grains.setvals "{'os': 'Mint', 'os_family': 'Debian'}"

   Changes for v2015.8.8..v2015.8.9
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-05-17T17:09:39Z

   Total Merges: 145

   Changes:

   * PR #33293: (twangboy) Fix minion start retry on Windows (2015.8)

   * 22c4331  linux_acl:  Allow  '-'  as  a  separation  character  in ACL
     permissions. Fixes
     `#31270`_
      (#33172) (#33305)

   * 7a181f2 Handle more ipv6 error as an exception
     `#33299`_
      (#33300)

   * eb47a15 Ignore retcode when checking service's status (#33294)

   * PR #33274: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 4f3596a Add comment for test=true w/o changes  ret  and  add  changes
     dict example (#33254)

   * 2a30c48 Update Git Policy docs to match Contribution guide (#33252)

   * 056c273 Fix
     `#33238`_
      (#33239)

   * 1cd34ab  Properly report on invalid gitfs/git_pillar/winrepo repos (
     #33245)

   * PR #33253: (rallytime) Update the release process docs

   * 8c2c5b1 update 2015.8.9 release notes (#33251)

   * 8ee8ee3 Handle ipv6 error as an exception (#33246)

   * 855bed3 Check rendered YAML for invalid keys (#33213)

   * 6fb25a8 Make note of  files  that  begin  with  '_'  in  master.d  or
     minion.d dirs (#33224)

   * a6dc0d2 Gate jnpr imports in salt.proxy.junos.py (#33150)

   * 64a89c4 Add docs for the http state (#33222)

   * 0a32163  Don't  stacktrace  when  using --out=highstate at CLI during
     staterun. (#33215)

   * 04d714d propagate opts to salt.util.http call (#33219)

   * c8236c0 update 2015.8.9 release notes (#33237)

   * PR #33217: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 730bec1 [2015.8] Merge forward from 2015.5 to 2015.8 (#33207)

   * 379b151 Add a fetch when compiling git_pillar for masterless  minions
     (#33204)

   * b3805d8 cloud.clouds.ec2: cache each named node (#33164)

   * 86db5df Properly handle failed git commands when redirect_stderr=True
     (#33203)

   * 8a0950d Don't force use of global ssh_config when git  identity  file
     is specified (#33152)

   * ce07133 update 2015.8.9 release notes (#33198)

   * PR #33188: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * e9108e0 add 2015.8.9 release notes (#33161)

   * 2d9919e  [2015.8]  Update  to  latest bootstrap script v2016.05.10 (
     #33156)

   * 033bef2 Hash fileclients by opts (#33142)

   * f520fa3 Back-port #31769 to 2015.8 (#33139)

   * PR #33144: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #33140: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * ad607ef If cache_jobs: True is set, populate the local job cache when
     running salt-call (#33100)

   * 64689a6 Fix broken parsing of usermgmt.conf on OpenBSD (#33135)

   * 06a382e  Add  a  check  that the cmdline of the found proc matches (
     #33129)

   * 10018e9 salt.utils.gitfs: fix  formatting  for  warning  messages  (
     #33064)

   * d45b599 Fix 33058 (#33099)

   * PR #33106: (abednarik) Moved _finger_fail method to parent class.

   * 20c7e10  clarify  docs  that  map  is designed to be run once. is not
     stateful (#33102)

   * 558561d cloud.query needs to define mapper.opts (#33098)

   * PR #33096: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 22a327b salt-cloud: fix ipv6-only virtual machines (#32865)

   * e788f7e modules.npm: do not log npm --version at info level (#33084)

   * PR #33081: (jfindlay) ssh docs: install py-2.6 for RHEL 5

   * PR #33088: (isbm)  Bugfix:  Restore  boolean  values  from  the  repo
     configuration

   * 2c6326f fix tests for file.blockplace to remove newline (#33082)

   * PR #32892: (isbm) Resolve Zypper locks on asynchronous calls

   * 3e0bf23 Add fun_args to scheduled return data (part of
     `#24237`_
     ) (#33039)

   * 264c0d4  Don't  append  a  newline  when  creating  new  content with
     blockreplace (#33049)

   * 54b783a Pass all data to batch.run() call when  using  --failhard  (
     #33048)

   * 2dbfa55  Display  command  output  when  command  fails  with batch +
     failhard options (#33050)

   * add9199 Allow security_groups kwarg for boto_elb.present to be string
     or list (#33053)

   * 111701c [2015.8] Merge forward from 2015.5 to 2015.8 (#33054)

   * 1066063 File and User test fixes for 2015.8 on Fedora23  (#33056)

   * f97b5d5 Back-port #33030 to 2015.8 (#33040)

   * e90a501   Update   the   docs   for   saltutil.find_job  to  be  more
     clear/accurate (#33017)

   * d3d77ce Add saltenv to the cmd.script state function (#33031)

   * 3434f44 Fix syndic regression (#33021)

   * 4bb3ca5 Compare uid and gid instead of name and group (#32674)

   * 9ca5b02 Allow batch mode to use verbose option, as well as  show_jid.
     (#32996)

   * 81c0fa4 Fixed glusterfs.peered output (#32955)

   * 8c70d7a Clarify some arg docs (#32994)

   * 00fbeab Fix boto_secgroup_test (#32986)

   * 3362367 fix user cron on solarish operating systems (#32970)

   * 07e38bc salt.log.setup: process user args before format (#32796)

   * b2d7c81 doc.ref.states.ordering: clarify requisite change (#32934)

   * df41d5d mode should default to 'text' (#32928)

   * f581a82  Remove  FileClient  class  references from docs - it doesn't
     exist. (#32925)

   * 31b96de Update contents_grains option with relevant docs (#32922)

   * PR #32926: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 1cd6a45 specify volume tags in profile configuration (#32908)

   * 85ca86d Update docs to warn users that -1 isn't  valid  for  iptables
     insert state (#32906)

   * cb68706  Allow  profile options to be specified in provider file when
     using maps (#32900)

   * 1a55fcb  Clarify  service  state  opening  docs  -   uses   'service'
     virtualname (#32880)

   * PR #32884: (terminalmage) Fix incorrect deprecation notice

   * PR  #32878:  (jacobhammons)  added  note about updating the bootstrap
     script in salt-cloud using th...

   * PR #32869: (rallytime) Use correct config  setting  in  cloud  syndic
     docs

   * PR #32844: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * eb8fb6b Back-port #31139 to 2015.8 (#32868)

   * 4bb5545 backport PR #32732 for issue
     `#23714`_
      (#32847)

   * 5ea003b  Add  pyvmomi  version warning to Getting Started with VMware
     docs (#32845)

   * 44f08d0 Pass None as memory limit. (#32841)

   * feebe69 Back-port #32813 to 2015.8 (#32839)

   * 3b81031 various improvements on cloud deploy script docs (#32659)

   * bf85987 update bootstrap to 2016.04.18 release (#32668)

   * 83dee63 Back-port #29322 to 2015.8 (#32785)

   * PR #32787: (rallytime) Back-port #32722 to 2015.8

   * PR #32786: (rallytime) Back-port #32703 to 2015.8

   * a6a42740 Merge branch 'pr-32775' into 2015.8

   * cda00f4 Improve documentation on pygit2 versions (#32779)

   * 1d6d234 Properly handle minion failback failure. (#32749)

   * 3751a27 Document pillar cache options (#32643)

   * 35c8af3 modules.win_dacl: consistent case of dacl constants (#32720)

   * 2cd0817 Update external auth documentation to list supported matcher.
     (#32733)

   * bba089d  Check  dependencies  type  before  appling str operations (
     #32693)

   * 3aa0605  Handle  when  beacon  not   configured   and   we   try   to
     enable/disable them (#32692)

   * PR #32718: (garethgreenaway) Fixes to schedule.list in 2015.8

   * PR #32684: (captaininspiration) Fix routes for redhat < 6

   * 7cdd512 Handle a couple of arguments better (Azure) (#32683)

   * aaa03bc Fix for issue 32523 (#32672)

   * 21081b1 Don't access deprecated Exception.message attribute. (#32556)

   * 5d1e9a4 Lower log level for pillar cache (#32655)

   * PR  #32588: (anlutro) Fix salt-ssh module function call argument type
     juggling by JSON encoding them

   * 5e7edfc yumpkg: Ignore  epoch  in  version  comparison  for  explicit
     versions without an epoch (#32563)

   * fea6056 Fixing critical bug to remove only the specified Host instead
     of the entire Host cluster (#32640)

   * 0477f66 align OS grains from older SLES with current one (#32649)

   * 8d46244 Prevent crash if pygit2 package is requesting  re-compilation
     of the e (#32652)

   * PR #32614: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32616: (rallytime) Back-port #32547 to 2015.8

   * 3047471 Fix comments value in salt.states.pkgrepo example (#32604)

   * ab9da90  Revert PR #32480 and apply #32314 with fixes / documentation
     (#32558)

   * c84c921 Better log message on minion restart if  master  couldn't  be
     reached. (#32576)

   * 3c81798 Don't return None from eval_master (#32555)

   * PR #32536: (rallytime) Back-port #31898 to 2015.8

   * d12a1c2 Fix binary search and replace (#32542)

   * PR #32539: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR     #32531:     (ticosax)     [dockerng]     Fix     support    of
     dockerng.volume_present when no volume is on present.

   * 5d73d54 Enhance dockerng.wait() to control success on  exit_code  and
     on already stopped containers (#32475)

   * 214f01e  Bugfix:  salt-key  crashes  if tries to generate keys to the
     directory w/o write access (#32436)

   * 288839f Turn on exc_info when logging failed minion startup (#32515)

   * 08a8020  Add  ignore_epoch  option  to   pkg.installed/removed/purged
     states (#32520)

   * 492ebfc Isbm zypper list products sles11 crash (#32505)

   * ae89882  Clear  VCS fsbackend and git_pillar locks on master start (
     #32480)

   * a6482a3 Use win32api to get Total System Memory (#32491)

   * PR  #32487:  (terminalmage)  Add   explanation   of   nonzero   epoch
     requirement to pkg.installed state documentation

   * PR #32482: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * f5bd6bd Backport 31164 and 31364 (#32474)

   * PR #32450: (cachedout) Pass parser options into batch mode

   * b299835 Issue
     `#28706`_
     : Fix state user.present behavior. (#32448)

   * cef33d5 Argument name in docs should match actual arg name (#32445)

   * PR #32432: (ticosax) [dockerng] Fix Domainname introspection

   * PR #32427: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32423: (jtand) Update glusterfs_test to be inline with #32312

   * PR #32425: (cachedout) Fix salt-cloud parallel provisioning

   * 51fb2ac  FreeBSD  supports  packages  in  format java/openjdk7 so the
     prior commit broke that functionality. Check freebsd/pkg`#1409`_  for
     more info.

   * 709410a Improve git_pillar documentation/logging

   * c53efc3 Update master config docs

   * PR  #32323:  (mcalmer) fix sorting by latest version when called with
     an attribute

   * PR #32376: (amontalban) Fixes saltstack/salt`#28262`_

   * 0d9a06b Cleaner deprecation process with decorators

   * 6979fda Correcty index glusterfs bricks

   * PR #32393: (jfindlay) modules.win_timezone: don't list all  zones  in
     debug log

   * PR #32372: (rallytime) Back-port #32358 to 2015.8

   * PR  #32392:  (multani)  Fix  documentation  on  boto_asg and boto_elb
     modules and states

   * PR #32373: (cachedout) Resolve memory leak in authentication

   * PR #32126:  (cro)  Add  a  couple  CLI  examples  for  the  highstate
     outputter.

   * PR #32353: (mcalmer) Prevent metadata download when listing installed
     products

   * PR #32321: (abednarik) Better message when minion fail to start

   * PR #32345: (nmadhok) [2015.8] Check if profile key exists in
     vm_
      dict

   * PR #32343: (Ferbla) Fixed win_wua example documentation

   * PR  #32360:  (rallytime)  Make  sure  hash_type   is   lowercase   in
     master/minion config files

   * PR #32361: (cro) SDB is no longer experimental

   * PR #32336: (rallytime) Back-port #28639 to 2015.8

   * PR  #32332: (rallytime) Don't unsubscribe from open events on the CLI
     too early on long-running commands

   * PR #32333: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32289: (rallytime) New salt-cloud instances should  not  use  old
     hash_type default.

   * PR #32291: (twangboy) Fix bad output for chocolatey.version (fixes
     `#14277`_
     )

   * PR      #32295:      (rallytime)     Test     the     contents     of
     'deploy_scripts_search_path' in salt.config.cloud_config

   * PR #32315: (ahus1) fixing file.managed with requests lib

   * PR #32316: (vutny) Update Salt Bootstrap tutorial

   * PR #32325: (bdrung) Re-add shebang to ssh-id-wrapper shell script

   * PR #32326: (bdrung) Fix typos

   * PR #32300: (twangboy) Add documentation to disable winrepo/winrepo_ng

   * PR #32288: (terminalmage) use dictupdate.merge instead of dict.update
     to merge CLI pillar overrides

   * PR #32243: (isbm) Ensure latest pkg.info_installed ensure latest

   * PR  #32268: (ticosax) [dockerng] Improve detection for older versions
     of docker-py

   * PR   #32258:   (jacobhammons)   Replaces   incorrect   reference   to
     master_alive_check

   * PR   #32254:   (twangboy)   Fix   Display   Name   with   spaces   in
     win_servermanager

   * PR #32248: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32230: (terminalmage) systemd.py: Support  both  update-rc.d  and
     chkconfig as managers of sysv services

   * PR #32249: (jacobhammons) Fixes windows download paths to account for
     patch

   * PR #32221: (dmurphy18) Fix version check, fix  extracting  Major  and
     Minor versions from __ver...

   * PR #32227: (twangboy) Remove list2cmdline usage from win_service.py

   * PR #32239: (anlutro) Add state file name to warning log line

   * PR #32215: (DmitryKuzmenko) rhel oscodename

   * PR #32217: (jacobhammons) 2015.8.8.2 release notes

   * PR #32212: (rallytime) Back-port #32197 to 2015.8

   * PR #32211: (rallytime) Back-port #32210 to 2015.8

   * PR #32209: (rallytime) Back-port #32208 to 2015.8

   * PR  #32204: (ticosax) [dockerng] Consider labels carried by the image
     when comparing user defined labels.

   * PR #32186: (rallytime) Add some "best practices" information to  test
     documentation

   * PR #32176: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR  #32163:  (rallytime)  Update  nacl.config  docs  to use key value
     instead of 'None'

   * PR #32166: (vutny) salt.states.file: correct examples with  multiline
     YAML string

   * PR #32168: (rallytime) Lint 2015.8

   * PR  #32165:  (terminalmage)  Make  __virtual__  for rhservice.py more
     robust

   * PR #32160: (cachedout) Fix beacon tutorial docs

   * PR #32145: (paclat) fixes 29817

   * PR #32133:  (basepi)  Pass  eauth  user/groups  through  salt-api  to
     destination functions

   * PR #32127: (rallytime) Add runners to __salt__ docs

   * PR  #32143: (DmitryKuzmenko) Set auth retry count to 0 if multimaster
     mode is failover.

   * PR #32134: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32091: (clarkperkins) Fixed the regression in 410da78

   * PR #32135: (rallytime) [2015.8] Support multiple valid  option  types
     when performing type checks

   * PR #31760: (sakateka) SMinion need wait future from eval_master

   * PR #32106: (jfindlay) update suse master service patch

   * PR  #32130:  (jacobhammons)  Added  known  issues  32004 and 32044 to
     2015.8.8 release notes

   * PR #32105: (clarkperkins) Fixed invalid deploy_scripts_search_path

   * PR #32117: (tomlaredo) Fixed validation type for file_ignore_glob

   * PR #32113: (sakateka) Fix log message for AsyncAuth initialization

   * PR #32116: (ticosax) Obtain default value  of  memory_swap  from  the
     container.

   * PR #32098: (rallytime) Back-port #32083 to 2015.8

   * PR #32099: (jacobhammons) 2015.8.8 release docs

   * PR #32088: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * PR #32074: (Xiami2012) Fix code for proto args in modules.iptables

   * PR #32053: (basepi) [2015.8] Fix rabbitmq_user.present tag handling

   * PR  #32023: (sbreidba) Move constant declaration into member variable
     to avoid issues when m...

   * PR #32026: (techhat) Don't require the  decode_out  file  to  already
     exist

   * PR #32019: (rallytime) Back-port #32012 to 2015.8

   * PR #32015: (ticosax) [dockerng] Fix ports exposition when protocol is
     passed.

   * PR #31999: (jacobhammons) Fixes  a  doc  build  exception  caused  by
     missing mocks for modules.win_dacl

   * PR #31992: (notpeter) salt-cloud: add D2 and G2 EC2 instance types

   * PR  #31981:  (lloydoliver)  include  rotational disks in grains under
     linux

   * PR #31970: (twangboy) Add apply_template_on_contents for windows

   * PR #31960: (aletourneau) fixed ec2 get_console_output

   * PR #31958: (rallytime) [2015.8] Merge forward from 2015.5 to 2015.8

   * 3934c66 Merge branch '2015.5' into '2015.8'

   * PR #31935: (twangboy) Back port nullsoft build script from 2015.8

   * PR #31912: (jfindlay) log.mixins: remove extermporaneous .record

   Salt 2015.5.0 Release Notes - Codename Lithium
   The 2015.5.0 feature release of Salt is focused on hardening  Salt  and
   mostly  on  improving  existing  systems.  A  few  major  additions are
   present, primarily the new Beacon system. Most enhancements  have  been
   focused around improving existing features and interfaces.

   As usual the release notes are not exhaustive and primarily include the
   most notable additions and improvements. Hundreds  of  bugs  have  been
   fixed and many modules have been substantially updated and added.

   WARNING:
      In  order  to  fix potential shell injection vulnerabilities in salt
      modules, a change has been made to the various cmd module functions.
      These  functions now default to python_shell=False, which means that
      the commands will not be sent to an actual shell.

      The largest side effect of this change is that "shellisms", such  as
      pipes,  will not work by default. The modules shipped with salt have
      been audited to fix any issues that  might  have  arisen  from  this
      change.  Additionally, the cmd state module has been unaffected, and
      use of cmd.run in jinja is also unaffected. cmd.run calls on the CLI
      will also allow shellisms.

      However,  custom  execution modules which use shellisms in cmd calls
      will break, unless you pass python_shell=True to these calls.

      As a temporary workaround, you  can  set  cmd_safe:  False  in  your
      minion and master configs. This will revert the default, but is also
      less secure, as it will allow shell injection vulnerabilities to  be
      written  in  custom code. We recommend you only set this setting for
      as long as it takes to resolve these issues  in  your  custom  code,
      then remove the override.

   NOTE:
      Starting  in  this  version  of  salt, pillar_opts defaults to False
      instead of True. This means that master opts will not be present  in
      minion  pillar,  and  as a result, config.get calls will not include
      master opts.

      We recommend pillar is used for configuration options which need  to
      make it to the minion.

   Beacons
   The  beacon  system allows the minion to hook into system processes and
   continually translate external events into  the  salt  event  bus.  The
   primary example of this is the inotify beacon. This beacon uses inotify
   to watch configured files or directories on  the  minion  for  changes,
   creation, deletion etc.

   This  allows  for  the  changes  to  be sent up to the master where the
   reactor can respond to changes.

   Sudo Minion Settings
   It is now possible to run the minion as a non-root  user  and  for  the
   minion  to execute commands via sudo. Simply add sudo_user: root to the
   minion config, run the minion as a non-root user and  grant  that  user
   sudo rights to execute salt-call.

   Lazy Loader
   The  Lazy  Loader  is  a  significant  overhaul of Salt's module loader
   system. The Lazy Loader will lazily load modules on access  instead  of
   all  on  start.  In  addition  to a major performance improvement, this
   "sandboxes" modules so a bad/broken import of a single module will only
   affect jobs that require accessing the broken module. (:issue: 20274)

   Enhanced Active Directory Support
   The eauth system for LDAP has been extended to support Microsoft Active
   Directory out of the box. This includes Active Directory and LDAP group
   support for eauth.

   Salt LXC Enhancements
   The  LXC  systems have been overhauled to be more consistent and to fix
   many bugs.

   This overhaul makes using LXC with Salt much easier  and  substantially
   improves the underlying capabilities of Salt's LXC integration.

   Salt SSH
   * Additional  configuration  options  and  command line flags have been
     added to configure the scan roster on the fly

   * Added support for state.single in salt-ssh

   * Added   support   for   publish.publish,    publish.full_data,    and
     publish.runner in salt-ssh

   * Added support for mine.get in salt-ssh

   New Windows Installer
   The  new  Windows  installer  changes how Salt is installed on Windows.
   The  old  installer  used  bbfreeze  to  create  an   isolated   python
   environment  to  execute  in.  This  made  adding  modules  and  python
   libraries difficult. The new installer sets up a more  flexible  python
   environment  making it easy to manage the python install and add python
   modules.

   Instead of frozen packages, a full python implementation resides in the
   bin  directory  (C:\salt	in).  By  executing  pip or easy_install from
   within the Scripts directory (C:\salt	in\Scripts) you can install  any
   additional python modules you may need for your custom environment.

   The  .exe's  that  once  resided  at  the  root  of  the salt directory
   (C:\salt) have been replaced by .bat files and should function the same
   way as the .exe's in previous versions.

   The  new  Windows Installer will not replace the minion config file and
   key if they already exist on the target system. Only the  salt  program
   files  will  be  replaced.  C:\salt\conf  and  C:\salt\var  will remain
   unchanged.

   Removed Requests Dependency
   The hard dependency on the requests library has been removed.  Requests
   is  still  required  by  a  number  of  cloud  modules but is no longer
   required for normal Salt operations.

   This removal fixes  issues  that  were  introduced  with  requests  and
   salt-ssh,  as  well as issues users experienced from the many different
   packaging methods used by requests package maintainers.

   Python 3 Updates
   While Salt does not YET run on Python 3 it has been updated to  INSTALL
   on  Python  3,  taking  us one step closer. What remains is getting the
   test suite to the point where it can run on Python 3  so  that  we  can
   verify compatibility.

   RAET Additions
   The  RAET  support continues to improve. RAET now supports multi-master
   and many bugs and performance issues have  been  fixed.  RAET  is  much
   closer to being a first class citizen.

   Modified File Detection
   A number of functions have been added to the RPM-based package managers
   to detect and diff files that are modified from  the  original  package
   installs.  This can be found in the new pkg.modified functions.

   Reactor Update
   Fix  an  infinite  recursion  problem  for runner/wheel reactor jobs by
   passing a "user" (Reactor) to all jobs that  the  reactor  starts.  The
   reactor  skips  all  events  created  by  that username -- thereby only
   reacting to events not caused by itself. Because of  this,  runner  and
   wheel  executions  from  the runner will have user "Reactor" in the job
   cache.

   Misc Fixes/Additions
   * SDB driver for etcd. (:issue: 22043)

   * Add only_upgrade argument to apt-based pkg.install to only install  a
     package  version  if  the  package  is  already installed. (Great for
     security updates!)

   * Joyent now requires  a  keyname  to  be  specified  in  the  provider
     configuration. This change was necessitated upstream by the 7.0+ API.

   * Add  args  argument  to cmd.script_retcode to match cmd.script in the
     cmd module. (:issue: 21122)

   * Fixed bug where TCP keepalive was  not  being  sent  on  the  defined
     interval  on  the  return port (4506) from minion to master. (:issue:
     21465)

   * LocalClient may now optionally raise SaltClientError  exceptions.  If
     using  this  class directly, checking for and handling this exception
     is recommended.  (:issue: 21501)

   * The SAuth object is now a singleton, meaning authentication state  is
     global  (per master) on each minion. This reduces sign-ins of minions
     from 3->1 per startup.

   * Nested outputter has been optimized, it is now much faster.

   * Extensive fileserver backend updates.

   Deprecations
   * Removed parameter keyword argument from eselect.exec_action execution
     module.

   * Removed  runas  parameter  from  the  following pip` execution module
     functions:  install,   uninstall,   freeze,   list_,   list_upgrades,
     upgrade_available, upgrade. Please migrate to user.

   * Removed   runas   parameter  from  the  following  pip  state  module
     functions: installed, removed, uptodate . Please migrate to user.

   * Removed quiet option from all functions in cmdmod  execution  module.
     Please use output_loglevel=quiet instead.

   * Removed parameter argument from eselect.set_ state. Please migrate to
     module_parameter or action_parameter.

   * The salt_events table schema has changed  to  include  an  additional
     field  called  master_id to distinguish between events flowing into a
     database from multiple masters. If event_return  is  enabled  in  the
     master  config,  the database schema must first be updated to add the
     master_id field.  This alteration can be accomplished as follows:
        ALTER TABLE salt_events ADD master_id VARCHAR(255) NOT NULL;

   Known Issues
   * In multi-master mode, a minion may become temporarily unresponsive if
     modules  or  pillars  are refreshed at the same time that one or more
     masters  are  down.   This  can   be   worked   around   by   setting
     'auth_timeout' and 'auth_tries' down to shorter periods.

   Salt 2015.5.1 Release Notes
   release
          2015-05-20

   Version 2015.5.1 is a bugfix release for 2015.5.0.

   Changes:

   * salt.runners.cloud.action()  has  changed the fun keyword argument to
     func.  Please update any calls to this function in the cloud runner.

   Extended     Changelog     Courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   PR #23989: (rallytime) Backport #23980 to 2015.5
          @ 2015-05-20T19:33:41Z

          * PR #23980: (iggy) template: jinja2 -> jinja | refs: #23989

          * 117ecb1 Merge pull request #23989 from rallytime/bp-23980

          * 8f8557c template: jinja2 -> jinja

   PR #23988: (rallytime) Backport #23977 to 2015.5
          @ 2015-05-20T19:13:36Z

          * PR  #23977:  (ionutbalutoiu) Fixed glance image_create | refs:
            #23988

          * d4f1ba0 Merge pull request #23988 from rallytime/bp-23977

          * 46fc7c6 Fixed glance image_create

   PR #23986: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5
          @ 2015-05-20T18:41:33Z

          * PR #23965: (hvnsweeting) handle all exceptions  gitpython  can
            raise

          * 9566e7d      Merge      pull      request      #23986     from
            basepi/merge-forward-2015.5

          * 0b78156 Merge remote-tracking  branch  'upstream/2014.7'  into
            merge-forward-2015.5

          * 314e4db      Merge      pull      request      #23965     from
            hvnsweeting/20147-fix-gitfs-gitpython-exception

          * 2576301 handle all exception gitpython can raise

   PR #23985: (UtahDave) Add 2014.7.5-2 and 2015.5.0-2  Windows  installer
   download links
          @ 2015-05-20T18:32:44Z

          * 9d1130e Merge pull request #23985 from UtahDave/2015.5local

          * 10338d0 Add links to Windows 2015.5.0-2 install downloads

          * b84f975 updated Windows 2014.7.5-2 installer download link

   PR  #23983: (rallytime) Versionadded tags for https_user and https_pass
   args new in 2015.5.0
          @ 2015-05-20T18:05:27Z

          * ca7729d     Merge      pull      request      #23983      from
            rallytime/versionadded_git_options

          * 14eae22  Versionadded  tags for https_user and https_pass args
            new in 2015.5.0

   PR #23970: (jayeshka) adding system unit test case
          @ 2015-05-20T17:12:57Z

          * b06df57     Merge      pull      request      #23970      from
            jayeshka/system-unit-test

          * 89eb008 adding system unit test case

   PR #23967: (jayeshka) adding states/memcached unit test case
          @ 2015-05-20T17:12:26Z

          * 38d5f75      Merge      pull      request      #23967     from
            jayeshka/memcached-states-unit-test

          * 8ef9240 adding states/memcached unit test case

   PR #23966: (jayeshka) adding states/modjk unit test case
          @ 2015-05-20T17:11:48Z

          * 868e807     Merge      pull      request      #23966      from
            jayeshka/modjk-states-unit-test

          * 422a964 adding states/modjk unit test case

   PR #23942: (jacobhammons) Updates to sphinx saltstack2 doc theme
          @ 2015-05-20T15:43:54Z

          * 6316490 Merge pull request #23942 from jacobhammons/2015.5

          * 31023c8 Updates to sphinx saltstack2 doc theme

   PR #23874: (joejulian) Validate keyword arguments to be valid
          @ 2015-05-20T04:53:40Z

          * ISSUE  #23872:  (joejulian) create_ca_signed_cert can error if
            dereferenced dict is used for args | refs: #23874

          * 587957b     Merge      pull      request      #23874      from
            joejulian/2015.5_tls_validate_kwargs

          * 30102ac Fix py3 and ordering inconsistency problems.

          * 493f7ad Validate keyword arguments to be valid

   PR #23960: (rallytime) Backport #22114 to 2015.5
          @ 2015-05-20T04:37:09Z

          * PR  #22114:  (dmyerscough)  Fixing  KeyError when there are no
            additional pages | refs: #23960

          * 00c5c22 Merge pull request #23960 from rallytime/bp-22114

          * f3e1d63 Catch KeyError

          * 306b1ea Fixing KeyError

          * 6b2cda2 Fix PEP8 complaint

          * 239e50f Fixing KeyError when there are no additional pages

   PR #23961: (rallytime) Backport #23944 to 2015.5
          @ 2015-05-20T04:35:41Z

          * PR #23944: (ryan-lane)  Add  missing  loginclass  argument  to
            _changes call | refs: #23961

          * 4648b46 Merge pull request #23961 from rallytime/bp-23944

          * 970d19a Add missing loginclass argument to _changes call

   PR #23948: (jfindlay) augeas.change state now returns changes as a dict
          @ 2015-05-20T04:00:10Z

          * 0cb5cd3 Merge pull request #23948 from jfindlay/augeas_changes

          * f09b80a augeas.change state now returns changes as a dict

   PR #23957: (rallytime) Backport #23951 to 2015.5
          @ 2015-05-20T03:04:24Z

          * PR  #23951:  (ryan-lane)  Do  not  check perms in file.copy if
            preserve | refs: #23957

          * 2d185f7 Merge pull request #23957 from rallytime/bp-23951

          * 996b431 Update file.py

          * 85d461f Do not check perms in file.copy if preserve

   * PR   #23956:   (rallytime)    Backport    #23906    to    2015.5    @
     2015-05-20T03:04:14Z

     * ISSUE #23839: (gladiatr72) wonky loader syndrome | refs: #23906

     * ISSUE   #23373:  (tnypex)  reactor/orchestrate  race  condition  on
       salt['pillar.get'] | refs: #23906

     * PR  #23906:  (gladiatr72)  Added  exception  handler  to  trap  the
       RuntimeError raised when | refs: #23956

     * ebff1ff Merge pull request #23956 from rallytime/bp-23906

     * 9d87fd3 add proper marker for format argument

     * 197688e  Added  exception  handler  to trap the RuntimeError raised
       when    Depends.enforce_dependency()     class     method     fires
       unsuccessfully.  There  appears to be no synchronization within the
       Depends decorator class wrt the class global dependency_dict  which
       results  in  incomplete  population  of  any  loader  instantiation
       occurring at the time of one of these exceptions.

   * PR   #23955:   (rallytime)    Backport    #19305    to    2015.5    @
     2015-05-20T03:03:55Z

     * ISSUE  #19852: (TaiSHiNet) DigitalOcean APIv2 can't delete machines
       when there is only 1 page | refs: #23955

     * ISSUE #19304: (TaiSHiNet) DigitalOcean API v2 cannot delete VMs  on
       2nd page | refs: #19305

     * PR  #19305:  (TaiSHiNet)  Fixes droplet listing past page 1 | refs:
       #23955

     * da3f919 Merge pull request #23955 from rallytime/bp-19305

     * bbf2429 Fixes droplet listing past page 1

   * PR #23940: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-19T22:37:58Z

     * ISSUE #23820: (UtahDave) 2014.7.5 schedule error | refs: #23881

     * ISSUE  #22131:  (quixoten) "unexpected keyword argument 'merge'" on
       2014.7.2 (salt-ssh) | refs: #23887

     * PR #23939: (basepi) Add  extended  changelog  to  2014.7.6  release
       notes

     * PR #23887: (basepi) [2014.7] Bring salt-ssh pillar.get in line with
       mainline pillar.get

     * PR #23881: (garethgreenaway) Fixes to schedule module in 2014.7

     * 02a78fc Merge pull request #23940 from basepi/merge-forward-2015.5

     * 36f0065  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

       * 9133912 Merge pull request #23939 from basepi/v2014.7.6release

         * 32b65dc Add extended changelog to 2014.7.6 release notes

       * 0031ca2       Merge       pull      request      #23881      from
         garethgreenaway/23820_2014_7_schedule_list_issue

         * b207f2a Missing continue in the  list  function  when  deleting
           unused attributes.

       * 63bd21e       Merge       pull      request      #23887      from
         basepi/salt-ssh.pillar.get.22131

         * bc84502  Bring  salt-ssh  pillar.get  in  line  with   mainline
           pillar.get

   * PR    #23932:    (rallytime)    Backport    #23908    to   2015.5   @
     2015-05-19T21:41:28Z

     * PR #23908: (nleib) fix connection function to mongo | refs: #23932

     * ee4c01b Merge pull request #23932 from rallytime/bp-23908

     * 5d520c9 fix connection function to mongo

   * PR   #23931:   (rallytime)    Backport    #23880    to    2015.5    @
     2015-05-19T21:41:18Z

     * PR  #23880: (bastiaanb) if setting client_config_dir to '~', expand
       path | refs: #23931

     * 70bd407 Merge pull request #23931 from rallytime/bp-23880

     * 8ce59a2 if setting client_config_dir to '~', expand path

   * PR   #23898:   (kiorky)   Lxc   profiles    |    refs:    #23897    @
     2015-05-19T21:08:28Z

     * ISSUE  #23847:  (kiorky)  lxc:  systemd containers cant be seeded |
       refs: #23806 #23898 #23897 #23808

     * ISSUE #23833: (kiorky) lxc.set_dns  fails  intermittently  |  refs:
       #23898 #23807 #23897 #23808

     * ISSUE #23772: (cheuschober) lxc.init fails to bootstrap container |
       refs: #23806 #23898 #23807 #23897 #23808

     * ISSUE #23658: (arthurlogilab) [salt-cloud lxc] too  verbose,  shows
       host: True multiple times when starting | refs: #23898 #23897

     * ISSUE  #23657:  (arthurlogilab)  [salt-cloud lxc] NameError: global
       name '__salt__' is not defined | refs: #23727 #23898 #23897

     * PR #23897: (kiorky) Lxc seed and prof ports | refs: #23898

     * PR #23808: (kiorky) Lxc seed and prof ports | refs: #23807 #23897

     * PR #23807: (kiorky) Lxc profiles | refs: #23898

     * PR #23806: (kiorky) Lxc seeding | refs: #23807

     * 5bdbf0a Merge pull request #23898 from makinacorpus/lxc_profiles

     * d9051a0 lxc: systemd support

     * e8d674f lxc: chroot fallback toggle

     * e2887a0 lxc: sync func name with develop

     * e96e345 lxc more fixes (lxc.set_dns)

     * fdb6424 lxc: Fix salt config (no more a kwarg)

     * 63e63fa repair salt cloud lxc api on develop

     * 80eabe2 lxc salt cloud doc

     * 73f229d lxc: unificate saltconfig/master/master_port

     * 0bc1f08 lxc: refactor a bit saltcloud/lxc interface

     * 7a80370 lxc: get networkprofile from saltcloud

     * 47acb2e lxc: default net profile has now correct options

     * 7eadf48 lxc: select the appropriate default bridge

   * PR   #23922:    (garethgreenaway)    Fixes    to    debian_ip.py    @
     2015-05-19T18:50:53Z

     * ISSUE   #23900:  (hashi825)  salt  ubuntu  network  building  issue
       2015.5.0 | refs: #23922

     * b818f72      Merge       pull       request       #23922       from
       garethgreenaway/23900_2015_5_bonding_interface_fixes

     * 0bba536  Fixing  issue  reported  when  using  bonded interfaces on
       Ubuntu.  Attributes should be bond-, but the code was attempting to
       split just on
       bond_
       .   Fix  accounts  for both, but the debian_ip.py module will write

       out bond attributes with bond-
   * PR #23925: (jpic) Fixed wrong  path  in  LXC  cloud  documentation  @
     2015-05-19T18:23:56Z

     * PR  #23924:  (jpic)  Fixed  wrong path in LXC cloud documentation |
       refs: #23925

     * b1c98a3 Merge pull request #23925 from jpic/fix/wrong_lxc_path

     * a4bcd75 Fixed wrong path in LXC cloud documentation

   * PR #23894: (whiteinge) Add __all__ attribute to Mock class for docs @
     2015-05-19T17:17:35Z

     * 7f6a716 Merge pull request #23894 from whiteinge/doc-mock__all__

     * 6eeca46 Add __all__ attribute to Mock class for docs

   * PR   #23884:   (jfindlay)   Fix   locale.set_locale   on   debian   @
     2015-05-19T15:51:22Z

     * ISSUE #23767: (chrimi) Salt system.locale  fails  on  non  existent
       default locale | refs: #23884

     * 8108a9b Merge pull request #23884 from jfindlay/fix_locale

     * 91c2d51 use append_if_not_found in locale.set_locale

     * e632603 (re)generate /etc/default/locale

   * PR #23866: (jfindlay) backport #23834, change portage.dep.strip_empty
     to list comprehension @ 2015-05-19T15:50:43Z

     * PR   #23834:    (Arabus)    Avoid    deprecation    warning    from
       portage.dep.strip_empty() | refs: #23866

     * 6bae12f Merge pull request #23866 from jfindlay/flag_strip

     * aa032cc replace portage.dep.strip_empty() with list comprehension

     * 7576872  Proper replacement for portage.dep.strip_empty() with list
       comprehension, pep8fix

     * 2851a5c Switch portage.dep.strip_empty(...) to filter(None,...)  to
       avoid deprecation warning and do essentially the same

   * PR  #23917: (corywright) Split debian bonding options on dash instead
     of underscore @ 2015-05-19T15:44:35Z

     * ISSUE #23904: (mbrgm) Network  config  bonding  section  cannot  be
       parsed when attribute names use dashes | refs: #23917

     * a67a008 Merge pull request #23917 from corywright/issue23904

     * c06f8cf Split debian bonding options on dash instead of underscore

   * PR  #23909:  (jayeshka) 'str' object has no attribute 'capitalized' @
     2015-05-19T15:41:53Z

     * e8fcd09 Merge pull request #23909 from jayeshka/file-exe-module

     * e422d9d 'str' object has no attribute 'capitalized'

   * PR #23903: (garethgreenaway) Adding docs for missing  schedule  state
     module parameters.  @ 2015-05-19T06:29:34Z

     * c73bf38       Merge       pull       request       #23903      from
       garethgreenaway/missing_docs_schedule_state

     * acd8ab9 Adding docs for missing schedule state module parameters.

   * f7eb70c changed previous release to 2014.7.6

   * 608059f Merge branch '2015.5' of https://github.com/jacobhammons/salt
     into 2015.5

     * a56697b  Merge branch '2015.5' of https://github.com/saltstack/salt
       into 2015.5

     * 1c2af5c Merge branch '2015.5' of  https://github.com/saltstack/salt
       into 2015.5

     * ef58128  Merge branch '2015.5' of https://github.com/saltstack/salt
       into 2015.5

     * 8664e8b Merge branch '2015.5' of  https://github.com/saltstack/salt
       into 2015.5-2

     * 46eb265 saltstack2 sphinx theme updates

     * e7442d3  Merge branch '2015.5' of https://github.com/saltstack/salt
       into 2015.5

     * ee3c1bd missed one

     * 3872921 More updates to sphinx2 theme

     * fcd4865 Merge branch '2015.5' of  https://github.com/saltstack/salt
       into 2015.5

     * 8c32152 removed TOC numbering, additional tweaks to layout.html

     * 73dfaef  Merge branch '2015.5' of https://github.com/saltstack/salt
       into 2015.5

     * 16d8a75 saltstack2 sphinx theme and build settings

   * PR #23806: (kiorky) Lxc seeding | refs: #23807 @ 2015-05-18T23:18:33Z

     * ISSUE #23847: (kiorky) lxc: systemd containers  cant  be  seeded  |
       refs: #23806 #23898 #23897 #23808

     * ISSUE #23772: (cheuschober) lxc.init fails to bootstrap container |
       refs: #23806 #23898 #23807 #23897 #23808

     * ff3cc7d Merge pull request #23806 from makinacorpus/lxc_seeding

     * 61b7aad runners/lxc: optim

   * PR #23892: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-18T23:07:57Z

     * PR #23891: (basepi) Update the release notes index page

     * PR  #23888:  (basepi)  Update  the  2014.7.6 release notes with CVE
       details

     * PR #23871: (rallytime) Backport #23848 to 2014.7

     * PR #23848: (dumol) Updated installation docs for SLES 12.  |  refs:
       #23871

     * 5f1a93d Merge pull request #23892 from basepi/merge-forward-2015.5

     * c2eed77   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

     * 17c5810 Merge pull request #23891 from basepi/releasenotes

       * dec153b Update the release notes index page

     * a93e58f Merge pull request #23888 from basepi/v2014.7.6release

       * 49921b6 Update the 2014.7.6 release notes with CVE details

     * 5073028 Merge pull request #23871 from rallytime/bp-23848

       * 379c09c Updated for SLES 12.

   * PR   #23875:   (rallytime)    Backport    #23838    to    2015.5    @
     2015-05-18T22:28:55Z

     * PR #23838: (gtmanfred) add refresh_beacons and sync_beacons | refs:
       #23875

     * 66d1335 Merge pull request #23875 from rallytime/bp-23838

     * 3174227  Add  versionadded  directives  to  new   beacon   saltutil
       functions

     * 4a94b2c add refresh_beacons and sync_beacons

   * PR  #23876:  (rallytime)  Switch  digital  ocean tests to v2 driver @
     2015-05-18T22:17:13Z

     * d294cf2      Merge       pull       request       #23876       from
       rallytime/switch_digital_ocean_tests_v2

     * dce9b54 Remove extra line

     * 4acf58e Switch digital ocean tests to v2 driver

   * PR   #23882:   (garethgreenaway)  Fixes  to  scheduler  in  2015.5  @
     2015-05-18T22:09:24Z

     * ISSUE #23792: (neogenix) Salt Scheduler Incorrect  Response  (True,
       should be False) | refs: #23882

     * b97a48c       Merge       pull       request       #23882      from
       garethgreenaway/23792_2015_5_wrong_return_code

     * 37dbde6 Job already exists in schedule, should return False.

   * PR #23868: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-18T18:35:54Z

     * ISSUE   #20198:   (jcftang)  virt.get_graphics,  virt.get_nics  are
       broken, in turn breaking other things | refs: #23809

     * PR #23823: (gtmanfred) add link local for ipv6

     * PR #23810: (rallytime) Backport #23757 to 2014.7

     * PR #23809: (rallytime) Fix  virtualport  section  of  virt.get_nics
       loop

     * PR #23802: (gtmanfred) if it is ipv6 ip_to_int will fail

     * PR  #23757: (clan) use abspath, do not eliminating symlinks | refs:
       #23810

     * PR #23573: (techhat) Scan all available  networks  for  public  and
       private IPs | refs: #23802

     * PR #21487: (rallytime) Backport #21469 to 2014.7 | refs: #23809

     * PR   #21469:  (vdesjardins)  fixes  #20198:  virt.get_graphics  and
       virt.get_nics calls in module virt | refs: #21487

     * 61c922e Merge pull request #23868 from basepi/merge-forward-2015.5

     * c9ed233  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * aee00c8 Merge pull request #23810 from rallytime/bp-23757

       * fb32c32 use abspath, do not eliminating symlinks

     * 6b3352b Merge pull request #23809 from rallytime/virt_get_nics_fix

       * 0616fb7 Fix virtualport section of virt.get_nics loop

     * 188f03f Merge pull request #23823 from gtmanfred/2014.7

       * 5ef006d add link local for ipv6

     * f3ca682 Merge pull request #23802 from gtmanfred/2014.7

       * 2da98b5 if it is ipv6 ip_to_int will fail

   * PR   #23863:   (rahulhan)   Adding  states/timezone.py  unit  test  @
     2015-05-18T17:02:19Z

     * 433f873      Merge       pull       request       #23863       from
       rahulhan/states_timezone_unit_test

     * 72fcabc Adding states/timezone.py unit test

   * PR   #23862:   (rahulhan)   Adding   states/tomcat.py  unit  tests  @
     2015-05-18T17:02:10Z

     * 37b3ee5      Merge       pull       request       #23862       from
       rahulhan/states_tomcat_unit_test

     * 65d7752 Adding states/tomcat.py unit tests

   * PR   #23860:   (rahulhan)   Adding   states/test.py   unit   tests  @
     2015-05-18T17:01:49Z

     * dde7207      Merge       pull       request       #23860       from
       rahulhan/states_test_unit_test

     * 1f4cf86 Adding states/test.py unit tests

   * PR   #23859:   (rahulhan)   Adding   states/sysrc.py   unit  tests  @
     2015-05-18T17:01:46Z

     * 3c9b813      Merge       pull       request       #23859       from
       rahulhan/states_sysrc_unit_test

     * 6a903b0 Adding states/sysrc.py unit tests

   * PR    #23812:    (rallytime)    Backport    #23790    to   2015.5   @
     2015-05-18T15:30:34Z

     * PR #23790: (aboe76) updated suse spec file to  version  2015.5.0  |
       refs: #23812

     * 4cf30a7 Merge pull request #23812 from rallytime/bp-23790

     * 3f65631 updated suse spec file to version 2015.5.0

   * PR    #23811:    (rallytime)    Backport    #23786    to   2015.5   @
     2015-05-18T15:30:27Z

     * PR  #23786:  (kaithar)  Log  the  error   generated   that   causes
       returns.mysql.returner to except.  | refs: #23811

     * c6f939a Merge pull request #23811 from rallytime/bp-23786

     * 346f30b  Log the error generated that causes returns.mysql.returner
       to except.

   * PR  #23850:   (jayeshka)   adding   sysbench   unit   test   case   @
     2015-05-18T15:28:04Z

     * ce60582 Merge pull request #23850 from jayeshka/sysbench-unit-test

     * 280abde adding sysbench unit test case

   * PR  #23843:  (The-Loeki)  Fix  erroneous  virtual:physical core grain
     detection @ 2015-05-18T15:24:22Z

     * 060902f Merge pull request #23843 from The-Loeki/patch-1

     * 9e2cf60 Fix erroneous virtual:physical core grain detection

   * PR #23816: (Snergster) Doc for  #23685  Added  prereq,  caution,  and
     additional mask information @ 2015-05-18T15:18:03Z

     * ISSUE  #23815:  (Snergster)  [beacons]  inotify  errors  on  subdir
       creation | refs: #23816

     * 3257a9b Merge pull request #23816 from Snergster/23685-doc-fix

     * 0fca49d Added prereq, caution, and additional mask information

   * PR #23832:  (ahus1)  make  saltify  provider  use  standard  boostrap
     procedure @ 2015-05-18T02:18:29Z

     * PR  #23829:  (ahus1)  make  saltify  provider use standard boostrap
       procedure | refs: #23832

     * 3df3b85      Merge       pull       request       #23832       from
       ahus1/ahus1_saltify_bootstrap_2015.5

     * f5b1734 fixing problem in unit test

     * cba47f6  make saltify to use standard boostrap procedure, therefore
       providing all options like master_sign_pub_file

   * PR #23791: (optix2000) Psutil compat @ 2015-05-16T04:05:54Z

     * 8ec4fb2 Merge pull request #23791 from optix2000/psutil_compat

     * 5470cf5 Fix pylint errors and sloppy inline comments

     * 64634b6 Update psutil.pid_list to use psutil.pids

     * 5dd6d69 Fix imports that aren't in __all__

     * 8a1da33 Fix test cases by mocking psutil_compat

     * 558798d Fix net_io_counters deprecation issue

     * 8140f92 Override unnecessary pylint errors

     * 7d02ad4 Fix some of the mock names for the new API

     * 9b3023e Fix overloaded getters/setters. Fix line lengths

     * 180eb87 Fix whitespace

     * f8edf72 Use new psutil API in ps module

     * e48982f Fix version checking in psutil_compat

     * 93ee411 Create compatibility psutil. psutil 3.0 drops 1.0 API,  but
       we still support old psutil versions.

   * PR  #23782:  (terminalmage) Replace "command -v" with "which" and get
     rid of spurious log messages @ 2015-05-16T04:03:10Z

     * 405517b Merge pull request #23782 from terminalmage/issue23772

     * 0f6f239 More ignore_retcode to suppress spurious log msgs

     * b4c48e6 Ignore return code in lxc.attachable

     * 08658c0 Replace "command -v" with "which"

   * PR #23783: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-15T21:38:51Z

     * ISSUE   #22959:   (highlyunavailable)   Windows   Salt   hangs   if
       file.directory is trying to write to a drive that doesn't exist

     * ISSUE #22332: (rallytime)  [salt-ssh]  Add  a  check  for  host  in
       /etc/salt/roster | refs: #23748

     * ISSUE #16424: (stanvit) salt-run cloud.create fails with saltify

     * PR #23748: (basepi) [2014.7] Log salt-ssh roster render errors more
       assertively and verbosely

     * PR #23731: (twangboy) Fixes #22959: Trying to add a directory to an
       unmapped drive in windows

     * PR #23730: (rallytime) Backport #23729 to 2014.7

     * PR  #23729: (rallytime) Partially merge #23437 (grains fix) | refs:
       #23730

     * PR #23688: (twangboy) Added inet_pton to utils/validate/net.py  for
       ip.set_static_ip in windows

     * PR #23488: (cellscape) LXC cloud fixes

     * PR #23437: (cedwards) Grains item patch | refs: #23729

     * cb2eb40 Merge pull request #23783 from basepi/merge-forward-2015.5

     * 9df51ca __opts__.get

     * 51d23ed   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

       * d9af0c3 Merge pull request #23488 from cellscape/lxc-cloud-fixes

         * 64250a6 Remove profile from opts after creating LXC container

         * c4047d2 Set destroy=True in opts when destroying cloud instance

         * 9e1311a Store instance names  in  opts  when  performing  cloud
           action

         * 934bc57 Correctly pass custom env to lxc-attach

         * 7fb85f7 Preserve test=True option in cloud states

         * 9771b5a Fix detection of absent LXC container in cloud state

         * fb24f0c   Report   failure  when  failed  to  create/clone  LXC
           container

         * 2d9aa2b Avoid shadowing variables in lxc module

         * 792e102     Allow     overriding     profile     options     in
           lxc.cloud_init_interface

         * 42bd64b Return changes on successful lxc.create from salt-cloud

         * 4409eab Return correct result when creating cloud LXC container

         * 377015c   Issue   #16424:  List  all  providers  when  creating
           salt-cloud instance without profile

       * 808bbe1      Merge      pull      request       #23748       from
         basepi/salt-ssh.roster.host.check

         * bc53e04 Log entire exception for render errors in roster

         * 753de6a Log render errors in roster to error level

         * e01a7a9 Always let the real YAML error through

       * 72cf360 Merge pull request #23731 from twangboy/fix_22959

         * 88e5495  Fixes #22959: Trying to add a directory to an unmapped
           drive in windows

       * 2610195 Merge pull request #23730 from rallytime/bp-23729

         * 1877cae adding support for nested grains to grains.item

       * 3e9df88 Merge pull request #23688 from twangboy/fix_23415

         * 6a91169 Fixed unused-import pylint error

         * 5e25b3f fixed pylint errors

         * 1a96766   Added   inet_pton   to   utils/validate/net.py    for
           ip.set_static_ip in windows

   * PR   #23781:   (jfindlay)  fix  unit  test  mock  errors  on  arch  @
     2015-05-15T19:40:07Z

     * 982f873 Merge pull request #23781 from jfindlay/fix_locale_tests

     * 14c711e fix unit test mock errors on arch

   * PR #23740: (jfindlay) Binary write @ 2015-05-15T18:10:44Z

     * ISSUE #23566: (rks2286) Salt-cp corrupting the file after  transfer
       to minion | refs: #23740

     * 916b1c4 Merge pull request #23740 from jfindlay/binary_write

     * 626930a update incorrect comment wording

     * a978f5c always use binary file write mode on windows

   * PR   #23736:   (jfindlay)   always   load   pip  execution  module  @
     2015-05-15T18:10:16Z

     * ISSUE #23682: (chrish42) Pip module requires system pip, even  when
       not used (with env_bin) | refs: #23736

     * 348645e Merge pull request #23736 from jfindlay/fix_pip

     * b8867a8 update pip tests

     * 040bbc4 only check pip version in one place

     * 6c453a5 check for executable status of bin_env

     * 3337257 always load the pip module as pip could be anywhere

   * PR   #23770:  (cellscape)  Fix  cloud  LXC  container  destruction  @
     2015-05-15T17:38:59Z

     * 10cedfb      Merge       pull       request       #23770       from
       cellscape/fix-cloud-lxc-destruction

     * 4f6021c Fix cloud LXC container destruction

   * PR  #23759: (lisa2lisa) fixed the problem for not beable to revoke .,
     for more detail https... @ 2015-05-15T17:38:38Z

     * ddea822 Merge pull request #23759 from lisa2lisa/iss23664

     * a29f161 fixed the problem for not beable  to  revoke  .,  for  more
       detail  https://github.com/saltstack/salt/issues/23201, fixed mysql
       cannot  create  user  with  pure  digit  password,  for  more  info
       https://github.com/saltstack/salt/issues/23664

   * PR    #23769:    (cellscape)    Fix    file_roots    CA   lookup   in
     salt.utils.http.get_ca_bundle @ 2015-05-15T16:21:49Z

     * 10615ff      Merge       pull       request       #23769       from
       cellscape/utils-http-ca-file-roots

     * 8e90f32 Fix file_roots CA lookup in salt.utils.http.get_ca_bundle

   * PR  #23765:  (jayeshka)  adding  states/makeconf  unit  test  case  @
     2015-05-15T14:29:43Z

     * fd8a1b7      Merge       pull       request       #23765       from
       jayeshka/makeconf_states-unit-test

     * 26e31af adding states/makeconf unit test case

   * PR    #23760:   (ticosax)   [doc]   document   refresh   argument   @
     2015-05-15T14:23:47Z

     * ee13b08 Merge pull request #23760 from ticosax/2015.5

     * e3ca859 document refresh argument

   * PR   #23766:   (jayeshka)   adding   svn    unit    test    case    @
     2015-05-15T14:23:18Z

     * a017f72 Merge pull request #23766 from jayeshka/svn-unit-test

     * 19939cf adding svn unit test case

   * PR    #23751:    (rallytime)    Backport    #23737    to   2015.5   @
     2015-05-15T03:58:37Z

     * ISSUE #23734:  (bradthurber)  2015.5.0  modules/archive.py  ZipFile
       instance  has  no  attribute '__exit__' - only python 2.6?  | refs:
       #23737

     * PR  #23737:  (bradthurber)  fix  for  2015.5.0   modules/archive.py
       ZipFile instance has no attribute... | refs: #23751

     * 0ed9d45 Merge pull request #23751 from rallytime/bp-23737

     * 8d1eb32 fix for 2015.5.0 modules/archive.py ZipFile instance has no
       attribute '__exit__' - only python 2.6? #23734

   * PR #23710: (kiorky) Get more useful output from stateful  commands  @
     2015-05-14T21:58:10Z

     * ISSUE  #23709:  (kiorky)  cmdmod:  enhancement is really needed for
       stateful commands | refs: #23710

     * d73984e Merge pull request #23710 from makinacorpus/i23709

     * c706909 Get more useful output from stateful commands

   * PR   #23724:   (rallytime)    Backport    #23609    to    2015.5    @
     2015-05-14T19:34:22Z

     * PR  #23609:  (kaidokert) file_map: chown created directories if not
       root #23608 | refs: #23724

     * cdf421b Merge pull request #23724 from rallytime/bp-23609

     * fe3a762 file_map: chmod created directories if not root

   * PR   #23723:   (rallytime)    Backport    #23568    to    2015.5    @
     2015-05-14T19:34:11Z

     * PR #23568: (techhat) Allow Salt Cloud to use either SCP or SFTP, as
       configured | refs: #23723

     * 94f9099 Merge pull request #23723 from rallytime/bp-23568

     * bbec34a Allow Salt Cloud to use either SCP or SFTP, as configured

   * PR   #23725:   (rallytime)    Backport    #23691    to    2015.5    @
     2015-05-14T19:32:30Z

     * PR  #23691: (dennisjac) add initial configuration documentation for
       varstack pillar | refs: #23725

     * 137e5ee Merge pull request #23725 from rallytime/bp-23691

     * 28a846e add initial configuration documentation for varstack pillar

   * PR   #23722:   (rallytime)    Backport    #23472    to    2015.5    @
     2015-05-14T19:31:52Z

     * PR  #23472:  (techhat)  Allow  neutron  network  list to be used as
       pillar data | refs: #23722

     * 0c00995 Merge pull request #23722 from rallytime/bp-23472

     * c3d0f39 Change versionadded tag for backport

     * 023e88f Allow neutron network list to be used as pillar data

   * PR  #23727:  (jfindlay)  fix  npm  execution  module   stacktrace   @
     2015-05-14T18:14:12Z

     * ISSUE  #23657:  (arthurlogilab)  [salt-cloud lxc] NameError: global
       name '__salt__' is not defined | refs: #23727 #23898 #23897

     * cbf4ca8 Merge pull request #23727 from jfindlay/npm_salt

     * 05392f2 fix npm execution module stacktrace

   * PR  #23718:   (rahulhan)   Adding   states/user.py   unit   tests   @
     2015-05-14T17:15:38Z

     * ef536d5       Merge       pull       request       #23718      from
       rahulhan/states_user_unit_tests

     * aad27db Adding states/user.py unit tests

   * PR #23720: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-14T17:13:02Z

     * ISSUE  #23604:  (Azidburn) service.dead on systemd Minion create an
       Error Message | refs: #23607

     * ISSUE #23548: (kkaig) grains.list_present  produces  incorrect  (?)
       output | refs: #23674

     * ISSUE  #23403:  (iamfil) salt.runners.cloud.action fun parameter is
       replaced | refs: #23680

     * PR #23680: (cachedout) Rename kwarg in cloud runner

     * PR    #23674:    (cachedout)    Handle    lists    correctly     in
       grains.list_prsesent

     * PR #23672: (twangboy) Fix user present

     * PR #23670: (rallytime) Backport #23607 to 2014.7

     * PR  #23607: (Azidburn) Fix for #23604. No error reporting. Exitcode
       !=0 are ok | refs: #23670

     * a529d74 Merge pull request #23720 from basepi/merge-forward-2015.5

     * 06a3ebd  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * 1b86460 Merge pull request #23680 from cachedout/issue_23403

       * d5986c2 Rename kwarg in cloud runner

     * cd64af0 Merge pull request #23674 from cachedout/issue_23548

       * da8a2f5 Handle lists correctly in grains.list_prsesent

     * d322a19 Merge pull request #23672 from twangboy/fix_user_present

       * 731e7af          Merge         branch         '2014.7'         of
         https://github.com/saltstack/salt into fix_user_present

       * d6f70a4 Fixed user.present to create password in windows

     * 43f7025 Merge pull request #23670 from rallytime/bp-23607

       * ed30dc4 Fix for #23604. No error reporting. Exitcode !=0 are ok

   * PR #23704: (jayeshka)  adding  states/lvs_server  unit  test  case  @
     2015-05-14T14:22:10Z

     * 13facbf       Merge       pull       request       #23704      from
       jayeshka/lvs_server_states-unit-test

     * da323da adding states/lvs_server unit test case

   * PR #23703: (jayeshka) adding  states/lvs_service  unit  test  case  @
     2015-05-14T14:21:23Z

     * f95ca31       Merge       pull       request       #23703      from
       jayeshka/lvs_service_states-unit-test

     * 66717c8 adding states/lvs_service unit test case

   * PR  #23702:  (jayeshka)  Remove  superfluous  return  statement.    @
     2015-05-14T14:20:42Z

     * 07e987e Merge pull request #23702 from jayeshka/fix_lvs_service

     * ecff218 fix lvs_service

   * PR   #23686:   (jfindlay)   remove  superfluous  return  statement  @
     2015-05-14T14:20:18Z

     * 39973d4 Merge pull request #23686 from jfindlay/fix_lvs_server

     * 5aaeb73 remove superfluous return statement

   * PR   #23690:   (rallytime)    Backport    #23424    to    2015.5    @
     2015-05-13T23:04:36Z

     * PR  #23424:  (jtand)  Added  python_shell=True  for  refresh_db  in
       pacman.py | refs: #23690

     * be7c7ef Merge pull request #23690 from rallytime/bp-23424

     * 94574b7 Added python_shell=True for refresh_db in pacman.py

   * PR  #23681:  (cachedout)  Start   on   2015.5.1   release   notes   @
     2015-05-13T19:44:22Z

     * 1a0db43       Merge       pull       request       #23681      from
       cachedout/2015_5_1_release_notes

     * bdbbfa6 Start on 2015.5.1 release notes

   * PR #23679: (jfindlay) Merge #23616 @ 2015-05-13T19:03:53Z

     * PR #23616: (Snergster) virtual returning none warning fixed in  dev
       but missed in 2015.5 | refs: #23679

     * b54075a Merge pull request #23679 from jfindlay/merge_23616

     * 6e15e19 appease pylint's blank line strictures

     * 8750680  virtual  returning none warning fixed in dev but missed in
       2015.5

   * PR #23675: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-13T18:35:54Z

     * ISSUE #23611: (hubez) master_type set to 'failover' but 'master' is
       not of type list but of type <type 'str'> | refs: #23637

     * ISSUE #23479: (danielmorlock) Typo in pkg.removed  for  Gentoo?   |
       refs: #23558

     * ISSUE  #23452:  (michaelforge)  minion  crashed  with empty grain |
       refs: #23639

     * ISSUE #23411: (dr4Ke) grains.append should work at any level  of  a
       grain | refs: #23440

     * ISSUE #23355: (dr4Ke) salt-ssh: 'sources: salt://' files from 'pkg'
       state are not included in salt_state.tgz | refs: #23530

     * ISSUE  #23110:  (martinhoefling)  Copying  files  from   gitfs   in
       file.recurse state fails

     * ISSUE  #23004:  (b18)  2014.7.5 - Windows - pkg.list_pkgs - "nxlog"
       never shows up in output.  | refs: #23433

     * ISSUE #22908: (karanjad) Add failhard option to salt  orchestration
       | refs: #23389

     * ISSUE  #22141: (Deshke) grains.get_or_set_hash render error if hash
       begins with "%" | refs: #23640

     * PR #23661: (rallytime) Merge #23640 with whitespace fix

     * PR  #23640:  (cachedout)  Add  warning  to  get_or_set_hash   about
       reserved chars | refs: #23661

     * PR #23639: (cachedout) Handle exceptions raised by __virtual__

     * PR #23637: (cachedout) Convert str master to list

     * PR  #23606:  (twangboy)  Fixed  checkbox  for  starting service and
       actually starting it

     * PR #23595: (rallytime) Backport #23549 to 2014.7

     * PR #23594: (rallytime) Backport #23496 to 2014.7

     * PR #23593: (rallytime) Backport #23442 to 2014.7

     * PR #23592: (rallytime) Backport #23389 to 2014.7

     * PR #23573: (techhat) Scan all available  networks  for  public  and
       private IPs | refs: #23802

     * PR #23558: (jfindlay) reorder emerge command line

     * PR #23554: (jleroy) Debian: Hostname always updated

     * PR #23551: (dr4Ke) grains.append unit tests, related to #23474

     * PR #23549: (vr-jack) Update __init__.py | refs: #23595

     * PR #23537: (t0rrant) Update changelog

     * PR  #23530:  (dr4Ke)  salt-ssh  state:  fix  including  all salt://
       references

     * PR #23496: (martinhoefling) Fix for issue #23110 | refs: #23594

     * PR #23474: (dr4Ke) Fix grains.append in  nested  dictionary  grains
       #23411

     * PR #23442: (clan) add directory itself to keep list | refs: #23593

     * PR  #23440:  (dr4Ke)  fix grains.append in nested dictionary grains
       #23411 | refs: #23474

     * PR #23433: (twangboy) Obtain all software from the registry

     * PR #23389: (cachedout) Correct fail_hard typo | refs: #23592

     * e480f13 Merge pull request #23675 from basepi/merge-forward-2015.5

     * bd63548  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

       * 0f006ac Merge pull request #23661 from rallytime/merge-23640

         * 4427f42 Whitespace fix

         * dd91154 Add warning to get_or_set_hash about reserved chars

       * 84e2ef8 Merge pull request #23639 from cachedout/issue_23452

         * d418b49 Syntax error!

         * 45b4015 Handle exceptions raised by __virtual__

       * bd9b94b Merge pull request #23637 from cachedout/issue_23611

         * 56cb1f5 Fix typo

         * f6fcf19 Convert str master to list

       * f20c0e4 Merge pull request #23595 from rallytime/bp-23549

         * 6efcac0 Update __init__.py

       * 1acaf86 Merge pull request #23594 from rallytime/bp-23496

         * d5ae1d2  Fix  for  issue  #23110  This resolves issues when the
           freshly created directory is removed by fileserver.update.

       * 2c221c7 Merge pull request #23593 from rallytime/bp-23442

         * 39869a1 check w/ low['name'] only

         * 304cc49 another fix for file defined w/ id, but require name

         * 8814d41 add directory itself to keep list

       * fadd1ef Merge pull request #23606 from twangboy/fix_installer

         * 038331e  Fixed  checkbox  for  starting  service  and  actually
           starting it

     * acdd3fc Fix lint

     * 680e88f   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

       * 10b3f0f Merge pull request #23592 from rallytime/bp-23389

         * 734cc43 Correct fail_hard typo

       * cd34b9b Merge pull request #23573 from techhat/novaquery

         * f92db5e Linting

         * 26e00d3 Scan all available networks for public and private IPs

       * 2a72cd7 Merge pull request #23558 from jfindlay/fix_ebuild

         * 45404fb reorder emerge command line

       * a664a3c      Merge      pull      request       #23530       from
         dr4Ke/fix_salt-ssh_to_include_pkg_sources

         * 5df6a80 fix pylint warning

         * d0549e5 salt-ssh state: fix including all salt:// references

       * 55c3869 Merge pull request #23433 from twangboy/list_pkgs_fix

         * 8ab5b1b Fix pylint error

         * 2d11d65 Obtain all software from the registry

       * 755bed0 Merge pull request #23554 from jleroy/debian-hostname-fix

         * 5ff749e Debian: Hostname always updated

       * 6ec87ce       Merge       pull      request      #23551      from
         dr4Ke/grains.append_unit_tests

         * ebff9df fix pylint errors

         * c495404 unit tests for grains.append module function

         * 0c9a323 use MagickMock

         * c838a22 unit tests for grains.append module function

       * e96c5c5      Merge      pull      request       #23474       from
         dr4Ke/fix_grains.append_nested

         * a01a5bb   grains.get,   parameter   delimititer,  versionadded:
           2014.7.6

         * b39f504 remove debugging output

         * b6e15e2 fix grains.append in nested dictionary grains #23411

       * ab7e1ae Merge pull request #23537 from t0rrant/patch-1

         * 8e03cc9 Update changelog

   * PR   #23669:   (rallytime)    Backport    #23586    to    2015.5    @
     2015-05-13T18:27:11Z

     * PR              #23586:              (Lothiraldan)              Fix
       salt.state.file._unify_sources_and_hashes  when  sources  is   used
       without sources_hashes | refs: #23669

     * 0dad6be Merge pull request #23669 from rallytime/bp-23586

     * ef4c6ad Remove another unused import

     * 73cfda7 Remove unused import

     * 52b68d6   Use   the  zip_longest  from  six  module  for  python  3
       compatibility

     * 18d5ff9 Fix salt.state.file._unify_sources_and_hashes when  sources
       is used without sources_hashes

   * PR   #23662:   (rallytime)   Merge   #23642   with   pylint   fix   @
     2015-05-13T15:46:51Z

     * PR #23642: (cachedout) Let saltmod  handle  lower-level  exceptions
       gracefully | refs: #23662

     * fabef75 Merge pull request #23662 from rallytime/merge-23642

     * aa7bbd8 Remove unused import

     * 9e66d4c Let saltmod handle lower-level exceptions gracefully

   * PR #23622: (jfindlay) merge #23508 @ 2015-05-13T15:36:49Z

     * PR  #23508:  (cro)  Port  mysql  returner  to  postgres using jsonb
       datatype | refs: #23622

     * 072b927 Merge pull request #23622 from jfindlay/pgjsonb

     * 454322c appease pylint's proscription on blank line excess

     * 57c6171 Get time with timezone correct also in job return.

     * e109d0f Get time with timezone correct.

     * 21e06b9 Fix SQL, remove unneeded imports.

     * 653f360 Stop making changes in 2 places.

     * d6daaa0 Typo.

     * 7d748bf SSL is handled differently by Pg, so don't set it here.

     * cc7c377 Fill alter_time field in salt_events with current time with
       timezone.

     * 43defe9 Port mysql module to Postgres using jsonb datatypes

   * PR    #23651:    (jayeshka)    adding   solr   unit   test   case   @
     2015-05-13T15:26:15Z

     * c1bdd4d Merge pull request #23651 from jayeshka/solr-unit-test

     * 6e05148 adding solr unit test case

   * PR  #23649:  (jayeshka)  adding  states/libvirt  unit  test  case   @
     2015-05-13T15:24:48Z

     * ee43411       Merge       pull       request       #23649      from
       jayeshka/libvirt_states-unit-test

     * 0fb923a adding states/libvirt unit test case

   * PR #23648:  (jayeshka)  adding  states/linux_acl  unit  test  case  @
     2015-05-13T15:24:11Z

     * c7fc466       Merge       pull       request       #23648      from
       jayeshka/linux_acl_states-unit-test

     * 3f0ab29 removed error.

     * 11081c1 adding states/linux_acl unit test case

   * PR  #23650:  (jayeshka)  adding  states/kmod   unit   test   case   @
     2015-05-13T15:09:18Z

     * 4cba7ba       Merge       pull       request       #23650      from
       jayeshka/kmod_states-unit-test

     * 1987015 adding states/kmod unit test case

   * PR #23633: (jayeshka) made changes to  test_interfaces  function.   @
     2015-05-13T06:51:07Z

     * bc8faf1       Merge       pull       request       #23633      from
       jayeshka/win_network-2015.5-unit-test

     * 0936e1d made changes to test_interfaces function.

   * PR #23619: (jfindlay) fix kmod.present processing of module loading @
     2015-05-13T01:16:56Z

     * 7df3579 Merge pull request #23619 from jfindlay/fix_kmod_state

     * 73facbf fix kmod.present processing of module loading

   * PR  #23598:  (rahulhan)  Adding states/win_dns_client.py unit tests @
     2015-05-12T21:47:36Z

     * d4f3095      Merge       pull       request       #23598       from
       rahulhan/states_win_dns_client_unit_test

     * d08d885 Adding states/win_dns_client.py unit tests

   * PR  #23597:  (rahulhan)  Adding  states/vbox_guest.py  unit  tests  @
     2015-05-12T21:46:30Z

     * 811c6a1      Merge       pull       request       #23597       from
       rahulhan/states_vbox_guest_unit_test

     * 6a2909e Removed errors

     * 4cde78a Adding states/vbox_guest.py unit tests

   * PR    #23615:    (rallytime)    Backport    #23577    to   2015.5   @
     2015-05-12T21:19:11Z

     * PR #23577:  (msciciel)  Fix  find  and  remove  functions  to  pass
       database param | refs: #23615

     * 029ff11 Merge pull request #23615 from rallytime/bp-23577

     * 6f74477 Fix find and remove functions to pass database param

   * PR   #23603:   (rahulhan)   Adding  states/winrepo.py  unit  tests  @
     2015-05-12T18:40:12Z

     * b858953      Merge       pull       request       #23603       from
       rahulhan/states_winrepo_unit_test

     * a66e7e7 Adding states/winrepo.py unit tests

   * PR   #23602:   (rahulhan)  Adding  states/win_path.py  unit  tests  @
     2015-05-12T18:39:37Z

     * 3cbbd6d      Merge       pull       request       #23602       from
       rahulhan/states_win_path_unit_test

     * 122c29f Adding states/win_path.py unit tests

   * PR  #23600:  (rahulhan)  Adding  states/win_network.py  unit  tests @
     2015-05-12T18:39:01Z

     * 3c904e8      Merge       pull       request       #23600       from
       rahulhan/states_win_network_unit_test

     * b418404 removed lint error

     * 1be8023 Adding states/win_network.py unit tests

   * PR   #23599:   (rahulhan)   Adding   win_firewall.py   unit  tests  @
     2015-05-12T18:37:49Z

     * 10243a7      Merge       pull       request       #23599       from
       rahulhan/states_win_firewall_unit_test

     * 6cda890 Adding win_firewall.py unit tests

   * PR  #23601:  (basepi)  Add  versionadded  for  jboss  module/state  @
     2015-05-12T17:22:59Z

     * e73071d Merge pull request #23601 from basepi/jboss.version.added

     * 0174c8f Add versionadded for jboss module/state

   * PR #23469: (s0undt3ch) Call the windows  specific  function  not  the
     general one @ 2015-05-12T16:47:22Z

     * 9beb7bc       Merge       pull       request       #23469      from
       s0undt3ch/hotfix/call-the-win-func

     * 83e88a3 Call the windows specific function not the general one

   * PR  #23583:  (jayeshka)  adding  states/ipset  unit   test   case   @
     2015-05-12T16:31:55Z

     * d2f0975       Merge       pull       request       #23583      from
       jayeshka/ipset_states-unit-test

     * 4330cf4 adding states/ipset unit test case

   * PR  #23582:  (jayeshka)  adding  states/keyboard  unit  test  case  @
     2015-05-12T16:31:17Z

     * 82a47e8       Merge       pull       request       #23582      from
       jayeshka/keyboard_states-unit-test

     * fa94d7a adding states/keyboard unit test case

   * PR  #23581:  (jayeshka)  adding  states/layman  unit  test   case   @
     2015-05-12T16:30:36Z

     * 77e5b28       Merge       pull       request       #23581      from
       jayeshka/layman_states-unit-test

     * 297b055 adding states/layman unit test case

   * PR   #23580:   (jayeshka)   adding   smf    unit    test    case    @
     2015-05-12T16:29:58Z

     * cbe3282 Merge pull request #23580 from jayeshka/smf-unit-test

     * 4f97191 adding smf unit test case

   * PR  #23572: (The-Loeki) Fix regression of #21355 introduced by #21603
     @ 2015-05-12T16:28:05Z

     * ISSUE #21603: (ipmb) ssh_auth.present fails on key without  comment
       | refs: #23572 #23572

     * PR #21355: (The-Loeki) Fix for comments containing whitespaces

     * 16a3338 Merge pull request #23572 from The-Loeki/ssh_auth_fix

     * d8248dd Fix regression of #21355 introduced by #21603

   * PR    #23565:    (garethgreenaway)    fix    to   aptpkg   module   @
     2015-05-12T16:25:46Z

     * ISSUE  #23490:  (lichtamberg)   salt.modules.aptpkg.upgrade  should
       have default "dist_upgrade=False" | refs: #23565

     * f843f89       Merge       pull       request       #23565      from
       garethgreenaway/2015_2_aptpkg_upgrade_default_to_upgrade

     * 97ae514  aptpkg.upgrade  should  default  to  upgrade  instead   of
       dist_upgrade.

   * PR  #23550: (jfindlay) additional mock for rh_ip_test test_build_bond
     @ 2015-05-12T15:17:16Z

     * ISSUE                    #23473:                     (terminalmage)
       unit.modules.rh_ip_test.RhipTestCase.test_build_bond     is     not
       properly mocked | refs: #23550

     * c1157cd Merge pull request #23550 from jfindlay/fix_rh_ip_test

     * e9b94d3 additional mock for rh_ip_test test_build_bond

   * PR #23552: (garethgreenaway) Fix for an issue caused  by  a  previous
     pull request @ 2015-05-11T21:54:59Z

     * b593328       Merge       pull       request       #23552      from
       garethgreenaway/2015_5_returner_fix_broken_previous_pr

     * 7d70e2b Passed argumentes in the call _fetch_profile_opts  to  were
       in the wrong order

   * PR  #23547:  (slinu3d)  Added  AWS  v4 signature support for 2015.5 @
     2015-05-11T21:52:24Z

     * d0f9682 Merge pull request #23547 from slinu3d/2015.5

     * f3bfdb5 Fixed urlparse and urlencode calls

     * 802dbdb Added AWS v4 signature support for 2015.5

   * PR #23544: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-11T18:02:06Z

     * ISSUE #23159: (aneeshusa) Unused validator

     * ISSUE  #20518: (ekle) module s3.get does not support eu-central-1 |
       refs: #23467

     * ISSUE #563: (chutz) pidfile support for minion and master daemons |
       refs: #23460 #23461

     * PR #23538: (cro) Update date in LICENSE file

     * PR  #23505:  (aneeshusa)  Remove unused ssh config validator. Fixes
       #23159.

     * PR #23467: (slinu3d) Added AWS v4 signature support

     * PR #23460: (s0undt3ch) [2014.7] Update to latest  stable  bootstrap
       script v2015.05.07

     * PR #23444: (techhat) Add create_attach_volume to nova driver

     * PR #23439: (techhat) Add wait_for_passwd_maxtries variable

     * 06c6a1f Merge pull request #23544 from basepi/merge-forward-2015.5

     * f8a36bc   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

       * b79fed3 Merge pull request #23538 from cro/licupdate

         * 345efe2 Update date in LICENSE file

       * a123a36      Merge      pull      request       #23505       from
         aneeshusa/remove-unused-ssh-config-validator

         * 90af167 Remove unused ssh config validator. Fixes #23159.

       * ca2c21a Merge pull request #23467 from slinu3d/2014.7

         * 0b4081d Fixed pylint error at line 363

         * 5be5eb5 Fixed pylink errors

         * e64f374 Fixed lint errors

         * b9d1ac4 Added AWS v4 signature support

       * e6f9eec Merge pull request #23444 from techhat/novacreateattach

         * ebdb7ea Add create_attach_volume to nova driver

       * e331463       Merge       pull      request      #23460      from
         s0undt3ch/hotfix/bootstrap-script-2014.7

         * edcd0c4 Update to latest stable bootstrap script v2015.05.07

       * 7a8ce1a Merge pull request #23439 from techhat/maxtries

         * 0ad3ff2 Add wait_for_passwd_maxtries variable

   * PR  #23470:  (twangboy)  Fixed  service.restart  for  salt-minion   @
     2015-05-11T17:54:47Z

     * ISSUE  #23426:  (twangboy)  Can't  restart  salt-minion  on  64 bit
       windows (2015.5.0) | refs: #23470

     * aa5b896 Merge pull request #23470 from twangboy/fix_svc_restart

     * b3f284c Fixed tests

     * ad44d79 Fixed service.restart for salt-minion

   * PR #23539: (rahulhan) Adding states/virtualenv_mod.py  unit  tests  @
     2015-05-11T17:02:31Z

     * 67988b2       Merge       pull       request       #23539      from
       rahulhan/states_virtualenv_mod_unit_test

     * 750bb07 Adding states/virtualenv_mod.py unit tests

   * 6f0cf2e Merge remote-tracking branch 'upstream/2015.2' into 2015.5

     * ISSUE #23244: (freimer) Caller not available in  reactors  |  refs:
       #23245

     * PR #23509: (keesbos) Catch the unset (empty/None) environment case

     * PR #23423: (cachedout) Remove jid_event from state.orch

     * PR #23245: (freimer) Add Caller functionality to reactors.

     * c966196       Merge       pull       request       #23423      from
       cachedout/remove_jid_event_from_orch

       * f81aab7 Remove jid_event from state.orch

     * 2bb09b7      Merge       pull       request       #23509       from
       keesbos/Catch_empty_environment

       * 6dedeac Catch the unset (empty/None) environment case

     * 6d42f30 Merge pull request #23245 from freimer/issue_23244

       * 24cf6eb Add Caller functionality to reactors.

   * PR #23513: (gladiatr72) short-circuit auto-failure of iptables.delete
     state @ 2015-05-11T15:18:33Z

     * c3f03d8      Merge       pull       request       #23513       from
       gladiatr72/RFC_stop_iptables.check_from_short-circuiting_position-only_delete_rule

     * c71714c short-circuit  auto-failure  of  iptables.delete  state  if
       position  argument  is  set  without  the  other accoutrements that
       check_rule requires.

   * PR #23534: (jayeshka)  adding  states/ini_manage  unit  test  case  @
     2015-05-11T14:32:06Z

     * 4e77f6f       Merge       pull       request       #23534      from
       jayeshka/ini_manage_states-unit-test

     * 831223c adding states/ini_manage unit test case

   * PR  #23533:  (jayeshka)  adding  states/hipchat  unit  test  case   @
     2015-05-11T14:30:22Z

     * 11ba9ed       Merge       pull       request       #23533      from
       jayeshka/hipchat-states-unit-test

     * 41d14b3 adding states/hipchat unit test case

   * PR  #23532:  (jayeshka)  adding  states/ipmi   unit   test   case   @
     2015-05-11T14:28:15Z

     * e542113       Merge       pull       request       #23532      from
       jayeshka/ipmi-states-unit-test

     * fc3e64a adding states/ipmi unit test case

   * PR   #23531:   (jayeshka)   adding   service   unit   test   case   @
     2015-05-11T14:27:12Z

     * 9ba85fd Merge pull request #23531 from jayeshka/service-unit-test

     * 3ad5314 adding service unit test case

   * PR #23517: (garethgreenaway) fix to returners @ 2015-05-11T14:20:51Z

     * ISSUE  #23512:  (Code-Vortex) hipchat_returner / slack_returner not
       work correctly | refs: #23517

     * 32838cd      Merge       pull       request       #23517       from
       garethgreenaway/23512_2015_5_returners_with_profiles

     * 81e31e2 fix for returners that utilize profile attributes.  code in
       the if else statement was backwards. #23512

   * PR #23502: (rahulhan) Adding states/win_servermanager.py unit tests @
     2015-05-08T19:47:18Z

     * 6be7d8d       Merge       pull       request       #23502      from
       rahulhan/states_win_servermanager_unit_test

     * 2490074 Adding states/win_servermanager.py unit tests

   * PR   #23495:   (jayeshka)   adding   seed   unit    test    case    @
     2015-05-08T17:30:38Z

     * 6048578 Merge pull request #23495 from jayeshka/seed-unit-test

     * 3f134bc adding seed unit test case

   * PR   #23494:   (jayeshka)   adding   sensors   unit   test   case   @
     2015-05-08T17:30:18Z

     * 70bc3c1 Merge pull request #23494 from jayeshka/sensors-unit-test

     * 1fb48a3 adding sensors unit test case

   * PR  #23493:  (jayeshka)  adding  states/incron  unit  test   case   @
     2015-05-08T17:29:59Z

     * b981b20       Merge       pull       request       #23493      from
       jayeshka/incron-states-unit-test

     * cc7bc17 adding states/incron unit test case

   * PR #23492: (jayeshka) adding states/influxdb_database unit test  case
     @ 2015-05-08T17:29:51Z

     * 4019c49       Merge       pull       request       #23492      from
       jayeshka/influxdb_database-states-unit-test

     * e1fcac8 adding states/influxdb_database unit test case

   * PR #23491: (jayeshka) adding states/influxdb_user unit  test  case  @
     2015-05-08T16:24:07Z

     * d317a77       Merge       pull       request       #23491      from
       jayeshka/influxdb_user-states-unit-test

     * 9d4043f adding states/influxdb_user unit test case

   * PR  #23477:  (galet)  LDAP  auth:  Escape  filter  value  for   group
     membership search @ 2015-05-07T22:04:48Z

     * e0b2a73 Merge pull request #23477 from galet/ldap-filter-escaping

     * 33038b9 LDAP auth: Escape filter value for group membership search

   * PR #23476: (cachedout) Lint becaon @ 2015-05-07T19:55:36Z

     * PR #23431: (UtahDave) Beacon fixes | refs: #23476

     * e1719fe Merge pull request #23476 from cachedout/lint_23431

     * 8d1ff20 Lint becaon

   * PR    #23431:    (UtahDave)   Beacon   fixes   |   refs:   #23476   @
     2015-05-07T19:53:47Z

     * 1e299ed Merge pull request #23431 from UtahDave/beacon_fixes

     * 152f223 remove unused import

     * 81198f9 fix interval logic and example

     * 5504778 update to proper examples

     * 6890439 fix list for mask

     * ee7b579 remove custom interval code.

   * PR  #23468:  (rahulhan)  Adding  states/win_system.py  unit  tests  @
     2015-05-07T19:20:50Z

     * ea55c44       Merge       pull       request       #23468      from
       rahulhan/states_win_system_unit_test

     * 33f8c12 Adding states/win_system.py unit tests

   * PR #23466: (UtahDave) minor spelling fix @ 2015-05-07T19:19:06Z

     * e6e1114 Merge pull request #23466 from UtahDave/2015.5local

     * b2c399a minor spelling fix

   * PR #23461: (s0undt3ch) [2015.5] Update  to  latest  stable  bootstrap
     script v2015.05.07 @ 2015-05-07T19:16:18Z

     * ISSUE #563: (chutz) pidfile support for minion and master daemons |
       refs: #23460 #23461

     * 4eeb1e6      Merge       pull       request       #23461       from
       s0undt3ch/hotfix/bootstrap-script

     * 638c63d Update to latest stable bootstrap script v2015.05.07

   * PR    #23450:    (jayeshka)    adding   scsi   unit   test   case   @
     2015-05-07T19:00:28Z

     * 8651278 Merge pull request #23450 from jayeshka/scsi-unit-test

     * e7269ff adding scsi unit test case

   * PR #23449: (jayeshka) adding s3 unit test case @ 2015-05-07T18:59:45Z

     * 8b374ae Merge pull request #23449 from jayeshka/s3-unit-test

     * 85786bf adding s3 unit test case

   * PR  #23448:  (jayeshka)  adding  states/keystone  unit  test  case  @
     2015-05-07T18:58:59Z

     * 49b431c       Merge       pull       request       #23448      from
       jayeshka/keystone-states-unit-test

     * a3050eb adding states/keystone unit test case

   * PR  #23447:  (jayeshka)  adding  states/grafana  unit  test  case   @
     2015-05-07T18:58:20Z

     * 23d7e7e       Merge       pull       request       #23447      from
       jayeshka/grafana-states-unit-test

     * 7e90a4a adding states/grafana unit test case

   * PR #23438: (techhat) Gate requests import @ 2015-05-07T07:22:58Z

     * 1fd0bc2 Merge pull request #23438 from techhat/gaterequests

     * d5b15fc Gate requests import

   * PR #23429: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-05-07T05:35:13Z

     * ISSUE  #17245: (tomashavlas) localemod does not generate locale for
       Arch | refs: #23307 #23397

     * PR #23425: (basepi) [2014.7] Fix typo in FunctionWrapper

     * PR #23422: (cro) $HOME should not be used, some  shells  don't  set
       it.

     * PR #23414: (jfindlay) 2015.2 -> 2015.5

     * PR  #23409:  (terminalmage)  Update  Lithium  docstrings  in 2014.7
       branch | refs: #23410

     * PR #23404: (hvnsweeting) saltapi cherrypy: initialize var when POST
       body is empty

     * PR  #23397:  (jfindlay)  add more flexible whitespace to locale_gen
       search

     * PR #23385: (rallytime) Backport #23346 to 2014.7

     * PR #23346:  (ericfode)  Allow  file_map  in  salt-cloud  to  handle
       folders.  | refs: #23385

     * 3c4f734 Merge pull request #23429 from basepi/merge-forward-2015.5

     * 7729834   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

     * 644eb75 Merge pull request #23422 from cro/gce_sh_home

       * 4ef9e6b Don't use $HOME to find  user's  directory,  some  shells
         don't set it

     * ef17ab4 Merge pull request #23425 from basepi/functionwrapper_typo

       * c390737 Fix typo in FunctionWrapper

     * 1b13ec0 Merge pull request #23385 from rallytime/bp-23346

       * 9efc13c more linting fixes

       * cf131c9 cleaned up some pylint errors

       * f981699  added  logic  to  sftp_file and file_map to allow folder
         uploads using file_map

     * f8c7a62 Merge pull request #23414 from jfindlay/update_branch

       * 8074d16 2015.2 -> 2015.5

     * 54b3bd4      Merge       pull       request       #23404       from
       hvnsweeting/cherrypy-post-emptybody-fix

       * f85f8f9 initialize var when POST body is empty

     * 160f703       Merge       pull       request       #23409      from
       terminalmage/update-lithium-docstrings-2014.7

       * bc97d01 Fix sphinx typo

       * 20006b0 Update Lithium docstrings in 2014.7 branch

     * aa5fb0a Merge pull request #23397 from jfindlay/fix_locale_gen

       * 0941fef add more flexible whitespace to locale_gen search

   * PR #23396: (basepi) [2015.2] Merge forward from 2014.7  to  2015.2  @
     2015-05-06T21:42:35Z

     * ISSUE  #23294: (variia) file.replace fails to append if repl string
       partially available | refs: #23350

     * ISSUE #23026: (adelcast) Incorrect salt-syndic logfile and  pidfile
       locations | refs: #23341

     * ISSUE #22742: (hvnsweeting) salt-master says: "This master address:
       'salt' was previously resolvable but  now  fails  to  resolve!"   |
       refs: #23344

     * ISSUE  #19114:  (pykler)  salt-ssh  and gpg pillar renderer | refs:
       #23272 #23347 #23188

     * ISSUE #17245: (tomashavlas) localemod does not generate locale  for
       Arch | refs: #23307 #23397

     * ISSUE  #580:  (thatch45)  recursive  watch not being caught | refs:
       #23324

     * ISSUE #552: (jhutchins) Support require and watch  under  the  same
       state dec | refs: #23324

     * PR #23368: (kaithar) Backport #23367 to 2014.7

     * PR  #23367:  (kaithar)  Put the sed insert statement back in to the
       output.  | refs: #23368

     * PR #23350: (lorengordon) Append/prepend: search for full line

     * PR     #23347:     (basepi)     [2014.7]     Salt-SSH      Backport
       FunctionWrapper.__contains__

     * PR #23344: (cachedout) Explicitly set file_client on master

     * PR #23341: (cachedout) Fix syndic pid and logfile path

     * PR #23324: (s0undt3ch) [2014.7] Update to the latest stable release
       of the bootstrap script v2015.05.04

     * PR  #23318:  (cellscape)  Honor  seed  argument  in  LXC  container
       initializaton

     * PR  #23311:  (cellscape)  Fix  new  container initialization in LXC
       runner | refs: #23318

     * PR #23307: (jfindlay) check for /etc/locale.gen

     * PR #23272: (basepi) [2014.7] Allow salt-ssh minion config overrides
       via master config and roster | refs: #23347

     * PR  #23188:  (basepi)  [2014.7]  Work  around  bug  in  salt-ssh in
       config.get for gpg renderer | refs: #23272

     * PR #18368: (basepi) Merge forward from 2014.7 to  develop  |  refs:
       #23367 #23368

     * PR  #589:  (epoelke) add --quiet and --outfile options to saltkey |
       refs: #23324

     * PR #567: (bastichelaar) Added upstart module | refs: #23324

     * PR  #560:  (UtahDave)  The  runas  feature  that   was   added   in
       93423aa2e5e4b7de6452090b0039560d2b13...  | refs: #23324

     * PR #504: (SEJeff) File state goodies | refs: #23324

     * 1fb8445 Merge pull request #23396 from basepi/merge-forward-2015.2

     * 2766c8c Fix typo in FunctionWrapper

     * fd09cda   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.2

       * 0c76dd4 Merge pull request #23368 from kaithar/bp-23367

         * 577f419 Pylint fix

         * 8d9acd1 Put the sed insert statement back in to the output.

       * 3493cc1      Merge      pull      request       #23350       from
         lorengordon/file.replace_assume_line

         * b60e224 Append/prepend: search for full line

       * 7be5c48 Merge pull request #23341 from cachedout/issue_23026

         * e98e65e Fix tests

         * 6011b43 Fix syndic pid and logfile path

       * ea61abf       Merge       pull      request      #23272      from
         basepi/salt-ssh.minion.config.19114

         * c223309 Add versionadded

         * be7407f Lint

         * c2c3375 Missing comma

         * 8e3e8e0 Pass the minion_opts through the FunctionWrapper

         * cb69cd0 Match the master config template in the  master  config
           reference

         * 87fc316 Add Salt-SSH section to master config template

         * 91dd9dc Add ssh_minion_opts to master config ref

         * c273ea1 Add minion config to salt-ssh doc

         * a0b6b76 Add minion_opts to roster docs

         * 5212c35 Accept minion_opts from the target information

         * e2099b6 Process ssh_minion_opts from master config

         * 3b64214  Revert  "Work around bug in salt-ssh in config.get for
           gpg renderer"

         * 494953a Remove the strip (embracing multi-line YAML dump)

         * fe87f0f Dump multi-line yaml into the SHIM

         * b751a72 Inject local minion config into shim if available

       * 4f760dd      Merge      pull      request       #23347       from
         basepi/salt-ssh.functionwrapper.contains.19114

         * 30595e3 Backport FunctionWrapper.__contains__

       * 02658b1 Merge pull request #23344 from cachedout/issue_22742

         * 5adc96c Explicitly set file_client on master

       * ba7605d       Merge       pull      request      #23318      from
         cellscape/honor-seed-argument

         * 228b1be Honor seed argument in LXC container initializaton

       * 4ac4509 Merge pull request #23307 from jfindlay/fix_locale_gen

         * 101199a check for /etc/locale.gen

       * f790f42      Merge      pull      request       #23324       from
         s0undt3ch/hotfix/bootstrap-script-2014.7

       * 6643e47  Update  to  the  latest  stable release of the bootstrap
         script v2015.05.04

   * 23d4feb Merge remote-tracking branch 'upstream/2015.2' into 2015.5

   * PR  #23412:  (rahulhan)  Adding  states/win_update.py  unit  tests  @
     2015-05-06T18:31:09Z

     * b3c1672       Merge       pull       request       #23412      from
       rahulhan/states_win_update_unit_test

     * 9bc1519 Removed unwanted imports

     * f12bfcf Adding states/win_update.py unit tests

   * PR #23413: (terminalmage) Update manpages  for  2015.2  ->  2015.5  @
     2015-05-06T17:12:57Z

     * f2d7646 Merge pull request #23413 from terminalmage/update-manpages

     * 23fa440 Update manpages to reflect 2015.2 rename to 2015.5

     * 0fdaa73 Fix missed docstring updates from 2015.2 -> 2015.5

     * 4fea5ba Add missing RST file

   * PR  #23410: (terminalmage) Update Lithium docstrings in 2015.2 branch
     @ 2015-05-06T15:53:52Z

     * PR #23409:  (terminalmage)  Update  Lithium  docstrings  in  2014.7
       branch | refs: #23410

     * bafbea7       Merge       pull       request       #23410      from
       terminalmage/update-lithium-docstrings-2015.2

     * d395565 Update Lithium docstrings in 2015.2 branch

   * PR   #23407:   (jayeshka)   adding   rsync   unit   test    case    @
     2015-05-06T15:52:23Z

     * 02ef41a Merge pull request #23407 from jayeshka/rsync-unit-test

     * a4dd836 adding rsync unit test case

   * PR   #23406:   (jayeshka)   adding   states/lxc   unit  test  case  @
     2015-05-06T15:51:50Z

     * 58ec2a2      Merge       pull       request       #23406       from
       jayeshka/lxc-states-unit-test

     * 32a0d03 adding states/lxc unit test case

   * PR #23395: (basepi) [2015.2] Add note to 2015.2.0 release notes about
     master opts in pillar @ 2015-05-05T22:15:20Z

     * 8837d00 Merge pull request #23395 from basepi/2015.2.0masteropts

     * b261c95 Add note to 2015.2.0 release notes  about  master  opts  in
       pillar

   * PR  #23393:  (basepi) [2015.2] Add warning about python_shell changes
     to 2015.2.0 release notes @ 2015-05-05T22:12:46Z

     * f79aed5 Merge pull request #23393 from basepi/2015.2.0python_shell

     * b2f033f Add CLI note

     * 48e7b3e Add warning about python_shell changes to 2015.2.0  release
       notes

   * PR  #23380:  (gladiatr72)  Fix  for  double  output with static  salt
     cli/v2015.2 @ 2015-05-05T21:44:28Z

     * a977776      Merge       pull       request       #23380       from
       gladiatr72/fix_for_double_output_with_static__salt_CLI/v2015.2

     * c47fdd7  Actually removed the static bits from below the else: fold
       this time.

     * 4ee3679 Fix for incorrect output with salt CLI --static option

   * PR   #23379:   (rahulhan)   Adding    states/rabbitmq_cluster.py    @
     2015-05-05T21:44:06Z

     * 5c9543c       Merge       pull       request       #23379      from
       rahulhan/states_rabbitmq_cluster_test

     * 04c22d1 Adding states/rabbitmq_cluster.py

   * PR  #23377:   (rahulhan)   Adding   states/xmpp.py   unit   tests   @
     2015-05-05T21:43:35Z

     * 430f080 Merge pull request #23377 from rahulhan/states_xmpp_test

     * 32923b5 Adding states/xmpp.py unit tests

   * PR  #23335:  (steverweber)  2015.2:  include doc in master config for
     module_dirs @ 2015-05-05T21:28:58Z

     * 8c057e6 Merge pull request #23335 from steverweber/2015.2

     * 5e3bae9 help installing python pysphere lib

     * 97513b0 include module_dirs

     * 36b1c87 include module_dirs

   * PR #23362: (jayeshka) adding states/zk_concurrency unit test  case  @
     2015-05-05T15:50:06Z

     * 1648253       Merge       pull       request       #23362      from
       jayeshka/zk_concurrency-states-unit-test

     * f60dda4 adding states/zk_concurrency unit test case

   * PR   #23363:   (jayeshka)   adding   riak   unit    test    case    @
     2015-05-05T14:23:05Z

     * 1cdaeed Merge pull request #23363 from jayeshka/riak-unit-test

     * f9da6db adding riak unit test case

   Salt 2015.5.10 Release Notes
   Security Fix
   CVE-2016-3176:  Insecure  configuration  of PAM external authentication
   service

   This issue affects all Salt versions prior to  2015.8.8/2015.5.10  when
   PAM  external authentication is enabled. This issue involves passing an
   alternative PAM authentication service with a command that is  sent  to
   LocalClient,   enabling   the   attacker   to   bypass  the  configured
   authentication service. Thank you to  Dylan  Frese  <[email protected]>
   for bringing this issue to our attention.

   This  update  defines  the  PAM  eAuth  service that users authenticate
   against in the Salt Master configuration.

   (No additional fixes are contained in this release).

   Read Before Upgrading Debian 8 (Jessie) from  Salt  Versions  Earlier  than
   2015.5.9
   Salt systemd service files are missing the following statement in these
   versions:

      [Service]
      KillMode=process

   This statement must be added to successfully upgrade on  these  earlier
   versions of Salt.

   Salt 2015.5.11 Release Notes
   Version 2015.5.11 is a bugfix release for 2015.5.0.

   Changes for v2015.5.10..v2015.5.11
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-05-20T21:02:38Z

   Total Merges: 101

   Changes:

   * dc8ce2d Fix traceback in logging for config  validation  (#33386)  (
     #33405)

   * PR #33383: (thatch45) maintain the fallabck because I am totally sick
     of this crap

   * 755acfb Improve doc  clarity  for  disable_modules  documentation  (
     #33379)

   * 2b5ad12 Better YAML syntax error handling (#33375)

   * PR  #33372:  (jacobhammons)  revved  2015.8  branch  to .9 in version
     selector

   * 55be0ab Expanded documentation for boto_elb state and module (#33341)

   * 9b42a05 Added some more docs for master and minion config settings (
     #33292)

   * 8acee5e Fix iptables --match-set (
     `#23643`_
     ) (#33301)

   * 757ef20 fix "loose" typo (#33290)

   * b7d98da Add auth_tries config option to minion.rst docs (#33287)

   * 061851b Document minion_id_caching config value (#33282)

   * 8fa72f6  Clarify  file.replace  MULTILINE flag interaction with regex
     anchors (#33137)

   * 4b1f460 update 2015.5.11 release notes (#33236)

   * PR #33211: (cachedout) Don't try to kill a parent proc if we can't

   * f868329 Resolve issue with pkg module on Mint Linux (#33205)

   * a09e1b6 Add pip installed and removed test (#33178)

   * 96e3586 update 2015.5.11 release notes (#33197)

   * 09b072a Fix file.managed for Windows (#33181)

   * 30868ab [2015.5] Update to latest  bootstrap  script  v2016.05.11  (
     #33185)

   * 264ad34 Pip fix (#33180)

   * 43288b2 add 2015.5.11 release notes (#33160)

   * e0da8fd  [2015.5]  Update  to  latest bootstrap script v2016.05.10 (
     #33155)

   * PR #33141: (jtand) Skipping salt-call --local test

   * 878d34a Doc mock decorators (#33132)

   * 30edead Lower display of msgpack failure msg to debug (#33078)

   * d4928c5 Use saltstack repo in buildpackage.py on CentOS 5 (#33080)

   * 61d126c add test for installing package while using salt-call --local
     (#33025)

   * 6d3e4e8 File and User test fixes for 2015.5 on Fedora23 (#33055)

   * d48b2b8 test pillar.items output (#33060)

   * 398793b Fix minor document error of test.assertion (#33067)

   * f875763 Saltfile with pillar tests (#33045)

   * 1d78924 Backport #33021 manually to 2015.5 (#33044)

   * f00b5f9 Add run_on_start docs to schedule.rst (#32958)

   * edce22a backport PR #32732 to 2015.5 fixes
     `#23714`_
      (#32848)

   * 9b5c14c    salt-cloud    -u    downloads    stable    version    from
     bootstrap.saltstack.com by default (#32837)

   * 9725804 update bootstrap to 2016.04.18 release (#32667)

   * PR #32776: (rallytime) [2015.5] Merge forward from 2014.7 to 2015.5

   * 67d0c81 Support remote sources in a source list (#32691)

   * PR #32686: (cachedout) Fix stacktrace in batch with dup minion ids

   * 3ec9502 Update "Low Hanging Fruit" to "Help Wanted" (#32675)

   * 77bea56  Additional  documentation  on  calling  exec  modules   from
     templates (#32657)

   * c910b8d Fixing critical bug to remove only the specified Host instead
     of the entire Host cluster (#32639)

   * 4568565 Add _syspaths.py to .gitignore (#32638)

   * PR #32561: (gtmanfred) redact passwords and hashes from  user.present
     updates

   * PR #32538: (rallytime) Back-port #32528 to 2015.5

   * 29333e5 Add documentation for some master/minion configs (#32454)

   * PR  #32458:  (terminalmage)  Improve  and  clarify  docs  on provider
     overrides.

   * 0809126 Merge #32293 with test fixes (#32418)

   * bbd8260 Ignore Raspbian in service.py __virtual__ (#32421)

   * 690addf FreeBSD supports packages  in  format  java/openjdk7  so  the
     prior  commit broke that functionality. Check freebsd/pkg`#1409`_ for
     more info.

   * PR #32399: (amontalban) Backport to fix
     `#28262`_
      for 2015.5 as requested in PR #32376

   * PR #32374: (cachedout) Update proxmox documentation

   * PR #32339: (Ch3LL) remove reference to master_alive_check in 2015.5

   * PR #32284: (rallytime) Audit config.py default types and values

   * PR  #32302:  (terminalmage)  Properly  support  packages  with  blank
     "Release" param in pkg.latest_version

   * PR  #32162: (terminalmage) Properly handle yum/zypper repositories in
     pkgrepo.managed

   * PR #32223:  (twangboy)  Create  minion.d  directory  on  install  for
     Windows

   * PR  #32218:  (cachedout)  Only  display  error  when  tty  is True in
     salt-ssh

   * PR #32196: (jtand) Fixed pylint error in app_pam_test.py

   * PR #32154: (Ch3LL) Add integration tests for salt-api using pam eauth

   * PR #32170: (gtmanfred) add name for lxc for use with cloud cache

   * PR #32164: (terminalmage)  Make  __virtual__  for  rhservice.py  more
     robust (2015.5 branch)

   * PR #32141: (paclat) fixes 32108

   * PR  #32129:  (terminalmage)  Support multiple valid option types when
     performing type checks

   * PR #32056: (bstevenson) Fix list absent

   * PR #32096: (rallytime) Back-port #32065 to 2015.5

   * PR #32104: (jacobhammons) One additional known  issue  for  2015.5.10
     release notes

   * PR #32100: (jacobhammons) 2015.5.10 release docs

   * PR   #32038:   (terminalmage)  Improve  state  module  docs,  replace
     references to state.highstate/state.sls with state.apply

   * PR #32051: (terminalmage) Fix outputter for state.apply

   * PR #32002: (abednarik) Added Manajro Linux to virtual.

   * PR #31957: (rallytime) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #31972:  (terminalmage)  Make  lack  of  python-ldap  module  more
     explicit when LDAP eauth is enabled

   * PR #31935: (twangboy) Back port nullsoft build script from 2015.8

   * PR #31912: (jfindlay) log.mixins: remove extermporaneous .record

   * PR  #31825: (jtand) Updated .testing.pylintrc to match newer versions
     of pylint

   * PR #31900:  (rallytime)  Add  "python  module"  clarification  to  ps
     __virtual__ warning.

   * PR #31878: (rallytime) Make sure __virtual__ error message is helpful
     when psutil is missing

   * PR #31852: (rallytime) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #31827: (gtmanfred)  Remove  ability  of  authenticating  user  to
     specify pam service

   * PR #31810: (whiteinge) Fix outdated Jinja 'env' variable reference

   * PR #31744: (brejoc) Fix for AttributeError with libcloud <0.15

   * PR  #31740:  (terminalmage)  Assume  pillar_opts  is  False  when not
     specified in masterless mode

   * PR #31750: (rallytime) Back-port #26170 to 2015.5

   * PR #31689: (rallytime) Back-port #29467 to 2015.5

   * PR #31687: (cachedout) Removed useless GPG tests

   * PR #31660: (terminalmage) Remove epoch from version string if present
     when installing with yum

   * PR #31683: (rallytime) Back-port #31578 to 2015.5

   * PR #31682: (cachedout) Add definition of job cache to glossary

   * PR  #31658:  (rallytime) Add mentioned of Salt's Coding Style docs to
     the Contributing docs

   * PR #31655: (rallytime) Make note of pylint dependencies in docs

   * PR #31440: (cachedout) Set correct type for master_tops config value

   * PR  #31622:  (jfindlay)   doc/topics/tutorials/http:   update   query
     decoding docs

   * PR  #31558:  (cachedout)  Don't  stacktrace  if  ssh  binary  is  not
     installed with salt-ssh

   * PR #31521: (terminalmage) salt-ssh: Fix race condition  when  caching
     files to build the thin tarball

   * PR  #31497:  (rallytime)  Remove  duplicate  "timeout"  definition in
     Roster docs

   * PR #31472: (rallytime) Update contributing docs

   * PR #31461: (DmitryKuzmenko) Set auth retry count to 0 if  multimaster
     mode is failover.

   * PR #31442: (sastorsl) Add os.path.exists(src) to file.py, def copy

   * PR   #31441:   (cachedout)  Include  localhost  minions  in  presence
     detection for runner

   * PR #31416: (carlwgeorge) selinux module documentation fix

   * PR #31336: (terminalmage) Improve config validation logging

   * PR #31374: (sjorge) fix for
     `#31369`_

   * PR #31339: (jacobhammons) changed latest release to 2015.8.7

   * PR    #31288:    (notpeter)    Improve    salt.states.ssh_known_hosts
     documentation.

   * PR  #31183: (heyfife) Fixed named external_ip reservation/re-use code
     in gce driver.

   * PR  #31032:  (terminalmage)  (2015.5  branch)  yumpkg:  ensure   that
     dnf-plugins-core >= 0.1.15 is installed

   * PR  #31264:  (sjorge) fix if_missing gets appended to dirs list, take
     III

   * PR #31110: (cachedout) Fixup 30730

   * PR #30974: (rallytime) Back-port #30949 to 2015.5

   * PR #30942: (rallytime) Back-port #30897 to 2015.5

   * PR #30922: (jacobhammons) Rev latest version to 2015.8.5

   * PR #30865: (abednarik) Better boto elb error message.

   * PR #30831: (jacobhammons) Updated readme

   * PR #30829: (jacobhammons) Updated latest version to 2015.8.4

   * PR #30784: (rallytime) Back-port #24952 to 2015.5

   * PR #30764: (terminalmage) Work around yum versionlock's inability  to
     remove holds by package name alone

   * PR  #30760: (toanju) Changed output format of arp_ip_target from list
     to comma delimited...

   * PR #30757: (yannis666) Fix to mine update to merge configuration

   * PR #30749: (abednarik) Fix Netwotk hostname Module in Debian systems.

   * PR #30699: (abednarik) Add Retry to save_load.

   * PR #30659: (sjmh) Fix lsscsi issues for certain platforms

   * PR #30671: (techhat) Add file locking to cloud index

   * PR #30586: (abednarik) Fix comment_line permissions.

   * PR #30582: (terminalmage)  yumpkg.check_db:  run  separate  repoquery
     commands when multiple names passed

   * PR   #30548:  (jacobhammons)  Added  placeholder  release  notes  for
     2015.5.10

   * PR #30530: (terminalmage) 2015.5 tweaks from #30529

   * PR #30484: (terminalmage) Backport DNF support to 2015.5 branch

   * PR #30512: (jfindlay) disable pkgrepo test for ubuntu 15.10+

   * PR #30478: (jtand) Updated pip_state to work with pip 8.0

   * PR  #30482:  (borgstrom)  Pyobjects  recursive  import  support  (for
     2015.5)

   * PR  #30459:  (jfindlay) modules.pkg: disable repo int test for ubuntu
     15.10

   * PR #30443: (jtand) Boto uses False for is_default instead of None

   * PR #30420: (attiasr) Backport #26853

   * PR #30364: (rallytime) Add TLS version imports and add linode  driver
     documentation notices

   * PR #30184: (rallytime) Back-port #30166 to 2015.5

   * PR #30291: (thegoodduke) ipset: fix test=true & add comment for every
     entry

   Salt 2015.5.2 Release Notes
   release
          2015-06-10

   Version 2015.5.2 is a bugfix release for 2015.5.0.

   Extended     Changelog     Courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   PR #24346: (rallytime) Backport #24271 to 2015.5
          @ 2015-06-03T18:44:31Z

          PR #24271: (randybias) Fixed the setup instructions
                 refs: #24346

          * 76927c9 Merge pull request #24346 from rallytime/bp-24271

          * 04067b6 Fixed the setup instructions

   PR #24345: (rallytime) Backport #24013 to 2015.5
          @ 2015-06-03T18:39:41Z

          ISSUE  #24012:  (jbq)  Enabling  a  service  does not create the
          appropriate rc.d symlinks on Ubuntu
                 refs: #24013

          PR #24013: (jbq) Fix enabling a service on Ubuntu #24012
                 refs: #24345

          * 4afa03d Merge pull request #24345 from rallytime/bp-24013

          * 16e0732 Fix enabling a service on Ubuntu #24012

   PR #24365: (jacobhammons) Fixes for PDF build errors
          @ 2015-06-03T17:50:02Z

          * c3392c2 Merge pull request #24365 from jacobhammons/DocFixes

          * 0fc1902 Fixes for PDF build errors

   PR  #24313:  (nicholascapo)  Fix  #22991  Correctly  set  result   when
   test=True
          @ 2015-06-03T14:49:18Z

          ISSUE  #22991:  (nicholascapo) npm.installed ignores test=True *
          ae681a4  Merge   pull   request   #24313   from   nicholascapo/
          fix-22991-npm.installed-test-true    *    ac9644c   Fix   #22991
          npm.installed correctly set result on test=True

   PR #24312: (nicholascapo) Fix #18966: file.serialize supports test=True
          @ 2015-06-03T14:49:06Z

          ISSUE #18966: (bechtoldt)  file.serialize  ignores  test=True  *
          d57a9a2   Merge   pull   request   #24312   from  nicholascapo/
          fix-18966-file.serialize-test-true   *   e7328e7   Fix    #18966
          file.serialize correctly set result on test=True

   PR #24302: (jfindlay) fix pkg hold/unhold integration test
          @ 2015-06-03T03:27:43Z

          * 6b694e3 Merge pull request #24302 from jfindlay/pkg_tests

          * c2db0b1 fix pkg hold/unhold integration test

   PR #24349: (rallytime) Remove references to mount_points in ec2 docs
          @ 2015-06-03T01:54:09Z

          ISSUE  #14021:  (mathrawka)  EC2  doc  mentions mount_point, but
          unable to use properly
                 refs: #24349

          * aca8447 Merge pull request #24349 from rallytime/fix-14021

          * a235b11 Remove references to mount_points in ec2 docs

   PR #24328: (dr4Ke) Fix state grains silently fails 2015.5
          @ 2015-06-02T15:18:46Z

          ISSUE #24319: (dr4Ke) grains state  shouldn't  fail  silently  *
          88a997e       Merge      pull      request      #24328      from
          dr4Ke/fix_state_grains_silently_fails_2015.5 * 8a63d1e fix state
          grains silently fails #24319

          * ca1af20 grains state: add some tests

   PR #24310: (techhat) Add warning about destroying maps
          @ 2015-06-02T03:01:28Z

          ISSUE   #24036:  (arthurlogilab)  [salt-cloud]  Protect  against
          passing command  line  arguments  as  names  for  the  --destroy
          command in map files
                 refs: #24310

          ISSUE  #9772:  (s0undt3ch)  Delete VM's in a map does not delete
          them all
                 refs: #24310

          * 7dcd9bb Merge pull request #24310 from techhat/mapwarning

          * ca535a6 Add warning about destroying maps

   PR #24281: (steverweber) Ipmi docfix
          @ 2015-06-01T17:45:36Z

          * 02bfb25 Merge pull request #24281 from steverweber/ipmi_docfix

          * dd36f2c yaml formatting

          * f6deef3 include api_kg kwarg in ipmi state

          * a7d4e97 doc cleanup

          * 0ded2fd save more cleanup to doc

          * 08872f2 fix name api_key to api_kg

          * 165a387 doc fix add api_kg kwargs

          * 1ec7888 cleanup docs

   PR #24287: (jfindlay) fix pkg test on ubuntu 12.04 for realz
          @ 2015-06-01T14:16:37Z

          * 73cd2cb Merge pull request #24287 from jfindlay/pkg_test

          * 98944d8 fix pkg test on ubuntu 12.04 for realz

   PR #24279: (rallytime) Backport #24263 to 2015.5
          @ 2015-06-01T04:29:34Z

          PR #24263: (cdarwin) Correct usage  of  import_yaml  in  formula
          documentation
                 refs: #24279

          * 02017a0 Merge pull request #24279 from rallytime/bp-24263

          * beff7c7 Correct usage of import_yaml in formula documentation

   PR #24277: (rallytime) Put a space between after_jump commands
          @ 2015-06-01T04:28:26Z

          ISSUE  #24226:  (c4urself) iptables state needs to keep ordering
          of flags
                 refs: #24277

          * 2ba696d     Merge      pull      request      #24277      from
            rallytime/fix_iptables_jump

          * e2d1606 Move after_jump split out of loop

          * d14f130 Remove extra loop

          * 42ed532 Put a space between after_jump commands

   PR #24262: (basepi) More dictupdate after #24142
          @ 2015-05-31T04:09:37Z

          PR  #24142:  (basepi)  Optimize dictupdate.update and add #24097
          functionality
                 refs: #24262

          PR #24097: (kiorky) Optimize dictupdate
                 refs: #24142 #24142

          * 113eba3 Merge pull request #24262 from basepi/dictupdatefix

          * 0c4832c Raise a typeerror if non-dict types

          * be21aaa Pylint

          * bb8a6c6 More optimization

          * c933249 py3 compat

          * ff6b2a7 Further optimize dictupdate.update()

          * c73f5ba Remove unused valtype

   PR #24269: (kiorky) zfs: Fix spurious retcode hijacking in virtual
          @ 2015-05-30T17:47:49Z

          * 785d5a1 Merge pull request #24269 from makinacorpus/zfs

          * 0bf23ce zfs: Fix spurious retcode hijacking in virtual

   PR #24257: (jfindlay) fix pkg mod integration test on ubuntu 12.04
          @ 2015-05-29T23:09:00Z

          * 3d885c0 Merge pull request #24257 from jfindlay/pkg_tests

          * 9508924 fix pkg mod integration test on ubuntu 12.04

   PR #24260: (basepi) Fix some typos from #24080
          @ 2015-05-29T22:54:58Z

          ISSUE #23657: (arthurlogilab) [salt-cloud lxc] NameError: global
          name '__salt__' is not defined
                 refs: #24080 #23982

          PR #24080: (kiorky) Lxc consistency2
                 refs: #24260 #23982 #24066

          PR #24066: (kiorky) Merge forward 2015.5 -> develop
                 refs: #23982

          PR #24065: (kiorky) continue to fix #23883
                 refs: #24080 #24066

          PR #23982: (kiorky) lxc: path support
                 refs: #24080

          * 08a1075 Merge pull request #24260 from basepi/lxctypos24080

          * 0fa1ad3 Fix another lxc typo

          * 669938f s/you ll/you'll/

   PR #24080: (kiorky) Lxc consistency2
          refs: #24260 #23982 #24066

          @ 2015-05-29T22:51:54Z

          ISSUE #23657: (arthurlogilab) [salt-cloud lxc] NameError: global
          name '__salt__' is not defined
                 refs: #24080 #23982

          PR #24066: (kiorky) Merge forward 2015.5 -> develop
                 refs: #23982

          PR #24065: (kiorky) continue to fix #23883
                 refs: #24080 #24066

          PR #23982: (kiorky) lxc: path support
                 refs: #24080

          * 75590cf     Merge      pull      request      #24080      from
            makinacorpus/lxc_consistency2

          * 81f8067 lxc: fix old lxc test

          * 458f506 seed: lint

          * 96b8d55 Fix seed.mkconfig yamldump

          * 76ddb68 lxc/applynet: conservative

          * ce7096f variable collision

          * 8a8b28d lxc: lint

          * 458b18b more lxc docs

          * ef1f952 lxc docs: typos

          * d67a43d more lxc docs

          * 608da5e modules/lxc: merge resolution

          * 27c4689 modules/lxc: more consistent comparison

          * 07c365a lxc: merge conflict spotted

          * 9993915 modules/lxc: rework settings for consistency

          * ce11d83 lxc: Global doc refresh

          * 61ed2f5 clouds/lxc: profile key is conflicting

   PR #24247: (rallytime) Backport #24220 to 2015.5
          @ 2015-05-29T21:40:01Z

          ISSUE  #24210:  (damonnk)  salt-cloud  vsphere.py  should  allow
          key_filename param
                 refs: #24220

          PR #24220: (djcrabhat)  adding  key_filename  param  to  vsphere
          provider
                 refs: #24247

          * da14f3b Merge pull request #24247 from rallytime/bp-24220

          * 0b1041d adding key_filename param to vsphere provider

   PR  #24254:  (rallytime)  Add  deprecation  warning to Digital Ocean v1
   Driver
          @ 2015-05-29T21:39:25Z

          PR #22731: (dmyerscough)  Decommission  DigitalOcean  APIv1  and
          have users use the new DigitalOcean APIv2
                 refs: #24254

          * 21d6126      Merge      pull      request      #24254     from
            rallytime/add_deprecation_warning_digitalocean

          * cafe37b Add note to docs about deprecation

          * ea0f1e0 Add deprecation warning to  digital  ocean  driver  to
            move to digital_ocean_v2

   PR #24252: (aboe76) Updated suse spec to 2015.5.1
          @ 2015-05-29T21:38:45Z

          * dac055d Merge pull request #24252 from aboe76/opensuse_package

          * 0ad617d Updated suse spec to 2015.5.1

   PR #24251: (garethgreenaway) Returners broken in 2015.5
          @ 2015-05-29T21:37:52Z

          * 49e7fe8      Merge      pull      request      #24251     from
            garethgreenaway/2015_5_returner_brokenness

          * 5df6b52 The code calling cfg as a function vs treating it as a
            dictionary  and  using  get  is  currently  backwards  causing
            returners to fail when used from  the  CLI  and  in  scheduled
            jobs.

   PR  #24255: (rallytime) Clarify digital ocean documentation and mention
   v1 driver deprecation
          @ 2015-05-29T21:37:07Z

          ISSUE #21498: (rallytime) Clarify Digital Ocean Documentation
                 refs: #24255

          * bfb9461     Merge      pull      request      #24255      from
            rallytime/clarify_digital_ocean_driver_docs

          * 8d51f75  Clarify  digital  ocean  documentation and mention v1
            driver deprecation

   PR #24232: (rallytime) Backport #23308 to 2015.5
          @ 2015-05-29T21:36:46Z

          PR #23308: (thusoy) Don't merge: Add missing jump  arguments  to
          iptables module
                 refs: #24232

          * 41f5756 Merge pull request #24232 from rallytime/bp-23308

          * 2733f66 Import string

          * 9097cca Add missing jump arguments to iptables module

   PR #24245: (Sacro) Unset PYTHONHOME when starting the service
          @ 2015-05-29T20:00:31Z

          * a95982c Merge pull request #24245 from Sacro/patch-2

          * 6632d06 Unset PYTHONHOME when starting the service

   PR   #24121:   (hvnsweeting)   deprecate  setting  user  permission  in
   rabbitmq_vhost.present
          @ 2015-05-29T15:55:40Z

          * 1504c76     Merge      pull      request      #24121      from
            hvnsweeting/rabbitmq-host-deprecate-set-permission

          * 2223158     deprecate     setting     user    permission    in
            rabbitmq_host.present

   PR #24179: (merll) Changing user and group only possible  for  existing
   ids.
          @ 2015-05-29T15:52:43Z

          PR  #24169:  (merll)  Changing  user and group only possible for
          existing ids.
                 refs: #24179

          * ba02f65     Merge      pull      request      #24179      from
            Precis/fix-file-uid-gid-2015.0

          * ee4c9d5 Use ids if user or group is not present.

   PR #24229: (msteed) Fix auth failure on syndic with external_auth
          @ 2015-05-29T15:04:06Z

          ISSUE   #24147:   (paclat)   Syndication   issues   when   using
          authentication on master of masters.
                 refs: #24229

          * 9bfb066 Merge pull request #24229 from msteed/issue-24147

          * 482d1cf Fix auth failure on syndic with external_auth

   PR #24234: (jayeshka) adding states/quota unit test case.
          @ 2015-05-29T14:14:27Z

          * 19fa43c     Merge      pull      request      #24234      from
            jayeshka/quota-states-unit-test

          * c233565 adding states/quota unit test case.

   PR #24217: (jfindlay) disable intermittently failing tests
          @ 2015-05-29T03:08:39Z

          ISSUE #40: (thatch45) Clean up timeouts
                 refs: #22857

          PR #23623: (jfindlay) Fix /jobs endpoint's return
                 refs: #24217

          PR #22857: (jacksontj) Fix /jobs endpoint's return
                 refs: #23623

          * e15142c      Merge      pull      request      #24217     from
            jfindlay/disable_bad_tests

          * 6b62804 disable intermittently failing tests

   PR #24199: (ryan-lane) Various fixes for boto_route53 and boto_elb
          @ 2015-05-29T03:02:41Z

          * ce8e43b Merge pull request #24199 from lyft/route53-fix-elb

          * d8dc9a7 Better unit tests for boto_elb state

          * 62f214b Remove cnames_present test

          * 7b9ae82 Lint fix

          * b74b0d1 Various fixes for boto_route53 and boto_elb

   PR  #24142:  (basepi)  Optimize  dictupdate.update   and   add   #24097
   functionality
          refs: #24262

          @ 2015-05-29T03:00:56Z

          PR #24097: (kiorky) Optimize dictupdate
                 refs: #24142 #24142

          PR  #21968:  (ryanwohara)  Verifying  the key has a value before
          using  it.   *  a43465d   Merge   pull   request   #24142   from
          basepi/dictupdate24097 * 5c6e210 Deepcopy on merge_recurse

          * a13c84a Fix None check from #21968

          * 9ef2c64 Add docstring

          * 8579429 Add in recursive_update from #24097

          * 8599143 if key not in dest, don't recurse

          * d8a84b3 Rename klass to valtype

   PR #24208: (jayeshka) adding states/ports unit test case.
          @ 2015-05-28T23:06:33Z

          * 526698b      Merge      pull      request      #24208     from
            jayeshka/ports-states-unit-test

          * 657b709 adding states/ports unit test case.

   PR #24219: (jfindlay) find zfs without modinfo
          @ 2015-05-28T21:07:26Z

          ISSUE #20635: (dennisjac) 2015.2.0rc1: zfs errors in  log  after
          update
                 refs: #24219

          * d00945f Merge pull request #24219 from jfindlay/zfs_check

          * 15d4019 use the salt loader in the zfs mod

          * 5599b67 try to search for zfs if modinfo is unavailable

   PR #24190: (msteed) Fix issue 23815
          @ 2015-05-28T20:10:34Z

          ISSUE  #23815:  (Snergster)  [beacons]  inotify errors on subdir
          creation   *   3dc4b85   Merge   pull   request   #24190    from
          msteed/issue-23815 * 086a1a9 lint

          * 65de62f fix #23815

          * d04e916 spelling

          * db9f682 add inotify beacon unit tests

   PR #24211: (rallytime) Backport #24205 to 2015.5
          @ 2015-05-28T18:28:15Z

          PR      #24205:      (hazelesque)      Docstring      fix     in
          salt.modules.yumpkg.hold
                 refs: #24211

          * 436634b Merge pull request #24211 from rallytime/bp-24205

          * 23284b5 Docstring fix in salt.modules.yumpkg.hold

   PR #24212: (terminalmage) Clarify error in rendering template  for  top
   file
          @ 2015-05-28T18:26:20Z

          * cc58624      Merge      pull      request      #24212     from
            terminalmage/clarify-error-msg

          * ca807fb Clarify error in rendering template for top file

   PR #24213: (The-Loeki) ShouldFix _- troubles in debian_ip
          @ 2015-05-28T18:24:39Z

          ISSUE #23904: (mbrgm) Network config bonding section  cannot  be
          parsed when attribute names use dashes
                 refs: #23917

          ISSUE  #23900:  (hashi825)  salt  ubuntu  network building issue
          2015.5.0
                 refs: #23922

          PR #23922: (garethgreenaway) Fixes to debian_ip.py
                 refs: #24213

          PR #23917: (corywright) Split debian  bonding  options  on  dash
          instead of underscore
                 refs: #24213

          * 9825160 Merge pull request #24213 from The-Loeki/patch-3

          * a68d515 ShouldFix _- troubles in debian_ip

   PR #24214: (basepi) 2015.5.1release
          @ 2015-05-28T16:23:57Z

          * 071751d Merge pull request #24214 from basepi/2015.5.1release

          * e5ba31b 2015.5.1 release date

          * 768494c Update latest release in docs

   PR #24202: (rallytime) Backport #24186 to 2015.5
          @ 2015-05-28T05:16:48Z

          PR #24186: (thcipriani) Update salt vagrant provisioner info
                 refs: #24202

          * c2f1fdb Merge pull request #24202 from rallytime/bp-24186

          * db793dd Update salt vagrant provisioner info

   PR #24192: (rallytime) Backport #20474 to 2015.5
          @ 2015-05-28T05:16:18Z

          PR #20474: (djcrabhat) add sudo, sudo_password params to vsphere
          deploy to allow for non-root deploys
                 refs: #24192

          * 8a085a2 Merge pull request #24192 from rallytime/bp-20474

          * fd3c783 add sudo, sudo_password params to deploy to allow  for
            non-root deploys

   PR #24184: (rallytime) Backport #24129 to 2015.5
          @ 2015-05-28T05:15:08Z

          PR #24129: (pengyao) Wheel client doc
                 refs: #24184

          * 7cc535b Merge pull request #24184 from rallytime/bp-24129

          * 722a662 fixed a typo

          * 565eb46 Add cmd doc for WheelClient

   PR #24183: (rallytime) Backport #19320 to 2015.5
          @ 2015-05-28T05:14:36Z

          PR  #19320: (clan) add 'state_output_profile' option for profile
          output
                 refs: #24183

          * eb0af70 Merge pull request #24183 from rallytime/bp-19320

          * 55db1bf sate_output_profile default to True

          * 9919227 fix type: statei -> state

          * 0549ca6 add 'state_output_profile' option for profile output

   PR  #24201:  (whiteinge)  Add  list  of  client   libraries   for   the
   rest_cherrypy module to the top-level documentation
          @ 2015-05-28T02:12:09Z

          * 1b5bf23      Merge      pull      request      #24201     from
            whiteinge/rest_cherrypy-client-libs

          * 5f71802 Add list of client  libraries  for  the  rest_cherrypy
            module

          * 28fc77f Fix rest_cherrypy config example indentation

   PR #24195: (rallytime) Merge #24185 with a couple of fixes
          @ 2015-05-27T22:18:37Z

          PR #24185: (jacobhammons) Fixes for doc build errors
                 refs: #24195

          * 3307ec2 Merge pull request #24195 from rallytime/merge-24185

          * d8daa9d Merge #24185 with a couple of fixes

          * 634d56b Fixed pylon error

          * 0689815 Fixes for doc build errors

   PR #24166: (jayeshka) adding states/pkgng unit test case.
          @ 2015-05-27T20:27:49Z

          * 7e400bc      Merge      pull      request      #24166     from
            jayeshka/pkgng-states-unit-test

          * 2234bb0 adding states/pkgng unit test case.

   PR #24189: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5
          @ 2015-05-27T20:26:31Z

          PR #24178: (rallytime)  Backport  #24118  to  2014.7,  too.   PR
          #24159: (rallytime) Fill out modules/keystone.py CLI Examples PR
          #24158: (rallytime) Fix test_valid_docs test for tls  module  PR
          #24118: (trevor-h) removed deprecated pymongo usage
             refs: #24139 #24178

          * 9fcda79      Merge      pull      request      #24189     from
            basepi/merge-forward-2015.5

          * 8839e9c Merge remote-tracking  branch  'upstream/2014.7'  into
            merge-forward-2015.5

          * 9d7331c Merge pull request #24178 from rallytime/bp-24118

            * e2217a0  removed  deprecated  pymongo  usage  as  no  longer
              functional with pymongo > 3.x

          * 4e8c503     Merge      pull      request      #24159      from
            rallytime/keystone_doc_examples

            * dadac8d Fill out modules/keystone.py CLI Examples

          * fc10ee8 Merge pull request #24158 from rallytime/fix_doc_error

            * 49a517e Fix test_valid_docs test for tls module

   PR #24181: (jtand) Fixed error where file was evaluated as a symlink in
   test_absent
          @ 2015-05-27T18:26:28Z

          * 2303dec Merge pull request #24181 from jtand/file_test

          * 5f0e601 Fixed error where file was evaluated as a  symlink  in
            test_absent

   PR #24180: (terminalmage) Skip libvirt tests if not running as root
          @ 2015-05-27T18:18:47Z

          * a162768      Merge      pull      request      #24180     from
            terminalmage/fix-libvirt-test

          * 72e7416 Skip libvirt tests if not running as root

   PR #24165: (jayeshka) adding states/portage_config unit test case.
          @ 2015-05-27T17:15:08Z

          * 1fbc5b2     Merge      pull      request      #24165      from
            jayeshka/portage_config-states-unit-test

          * 8cf1505 adding states/portage_config unit test case.

   PR #24164: (jayeshka) adding states/pecl unit test case.
          @ 2015-05-27T17:14:26Z

          * 4747856      Merge      pull      request      #24164     from
            jayeshka/pecl-states-unit-test

          * 563a5b3 adding states/pecl unit test case.

   PR #24160: (The-Loeki) small enhancement to data module; pop()
          @ 2015-05-27T17:03:10Z

          * cdaaa19 Merge pull request #24160 from The-Loeki/patch-1

          * 2175ff3 doc & merge fix

          * eba382c small enhancement to data module; pop()

   PR #24153: (techhat) Batch mode sometimes improperly  builds  lists  of
   minions to process
          @ 2015-05-27T16:21:53Z

          * 4a8dbc7 Merge pull request #24153 from techhat/batchlist

          * 467ba64 Make sure that minion IDs are strings

   PR #24167: (jayeshka) adding states/pagerduty unit test case.
          @ 2015-05-27T16:14:01Z

          * ed8ccf5      Merge      pull      request      #24167     from
            jayeshka/pagerduty-states-unit-test

          * 1af8c83 adding states/pagerduty unit test case.

   PR #24156: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5
          @ 2015-05-27T15:05:01Z

          ISSUE #23464: (tibold) cmd_iter_no_block() blocks
                 refs: #24093

          PR #24125: (hvnsweeting)  Fix  rabbitmq  test  mode  PR  #24093:
          (msteed)   Make  LocalClient.cmd_iter_no_block()  not  block  PR
          #24008:  (davidjb)  Correct  reST  formatting   for   states.cmd
          documentation  PR  #23933:  (jacobhammons) sphinx saltstack2 doc
          theme   *   b9507d1   Merge    pull    request    #24156    from
          basepi/merge-forward-2015.5 * e52b5ab Remove stray >>>>>

          * 7dfbd92  Merge  remote-tracking  branch 'upstream/2014.7' into
            merge-forward-2015.5

            * c0d32e0     Merge     pull     request      #24125      from
              hvnsweeting/fix-rabbitmq-test-mode

              * 71862c6 enhance log

              * 28e2594  change according to new output of rabbitmq module
                functions

              * cd0212e processes and returns better output  for  rabbitmq
                module

            * 39a8f30 Merge pull request #24093 from msteed/issue-23464

              * fd35903 Fix failing test

              * 41b344c Make LocalClient.cmd_iter_no_block() not block

            * 5bffd30 Merge pull request #24008 from davidjb/2014.7

              * 8b8d029 Correct reST formatting for documentation

            * 1aa0420 Merge pull request #23933 from jacobhammons/2014.7

            * a3613e6 removed numbering from doc TOC

            * 78b737c  removed  2015.* release from release notes, updated
              index page to remove PDF/epub links

            * e867f7d Changed build settings to use saltstack2  theme  and
              update release versions.

            * 81ed9c9 sphinx saltstack2 doc theme

   PR #24145: (jfindlay) attempt to decode win update package
          @ 2015-05-26T23:20:20Z

          ISSUE #24102: (bormotov) win_update encondig problems
                 refs: #24145

          * 05745fa      Merge      pull      request      #24145     from
            jfindlay/win_update_encoding

          * cc5e17e attempt to decode win update package

   PR #24123: (kiorky) fix service enable/disable change
          @ 2015-05-26T21:24:19Z

          ISSUE  #24122:  (kiorky)  service.dead  is  no  more   stateful:
          services does not handle correctly enable/disable change state
                 refs: #24123

          * 7024789 Merge pull request #24123 from makinacorpus/ss

          * 2e2e1d2 fix service enable/disable change

   PR  #24146:  (rallytime)  Fixes  the  boto_vpc_test failure on CentOS 5
   tests
          @ 2015-05-26T20:15:19Z

          * 51c3cec     Merge      pull      request      #24146      from
            rallytime/fix_centos_boto_failure

          * ac0f97d Fixes the boto_vpc_test failure on CentOS 5 tests

   PR  #24144:  (twangboy)  Compare Keys ignores all newlines and carriage
   returns
          @ 2015-05-26T19:25:48Z

          ISSUE #24052: (twangboy) v2015.5.1 Changes the way it interprets
          the minion_master.pub file
                 refs: #24089 #24144

          ISSUE  #23566:  (rks2286)  Salt-cp  corrupting  the  file  after
          transfer to minion
                 refs: #24144 #23740

          PR #23740: (jfindlay) Binary write
                 refs: #24144

          * 1c91a21 Merge pull request #24144 from twangboy/fix_24052

          * c197b41  Compare  Keys  removing  all  newlines  and  carriage
            returns

   PR #24139: (rallytime) Backport #24118 to 2015.5
          @ 2015-05-26T18:24:27Z

          PR #24118: (trevor-h) removed deprecated pymongo usage
                 refs: #24139 #24178

          * 0841667 Merge pull request #24139 from rallytime/bp-24118

          * 4bb519b   removed   deprecated  pymongo  usage  as  no  longer
            functional with pymongo > 3.x

   PR #24138: (rallytime) Backport #24116 to 2015.5
          @ 2015-05-26T18:23:51Z

          PR #24116: (awdrius) Fixed typo in chown username  (ending  dot)
          that fails the command.
                 refs: #24138

          * 742eca2 Merge pull request #24138 from rallytime/bp-24116

          * 7f08641  Fixed  typo in chown username (ending dot) that fails
            the command.

   PR #24137: (rallytime) Backport #24105 to 2015.5
          @ 2015-05-26T18:23:40Z

          PR #24105: (cedwards) Updated some beacon-specific documentation
          formatting
                 refs: #24137

          * e01536d Merge pull request #24137 from rallytime/bp-24105

          * f0778a0 Updated some beacon-specific documentation formatting

   PR #24136: (rallytime) Backport #24104 to 2015.5
          @ 2015-05-26T15:58:47Z

          ISSUE  #23364:  (pruiz)  Unable  to  destroy  host using proxmox
          cloud: There was an error destroying machines: 501 Server Error:
          Method 'DELETE /nodes/pmx1/openvz/openvz/100' not implemented PR
          #24104: (pruiz) Only try to  stop  a  VM  if  it's  not  already
          stopped. (fixes #23364)
             refs: #24136

          * 89cdf97 Merge pull request #24136 from rallytime/bp-24104

          * c538884  Only  try  to  stop a VM if it's not already stopped.
            (fixes #23364)

   PR #24135: (rallytime) Backport #24083 to 2015.5
          @ 2015-05-26T15:58:27Z

          PR #24083: (swdream) fix code block syntax
                 refs: #24135

          * 67c4373 Merge pull request #24135 from rallytime/bp-24083

          * e1d06f9 fix code block syntax

   PR #24131: (jayeshka) adding states/mysql_user unit test case
          @ 2015-05-26T15:58:10Z

          * a83371e     Merge      pull      request      #24131      from
            jayeshka/mysql_user-states-unit-test

          * ed1ef69 adding states/mysql_user unit test case

   PR #24130: (jayeshka) adding states/ntp unit test case
          @ 2015-05-26T15:57:29Z

          * 1dc1d2a      Merge      pull      request      #24130     from
            jayeshka/ntp-states-unit-test

          * ede4a9f adding states/ntp unit test case

   PR #24128: (jayeshka) adding states/openstack_config unit test case
          @ 2015-05-26T15:56:08Z

          * 3943417     Merge      pull      request      #24128      from
            jayeshka/openstack_config-states-unit-test

          * ca09e0f adding states/openstack_config unit test case

   PR #24127: (jayeshka) adding states/npm unit test case
          @ 2015-05-26T15:55:18Z

          * 23f25c4      Merge      pull      request      #24127     from
            jayeshka/npm-states-unit-test

          * c3ecabb adding states/npm unit test case

   PR #24077: (anlutro) Change how state_verbose output is filtered
          @ 2015-05-26T15:41:11Z

          ISSUE #24009: (hvnsweeting) state_verbose False summary is wrong
                 refs: #24077

          * 07488a4     Merge      pull      request      #24077      from
            alprs/fix-outputter_highstate_nonverbose_count

          * 7790408 Change how state_verbose output is filtered

   PR #24119: (jfindlay) Update contrib docs
          @ 2015-05-26T15:37:01Z

          * 224820f      Merge      pull      request      #24119     from
            jfindlay/update_contrib_docs

          * fa2d411 update example release branch in contrib docs

          * a0b76b5 clarify git rebase instructions

          * 3517e00 fix contribution docs link typos

          * 651629c backport dev contrib doc updates to 2015.5

   PR #23928: (joejulian) Add the ability to replace existing certificates
          @ 2015-05-25T19:47:26Z

          * 5488c4a     Merge      pull      request      #23928      from
            joejulian/2015.5_tls_module_replace_existing

          * 4a4cbdd Add the ability to replace existing certificates

   PR  #24078:  (jfindlay)  if  a  charmap  is not supplied, set it to the
   codeset
          @ 2015-05-25T19:39:19Z

          ISSUE #23221:  (Reiner030)  Debian  Jessie:  locale.present  not
          working again
                 refs: #24078

          * dd90ef0 Merge pull request #24078 from jfindlay/locale_charmap

          * 5eb97f0 if a charmap is not supplied, set it to the codeset

   PR #24088: (jfindlay) pkg module integration tests
          @ 2015-05-25T19:39:02Z

          * 9cec5d3 Merge pull request #24088 from jfindlay/pkg_tests

          * f1bd5ec adding pkg module integration tests

          * 739b2ef rework yumpkg refresh_db so args are not mandatory

   PR #24089: (jfindlay) allow override of binary file mode on windows
          @ 2015-05-25T19:38:44Z

          ISSUE #24052: (twangboy) v2015.5.1 Changes the way it interprets
          the minion_master.pub file
                 refs: #24089 #24144

          * 517552c Merge pull request #24089 from jfindlay/binary_write

          * b2259a6 allow override of binary file mode on windows

   PR #24092: (jfindlay) collect scattered contents edits, ensure  it's  a
   str
          @ 2015-05-25T19:38:10Z

          ISSUE    #23973:    (mschiff)    state   file.managed:   setting
          contents_pillar to a pillar which is  a  list  throws  exception
          instead giving descriptive error message
                 refs: #24092

          * 121ab9f Merge pull request #24092 from jfindlay/file_state

          * cfa0f13 collect scattered contents edits, ensure it's a str

   PR #24112: (The-Loeki) thin_gen breaks when thinver doesn't exist
          @ 2015-05-25T19:37:47Z

          * 84e65de Merge pull request #24112 from The-Loeki/patch-1

          * 34646ea thin_gen breaks when thinver doesn't exist

   PR #24108: (jayeshka) adding states/mysql_query unit test case
          @ 2015-05-25T12:30:48Z

          * ec509ed      Merge      pull      request      #24108     from
            jayeshka/mysql_query-states-unit-test

          * ec50450 adding states/mysql_query unit test case

   PR #24110: (jayeshka) adding varnish unit test case
          @ 2015-05-25T12:30:21Z

          * f2e5d6c     Merge      pull      request      #24110      from
            jayeshka/varnish-unit-test

          * e119889 adding varnish unit test case

   PR #24109: (jayeshka) adding states/mysql_grants unit test case
          @ 2015-05-25T12:29:53Z

          * 4fca2b4      Merge      pull      request      #24109     from
            jayeshka/mysql_grants-states-unit-test

          * 11a93cb adding states/mysql_grants unit test case

   PR #24028: (nleib) send a disable message to disable puppet
          @ 2015-05-25T04:02:11Z

          * 6b43c9a Merge pull request #24028 from nleib/2015.5

          * 15f24b4 update format of string in disabled msg

          * 7690e5b remove trailing whitespaces

          * 56a9720 Update puppet.py

          * 9686391 Update puppet.py

          * 33f3d68 send a disable message to disable puppet

   PR #24100: (jfindlay) adding states/file unit test case
          @ 2015-05-24T05:17:54Z

          PR #23963: (jayeshka) adding states/file unit test case
                 refs: #24100

          * 52c9aca Merge pull request #24100 from jfindlay/merge_23963

          * 7d59deb adding states/file unit test case

   PR #24098: (galet) Systemd not recognized properly on Oracle Linux 7
          @ 2015-05-24T04:07:31Z

          ISSUE #21446: (dpheasant) check for systemd on Oracle Linux
                 refs: #24098

          * 0eb9f15 Merge pull request #24098 from galet/2015.5

          * 4d6ab21 Systemd not recognized properly on Oracle Linux 7

   PR #24090: (jfindlay) adding states/mount unit test case
          @ 2015-05-22T23:02:57Z

          PR #24062: (jayeshka) adding states/mount unit test case
                 refs: #24090

          * 8e04db7 Merge pull request #24090 from jfindlay/merge_24062

          * a81a922 adding states/mount unit test case

   PR #24086: (rallytime) Backport #22806 to 2015.5
          @ 2015-05-22T21:18:20Z

          ISSUE #22574: (unicolet) error when which is not available
                 refs: #22806

          PR #22806: (jfindlay) use cmd.run_all instead of cmd.run_stdout
                 refs: #24086

          * c0079f5 Merge pull request #24086 from rallytime/bp-22806

          * f728f55 use cmd.run_all instead of cmd.run_stdout

   PR #24024: (jayeshka) adding states/mongodb_user unit test case
          @ 2015-05-22T20:53:19Z

          * 09de253     Merge      pull      request      #24024      from
            jayeshka/mongodb_user-states-unit-test

          * f31dc92 resolved errors

          * d038b1f adding states/mongodb_user unit test case

   PR #24065: (kiorky) continue to fix #23883
          refs: #24080 #24066

          @ 2015-05-22T18:59:21Z

          ISSUE  #23883:  (kaithar)  max_event_size seems broken * bfd812c
          Merge pull request #24065 from makinacorpus/real23883 *  028282e
          continue to fix #23883

   PR #24029: (kiorky) Fix providers handling
          @ 2015-05-22T16:56:06Z

          ISSUE  #24017: (arthurlogilab) [salt-cloud openstack] TypeError:
          unhashable type: 'dict' on map creation
                 refs: #24029

          * 429adfe     Merge      pull      request      #24029      from
            makinacorpus/fixproviders

          * 412b39b Fix providers handling

   PR #23936: (jfindlay) remove unreachable returns in file state
          @ 2015-05-22T16:26:49Z

          * a42cccc Merge pull request #23936 from jfindlay/file_state

          * ac29c0c also validate file.recurse source parameter

          * 57f7388 remove unreachable returns in file state

   PR #24063: (jayeshka) removed tuple index error
          @ 2015-05-22T14:58:20Z

          * 8b69b41      Merge      pull      request      #24063     from
            jayeshka/mount-states-module

          * b9745d5 removed tuple index error

   PR #24057: (rallytime) Backport #22572 to 2015.5
          @ 2015-05-22T05:36:25Z

          PR #22572: (The-Loeki) Small docfix for GitPillar
                 refs: #24057

          * 02ac4aa Merge pull request #24057 from rallytime/bp-22572

          * 49aad84 Small docfix for GitPillar

   PR #24040: (rallytime) Backport #24027 to 2015.5
          @ 2015-05-21T23:43:54Z

          ISSUE #23088: (wfhg) Segfault when adding a Zypper repo on  SLES
          11.3
                 refs: #24027

          PR #24027: (wfhg) Add baseurl to salt.modules.zypper.mod_repo
                 refs: #24040

          * 82de059 Merge pull request #24040 from rallytime/bp-24027

          * 37d25d8  Added  baseurl  as  alias  for  url and mirrorlist in
            salt.modules.zypper.mod_repo.

   PR #24039: (rallytime) Backport #24015 to 2015.5
          @ 2015-05-21T23:43:25Z

          PR #24015: (YanChii) minor improvement of solarisips docs &  fix
          typos
                 refs: #24039

          * d909781 Merge pull request #24039 from rallytime/bp-24015

          * 6bfaa94 minor improvement of solarisips docs & fix typos

   PR #24038: (rallytime) Backport #19599 to 2015.5
          @ 2015-05-21T23:43:10Z

          ISSUE  #19598:  (fayetted) ssh_auth.present test=true incorectly
          reports changes will be made
                 refs: #19599

          PR #19599: (fayetted) Fix ssh_auth test mode, compare lines  not
          just key
                 refs: #24038

          * 4a0f254 Merge pull request #24038 from rallytime/bp-19599

          * ea00d3e Fix ssh_auth test mode, compare lines not just key

   PR  #24046:  (rallytime)  Remove key management test from digital ocean
   cloud tests
          @ 2015-05-21T22:32:04Z

          * 42b87f1     Merge      pull      request      #24046      from
            rallytime/remove_key_test

          * 1d031ca  Remove  key  management test from digital ocean cloud
            tests

   PR #24044: (cro) Remove spurious log message, fix typo in doc
          @ 2015-05-21T22:31:49Z

          * eff54b1 Merge pull request #24044 from cro/pgjsonb

          * de06633 Remove spurious log message, fix typo in doc

   PR #24001: (msteed) issue #23883
          @ 2015-05-21T20:32:30Z

          ISSUE #23883: (kaithar) max_event_size seems  broken  *  ac32000
          Merge  pull  request  #24001  from  msteed/issue-23883 * bea97a8
          issue #23883

   PR #23995: (kiorky) Lxc path pre
          @ 2015-05-21T17:26:03Z

          * f7fae26     Merge      pull      request      #23995      from
            makinacorpus/lxc_path_pre

          * 319282a lint

          * 1dc67e5 lxc: versionadded

          * fcad7cb lxc: states improvements

          * 644bd72 lxc: more consistence for profiles

          * 139372c lxc: remove merge cruft

          * 725b046 lxc: Repair merge

   PR #24032: (kartiksubbarao) Update augeas_cfg.py
          @ 2015-05-21T17:03:42Z

          ISSUE  #16383:  (interjection) salt.states.augeas.change example
          from docs fails with exception
                 refs: #24032

          * 26d6851     Merge      pull      request      #24032      from
            kartiksubbarao/augeas_insert_16383

          * 3686dcd Update augeas_cfg.py

   PR #24025: (jayeshka) adding timezone unit test case
          @ 2015-05-21T16:50:53Z

          * 55c9245      Merge      pull      request      #24025     from
            jayeshka/timezone-unit-test

          * 1ec33e2 removed assertion error

          * 16ecb28 adding timezone unit test case

   PR #24023: (jayeshka) adding states/mongodb_database unit test case
          @ 2015-05-21T16:49:17Z

          * e243617     Merge      pull      request      #24023      from
            jayeshka/mongodb_database-states-unit-test

          * 5a9ac7e adding states/mongodb_database unit test case

   PR #24022: (jayeshka) adding states/modjk_worker unit test case
          @ 2015-05-21T16:48:29Z

          * b377bd9      Merge      pull      request      #24022     from
            jayeshka/modjk_worker-states-unit-test

          * 05c0a98 adding states/modjk_worker unit test case

   PR #24005: (msteed) issue #23776
          @ 2015-05-21T01:55:34Z

          ISSUE  #23776:  (enblde)  Presence  change   events   constantly
          reporting  all  minions  as  new  in 2015.5 * 701c51b Merge pull
          request #24005 from msteed/issue-23776 * 62e67d8 issue #23776

   PR #23996: (neogenix) iptables state generates a 0  position  which  is
   invalid in iptables cli #23950
          @ 2015-05-20T22:44:27Z

          ISSUE  #23950:  (neogenix) iptables state generates a 0 position
          which is invalid in iptables cli
                 refs: #23996

          * 17b7c0b Merge pull request #23996 from neogenix/2015.5-23950

          * ad417a5 fix for #23950

   PR #23994: (rallytime) Skip the gpodder pkgrepo test for  Ubuntu  15  -
   they don't have vivid ppa up yet
          @ 2015-05-20T21:18:21Z

          * 4cb8773      Merge      pull      request      #23994     from
            rallytime/skip_test_ubuntu_15

          * 9e0ec07 Skip the gpodder pkgrepo test - they don't have  vivid
            ppa up yet

   Salt 2015.5.3 Release Notes
   Extended     Changelog     Courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-07-01T19:40:52Z

   Statistics:

   * Total Merges: 177

   * Total Issue references: 81

   * Total PR references: 231

   Changes:

   * PR #25096: (jfindlay) Postgres group test @ 2015-07-01T18:48:26Z

     * PR #24330: (jayeshka) adding states/postgres_group unit test  case.
       | refs: #25096

     * 21709aa Merge pull request #25096 from jfindlay/postgres_group_test

     * 3c379dc declobber postgres state unit test mocking

     * a162ffa adding states/postgres_group unit test case.

   * PR  #25085:  (jfindlay)  accept  all  sources  in  the  file  state @
     2015-07-01T18:23:45Z

     * ISSUE #25041: (wt)  REGRESSION:  pillar.get  of  integer  fails  to
       render in sls | refs: #25085

     * 0a84640 Merge pull request #25085 from jfindlay/fix_file

     * 937a252 remove unnecessary file state tests

     * 6f238e9 integration test file.managed sources

     * a5978d3 iterate an iterable source othwerise list+str it

   * PR #25095: (jfindlay) Win groupadd unit tests @ 2015-07-01T18:18:53Z

     * PR  #24207: (jayeshka) adding win_groupadd unit test case.  | refs:
       #25095

     * a983942 Merge pull request #25095 from jfindlay/win_groupadd_test

     * 564dffd depend on win libs rather than mocking them

     * 9b9aeb8 resolved all errors.

     * aaf8935 adding win_groupadd unit test case.

   * PR #25089: (jfindlay) fix minion sudo @ 2015-07-01T15:53:16Z

     * ISSUE #21520: (jfindlay) sudo.salt_call is broken | refs: #25089

     * PR #20226: (thatch45) Allow sudo priv escalation | refs: #25089

     * 7c8d2a8 Merge pull request #25089 from jfindlay/fix_sudo

     * d8f91d4 add some apprehension to the sudo exec module

     * a9269c0 adding sudo exec module docs

     * e4a40b7 comment whitespace in minion config

     * 44cb167 adding sudo_user minion config docs

     * d461060 adding sudo_user minion config to default

   * PR #25099: (driskell) Fix broken batch results @ 2015-07-01T15:51:29Z

     * ISSUE #24875: (ahammond) ValueError: list.remove(x): x not in  list
       in     File   "/usr/lib/python2.6/site-packages/salt/cli/batch.py",
       line 179, in run active.remove(minion) | refs: #25099

     * 4d6078e Merge pull request #25099 from driskell/patch-1

     * 59b23e5 Fix broken batch results

   * PR #25083: (steverweber) ipmi: get_sensor_data would  always  fail  @
     2015-06-30T20:57:21Z

     * 4635079 Merge pull request #25083 from steverweber/fix_ipmi_stat

     * 836f48c include _ in IpmiCommand

     * 817e434 get_sensor_data would always fail

   * PR    #25067:    (The-Loeki)   Fix   for   maxdepth=0   in   find   @
     2015-06-30T20:54:06Z

     * 15f2a40 Merge pull request #25067 from The-Loeki/patch-1

     * 61edad3 Fix for maxdepth=0 in find

   * PR #25078: (terminalmage) Use  smaller  number  for  upper  limit  of
     mac_user's _first_avail_uid helper function @ 2015-06-30T20:53:24Z

     * 58d933c Merge pull request #25078 from terminalmage/fix-mac-uid

     * df2ab7e   Use   smaller   number  for  upper  limit  of  mac_user's
       _first_avail_uid helper function

   * PR #25045:  (garethgreenaway)  Fixes  to  debian_ip.py  in  2015.5  @
     2015-06-30T17:36:43Z

     * ISSUE  #24521:  (multani)  State  network.managed  fails  on Debian
       (Jessie) | refs: #25045

     * ebd6cdc      Merge       pull       request       #25045       from
       garethgreenaway/24521_debian_networking

     * 6f2a6c9  having  proto default to static since it's needed to build
       the template.

   * PR #25065:  (lorengordon)  Add  download  links  for  2015.5.1-3  and
     2015.5.2 Windows installers @ 2015-06-30T15:29:31Z

     * ISSUE  #25057: (TheBigBear) why is there still no newer salt-minion
       for windows than ver. 2015.5.0-2? no 2015.5.1 or 2015.5.2?

     * ae31b27      Merge       pull       request       #25065       from
       lorengordon/update-windows-installer-links

     * 40a0c13  Add  download  links  for  2015.5.1-3  and 2015.5.2, Fixes
       #25057

   * PR #25052: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-06-30T01:05:00Z

     * ISSUE  #15209:  (hubez)  file.manage:  source_hash not working with
       s3:// (2014.7.0rc1) | refs: #25011

     * PR #25011: (notpeter) Add s3 to protocols  for  remote  source_hash
       (2014.7 backport)

     * ddaeb0f Merge pull request #25052 from basepi/merge-forward-2015.5

     * 2c5e664   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

     * a7154e7 Merge pull request #25011 from notpeter/s3_2014.7_backport

       * 8b8af64 Add s3 to protocols for remote source_hash

   * PR #25038: (jfindlay) versionadded @ 2015-06-29T19:49:27Z

     * PR #24747: (msciciel) add get_route function to  network  module  |
       refs: #25038

     * c7003d4 Merge pull request #25038 from jfindlay/versionadded

     * d6dc6f9 versionadded

   * PR  #24747:  (msciciel)  add  get_route  function to network module |
     refs: #25038 @ 2015-06-29T16:51:43Z

     * 28c87ca Merge pull request #24747 from msciciel/2015.5

     * 79b4ec2 network module lint fix

     * 0b6ef78 network module: fix for ipv6

     * f3d184c add get_route function to network module

   * PR #24975: (ryan-lane) Fix update of undefined env var in npm  module
     @ 2015-06-29T16:45:05Z

     * 46a9677 Merge pull request #24975 from lyft/npm-module-fix

     * 6fde581 Try byte literals rather than unicode strings in the env

     * c8514de Fix update of undefined env var in npm module

   * PR #24986: (heewa) Don't modify empty change @ 2015-06-29T16:44:17Z

     * 9cf8550       Merge       pull       request       #24986      from
       heewa/fix-pkg-hold-when-errored

     * d47a448 Don't modify empty change

   * PR #24999: (rallytime) Provide a  less  confusing  error  when  cloud
     provider is misconfigured @ 2015-06-29T16:43:31Z

     * ISSUE  #24969:  (bradthurber)  salt-cloud  2015.5.0:  missing azure
       dependency results in misleading error | refs: #24999

     * ece897d Merge pull request #24999 from rallytime/cloud_error_help

     * 1e81a88 Clean up

     * be19a67 Provide a less  confusing  error  when  cloud  provider  is
       misconfigured

   * PR #24987: (heewa) Don't try to cache a template when it's not a file
     @ 2015-06-29T14:02:59Z

     * 4af15cf      Merge       pull       request       #24987       from
       heewa/fix-trying-to-cache-no-file

     * 9ae0c78 Don't try to cache a template when it's not a file

   * PR  #25022:  (jfindlay)  revise  label  and milestone documentation @
     2015-06-29T13:51:24Z

     * 8eeaddb Merge pull request #25022 from jfindlay/label_docs

     * 8575192 revise label and milestone documentation

   * PR  #25029:  (jayeshka)  adding   redismod   unit   test   case.    @
     2015-06-29T13:50:33Z

     * 89c2e01 Merge pull request #25029 from jayeshka/redismod-unit-test

     * e3045be adding redismod unit test case.

   * PR #24995: (rallytime) Fix deprecated pymongo usage causing errors in
     latest pymongo @ 2015-06-27T22:28:56Z

     * PR #24175: (trevor-h) fix deprecated pymongo usage  causing  errors
       in latest pymongo | refs: #24995

     * 6425252 Merge pull request #24995 from rallytime/tops_mongo

     * a3c1063  fix  deprecated  pymongo  usage  causing  errors in latest
       pymongo

   * PR #24994: (garethgreenaway)  Another  Fix  to  gpg.py  in  2015.5  @
     2015-06-27T22:28:15Z

     * ISSUE  #24862:  (dkatsanikakis)  gpg.import_key returns error after
       successfully completed | refs: #24966 #24994

     * e9aaa11      Merge       pull       request       #24994       from
       garethgreenaway/2015_5_24862_gpg_import_key

     * d2f0d8f  variable  was referenced before assignment.  Just removing
       the     variable     and     checking     the      return      from
       distutils.version.LooseVersion directly.

   * PR  #24988:  (jayeshka)  adding states/supervisord unit test case.  @
     2015-06-27T22:24:42Z

     * ebd666e      Merge       pull       request       #24988       from
       jayeshka/supervisord-states-unit-test

     * bb0a6d5 adding states/supervisord unit test case.

   * PR  #25007:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-06-26T21:28:57Z

     * ISSUE #24915: (jtand) Salt-cloud not working in  2014.7.6  |  refs:
       #24944

     * PR #24944: (techhat) Double-check main_cloud_config

     * PR  #24936:  (jtand)  Fixed ps module to not use depreciated psutil
       commands

     * 0487c3c Merge pull request #25007 from basepi/merge-forward-2015.5

     * 4980fd5  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * a11e4c6 Merge pull request #24944 from techhat/issue24915

       * 59c3081 Double-check main_cloud_config

     * d26a544 Merge pull request #24936 from jtand/psutil

       * bdb7a19 Fixed ps module to not use depreciated psutil commands

   * PR #25003: (jacobhammons) Updated man pages @ 2015-06-26T19:13:41Z

     * 91a60e1 Merge pull request #25003 from jacobhammons/man-pages

     * cf97a4a Updated man pages

   * PR    #25002:    (jacobhammons)   sphinx   html   theme   updates   @
     2015-06-26T18:39:14Z

     * a60a2c4      Merge       pull       request       #25002       from
       jacobhammons/doc-announcements

     * f88f344 sphinx html theme updates

   * PR  #24977:  (rallytime) Only warn about digital ocean deprecation if
     digital ocean is configured @ 2015-06-25T23:54:46Z

     * a791b23 Merge pull request #24977 from rallytime/do_move_warning

     * 6b54422 Only warn about digital ocean deprecation if digital  ocean
       is configured

   * PR   #24966:   (garethgreenaway)   Fixes   to   gpg.py  in  2015.5  @
     2015-06-25T19:58:49Z

     * ISSUE #24862: (dkatsanikakis) gpg.import_key  returns  error  after
       successfully completed | refs: #24966 #24994

     * a71c1b7       Merge       pull       request       #24966      from
       garethgreenaway/2015_5_24862_gpg_import_key

     * 55eb73b fixing unit tests.

     * 80c24be Fixing an issue  with  the  import_key  method.   Different
       results depending on which gnupg python module is installed.

   * PR    #24965:   (jacksontj)   Fix   memory   leak   in   saltnado   @
     2015-06-25T18:48:03Z

     * ISSUE #24846: (mavenAtHouzz)  Memory  leak  issue  in  rest_tornado
       EventListener | refs: #24965

     * 8622184 Merge pull request #24965 from jacksontj/2015.5

     * 48b5e16 pylint

     * 87adca4 Fix memory leak in saltnado

   * PR  #24948:  (jfindlay)  fix  some  malformed doc links and anchors @
     2015-06-25T15:51:38Z

     * 773c4cf Merge pull request #24948 from jfindlay/doc_links

     * 152a9b2 fix some malformed doc links and anchors

   * PR #24886: (anlutro) Be more careful about  stripping  away  root_dir
     from directory options @ 2015-06-25T15:50:11Z

     * ISSUE #24885: (anlutro) Master config - Directories starting with a
       dot have the dot stripped when root_dir is .  | refs: #24886

     * 4ebc01e Merge pull request #24886 from alprs/fix-root_dir_bug

     * 52ccafd os.sep is the correct directory separator constant

     * 0ecbf26  Be  more  careful  about  stripping  away  root_dir   from
       directory options

   * PR  #24930:  (jacksontj)  Don't  refetch  file  templates 100% of the
     time--   Performance   optimization    for    templated    files    @
     2015-06-24T21:22:47Z

     * f52f7e1 Merge pull request #24930 from jacksontj/2015.5

     * 5fb7534 Only parse the source if we have one

     * c03a6fa Add support for sources of managed files to be local

     * 4cf78a0 pylint

     * d70914e  Don't  refetch the template 100% of the time-- Performance
       optimization for templated files

   * PR #24935: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-06-24T18:17:54Z

     * PR #24918: (BretFisher) SmartOS SMF minion startup fix

     * PR  #473:  (whiteinge)  Added  a  couple functions to work with the
       minion file cache | refs: #24918

     * 925a4d9 Merge pull request #24935 from basepi/merge-forward-2015.5

     * 8d8bf34  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * eeb05a1       Merge       pull       request       #24918      from
       BretFisher/minion-start-smartos-smf-fix

       * d7bfb0c Smartos smf minion fix

   * PR #24873: (jfindlay) convert osrelease grain to str before str op  @
     2015-06-24T16:43:08Z

     * ISSUE   #24826:   (rakai93)  rh_service.py:  'int'  object  has  no
       attribute 'startswith' | refs: #24873

     * 4e8ed0d Merge pull request #24873 from jfindlay/rh_service

     * febe6ef convert osrelease grain to str before str op

   * PR  #24923:  (jayeshka)  adding  states/status  unit  test  case.   @
     2015-06-24T15:50:07Z

     * 90819f9       Merge       pull       request       #24923      from
       jayeshka/status-states-unit-test

     * baec650 adding states/status unit test case.

   * PR   #24902:   (cro)   Fix   minion   failover,   document   same   @
     2015-06-24T15:20:43Z

     * 2dd24ec Merge pull request #24902 from cro/fixfo2

     * 90c73ff References to documentation.

     * f0c9204 Add references to failover parameters in conf

     * 9da96a8 Docs

     * e2314f0 Move comment.

     * b9a756f Fix master failover and add documentation for same.  Factor
       in syndics.  Syndics will not failover (yet).

   * PR   #24926:   (rallytime)   Back-port    #22263    to    2015.5    @
     2015-06-24T15:09:40Z

     * PR  #22263:  (cachedout)  Prevent  a load from being written if one
       already exists | refs: #24926

     * 087ee09 Merge pull request #24926 from rallytime/bp-22263

     * 8c92d9c Prevent a load from being written if one already exists

   * PR   #24900:   (rallytime)   Back-port    #24848    to    2015.5    @
     2015-06-24T15:09:18Z

     * PR #24848: (nmadhok) Correcting bash code blocks | refs: #24900

     * b34a74f Merge pull request #24900 from rallytime/bp-24848

     * d2b5456 Correcting bash code blocks

   * PR    #24899:    (rallytime)    Back-port    #24847   to   2015.5   @
     2015-06-24T15:09:01Z

     * PR #24847: (borutmrak) unset size  parameter  for  lxc.create  when
       backing=zfs | refs: #24899

     * a546e8e Merge pull request #24899 from rallytime/bp-24847

     * 1e4ec7a unset size parameter for lxc.create when backing=zfs

   * PR    #24898:    (rallytime)    Back-port    #24845   to   2015.5   @
     2015-06-24T15:06:09Z

     * PR #24845: (porterjamesj) fix bug in docker.loaded | refs: #24898

     * d4dd8d2 Merge pull request #24898 from rallytime/bp-24845

     * 071049a fix bug in docker.loaded

   * PR   #24897:   (rallytime)   Back-port    #24839    to    2015.5    @
     2015-06-24T15:05:35Z

     * ISSUE  #24799:  (infestdead) Forced remount because options changed
       when no options changed (glusterfs)

     * PR #24839: (infestdead) fix for issue #24799 | refs: #24897

     * 6930855 Merge pull request #24897 from rallytime/bp-24839

     * f3b20d5 fix for issue #24799

   * PR #24891: (jayeshka) adding states/ssh_known_hosts unit  test  case.
     @ 2015-06-23T16:46:58Z

     * 1650233       Merge       pull       request       #24891      from
       jayeshka/ssh_known_hosts-states-unit-test

     * ef1347f adding states/ssh_known_hosts unit test case.

   * PR #24874: (dkiser) Fix for salt-cloud when ssh key used to auth  and
     using sudo.  @ 2015-06-22T23:46:08Z

     * ISSUE  #24870:  (dkiser)  salt-cloud  fails on sudo password prompt
       when using ssh key to auth | refs: #24874

     * c32aae9 Merge pull request #24874 from dkiser/salt-cloud-24870

     * 6c31143 Fix key error for the PR to fix #24870.

     * bdcf7d8 Fix pylint for #24874.

     * 8f66d19 Fix for salt-cloud when ssh key  used  to  auth  and  using
       sudo.

   * PR  #24880:  (dkiser)  Fix to allow password for salt-cloud to be set
     outside of a vm specif... @ 2015-06-22T23:44:59Z

     * ISSUE #24871: (dkiser) salt-cloud  fails  to  honor  'password'  in
       cloud options before raising an exception | refs: #24880

     * ddaa21c Merge pull request #24880 from dkiser/salt-cloud-24871

     * 4f6c035 Fix to allow password for salt-cloud to be set outside of a
       vm specific context.

   * PR #24852: (pruiz) Fix issue 24851:  regular  expression  so  it  now
     matches packages with '.' or '-' at pkg name @ 2015-06-22T20:37:13Z

     * 3902b16 Merge pull request #24852 from pruiz/issue-24851

     * 73adb1d  Fix regular expression so it now matches packages with '.'
       or '-' at pkg name.

   * PR #24861: (jayeshka)  adding  states/ssh_auth  unit  test  case.   @
     2015-06-22T16:20:01Z

     * 6c5b788       Merge       pull       request       #24861      from
       jayeshka/ssh_auth-states-unit-test

     * e5d7b0d adding states/ssh_auth unit test case.

   * PR #24824: (kev009) Detect bhyve virtual type for  FreeBSD  guests  @
     2015-06-22T15:24:35Z

     * ISSUE  #23478:  (calvinhp) grains.get virtual reports "physical" on
       bhyve FreeBSD VM | refs: #24824

     * 9e3321c Merge pull request #24824 from kev009/grains-bhyve-bsd

     * a226209 Detect bhyve virtual type for freebsd guests

   * PR   #24795:   (anlutro)   Fix    state.apply    for    salt-ssh    @
     2015-06-22T15:23:57Z

     * ISSUE  #24746:  (anlutro)  state.apply doesn't seem to work | refs:
       #24795

     * 7b07ef9      Merge       pull       request       #24795       from
       alprs/fix-salt_ssh_state_apply

     * 905840b Fix state.apply for salt-ssh

   * PR  #24832:  (jacksontj) Don't incur a "_load_all" of the lazy_loader
     while looking for mod_init.  @ 2015-06-22T15:17:10Z

     * PR #20540: (jacksontj)  Loader  nomerge:  Don't  allow  modules  to
       "merge" | refs: #24832

     * PR  #20481: (jacksontj) Add submodule support to LazyLoader | refs:
       #20540

     * PR #20473: (jacksontj) Add "disabled" support | refs: #20481

     * PR #20274: (jacksontj) Loader overhaul to LazyLoader | refs: #20473

     * PR #12327: (jacksontj) Add a LazyLoader  class  which  will  lazily
       load modules (with the given lo...  | refs: #20274

     * 31d4c13 Merge pull request #24832 from jacksontj/2015.5

     * cfa7c0a pylint

     * be18439  Don't incur a "_load_all" of the lazy_loader while looking
       for mod_init.

   * PR   #24834:   (rallytime)   Back-port    #24811    to    2015.5    @
     2015-06-19T18:43:49Z

     * ISSUE #14666: (luciddr34m3r) salt-cloud GoGrid exception when using
       map file | refs: #24811

     * PR #24811: (rallytime) Add notes to map and gogrid  docs  --  don't
       use -P with map files | refs: #24834

     * 2d8148f Merge pull request #24834 from rallytime/bp-24811

     * e2684ec  Add  notes to map and gogrid docs -- don't use -P with map
       files

   * PR   #24790:   (rallytime)   Back-port    #24741    to    2015.5    @
     2015-06-19T17:25:58Z

     * PR  #24741: (CameronNemo) Improve Upstart enable/disable handling |
       refs: #24790

     * d2edb63 Merge pull request #24790 from rallytime/bp-24741

     * a54245f Add missing import

     * 4ce6370 salt.modules.upstart: fix lint errors

     * aec53ec Improve Upstart enable/disable handling

   * PR   #24789:   (rallytime)   Back-port    #24717    to    2015.5    @
     2015-06-19T17:17:00Z

     * PR  #24717: (gthb) virtualenv.managed: document user and no_chown |
       refs: #24789

     * 645e62a Merge pull request #24789 from rallytime/bp-24717

     * 95ac4eb virtualenv.managed: document user and no_chown

   * PR #24823: (jayeshka) adding states/splunk_search unit test case.   @
     2015-06-19T17:14:12Z

     * 0a6c70f       Merge       pull       request       #24823      from
       jayeshka/splunk_search-states-unit-test

     * 98831a8 adding states/splunk_search unit test case.

   * PR #24809: (jodv) Correctly create  single  item  list  for  failover
     master type with string value for master opt @ 2015-06-19T15:22:20Z

     * 4c5a708 Merge pull request #24809 from jodv/single_item_master_list

     * 18ceebc single item list vs. list of characters

   * PR  #24802:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-06-18T20:11:58Z

     * ISSUE #24776: (nmadhok) --static option in salt  raises  ValueError
       and has been broken for a very long time | refs: #24777

     * ISSUE  #21318:  (thanatos) get_full_returns raises KeyError | refs:
       #24769

     * ISSUE #18994: (njhartwell) salt.client.get_cli_returns errors  when
       called immediately after run_job | refs: #24769

     * ISSUE  #17041:  (xenophonf)  Confusing  Salt  error messages due to
       limited/incomplete PowerShell command error handling | refs: #24690

     * ISSUE #19: (thatch45)  Sending  a  faulty  command  kills  all  the
       minions!

     * PR #24780: (nmadhok) Backporting PR #24777 to 2014.7 branch

     * PR  #24779:  (nmadhok) Backporting Changes to 2014.7 branch | refs:
       #24777

     * PR #24778: (nmadhok) Backporting PR #24777 to 2015.2 branch | refs:
       #24777

     * PR  #24777: (nmadhok) Fixing issue where --static option fails with
       ValueError Fixes #24776 | refs: #24778 #24780

     * PR #24769: (msteed) Fix stacktrace in get_cli_returns()

     * PR #24690: (twangboy) Report powershell output instead of error

     * ae05e70 Merge pull request #24802 from basepi/merge-forward-2015.5

     * 5b7a65d Merge pull request #19 from twangboy/merge-forward-fixes

       * 98e7e90 Fixed test failures for Colton

     * b949856  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

       * 4281dff       Merge       pull      request      #24780      from
         nmadhok/backport-2014.7-24777

         * c53b0d9 Backporting PR #24777 to 2014.7 branch

       * f3c5cb2 Merge pull request #24769 from msteed/issue-21318

         * f40a9d5 Fix stacktrace in get_cli_returns()

       * 59db246 Merge pull request #24690 from twangboy/fix_17041

         * 7a01538 Added additional reporting

         * d84ad5d Fixed capitalization... Failed and Already

         * e955245        Merge         branch         '2014.7'         of
           https://github.com/saltstack/salt into fix_17041

         * 144bff2 Report powershell output instead of error

   * PR  #24798: (jtand) Revert "adding states/postgres_database unit test
     case."  @ 2015-06-18T17:56:17Z

     * PR #24329: (jayeshka)  adding  states/postgres_database  unit  test
       case.  | refs: #24798

     * daa76c3       Merge       pull       request       #24798      from
       saltstack/revert-24329-postgres_database-states-unit-test

     * 179ce03 Revert "adding states/postgres_database unit test case."

   * PR   #24791:   (rallytime)   Back-port    #24749    to    2015.5    @
     2015-06-18T17:43:15Z

     * PR   #24749:   (obestwalter)   add  windows  specific  default  for
       multiprocessing | refs: #24791

     * 7073a9f Merge pull request #24791 from rallytime/bp-24749

     * be43b2b add windows specific default for multiprocessing

   * PR   #24792:   (rallytime)   Back-port    #24757    to    2015.5    @
     2015-06-18T15:58:35Z

     * PR #24757: (cachedout) Fix loader call in pyobjects | refs: #24792

     * PR  #24668:  (grischa)  enable  virtual  package names in pyobjects
       renderer | refs: #24721 #24757

     * 1a158e8 Merge pull request #24792 from rallytime/bp-24757

     * 6c804f0 Fix loader call in pyobjects

   * PR #24768: (jfindlay) fix yum versionlock on RHEL/CentOS  5,  disable
     corresponding test @ 2015-06-18T15:13:12Z

     * 0f92982 Merge pull request #24768 from jfindlay/pkg_mod

     * 7a26c2b disable pkg.hold test for RHEL/CentOS 5

     * 4cacd93 use correct yum versionlock pkg name on centos 5

   * PR  #24778:  (nmadhok) Backporting PR #24777 to 2015.2 branch | refs:
     #24777 @ 2015-06-18T14:53:04Z

     * ISSUE #24776: (nmadhok) --static option in salt  raises  ValueError
       and has been broken for a very long time | refs: #24777

     * PR  #24779:  (nmadhok) Backporting Changes to 2014.7 branch | refs:
       #24777

     * PR #24777: (nmadhok) Fixing issue where --static option fails  with
       ValueError Fixes #24776 | refs: #24778 #24780

     * 39f088a       Merge       pull       request       #24778      from
       nmadhok/backport-2015.2-24777

     * ae3701f Backporting PR #24777 to 2015.2 branch

   * PR  #24774:   (zefrog)   Fix   lxc   lvname   parameter   command   @
     2015-06-18T14:49:06Z

     * 2a4f65f Merge pull request #24774 from zefrog/fix-lxc-lvname-param

     * 21e0cd4 Fixed typo in lxc module: lvname parameter typo

     * 283d86e  Fixed  bug  in lxc module: lvname using wrong parameter in
       cmd

   * PR  #24782:  (jayeshka)  adding  states/slack  unit  test  case.    @
     2015-06-18T14:33:55Z

     * fd73390       Merge       pull       request       #24782      from
       jayeshka/slack-states-unit-test

     * e2b6214 adding states/slack unit test case.

   * PR #24771: (jacksontj) Always extend requisites, instead of replacing
     them @ 2015-06-18T14:29:09Z

     * ISSUE  #24770:  (jacksontj)  Requisite  and Requisite_in don't play
       nice together | refs: #24771

     * c9c90af Merge pull request #24771 from jacksontj/2015.5

     * b1211c5 Re-enable tests for complex prereq and prereq_in

     * 378f6bf Only merge when the merge is of requisites

   * PR #24766: (msteed) Remove doc references to obsolete  minion  opt  @
     2015-06-17T21:36:55Z

     * 5fe4de8 Merge pull request #24766 from msteed/undoc-dns_check

     * f92a769 Remove doc references to obsolete minion opt

   * PR #24329: (jayeshka) adding states/postgres_database unit test case.
     | refs: #24798 @ 2015-06-17T19:11:02Z

     * a407ab7      Merge       pull       request       #24329       from
       jayeshka/postgres_database-states-unit-test

     * ee06f1a adding states/postgres_database unit test case.

   * PR #24632: (jacobhammons) Doc bug fixes @ 2015-06-17T18:40:02Z

     * ISSUE  #24560:  (hydrosine)  Documentation  missing  on parameter |
       refs: #24632

     * ISSUE #24547: (dragonpaw) Artifactory docs say module is  'jboss7'.
       | refs: #24632

     * ISSUE  #24375:  (companykitchen-dev)  Custom grain won't sync under
       any circumstances | refs: #24632

     * ISSUE  #24275:  (kartiksubbarao)  augeas  issue  with  apache   and
       recognizing changes that have been already made | refs: #24632

     * ISSUE  #24163: (tbaker57) enable_gpu_grains default value confusion
       | refs: #24632

     * 3ff6eff Merge pull request #24632 from jacobhammons/bug-fixes

     * 7c52012 Fixed typos

     * c7cdd41 Doc bug fixes Refs #24547  Refs  #24275  Refs  #24375  Refs
       #24560 Refs #24163

   * PR     #24607:     (garethgreenaway)    fixes    to    minion.py    @
     2015-06-17T18:16:42Z

     * ISSUE #24198: (ahammond) salt-call event.send doesn't  send  events
       from minion | refs: #24607

     * 9995f64       Merge       pull       request       #24607      from
       garethgreenaway/2015_5_sending_events_multi_master

     * 8abd3f0 A fix if you have multiple masters configured  and  try  to
       fire events to the minion.  Currently they fail silently.  Might be
       the cause of #24198.

   * PR  #24755:  (rallytime)  Remove  SALT_CLOUD_REQS  from  setup.py   @
     2015-06-17T17:42:25Z

     * bf2dd94 Merge pull request #24755 from rallytime/fix_setup_15

     * 48769a5 Remove SALT_CLOUD_REQS from setup.py

   * PR    #24740:    (rallytime)    Backport    #24720    to   2015.5   @
     2015-06-17T16:43:37Z

     * PR #24720: (TheScriptSage) Issue 24621 - AD/LDAP Group Auth Issue |
       refs: #24740

     * 3d53d79 Merge pull request #24740 from rallytime/bp-24720

     * a9bcdb5  Updating  master.py  to properly check against groups when
       user is only authed against group.  Tested against unit.auth_test.

   * PR   #24723:   (rallytime)   Back-port    #20124    to    2015.5    @
     2015-06-17T16:43:20Z

     * PR #20124: (cgtx) add init system to default grains | refs: #24723

     * ac2851b Merge pull request #24723 from rallytime/bp-20124

     * 4d0061b fix infinite loop introduced by #20124 when the init system
       is not in the supported_inits list

     * 0c7fa0f Optimizations for #20124

     * f353454 add init system to default grains (resolve #20124)

   * PR #24754: (anlutro) salt-cloud documentation - Add information about
     linode location @ 2015-06-17T16:04:48Z

     * 78cd09b       Merge       pull       request       #24754      from
       alprs/docs-add_linode_location_option

     * d88e071 add information about linode location

   * PR #24748: (jayeshka) adding  states/serverdensity_device  unit  test
     case.  @ 2015-06-17T15:39:07Z

     * d5554f7       Merge       pull       request       #24748      from
       jayeshka/serverdensity_device-states-unit-test

     * 1a4c241 adding states/serverdensity_device unit test case.

   * PR   #24739:   (rallytime)   Back-port    #24735    to    2015.5    @
     2015-06-17T15:16:47Z

     * PR #24735: (notpeter) Add 2015.5 codename to version numbers docs |
       refs: #24739

     * 0b7e7ef Merge pull request #24739 from rallytime/bp-24735

     * 64c565d Add .0 to version number

     * 5ed801b Add codenames for  2015.5  and  future  versions.  Trailing
       newline.

   * PR   #24732:  (msteed)  Fix  stacktrace  when  --summary  is  used  @
     2015-06-17T03:27:57Z

     * ISSUE #24111: (yermulnik) cli option '--summary' got  broken  after
       upgrade to 2015.5.1 | refs: #24732

     * c8713f2 Merge pull request #24732 from msteed/issue-24111

     * 54b33dd Fix stacktrace when --summary is used

   * PR    #24721:    (rallytime)    Back-port    #24668   to   2015.5   @
     2015-06-17T03:23:47Z

     * PR #24668: (grischa) enable  virtual  package  names  in  pyobjects
       renderer | refs: #24721 #24757

     * 70d3781 Merge pull request #24721 from rallytime/bp-24668

     * 68fb5af fixing other test

     * ba4f262 fixing text for virtual support in pyobjects

     * b349d91 enable virtual package names in pyobjects renderer

   * PR #24718: (rallytime) Added some missing config documentation to the
     vsphere driver @ 2015-06-17T03:19:35Z

     * ISSUE #21923: (Fluro) Salt cloud not running   provisioning  script
       as root | refs: #24718

     * ISSUE  #17241:  (hasues)  Salt-Cloud  for  vSphere needs additional
       documentation | refs: #24718

     * 1b9d689      Merge       pull       request       #24718       from
       rallytime/update_vsphere_docs

     * bfdebb6  Added  some  missing  config  documentation to the vsphere
       driver

   * PR    #24714:    (rallytime)    Remove    cloud-requirements.txt    @
     2015-06-17T03:17:04Z

     * 64857c7       Merge       pull       request       #24714      from
       rallytime/remove_cloud_reqs_15

     * 67b796d Remove cloud-requirements.txt

   * PR  #24733:  (msteed)  Include   Tornado   in   versions   report   @
     2015-06-17T03:13:53Z

     * ISSUE  #24439: (bechtoldt) Add tornado version to versions report |
       refs: #24733

     * f96b1d6 Merge pull request #24733 from msteed/issue-24439

     * 76cfef0 Include Tornado in versions report

   * PR  #24737:  (jacksontj)  Move  AES  command  logging  to   trace   @
     2015-06-17T01:48:11Z

     * a861fe0 Merge pull request #24737 from jacksontj/2015.5

     * a4ed41a Move AES command logging to trace

   * PR  #24724:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-06-16T22:46:27Z

     * ISSUE #24196: (johnccfm) Exception  when  using  user.present  with
       Windows | refs: #24646

     * PR #24646: (twangboy) Fixed user.present on existing user

     * 0d2dc46 Merge pull request #24724 from basepi/merge-forward-2015.5

     * 4641028   Merge   remote-tracking   branch  'upstream/2014.7'  into
       merge-forward-2015.5

     * a18dada Merge pull request #24646 from twangboy/fix_24196

       * a208e1d Fixed user.present on existing user

   * PR #24701:  (jayeshka)  adding  states/selinux  unit  test  case.   @
     2015-06-16T15:27:29Z

     * 3d33fe7       Merge       pull       request       #24701      from
       jayeshka/selinux-states-unit-test

     * 0c136fd adding states/selinux unit test case.

   * PR  #24687:  (cachedout)  Note   about   minimum   worker_threads   @
     2015-06-15T20:46:23Z

     * 2e287a9 Merge pull request #24687 from cachedout/min_worker_threads

     * b7bb7ea Note about minimum worker_threads

   * PR #24688: (cachedout) Update AUTHORS @ 2015-06-15T20:46:03Z

     * 432478c Merge pull request #24688 from cachedout/update_authors

     * 3f6880e Better email

     * 6c7b773 Update AUTHORS

   * PR  #24649:  (cachedout) Improved error reporting for failed states @
     2015-06-15T16:04:20Z

     * ISSUE #22385: (cachedout) States which require unavailable  modules
       should display the reason | refs: #24649

     * 9a2b50d Merge pull request #24649 from cachedout/issue_22385

     * b9fe792  States  will  now  return  the  reason behind failure if a
       module could not be loaded

   * PR #24673: (jayeshka)  adding  states/schedule  unit  test  case.   @
     2015-06-15T15:24:52Z

     * 66e9e16       Merge       pull       request       #24673      from
       jayeshka/schedule-states-unit-test

     * 54aaaa5 adding states/schedule unit test case.

   * PR    #24663:     (kartiksubbarao)     Update     augeas_cfg.py     @
     2015-06-15T15:18:48Z

     * ISSUE   #24661:   (kartiksubbarao)  augeas.change  doesn't  support
       setting empty values | refs: #24663

     * 5eb19c4 Merge pull request #24663 from kartiksubbarao/patch-2

     * e18db50 Update augeas_cfg.py

   * PR #24667: (dkiser) fix for #24583 clouds/openstack.py kerying  first
     time succeeds @ 2015-06-14T21:58:58Z

     * ISSUE  #24583:  (dkiser)  salt-cloud  keyring  password  referenced
       before assignment | refs: #24667

     * 4450432 Merge pull request #24667 from dkiser/fix-cloud-keyring

     * c92c05f fix  for  #24583  clouds/openstack.py  kerying  first  time
       succeeds

   * PR #24659: (kartiksubbarao) Update aliases.py @ 2015-06-13T17:31:42Z

     * ISSUE  #24537:  (kartiksubbarao) alias.present doesn't update alias
       values that are substrings of the existing value | refs: #24659

     * 4c64ee9 Merge pull request #24659 from kartiksubbarao/patch-1

     * d683474 Update aliases.py

   * PR #24644: (cro) Merge forward 2014.7->2015.5 @ 2015-06-12T21:31:41Z

     * PR #24643: (cro) Add reference to salt-announce mailing list

     * PR #24620: (twangboy) Fixed  comment  and  uncomment  functions  in
       file.py

     * 89eb616 Merge pull request #24644 from cro/2014.7-2015.5-20150612

     * 4136dc3 Merge forward from 2014.7 to 2015.5

     * b99484f Merge pull request #24643 from cro/saltannounce

       * ecb0623 Add salt-announce mailing list.

     * 635121e Merge pull request #24620 from twangboy/fix_24215

       * d7a9999 Fixed comment and uncomment functions in file.py

   * PR   #24642:  (basepi)  Revert  "fix  target  rule,  remove  unneeded
     quotation mark" @ 2015-06-12T20:14:26Z

     * PR #24595: (tankywoo) fix target rule,  remove  unneeded  quotation
       mark | refs: #24642

     * b896a0d       Merge       pull       request       #24642      from
       saltstack/revert-24595-fix-iptables-target

     * 5ff3224 Revert "fix target rule, remove unneeded quotation mark"

   * PR  #24628:  (jayeshka)  adding  states/reg  unit   test   case.    @
     2015-06-12T17:29:11Z

     * 01092c2       Merge       pull       request       #24628      from
       jayeshka/reg_states-unit-test

     * af1bd8f adding states/reg unit test case.

   * PR   #24631:   (rallytime)   Back-port    #24591    to    2015.5    @
     2015-06-12T16:54:32Z

     * ISSUE  #24494:  (arnoutpierre)  Computed comments in jinja states |
       refs: #24591

     * ISSUE #24073: (primechuck) State.highstate uses stale  grain  data.
       | refs: #24492

     * ISSUE #23359: (BalintSzigeti) init.sls parsing issue | refs: #24591

     * ISSUE  #21217:  (Colstuwjx)  Maybe a bug for jinja render?  | refs:
       #24591

     * PR #24591: (tbaker57) Add some documentation surrounding  Jinja  vs
       yaml comments - | refs: #24631

     * PR #24492: (DmitryKuzmenko) Don't remove grains from opts

     * 5f491f9 Merge pull request #24631 from rallytime/bp-24591

     * f13cd41 Add extra clarification why jinja comments are needed.

     * 2374971 Fix typo

     * 6a91747  Add  some  documentation surrounding Jinja comments - refs
       #24492, #21217, #23359

   * PR #24616: (garethgreenaway) additional logging in state.py module  @
     2015-06-12T16:25:39Z

     * f23f99e       Merge       pull       request       #24616      from
       garethgreenaway/2015_5_logging_disabled_states

     * 4dbf0ef Adding some logging statement to give feedback when states,
       including  highstate,  are  disabled.   Useful  when  running  from
       scheduler.

   * PR #24595: (tankywoo) fix target rule, remove unneeded quotation mark
     | refs: #24642 @ 2015-06-12T16:23:22Z

     * 6dccbb0 Merge pull request #24595 from tankywoo/fix-iptables-target

     * 10a5160 fix target rule, remove unneeded quotation mark

   * PR   #24604:   (jfindlay)   fix   pkg   module  integration  tests  @
     2015-06-12T16:04:26Z

     * 8ac3d94 Merge pull request #24604 from jfindlay/pkg_tests

     * d88fb22 fix pkg module integration tests on CentOS 5

     * fb91b40 fix pkg module integration tests on ubuntu 12

   * PR #24600: (basepi) [2015.5] Remove __kwarg__ from  salt-ssh  keyword
     args @ 2015-06-12T04:21:29Z

     * 0ff545c       Merge       pull       request       #24600      from
       basepi/salt-ssh.orchestrate.20615

     * 9b55683 Remove __kwarg__ from salt-ssh keyword args

   * PR #24608: (basepi) [2015.5] Normalize salt-ssh  flat  roster  minion
     IDs to strings @ 2015-06-11T21:35:07Z

     * ISSUE  #22843:  (Xiol)  salt-ssh roster doesn't support integers as
       host keys | refs: #24608

     * 832916f      Merge       pull       request       #24608       from
       basepi/salt-ssh.flat.roster.integers.22843

     * 381820f Normalize salt-ssh flat roster minion IDs to strings

   * PR  #24605:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-06-11T19:15:21Z

     * PR #24589: (BretFisher) Fixed Mine example for jinja code block

     * 4eb5bb2 Merge pull request #24605 from basepi/merge-forward-2015.5

     * f96c502  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * d83928a Merge pull request #24589 from BretFisher/patch-1

       * 65a1133 Fixed Mine example for jinja code block

   * PR    #24598:    (jacobhammons)    2015.5.2    release    changes   @
     2015-06-11T17:24:11Z

     * ISSUE #24457: (ryan-lane) When selecting the version of docs on the
       docs site, it brings you to the homepage | refs: #24598

     * ISSUE  #24250:  (jfindlay)  have version links on docs page link to
       that version of the current page | refs: #24598

     * e0bb177 Merge pull request #24598 from jacobhammons/doc-fixes

     * f3f34dd 2015.5.2 release changes Refs #24250 Refs #24457

   * PR  #24588:  (basepi)  Fixes  for  saltmod.function  for  salt-ssh  @
     2015-06-11T16:15:21Z

     * ISSUE   #20615:   (aurynn)   2014.7.1:   salt/states/saltmod  using
       incorrect return dict for orchestrate | refs: #24588

     * 26930b4      Merge       pull       request       #24588       from
       basepi/salt-ssh.orchestrate.20615

     * 826936c Move documentation into docstring instead of comments

     * de052e7 Assign 'return' to 'ret' if necessary in saltmod.function

     * 34ff989 Convert keyword args to key=value strings in salt-ssh

   * PR  #24593:  (jayeshka)  adding  states/redismod  unit  test case.  @
     2015-06-11T15:55:27Z

     * 5a21ad1      Merge       pull       request       #24593       from
       jayeshka/redismod_states-unit-test

     * 3b95744 adding states/redismod unit test case.

   * PR  #24581: (rallytime) Disabled some flaky tests until we can figure
     out how to make them more reliable @ 2015-06-11T15:51:41Z

     * ISSUE #40: (thatch45) Clean up timeouts | refs: #22857

     * PR #24217: (jfindlay) disable intermittently failing tests |  refs:
       #24581

     * PR #23623: (jfindlay) Fix /jobs endpoint's return | refs: #24217

     * PR #22857: (jacksontj) Fix /jobs endpoint's return | refs: #23623

     * 8ffb86e       Merge       pull       request       #24581      from
       rallytime/disable_some_flaky_tests

     * c82f135 Disabled some flaky tests until we can figure  out  how  to
       make them more reliable

   * PR   #24566:   (jayeshka)   adding  states/rdp  unit  test  case.   @
     2015-06-11T02:14:39Z

     * a570d7f      Merge       pull       request       #24566       from
       jayeshka/rdp_states-unit-test

     * 273b994 adding states/rdp unit test case.

   * PR   #24551:   (joejulian)   2015.5   don't   pollute  environment  @
     2015-06-11T02:13:06Z

     * ISSUE #24480: (kiorky) [CRITICAL]  [2015.5]  tls  breaks  tzinfo  |
       refs: #24551

     * 20ada1f       Merge       pull       request       #24551      from
       joejulian/2015.5_dont_pollute_environment

     * cfc3b43 Don't pollute the TZ environment variable

     * cba8d3f pep8

     * 9cb7015 Mark keyword version adds

     * 76e2583 Merge tls changes from develop

   * PR #24574: (jacobhammons) Refs #19901 @ 2015-06-10T20:09:23Z

     * ISSUE #19901: (clinta) State cache is not documented | refs: #24468

     * bb2fd6a Merge pull request #24574 from jacobhammons/19901

     * e2a2946 Refs #19901

   * PR #24577: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-06-10T19:46:22Z

     * ISSUE  #24427:  (fayetted) 2015.5.1-3 Windows 64Bit Minion fails to
       start after install | refs: #24530

     * PR #24530: (twangboy) Start Minion Service on Silent Install

     * b03166c Merge pull request #24577 from basepi/merge-forward-2015.5

     * e1d45cc  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * d376390 Merge pull request #24530 from twangboy/fix_24427

       * 673e1d8 Added missing panel.bmp for installer

       * cc50218 Start Minion Service on Silent Install

   * PR #24571: (jacobhammons) Refs #24235 @ 2015-06-10T17:02:18Z

     * ISSUE  #24235: (tomasfejfar) Difference between running from minion
       and from master | refs: #24468

     * 3ec457b Merge pull request #24571 from jacobhammons/24235

     * 8df5d53 Refs #24235

   * PR  #24565:  (pille)  fix   backtrace,   when   listing   plugins   @
     2015-06-10T16:33:11Z

     * fe07eb5       Merge       pull       request       #24565      from
       pille/munin-ignore-broken-symlinks

     * 8511a6c fix backtrace, when listing plugins

   * PR  #24554:  (ryan-lane)  Fix  yes  usage   for   pecl   defaults   @
     2015-06-09T23:59:49Z

     * 251c8f9 Merge pull request #24554 from lyft/pecl-module-fix

     * 56a9cfc Fix yes usage for pecl defaults

   * PR    #24535:    (rallytime)    Back-port    #24518   to   2015.5   @
     2015-06-09T20:06:18Z

     * PR #24518: (rallytime) Merge  #24448  with  Pylint  Fixes  |  refs:
       #24535

     * PR  #24448:  (codertux)  Update  modules path for operating systems
       using systemd | refs: #24518

     * dbd49b4 Merge pull request #24535 from rallytime/bp-24518

     * fc75197 Pylint fix

     * 3e08840 Update modules path for operating systems using systemd

   * PR #24538: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-06-09T17:27:20Z

     * PR #24513: (jquast) bugfix use of 'iteritem' in 2014.7 branch

     * PR #24511: (jquast) bugfix: trailing "...done" in rabbitmq output |
       refs: #24513

     * 485ed3c Merge pull request #24538 from basepi/merge-forward-2015.5

     * 6a8039d  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

     * 6ebc476       Merge       pull       request       #24513      from
       jquast/2014.7-bugfix-iteritem

       * 2be0180 bugfix use of 'iteritem' in 2014.7 branch

   * PR #24495: (jayeshka) adding states/rabbitmq_vhost unit test case.  @
     2015-06-09T15:33:23Z

     * 73e6388       Merge       pull       request       #24495      from
       jayeshka/rabbitmq_vhost_states-unit-test

     * 31889e3 cosmetic change.

     * cf501cf resolved error.

     * 4bb6087 Merge branch '2015.5' of  https://github.com/saltstack/salt
       into rabbitmq_vhost_states-unit-test

     * 3ad7714 adding states/rabbitmq_vhost unit test case.

   * PR  #24445:  (jayeshka) adding states/pyrax_queues unit test case.  @
     2015-06-09T15:28:45Z

     * bf1abcc      Merge       pull       request       #24445       from
       jayeshka/pyrax_queues_states-unit-test

     * ea27cef adding states/pyrax_queues unit test case.

   * PR  #24490: (aneeshusa) Fix pacman.list_upgrades for new python_shell
     default.  @ 2015-06-09T15:13:16Z

     * 0247e8d      Merge       pull       request       #24490       from
       aneeshusa/fix-pacman-list-upgrades

     * 980e1cb Lint fix.

     * dca33f1 Fix pacman.list_upgrades for new python_shell default.

   * PR   #24517:   (steverweber)   small   fixes   to  the  ipmi  docs  @
     2015-06-09T15:10:14Z

     * 6268ddb Merge pull request #24517 from steverweber/ipmi_doc

     * 6413712 lint

     * e78aea9 more small fixes to the ipmi docs

   * PR   #24524:   (jayeshka)   any()   takes   list   oy    tuple.     @
     2015-06-09T13:49:42Z

     * 3728b3f       Merge       pull       request       #24524      from
       jayeshka/rabbitmq_vhost_states-module

     * 01c99ad any() takes list oy tuple.

   * PR #24482: (eliasp) 'docker.running' needs now the 'image' param.   @
     2015-06-09T04:43:04Z

     * dd23de8       Merge       pull       request       #24482      from
       eliasp/2015.5-states.dockerio-docker.running-doc

     * 5de741d 'docker.running' needs now the 'image' param.

   * PR #24515: (basepi) [2015.5] Add  xml  library  to  the  salt-thin  @
     2015-06-09T04:10:06Z

     * ISSUE #23503: (jfindlay) salt-ssh fails on CentOS 7 when python-zmq
       is not installed | refs: #24515

     * 2a727c3 Merge pull request #24515 from basepi/susexml23503

     * 078b33e Add xml library to the thin

   * PR  #24497:  (jayeshka)  adding  states/rbenv  unit  test  case.    @
     2015-06-09T03:56:10Z

     * fce998a       Merge       pull       request       #24497      from
       jayeshka/rbenv_states-unit-test

     * 79d343a adding states/rbenv unit test case.

   * PR #24496: (jayeshka) adding states/rabbitmq_user unit test case.   @
     2015-06-09T03:55:23Z

     * 2bcb4b1       Merge       pull       request       #24496      from
       jayeshka/rabbitmq_user_states-unit-test

     * 7d96f27 adding states/rabbitmq_user unit test case.

   * PR   #24481:   (eliasp)   Fix   typo   (licnese      license).     @
     2015-06-09T03:30:25Z

     * 02a597b       Merge       pull       request       #24481      from
       eliasp/2015.5-salt.states.powerpath-license_typo

     * 1280054 Fix typo (licnese  license).

   * PR   #24467:   (thenewwazoo)   Fix   dockerio   bound    volumes    @
     2015-06-09T01:40:23Z

     * 5ad3db5       Merge       pull       request       #24467      from
       thenewwazoo/fix-dockerio-bound-volumes

     * db4e3dc Let's raise an exception if create fails

     * d1d85dd Add logging

     * ddc63f0 Fix volume handling when creating containers

   * PR  #24504:  (rallytime)  Move  vsphere  deprecation  to   2015.5   @
     2015-06-08T22:43:05Z

     * PR  #24487:  (nmadhok) Deprecating vsphere cloud driver in favor of
       vmware cloud driver | refs: #24504

     * d236fbd      Merge       pull       request       #24504       from
       rallytime/move_vsphere_deprecation_2015.5

     * d876535 Add Getting Started with VSphere doc to 2015.5

     * b685ebc Add vSphere deprecation warnings to 2015.5

   * PR    #24506:    (rallytime)    Backport    #24450    to   2015.5   @
     2015-06-08T22:42:14Z

     * PR #24450: (ruzarowski) Fix salt cli runs  with  batch-size  set  |
       refs: #24506

     * cb55460 Merge pull request #24506 from rallytime/bp-24450

     * 1c0fca2 Backport #24450 to 2015.5

   * PR #24498: (rallytime) Added "CLI Example" to make failing test happy
     on 2015.5 @ 2015-06-08T15:48:40Z

     * 3173fd1      Merge       pull       request       #24498       from
       rallytime/fix_doc_failure_fifteen

     * d992ef4 Added "CLI Example" to make failing test happy on 2015.5

   * PR    #24471:    (anlutro)   Set   up   salt-ssh   file   logging   @
     2015-06-08T15:26:49Z

     * 3639e41 Merge pull request #24471 from alprs/fix-salt_ssh_logging

     * 6a11ec8 set up salt-ssh file logging

   * PR #24469: (jfindlay) correctly handle user environment info for  npm
     @ 2015-06-08T15:26:02Z

     * ISSUE #24231: (tarwich) npm.bootstrap | refs: #24469

     * 551e70f Merge pull request #24469 from jfindlay/npm_env

     * 8140c96 update npm's user info envs

     * cb572f8 add env parameter to npm.uninstall

   * PR   #24468:   (jacobhammons)   Bug   fixes   and   build   errors  @
     2015-06-08T15:25:40Z

     * ISSUE  #24268:  (tkent-xetus)  Ability  to  specify  revision   for
       win_gitrepos undocumented | refs: #24468

     * ISSUE  #24235: (tomasfejfar) Difference between running from minion
       and from master | refs: #24468

     * ISSUE #24193: (abng88) Update ext_pillar docs to mention that  this
       feature is supported masterless as well | refs: #24468

     * ISSUE  #24172:  (zhujinhe) Can lists be passed in the pillar on the
       command line on version 2015.5.0?  | refs: #24468

     * ISSUE #23211: (lloesche) Document  that  salt://|  escapes  special
       characters in filenames | refs: #24468

     * ISSUE #19901: (clinta) State cache is not documented | refs: #24468

     * ISSUE #19801: (ksalman) How are grains static?  | refs: #24468

     * 0d9e0c2 Merge pull request #24468 from jacobhammons/doc-fixes

     * 1035959 Appended .0 to version added

     * d45c4ed  Bug  fixes  and  build errors Refs #23211 Refs #24268 Refs
       #24235 Refs #24193 Refs #24172 Refs #19901 Refs #19801

   * PR #24465: (jfindlay) catch  exception  from  softwarerepositories  @
     2015-06-08T15:25:19Z

     * ISSUE  #24318:  (favadi)  uncaught exception for pkgrepo.absent for
       invalid PPA | refs: #24465

     * be6905a Merge pull request #24465 from jfindlay/unknown_ppa

     * 19c9128 catch exception from softwarerepositories

   * PR   #24464:   (jfindlay)   fix   typo    in    modules/mount.py    @
     2015-06-08T15:25:07Z

     * ISSUE #24296: (objectx) mount.mount calls file.mkdir with incorrect
       named argument | refs: #24464

     * 58d1ea8 Merge pull request #24464 from jfindlay/file_mkdir

     * 6e8cd44 fix typo in modules/mount.py

   * PR #24461: (dkiser) fix for #24434 @ 2015-06-08T15:24:53Z

     * ISSUE #24434: (dkiser) multimaster failover fails due to logic from
       issue #23611

     * 4f332a7       Merge       pull       request       #24461      from
       dkiser/multimaster_minion_fix

     * 1944a74 fix for #24434

   * PR #24479: (ahus1) change "path" to "name" for  "file"  operations  @
     2015-06-07T17:56:11Z

     * 8917416 Merge pull request #24479 from ahus1/patch-1

     * 7d6b60c change "path" to "name" for "file" operations

   * PR    #24475:    (rallytime)    Back-port    #24454   to   2015.5   @
     2015-06-07T01:29:32Z

     * PR #24454: (rhertzog) Strip extraneous newline character  added  in
       last environment variable | refs: #24475

     * 8618d5b Merge pull request #24475 from rallytime/bp-24454

     * a793c19   Avoid   extraneous   newline   character  added  in  last
       environment variable

   * PR   #24474:   (rallytime)   Back-port    #24420    to    2015.5    @
     2015-06-07T01:29:11Z

     * ISSUE  #24407:  (aboe76)  Please  expand salt module random | refs:
       #24420

     * PR #24420: (aboe76) added random integer module to mod_random.py  |
       refs: #24474

     * 61658ff Merge pull request #24474 from rallytime/bp-24420

     * 4219b40 Fix lint error and update versionadded to 2015.5.3

     * 3613cc9 added random integer module to mod_random.py

   * PR  #24472:  (variia)  ensure  {}  output is not treated as change in
     module.py state, fixes #... @ 2015-06-06T14:45:44Z

     * ISSUE #24233: (variia) yumpkg.group_install keeps  returning  state
       change

     * 508d7dd       Merge       pull       request       #24472      from
       variia/Fix-yumpkg_group_install-return-change-#24233

     * 37e8827 ensure {} output is not  treated  as  change  in  module.py
       state, fixes #24233

   * PR  #24466:  (basepi)  [2015.5]  Fix  for  # in inner strings in yaml
     arguments @ 2015-06-06T14:35:56Z

     * ISSUE #18045: (dstokes) Pillar kwargs parse error with  #  |  refs:
       #24466

     * ISSUE  #8585:  (UtahDave)  '#'  in  single quoted option on cli not
       making it into the execution module | refs: #24466

     * 0292e67 Merge pull request #24466 from basepi/fixhashinargs18045

     * 2e0609f Fix for # in inner strings in yaml arguments

   * PR   #24456:   (rallytime)   Back-port    #24441    to    2015.5    @
     2015-06-05T22:32:25Z

     * PR  #24441:  (arthurlogilab)  [doc] Alignement fix on external_auth
       documentation | refs: #24456

     * ced558a Merge pull request #24456 from rallytime/bp-24441

     * 7002855 yaml indentations should be 2 spaces

     * 21b51ab [doc] Alignement fix on external_auth documentation

   * PR #24398: (kiorky) VirtualName  for  states.apt  |  refs:  #24399  @
     2015-06-05T17:40:04Z

     * ISSUE #24397: (kiorky) on debian: states.apt should use virtualname
       as it shadows system apt module | refs: #24398 #24398 #24399 #24399
       #24400

     * PR #24399: (kiorky) Versionvirtual | refs: #24398

     * c0ff411 Merge pull request #24398 from makinacorpus/aptv

     * 785d277 VirtualName for states.apt

   * PR  #24447:  (jayeshka) adding states/rabbitmq_policy unit test case.
     @ 2015-06-05T15:26:11Z

     * 3626340      Merge       pull       request       #24447       from
       jayeshka/rabbitmq_policy_states-unit-test

     * 9b038ab adding states/rabbitmq_policy unit test case.

   * PR  #24446:  (jayeshka) adding states/rabbitmq_plugin unit test case.
     @ 2015-06-05T15:25:33Z

     * 8445a3f      Merge       pull       request       #24446       from
       jayeshka/rabbitmq_plugin_states-unit-test

     * cb0c99a adding states/rabbitmq_plugin unit test case.

   * PR  #24426:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-06-05T03:59:11Z

     * ISSUE #24276: (markuskramerIgitt) Live salt-master  Profiling  with
       SIGUSR2 fails

     * PR #24405: (jacksontj) Fix for #24276

     * PR  #24395:  (hvnsweeting)  handle exceptions when received data is
       not in good shape

     * PR #24305: (twangboy) Added documentation, fixed formatting

     * 9cc3808 Merge pull request #24426 from basepi/merge-forward-2015.5

     * eafa20c  Merge  remote-tracking   branch   'upstream/2014.7'   into
       merge-forward-2015.5

       * 83f853b Merge pull request #24405 from jacksontj/2014.7

         * 2c7afae Fix for #24276

       * cef919c       Merge       pull      request      #24395      from
         hvnsweeting/handle-exception-get-file

         * bb798a0 handle exceptions when received data  is  not  in  good
           shape

       * efba1a9 Merge pull request #24305 from twangboy/win_path_docs

       * 36804253 Fixed pylint error caused by \P... added r

       * bc42a4b triple double quotes to triple single quotes

       * 77cd930 Added documentation, fixed formatting

   * PR  #24429:  (jacobhammons)  Salt cloud doc updates, build errors and
     bug fixes @ 2015-06-05T00:27:38Z

     * ISSUE #24309: (steverweber) missing docs | refs: #24429

     * 5d738b8      Merge       pull       request       #24429       from
       jacobhammons/cloud-doc-updates

     * 1f7a13d  Salt  cloud  doc  updates, build errors and bug fixes Refs
       #24309

   * PR   #24408:   (rallytime)    Backport    #24392    to    2015.5    @
     2015-06-04T20:22:09Z

     * PR   #24392:   (quixoten)  Fix  "No  such  file  or  directory"  in
       grains/core.py | refs: #24408

     * cdffc02 Merge pull request #24408 from rallytime/bp-24392

     * ff7461b Use path found by salt.utils.which

   * PR   #24380:   (rallytime)    Backport    #24357    to    2015.5    @
     2015-06-04T20:13:51Z

     * PR  #24357:  (zhujinhe) fix invoke issues of Jinja Macros example |
       refs: #24380

     * a6a1f87 Merge pull request #24380 from rallytime/bp-24357

     * f08c875 fix invoke issues of Jinja Macros example

   * PR #24388: (pengyao) fixes #24358 @ 2015-06-04T20:07:40Z

     * ISSUE #24358: (pengyao) Netapi SSH client  don't  support  ssh_user
       and ssh_passwd arguments | refs: #24388

     * 86ce9db Merge pull request #24388 from pengyao/sshclient-kwargs

     * 5c08ca4 fixes #24358

   * PR  #24367: (terminalmage) Improve error message when module does not
     exist @ 2015-06-04T20:07:12Z

     * ISSUE  #22958:  (highlyunavailable)  Weird  error  when  typoing  a
       command | refs: #24367

     * 72d2eae Merge pull request #24367 from terminalmage/issue22958

     * d0d7a54 Improve error message when module does not exist

   * PR #24412: (jfindlay) backport #23387 @ 2015-06-04T20:06:03Z

     * ISSUE  #23101:  (gravyboat)  Create  a docs page for labels | refs:
       #23387

     * PR #23387: (rallytime) Add some "What are all  these  labels  for?"
       documentation | refs: #24412

     * a628778 Merge pull request #24412 from jfindlay/bp-23387

     * bf85772 Make sure the parameters are in the correct order

     * 9f53809 Add "* Change" label parameters

     * b27a15e Remove "workaround" wording

     * 9fff35a Some small fixes

     * 54a7089 Link the new labels doc in contributing and hacking docs

     * 375695e Add pull request label definitions

     * de94563 Add Feature Request label definition

     * 684f291 Add issue definition and augment functional areas section

     * 2da13dd Start a "what are all of these labels for?" doc

   * PR  #24336:  (twangboy)  Added  line to give more descriptive error @
     2015-06-04T19:56:00Z

     * ISSUE #24154: (ssgward) Exception when running cp.get_url  |  refs:
       #24336

     * 485116c Merge pull request #24336 from twangboy/fix_cp_get_url

     * 37b11f9 Added line to give more descriptive error

   * PR #24413: (techhat) Add more namespaced functions to GoGrid driver @
     2015-06-04T19:51:22Z

     * b3d39cc Merge pull request #24413 from techhat/gogridnamespace

     * 1b397cb Adding blank line

     * da08cc9 Add more namespaced functions to GoGrid driver

   * PR   #24399:   (kiorky)   Versionvirtual    |    refs:    #24398    @
     2015-06-04T18:02:22Z

     * ISSUE #24397: (kiorky) on debian: states.apt should use virtualname
       as it shadows system apt module | refs: #24398 #24398 #24399 #24399
       #24400

     * PR #24398: (kiorky) VirtualName for states.apt | refs: #24399

     * 27f109b Merge pull request #24399 from makinacorpus/versionvirtual

     * 235c78d Use apt_pkg.version_compare if available

     * 1c0cd45 reindent block to isolate conflict on merge forward

     * 699ecea use var to isolate conflict on merge forward

   * PR #24371: (joejulian) 2015.5 tls module tests @ 2015-06-04T15:20:16Z

     * deaee68       Merge       pull       request       #24371      from
       joejulian/2015.5_tls_module_tests

     * 4c5dee1 Add @destructiveTest decorator to destructive tests

     * 274bbd4 Accept results from older pyOpenSSL

     * 161f913 All cert info should be in UTC always

     * 9affcca See the whole diff if dict compare fails

     * 94f6208 Ignore extensions for now. Resolve this as part  of  fixing
       issue 24338.

     * 84904d3 Mask lint warning for unused imported module

     * 5675b78 Do not test if PyOpenSSL is not installed

     * 563cc66 Add tls tests

   * PR  #24403:  (jayeshka)  adding  states/process  unit  test  case.  @
     2015-06-04T15:19:01Z

     * 84686ee      Merge       pull       request       #24403       from
       jayeshka/process_states-unit-test

     * fcb71fb adding states/process unit test case.

   * PR   #24402:  (jayeshka)  adding  states/pyenv  unit  test  case.   @
     2015-06-04T15:18:11Z

     * 35de8d7      Merge       pull       request       #24402       from
       jayeshka/pyenv_states-unit-test

     * 5f263ab adding states/pyenc unit test case.

   * PR  #24401:  (jayeshka)  adding  states/powerpath  unit test case.  @
     2015-06-04T15:17:46Z

     * 632f838      Merge       pull       request       #24401       from
       jayeshka/powerpath-states-unit-test

     * 49ff927 adding states/powerpath unit test case.

   * PR #24400: (kiorky) Aptversion @ 2015-06-04T15:17:19Z

     * ISSUE #24397: (kiorky) on debian: states.apt should use virtualname
       as it shadows system apt module | refs: #24398 #24398 #24399 #24399
       #24400

     * 0a6e5e0 Merge pull request #24400 from makinacorpus/aptversion

     * e15cb93 Use apt_pkg.version_compare if available

     * 953725a Fix too much quoting in apt.version_cmp

   * PR  #24385:  (jeanpralo)  Fix  salt.modules.dockerio.start  method  @
     2015-06-04T15:00:22Z

     * a904055      Merge       pull       request       #24385       from
       jeanpralo/Fix-binds-dockerio.start

     * a0fed31 binds dict if not specified should remain to none otherwise
       docker-py will try to create a new host config and all  volume  and
       ports  binds are lost. config should be done at the creation of the
       container not when we start it

   * PR  #24381:  (jtand)  Disabled  flaky  test   to   review   later   @
     2015-06-04T14:57:43Z

     * 9890bc4 Merge pull request #24381 from jtand/seed_test

     * 7570ae9 Disabled flaky test to review later

   * PR  #24382:  (basepi) [2015.5] Handle CommandExecutionError in grains
     commands, Fixes #23342 @ 2015-06-04T12:44:04Z

     * ISSUE #23342: (philipsd6) salt-ssh 2015.2.0rc2  fails  when  target
       doesn't have lspci available | refs: #24382

     * b3fa8fe       Merge       pull       request       #24382      from
       basepi/grainscommandnotfound23342

     * 85b91d6 Handle CommandExecutionError in grains commands

   * PR   #24379:   (Starblade42)   Fixes   an   issue   where   Pagerduty
     states/modules   couldn't   find   their  profile  in  the  Pillar  @
     2015-06-04T12:41:13Z

     * 52587a4 Merge pull request #24379 from Starblade42/2015.5

     * b93dc5e Linting!

     * 2dd5904 Fixes an issue where Pagerduty states/modules couldn't find
       it's profile in the Pillar

   * PR  #24366:  (terminalmage)  Use yes $'\n' instead of printf '\n' for
     pecl commands @ 2015-06-03T21:28:58Z

     * 3ca35d1 Merge pull request #24366 from terminalmage/pecl-yes

     * dcd9ad8 Use yes $'\n' instead of printf '\n' for pecl commands

   * PR #24348: (kiorky) Try to close input pipes before calling lxc-start
     @ 2015-06-03T19:38:07Z

     * ISSUE  #24284:  (kiorky) systemd lxc containers need use_vt=True at
       lxc-start stage | refs: #24348

     * PR  #548:  (Lanzaa)   Salt   is   now   platform   dependent.   Use
       get_python_lib(1) | refs: #24348

     * 86a3b31 Merge pull request #24348 from makinacorpus/lxcpre

     * 0cb11a2 lxc: typo

     * d71efa6 Try to close input pipes before calling lxc-start

   Salt 2015.5.4 Release Notes
   Version 2015.5.4 is a bugfix release for 2015.5.0.

   Changes:

   * The  cron.present  state  now  correctly  defaults  to  state  ID  as
     identifier.

   * When querying for VMs in digital_ocean_v2.py, the number  of  VMs  to
     include  in a page was changed from 20 (default) to 200 to reduce the
     number of API calls to Digital Ocean.

   * The vmware Salt-Cloud driver was back-ported from the develop  branch
     in order for installations of Salt that are older than 2015.8.0 to be
     able to use  the  vmware  driver  without  stack-tracing  on  various
     deprecation paths that were implemented in the 2015.8.0 release.

   Changes for v2015.5.3..v2015.5.4
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-08-13T20:23:30Z

   Statistics:

   * Total Merges: 247

   * Total Issue references: 140

   * Total PR references: 330

   Changes:

   * PR #26292: (jquast) Rabbitmq 3.2.4  on  Ubuntu  has  "...done.",  not
     "...done" @ 2015-08-13T19:53:29Z

   * PR #26296: (jquast) bugfix missing
     `
     runas=None'   for   rabbitmqctl   cmds   (backport   to   2015.5)   @
     2015-08-13T19:52:40Z

   * PR #26293: (jfindlay) Fix #26268 @ 2015-08-13T19:48:06Z

     * ISSUE #25618: (twangboy) Fix  reg.py  to  work  with  the  registry
       properly | refs: #26268

     * PR #26268: (twangboy) Multiple improvements to reg executionmod and
       state mod | refs: #26293

   * PR #26290: (rallytime) Only call convert_to_arn when action  name  is
     provided @ 2015-08-13T18:48:58Z

     * ISSUE #25192: (deuscapturus) 2015.5.2 boto_cloudwatch_alarm.present
       not working.  | refs: #26290

   * PR #26288: (bbinet) allow deleting grains  which  value  is  False  @
     2015-08-13T18:24:36Z

   * PR   #26263:  (rallytime)  Don't  make  changes  when  test=True  for
     openstack present/absent funcs @ 2015-08-13T16:30:31Z

     * ISSUE #24882:  (nmadhok)  salt.states.openstack_config.present  and
       salt.states.openstack_config.absent  make  changes when test=True |
       refs: #26263

   * PR  #26265:  (rallytime)  Don't  stacktrace  on   query   return   in
     ec2.create_snapshot @ 2015-08-13T16:28:48Z

     * ISSUE  #24484:  (codehotter)  clouds/ec2.py: create_snapshot throws
       exception | refs: #26265

   * PR  #26285:  (stanislavb)  Remove  explicit  version  from   instance
     identity URL @ 2015-08-13T16:25:32Z

   * PR  #26275:  (cachedout)  Re-init modules on multi-master reconnect @
     2015-08-13T15:52:50Z

   * PR #26273: (garethgreenaway) Fixes to schedule  module  in  2015.5  @
     2015-08-13T15:34:43Z

   * PR    #26271:    (rallytime)    Fix    del_root_vol_on_destroy    and
     del_all_vols_on_destroy functionality on ec2 @ 2015-08-12T23:22:47Z

     * ISSUE #24483: (codehotter)  clouds/ec2.py:  del_root_vol_on_destroy
       and del_all_vols_on_destroy not working | refs: #26271

   * PR  #26219:  (anlutro)  cron:  make  identifier default to state ID @
     2015-08-12T18:42:33Z

     * ISSUE #25958: (anlutro) Cron identifier does not default  to  state
       ID as documented | refs: #26219

   * PR    #26257:    (rallytime)    Back-port    #26237   to   2015.5   @
     2015-08-12T18:40:35Z

     * ISSUE #26207: (fullermd) group members setting fails  with  obscure
       error message on FreeBSD | refs: #26237

     * PR #26237: (silenius) fix issue #26207 | refs: #26257

   * PR  #26258:  (nmadhok)  Fix permission on tests/runtests.py on 2015.5
     branch @ 2015-08-12T18:40:04Z

   * PR #26261: (nmadhok)  Correct  spelling  of  integration  in  docs  @
     2015-08-12T18:14:48Z

     * PR #2015: (thekuffs) Esky / bbfreeze support

   * PR  #26247:  (nmadhok)  Initial commit of unit tests for vmware cloud
     driver @ 2015-08-12T16:58:24Z

   * PR #26246: (nmadhok) Backport additions to VMware cloud  driver  from
     develop to 2015.5 branch @ 2015-08-12T15:11:26Z

   * PR  #26239:  (opdude)  Fixed  documentation  to match function name @
     2015-08-12T14:48:52Z

   * PR #26232: (garethgreenaway) Fix  to  trust_key  in  gpg  module  for
     2015.5.  @ 2015-08-12T04:48:27Z

   * PR  #26084:  (twangboy)  Added python_shell=True, quoted user input @
     2015-08-10T21:29:35Z

     * ISSUE #25802:  (jefftucker)  Running  module  "npm.list"  fails  on
       Windows for masterless minion | refs: #26084

   * PR    #26183:    (cro)    Fix    LDAP    configuration    issue.    @
     2015-08-10T19:09:41Z

   * PR    #26186:    (jacobhammons)    regenerated    man     pages     @
     2015-08-10T19:07:44Z

   * PR  #26182:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-08-10T19:00:10Z

     * ISSUE           #25961:            (getabc)            [2015.5.3-2]
       salt-winrepo.git/salt-minion.sls fails certificate '
       *
       .wpengine.com' or 'wpengine.com' | refs: #26047

     * ISSUE  #25751:  (basepi)  Document master_finger more prominently |
       refs: #26088

     * PR #26116: (corux) file.replace fails if repl string is an  invalid
       regex and append/prepend is used

     * PR #26088: (jacobhammons) Master finger

     * PR  #26047:  (jacobhammons)  Updated  windows download links in the
       docs to https://repo.saltstack.com

   * PR #26000: (driskell) Implement full  event  caching  for  subscribed
     tags @ 2015-08-10T18:57:17Z

     * ISSUE #25998: (driskell) Event subsystem discarding required events
       during --batch breaking it for slow running commands | refs: #26000

   * PR   #26175:   (rallytime)   Back-port    #26153    to    2015.5    @
     2015-08-10T18:22:32Z

     * PR  #26153:  (loa)  Fix  dockerio  state documentation typo | refs:
       #26175

   * PR   #26177:   (rallytime)   Back-port    #26147    to    2015.5    @
     2015-08-10T18:22:01Z

     * ISSUE #26024: (jpic) lxc_conf_unset in cloud.profile is ignored

     * PR #26147: (martinhoefling) Fixes #26024 | refs: #26177

   * PR    #26179:    (rallytime)    Back-port    #25404   to   2015.5   @
     2015-08-10T18:21:50Z

     * ISSUE #21082: (clinta) master_type failover does  not  failover  on
       DNS errors | refs: #25404

     * PR #25404: (DmitryKuzmenko) Fixed minion failover to next master on
       DNS errors.  | refs: #26179

   * PR  #26180:   (jfindlay)   fix   processing   of   state.template   @
     2015-08-10T18:21:38Z

     * ISSUE  #26112:  (wt)  state.template  fails with unclear error with
       template with only an include | refs: #26180

   * PR #26172: (nmadhok) [Backport] Make sure variable  is  a  dictionary
     before popping something from it.  @ 2015-08-10T16:42:50Z

     * ISSUE #26162: (nmadhok) VMware cloud driver create function failing
       with traceback on latest develop | refs: #26163 #26172

     * PR #26163: (nmadhok) Make sure  variable  is  a  dictionary  before
       popping something from it.

   * PR #26168: (cachedout) Fix slack docs @ 2015-08-10T14:57:18Z

     * ISSUE #26098: (rdinoff) SALT.STATES.SLACK Doc update | refs: #26168

   * PR  #26127:  (garethgreenaway)  Fixes  to  salt.utils.http related to
     cp.get_file_str bug.  @ 2015-08-10T14:38:25Z

     * ISSUE #24106: (nvx) fileclient.py#get_url ignores HTTP  Auth  again
       (2015.5 regression) | refs: #26127

   * PR #26140: (nmadhok) VMware cloud driver fixes @ 2015-08-10T13:15:58Z

     * ISSUE  #26141:  (nmadhok) salt-cloud VMware driver fails with error
       in parsing configuration file | refs: #26140

     * ISSUE #25809: (o-sleep) vmware cloud module error message  |  refs:
       #26140

     * ISSUE  #25625:  (steverweber)  cloud vmware driver does not provide
       mac_address unless vmware tools is running | refs: #26137 #26140

   * PR #26137: (steverweber) use device mac address if vmtools not active
     @ 2015-08-09T03:05:36Z

     * ISSUE  #25625:  (steverweber)  cloud vmware driver does not provide
       mac_address unless vmware tools is running | refs: #26137 #26140

   * PR   #26119:   (jodv)   Backport   eauth   bugfix   to    2015.5    @
     2015-08-09T02:19:52Z

   * PR #26135: (cro) Fix proxy minions in 2015.5 and significantly update
     documentation.  @ 2015-08-09T02:19:21Z

   * PR #26132: (TheBigBear) minor edit @ 2015-08-08T21:05:34Z

   * PR #26133: (amontalban) Fixed  #25915  in  salt/modules/pkgng.py  and
     salt/states/pkg.py @ 2015-08-08T21:05:05Z

     * ISSUE #25915: (ari) FreeBSD pkg install fails

   * PR  #26111:  (anlutro) Better error messages when virtualenv creation
     fails @ 2015-08-07T21:42:09Z

   * PR #26110: (jfindlay) check for sources before adding them to cmd str
     @ 2015-08-07T21:33:23Z

     * ISSUE #26093: (freedba) archive.tar bug | refs: #26110

   * PR #26106: (vr-jack) Update __init__.py @ 2015-08-07T21:15:55Z

   * PR    #26101:    (rallytime)    Back-port    #25984   to   2015.5   @
     2015-08-07T18:56:26Z

     * ISSUE #25983: (jmdcal) Trying to get  md5  of  local  zip  |  refs:
       #25984

     * PR  #25984:  (jmdcal)  Support  local  files without md5sum | refs:
       #26101

   * PR   #26080:   (techhat)   Fix   string   checking    in    s3fs    @
     2015-08-06T23:36:09Z

   * PR   #26079:   (cachedout)   Update   docs  to  remove  state.over  @
     2015-08-06T23:35:26Z

     * ISSUE #26039: (basepi) Update scheduler  docs  to  use  orchestrate
       instead of overstate | refs: #26079

   * PR  #26058:  (opdude)  Fix choco version on chocolatey versions below
     0.9.9 @ 2015-08-06T18:50:10Z

   * PR #26068: (jfindlay) fix autoruns.list looking in wrong directory  @
     2015-08-06T18:49:48Z

   * PR  #26065:  (s0undt3ch)  [2015.5]  Update to latest bootstrap stable
     release v2015.06.08 @ 2015-08-06T17:09:35Z

     * ISSUE #634: (loupgaroublond) /srv/salt/_grains/  not  documented  |
       refs: #26065

     * ISSUE  #631:  (fatbox)  Can't extend the same item multiple times |
       refs: #26065

     * ISSUE #625: (whiteinge) cmd.run state user flag is  not  working  |
       refs: #25506 #632

     * PR  #640: (terminalmage) fix syntax errors introduced in 0f776c13 |
       refs: #26065

     * PR   #638:   (blast-hardcheese)    Tightened    up    configuration
       documentation | refs: #26065

     * PR #633: (epoelke) Bug fix to salt-key | refs: #26065

     * PR  #632: (whiteinge) Change the cmd.run state to use the new runas
       arg | refs: #26065

   * PR   #26061:    (gmcwhistler)    Patch    for    issue    #25994    @
     2015-08-06T17:07:34Z

     * ISSUE   #25994:   (gmcwhistler)  module.ilo  tempfile  creation  in
       __execute_cmd results in TypeError: cannot  concatenate  'str'  and
       'int' objects

   * PR  #26064:  (s0undt3ch)  Don't  stacktrace  when  trying  to get the
     default locale.  @ 2015-08-06T16:11:05Z

     * ISSUE #26063: (saltstack-bot) not  working  with  salt-cloud  shows
       unknown locale error | refs: #26064

   * PR  #26048: (jacobhammons) Updated windows download links in the docs
     to https://repo.saltstack.com @ 2015-08-05T22:59:50Z

   * PR #26044: (rallytime) Make sure the  key  we're  comparing  is  also
     lowercase @ 2015-08-05T19:23:54Z

     * ISSUE #25616: (rallytime) [2015.5] Provisioning Linodes Stacktraces
       | refs: #26044

   * PR  #26042:  (jfindlay)  fix  test  mode  logic  in  state   docs   @
     2015-08-05T19:23:07Z

   * PR #26036: (nicholascapo) survey.hash: Remove manually printed text @
     2015-08-05T19:21:59Z

     * ISSUE #24460: (nicholascapo) Survey runner does  not  follow  --out
       flag | refs: #26036

   * PR #26030: (opdude) Fix a bug in choco version that returned odd data
     @ 2015-08-05T16:30:25Z

   * PR  #26032:  (jfindlay)  add  test  logic  to  state  reult   doc   @
     2015-08-05T16:28:32Z

   * PR  #26031:  (alekti) Revert "Add file as supported protocol for file
     source_hash. Fixes #23764" @ 2015-08-05T15:32:01Z

     * ISSUE #23764: (es1o) source_hash from local file is not  supported.
       | refs: #25750

   * PR   #26021:   (anlutro)   Documentation:  Specify  versionadded  for
     git.present shared argument @ 2015-08-05T14:17:38Z

   * PR #26020: (alekti) Correctly resolve conflict merging pull 25750  to
     2015.5 @ 2015-08-05T14:16:58Z

     * ISSUE  #23764: (es1o) source_hash from local file is not supported.
       | refs: #25750

     * PR #25750:  (alekti)  Add  file  as  supported  protocol  for  file
       source_hash. Fixes #25701.  | refs: #26020

   * PR   #26016:   (basepi)   Revert  "Deep  merge  of  pillar  lists"  @
     2015-08-05T04:59:52Z

     * ISSUE #22241: (masterkorp) Salt master not properly generating  the
       map | refs: #25358

     * PR #25358: (dkiser) Deep merge of pillar lists | refs: #26016

   * PR #25992: (twangboy) Refactor win_system.py @ 2015-08-05T04:54:18Z

     * ISSUE   #12255:   (eliasp)  'system.set_computer_desc'  fails  with
       non-ASCII chars | refs: #25992

     * ISSUE #3: (thatch45) libvirt module

   * PR #26002: (twangboy) Fixed regex to account  for  comment  character
     followed by whitespace @ 2015-08-04T22:28:11Z

     * ISSUE  #25948: (twangboy) Fix uncomment function to handle spaces |
       refs: #26002

   * PR  #25970:  (jfindlay)  accept  addition   of   layman   overlay   @
     2015-08-04T15:42:28Z

     * ISSUE  #25949: (godlike64) layman.add does not work with unofficial
       overlays | refs: #25970

   * PR #25971: (basepi) [2015.5] salt.modules.reg Add spaces for  strings
     split across multiple lines @ 2015-08-04T15:39:48Z

   * PR    #25990:    (rallytime)    Back-port    #25976   to   2015.5   @
     2015-08-04T14:36:53Z

     * PR #25976: (fleaflicker) Typo in help output | refs: #25990

   * PR   #25996:    (attiasr)    fix    msiexec    package    remove    @
     2015-08-04T14:36:31Z

   * PR    #25966:    (rallytime)    Back-port    #25864   to   2015.5   @
     2015-08-03T18:48:26Z

     * ISSUE #25863: (peterdemin) pkg.installed fails on already installed
       package if it is in versionlock.list | refs: #25864

     * PR  #25864:  (peterdemin)  #25863  state.pkg.installed  fix | refs:
       #25966

   * PR   #25967:   (rallytime)   Back-port    #25917    to    2015.5    @
     2015-08-03T18:48:02Z

     * PR #25917: (jmdcal) adding missing format string | refs: #25967

   * PR  #25895:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-08-03T17:12:37Z

     * ISSUE #23764: (es1o) source_hash from local file is not  supported.
       | refs: #25750

     * PR  #25750:  (alekti)  Add  file  as  supported  protocol  for file
       source_hash. Fixes #25701.  | refs: #26020

     * PR #25704: (cachedout) Ensure prior alignment with  master_type  in
       2014.7

     * PR #25657: (MrCitron) Add the ability to specify a base pattern for
       carbon returner

     * PR #25633: (AkhterAli) Update loader.py

   * PR  #25941:  (jfindlay)  add  timelib  to   dependency   versions   @
     2015-08-03T12:23:42Z

     * ISSUE #25850: (ssgward) Need to add packages to --versions-report |
       refs: #25941

   * PR   #25951:    (garethgreenaway)    Log    when    event.fire    and
     event.fire_master fail.  @ 2015-08-03T00:19:45Z

   * PR #25942: (jfindlay) typo in minion doc @ 2015-07-31T23:34:55Z

     * ISSUE  #25838: (grep4linux) docs disable_modules documentation typo
       | refs: #25942

   * PR #25938: (jacobhammons) Doc on  using  syndic  with  multimaster  @
     2015-07-31T23:05:05Z

     * PR #14690: (jacksontj) Multi syndic | refs: #25938

   * PR  #25848:  (twangboy)  Added  allusers="1"  when  installing  msi @
     2015-07-31T20:33:17Z

     * ISSUE #25839: (twangboy) ALLUSERS="1"  should  be  a  default  when
       installing MSI's | refs: #25848

   * PR   #25898:   (jfindlay)   clarify   and   expand   syndic   docs  @
     2015-07-31T20:01:23Z

   * PR  #25927:  (jacksontj)  Pass  actual  renderers  to  the  Reactor's
     Compiler @ 2015-07-31T20:00:17Z

     * ISSUE  #25852:  (UtahDave)  Salt loader is not loading Salt vars in
       reactor python renderer | refs: #25927

   * PR  #25921:   (cachedout)   Handle   non-ascii   in   state   log   @
     2015-07-31T17:41:30Z

     * ISSUE  #25810: (nvx) winpkg highstate fails when a new package name
       contains a unicide character | refs: #25921

   * PR #25919: (TheBigBear) Minor  update  to  msi  un-installer  info  @
     2015-07-31T17:39:48Z

   * PR    #25905:    (rallytime)    Back-port    #25982   to   2015.5   @
     2015-07-30T23:24:19Z

     * PR #25892: (TheBigBear) Update 7-zip msi un-installer  instructions
       | refs: #25905

   * PR    #25890:    (rallytime)    Back-port    #25698   to   2015.5   @
     2015-07-30T23:12:09Z

     * ISSUE #25577: (yellow1912) Wrong indentation in  document  |  refs:
       #25696

     * PR #25698: (rallytime) Back-port #25659 to 2015.8 | refs: #25890

     * PR #25696: (AkhterAli) Update schedule.py

     * PR  #25659:  (isbm)  Bugfix:  crash  at getting non-existing repo |
       refs: #25698

   * PR #25894: (jacobhammons) Minor doc bug fixes @ 2015-07-30T23:02:34Z

     * ISSUE #25650: (jacksontj) state.running documentation is  incorrect
       | refs: #25894

     * ISSUE   #24042:   (whiteinge)   The  state_events  setting  is  not
       documented | refs: #25894

     * ISSUE #23788: (k5jj) functions  in  drac.py  module  do  not  match
       documentation | refs: #25894

     * ISSUE  #21296:  (Lothiraldan)  Possible  minion  enumeration  using
       saltutil.find_job and eauth | refs: #25894

   * PR #25877: (rallytime) Protect against passing a map file in addition
     to VM names with --destroy @ 2015-07-30T21:55:45Z

     * ISSUE  #24036: (arthurlogilab) [salt-cloud] Protect against passing
       command line arguments as names for the --destroy  command  in  map
       files | refs: #25877

   * PR    #25870:    (rallytime)    Back-port    #25824   to   2015.5   @
     2015-07-30T21:54:35Z

     * PR #25824: (klyr) Fix get_managed() in  file.py  module  for  local
       files | refs: #25870

   * PR #25885: (t0rrant) Update Debian changelog @ 2015-07-30T20:05:59Z

   * PR    #25875:    (rallytime)    Back-port    #25862   to   2015.5   @
     2015-07-30T17:34:02Z

     * ISSUE #25478: (zyio) salt-ssh  -  Unable  to  locate  current  thin
       version | refs: #25862

     * ISSUE  #25026: (sylvia-wang) salt-ssh "Failure deploying thin" when
       using salt module functions | refs: #25862

     * PR #25862: (zyio) Adding SCP_NOT_FOUND exit code | refs: #25875

   * PR   #25873:   (rallytime)   Back-port    #25855    to    2015.5    @
     2015-07-30T17:33:55Z

     * PR #25855: (puneetk) Patch 3 | refs: #25873

   * PR    #25871:    (rallytime)    Back-port    #25829   to   2015.5   @
     2015-07-30T17:33:43Z

     * PR #25829: (peterdemin) Fixed typo in  salt.states.saltmod.function
       doc string | refs: #25871

   * PR    #25869:    (rallytime)    Back-port    #25788   to   2015.5   @
     2015-07-30T17:33:33Z

     * ISSUE #24002: (csakoda) File lock  contention  on  windows  minions
       causing highstate crash | refs: #25788

     * PR  #25788:  (opdude)  Catch a hard crash when running highstate on
       windows | refs: #25869

   * PR #25853: (davidjb) Make ssh-id-wrapper accessible to non-root users
     @ 2015-07-30T16:49:47Z

     * ISSUE  #19532: (stolendog) salt-ssh running git clone with not root
       user | refs: #25853

   * PR #25856: (jfindlay) expand minion reauth scalability  documentation
     @ 2015-07-30T15:33:17Z

     * ISSUE   #25447:  (spo0nman)  SaltMaster  is  crippled  with  Minion
       Re-Authentication | refs: #25856

   * PR #25840: (jfindlay) add note to winrepo state docs  about  required
     grain @ 2015-07-30T14:38:27Z

     * ISSUE  #25801:  (themalkolm)  Update  docs that salt.states.winrepo
       requires roles:salt-master in grains.  | refs: #25840

   * PR #25846: (jfindlay) rework deprecation  documentation  for  release
     names @ 2015-07-30T13:26:21Z

     * ISSUE  #25827: (0xf10e) "Deprecating Code" doesn't mention Usage of
       warn_until() w/ Release Names | refs: #25846

   * PR  #25833:  (jahamn)  Allows  cp.push  to  recreate  empty  files  @
     2015-07-29T16:14:48Z

     * ISSUE  #23288: (UtahDave) cp.push fails to recreate empty files.  |
       refs: #25833

   * PR #25831: (rallytime) Add salt:// to key_url  options  to  docs  for
     pkgrepo.managed @ 2015-07-29T15:38:43Z

     * ISSUE  #11474: (JensRantil) pkgrepo.managed key_url: salt:// always
       use base env | refs: #25831

   * PR #25807: (rallytime) Provide helpful error when using actions  with
     a mapfile @ 2015-07-29T15:30:15Z

     * ISSUE  #22699:  (arthurlogilab)  salt-cloud  fails on KeyError when
       given a nonexistent action | refs: #25807

   * PR #25818: (jfindlay) fix autoruns list @ 2015-07-29T15:29:20Z

   * PR  #25826:  (anlutro)  Check  that   "onchanges"   is   a   list   @
     2015-07-29T15:00:28Z

   * PR  #25798:  (twangboy)  Fixed stacktrace on package name not found @
     2015-07-28T22:40:14Z

     * ISSUE #25258: (nickw8) windows minion repo  not  updating  |  refs:
       #25798

   * PR  #25797:  (twangboy)  Changed  repocache  back  to  cached_repo  @
     2015-07-28T22:39:32Z

     * ISSUE #25437: (lorengordon)  Stacktrace  on  Windows  when  running
       pkg.list_pkgs | refs: #25598 #25763

     * PR #25763: (twangboy) Fix 25437 | refs: #25797

   * PR    #25793:    (rallytime)    Back-port    #25730   to   2015.5   @
     2015-07-28T19:37:34Z

     * PR #25730: (sjorge) patchelf lives in pkgsrc | refs: #25793

   * PR   #25792:   (rallytime)   Back-port    #25688    to    2015.5    @
     2015-07-28T19:37:17Z

     * PR  #25688: (bclermont) Don't acquire lock if there is no formatter
       | refs: #25792

   * PR #25796: (cachedout) Remove debug from docs @ 2015-07-28T17:35:59Z

   * PR  #25749:  (jahamn)  Allow  zpool.create  on  character  devices  @
     2015-07-28T16:01:40Z

     * ISSUE  #24920: (voileux) module.zpool.create on character device is
       not possible by salt | refs: #25749

   * PR #25685: (twangboy) Fixed regex issues with comment and uncomment @
     2015-07-28T15:29:49Z

   * PR #25763: (twangboy) Fix 25437 | refs: #25797 @ 2015-07-28T15:29:27Z

     * ISSUE  #25437:  (lorengordon)  Stacktrace  on  Windows when running
       pkg.list_pkgs | refs: #25598 #25763

   * PR #25752: (thatch45) State top saltenv @ 2015-07-28T01:02:10Z

   * PR #25755: (twangboy) Fixed problem with dunder functions  not  being
     passed @ 2015-07-27T19:31:22Z

     * ISSUE #25717: (twangboy) Problem with chocolatey module not loading
       | refs: #25755

   * PR #25648: (twangboy) Clarified functionality of  reg  module,  fixed
     state to work with new module @ 2015-07-27T19:30:33Z

     * ISSUE  #25352: (m03) reg.absent reporting incorrect results | refs:
       #25648

     * ISSUE #1: (thatch45) Enable regex on the salt cli

   * PR   #25740:   (rallytime)   Back-port    #25722    to    2015.5    @
     2015-07-27T16:08:40Z

     * ISSUE  #25154:  (uvsmtid)  All data mixed on STDOUT together should
       generate valid JSON output | refs: #25722

     * ISSUE #25153: (uvsmtid) Multiple results should generate valid JSON
       output | refs: #25722

     * PR  #25722:  (uvsmtid)  Minor docs changes to emphasize JSON output
       problems without --static option | refs: #25740

   * PR   #25739:   (rallytime)   Back-port    #25709    to    2015.5    @
     2015-07-27T16:08:27Z

     * PR     #25709:     (colekowalski)     add     direct-io-mode     to
       mount_invisible_options | refs: #25739

     * PR #25699: (rallytime) Back-port #25660 to 2015.5 | refs: #25709

     * PR  #25660:  (colekowalski)  add   glusterfs'   direct-io-mode   to
       mount_invisible_keys | refs: #25699 #25709

   * PR    #25738:    (rallytime)    Back-port    #25671   to   2015.5   @
     2015-07-27T16:08:23Z

     * PR #25671: (niq000) added a  parameter  so  verifying  SSL  is  now
       optional instead of hard-coded | refs: #25738

   * PR    #25737:    (rallytime)    Back-port    #25608   to   2015.5   @
     2015-07-27T16:08:18Z

     * ISSUE #25229: (rall0r) Module  git.latest  kills  target  directory
       when test=True | refs: #25608

     * PR  #25608: (rall0r) Fix: prevent git.latest from removing target |
       refs: #25737

   * PR #25733: (davidjb) Avoid IndexError when listing  mounts  if  mount
     output ends in newline @ 2015-07-27T16:08:05Z

   * PR   #25705:   (blackduckx)  Support  for  setm  augeas  command.   @
     2015-07-27T16:07:10Z

     * ISSUE #22460: (onmeac) Command setm is not supported (yet) |  refs:
       #25705

   * PR  #25703:  (cachedout)  Return  to str for master_type for 2015.5 @
     2015-07-27T16:06:22Z

   * PR #25702: (twangboy) Fixed win_user module for groups with spaces in
     the name @ 2015-07-27T15:06:33Z

     * ISSUE  #25144: (johnccfm) user.present on Windows fails to add user
       to groups if group name contains a space | refs: #25702

   * PR      #25711:       (twangboy)       Fixed       problem       with
     win_servermanager.list_installed @ 2015-07-27T15:05:48Z

     * ISSUE  #25351:  (m03) win_servermanager.list_installed failing with
       "IndexError: list index out of range" | refs: #25711

   * PR #25714: (cachedout) Display  warning  when  progressbar  can't  be
     loaded @ 2015-07-25T00:10:13Z

     * ISSUE  #25435:  (yee379)  progressbar  dependency  missing  | refs:
       #25714

   * PR #25699: (rallytime) Back-port #25660 to 2015.5 |  refs:  #25709  @
     2015-07-24T22:11:40Z

     * PR   #25660:   (colekowalski)   add  glusterfs'  direct-io-mode  to
       mount_invisible_keys | refs: #25699 #25709

   * PR #25694: (s0undt3ch) Salt-SSH fix for #25689 @ 2015-07-24T21:41:57Z

     * ISSUE #25689: (anlutro) Minion log in salt-ssh | refs: #25694

   * PR  #25710:  (jahamn)  Integration  Testcase  for   Issue   25250   @
     2015-07-24T20:57:33Z

     * ISSUE  #25250:  (wipfs) 'force' option in copy state deletes target
       file | refs: #25461 #25710

   * PR #25680: (basepi) [2015.5] Move cmd.run jinja aliasing to a wrapper
     class to prevent side effects @ 2015-07-24T19:52:10Z

     * PR  #25049:  (terminalmage)  Fix  cmd.run  when  cross-called  in a
       state/execution module | refs: #25680

   * PR #25682: (basepi) [2015.5] Fix parsing args with just a hash (#)  @
     2015-07-24T19:52:01Z

   * PR  #25695:  (stanislavb)  Configurable  AWS region & region from IAM
     metadata @ 2015-07-24T19:36:40Z

   * PR #25645: (kev009) Fix pkgng provider to work with  a  sources  list
     and the underlying pkg... @ 2015-07-24T16:33:18Z

   * PR #25677: (aneeshusa) Fix pacman.list_upgrades when refresh=True.  @
     2015-07-24T16:30:06Z

   * PR  #25675:  (UtahDave)  Use  OS  line  endings  with   contents   on
     file.managed @ 2015-07-24T16:29:50Z

     * ISSUE  #25674: (UtahDave) file.managed with contents parameter uses
       wrong line endings on Windows | refs: #25675

   * PR #25676: (basepi) Update release candidate docs  to  2015.8.0rc2  @
     2015-07-23T20:29:37Z

   * PR  #25666:  (nmadhok)  Check  if the properties exist before looping
     over them causing KeyError @ 2015-07-23T17:55:40Z

     * ISSUE  #25665:  (nmadhok)  salt-cloud  VMware  driver  fails   with
       KeyErrors   if   there's   any   existing  machine  in  the  VMware
       infrastructure in (invalid state) | refs: #25666

   * PR  #25656:  (anlutro)  Fix  locale  detection  in  debian/gentoo   @
     2015-07-23T16:46:40Z

   * PR    #25661:    (rallytime)    Back-port    #25624   to   2015.5   @
     2015-07-23T16:26:48Z

     * PR #25624: (bobrik) Fix typo in get_routes example for debian_ip  |
       refs: #25661

   * PR    #25662:    (rallytime)    Back-port    #25638   to   2015.5   @
     2015-07-23T16:26:40Z

     * ISSUE #15209: (hubez) file.manage:  source_hash  not  working  with
       s3:// (2014.7.0rc1) | refs: #25638

     * PR #25638: (TronPaul) fix bad merge in 99fc7ec | refs: #25662

   * PR #25644: (cachedout) pillar doc fix @ 2015-07-22T22:57:23Z

     * ISSUE  #25413:  (zizkebab)  pillar_opts  default  behavior  is  not
       reflected in the docs | refs: #25644

   * PR  #25642:  (cachedout)   Warn   on   pillar   schedule   delete   @
     2015-07-22T22:04:12Z

     * ISSUE #25540: (dennisjac) salt highstate schedule cannot be removed
       | refs: #25642

   * PR #25598: (twangboy) Fixed problem trying to load file with name  of
     boolean type @ 2015-07-22T17:07:49Z

     * ISSUE  #25437:  (lorengordon)  Stacktrace  on  Windows when running
       pkg.list_pkgs | refs: #25598 #25763

     * 7b79e433 Merge pull request #25598 from twangboy/fix_25437

   * PR #25604: (terminalmage) Move patching of mock_open to within test @
     2015-07-22T16:53:55Z

     * ISSUE #25323: (terminalmage) unit.modules.tls_test fails with older
       mock | refs: #25604

   * PR #25609: (s0undt3ch) [2015.5] Update the bootstrap script to latest
     release v2015.07.22 @ 2015-07-22T16:28:52Z

     * ISSUE  #630:  (syphernl)  Allow  for an include statement in config
       files | refs: #25609

     * PR #627: (chjohnst) add saltversion grain | refs: #25609

   * PR #25603: (terminalmage) Add version_cmp  function  to  yumpkg.py  @
     2015-07-22T15:42:29Z

     * ISSUE #21912: (rvora) pkg.latest not updating the package on CentOS
       though yum reports an update available | refs: #25603

   * PR #25590: (garethgreenaway) 2015.5  scheduled  jobs  return  data  @
     2015-07-21T21:57:42Z

     * ISSUE  #25560:  (dennisjac)  scheduled  highstate runs don't return
       results to the job cache | refs: #25590

   * PR #25584: (rallytime)  Back-port  #24054  and  #25576  to  2015.5  @
     2015-07-21T21:16:38Z

     * PR  #25576:  (pcn)  s3fs breaks when fetching files from s3 | refs:
       #25584

     * PR #24054: (mgwilliams) s3.head: return useful data | refs: #25584

   * PR #25589: (jahamn) Fixes ssh_known_host not taking port into account
     @ 2015-07-21T21:15:06Z

     * ISSUE  #23626:  (mirko)  salt  state 'ssh_known_hosts' doesn't take
       'port' into account | refs: #25589

   * PR  #25573:  (EvaSDK)  Do  not  execute  bootstrap  script  twice   @
     2015-07-21T18:20:04Z

     * PR #25465: (EvaSDK) 2015.5.3 LXC module fixes | refs: #25573

   * PR   #25580:   (attiasr)  use  explicit  utf-8  decoding  (#25532)  @
     2015-07-21T15:40:49Z

     * ISSUE #25532: (attiasr) salt/modules/win_pkg.py list_pkgs is broken
       (encoding issues) | refs: #25556 #25580

   * PR  #25568:  (twangboy)  Fixed  win_useradd  module to add fullname @
     2015-07-21T14:30:25Z

     * ISSUE #25206: (jfindlay) fullname issues  with  user.add  state  on
       windows | refs: #25568

   * PR  #25561:  (twangboy)  Fixed  the  gem module to work on windows...
     without injection @ 2015-07-20T21:12:15Z

     * ISSUE #21041: (deuscapturus) state module gem.installed not working
       on Windows.  | refs: #25430 #25561 #25428

     * PR  #25428:  (twangboy)  Fixed  the gem module to work on windows |
       refs: #25561

   * PR   #25521:   (cachedout)   Fix   outputter   for    state.orch    @
     2015-07-20T19:30:14Z

   * PR  #25563:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-07-20T19:27:36Z

     * PR #25416: (cachedout) Fix broken keyword

   * PR #25559: (cachedout) Lint win_pkg @ 2015-07-20T17:46:29Z

   * PR #25556: (attiasr) fix for #25532 @ 2015-07-20T17:45:11Z

     * ISSUE #25532: (attiasr) salt/modules/win_pkg.py list_pkgs is broken
       (encoding issues) | refs: #25556 #25580

   * PR   #25554:   (jfindlay)   verify_ssl=True   for  s3  ext  pillar  @
     2015-07-20T17:43:38Z

     * ISSUE #25538: (stanislavb)  S3  ext_pillar  configuration  requires
       verify_ssl | refs: #25554

   * PR    #25551:    (rallytime)    Backport    #25530    to   2015.5   @
     2015-07-20T17:43:00Z

     * PR #25530: (andre-luiz-dos-santos) The variable name must be last |
       refs: #25551

   * PR   #25533:   (attiasr)   port   445   for  windows  bootstraping  @
     2015-07-20T15:13:06Z

   * PR #25525: (gtmanfred) add make _prepare an alias  for  postinitio  @
     2015-07-20T15:12:38Z

     * ISSUE   #25432:   (gtmanfred)   [2015.5.3][raet]  raet  error  with
       SaltRaetRoadStackJoiner | refs: #25525

   * PR #25519: (rallytime) Backport vmware  driver  to  2015.5  branch  @
     2015-07-20T15:11:26Z

     * ISSUE  #25511: (rallytime) Make provider --> driver change backward
       compatible | refs: #25519 #25519

     * ISSUE #23574: (CedNantes) Failed to Deploy  Salt-Minion  on  a  Win
       2012  R2  using  wmware  Cloud  Driver  from Develop branch | refs:
       #25519

   * PR #25542:  (Oro)  Fix  hipchat.send_message  when  using  API  v2  @
     2015-07-20T15:09:13Z

   * PR    #25531:    (rallytime)    Back-port    #25529   to   2015.5   @
     2015-07-18T19:16:10Z

     * PR #25529: (davidjb) Fix minor typo  in  best  practice  example  |
       refs: #25531

   * PR   #25528:   (davidjb)  Fix  typo  in  extend  declaration  doco  @
     2015-07-18T14:22:06Z

   * PR   #25517:   (rallytime)   Back-port    #25486    to    2015.5    @
     2015-07-17T21:49:26Z

     * ISSUE   #25486:   (whiteinge)  Highstate  outputter  not  used  for
       state.apply | refs: #25517

     * PR #25485: (attiasr) fix file downloads on windows

   * PR   #25516:   (rallytime)   Back-port    #25483    to    2015.5    @
     2015-07-17T21:49:05Z

     * ISSUE #25479: (alexandrsushko) multiple mount.mounted of one device
       | refs: #25483

     * PR #25483: (alexandrsushko) Added 'none' to the set of  specialFSes
       | refs: #25516

   * PR  #25513:  (garethgreenaway) fixes to schedule.add documentation in
     2015.5 @ 2015-07-17T17:03:24Z

     * ISSUE #25493: (blackduckx)  Issue  with  job_args  on  schedule.add
       command | refs: #25513

   * PR  #25465:  (EvaSDK)  2015.5.3  LXC  module  fixes  | refs: #25573 @
     2015-07-17T15:57:54Z

   * PR #25506: (s0undt3ch) [2015.5] Update  bootstrap  script  to  latest
     stable release, v2015.07.17 @ 2015-07-17T15:40:38Z

     * ISSUE  #25456:  (julienlavergne) [2015.8.0rc1] salt-bootstrap fails
       to install salt master | refs: #25506

     * ISSUE #25270: (iggy) [2015.8.0rc1] salt-bootstrap fails to properly
       install a minion | refs: #25506

     * ISSUE  #625:  (whiteinge)  cmd.run state user flag is not working |
       refs: #25506 #632

     * ISSUE  #611:  (fatbox)  Peer  interface  fails   to   return   data
       occasionally | refs: #25506

     * ISSUE #607: (thatch45) next level -X support | refs: #25506

     * ISSUE  #598:  (syphernl)  Explanation on how to execute interactive
       installs | refs: #25506

     * ISSUE #455: (whiteinge)  Document  common  troubleshooting  tips  |
       refs: #25506

     * PR  #624: (chjohnst) Docs are not correct with network.ping as args
       are not supported | refs: #25506

     * PR #621: (akoumjian) Adding ec2 cloud-init bootstrap docs  |  refs:
       #25506

     * PR  #606:  (terminalmage) need empty line before code blocks. added
       ones that were missing.  | refs: #25506

     * PR #602: (terminalmage) State-related documentation changes | refs:
       #25506

   * PR  #25498:  (jfindlay)  only  read  /proc/1/cmdline  if  it exists @
     2015-07-17T15:35:33Z

     * ISSUE #25454: (mschiff) Regression:  salt  2015.5  not  working  in
       secure chroot anymore.  | refs: #25498

   * PR    #25487:    (rallytime)    Back-port    #25464   to   2015.5   @
     2015-07-16T16:58:36Z

     * PR #25464: (jquast) docfix: "cache_jobs:  False"  =>  grains_cache:
       False" | refs: #25487

   * PR   #25482:  (oeuftete)  Fix  docker.running  detection  of  running
     container @ 2015-07-16T16:58:29Z

     * PR #2015: (thekuffs) Esky / bbfreeze support

   * PR  #25468:  (joejulian)  Add  support  for  pyOpenSSL   >   0.10   @
     2015-07-16T15:10:30Z

     * ISSUE  #25384:  (rickh563)  pyopenssl  0.14 requirement in 2015.5.3
       does not work in RHEL6 : ZD-364 | refs: #25468

   * PR #25467: (rallytime) Add  lxml  dependency  to  opennebula  docs  @
     2015-07-16T15:09:57Z

   * PR #25461: (jahamn) Update file, if force option and content not same
     @ 2015-07-15T20:15:07Z

     * ISSUE #25250: (wipfs) 'force' option in copy state  deletes  target
       file | refs: #25461 #25710

     * ISSUE  #24647:  (nmadhok)  salt.states.file.copy  does not copy the
       file if it already exists with force=True | refs: #25461

   * PR #25438: (rallytime) Reduce digital_ocean_v2 API call  frequency  @
     2015-07-15T19:40:18Z

     * ISSUE  #25431:  (namcois)  Digital  Ocean  v2 reducing API calls by
       adding per_page | refs: #25438

   * PR #25457: (jacksontj) Saltnado @ 2015-07-15T17:50:12Z

     * PR #25427: (tony-cocco) Saltnado runner client results in  blocking
       call despite being set-up as Runner.async | refs: #25457

   * PR   #25459:   (jahamn)   Fixed   'defulats'   typo  in  verify.py  @
     2015-07-15T16:53:06Z

   * PR #25426: (jquast) bugfix: trailing  "...done"  in  rabbitmq  output
     (backport from 'develop' to 2015.5) @ 2015-07-15T14:48:05Z

   * PR   #25433:   (jleroy)   Support   for   IPv6  addresses  scopes  in
     network.interfaces (ifconfig) @ 2015-07-15T14:44:09Z

     * PR  #25151:  (jleroy)  Support  for  IPv6   addresses   scopes   in
       network.interfaces | refs: #25274 #25433

   * PR  #25430:  (twangboy) Disabled rbenv execution module for Windows @
     2015-07-15T14:41:18Z

     * ISSUE #21041: (deuscapturus) state module gem.installed not working
       on Windows.  | refs: #25430 #25561 #25428

   * c4b1584 Additional test case for question raised in #1846

     * ISSUE #1846: (seanchannel) development dependencies

   * PR  #25420:  (techhat)  Move  S3  to  use  AWS  Signature Version 4 @
     2015-07-14T22:03:09Z

   * PR #25418: (twangboy) Fixed problem  with  file.managed  test=True  @
     2015-07-14T21:26:59Z

     * ISSUE  #20441:  (deuscapturus) State module file.managed returns an
       error on Windows and test=Test | refs: #25418

   * PR #25417: (ahus1) extended documentation about dependencies for  dig
     module @ 2015-07-14T20:49:51Z

   * PR  #25411:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-07-14T17:55:26Z

     * PR #25375: (cachedout) Fix error in config.py for master_type

     * PR #25324: (jacobhammons) Latest help theme updates

   * PR #25406:  (anlutro)  Force  arguments  to  aptpkg.version_cmp  into
     strings @ 2015-07-14T16:15:41Z

   * PR    #25408:    (rallytime)    Back-port    #25399   to   2015.5   @
     2015-07-14T16:09:06Z

     * PR #25399: (jarpy)  Demonstrate  per-minion  client_acl.   |  refs:
       #25408

   * PR  #25240:  (tankywoo)  file  make  os.walk  only  be  called  one @
     2015-07-14T16:04:49Z

   * PR   #25395:   (rallytime)   Back-port    #25389    to    2015.5    @
     2015-07-14T03:26:34Z

     * PR  #25389: (l2ol33rt) Adding entropy note for gpg renderer | refs:
       #25395

   * PR   #25392:   (rallytime)   Back-port    #25256    to    2015.5    @
     2015-07-14T03:25:13Z

     * PR  #25256:  (yanatan16)  Don't  assume  source_hash exists | refs:
       #25392

   * PR #25398: (twangboy) Fix date @ 2015-07-14T03:21:17Z

   * PR #25397: (GideonRed) Introduce standard error output when cli exits
     with non-zero status @ 2015-07-14T03:20:24Z

   * PR #25386: (cachedout) Lint #25383 @ 2015-07-13T21:01:10Z

     * ISSUE  #24444:  (michaelkrupp)  file.managed  does  not handle dead
       symlinks | refs: #25383

     * PR    #25383:    (jahamn)    Fix    manage_file     function     in
       salt/modules/file.py to handle broken sym...

   * PR  #25383: (jahamn) Fix manage_file function in salt/modules/file.py
     to handle broken sym... @ 2015-07-13T20:58:23Z

     * ISSUE #24444: (michaelkrupp)  file.managed  does  not  handle  dead
       symlinks | refs: #25383

   * PR #25369: (anlutro) Fix aptpkg.version_cmp @ 2015-07-13T20:18:45Z

   * PR   #25379:   (jfindlay)   check   for   cwd  before  getting  it  @
     2015-07-13T19:50:27Z

     * ISSUE #25337: (eliasp) salt-call from non-existend cwd backtraces |
       refs: #25379

   * PR  #25334:  (jfindlay)  return  all  cmd  info  back to zypper fcn @
     2015-07-13T17:03:29Z

     * ISSUE #25320: (podloucky-init) zypper module  list_upgrades  broken
       (2015.5.2) | refs: #25334

   * PR     #25339:     (jfindlay)    update    orchestration    docs    @
     2015-07-13T16:04:26Z

   * PR #25358: (dkiser) Deep merge of  pillar  lists  |  refs:  #26016  @
     2015-07-13T15:51:01Z

     * ISSUE  #22241: (masterkorp) Salt master not properly generating the
       map | refs: #25358

   * PR #25346: (bechtoldt) set correct indention in states/requisites.rst
     (docs), fixes #25281 @ 2015-07-13T15:34:45Z

     * ISSUE  #25281:  (shinshenjs)  Unless  usage  in Official Doc syntax
       error?

   * PR #25336: (terminalmage) Don't try to read init binary if it  wasn't
     found @ 2015-07-13T09:45:30Z

   * PR  #25350:  (davidjb)  Fix  documentation  for  file.blockreplace  @
     2015-07-13T03:41:20Z

   * PR   #25326:   (rallytime)   Back-port    #20972    to    2015.5    @
     2015-07-10T18:49:44Z

     * ISSUE  #19288:  (oba11)  AssociatePublicIpAddress doesn't work with
       salt-cloud 2014.7.0 | refs: #20972 #25326

     * PR  #20972:  (JohannesEbke)  Fix  interface  cleanup   when   using
       AssociatePublicIpAddress in #19288 | refs: #25326

   * PR    #25327:    (rallytime)    Back-port    #25290   to   2015.5   @
     2015-07-10T18:49:37Z

     * ISSUE #24433: (chrimi) Salt locale state fails, if locale  has  not
       been generated | refs: #25290

     * PR  #25290:  (pcdummy)  Simple fix for locale.present on Ubuntu.  |
       refs: #25327

   * PR   #25328:   (rallytime)   Back-port    #25309    to    2015.5    @
     2015-07-10T17:22:59Z

     * ISSUE #24827: (yermulnik) locale.present doesn't generate locales |
       refs: #25309

     * PR  #25309:   (davidjb)   Format   /etc/locale.gen   correctly   in
       salt.modules.localemod.gen_locale | refs: #25328

   * PR    #25322:   (jacobhammons)   version   change   to   2015.5.3   @
     2015-07-10T16:11:24Z

   * PR #25308: (jacksontj) Make clear  commands  trace  level  logging  @
     2015-07-10T14:20:06Z

     * PR  #24737:  (jacksontj)  Move AES command logging to trace | refs:
       #25308

   * PR   #25269:   (jfindlay)    Extract    tomcat    war    version    @
     2015-07-10T01:28:21Z

     * ISSUE  #24520:  (nvx) Tomcat module fails to extract version number
       from snapshot builds (2015.5 regression) | refs: #24927

     * PR #24927: (egarbi) Tomcat module fails to extract  version  number
       from snapshot builds #2... | refs: #25269

   * PR    #25238:    (DmitryKuzmenko)   Pillarenv   backport   2015.5   @
     2015-07-10T01:25:07Z

     * ISSUE #18808: (amendlik) Add command line argument to select pillar
       environment | refs: #25238

     * PR #23719: (DmitryKuzmenko) Support pillarenv cmdline in state.sls

   * PR  #25299:  (twangboy)  Added  -NonInteractive so powershell doesn't
     hang waiting for input @ 2015-07-09T21:00:16Z

     * ISSUE #13943: (Supermathie) Powershell commands that  expect  input
       hang forever | refs: #25299

   * PR #25301: (jacobhammons) bug fix for module function display in help
     @ 2015-07-09T20:46:34Z

   * PR #25279: (jacobhammons) Additional docs on external and master  job
     cache, assorted doc fixes @ 2015-07-09T16:46:26Z

     * ISSUE  #25277: (jacobhammons) CherryPy recommended versions | refs:
       #25279

   * PR #25274: (jleroy) Fix for issue #25268 @ 2015-07-09T13:36:26Z

     * ISSUE  #25268:  (lichtamberg)   Salt   not   working   anymore   in
       2015.8/develop: ValueError: 'scope' is not in list | refs: #25274

     * PR   #25151:   (jleroy)   Support  for  IPv6  addresses  scopes  in
       network.interfaces | refs: #25274 #25433

   * PR #25272: (twangboy) Fixed  problem  with  service  not  starting  @
     2015-07-08T23:29:48Z

   * PR  #25225:  (nmadhok)  Backporting  fix  for  issue #25223 on 2015.5
     branch @ 2015-07-08T15:16:18Z

     * ISSUE  #25223:  (nmadhok)  Runner   occasionally   fails   with   a
       RuntimeError when fired by a reactor | refs: #25225

   * PR  #25214: (rallytime) A couple of doc fixes for the http tutorial @
     2015-07-07T22:23:07Z

   * PR #25194: (rallytime) Update moto version check in boto_vpc_test and
     update min version @ 2015-07-07T18:27:32Z

     * ISSUE  #24272:  (rallytime)  Fix boto_vpc_test moto version check |
       refs: #25194

   * PR    #25205:    (basepi)    Update    releasecandidate    docs     @
     2015-07-07T15:25:24Z

   * PR   #25187:   (UtahDave)  Doc  fixes:  Fix  misspelling  and  remove
     extraneous double spaces @ 2015-07-07T01:07:04Z

   * PR  #25182:  (cachedout)  Try  to  re-pack  long  floats  as  strs  @
     2015-07-07T01:06:43Z

   * PR    #25185:    (rallytime)    Back-port    #25128   to   2015.5   @
     2015-07-07T00:58:00Z

     * ISSUE  #23822:  (sidcarter)  Zip  file  extracted  permissions  are
       incorrect | refs: #25128

     * PR  #25128:  (stanislavb)  Use  cmd_unzip to preserve permissions |
       refs: #25185

   * PR   #25181:   (rallytime)   Back-port    #25102    to    2015.5    @
     2015-07-07T00:57:13Z

     * PR #25102: (derBroBro) Update win_network.py | refs: #25181

   * PR    #25179:    (rallytime)    Back-port    #25059   to   2015.5   @
     2015-07-07T00:56:44Z

     * ISSUE #24301: (iggy)  influxdb_user  and  influxdb_database  states
       need virtual functions | refs: #25059

     * PR  #25059:  (babilen)  Add  virtual  functions  to  influxdb state
       modules | refs: #25179

   * PR #25196: (twangboy) Fixed #18919 false-positive  on  pkg.refresh  @
     2015-07-07T00:24:13Z

     * ISSUE    #18919:    (giner)    Windows:    pkg.refresh_db   returns
       false-positive success | refs: #25196

   * PR   #25180:   (rallytime)   Back-port    #25088    to    2015.5    @
     2015-07-06T20:33:45Z

     * PR #25088: (supertom) Update | refs: #25180

   * PR  #25191:  (basepi)  Add  extrndest back to fileclient.is_cached in
     2015.5 @ 2015-07-06T19:35:24Z

     * PR #25117: (basepi) Fix fileclient.is_cached | refs: #25191

   * PR   #25175:   (rallytime)   Back-port    #25020    to    2015.5    @
     2015-07-06T18:53:19Z

     * ISSUE  #25016:  (martinhoefling)  salt-run doc.execution fails with
       AttributeError

     * PR #25020: (martinhoefling) Fix for issue #25016 | refs: #25175

   * PR   #25173:   (rallytime)   Partial   back-port    of    #25019    @
     2015-07-06T18:52:59Z

     * ISSUE  #21879:  (bechtoldt)  Reference  pages  in documentation are
       outdated again | refs: #25019

     * ISSUE #19262: (bechtoldt) salt.pillar.file_tree doesn't  appear  in
       the documentation | refs: #25019

     * PR   #25019:   (bechtoldt)  add  missing  module  documentation  to
       references | refs: #25173

     * PR #24421: (bechtoldt) add missing  module  documentation  |  refs:
       #25019

     * PR  #21880:  (bechtoldt)  update  references,  fixes #21879 | refs:
       #25019

     * PR #20039: (bechtoldt)  completing  some  doc  references  |  refs:
       #25019

   * PR    #25171:    (rallytime)    Back-port    #25001   to   2015.5   @
     2015-07-06T18:51:53Z

     * PR   #25001:   (jasonkeene)   Add   docs    for    key    arg    in
       ssh_known_hosts.present | refs: #25171

   * PR    #25170:    (rallytime)    Back-port    #24982   to   2015.5   @
     2015-07-06T16:34:43Z

     * PR #24982: (asyncsrc) ec2 network_interfaces fix | refs: #25170

   * PR #25161: (aneeshusa)  Allow  checking  for  non-normalized  systemd
     units.  @ 2015-07-06T15:15:31Z

   * PR   #25151:   (jleroy)   Support   for   IPv6  addresses  scopes  in
     network.interfaces | refs: #25274 #25433 @ 2015-07-06T14:43:03Z

   * PR #25166: (cachedout) Lint #25149 @ 2015-07-06T14:40:29Z

     * ISSUE #24979: (mavenAtHouzz) [Discussion] Support for more  than  1
       netapi.rest_tornado server process | refs: #25149

     * PR #25149: (jacksontj) Saltnado multiprocess support | refs: #25166

   * PR #25149: (jacksontj) Saltnado multiprocess support | refs: #25166 @
     2015-07-06T14:38:43Z

     * ISSUE #24979: (mavenAtHouzz) [Discussion] Support for more  than  1
       netapi.rest_tornado server process | refs: #25149

   * PR   #25120:  (d--j)  add  missing  continue  for  exception  case  @
     2015-07-02T19:38:45Z

   * PR  #25117:  (basepi)  Fix  fileclient.is_cached  |  refs:  #25191  @
     2015-07-02T19:38:26Z

   * PR  #25087:  (0xf10e)  Fix execution module for glance - now based on
     2015.5!  @ 2015-07-02T19:36:27Z

   * PR #25129: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-07-02T17:37:40Z

     * ISSUE #18447: (ryan-lane) Can't install salt with raet using pip -e
       git

     * PR #25093: (jaybocc2) quick fix for issue #18447

     * PR  #25069:  (puneetk)  Add  a  helper   module   function   called
       list_enabled

   * PR #25114: (jfindlay) Revert "Revert "adding states/postgres_database
     unit test case.""  @ 2015-07-02T01:01:29Z

     * PR #24798: (jtand)  Revert  "adding  states/postgres_database  unit
       test case."  | refs: #25114

     * PR  #24329:  (jayeshka)  adding  states/postgres_database unit test
       case.  | refs: #24798

   * PR #24362: (jayeshka) adding states/postgres_user unit test case.   @
     2015-07-01T21:45:31Z

   * PR  #24361:  (jayeshka) adding states/postgres_schema unit test case.
     @ 2015-07-01T21:44:56Z

   * PR #24331:  (jayeshka)  adding  states/postgres_extension  unit  test
     case.  @ 2015-07-01T21:43:58Z

   Salt 2015.5.5 Release Notes
   Version 2015.5.5 is a bugfix release for 2015.5.0.

   Changes:

   * The  cron.present  state  now  correctly  defaults  to  state  ID  as
     identifier.

   * When querying for VMs in ditigal_ocean_v2.py, the number  of  VMs  to
     include  in a page was changed from 20 (default) to 200 to reduce the
     number of API calls to Digital Ocean.

   * The vmware Salt-Cloud driver was back-ported from the develop  branch
     in order for installations of Salt that are older than 2015.8.0 to be
     able to use  the  vmware  driver  without  stack-tracing  on  various
     deprecation paths that were implemented in the 2015.8.0 release.

   Changes for v2015.5.3..v2015.5.5
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-08-20T17:02:37Z

   Statistics:

   * Total Merges: 280

   * Total Issue references: 168

   * Total PR references: 371

   Changes:

   * PR #26292: (jquast) Rabbitmq 3.2.4  on  Ubuntu  has  "...done.",  not
     "...done" @ 2015-08-13T19:53:29Z

   * PR #26296: (jquast) bugfix missing
     `
     runas=None'   for   rabbitmqctl   cmds   (backport   to   2015.5)   @
     2015-08-13T19:52:40Z

   * PR #26293: (jfindlay) Fix #26268 @ 2015-08-13T19:48:06Z

     * ISSUE #25618: (twangboy) Fix  reg.py  to  work  with  the  registry
       properly | refs: #26268

     * PR #26268: (twangboy) Multiple improvements to reg executionmod and
       state mod | refs: #26293

   * PR #26290: (rallytime) Only call convert_to_arn when action  name  is
     provided @ 2015-08-13T18:48:58Z

     * ISSUE #25192: (deuscapturus) 2015.5.2 boto_cloudwatch_alarm.present
       not working.  | refs: #26290

   * PR #26288: (bbinet) allow deleting grains  which  value  is  False  @
     2015-08-13T18:24:36Z

   * PR   #26263:  (rallytime)  Don't  make  changes  when  test=True  for
     openstack present/absent funcs @ 2015-08-13T16:30:31Z

     * ISSUE #24882:  (nmadhok)  salt.states.openstack_config.present  and
       salt.states.openstack_config.absent  make  changes when test=True |
       refs: #26263

   * PR  #26265:  (rallytime)  Don't  stacktrace  on   query   return   in
     ec2.create_snapshot @ 2015-08-13T16:28:48Z

     * ISSUE  #24484:  (codehotter)  clouds/ec2.py: create_snapshot throws
       exception | refs: #26265

   * PR  #26285:  (stanislavb)  Remove  explicit  version  from   instance
     identity URL @ 2015-08-13T16:25:32Z

   * PR  #26275:  (cachedout)  Re-init modules on multi-master reconnect @
     2015-08-13T15:52:50Z

   * PR #26273: (garethgreenaway) Fixes to schedule  module  in  2015.5  @
     2015-08-13T15:34:43Z

   * PR    #26271:    (rallytime)    Fix    del_root_vol_on_destroy    and
     del_all_vols_on_destroy functionality on ec2 @ 2015-08-12T23:22:47Z

     * ISSUE #24483: (codehotter)  clouds/ec2.py:  del_root_vol_on_destroy
       and del_all_vols_on_destroy not working | refs: #26271

   * PR  #26219:  (anlutro)  cron:  make  identifier default to state ID @
     2015-08-12T18:42:33Z

     * ISSUE #25958: (anlutro) Cron identifier does not default  to  state
       ID as documented | refs: #26219

   * PR    #26257:    (rallytime)    Back-port    #26237   to   2015.5   @
     2015-08-12T18:40:35Z

     * ISSUE #26207: (fullermd) group members setting fails  with  obscure
       error message on FreeBSD | refs: #26237

     * PR #26237: (silenius) fix issue #26207 | refs: #26257

   * PR  #26258:  (nmadhok)  Fix permission on tests/runtests.py on 2015.5
     branch @ 2015-08-12T18:40:04Z

   * PR #26261: (nmadhok)  Correct  spelling  of  integration  in  docs  @
     2015-08-12T18:14:48Z

     * PR #2015: (thekuffs) Esky / bbfreeze support

   * PR  #26247:  (nmadhok)  Initial commit of unit tests for vmware cloud
     driver @ 2015-08-12T16:58:24Z

   * PR #26246: (nmadhok) Backport additions to VMware cloud  driver  from
     develop to 2015.5 branch @ 2015-08-12T15:11:26Z

   * PR  #26239:  (opdude)  Fixed  documentation  to match function name @
     2015-08-12T14:48:52Z

   * PR #26232: (garethgreenaway) Fix  to  trust_key  in  gpg  module  for
     2015.5.  @ 2015-08-12T04:48:27Z

   * PR  #26084:  (twangboy)  Added python_shell=True, quoted user input @
     2015-08-10T21:29:35Z

     * ISSUE #25802:  (jefftucker)  Running  module  "npm.list"  fails  on
       Windows for masterless minion | refs: #26084

   * PR    #26183:    (cro)    Fix    LDAP    configuration    issue.    @
     2015-08-10T19:09:41Z

   * PR    #26186:    (jacobhammons)    regenerated    man     pages     @
     2015-08-10T19:07:44Z

   * PR  #26182:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-08-10T19:00:10Z

     * ISSUE           #25961:            (getabc)            [2015.5.3-2]
       salt-winrepo.git/salt-minion.sls fails certificate '
       *
       .wpengine.com' or 'wpengine.com' | refs: #26047

     * ISSUE  #25751:  (basepi)  Document master_finger more prominently |
       refs: #26088

     * PR #26116: (corux) file.replace fails if repl string is an  invalid
       regex and append/prepend is used

     * PR #26088: (jacobhammons) Master finger

     * PR  #26047:  (jacobhammons)  Updated  windows download links in the
       docs to https://repo.saltstack.com

   * PR #26000: (driskell) Implement full  event  caching  for  subscribed
     tags @ 2015-08-10T18:57:17Z

     * ISSUE #25998: (driskell) Event subsystem discarding required events
       during --batch breaking it for slow running commands | refs: #26000

   * PR   #26175:   (rallytime)   Back-port    #26153    to    2015.5    @
     2015-08-10T18:22:32Z

     * PR  #26153:  (loa)  Fix  dockerio  state documentation typo | refs:
       #26175

   * PR   #26177:   (rallytime)   Back-port    #26147    to    2015.5    @
     2015-08-10T18:22:01Z

     * ISSUE #26024: (jpic) lxc_conf_unset in cloud.profile is ignored

     * PR #26147: (martinhoefling) Fixes #26024 | refs: #26177

   * PR    #26179:    (rallytime)    Back-port    #25404   to   2015.5   @
     2015-08-10T18:21:50Z

     * ISSUE #21082: (clinta) master_type failover does  not  failover  on
       DNS errors | refs: #25404

     * PR #25404: (DmitryKuzmenko) Fixed minion failover to next master on
       DNS errors.  | refs: #26179

   * PR  #26180:   (jfindlay)   fix   processing   of   state.template   @
     2015-08-10T18:21:38Z

     * ISSUE  #26112:  (wt)  state.template  fails with unclear error with
       template with only an include | refs: #26180

   * PR #26172: (nmadhok) [Backport] Make sure variable  is  a  dictionary
     before popping something from it.  @ 2015-08-10T16:42:50Z

     * ISSUE #26162: (nmadhok) VMware cloud driver create function failing
       with traceback on latest develop | refs: #26163 #26172

     * PR #26163: (nmadhok) Make sure  variable  is  a  dictionary  before
       popping something from it.

   * PR #26168: (cachedout) Fix slack docs @ 2015-08-10T14:57:18Z

     * ISSUE #26098: (rdinoff) SALT.STATES.SLACK Doc update | refs: #26168

   * PR  #26127:  (garethgreenaway)  Fixes  to  salt.utils.http related to
     cp.get_file_str bug.  @ 2015-08-10T14:38:25Z

     * ISSUE #24106: (nvx) fileclient.py#get_url ignores HTTP  Auth  again
       (2015.5 regression) | refs: #26127

   * PR #26140: (nmadhok) VMware cloud driver fixes @ 2015-08-10T13:15:58Z

     * ISSUE  #26141:  (nmadhok) salt-cloud VMware driver fails with error
       in parsing configuration file | refs: #26140

     * ISSUE #25809: (o-sleep) vmware cloud module error message  |  refs:
       #26140

     * ISSUE  #25625:  (steverweber)  cloud vmware driver does not provide
       mac_address unless vmware tools is running | refs: #26137 #26140

   * PR #26137: (steverweber) use device mac address if vmtools not active
     @ 2015-08-09T03:05:36Z

     * ISSUE  #25625:  (steverweber)  cloud vmware driver does not provide
       mac_address unless vmware tools is running | refs: #26137 #26140

   * PR   #26119:   (jodv)   Backport   eauth   bugfix   to    2015.5    @
     2015-08-09T02:19:52Z

   * PR #26135: (cro) Fix proxy minions in 2015.5 and significantly update
     documentation.  @ 2015-08-09T02:19:21Z

   * PR #26132: (TheBigBear) minor edit @ 2015-08-08T21:05:34Z

   * PR #26133: (amontalban) Fixed  #25915  in  salt/modules/pkgng.py  and
     salt/states/pkg.py @ 2015-08-08T21:05:05Z

     * ISSUE #25915: (ari) FreeBSD pkg install fails

   * PR  #26111:  (anlutro) Better error messages when virtualenv creation
     fails @ 2015-08-07T21:42:09Z

   * PR #26110: (jfindlay) check for sources before adding them to cmd str
     @ 2015-08-07T21:33:23Z

     * ISSUE #26093: (freedba) archive.tar bug | refs: #26110

   * PR #26106: (vr-jack) Update __init__.py @ 2015-08-07T21:15:55Z

   * PR    #26101:    (rallytime)    Back-port    #25984   to   2015.5   @
     2015-08-07T18:56:26Z

     * ISSUE #25983: (jmdcal) Trying to get  md5  of  local  zip  |  refs:
       #25984

     * PR  #25984:  (jmdcal)  Support  local  files without md5sum | refs:
       #26101

   * PR   #26080:   (techhat)   Fix   string   checking    in    s3fs    @
     2015-08-06T23:36:09Z

   * PR   #26079:   (cachedout)   Update   docs  to  remove  state.over  @
     2015-08-06T23:35:26Z

     * ISSUE #26039: (basepi) Update scheduler  docs  to  use  orchestrate
       instead of overstate | refs: #26079

   * PR  #26058:  (opdude)  Fix choco version on chocolatey versions below
     0.9.9 @ 2015-08-06T18:50:10Z

   * PR #26068: (jfindlay) fix autoruns.list looking in wrong directory  @
     2015-08-06T18:49:48Z

   * PR  #26065:  (s0undt3ch)  [2015.5]  Update to latest bootstrap stable
     release v2015.06.08 @ 2015-08-06T17:09:35Z

     * ISSUE #634: (loupgaroublond) /srv/salt/_grains/  not  documented  |
       refs: #26065

     * ISSUE  #631:  (fatbox)  Can't extend the same item multiple times |
       refs: #26065

     * ISSUE #625: (whiteinge) cmd.run state user flag is  not  working  |
       refs: #25506 #632

     * PR  #640: (terminalmage) fix syntax errors introduced in 0f776c13 |
       refs: #26065

     * PR   #638:   (blast-hardcheese)    Tightened    up    configuration
       documentation | refs: #26065

     * PR #633: (epoelke) Bug fix to salt-key | refs: #26065

     * PR  #632: (whiteinge) Change the cmd.run state to use the new runas
       arg | refs: #26065

   * PR   #26061:    (gmcwhistler)    Patch    for    issue    #25994    @
     2015-08-06T17:07:34Z

     * ISSUE   #25994:   (gmcwhistler)  module.ilo  tempfile  creation  in
       __execute_cmd results in TypeError: cannot  concatenate  'str'  and
       'int' objects

   * PR  #26064:  (s0undt3ch)  Don't  stacktrace  when  trying  to get the
     default locale.  @ 2015-08-06T16:11:05Z

     * ISSUE #26063: (saltstack-bot) not  working  with  salt-cloud  shows
       unknown locale error | refs: #26064

   * PR  #26048: (jacobhammons) Updated windows download links in the docs
     to https://repo.saltstack.com @ 2015-08-05T22:59:50Z

   * PR #26044: (rallytime) Make sure the  key  we're  comparing  is  also
     lowercase @ 2015-08-05T19:23:54Z

     * ISSUE #25616: (rallytime) [2015.5] Provisioning Linodes Stacktraces
       | refs: #26044

   * PR  #26042:  (jfindlay)  fix  test  mode  logic  in  state   docs   @
     2015-08-05T19:23:07Z

   * PR #26036: (nicholascapo) survey.hash: Remove manually printed text @
     2015-08-05T19:21:59Z

     * ISSUE #24460: (nicholascapo) Survey runner does  not  follow  --out
       flag | refs: #26036

   * PR #26030: (opdude) Fix a bug in choco version that returned odd data
     @ 2015-08-05T16:30:25Z

   * PR  #26032:  (jfindlay)  add  test  logic  to  state  reult   doc   @
     2015-08-05T16:28:32Z

   * PR  #26031:  (alekti) Revert "Add file as supported protocol for file
     source_hash. Fixes #23764" @ 2015-08-05T15:32:01Z

     * ISSUE #23764: (es1o) source_hash from local file is not  supported.
       | refs: #25750

   * PR   #26021:   (anlutro)   Documentation:  Specify  versionadded  for
     git.present shared argument @ 2015-08-05T14:17:38Z

   * PR #26020: (alekti) Correctly resolve conflict merging pull 25750  to
     2015.5 @ 2015-08-05T14:16:58Z

     * ISSUE  #23764: (es1o) source_hash from local file is not supported.
       | refs: #25750

     * PR #25750:  (alekti)  Add  file  as  supported  protocol  for  file
       source_hash. Fixes #25701.  | refs: #26020

   * PR   #26016:   (basepi)   Revert  "Deep  merge  of  pillar  lists"  @
     2015-08-05T04:59:52Z

     * ISSUE #22241: (masterkorp) Salt master not properly generating  the
       map | refs: #25358

     * PR #25358: (dkiser) Deep merge of pillar lists | refs: #26016

   * PR #25992: (twangboy) Refactor win_system.py @ 2015-08-05T04:54:18Z

     * ISSUE   #12255:   (eliasp)  'system.set_computer_desc'  fails  with
       non-ASCII chars | refs: #25992

     * ISSUE #3: (thatch45) libvirt module

   * PR #26002: (twangboy) Fixed regex to account  for  comment  character
     followed by whitespace @ 2015-08-04T22:28:11Z

     * ISSUE  #25948: (twangboy) Fix uncomment function to handle spaces |
       refs: #26002

   * PR  #25970:  (jfindlay)  accept  addition   of   layman   overlay   @
     2015-08-04T15:42:28Z

     * ISSUE  #25949: (godlike64) layman.add does not work with unofficial
       overlays | refs: #25970

   * PR #25971: (basepi) [2015.5] salt.modules.reg Add spaces for  strings
     split across multiple lines @ 2015-08-04T15:39:48Z

   * PR    #25990:    (rallytime)    Back-port    #25976   to   2015.5   @
     2015-08-04T14:36:53Z

     * PR #25976: (fleaflicker) Typo in help output | refs: #25990

   * PR   #25996:    (attiasr)    fix    msiexec    package    remove    @
     2015-08-04T14:36:31Z

   * PR    #25966:    (rallytime)    Back-port    #25864   to   2015.5   @
     2015-08-03T18:48:26Z

     * ISSUE #25863: (peterdemin) pkg.installed fails on already installed
       package if it is in versionlock.list | refs: #25864

     * PR  #25864:  (peterdemin)  #25863  state.pkg.installed  fix | refs:
       #25966

   * PR   #25967:   (rallytime)   Back-port    #25917    to    2015.5    @
     2015-08-03T18:48:02Z

     * PR #25917: (jmdcal) adding missing format string | refs: #25967

   * PR  #25895:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-08-03T17:12:37Z

     * ISSUE #23764: (es1o) source_hash from local file is not  supported.
       | refs: #25750

     * PR  #25750:  (alekti)  Add  file  as  supported  protocol  for file
       source_hash. Fixes #25701.  | refs: #26020

     * PR #25704: (cachedout) Ensure prior alignment with  master_type  in
       2014.7

     * PR #25657: (MrCitron) Add the ability to specify a base pattern for
       carbon returner

     * PR #25633: (AkhterAli) Update loader.py

   * PR  #25941:  (jfindlay)  add  timelib  to   dependency   versions   @
     2015-08-03T12:23:42Z

     * ISSUE #25850: (ssgward) Need to add packages to --versions-report |
       refs: #25941

   * PR   #25951:    (garethgreenaway)    Log    when    event.fire    and
     event.fire_master fail.  @ 2015-08-03T00:19:45Z

   * PR #25942: (jfindlay) typo in minion doc @ 2015-07-31T23:34:55Z

     * ISSUE  #25838: (grep4linux) docs disable_modules documentation typo
       | refs: #25942

   * PR #25938: (jacobhammons) Doc on  using  syndic  with  multimaster  @
     2015-07-31T23:05:05Z

     * PR #14690: (jacksontj) Multi syndic | refs: #25938

   * PR  #25848:  (twangboy)  Added  allusers="1"  when  installing  msi @
     2015-07-31T20:33:17Z

     * ISSUE #25839: (twangboy) ALLUSERS="1"  should  be  a  default  when
       installing MSI's | refs: #25848

   * PR   #25898:   (jfindlay)   clarify   and   expand   syndic   docs  @
     2015-07-31T20:01:23Z

   * PR  #25927:  (jacksontj)  Pass  actual  renderers  to  the  Reactor's
     Compiler @ 2015-07-31T20:00:17Z

     * ISSUE  #25852:  (UtahDave)  Salt loader is not loading Salt vars in
       reactor python renderer | refs: #25927

   * PR  #25921:   (cachedout)   Handle   non-ascii   in   state   log   @
     2015-07-31T17:41:30Z

     * ISSUE  #25810: (nvx) winpkg highstate fails when a new package name
       contains a unicide character | refs: #25921

   * PR #25919: (TheBigBear) Minor  update  to  msi  un-installer  info  @
     2015-07-31T17:39:48Z

   * PR    #25905:    (rallytime)    Back-port    #25982   to   2015.5   @
     2015-07-30T23:24:19Z

     * PR #25892: (TheBigBear) Update 7-zip msi un-installer  instructions
       | refs: #25905

   * PR    #25890:    (rallytime)    Back-port    #25698   to   2015.5   @
     2015-07-30T23:12:09Z

     * ISSUE #25577: (yellow1912) Wrong indentation in  document  |  refs:
       #25696

     * PR #25698: (rallytime) Back-port #25659 to 2015.8 | refs: #25890

     * PR #25696: (AkhterAli) Update schedule.py

     * PR  #25659:  (isbm)  Bugfix:  crash  at getting non-existing repo |
       refs: #25698

   * PR #25894: (jacobhammons) Minor doc bug fixes @ 2015-07-30T23:02:34Z

     * ISSUE #25650: (jacksontj) state.running documentation is  incorrect
       | refs: #25894

     * ISSUE   #24042:   (whiteinge)   The  state_events  setting  is  not
       documented | refs: #25894

     * ISSUE #23788: (k5jj) functions  in  drac.py  module  do  not  match
       documentation | refs: #25894

     * ISSUE  #21296:  (Lothiraldan)  Possible  minion  enumeration  using
       saltutil.find_job and eauth | refs: #25894

   * PR #25877: (rallytime) Protect against passing a map file in addition
     to VM names with --destroy @ 2015-07-30T21:55:45Z

     * ISSUE  #24036: (arthurlogilab) [salt-cloud] Protect against passing
       command line arguments as names for the --destroy  command  in  map
       files | refs: #25877

   * PR    #25870:    (rallytime)    Back-port    #25824   to   2015.5   @
     2015-07-30T21:54:35Z

     * PR #25824: (klyr) Fix get_managed() in  file.py  module  for  local
       files | refs: #25870

   * PR #25885: (t0rrant) Update Debian changelog @ 2015-07-30T20:05:59Z

   * PR    #25875:    (rallytime)    Back-port    #25862   to   2015.5   @
     2015-07-30T17:34:02Z

     * ISSUE #25478: (zyio) salt-ssh  -  Unable  to  locate  current  thin
       version | refs: #25862

     * ISSUE  #25026: (sylvia-wang) salt-ssh "Failure deploying thin" when
       using salt module functions | refs: #25862

     * PR #25862: (zyio) Adding SCP_NOT_FOUND exit code | refs: #25875

   * PR   #25873:   (rallytime)   Back-port    #25855    to    2015.5    @
     2015-07-30T17:33:55Z

     * PR #25855: (puneetk) Patch 3 | refs: #25873

   * PR    #25871:    (rallytime)    Back-port    #25829   to   2015.5   @
     2015-07-30T17:33:43Z

     * PR #25829: (peterdemin) Fixed typo in  salt.states.saltmod.function
       doc string | refs: #25871

   * PR    #25869:    (rallytime)    Back-port    #25788   to   2015.5   @
     2015-07-30T17:33:33Z

     * ISSUE #24002: (csakoda) File lock  contention  on  windows  minions
       causing highstate crash | refs: #25788

     * PR  #25788:  (opdude)  Catch a hard crash when running highstate on
       windows | refs: #25869

   * PR #25853: (davidjb) Make ssh-id-wrapper accessible to non-root users
     @ 2015-07-30T16:49:47Z

     * ISSUE  #19532: (stolendog) salt-ssh running git clone with not root
       user | refs: #25853

   * PR #25856: (jfindlay) expand minion reauth scalability  documentation
     @ 2015-07-30T15:33:17Z

     * ISSUE   #25447:  (spo0nman)  SaltMaster  is  crippled  with  Minion
       Re-Authentication | refs: #25856

   * PR #25840: (jfindlay) add note to winrepo state docs  about  required
     grain @ 2015-07-30T14:38:27Z

     * ISSUE  #25801:  (themalkolm)  Update  docs that salt.states.winrepo
       requires roles:salt-master in grains.  | refs: #25840

   * PR #25846: (jfindlay) rework deprecation  documentation  for  release
     names @ 2015-07-30T13:26:21Z

     * ISSUE  #25827: (0xf10e) "Deprecating Code" doesn't mention Usage of
       warn_until() w/ Release Names | refs: #25846

   * PR  #25833:  (jahamn)  Allows  cp.push  to  recreate  empty  files  @
     2015-07-29T16:14:48Z

     * ISSUE  #23288: (UtahDave) cp.push fails to recreate empty files.  |
       refs: #25833

   * PR #25831: (rallytime) Add salt:// to key_url  options  to  docs  for
     pkgrepo.managed @ 2015-07-29T15:38:43Z

     * ISSUE  #11474: (JensRantil) pkgrepo.managed key_url: salt:// always
       use base env | refs: #25831

   * PR #25807: (rallytime) Provide helpful error when using actions  with
     a mapfile @ 2015-07-29T15:30:15Z

     * ISSUE  #22699:  (arthurlogilab)  salt-cloud  fails on KeyError when
       given a nonexistent action | refs: #25807

   * PR #25818: (jfindlay) fix autoruns list @ 2015-07-29T15:29:20Z

   * PR  #25826:  (anlutro)  Check  that   "onchanges"   is   a   list   @
     2015-07-29T15:00:28Z

   * PR  #25798:  (twangboy)  Fixed stacktrace on package name not found @
     2015-07-28T22:40:14Z

     * ISSUE #25258: (nickw8) windows minion repo  not  updating  |  refs:
       #25798

   * PR  #25797:  (twangboy)  Changed  repocache  back  to  cached_repo  @
     2015-07-28T22:39:32Z

     * ISSUE #25437: (lorengordon)  Stacktrace  on  Windows  when  running
       pkg.list_pkgs | refs: #25598 #25763

     * PR #25763: (twangboy) Fix 25437 | refs: #25797

   * PR    #25793:    (rallytime)    Back-port    #25730   to   2015.5   @
     2015-07-28T19:37:34Z

     * PR #25730: (sjorge) patchelf lives in pkgsrc | refs: #25793

   * PR   #25792:   (rallytime)   Back-port    #25688    to    2015.5    @
     2015-07-28T19:37:17Z

     * PR  #25688: (bclermont) Don't acquire lock if there is no formatter
       | refs: #25792

   * PR #25796: (cachedout) Remove debug from docs @ 2015-07-28T17:35:59Z

   * PR  #25749:  (jahamn)  Allow  zpool.create  on  character  devices  @
     2015-07-28T16:01:40Z

     * ISSUE  #24920: (voileux) module.zpool.create on character device is
       not possible by salt | refs: #25749

   * PR #25685: (twangboy) Fixed regex issues with comment and uncomment @
     2015-07-28T15:29:49Z

   * PR #25763: (twangboy) Fix 25437 | refs: #25797 @ 2015-07-28T15:29:27Z

     * ISSUE  #25437:  (lorengordon)  Stacktrace  on  Windows when running
       pkg.list_pkgs | refs: #25598 #25763

   * PR #25752: (thatch45) State top saltenv @ 2015-07-28T01:02:10Z

   * PR #25755: (twangboy) Fixed problem with dunder functions  not  being
     passed @ 2015-07-27T19:31:22Z

     * ISSUE #25717: (twangboy) Problem with chocolatey module not loading
       | refs: #25755

   * PR #25648: (twangboy) Clarified functionality of  reg  module,  fixed
     state to work with new module @ 2015-07-27T19:30:33Z

     * ISSUE  #25352: (m03) reg.absent reporting incorrect results | refs:
       #25648

     * ISSUE #1: (thatch45) Enable regex on the salt cli

   * PR   #25740:   (rallytime)   Back-port    #25722    to    2015.5    @
     2015-07-27T16:08:40Z

     * ISSUE  #25154:  (uvsmtid)  All data mixed on STDOUT together should
       generate valid JSON output | refs: #25722

     * ISSUE #25153: (uvsmtid) Multiple results should generate valid JSON
       output | refs: #25722

     * PR  #25722:  (uvsmtid)  Minor docs changes to emphasize JSON output
       problems without --static option | refs: #25740

   * PR   #25739:   (rallytime)   Back-port    #25709    to    2015.5    @
     2015-07-27T16:08:27Z

     * PR     #25709:     (colekowalski)     add     direct-io-mode     to
       mount_invisible_options | refs: #25739

     * PR #25699: (rallytime) Back-port #25660 to 2015.5 | refs: #25709

     * PR  #25660:  (colekowalski)  add   glusterfs'   direct-io-mode   to
       mount_invisible_keys | refs: #25699 #25709

   * PR    #25738:    (rallytime)    Back-port    #25671   to   2015.5   @
     2015-07-27T16:08:23Z

     * PR #25671: (niq000) added a  parameter  so  verifying  SSL  is  now
       optional instead of hard-coded | refs: #25738

   * PR    #25737:    (rallytime)    Back-port    #25608   to   2015.5   @
     2015-07-27T16:08:18Z

     * ISSUE #25229: (rall0r) Module  git.latest  kills  target  directory
       when test=True | refs: #25608

     * PR  #25608: (rall0r) Fix: prevent git.latest from removing target |
       refs: #25737

   * PR #25733: (davidjb) Avoid IndexError when listing  mounts  if  mount
     output ends in newline @ 2015-07-27T16:08:05Z

   * PR   #25705:   (blackduckx)  Support  for  setm  augeas  command.   @
     2015-07-27T16:07:10Z

     * ISSUE #22460: (onmeac) Command setm is not supported (yet) |  refs:
       #25705

   * PR  #25703:  (cachedout)  Return  to str for master_type for 2015.5 @
     2015-07-27T16:06:22Z

   * PR #25702: (twangboy) Fixed win_user module for groups with spaces in
     the name @ 2015-07-27T15:06:33Z

     * ISSUE  #25144: (johnccfm) user.present on Windows fails to add user
       to groups if group name contains a space | refs: #25702

   * PR      #25711:       (twangboy)       Fixed       problem       with
     win_servermanager.list_installed @ 2015-07-27T15:05:48Z

     * ISSUE  #25351:  (m03) win_servermanager.list_installed failing with
       "IndexError: list index out of range" | refs: #25711

   * PR #25714: (cachedout) Display  warning  when  progressbar  can't  be
     loaded @ 2015-07-25T00:10:13Z

     * ISSUE  #25435:  (yee379)  progressbar  dependency  missing  | refs:
       #25714

   * PR #25699: (rallytime) Back-port #25660 to 2015.5 |  refs:  #25709  @
     2015-07-24T22:11:40Z

     * PR   #25660:   (colekowalski)   add  glusterfs'  direct-io-mode  to
       mount_invisible_keys | refs: #25699 #25709

   * PR #25694: (s0undt3ch) Salt-SSH fix for #25689 @ 2015-07-24T21:41:57Z

     * ISSUE #25689: (anlutro) Minion log in salt-ssh | refs: #25694

   * PR  #25710:  (jahamn)  Integration  Testcase  for   Issue   25250   @
     2015-07-24T20:57:33Z

     * ISSUE  #25250:  (wipfs) 'force' option in copy state deletes target
       file | refs: #25461 #25710

   * PR #25680: (basepi) [2015.5] Move cmd.run jinja aliasing to a wrapper
     class to prevent side effects @ 2015-07-24T19:52:10Z

     * PR  #25049:  (terminalmage)  Fix  cmd.run  when  cross-called  in a
       state/execution module | refs: #25680

   * PR #25682: (basepi) [2015.5] Fix parsing args with just a hash (#)  @
     2015-07-24T19:52:01Z

   * PR  #25695:  (stanislavb)  Configurable  AWS region & region from IAM
     metadata @ 2015-07-24T19:36:40Z

   * PR #25645: (kev009) Fix pkgng provider to work with  a  sources  list
     and the underlying pkg... @ 2015-07-24T16:33:18Z

   * PR #25677: (aneeshusa) Fix pacman.list_upgrades when refresh=True.  @
     2015-07-24T16:30:06Z

   * PR  #25675:  (UtahDave)  Use  OS  line  endings  with   contents   on
     file.managed @ 2015-07-24T16:29:50Z

     * ISSUE  #25674: (UtahDave) file.managed with contents parameter uses
       wrong line endings on Windows | refs: #25675

   * PR #25676: (basepi) Update release candidate docs  to  2015.8.0rc2  @
     2015-07-23T20:29:37Z

   * PR  #25666:  (nmadhok)  Check  if the properties exist before looping
     over them causing KeyError @ 2015-07-23T17:55:40Z

     * ISSUE  #25665:  (nmadhok)  salt-cloud  VMware  driver  fails   with
       KeyErrors   if   there's   any   existing  machine  in  the  VMware
       infrastructure in (invalid state) | refs: #25666

   * PR  #25656:  (anlutro)  Fix  locale  detection  in  debian/gentoo   @
     2015-07-23T16:46:40Z

   * PR    #25661:    (rallytime)    Back-port    #25624   to   2015.5   @
     2015-07-23T16:26:48Z

     * PR #25624: (bobrik) Fix typo in get_routes example for debian_ip  |
       refs: #25661

   * PR    #25662:    (rallytime)    Back-port    #25638   to   2015.5   @
     2015-07-23T16:26:40Z

     * ISSUE #15209: (hubez) file.manage:  source_hash  not  working  with
       s3:// (2014.7.0rc1) | refs: #25638

     * PR #25638: (TronPaul) fix bad merge in 99fc7ec | refs: #25662

   * PR #25644: (cachedout) pillar doc fix @ 2015-07-22T22:57:23Z

     * ISSUE  #25413:  (zizkebab)  pillar_opts  default  behavior  is  not
       reflected in the docs | refs: #25644

   * PR  #25642:  (cachedout)   Warn   on   pillar   schedule   delete   @
     2015-07-22T22:04:12Z

     * ISSUE #25540: (dennisjac) salt highstate schedule cannot be removed
       | refs: #25642

   * PR #25598: (twangboy) Fixed problem trying to load file with name  of
     boolean type @ 2015-07-22T17:07:49Z

     * ISSUE  #25437:  (lorengordon)  Stacktrace  on  Windows when running
       pkg.list_pkgs | refs: #25598 #25763

     * 7b79e433 Merge pull request #25598 from twangboy/fix_25437

   * PR #25604: (terminalmage) Move patching of mock_open to within test @
     2015-07-22T16:53:55Z

     * ISSUE #25323: (terminalmage) unit.modules.tls_test fails with older
       mock | refs: #25604

   * PR #25609: (s0undt3ch) [2015.5] Update the bootstrap script to latest
     release v2015.07.22 @ 2015-07-22T16:28:52Z

     * ISSUE  #630:  (syphernl)  Allow  for an include statement in config
       files | refs: #25609

     * PR #627: (chjohnst) add saltversion grain | refs: #25609

   * PR #25603: (terminalmage) Add version_cmp  function  to  yumpkg.py  @
     2015-07-22T15:42:29Z

     * ISSUE #21912: (rvora) pkg.latest not updating the package on CentOS
       though yum reports an update available | refs: #25603

   * PR #25590: (garethgreenaway) 2015.5  scheduled  jobs  return  data  @
     2015-07-21T21:57:42Z

     * ISSUE  #25560:  (dennisjac)  scheduled  highstate runs don't return
       results to the job cache | refs: #25590

   * PR #25584: (rallytime)  Back-port  #24054  and  #25576  to  2015.5  @
     2015-07-21T21:16:38Z

     * PR  #25576:  (pcn)  s3fs breaks when fetching files from s3 | refs:
       #25584

     * PR #24054: (mgwilliams) s3.head: return useful data | refs: #25584

   * PR #25589: (jahamn) Fixes ssh_known_host not taking port into account
     @ 2015-07-21T21:15:06Z

     * ISSUE  #23626:  (mirko)  salt  state 'ssh_known_hosts' doesn't take
       'port' into account | refs: #25589

   * PR  #25573:  (EvaSDK)  Do  not  execute  bootstrap  script  twice   @
     2015-07-21T18:20:04Z

     * PR #25465: (EvaSDK) 2015.5.3 LXC module fixes | refs: #25573

   * PR   #25580:   (attiasr)  use  explicit  utf-8  decoding  (#25532)  @
     2015-07-21T15:40:49Z

     * ISSUE #25532: (attiasr) salt/modules/win_pkg.py list_pkgs is broken
       (encoding issues) | refs: #25556 #25580

   * PR  #25568:  (twangboy)  Fixed  win_useradd  module to add fullname @
     2015-07-21T14:30:25Z

     * ISSUE #25206: (jfindlay) fullname issues  with  user.add  state  on
       windows | refs: #25568

   * PR  #25561:  (twangboy)  Fixed  the  gem module to work on windows...
     without injection @ 2015-07-20T21:12:15Z

     * ISSUE #21041: (deuscapturus) state module gem.installed not working
       on Windows.  | refs: #25430 #25561 #25428

     * PR  #25428:  (twangboy)  Fixed  the gem module to work on windows |
       refs: #25561

   * PR   #25521:   (cachedout)   Fix   outputter   for    state.orch    @
     2015-07-20T19:30:14Z

   * PR  #25563:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-07-20T19:27:36Z

     * PR #25416: (cachedout) Fix broken keyword

   * PR #25559: (cachedout) Lint win_pkg @ 2015-07-20T17:46:29Z

   * PR #25556: (attiasr) fix for #25532 @ 2015-07-20T17:45:11Z

     * ISSUE #25532: (attiasr) salt/modules/win_pkg.py list_pkgs is broken
       (encoding issues) | refs: #25556 #25580

   * PR   #25554:   (jfindlay)   verify_ssl=True   for  s3  ext  pillar  @
     2015-07-20T17:43:38Z

     * ISSUE #25538: (stanislavb)  S3  ext_pillar  configuration  requires
       verify_ssl | refs: #25554

   * PR    #25551:    (rallytime)    Backport    #25530    to   2015.5   @
     2015-07-20T17:43:00Z

     * PR #25530: (andre-luiz-dos-santos) The variable name must be last |
       refs: #25551

   * PR   #25533:   (attiasr)   port   445   for  windows  bootstraping  @
     2015-07-20T15:13:06Z

   * PR #25525: (gtmanfred) add make _prepare an alias  for  postinitio  @
     2015-07-20T15:12:38Z

     * ISSUE   #25432:   (gtmanfred)   [2015.5.3][raet]  raet  error  with
       SaltRaetRoadStackJoiner | refs: #25525

   * PR #25519: (rallytime) Backport vmware  driver  to  2015.5  branch  @
     2015-07-20T15:11:26Z

     * ISSUE  #25511: (rallytime) Make provider --> driver change backward
       compatible | refs: #25519 #25519

     * ISSUE #23574: (CedNantes) Failed to Deploy  Salt-Minion  on  a  Win
       2012  R2  using  wmware  Cloud  Driver  from Develop branch | refs:
       #25519

   * PR #25542:  (Oro)  Fix  hipchat.send_message  when  using  API  v2  @
     2015-07-20T15:09:13Z

   * PR    #25531:    (rallytime)    Back-port    #25529   to   2015.5   @
     2015-07-18T19:16:10Z

     * PR #25529: (davidjb) Fix minor typo  in  best  practice  example  |
       refs: #25531

   * PR   #25528:   (davidjb)  Fix  typo  in  extend  declaration  doco  @
     2015-07-18T14:22:06Z

   * PR   #25517:   (rallytime)   Back-port    #25486    to    2015.5    @
     2015-07-17T21:49:26Z

     * ISSUE   #25486:   (whiteinge)  Highstate  outputter  not  used  for
       state.apply | refs: #25517

     * PR #25485: (attiasr) fix file downloads on windows

   * PR   #25516:   (rallytime)   Back-port    #25483    to    2015.5    @
     2015-07-17T21:49:05Z

     * ISSUE #25479: (alexandrsushko) multiple mount.mounted of one device
       | refs: #25483

     * PR #25483: (alexandrsushko) Added 'none' to the set of  specialFSes
       | refs: #25516

   * PR  #25513:  (garethgreenaway) fixes to schedule.add documentation in
     2015.5 @ 2015-07-17T17:03:24Z

     * ISSUE #25493: (blackduckx)  Issue  with  job_args  on  schedule.add
       command | refs: #25513

   * PR  #25465:  (EvaSDK)  2015.5.3  LXC  module  fixes  | refs: #25573 @
     2015-07-17T15:57:54Z

   * PR #25506: (s0undt3ch) [2015.5] Update  bootstrap  script  to  latest
     stable release, v2015.07.17 @ 2015-07-17T15:40:38Z

     * ISSUE  #25456:  (julienlavergne) [2015.8.0rc1] salt-bootstrap fails
       to install salt master | refs: #25506

     * ISSUE #25270: (iggy) [2015.8.0rc1] salt-bootstrap fails to properly
       install a minion | refs: #25506

     * ISSUE  #625:  (whiteinge)  cmd.run state user flag is not working |
       refs: #25506 #632

     * ISSUE  #611:  (fatbox)  Peer  interface  fails   to   return   data
       occasionally | refs: #25506

     * ISSUE #607: (thatch45) next level -X support | refs: #25506

     * ISSUE  #598:  (syphernl)  Explanation on how to execute interactive
       installs | refs: #25506

     * ISSUE #455: (whiteinge)  Document  common  troubleshooting  tips  |
       refs: #25506

     * PR  #624: (chjohnst) Docs are not correct with network.ping as args
       are not supported | refs: #25506

     * PR #621: (akoumjian) Adding ec2 cloud-init bootstrap docs  |  refs:
       #25506

     * PR  #606:  (terminalmage) need empty line before code blocks. added
       ones that were missing.  | refs: #25506

     * PR #602: (terminalmage) State-related documentation changes | refs:
       #25506

   * PR  #25498:  (jfindlay)  only  read  /proc/1/cmdline  if  it exists @
     2015-07-17T15:35:33Z

     * ISSUE #25454: (mschiff) Regression:  salt  2015.5  not  working  in
       secure chroot anymore.  | refs: #25498

   * PR    #25487:    (rallytime)    Back-port    #25464   to   2015.5   @
     2015-07-16T16:58:36Z

     * PR #25464: (jquast) docfix: "cache_jobs:  False"  =>  grains_cache:
       False" | refs: #25487

   * PR   #25482:  (oeuftete)  Fix  docker.running  detection  of  running
     container @ 2015-07-16T16:58:29Z

     * PR #2015: (thekuffs) Esky / bbfreeze support

   * PR  #25468:  (joejulian)  Add  support  for  pyOpenSSL   >   0.10   @
     2015-07-16T15:10:30Z

     * ISSUE  #25384:  (rickh563)  pyopenssl  0.14 requirement in 2015.5.3
       does not work in RHEL6 : ZD-364 | refs: #25468

   * PR #25467: (rallytime) Add  lxml  dependency  to  opennebula  docs  @
     2015-07-16T15:09:57Z

   * PR #25461: (jahamn) Update file, if force option and content not same
     @ 2015-07-15T20:15:07Z

     * ISSUE #25250: (wipfs) 'force' option in copy state  deletes  target
       file | refs: #25461 #25710

     * ISSUE  #24647:  (nmadhok)  salt.states.file.copy  does not copy the
       file if it already exists with force=True | refs: #25461

   * PR #25438: (rallytime) Reduce digital_ocean_v2 API call  frequency  @
     2015-07-15T19:40:18Z

     * ISSUE  #25431:  (namcois)  Digital  Ocean  v2 reducing API calls by
       adding per_page | refs: #25438

   * PR #25457: (jacksontj) Saltnado @ 2015-07-15T17:50:12Z

     * PR #25427: (tony-cocco) Saltnado runner client results in  blocking
       call despite being set-up as Runner.async | refs: #25457

   * PR   #25459:   (jahamn)   Fixed   'defulats'   typo  in  verify.py  @
     2015-07-15T16:53:06Z

   * PR #25426: (jquast) bugfix: trailing  "...done"  in  rabbitmq  output
     (backport from 'develop' to 2015.5) @ 2015-07-15T14:48:05Z

   * PR   #25433:   (jleroy)   Support   for   IPv6  addresses  scopes  in
     network.interfaces (ifconfig) @ 2015-07-15T14:44:09Z

     * PR  #25151:  (jleroy)  Support  for  IPv6   addresses   scopes   in
       network.interfaces | refs: #25274 #25433

   * PR  #25430:  (twangboy) Disabled rbenv execution module for Windows @
     2015-07-15T14:41:18Z

     * ISSUE #21041: (deuscapturus) state module gem.installed not working
       on Windows.  | refs: #25430 #25561 #25428

     * ISSUE #1846: (seanchannel) development dependencies

   * PR  #25420:  (techhat)  Move  S3  to  use  AWS  Signature Version 4 @
     2015-07-14T22:03:09Z

   * PR #25418: (twangboy) Fixed problem  with  file.managed  test=True  @
     2015-07-14T21:26:59Z

     * ISSUE  #20441:  (deuscapturus) State module file.managed returns an
       error on Windows and test=Test | refs: #25418

   * PR #25417: (ahus1) extended documentation about dependencies for  dig
     module @ 2015-07-14T20:49:51Z

   * PR  #25411:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-07-14T17:55:26Z

     * PR #25375: (cachedout) Fix error in config.py for master_type

     * PR #25324: (jacobhammons) Latest help theme updates

   * PR #25406:  (anlutro)  Force  arguments  to  aptpkg.version_cmp  into
     strings @ 2015-07-14T16:15:41Z

   * PR    #25408:    (rallytime)    Back-port    #25399   to   2015.5   @
     2015-07-14T16:09:06Z

     * PR #25399: (jarpy)  Demonstrate  per-minion  client_acl.   |  refs:
       #25408

   * PR  #25240:  (tankywoo)  file  make  os.walk  only  be  called  one @
     2015-07-14T16:04:49Z

   * PR   #25395:   (rallytime)   Back-port    #25389    to    2015.5    @
     2015-07-14T03:26:34Z

     * PR  #25389: (l2ol33rt) Adding entropy note for gpg renderer | refs:
       #25395

   * PR   #25392:   (rallytime)   Back-port    #25256    to    2015.5    @
     2015-07-14T03:25:13Z

     * PR  #25256:  (yanatan16)  Don't  assume  source_hash exists | refs:
       #25392

   * PR #25398: (twangboy) Fix date @ 2015-07-14T03:21:17Z

   * PR #25397: (GideonRed) Introduce standard error output when cli exits
     with non-zero status @ 2015-07-14T03:20:24Z

   * PR #25386: (cachedout) Lint #25383 @ 2015-07-13T21:01:10Z

     * ISSUE  #24444:  (michaelkrupp)  file.managed  does  not handle dead
       symlinks | refs: #25383

     * PR    #25383:    (jahamn)    Fix    manage_file     function     in
       salt/modules/file.py to handle broken sym...

   * PR  #25383: (jahamn) Fix manage_file function in salt/modules/file.py
     to handle broken sym... @ 2015-07-13T20:58:23Z

     * ISSUE #24444: (michaelkrupp)  file.managed  does  not  handle  dead
       symlinks | refs: #25383

   * PR #25369: (anlutro) Fix aptpkg.version_cmp @ 2015-07-13T20:18:45Z

   * PR   #25379:   (jfindlay)   check   for   cwd  before  getting  it  @
     2015-07-13T19:50:27Z

     * ISSUE #25337: (eliasp) salt-call from non-existend cwd backtraces |
       refs: #25379

   * PR  #25334:  (jfindlay)  return  all  cmd  info  back to zypper fcn @
     2015-07-13T17:03:29Z

     * ISSUE #25320: (podloucky-init) zypper module  list_upgrades  broken
       (2015.5.2) | refs: #25334

   * PR     #25339:     (jfindlay)    update    orchestration    docs    @
     2015-07-13T16:04:26Z

   * PR #25358: (dkiser) Deep merge of  pillar  lists  |  refs:  #26016  @
     2015-07-13T15:51:01Z

     * ISSUE  #22241: (masterkorp) Salt master not properly generating the
       map | refs: #25358

   * PR #25346: (bechtoldt) set correct indention in states/requisites.rst
     (docs), fixes #25281 @ 2015-07-13T15:34:45Z

     * ISSUE  #25281:  (shinshenjs)  Unless  usage  in Official Doc syntax
       error?

   * PR #25336: (terminalmage) Don't try to read init binary if it  wasn't
     found @ 2015-07-13T09:45:30Z

   * PR  #25350:  (davidjb)  Fix  documentation  for  file.blockreplace  @
     2015-07-13T03:41:20Z

   * PR   #25326:   (rallytime)   Back-port    #20972    to    2015.5    @
     2015-07-10T18:49:44Z

     * ISSUE  #19288:  (oba11)  AssociatePublicIpAddress doesn't work with
       salt-cloud 2014.7.0 | refs: #20972 #25326

     * PR  #20972:  (JohannesEbke)  Fix  interface  cleanup   when   using
       AssociatePublicIpAddress in #19288 | refs: #25326

   * PR    #25327:    (rallytime)    Back-port    #25290   to   2015.5   @
     2015-07-10T18:49:37Z

     * ISSUE #24433: (chrimi) Salt locale state fails, if locale  has  not
       been generated | refs: #25290

     * PR  #25290:  (pcdummy)  Simple fix for locale.present on Ubuntu.  |
       refs: #25327

   * PR   #25328:   (rallytime)   Back-port    #25309    to    2015.5    @
     2015-07-10T17:22:59Z

     * ISSUE #24827: (yermulnik) locale.present doesn't generate locales |
       refs: #25309

     * PR  #25309:   (davidjb)   Format   /etc/locale.gen   correctly   in
       salt.modules.localemod.gen_locale | refs: #25328

   * PR    #25322:   (jacobhammons)   version   change   to   2015.5.3   @
     2015-07-10T16:11:24Z

   * PR #25308: (jacksontj) Make clear  commands  trace  level  logging  @
     2015-07-10T14:20:06Z

     * PR  #24737:  (jacksontj)  Move AES command logging to trace | refs:
       #25308

   * PR   #25269:   (jfindlay)    Extract    tomcat    war    version    @
     2015-07-10T01:28:21Z

     * ISSUE  #24520:  (nvx) Tomcat module fails to extract version number
       from snapshot builds (2015.5 regression) | refs: #24927

     * PR #24927: (egarbi) Tomcat module fails to extract  version  number
       from snapshot builds #2... | refs: #25269

   * PR    #25238:    (DmitryKuzmenko)   Pillarenv   backport   2015.5   @
     2015-07-10T01:25:07Z

     * ISSUE #18808: (amendlik) Add command line argument to select pillar
       environment | refs: #25238

     * PR #23719: (DmitryKuzmenko) Support pillarenv cmdline in state.sls

   * PR  #25299:  (twangboy)  Added  -NonInteractive so powershell doesn't
     hang waiting for input @ 2015-07-09T21:00:16Z

     * ISSUE #13943: (Supermathie) Powershell commands that  expect  input
       hang forever | refs: #25299

   * PR #25301: (jacobhammons) bug fix for module function display in help
     @ 2015-07-09T20:46:34Z

   * PR #25279: (jacobhammons) Additional docs on external and master  job
     cache, assorted doc fixes @ 2015-07-09T16:46:26Z

     * ISSUE  #25277: (jacobhammons) CherryPy recommended versions | refs:
       #25279

   * PR #25274: (jleroy) Fix for issue #25268 @ 2015-07-09T13:36:26Z

     * ISSUE  #25268:  (lichtamberg)   Salt   not   working   anymore   in
       2015.8/develop: ValueError: 'scope' is not in list | refs: #25274

     * PR   #25151:   (jleroy)   Support  for  IPv6  addresses  scopes  in
       network.interfaces | refs: #25274 #25433

   * PR #25272: (twangboy) Fixed  problem  with  service  not  starting  @
     2015-07-08T23:29:48Z

   * PR  #25225:  (nmadhok)  Backporting  fix  for  issue #25223 on 2015.5
     branch @ 2015-07-08T15:16:18Z

     * ISSUE  #25223:  (nmadhok)  Runner   occasionally   fails   with   a
       RuntimeError when fired by a reactor | refs: #25225

   * PR  #25214: (rallytime) A couple of doc fixes for the http tutorial @
     2015-07-07T22:23:07Z

   * PR #25194: (rallytime) Update moto version check in boto_vpc_test and
     update min version @ 2015-07-07T18:27:32Z

     * ISSUE  #24272:  (rallytime)  Fix boto_vpc_test moto version check |
       refs: #25194

   * PR    #25205:    (basepi)    Update    releasecandidate    docs     @
     2015-07-07T15:25:24Z

   * PR   #25187:   (UtahDave)  Doc  fixes:  Fix  misspelling  and  remove
     extraneous double spaces @ 2015-07-07T01:07:04Z

   * PR  #25182:  (cachedout)  Try  to  re-pack  long  floats  as  strs  @
     2015-07-07T01:06:43Z

   * PR    #25185:    (rallytime)    Back-port    #25128   to   2015.5   @
     2015-07-07T00:58:00Z

     * ISSUE  #23822:  (sidcarter)  Zip  file  extracted  permissions  are
       incorrect | refs: #25128

     * PR  #25128:  (stanislavb)  Use  cmd_unzip to preserve permissions |
       refs: #25185

   * PR   #25181:   (rallytime)   Back-port    #25102    to    2015.5    @
     2015-07-07T00:57:13Z

     * PR #25102: (derBroBro) Update win_network.py | refs: #25181

   * PR    #25179:    (rallytime)    Back-port    #25059   to   2015.5   @
     2015-07-07T00:56:44Z

     * ISSUE #24301: (iggy)  influxdb_user  and  influxdb_database  states
       need virtual functions | refs: #25059

     * PR  #25059:  (babilen)  Add  virtual  functions  to  influxdb state
       modules | refs: #25179

   * PR #25196: (twangboy) Fixed #18919 false-positive  on  pkg.refresh  @
     2015-07-07T00:24:13Z

     * ISSUE    #18919:    (giner)    Windows:    pkg.refresh_db   returns
       false-positive success | refs: #25196

   * PR   #25180:   (rallytime)   Back-port    #25088    to    2015.5    @
     2015-07-06T20:33:45Z

     * PR #25088: (supertom) Update | refs: #25180

   * PR  #25191:  (basepi)  Add  extrndest back to fileclient.is_cached in
     2015.5 @ 2015-07-06T19:35:24Z

     * PR #25117: (basepi) Fix fileclient.is_cached | refs: #25191

   * PR   #25175:   (rallytime)   Back-port    #25020    to    2015.5    @
     2015-07-06T18:53:19Z

     * ISSUE  #25016:  (martinhoefling)  salt-run doc.execution fails with
       AttributeError

     * PR #25020: (martinhoefling) Fix for issue #25016 | refs: #25175

   * PR   #25173:   (rallytime)   Partial   back-port    of    #25019    @
     2015-07-06T18:52:59Z

     * ISSUE  #21879:  (bechtoldt)  Reference  pages  in documentation are
       outdated again | refs: #25019

     * ISSUE #19262: (bechtoldt) salt.pillar.file_tree doesn't  appear  in
       the documentation | refs: #25019

     * PR   #25019:   (bechtoldt)  add  missing  module  documentation  to
       references | refs: #25173

     * PR #24421: (bechtoldt) add missing  module  documentation  |  refs:
       #25019

     * PR  #21880:  (bechtoldt)  update  references,  fixes #21879 | refs:
       #25019

     * PR #20039: (bechtoldt)  completing  some  doc  references  |  refs:
       #25019

   * PR    #25171:    (rallytime)    Back-port    #25001   to   2015.5   @
     2015-07-06T18:51:53Z

     * PR   #25001:   (jasonkeene)   Add   docs    for    key    arg    in
       ssh_known_hosts.present | refs: #25171

   * PR    #25170:    (rallytime)    Back-port    #24982   to   2015.5   @
     2015-07-06T16:34:43Z

     * PR #24982: (asyncsrc) ec2 network_interfaces fix | refs: #25170

   * PR #25161: (aneeshusa)  Allow  checking  for  non-normalized  systemd
     units.  @ 2015-07-06T15:15:31Z

   * PR   #25151:   (jleroy)   Support   for   IPv6  addresses  scopes  in
     network.interfaces | refs: #25274 #25433 @ 2015-07-06T14:43:03Z

   * PR #25166: (cachedout) Lint #25149 @ 2015-07-06T14:40:29Z

     * ISSUE #24979: (mavenAtHouzz) [Discussion] Support for more  than  1
       netapi.rest_tornado server process | refs: #25149

     * PR #25149: (jacksontj) Saltnado multiprocess support | refs: #25166

   * PR #25149: (jacksontj) Saltnado multiprocess support | refs: #25166 @
     2015-07-06T14:38:43Z

     * ISSUE #24979: (mavenAtHouzz) [Discussion] Support for more  than  1
       netapi.rest_tornado server process | refs: #25149

   * PR   #25120:  (d--j)  add  missing  continue  for  exception  case  @
     2015-07-02T19:38:45Z

   * PR  #25117:  (basepi)  Fix  fileclient.is_cached  |  refs:  #25191  @
     2015-07-02T19:38:26Z

   * PR  #25087:  (0xf10e)  Fix execution module for glance - now based on
     2015.5!  @ 2015-07-02T19:36:27Z

   * PR #25129: (basepi) [2015.5] Merge forward from 2014.7  to  2015.5  @
     2015-07-02T17:37:40Z

     * ISSUE #18447: (ryan-lane) Can't install salt with raet using pip -e
       git

     * PR #25093: (jaybocc2) quick fix for issue #18447

     * PR  #25069:  (puneetk)  Add  a  helper   module   function   called
       list_enabled

   * PR #25114: (jfindlay) Revert "Revert "adding states/postgres_database
     unit test case.""  @ 2015-07-02T01:01:29Z

     * PR #24798: (jtand)  Revert  "adding  states/postgres_database  unit
       test case."  | refs: #25114

     * PR  #24329:  (jayeshka)  adding  states/postgres_database unit test
       case.  | refs: #24798

   * PR #24362: (jayeshka) adding states/postgres_user unit test case.   @
     2015-07-01T21:45:31Z

   * PR  #24361:  (jayeshka) adding states/postgres_schema unit test case.
     @ 2015-07-01T21:44:56Z

   * PR #24331:  (jayeshka)  adding  states/postgres_extension  unit  test
     case.  @ 2015-07-01T21:43:58Z

   * PR   #26486:  (thusoy)  Git:  Don't  leak  https  user/pw  to  log  @
     2015-08-20T16:04:52Z

     * ISSUE #26484: (thusoy) Git state leaks HTTPS user/pw to log | refs:
       #26486

     * ISSUE  #26482:  (thusoy)  Git states doesn't allow user-only auth |
       refs: #26483

     * PR #26483: (thusoy) Handle user-only http  auth  in  git  module  |
       refs: #26486

   * PR #26476: (jacobhammons) Minor doc bug fixes @ 2015-08-19T22:52:35Z

     * ISSUE  #26432:  (centromere)  Documentation  incorrectly references
       salt-key on the minion | refs: #26476

     * ISSUE #26403: (adelcast) Grains  documentation  incorrectly  states
       they are static | refs: #26476

     * ISSUE  #26329:  (cro) Add note to eauth docs indicating default PAM
       service.  | refs: #26476

     * ISSUE #26264: (grep4linux) state trees cannot have  'dots'  in  the
       name | refs: #26476

     * ISSUE  #26233:  (dove-young)  pip  install  salt, then start master
       failed on Fedora 22 | refs: #26476

   * PR  #26443:  (cachedout)  Fix  connect  issue   in   event   init   @
     2015-08-19T22:50:22Z

     * ISSUE  #26366: (GreatSnoopy) The development tree produces hanging,
       100%cpu salt-master processes | refs: #26443

     * ISSUE #26301: (waynew) CPU pegged out  running  salt-master  (after
       running command) | refs: #26443

     * ISSUE #25998: (driskell) Event subsystem discarding required events
       during --batch breaking it for slow running commands | refs: #26000

     * PR #26000: (driskell) Implement full event caching  for  subscribed
       tags | refs: #26443

   * PR  #26445: (cachedout) Raise clean error when no minions targeted in
     batch mode @ 2015-08-19T22:50:07Z

     * ISSUE #26343: (jfindlay) batch error when no minions match target |
       refs: #26445

   * PR  #26483: (thusoy) Handle user-only http auth in git module | refs:
     #26486 @ 2015-08-19T22:47:41Z

     * ISSUE #26482: (thusoy) Git states doesn't allow  user-only  auth  |
       refs: #26483

   * PR   #26496:   (jfindlay)   add   dateutil   dependency  reporting  @
     2015-08-19T22:46:31Z

   * PR  #26494:  (cachedout)  Remove  unnecessary  debug   statements   @
     2015-08-19T20:46:00Z

   * PR    #26465:    (rallytime)    Back-port    #26457   to   2015.5   @
     2015-08-19T16:08:16Z

     * PR #26457: (arthurlogilab) docstring improvement  for  network.ping
       module execution | refs: #26465

   * PR #26434: (s0undt3ch) Fix missed typo @ 2015-08-18T18:14:29Z

   * PR  #26430: (rallytime) List public and private ips under the correct
     label @ 2015-08-18T16:20:32Z

     * ISSUE #26426: (alxbse) Private/public  IPs  are  interchanged  when
       listing nova driver cloud nodes | refs: #26430

   * PR    #26431:    (rallytime)    Back-port    #26417   to   2015.5   @
     2015-08-18T15:41:58Z

     * PR #26417: (scottjpack) Changed t1 -> t2 micro | refs: #26431

   * PR #26378: (stanislavb) Fix EC2 credentials from IAM roles  for  s3fs
     and s3 ext_pillar in 2015.5 @ 2015-08-18T14:01:53Z

   * PR #26420: (terminalmage) Only use pygit2.errors if it exists (2015.5
     branch) @ 2015-08-18T14:00:01Z

     * ISSUE #26245: (bradthurber) salt  v2015.5.3  gitfs.py  using  newer
       pygit2 feature than required minimum | refs: #26420

   * PR  #26409:  (basepi)  [2015.5] Merge forward from 2014.7 to 2015.5 @
     2015-08-17T23:19:56Z

     * PR #26242: (cro) Remove dead code

     * PR #26216: (cro) Fix LDAP configuration issue.

   * PR  #26406:  (jfindlay)  fix  syntax  error  in  lvm  exec  module  @
     2015-08-17T21:18:25Z

     * ISSUE #26404: (ssgward) Syntax error in lvm.vg_absent state causing
       failure | refs: #26406

   * PR #26405: (TheBigBear) dependency zip files  moved  to  new  site  @
     2015-08-17T21:17:24Z

   * PR  #26298:  (vr-jack)  Keep  $HOME from being interpretted by Master
     shell @ 2015-08-17T21:15:11Z

   * PR #26324: (s0undt3ch) Salt is now  pip  install'able  in  windows  @
     2015-08-17T20:41:34Z

   * PR  #26371:  (bastiaanb)  fix  issue #26161: on RedHat family systems
     touch /var/lock/subsys/$SE... @ 2015-08-17T20:39:28Z

     * ISSUE #26161: (bastiaanb) salt initscripts do not set lock file  in
       /var/lock/subsys as required on RedHat family OSes

   * PR  #26402:  (twangboy)  Removed  documentation  no longer required @
     2015-08-17T20:35:37Z

     * ISSUE #25801: (themalkolm)  Update  docs  that  salt.states.winrepo
       requires roles:salt-master in grains.  | refs: #26328

     * ISSUE #25562: (jefftucker) winrepo state does not run on masterless
       minion | refs: #26328

     * PR #26328: (twangboy) Removed salt-master role requirement |  refs:
       #26402

   * PR    #26392:    (rallytime)    Back-port    #26376   to   2015.5   @
     2015-08-17T19:39:51Z

     * PR #26376: (TheBigBear) minor edit spelling | refs: #26392

   * PR #26342: (rallytime) Don't call boto_elb._attributes_present if  no
     attributes were provided @ 2015-08-17T19:19:08Z

     * ISSUE   #16049:   (ryan-lane)   boto_elb.present   state   requires
       attributes argument | refs: #26342

   * PR   #26389:   (rallytime)   Back-port    #26160    to    2015.5    @
     2015-08-17T19:09:16Z

     * ISSUE  #26155:  (silenius)  pip  availability in states/pip_state |
       refs: #26160

     * PR #26160: (silenius) proposed fix for #26155 | refs: #26389

   * PR #26300: (jfindlay) mock pwd function calls in pw_user exec  module
     @ 2015-08-17T18:56:41Z

     * ISSUE  #26266:  (o-sleep)  limit  pw_user.getent()  from  returning
       entire corporate list | refs: #26300

   * PR    #26386:    (jahamn)    Fixes    autosign_timeout    usage    in
     check_autosign_dir @ 2015-08-17T18:34:40Z

     * ISSUE  #24334:  (afletch)  autosign_timeout  not  honoured  | refs:
       #26386

   * PR #26328: (twangboy) Removed salt-master role  requirement  |  refs:
     #26402 @ 2015-08-17T18:30:17Z

     * ISSUE  #25801:  (themalkolm)  Update  docs that salt.states.winrepo
       requires roles:salt-master in grains.  | refs: #26328

     * ISSUE #25562: (jefftucker) winrepo state does not run on masterless
       minion | refs: #26328

   * PR    #26362:    (garethgreenaway)   Fixes   to   mount   state.    @
     2015-08-17T17:44:55Z

     * ISSUE #26327: (bradthurber) mount.mounted  opts  incorrect  "forced
       unmount and mount because options (tcp) changed" | refs: #26362

   * PR     #26379:     (s0undt3ch)    [2015.5]    Backport    #26353    @
     2015-08-17T17:19:29Z

     * PR #26353: (sixninetynine) fixed a typo in setup.py | refs: #26379

   * PR #26277: (rallytime) Handle exception when user  is  not  found  in
     keystone.user_get @ 2015-08-14T19:41:59Z

     * ISSUE #26240: (0xf10e) keystone.user_get raises exception when user
       is not found | refs: #26277

   * PR #26326: (rallytime) Make ec2.create_snapshot return less unweildly
     and more relevant @ 2015-08-14T19:40:47Z

     * ISSUE  #24484:  (codehotter)  clouds/ec2.py: create_snapshot throws
       exception | refs: #26326

   * PR #26306: (rallytime) Move VM creation details dict to  log.trace  @
     2015-08-14T17:39:52Z

     * ISSUE  #16179:  (UtahDave)  Salt Cloud -l debug includes the entire
       bootstrap script twice in its output | refs: #26306

   Salt 2015.5.6 Release Notes
   Version 2015.5.6 is a bugfix release for 2015.5.0.

   Security Fixes
   CVE-2015-6941 - win_useradd module and salt-cloud display passwords  in
   debug log

   Updated  the  win_useradd  module  return data to no longer include the
   password of the newly created user. The password is now  replaced  with
   the string XXX-REDACTED-XXX.  Updated the Salt Cloud debug output to no
   longer   display   win_password   and   sudo_password    authentication
   credentials.

   CVE-2015-6918 - Git modules leaking HTTPS auth credentials to debug log

   Updated  the Git state and execution modules to no longer display HTTPS
   basic authentication credentials in loglevel debug output on  the  Salt
   master.  These  credentials are now replaced with REDACTED in the debug
   output. Thanks to Andreas Stieger <[email protected]> for bringing this
   to our attention.

   Changes for v2015.5.5..v2015.5.6
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-09-30T22:22:43Z

   Total Merges: 144

   Changes:

   * PR #27557: (jfindlay) add doc motivating mine vs grains

   * PR #27515: (jfindlay) save iptables rules on SuSE

   * PR #27509: (jfindlay) tell the user why the gluster module  does  not
     work

   * PR #27379: (jfindlay) document and check dict type for pip env_vars

   * PR #27516: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR  #27472:  (cachedout)  Change recommended schema for data field in
     mysql event table

   * PR #27468: (cachedout) Fix 27351

   * PR #27479: (aboe76) fix locale on opensuse and suse
     `#27438`_

   * PR  #27483:  (rallytime)  Outputters  should  sync  to  output,   not
     outputters, on the minion.

   * PR #27484: (rallytime) Back-port #27434 and #27470 to 2015.5

   * PR #27469: (twangboy) Added quotes to version numbers example

   * PR  #27467:  (cachedout)  file.managed: check contents_{pillar|grain}
     result

   * PR #27419: (rallytime) Amend error log to include multiple  tips  for
     troubleshooting.

   * PR  #27426:  (rallytime) Don't stacktrace if there are conflicting id
     errors in highstate

   * PR  #27408:  (rallytime)  Fix  avail_locations   function   for   the
     softlayer_hw driver in 2015.5

   * PR #27410: (jacobhammons) Fix css layout Refs
     `#27389`_

   * PR #27336: (rallytime) [2015.5] Fixup salt-cloud logging

   * PR #27358: (lorengordon) Escape search replacement text, fixes
     `#27356`_

   * PR  #27345:  (rallytime)  Allow use of rst header links by separating
     options out from yaml example

   * PR #26903: (bersace) Review defaults.get

   * PR #27317: (efficks) State unzip should use unzip command instead  of
     unzip_cmd.

   * PR  #27309:  (rallytime)  Change  a  value  list to a comma-separated
     string in boto_route53.present

   * PR #27311: (jfindlay) discuss replacement occurrences in file doc

   * PR #27310: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #27308: (terminalmage) Fix refresh_db regression in yumpkg.py

   * PR #27286: (terminalmage) Add a configurable timer for minion  return
     retries

   * PR #27278: (rallytime) Back-port #27256 to 2015.5

   * PR #27277: (rallytime) Back-port #27230 to 2015.5

   * PR #27253: (jfindlay) 2015.5 -> 2015.5.0

   * PR #27244: (garethgreenaway) Exception in cloud.ec2.create_snapshot

   * PR #27231: (jfindlay) only write cron file if it is changed

   * PR #27233: (basepi) [2015.5] Add stub release notes for 2015.5.6

   * PR #27208: (basepi) [2015.5] Add test.nop state

   * PR #27201: (jfindlay) rename hash_hostname to hash_known_hosts

   * PR  #27214:  (jacksontj)  Correctly  support https, port 443 is not a
     requirement

   * PR #27172: (rallytime) Back-port #27150 to 2015.5

   * PR #27194: (rallytime) Back-port #27180 to 2015.5

   * PR #27176: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #27170: (rallytime) Update Getting Started with GCE  docs  to  use
     cloud.profiles or cloud.profiles.d examples

   * PR #27167: (rallytime) Back-port #27148 to 2015.5

   * PR #27168: (techhat) Add further gating of impacket library

   * PR  #27166: (rallytime) Allow a full-query for EC2, even if there are
     no profiles defined

   * PR #27162: (rallytime) Be explicit in using "SoftLayer"  for  service
     queries in SoftLayer drivers

   * PR #27149: (twangboy) Fixed problem with add/remove path

   * PR #27147: (rallytime) Enforce bounds in the GCE Regex

   * PR #27128: (eguven) don't show diff for test run if show_diff=False

   * PR  #27116:  (jacobhammons)  Update  latest  to 2015.8, 2015.5 is now
     previous

   * PR #27033: (jfindlay) Merge #27019

   * PR #26942: (Arabus) Fix docker.run

   * PR  #26977:  (abh)  Add  support  for   PEERNTP   network   interface
     configuration

   * PR #27023: (jfindlay) add test support for htpasswd state mod

   * PR #27074: (twangboy) Replaced password with redacted when displayed

   * PR  #27073:  (rallytime) Remove "use develop branch" warning from LXC
     tutorial

   * PR #27054: (rallytime) Back-port #27029 to 2015.5

   * PR #27053: (rallytime) Back-port #26992 to 2015.5

   * PR #27052: (rallytime) Back-port #26930 to 2015.5

   * PR #27049: (johanek) Run repoquery less

   * PR #27070: (stanislavb) Deprecate salt.utils.iam in Carbon

   * PR #27030: (jfindlay) Backport #26938

   * PR #27025: (cachedout) Better try and error handling for prep_jid

   * PR #27035: (terminalmage) useradd.py: Use contextmanager  to  prevent
     leaked filehandles

   * PR #27034: (rallytime) Update softlayer docs for where to find apikey

   * PR #27024: (rallytime) Back-port #27004 to 2015.5

   * PR #27027: (rallytime) Back-port #27013 to 2015.5

   * PR #27026: (rallytime) Back-port #27011 to 2015.5

   * PR #26972: (twangboy) Catch the 404 error from fileclient

   * PR #26951: (terminalmage) Fix timezone module for CentOS

   * PR  #26875:  (marccardinal)  LXC  gateway provisioned only when IP is
     provided

   * PR #26997: (twangboy) Fixed symlinks  for  windows  (don't  use  user
     root)

   * PR #27001: (twangboy) Added CLI Example for reg.delete_key_recursive

   * PR #26996: (jacobhammons) Beacon doc updates

   * PR  #26868:  (joejulian)  Use  the  actual  device name when checking
     vgdisplay

   * PR  #26955:  (dsumsky)  S3  ext_pillar  module  has  broken   caching
     mechanism (backport to 2015.5)

   * PR #26987: (rallytime) Back-port #26966 to 2015.5

   * PR #26915: (rallytime) Update Joyent Cloud Tests

   * PR #26971: (rallytime) Fix a couple of typos in reactor docs

   * PR  #26976:  (thatch45)  Revert  "file.symlink  gets  windows account
     instead of root"

   * PR #26975: (whiteinge) Remove mocks  from  rest_cherrypy  integration
     tests; fix groups check bug

   * PR  #26899:  (twangboy)  file.symlink gets windows account instead of
     root

   * PR #26960: (rallytime) Fix bash code  block  formatting  in  CherryPy
     netapi docs

   * PR #26940: (rallytime) Fix minor doc typo in client api

   * PR #26871: (rallytime) Back-port #26852 to 2015.5

   * PR  #26851: (jacobhammons) states/pkgrepo examples, suse installation
     updates

   * PR #26817: (jfindlay) modify groupadd for rhel 5

   * PR #26824: (pravka) [salt-cloud] Fix creating droplet  from  snapshot
     in digital_ocean provider

   * PR #26823: (joejulian) use dbus instead of localectl

   * PR #26820: (jfindlay) add default param in _parse_localectl in locale
     mod

   * PR #26821: (twangboy) Fixed user.rename function in windows

   * PR #26803: (twangboy) Added check for PyMySQL if MySQLdb import fails

   * PR #26815: (jfindlay)  stringify  linode  id  before  performing  str
     actions

   * PR #26800: (jacobhammons) Doc bug fixes

   * PR  #26793:  (rallytime) Don't stacktrace if "name" is specified as a
     minion id in a map file

   * PR #26790: (rallytime) Update Saltify docs to be  more  accurate  and
     helpful

   * PR #26787: (jfindlay) merge #26775

   * PR #26759: (terminalmage) Backport PR #26726 to 2015.5 branch

   * PR #26768: (garethgreenaway) Fixes to ipset in 2015.5 for
     `#26628`_

   * PR #26753: (jfindlay) import elementree from _compat in ilo exec mod

   * PR #26736: (twangboy) Changed import from smbconnection to smb3

   * PR #26714: (jfindlay) add exception placeholder for older msgpacks

   * PR  #26710:  (rallytime) Update GCE driver to return True, False or a
     new name in __virtual__()

   * PR #26709: (rallytime) Ensure VM  name  is  valid  before  trying  to
     create Linode VM

   * PR  #26617:  (terminalmage) Fix Windows failures in pip module due to
     raw string formatting

   * PR #26700: (kev009) Ignore the first  element  of  kern.disks  split,
     which is the sysctl name

   * PR  #26695:  (terminalmage)  Better  HTTPS  basic  auth redaction for
     2015.5 branch

   * PR #26694: (terminalmage) Backport #26693 to 2015.5

   * PR #26681: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #26676: (rallytime) Back-port #26648 to 2015.5

   * PR #26677: (rallytime) Back-port #26653 to 2015.5

   * PR #26675: (rallytime) Back-port #26631 to 2015.5

   * PR #26655: (cheng0919) Update win_dns_client.py

   * PR #26662: (jacobhammons) update version to 2015.5

   * PR #26651: (jfindlay) add 2015.5.4 notes to 2015.5.5 notes

   * PR #26525: (jfindlay) document check_file_meta  args,  remove  unused
     arg

   * PR  #26561:  (stanislavb)  Leave  salt.utils.s3  location fallback to
     salt.utils.aws

   * PR #26573: (rallytime) Don't  stacktrace  if  using  private_ips  and
     delete_sshkeys together

   * PR  #26563: (rallytime) Fix error detection when salt-cloud config is
     missing a master's address

   * PR #26641: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #26620: (rallytime) Also add -Z to script args for cloud tests

   * PR #26618: (rallytime) Add script_args: '-P' to  Ubuntu  14  profiles
     for nightly cloud tests

   * PR #26612: (rallytime) Use an available image to test against

   * PR  #26576:  (rallytime)  Ensure GCE and EC2 configuration checks are
     correct

   * PR #26580: (rallytime) Avoid race condition when  assigning  floating
     IPs to new VMs

   * PR #26581: (terminalmage) Skip tests that don't work with older mock

   * PR #26591: (rallytime) Back-port #26554 to 2015.5

   * PR #26565: (cachedout) Fix many errors with __virtual__ in tests

   * PR #26553: (rallytime) Back-port #26548 to 2015.5

   * PR #26552: (rallytime) Back-port #26542 to 2015.5

   * PR #26551: (rallytime) Back-port #26539 to 2015.5

   * PR #26549: (rallytime) Back-port #26524 to 2015.5

   * PR #26527: (jfindlay) check exists and values in boto_elb listeners

   * PR #26446: (stanislavb) Fetch AWS region from EC2 instance metadata

   * PR  #26546: (nmadhok) Do not raise KeyError when calling avail_images
     if VM/template is in disconnected state

   * PR #26537: (jfindlay) Merge #26481

   * PR #26528: (zmalone) Fixing encrypt to  instructions  in  the  2015.5
     branch

   Salt 2015.5.7 Release Notes
   NOTE:
      A  significant  orchestrate  issue  #29110 was discovered during the
      release process of 2015.5.7, so it has not been officially released.
      Please use 2015.5.8 instead.

   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-11-13T17:11:14Z

   Total Merges: 102

   Changes:

   * PR #28731: (garethgreenaway)  Fixes  to  salt  scheduler  in  2015.5,
     ensuring that return_job is only used on minion scheduler

   * PR #28857: (rallytime) Back-port #28851 to 2015.5

   * PR #28856: (rallytime) Back-port #28853 to 2015.5

   * PR #28832: (basepi) [2015.5] Backport #28826

   * PR #28833: (basepi) [2015.5] Increase the default gather_job_timeout

   * PR #28829: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #28756: (MrCitron) Fix
     `#25775`_

   * PR #28786: (chrigl) closes
     `#28783`_

   * PR #28776: (rallytime) Back-port #28740 to 2015.5

   * PR #28760: (dmyerscough) Fixing CherryPy key bug

   * PR #28746: (rallytime) Back-port #28718 to 2015.5

   * PR #28705: (cachedout) Account for new headers class in tornado 4.3

   * PR #28699: (rallytime) Back-port #28670 to 2015.5

   * PR #28703: (rallytime) Back-port #28690 to 2015.5

   * PR  #28694:  (s0undt3ch)  [2015.5]  Update to latest bootstrap script
     v2015.11.09

   * PR #28669: (rallytime)  Use  the  -q  argument  to  strip  extraneous
     messages from rabbitmq

   * PR #28645: (jacksontj) Rework minion return_retry_timer

   * PR #28668: (twangboy) Fixed join_domain and unjoin_domain for Windows

   * PR #28666: (jfindlay) define r_data before using it in file module

   * PR #28662: (cachedout) Add note about disabling master_alive_interval

   * PR #28627: (twangboy) Backport win_useradd

   * PR #28617: (cachedout) Set restrictive umask on module sync

   * PR #28622: (gravyboat) Update puppet module wording

   * PR  #28563:  (s0undt3ch)  [2015.5]  Update to latest bootstrap script
     v2015.11.04

   * PR #28541: (twangboy) Fixed problem with system.set_computer_name

   * PR #28537: (jfindlay) decode filename to utf-8 in file.recurse state

   * PR #28529: (rallytime) Update contributing and documentation pages to
     recommend submitting against branches

   * PR #28548: (nmadhok) [Backport] [2015.5] Tasks can be in queued state
     instead of running

   * PR #28531: (rallytime) Add versionadded directives to  virtualenv_mod
     state/module

   * PR #28508: (twangboy) Fixed windows tests

   * PR  #28525:  (rallytime) Fix spacing in doc examples for boto_route53
     state and module

   * PR #28517: (rallytime) Add state_auto_order defaults to True note  to
     ordering docs

   * PR #28512: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR  #28448:  (gwaters)  added  a  note  to  the  tutorial  for redhat
     derivatives

   * PR #28406: (rallytime) Back-port #28381 to 2015.5

   * PR #28413: (rallytime) Back-port #28400 to 2015.5

   * PR #28366: (erchn) mark repo not enabled when pkgrepo state passes in
     disable: True

   * PR #28373: (beverlcl) Fixing bug
     `#28372`_
      for use_carrier option on bonding network interfaces.

   * PR #28359: (rallytime) Back-port #28358 to 2015.5

   * PR #28346: (twangboy) Fix installer

   * PR  #28315: (gwaters) Adding a working example of setting pillar data
     on the cli

   * PR #28211: (terminalmage) Fix for ext_pillar being compiled twice  in
     legacy git_pillar code (2015.5 branch)

   * PR #28263: (cachedout) New channel for event.send

   * PR #28293: (cachedout) Minor grammar changes

   * PR #28271: (gwaters) Update tutorial documentation

   * PR #28280: (0xf10e) Correct Jinja function load_* to import_*

   * PR #28255: (cachedout) Add __cli opt

   * PR  #28213:  (rallytime) If record returned None, don't continue with
     the state. Something went wrong

   * PR #28238: (basepi) [2015.5] Fix schedule.present always diffing

   * PR  #28174:  (lorengordon)  Add  support  for  multiline   regex   in
     file.replace

   * PR #28175: (twangboy) Fixes
     `#19673`_

   * PR  #28140:  (rallytime)  Add  OpenBSD  installation documentation to
     2015.5 branch

   * PR #28138: (rallytime) Back-port #28130 EC2  Sizes  Only  portion  to
     2015.5

   * PR  #28097:  (jacksontj)  For  all  multi-part  messages,  check  the
     headers. If the header is not ...

   * PR #28117: (rallytime) Clean  up  stacktrace  when  master  can't  be
     reached in lxc cloud driver

   * PR  #28110:  (terminalmage)  Add  explanation  of  file_client: local
     setting masterless mode

   * PR #28109: (rallytime) Add created reactor event to lxc cloud driver

   * PR #27996: (rallytime) Don't fail if pip package is  already  present
     and pip1 is installed

   * PR #28056: (rallytime) Back-port #28033 to 2015.5

   * PR #28059: (rallytime) Back-port #28040 to 2015.5

   * PR #28047: (cachedout) Restore FTP functionality to file client

   * PR #28032: (twangboy) Fixed win_path.py

   * PR #28037: (rallytime) Back-port #28003 to 2015.5

   * PR  #28031:  (jacobhammons) Updated release notes with additional CVE
     information

   * PR #28008: (jfindlay) platform independent line endings in hosts mod

   * PR #28012: (rallytime) Clean up stack trace when something goes wrong
     with minion output

   * PR  #27995:  (jacobhammons)  added  link  to  grains  security FAQ to
     targeting and pillar topics.

   * PR #27986: (jacobhammons) Changed current release to  5.6  and  added
     CVE to release notes

   * PR #27913: (pass-by-value) Set default

   * PR  #27876:  (terminalmage)  2015.5 branch: Fix traceback when 2015.8
     git ext_pillar config schema used

   * PR  #27726:  (jfindlay)   deprecate   hash_hostname   in   favor   of
     hash_known_hosts

   * PR #27776: (jfindlay) return message when local jobs_cache not found

   * PR #27766: (jfindlay) better check for debian userdel error

   * PR #27758: (iggy) Remove redundant text from syslog returner

   * PR #27841: (terminalmage) Detect Manjaro Linux as Arch derivative

   * PR #27852: (rallytime) Back-port #27806 to 2015.5

   * PR   #27838:   (basepi)   [2015.5]   Fix   highstate   outputter  for
     jobs.lookup_jid

   * PR #27791: (eguven) 2015.5 postgres_user groups backport

   * PR #27759: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR  #27732:  (jacobhammons)   update   docs   for   __virtual__   and
     __virtualname__

   * PR #27747: (Sacro) Chocolatey doesn't have a help command.

   * PR    #27733:   (jacobhammons)   hardening   topic   -   updates   to
     docs.saltstack.com theme

   * PR #27706: (jacobhammons) Assorted doc bugs

   * PR #27695: (rallytime) Back-port #27671 to 2015.5

   * PR #27524: (jfindlay) parse pkgng output in quiet mode for >= 1.6.1

   * PR #27686: (rallytime) Back-port #27476 to 2015.5

   * PR #27684: (rallytime) Back-port #27656 to 2015.5

   * PR #27683: (rallytime) Back-port #27659 to 2015.5

   * PR #27682: (rallytime) Back-port #27566 to 2015.5

   * PR #27681: (rallytime) Back-port #25928 to 2015.5

   * PR #27680: (rallytime) Back-port #27535 to 2015.5

   * PR #27442: (JaseFace)  Ensure  we  pass  on  the  enable  setting  if
     present, or use the default of True if not in build_schedule_item()

   * PR #27641: (rallytime) Gate the psutil import and add depends doc for
     diskusage beacon

   * PR #27644: (rallytime) Back-port #27640 to 2015.5

   * PR #27612: (rallytime) Fix GCE external_ip stacktraces in 2015.5

   * PR #27568: (jacobhammons) regenerated man pages

   Salt 2015.5.8 Release Notes
   Security Fix
   CVE-2015-8034: Saving  state.sls  cache  data  to  disk  with  insecure
   permissions

   This  affects  users  of the state.sls function. The state run cache on
   the minion was being created  with  incorrect  permissions.  This  file
   could  potentially  contain  sensitive data that was inserted via jinja
   into the state SLS files. The permissions for this file are  now  being
   set  correctly.  Thanks  to  @zmalone  for  bringing  this issue to our
   attention.

   Changes
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2015-11-23T23:16:23Z

   Total Merges: 118

   Changes:

   * PR #29128: (cachedout) Set a safer default value for ret in saltmod

   * PR #29122: (cachedout) Fix broken state orchestration

   * PR #29096: (rallytime) Back-port #29093 to 2015.5

   * PR #29084: (rallytime) Back-port #29055 to 2015.5

   * PR #29083: (rallytime) Back-port #29053 to 2015.5

   * PR #28932: (twangboy) Fixed user.present / user.absent in windows

   * PR #29011: (rallytime) Back-port #28630 to 2015.5

   * PR #28982: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #28949: (whiteinge) Add sync_sdb execution function

   * PR #28930: (twangboy) Added missing import mmap required by file.py

   * PR #28908: (rallytime) A couple of spelling fixes for doc conventions
     page.

   * PR #28902: (whiteinge) Fix missing JSON support for /keys endpoint

   * PR #28897: (rallytime) Back-port #28873 to 2015.5

   * PR   #28871:   (basepi)   [2015.5]   Fix   command   generation   for
     mdadm.assemble

   * PR #28864: (jfindlay) add 2015.5.7 release notes

   * PR  #28731:  (garethgreenaway)  Fixes  to  salt  scheduler in 2015.5,
     ensuring that return_job is only used on minion scheduler

   * PR #28857: (rallytime) Back-port #28851 to 2015.5

   * PR #28856: (rallytime) Back-port #28853 to 2015.5

   * PR #28832: (basepi) [2015.5] Backport #28826

   * PR #28833: (basepi) [2015.5] Increase the default gather_job_timeout

   * PR #28829: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #28756: (MrCitron) Fix
     `#25775`_

   * PR #28786: (chrigl) closes
     `#28783`_

   * PR #28776: (rallytime) Back-port #28740 to 2015.5

   * PR #28760: (dmyerscough) Fixing CherryPy key bug

   * PR #28746: (rallytime) Back-port #28718 to 2015.5

   * PR #28705: (cachedout) Account for new headers class in tornado 4.3

   * PR #28699: (rallytime) Back-port #28670 to 2015.5

   * PR #28703: (rallytime) Back-port #28690 to 2015.5

   * PR #28694: (s0undt3ch) [2015.5] Update  to  latest  bootstrap  script
     v2015.11.09

   * PR  #28669:  (rallytime)  Use  the  -q  argument  to strip extraneous
     messages from rabbitmq

   * PR #28645: (jacksontj) Rework minion return_retry_timer

   * PR #28668: (twangboy) Fixed join_domain and unjoin_domain for Windows

   * PR #28666: (jfindlay) define r_data before using it in file module

   * PR #28662: (cachedout) Add note about disabling master_alive_interval

   * PR #28627: (twangboy) Backport win_useradd

   * PR #28617: (cachedout) Set restrictive umask on module sync

   * PR #28622: (gravyboat) Update puppet module wording

   * PR #28563: (s0undt3ch) [2015.5] Update  to  latest  bootstrap  script
     v2015.11.04

   * PR #28541: (twangboy) Fixed problem with system.set_computer_name

   * PR #28537: (jfindlay) decode filename to utf-8 in file.recurse state

   * PR #28529: (rallytime) Update contributing and documentation pages to
     recommend submitting against branches

   * PR #28548: (nmadhok) [Backport] [2015.5] Tasks can be in queued state
     instead of running

   * PR  #28531: (rallytime) Add versionadded directives to virtualenv_mod
     state/module

   * PR #28508: (twangboy) Fixed windows tests

   * PR #28525: (rallytime) Fix spacing in doc examples  for  boto_route53
     state and module

   * PR  #28517: (rallytime) Add state_auto_order defaults to True note to
     ordering docs

   * PR #28512: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #28448:  (gwaters)  added  a  note  to  the  tutorial  for  redhat
     derivatives

   * PR #28406: (rallytime) Back-port #28381 to 2015.5

   * PR #28413: (rallytime) Back-port #28400 to 2015.5

   * PR #28366: (erchn) mark repo not enabled when pkgrepo state passes in
     disable: True

   * PR #28373: (beverlcl) Fixing bug
     `#28372`_
      for use_carrier option on bonding network interfaces.

   * PR #28359: (rallytime) Back-port #28358 to 2015.5

   * PR #28346: (twangboy) Fix installer

   * PR #28315: (gwaters) Adding a working example of setting pillar  data
     on the cli

   * PR  #28211: (terminalmage) Fix for ext_pillar being compiled twice in
     legacy git_pillar code (2015.5 branch)

   * PR #28263: (cachedout) New channel for event.send

   * PR #28293: (cachedout) Minor grammar changes

   * PR #28271: (gwaters) Update tutorial documentation

   * PR #28280: (0xf10e) Correct Jinja function load_* to import_*

   * PR #28255: (cachedout) Add __cli opt

   * PR #28213: (rallytime) If record returned None, don't  continue  with
     the state. Something went wrong

   * PR #28238: (basepi) [2015.5] Fix schedule.present always diffing

   * PR   #28174:   (lorengordon)  Add  support  for  multiline  regex  in
     file.replace

   * PR #28175: (twangboy) Fixes
     `#19673`_

   * PR #28140: (rallytime)  Add  OpenBSD  installation  documentation  to
     2015.5 branch

   * PR  #28138:  (rallytime)  Back-port  #28130 EC2 Sizes Only portion to
     2015.5

   * PR  #28097:  (jacksontj)  For  all  multi-part  messages,  check  the
     headers. If the header is not ...

   * PR  #28117:  (rallytime)  Clean  up  stacktrace  when master can't be
     reached in lxc cloud driver

   * PR #28110:  (terminalmage)  Add  explanation  of  file_client:  local
     setting masterless mode

   * PR #28109: (rallytime) Add created reactor event to lxc cloud driver

   * PR  #27996:  (rallytime) Don't fail if pip package is already present
     and pip1 is installed

   * PR #28056: (rallytime) Back-port #28033 to 2015.5

   * PR #28059: (rallytime) Back-port #28040 to 2015.5

   * PR #28047: (cachedout) Restore FTP functionality to file client

   * PR #28032: (twangboy) Fixed win_path.py

   * PR #28037: (rallytime) Back-port #28003 to 2015.5

   * PR #28031: (jacobhammons) Updated release notes with  additional  CVE
     information

   * PR #28008: (jfindlay) platform independent line endings in hosts mod

   * PR #28012: (rallytime) Clean up stack trace when something goes wrong
     with minion output

   * PR #27995: (jacobhammons)  added  link  to  grains  security  FAQ  to
     targeting and pillar topics.

   * PR  #27986:  (jacobhammons)  Changed current release to 5.6 and added
     CVE to release notes

   * PR #27913: (pass-by-value) Set default

   * PR #27876: (terminalmage) 2015.5 branch: Fix  traceback  when  2015.8
     git ext_pillar config schema used

   * PR   #27726:   (jfindlay)   deprecate   hash_hostname   in  favor  of
     hash_known_hosts

   * PR #27776: (jfindlay) return message when local jobs_cache not found

   * PR #27766: (jfindlay) better check for debian userdel error

   * PR #27758: (iggy) Remove redundant text from syslog returner

   * PR #27841: (terminalmage) Detect Manjaro Linux as Arch derivative

   * PR #27852: (rallytime) Back-port #27806 to 2015.5

   * PR  #27838:   (basepi)   [2015.5]   Fix   highstate   outputter   for
     jobs.lookup_jid

   * PR #27791: (eguven) 2015.5 postgres_user groups backport

   * PR #27759: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR   #27732:   (jacobhammons)   update   docs   for  __virtual__  and
     __virtualname__

   * PR #27747: (Sacro) Chocolatey doesn't have a help command.

   * PR   #27733:   (jacobhammons)   hardening   topic   -   updates    to
     docs.saltstack.com theme

   * PR #27706: (jacobhammons) Assorted doc bugs

   * PR #27695: (rallytime) Back-port #27671 to 2015.5

   * PR #27524: (jfindlay) parse pkgng output in quiet mode for >= 1.6.1

   * PR #27686: (rallytime) Back-port #27476 to 2015.5

   * PR #27684: (rallytime) Back-port #27656 to 2015.5

   * PR #27683: (rallytime) Back-port #27659 to 2015.5

   * PR #27682: (rallytime) Back-port #27566 to 2015.5

   * PR #27681: (rallytime) Back-port #25928 to 2015.5

   * PR #27680: (rallytime) Back-port #27535 to 2015.5

   * PR  #27442:  (JaseFace)  Ensure  we  pass  on  the  enable setting if
     present, or use the default of True if not in build_schedule_item()

   * PR #27641: (rallytime) Gate the psutil import and add depends doc for
     diskusage beacon

   * PR #27644: (rallytime) Back-port #27640 to 2015.5

   * PR #27612: (rallytime) Fix GCE external_ip stacktraces in 2015.5

   * PR #27568: (jacobhammons) regenerated man pages

   Salt 2015.5.9 Release Notes
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-01-08T23:02:31Z

   Total Merges: 44

   Changes:

   * PR #30237: (jacobhammons) Updated  man  pages  and  doc  version  for
     2015.5.9

   * PR #30207: (rallytime) Use correct spacing in rabbitmq state examples

   * PR #30191: (jacobhammons) Updated doc site banners

   * PR  #30125: (abednarik) Update user home event when createhome is set
     to False

   * PR #30127: (jsutton) Updating documentation and example minion config
     for random_master/master_shuffle.

   * PR #30110: (markckimball) Fixed flag sent to salt.utils.http in order
     for verify_ssl to work correctly

   * PR #30093: (zmalone) Noting that file_roots and "state  tree"  should
     both be avoided

   * PR  #30097: (cachedout) Note concern about cleartext password in docs
     for shadow.gen_password

   * PR #30089: (mpreziuso)  Fixes  terminology  and  adds  more  accurate
     details about the algorithms

   * PR #30086: (cachedout) Document that gitfs needs recent libs

   * PR #30070: (cachedout) Add documentation on debugging salt-ssh

   * PR #30059: (mpreziuso) Fixes wrong function scope

   * PR #30025: (jtand) Skipping some Boto tests until resolved moto issue

   * PR #29949: (aletourneau) Enhanced netscaler docstring

   * PR #29941: (cachedout) Fix spelling error in boto_vpc

   * PR  #29908:  (cachedout)  Allow kwargs to be passed to pacman provide
     for update func

   * PR #29909: (abednarik) FreeBSD pkgng fix for non-interactive install.

   * PR #29730: (rallytime) Update docker-py version requirement to  0.6.0
     for dockerio.py files

   * PR  #29715: (rallytime) Install correct package version, if provided,
     for npm state.

   * PR #29721: (terminalmage)  Fix  display  of  multiline  strings  when
     iterating over a list

   * PR #29646: (rallytime) Don't stacktrace on kwargs.get if kwargs=None

   * PR #29673: (rallytime) Default value should be False and not 'False'

   * PR  #29527:  (jfindlay)  2015.5.7  notes:  add  note  about not being
     released

   * PR #29539: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #29504: (rallytime) Document userdata_file option for EC2 driver

   * PR #29507: (rallytime) Switch volumes  and  del_*_on_destroy  example
     ordering

   * PR #29469: (abednarik) Added Documentation note in salt cloud.

   * PR  #29461:  (dmyerscough)  Fix  resource  limits,  systemd  sets the
     default too small

   * PR #29439: (rallytime) Back-port #28656 to 2015.5

   * PR #29418: (jacobhammons) Added CVE  2015-8034  to  2015.5.8  release
     notes

   * PR #29389: (jacobhammons) updated version numbers in documentation

   * PR #28501: (twangboy) Requested fixes for 26898

   * PR #29348: (jtand) Fixes an file.search on python2.6

   * PR #29336: (rallytime) Back-port #29276 to 2015.5

   * PR #29333: (rallytime) Back-port #29280 to 2015.5

   * PR #29316: (basepi) [2015.5] Merge forward from 2014.7 to 2015.5

   * PR #29216: (clan) size is 0 doesn't mean no data, e.g, /proc/version

   * PR #29261: (attiasr) fix incorrect reinstallation of windows pkg

   * PR  #29214:  (cro)  Doc for salt.utils.http should say verify_ssl not
     ssl_verify.

   * PR #29204: (lorengordon) Use os.path.join to return full path  to  ca
     bundle

   Salt 2014.7.0 Release Notes - Codename Helium
   This  release  is the largest Salt release ever, with more features and
   commits then any previous release of Salt. Everything from the new RAET
   transport  to  major  updates in Salt Cloud and the merging of Salt API
   into the main project.

   IMPORTANT:
      The Fedora/RHEL/CentOS salt-master package  has  been  modified  for
      this  release. The following components of Salt have been broken out
      and placed into their own packages:

      * salt-syndic

      * salt-cloud

      * salt-ssh

      When the salt-master package is upgraded, these components  will  be
      removed, and they will need to be manually installed.

   IMPORTANT:
      Compound/pillar matching have been temporarily disabled for the mine
      and publish modules for this  release  due  to  the  possibility  of
      inferring  pillar  data  using pillar glob matching. A proper fix is
      now in the 2014.7 branch and scheduled for  the   2014.7.1  release,
      and  compound  matching  and  non-globbing  pillar  matching will be
      re-enabled at that point.

      Compound  and  pillar  matching  for  normal   salt   commands   are
      unaffected.

   New Transport!
   RAET Transport Option
   This  has been a HUGE amount of work, but the beta release of Salt with
   RAET is ready to go. RAET is a reliable queuing transport  system  that
   has been developed in partnership with a number of large enterprises to
   give Salt an alternative to ZeroMQ and a way to get Salt to scale  well
   beyond  tens of thousands of servers. Unlike ZeroMQ, RAET is completely
   asynchronous in every aspect of its operation and  has  been  developed
   using   the  flow  programming  paradigm.  This  allows  for  many  new
   capabilities to be added to Salt in the upcoming releases.

   Please keep in mind that this is a beta release of RAET and we hope for
   bugs  to  be  worked out, performance to be better realized and more in
   the 2015.5.0 release.

   Simply stated, users running Salt with RAET should expect some  hiccups
   as we hammer out the update. This is a BETA release of Salt RAET.

   For  information  about  how  to  use  Salt  with  RAET  please see the
   tutorial.

   Salt SSH Enhancements
   Salt SSH has just entered a new league, with  substantial  updates  and
   improvements  to make salt-ssh more reliable and easier then ever! From
   new features like the ansible roster and fileserver backends to the new
   pypi  salt-ssh  installer  to  lowered  deps  and  a swath of bugfixes,
   salt-ssh is basically reborn!

   Install salt-ssh Using pip
   Salt-ssh is now pip-installable!

   https://pypi.python.org/pypi/salt-ssh/

   Pip will bring in all of the required deps, and  while  some  deps  are
   compiled,  they  all  include pure python implementations, meaning that
   any compile errors which may be seen can be safely ignored.

      pip install salt-ssh

   Fileserver Backends
   Salt-ssh can now use the salt fileserver backend  system.  This  allows
   for  the  gitfs, hgfs, s3, and many more ways to centrally store states
   to be easily used with salt-ssh. This also  allows  for  a  distributed
   team to easily use a centralized source.

   Saltfile Support
   The  new  saltfile  system makes it easy to have a user specific custom
   extended configuration.

   Ext Pillar
   Salt-ssh can now use the external pillar system. Making it easier  then
   ever to use salt-ssh with teams.

   No More sshpass
   Thanks  to  the  enhancements in the salt vt system, salt-ssh no longer
   requires sshpass  to  send  passwords  to  ssh.  This  also  makes  the
   manipulation  of  ssh  calls  substantially more flexible, allowing for
   intercepting ssh calls in a much more fluid way.

   Pure Python Shim
   The salt-ssh call originally used  a  shell  script  to  discover  what
   version  of  python  to execute with and determine the state of the ssh
   code deployment.  This shell script  has  been  replaced  with  a  pure
   python  version  making  it easy to increase the capability of the code
   deployment without causing platform inconsistency issues with different
   shell interpreters.

   Custom Module Delivery
   Custom  modules are now seamlessly delivered. This makes the deployment
   of custom grains, states, execution modules and  returners  a  seamless
   process.

   CP Module Support
   Salt-ssh  now  makes  simple  file  transfers  easier then ever! The cp
   module  allows  for  files  to  be  conveniently  sent  from  the  salt
   fileserver system down to systems.

   More Thin Directory Options
   Salt  ssh  functions by copying a subset of the salt code, or salt thin
   down to the target system. In the past this was always  transferred  to
   /tmp/.salt and cached there for subsequent commands.

   Now,  salt  thin can be sent to a random directory and removed when the
   call is complete with the -W option. The new -W  option  still  uses  a
   static location but will clean up that location when finished.

   The  default  salt thin location is now user defined, allowing multiple
   users to cleanly access the same systems.

   State System Enhancements
   New Imperative State Keyword Listen
   The new listen and listen_in keywords allow for  completely  imperative
   states  by  calling  the  mod_watch() routine after all states have run
   instead of re-ordering the states.

   Mod Aggregate Runtime Manipulator
   The new mod_aggregate system allows for the state system to rewrite the
   state  data  during  execution. This allows for state definitions to be
   aggregated dynamically at runtime.

   The best example is found in the pkg state. If mod_aggregate is  turned
   on,  then  when  the  first pkg state is reached, the state system will
   scan all of the other running states for pkg states and take all  other
   packages  set for install and install them all at once in the first pkg
   state.

   These runtime modifications make  it  easy  to  run  groups  of  states
   together.  In  future  versions,  we hope to fill out the mod_aggregate
   system to build in more and more optimizations.

   For more documentation on mod_aggregate, see the documentation.

   New Requisites: onchanges and onfail
   The new onchanges and onchanges_in requisites make a state  apply  only
   if  there  are changes in the required state. This is useful to execute
   post hooks after changes occur on a system.

   The other new requisites, onfail, and onfail_in, allow for a  state  to
   run in reaction to the failure of another state.

   For  more  information  about  these new requisites, see the requisites
   documentation.

   Global onlyif and unless
   The  onlyif  and  unless  options  can  now  be  used  for  any   state
   declaration.

   Use names to expand and override values
   The  names  declaration  in Salt's state system can now override or add
   values to the expanded data structure. For example:

      my_users:
        user.present:
          - names:
            - larry
            - curly
            - moe:
              - shell: /bin/zsh
              - groups:
                - wheel
          - shell: /bin/bash

   Major Features
   Scheduler Additions
   The Salt scheduler system has received MAJOR enhancements, allowing for
   cron-like  scheduling  and much more granular timing routines. See here
   for more info.

   Red Hat 7 Family Support
   All the needed additions have been made to  run  Salt  on  RHEL  7  and
   derived OSes like CentOS and Scientific.

   Fileserver Backends in salt-call
   Fileserver  backends  like gitfs can now be used without a salt master!
   Just add the fileserver backend configuration to the minion config  and
   execute  salt-call.  This  has been a much-requested feature and we are
   happy to finally bring it to our users.

   Amazon Execution Modules
   An entire family of execution modules further enhancing  Salt's  Amazon
   Cloud support. They include the following:

   * Autoscale  Groups (includes state support) -- related: Launch Control
     states

   * Cloud Watch (includes state support)

   * Elastic Cache (includes state support)

   * Elastic Load Balancer (includes state support)

   * IAM Identity and Access Management (includes state support)

   * Route53 DNS (includes state support)

   * Security Groups (includes state support)

   * Simple Queue Service (includes state support)

   LXC Runner Enhancements
   BETA  The  Salt  LXC  management  system  has  received  a  number   of
   enhancements which make running an LXC cloud entirely from Salt an easy
   proposition.

   Next Gen Docker Management
   The Docker support in Salt has been increased at least  ten  fold.  The
   Docker  API  is  now completely exposed and Salt ships with Docker data
   tracking systems which make automating Docker deployments very easy.

   Peer System Performance Improvements
   The peer system communication routines have been refined  to  make  the
   peer system substantially faster.

   SDB
   Encryption at rest for configs

   GPG Renderer
   Encrypted pillar at rest

   OpenStack Expansion
   Lots of new OpenStack stuff

   Queues System
   Ran change external queue systems into Salt events

   Multi Master Failover Additions
   Connecting to multiple masters is more dynamic then ever

   Chef Execution Module
   Managing Chef with Salt just got even easier!

   salt-api Project Merge
   The  salt-api  project  has  been  merged  into  Salt  core  and is now
   available as part of the regular salt-master package  install.  No  API
   changes were made, the salt-api script and init scripts remain intact.

   salt-api  has  always  provided Yet Another Pluggable Interface to Salt
   (TM) in the form of "netapi" modules. These are modules that bind to  a
   port  and  start  a  service.  Like  many of Salt's other module types,
   netapi modules often have library and configuration  dependencies.  See
   the documentation for each module for instructions.

   SEE ALSO:
      The full list of netapi modules.

   Synchronous and Asynchronous Execution of Runner and Wheel Modules
   salt.runner.RunnerClient  and  salt.wheel.WheelClient  have both gained
   complimentary cmd_sync and cmd_async methods allowing  for  synchronous
   and  asynchronous execution of any Runner or Wheel module function, all
   protected  using  Salt's  external  authentication   system.   salt-api
   benefits from this addition as well.

   rest_cherrypy Additions
   The rest_cherrypy netapi module provides the main REST API for Salt.

   Web Hooks
   This  release  of  course includes the Web Hook additions from the most
   recent salt-api release,  which  allows  external  services  to  signal
   actions  within a Salt infrastructure. External services such as Amazon
   SNS, Travis-CI, or GitHub, as well as internal services that cannot  or
   should  not  run  a  Salt  minion  daemon  can  be  used as first-class
   components in Salt's rich orchestration capabilities.

   The raw HTTP request body is now available in the event data.  This  is
   sometimes  required information for checking an HMAC signature in order
   to verify a HTTP request. As an example, Amazon or GitHub requests  are
   signed this way.

   Generating and Accepting Minion Keys
   The  /key  convenience  URL  generates  a  public and private key for a
   minion, automatically pre-accepts the public key on  the  Salt  Master,
   and returns both keys as a tarball for download.

   This  allows  for  easily  bootstrapping the key on a new minion with a
   single HTTP call, such as with a Kickstart script,  all  using  regular
   shell tools.

      curl -sS http://salt-api.example.com:8000/keys \
              -d mid=jerry \
              -d username=kickstart \
              -d password=kickstart \
              -d eauth=pam \
              -o jerry-salt-keys.tar

   Fileserver Backend Enhancements
   All  of  the  fileserver  backends  have  been overhauled to be faster,
   lighter, and more reliable. The VCS backends (gitfs, hgfs,  and  svnfs)
   have also received a lot of new features.

   Additionally,  most  config  parameters for the VCS backends can now be
   configured on a per-remote basis, allowing for global config parameters
   to be overridden for a specific gitfs/hgfs/svnfs remote.

   New gitfs Features
   Pygit2 and Dulwich
   In  addition  to  supporting  GitPython, support for pygit2 (0.20.3 and
   newer) and dulwich have been added. Provided a  compatible  version  of
   pygit2  is  installed,  it will now be the default provider. The config
   parameter gitfs_provider has been  added  to  allow  one  to  choose  a
   specific provider for gitfs.

   Mountpoints
   Prior  to this release, to serve a file from gitfs at a salt fileserver
   URL of salt://foo/bar/baz.txt, it was  necessary  to  ensure  that  the
   parent  directories  existed  in the repository. A new config parameter
   gitfs_mountpoint allows gitfs remotes  to  be  exposed  starting  at  a
   user-defined salt:// URL.

   Environment Whitelisting/Blacklisting
   By  default, gitfs will expose all branches and tags as Salt fileserver
   environments.  Two  new  config  parameters,  gitfs_env_whitelist,  and
   gitfs_env_blacklist,  allow  more  control over which branches and tags
   are exposed. More detailed information on how these  two  options  work
   can be found in the Gitfs Walkthrough.

   Expanded Authentication Support
   As  of  pygit2  0.20.3,  both  http(s)  and  SSH key authentication are
   supported, and Salt now also supports both authentication methods  when
   using  pygit2.  Keep in mind that pygit2 0.20.3 is not yet available on
   many  platforms,  so  those  who  had  been  using  authenticated   git
   repositories  with  a passphraseless key should stick to GitPython if a
   new enough pygit2 is not yet available for the platform  on  which  the
   master is running.

   A  full  explanation  of  how to use authentication can be found in the
   Gitfs Walkthrough.

   New hgfs Features
   Mountpoints
   This feature works exactly like its gitfs counterpart. The  new  config
   parameter is called hgfs_mountpoint.

   Environment Whitelisting/Blacklisting
   This  feature  works exactly like its gitfs counterpart. The new config
   parameters are called hgfs_env_whitelist and hgfs_env_blacklist.

   New svnfs Features
   Mountpoints
   This feature works exactly like its gitfs counterpart. The  new  config
   parameter is called svnfs_mountpoint.

   Environment Whitelisting/Blacklisting
   This  feature  works exactly like its gitfs counterpart. The new config
   parameters are called svnfs_env_whitelist and svnfs_env_blacklist.

   Configurable Trunk/Branches/Tags Paths
   Prior to this release, the paths where trunk, branches, and  tags  were
   located  could  only  be  in directories named "trunk", "branches", and
   "tags" directly under the root of  the  repository.  Three  new  config
   parameters  (svnfs_trunk,  svnfs_branches,  and  svnfs_tags)  allow SVN
   repositories which are laid out differently to be used with svnfs.

   New minionfs Features
   Mountpoint
   This feature works exactly like its gitfs counterpart. The  new  config
   parameter  is  called  minionfs_mountpoint. The one major difference is
   that, as minionfs doesn't use multiple remotes (it just serves up files
   pushed  to  the  master  using  cp.push)  there  is  no such thing as a
   per-remote configuration for minionfs_mountpoint.

   Changing the Saltenv from Which Files are Served
   A new config parameter  (minionfs_env)  allows  minionfs  files  to  be
   served from a Salt fileserver environment other than base.

   Minion Whitelisting/Blacklisting
   By default, minionfs will expose the pushed files from all minions. Two
   new  config  parameters,  minionfs_whitelist,  and  minionfs_blacklist,
   allow  minionfs  to  be restricted to serve files from only the desired
   minions.

   Pyobjects Renderer
   Salt now ships  with  with  the  Pyobjects  Renderer  that  allows  for
   construction  of  States  using  pure  Python  with an idiomatic object
   interface.

   New Modules
   In addition to the Amazon  modules  mentioned  above,  there  are  also
   several other new execution modules:

   * Oracle

   * Random

   * Redis

   * Amazon Simple Queue Service

   * Block Device Management

   * CoreOS etcd

   * Genesis

   * InfluxDB

   * Server Density

   * Twilio Notifications

   * Varnish

   * ZNC IRC Bouncer

   * SMTP

   New Runners
   * Map/Reduce Style

   * Queue

   New External Pillars
   * CoreOS etcd

   New Salt-Cloud Providers
   * Aliyun ECS Cloud

   * LXC Containers

   * Proxmox (OpenVZ containers & KVM)

   Salt Call Change
   When  used  with a returner, salt-call now contacts a master if --local
   is not specicified.

   Deprecations
   salt.modules.virtualenv_mod
   * Removed  deprecated  memoize  function  from   salt/utils/__init__.py
     (deprecated)

   * Removed  deprecated  no_site_packages  argument  from create function
     (deprecated)

   * Removed  deprecated  check_dns  argument   from   minion_config   and
     apply_minion_config functions (deprecated)

   * Removed     deprecated    OutputOptionsWithTextMixIn    class    from
     salt/utils/parsers.py (deprecated)

   * Removed the following deprecated functions from salt/modules/ps.py: -
     physical_memory_usage     (deprecated)     -     virtual_memory_usage
     (deprecated)     -     cached_physical_memory     (deprecated)      -
     physical_memory_buffers (deprecated)

   * Removed  deprecated  cloud  arguments  from  cloud_config function in
     salt/config.py:   -   vm_config   (deprecated)    -    vm_config_path
     (deprecated)

   * Removed      deprecated      libcloud_version      function      from
     salt/cloud/libcloudfuncs.py (deprecated)

   * Removed deprecated CloudConfigMixIn class from  salt/utils/parsers.py
     (deprecated)

   Salt 2014.7.1 Release Notes
   release
          2015-01-12

   Version  2014.7.1  is  a  bugfix  release  for  2014.7.0.   The changes
   include:

   * Fixed gitfs serving symlinks in file.recurse states (issue 17700)

   * Fixed holding of multiple packages (YUM) when combined  with  version
     pinning (issue 18468)

   * Fixed  use  of  Jinja  templates  in  masterless  mode with non-roots
     fileserver backend (issue 17963)

   * Re-enabled pillar and compound matching for mine and  publish  calls.
     Note  that  pillar  globbing  is  still disabled for those modes, for
     security reasons.  (issue 17194)

   * Fix for tty: True in salt-ssh (issue 16847)

   * Fix for supervisord states when supervisor not  installed  to  system
     python (issue 18044)

   * Fix for logging when log_level='quiet' for cmd.run (issue 19479)

   Salt 2014.7.2 Release Notes
   release
          2015-02-09

   Version  2014.7.2  is  a  bugfix  release  for  2014.7.0.   The changes
   include:

   * Fix erroneous warnings  for  systemd  service  enabled  check  (issue
     19606)

   * Fix  FreeBSD  kernel module loading, listing, and persistence kmod (
     issue 197151, issue 19682)

   * Allow case-sensitive npm package names in the npm  state.   This  may
     break  behavior for people expecting the state to lowercase their npm
     package names for  them.   The  npm  module  was  never  affected  by
     mandatory lowercasing.  (issue 20329)

   * Deprecate  the activate parameter for pip.install for both the module
     and the state.  If bin_env is given and points to a virtualenv, there
     is  no need to activate that virtualenv in a shell for pip to install
     to the virtualenv.

   * Fix a file-locking bug in gitfs (issue 18839)

   * Deprecated archive_user in favor of standardized  user  parameter  in
     state and added group parameter.

   Salt 2014.7.3 Release Notes
   release
          TBA

   Version 2014.7.3 is a bugfix release for 2014.7.0.

   Changes:

   * Multi-master  minions  mode  no  longer  route  fileclient operations
     asymetrically.  This fixes the source of many multi-master bugs where
     the minion would become unrepsonsive from one or more masters.

   * Fix bug wherein network.iface could produce stack traces.

   * net.arp  will  no longer be made available unless arp is installed on
     the system.

   * Major performance improvements to Saltnado

   * Allow KVM module to operate under KVM itself or VMware Fusion

   * Various fixes to the Windows installation scripts

   * Fix issue where the syndic would not correctly propagate loads to the
     master job cache.

   * Improve  error  handling  on  invalid /etc/network/interfaces file in
     salt networking modules

   * Fix  bug  where  a  response  status   was   not   checked   for   in
     fileclient.get_url

   * Enable eauth when running salt in batch mode

   * Increase timeout in Boto Route53 module

   * Fix bugs with Salt's 'tar' module option parsing

   * Fix parsing of NTP servers on Windows

   * Fix issue with blockdev tuning not reporting changes correctly

   * Update to the latest Salt bootstrap script

   * Update  Linode  salt-cloud  driver  to  use  either  linode-python or
     apache-libcloud

   * Fix for s3.query function to return correct headers

   * Fix for s3.head returning None for files that exist

   * Fix the disable function in win_service module so that the service is
     disabled correctly

   * Fix  race condition between master and minion when making a directory
     when both daemons are on the same host

   * Fix an issue where file.recurse would fail at the root of an svn repo
     when the repo has a mountpoint

   * Fix  an  issue  where  file.recurse would fail at the root of an hgfs
     repo when the repo has a mountpoint

   * Fix an issue where file.recurse would fail at the root  of  an  gitfs
     repo when the repo has a mountpoint

   * Add status.master capability for Windows.

   * Various fixes to ssh_known_hosts

   * Various fixes to states.network bonding for Debian

   * The debian_ip.get_interfaces module no longer removes nameservers.

   * Better integration between grains.virtual and systemd-detect-virt and
     virt-what

   * Fix traceback in sysctl.present state output

   * Fix for issue where mount.mounted would fail when superopts were  not
     a  part  of  mount.active (extended=True). Also mount.mounted various
     fixes for Solaris and FreeBSD.

   * Fix error where datetimes were not correctly safeguarded before being
     passed into msgpack.

   * Fix  file.replace  regressions.   If the pattern is not found, and if
     dry run is False, and if backup is False, and if a pre-existing  file
     exists   with   extension   .bak,  then  that  backup  file  will  be
     overwritten. This backup behavior is a result of how fileinput works.
     Fixing  it  requires either passing through the file twice (the first
     time only to search  for  content  and  set  a  flag),  or  rewriting
     file.replace so it doesn't use fileinput

   * VCS filreserver fixes/optimizations

   * Catch fileserver configuration errors on master start

   * Raise errors on invalid gitfs configurations

   * set_locale when locale file does not exist (Redhat family)

   * Fix  to  correctly count active devices when created mdadm array with
     spares

   * Fix to correctly target minions in batch mode

   * Support ssh:// urls using the gitfs dulwhich backend

   * New fileserver runner

   * Fix various bugs with argument parsing to the publish module.

   * Fix disk.usage for Synology OS

   * Fix issue with tags occurring twice with docker.pulled

   * Fix incorrect key error in SMTP returner

   * Fix condition which would remount loopback filesystems on every state
     run

   * Remove  requsites  from  listens  after  they are called in the state
     system

   * Make system implementation of service.running aware of legacy service
     calls

   * Fix  issue where publish.publish would not handle duplicate responses
     gracefully.

   * Accept Kali Linux for aptpkg salt execution module

   * Fix bug where cmd.which could not handle a dirname as an argument

   * Fix issue in ps.pgrep where exceptions were thrown on Windows.

   Known issues:

   * In multimaster mode, a minion may become temporarily unresponsive  if
     modules  or  pillars  are refreshed at the same time that one or more
     masters are down. This can be worked around by setting 'auth_timeout'
     and 'auth_tries' down to shorter periods.

   Salt 2014.7.4 Release Notes
   release
          2015-03-30

   Version 2014.7.4 is a bugfix release for 2014.7.0.

   This  is  a  security release. The security issues fixed have only been
   present since 2014.7.0, and only users of the two  listed  modules  are
   vulnerable. The following CVEs have been resolved:

   * CVE-2015-1838    SaltStack:    insecure   /tmp   file   handling   in
     salt/modules/serverdensity_device.py

   * CVE-2015-1839   SaltStack:   insecure   /tmp   file    handling    in
     salt/modules/chef.py

   Changes:

   * Multi-master  minions  mode  no  longer  route  fileclient operations
     asymetrically.  This fixes the source of many multi-master bugs where
     the minion would become unrepsonsive from one or more masters.

   * Fix bug wherein network.iface could produce stack traces.

   * net.arp  will  no longer be made available unless arp is installed on
     the system.

   * Major performance improvements to Saltnado

   * Allow KVM module to operate under KVM itself or VMware Fusion

   * Various fixes to the Windows installation scripts

   * Fix issue where the syndic would not correctly propagate loads to the
     master job cache.

   * Improve  error  handling  on  invalid /etc/network/interfaces file in
     salt networking modules

   * Fix  bug  where  a  response  status   was   not   checked   for   in
     fileclient.get_url

   * Enable eauth when running salt in batch mode

   * Increase timeout in Boto Route53 module

   * Fix bugs with Salt's 'tar' module option parsing

   * Fix parsing of NTP servers on Windows

   * Fix issue with blockdev tuning not reporting changes correctly

   * Update to the latest Salt bootstrap script

   * Update  Linode  salt-cloud  driver  to  use  either  linode-python or
     apache-libcloud

   * Fix for s3.query function to return correct headers

   * Fix for s3.head returning None for files that exist

   * Fix the disable function in win_service module so that the service is
     disabled correctly

   * Fix  race condition between master and minion when making a directory
     when both daemons are on the same host

   * Fix an issue where file.recurse would fail at the root of an svn repo
     when the repo has a mountpoint

   * Fix  an  issue  where  file.recurse would fail at the root of an hgfs
     repo when the repo has a mountpoint

   * Fix an issue where file.recurse would fail at the root  of  an  gitfs
     repo when the repo has a mountpoint

   * Add status.master capability for Windows.

   * Various fixes to ssh_known_hosts

   * Various fixes to states.network bonding for Debian

   * The debian_ip.get_interfaces module no longer removes nameservers.

   * Better integration between grains.virtual and systemd-detect-virt and
     virt-what

   * Fix traceback in sysctl.present state output

   * Fix for issue where mount.mounted would fail when superopts were  not
     a  part  of  mount.active (extended=True). Also mount.mounted various
     fixes for Solaris and FreeBSD.

   * Fix error where datetimes were not correctly safeguarded before being
     passed into msgpack.

   * Fix  file.replace  regressions.   If the pattern is not found, and if
     dry run is False, and if backup is False, and if a pre-existing  file
     exists   with   extension   .bak,  then  that  backup  file  will  be
     overwritten. This backup behavior is a result of how fileinput works.
     Fixing  it  requires either passing through the file twice (the first
     time only to search  for  content  and  set  a  flag),  or  rewriting
     file.replace so it doesn't use fileinput

   * VCS filreserver fixes/optimizations

   * Catch fileserver configuration errors on master start

   * Raise errors on invalid gitfs configurations

   * set_locale when locale file does not exist (Redhat family)

   * Fix  to  correctly count active devices when created mdadm array with
     spares

   * Fix to correctly target minions in batch mode

   * Support ssh:// urls using the gitfs dulwhich backend

   * New fileserver runner

   * Fix various bugs with argument parsing to the publish module.

   * Fix disk.usage for Synology OS

   * Fix issue with tags occurring twice with docker.pulled

   * Fix incorrect key error in SMTP returner

   * Fix condition which would remount loopback filesystems on every state
     run

   * Remove  requsites  from  listens  after  they are called in the state
     system

   * Make system implementation of service.running aware of legacy service
     calls

   * Fix  issue where publish.publish would not handle duplicate responses
     gracefully.

   * Accept Kali Linux for aptpkg salt execution module

   * Fix bug where cmd.which could not handle a dirname as an argument

   * Fix issue in ps.pgrep where exceptions were thrown on Windows.

   Known issues:

   * In multimaster mode, a minion may become temporarily unresponsive  if
     modules  or  pillars  are refreshed at the same time that one or more
     masters are down. This can be worked around by setting 'auth_timeout'
     and 'auth_tries' down to shorter periods.

   * There  are  known  issues  with batch mode operating on the incorrect
     number of minions.  This bug can be patched with the change  in  Pull
     Request #22464.

   * The  fun,  state,  and  unless  keywords  are  missing from the state
     internals, which can cause problems running some states. This bug can
     be patched with the change in Pull Request #22365.

   Salt 2014.7.5 Release Notes
   release
          2015-04-16

   Version 2014.7.5 is a bugfix release for 2014.7.0.

   Changes:

   * Fixed a key error bug in salt-cloud

   * Updated man pages to better match documentation

   * Fixed bug concerning high CPU usage with salt-ssh

   * Fixed bugs with remounting cvfs and fuse filesystems

   * Fixed bug with alowing requisite tracking of entire sls files

   * Fixed    bug    with    aptpkg.mod_repo    returning   OK   even   if
     apt-add-repository fails

   * Increased frequency of ssh terminal output checking

   * Fixed malformed locale string in localmod module

   * Fixed checking of available version of package  when  accept_keywords
     were changed

   * Fixed bug to make git.latest work with empty repositories

   * Added  **kwargs  to  service.mod_watch  which  removes warnings about
     enable and __reqs__ not being supported by the function

   * Improved state comments to not grow so quickly on failed requisites

   * Added force argument to service to trigger force_reload

   * Fixed bug to andle pkgrepo keyids that have been converted to int

   * Fixed module.portage_config bug with appending accept_keywords

   * Fixed bug to correctly report disk usage on windows minion

   * Added the ability to specify key prefix for S3 ext_pillar

   * Fixed issues with batch mode operating on  the  incorrect  number  of
     minions

   * Fixed  a  bug  with  the  proxmox cloud provider stacktracing on disk
     definition

   * Fixed a bug with the changes dictionary in the file state

   * Fixed the TCP keep alive settings to work better with SREQ caching

   * Fixed many bugs within the iptables state and module

   * Fixed bug with states by adding fun, state, and unless to  the  state
     runtime internal keywords listing

   * Added ability to eAuth against Active Directory

   * Fixed some salt-ssh issues when running on Fedora 21

   * Fixed grains.get_or_set_hash to work with multiple entries under same
     key

   * Added better explanations and more examples of how the Reactor  calls
     functions to docs

   * Fixed  bug  to  not  pass  ex_config_drive  to  libcloud  unless it's
     explicitly enabled

   * Fixed bug with pip.install on windows

   * Fixed bug where puppet.run always returns a 0 retcode

   * Fixed race condition bug with minion scheduling via pillar

   * Made efficiency improvements and bug fixes to the windows installer

   * Updated environment variables to fix bug  with  pygit2  when  running
     salt as non-root user

   * Fixed cas behavior on data module -- data.cas was not saving changes

   * Fixed GPG rendering error

   * Fixed strace error in virt.query

   * Fixed stacktrace when running chef-solo command

   * Fixed  possible bug wherein uncaught exceptions seem to make zmq3 tip
     over when threading is involved

   * Fixed argument passing to the reactor

   * Fixed glibc caching to prevent bug where salt-minion  getaddrinfo  in
     dns_check() never got updated nameservers

   Known issues:

   * In  multimaster mode, a minion may become temporarily unresponsive if
     modules or pillars are refreshed at the same time that  one  or  more
     masters are down. This can be worked around by setting 'auth_timeout'
     and 'auth_tries' down to shorter periods.

   Salt 2014.7.6 Release Notes
   release
          2015-05-18

   Version 2014.7.6 is a bugfix release for 2014.7.0.

   This release is a security release. A minor issue was found,  as  cited
   below:

   * CVE-2015-4017  --  Certificates  are  not verified when connecting to
     server in the Aliyun and Proxmox modules

   Only users of the Aliyun or Proxmox cloud  modules  are  at  risk.  The
   vulnerability does not exist in the latest 2015.5.0 release of Salt.

   Changes:

   * salt.runners.cloud.action()  has  changed the fun keyword argument to
     func.  Please update any calls to this function in the cloud runner.

   Extended     Changelog     Courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   * PR    #23810:    (rallytime)    Backport    #23757    to   2014.7   @
     2015-05-18T15:30:21Z

     * PR #23757: (clan) use abspath, do not eliminating symlinks |  refs:
       #23810

     * aee00c8 Merge pull request #23810 from rallytime/bp-23757

     * fb32c32 use abspath, do not eliminating symlinks

   * PR  #23809: (rallytime) Fix virtualport section of virt.get_nics loop
     @ 2015-05-18T15:30:09Z

     * ISSUE  #20198:  (jcftang)  virt.get_graphics,   virt.get_nics   are
       broken, in turn breaking other things | refs: #23809

     * PR #21487: (rallytime) Backport #21469 to 2014.7 | refs: #23809

     * PR   #21469:  (vdesjardins)  fixes  #20198:  virt.get_graphics  and
       virt.get_nics calls in module virt | refs: #21487

     * 6b3352b Merge pull request #23809 from rallytime/virt_get_nics_fix

     * 0616fb7 Fix virtualport section of virt.get_nics loop

   * PR #23823: (gtmanfred) add link local for ipv6 @ 2015-05-17T12:48:25Z

     * 188f03f Merge pull request #23823 from gtmanfred/2014.7

     * 5ef006d add link local for ipv6

   * PR  #23802:  (gtmanfred)  if  it  is  ipv6  ip_to_int  will  fail   @
     2015-05-16T04:06:59Z

     * PR  #23573:  (techhat)  Scan  all available networks for public and
       private IPs | refs: #23802

     * f3ca682 Merge pull request #23802 from gtmanfred/2014.7

     * 2da98b5 if it is ipv6 ip_to_int will fail

   * PR #23488: (cellscape) LXC cloud fixes @ 2015-05-15T18:09:35Z

     * ISSUE #16424: (stanvit) salt-run cloud.create fails with saltify

     * d9af0c3 Merge pull request #23488 from cellscape/lxc-cloud-fixes

     * 64250a6 Remove profile from opts after creating LXC container

     * c4047d2 Set destroy=True in opts when destroying cloud instance

     * 9e1311a Store instance names in opts when performing cloud action

     * 934bc57 Correctly pass custom env to lxc-attach

     * 7fb85f7 Preserve test=True option in cloud states

     * 9771b5a Fix detection of absent LXC container in cloud state

     * fb24f0c Report failure when failed to create/clone LXC container

     * 2d9aa2b Avoid shadowing variables in lxc module

     * 792e102     Allow      overriding      profile      options      in
       lxc.cloud_init_interface

     * 42bd64b Return changes on successful lxc.create from salt-cloud

     * 4409eab Return correct result when creating cloud LXC container

     * 377015c  Issue  #16424: List all providers when creating salt-cloud
       instance without profile

   * PR #23748: (basepi) [2014.7] Log salt-ssh roster render  errors  more
     assertively and verbosely @ 2015-05-14T22:38:10Z

     * ISSUE  #22332:  (rallytime)  [salt-ssh]  Add  a  check  for host in
       /etc/salt/roster | refs: #23748

     * 808bbe1      Merge       pull       request       #23748       from
       basepi/salt-ssh.roster.host.check

     * bc53e04 Log entire exception for render errors in roster

     * 753de6a Log render errors in roster to error level

     * e01a7a9 Always let the real YAML error through

   * PR  #23731:  (twangboy) Fixes #22959: Trying to add a directory to an
     unmapped drive in windows @ 2015-05-14T21:59:14Z

     * ISSUE   #22959:   (highlyunavailable)   Windows   Salt   hangs   if
       file.directory is trying to write to a drive that doesn't exist

     * 72cf360 Merge pull request #23731 from twangboy/fix_22959

     * 88e5495  Fixes  #22959:  Trying  to  add a directory to an unmapped
       drive in windows

   * PR   #23730:   (rallytime)    Backport    #23729    to    2014.7    @
     2015-05-14T21:58:34Z

     * PR  #23729: (rallytime) Partially merge #23437 (grains fix) | refs:
       #23730

     * PR #23437: (cedwards) Grains item patch | refs: #23729

     * 2610195 Merge pull request #23730 from rallytime/bp-23729

     * 1877cae adding support for nested grains to grains.item

   * PR #23688: (twangboy) Added inet_pton  to  utils/validate/net.py  for
     ip.set_static_ip in windows @ 2015-05-14T16:15:56Z

     * 3e9df88 Merge pull request #23688 from twangboy/fix_23415

     * 6a91169 Fixed unused-import pylint error

     * 5e25b3f fixed pylint errors

     * 1a96766    Added    inet_pton    to    utils/validate/net.py    for
       ip.set_static_ip in windows

   * PR   #23680:   (cachedout)   Rename   kwarg   in   cloud   runner   @
     2015-05-13T19:44:02Z

     * ISSUE  #23403:  (iamfil) salt.runners.cloud.action fun parameter is
       replaced | refs: #23680

     * 1b86460 Merge pull request #23680 from cachedout/issue_23403

     * d5986c2 Rename kwarg in cloud runner

   * PR #23674: (cachedout) Handle lists correctly in grains.list_prsesent
     @ 2015-05-13T18:34:58Z

     * ISSUE  #23548:  (kkaig)  grains.list_present produces incorrect (?)
       output | refs: #23674

     * cd64af0 Merge pull request #23674 from cachedout/issue_23548

     * da8a2f5 Handle lists correctly in grains.list_prsesent

   * PR #23672: (twangboy) Fix user present @ 2015-05-13T18:30:09Z

     * d322a19 Merge pull request #23672 from twangboy/fix_user_present

     * 731e7af Merge branch '2014.7' of  https://github.com/saltstack/salt
       into fix_user_present

     * d6f70a4 Fixed user.present to create password in windows

   * PR    #23670:    (rallytime)    Backport    #23607    to   2014.7   @
     2015-05-13T18:27:17Z

     * ISSUE #23604: (Azidburn) service.dead on systemd Minion  create  an
       Error Message | refs: #23607

     * PR  #23607: (Azidburn) Fix for #23604. No error reporting. Exitcode
       !=0 are ok | refs: #23670

     * 43f7025 Merge pull request #23670 from rallytime/bp-23607

     * ed30dc4 Fix for #23604. No error reporting. Exitcode !=0 are ok

   * PR  #23661:  (rallytime)  Merge  #23640   with   whitespace   fix   @
     2015-05-13T15:47:30Z

     * ISSUE  #22141: (Deshke) grains.get_or_set_hash render error if hash
       begins with "%" | refs: #23640

     * PR  #23640:  (cachedout)  Add  warning  to  get_or_set_hash   about
       reserved chars | refs: #23661

     * 0f006ac Merge pull request #23661 from rallytime/merge-23640

     * 4427f42 Whitespace fix

     * dd91154 Add warning to get_or_set_hash about reserved chars

   * PR  #23639:  (cachedout)  Handle  exceptions  raised by __virtual__ @
     2015-05-13T15:11:12Z

     * ISSUE #23452: (michaelforge) minion  crashed  with  empty  grain  |
       refs: #23639

     * 84e2ef8 Merge pull request #23639 from cachedout/issue_23452

     * d418b49 Syntax error!

     * 45b4015 Handle exceptions raised by __virtual__

   * PR    #23637:    (cachedout)   Convert   str   master   to   list   @
     2015-05-13T15:08:19Z

     * ISSUE #23611: (hubez) master_type set to 'failover' but 'master' is
       not of type list but of type <type 'str'> | refs: #23637

     * bd9b94b Merge pull request #23637 from cachedout/issue_23611

     * 56cb1f5 Fix typo

     * f6fcf19 Convert str master to list

   * PR    #23595:    (rallytime)    Backport    #23549    to   2014.7   @
     2015-05-12T21:19:40Z

     * PR #23549: (vr-jack) Update __init__.py | refs: #23595

     * f20c0e4 Merge pull request #23595 from rallytime/bp-23549

     * 6efcac0 Update __init__.py

   * PR   #23594:   (rallytime)    Backport    #23496    to    2014.7    @
     2015-05-12T21:19:34Z

     * ISSUE   #23110:   (martinhoefling)  Copying  files  from  gitfs  in
       file.recurse state fails

     * PR #23496: (martinhoefling) Fix for issue #23110 | refs: #23594

     * 1acaf86 Merge pull request #23594 from rallytime/bp-23496

     * d5ae1d2 Fix for issue #23110 This resolves issues when the  freshly
       created directory is removed by fileserver.update.

   * PR    #23593:    (rallytime)    Backport    #23442    to   2014.7   @
     2015-05-12T21:19:26Z

     * PR #23442: (clan) add directory itself to keep list | refs: #23593

     * 2c221c7 Merge pull request #23593 from rallytime/bp-23442

     * 39869a1 check w/ low['name'] only

     * 304cc49 another fix for file defined w/ id, but require name

     * 8814d41 add directory itself to keep list

   * PR  #23606:  (twangboy)  Fixed  checkbox  for  starting  service  and
     actually starting it @ 2015-05-12T21:18:50Z

     * fadd1ef Merge pull request #23606 from twangboy/fix_installer

     * 038331e  Fixed  checkbox for starting service and actually starting
       it

   * PR   #23592:   (rallytime)    Backport    #23389    to    2014.7    @
     2015-05-12T16:44:42Z

     * ISSUE  #22908: (karanjad) Add failhard option to salt orchestration
       | refs: #23389

     * PR #23389: (cachedout) Correct fail_hard typo | refs: #23592

     * 10b3f0f Merge pull request #23592 from rallytime/bp-23389

     * 734cc43 Correct fail_hard typo

   * PR #23573: (techhat) Scan  all  available  networks  for  public  and
     private IPs | refs: #23802 @ 2015-05-12T15:22:22Z

     * cd34b9b Merge pull request #23573 from techhat/novaquery

     * f92db5e Linting

     * 26e00d3 Scan all available networks for public and private IPs

   * PR    #23558:    (jfindlay)    reorder    emerge   command   line   @
     2015-05-12T15:17:46Z

     * ISSUE #23479: (danielmorlock) Typo in pkg.removed  for  Gentoo?   |
       refs: #23558

     * 2a72cd7 Merge pull request #23558 from jfindlay/fix_ebuild

     * 45404fb reorder emerge command line

   * PR   #23530:  (dr4Ke)  salt-ssh  state:  fix  including  all  salt://
     references @ 2015-05-12T15:13:43Z

     * ISSUE #23355: (dr4Ke) salt-ssh: 'sources: salt://' files from 'pkg'
       state are not included in salt_state.tgz | refs: #23530

     * a664a3c       Merge       pull       request       #23530      from
       dr4Ke/fix_salt-ssh_to_include_pkg_sources

     * 5df6a80 fix pylint warning

     * d0549e5 salt-ssh state: fix including all salt:// references

   * PR #23433:  (twangboy)  Obtain  all  software  from  the  registry  @
     2015-05-11T22:47:52Z

     * ISSUE  #23004:  (b18)  2014.7.5 - Windows - pkg.list_pkgs - "nxlog"
       never shows up in output.  | refs: #23433

     * 55c3869 Merge pull request #23433 from twangboy/list_pkgs_fix

     * 8ab5b1b Fix pylint error

     * 2d11d65 Obtain all software from the registry

   * PR   #23554:   (jleroy)   Debian:   Hostname   always    updated    @
     2015-05-11T21:57:00Z

     * 755bed0 Merge pull request #23554 from jleroy/debian-hostname-fix

     * 5ff749e Debian: Hostname always updated

   * PR  #23551:  (dr4Ke)  grains.append  unit  tests, related to #23474 @
     2015-05-11T21:54:25Z

     * 6ec87ce      Merge       pull       request       #23551       from
       dr4Ke/grains.append_unit_tests

     * ebff9df fix pylint errors

     * c495404 unit tests for grains.append module function

     * 0c9a323 use MagickMock

     * c838a22 unit tests for grains.append module function

   * PR  #23474:  (dr4Ke)  Fix  grains.append  in nested dictionary grains
     #23411 @ 2015-05-11T18:00:21Z

     * ISSUE #23411: (dr4Ke) grains.append should work at any level  of  a
       grain | refs: #23440

     * PR  #23440:  (dr4Ke)  fix grains.append in nested dictionary grains
       #23411 | refs: #23474

     * e96c5c5      Merge       pull       request       #23474       from
       dr4Ke/fix_grains.append_nested

     * a01a5bb grains.get, parameter delimititer, versionadded: 2014.7.6

     * b39f504 remove debugging output

     * b6e15e2 fix grains.append in nested dictionary grains #23411

   * PR #23537: (t0rrant) Update changelog @ 2015-05-11T17:02:16Z

     * ab7e1ae Merge pull request #23537 from t0rrant/patch-1

     * 8e03cc9 Update changelog

   * PR #23538: (cro) Update date in LICENSE file @ 2015-05-11T15:19:25Z

     * b79fed3 Merge pull request #23538 from cro/licupdate

     * 345efe2 Update date in LICENSE file

   * PR  #23505:  (aneeshusa)  Remove  unused  ssh config validator. Fixes
     #23159.  @ 2015-05-09T13:24:15Z

     * ISSUE #23159: (aneeshusa) Unused validator

     * a123a36      Merge       pull       request       #23505       from
       aneeshusa/remove-unused-ssh-config-validator

     * 90af167 Remove unused ssh config validator. Fixes #23159.

   * PR   #23467:   (slinu3d)   Added   AWS   v4   signature   support   @
     2015-05-08T14:36:19Z

     * ISSUE #20518: (ekle) module s3.get does not support eu-central-1  |
       refs: #23467

     * ca2c21a Merge pull request #23467 from slinu3d/2014.7

     * 0b4081d Fixed pylint error at line 363

     * 5be5eb5 Fixed pylink errors

     * e64f374 Fixed lint errors

     * b9d1ac4 Added AWS v4 signature support

   * PR  #23444:  (techhat)  Add  create_attach_volume  to  nova  driver @
     2015-05-07T19:51:32Z

     * e6f9eec Merge pull request #23444 from techhat/novacreateattach

     * ebdb7ea Add create_attach_volume to nova driver

   * PR #23460: (s0undt3ch) [2014.7] Update  to  latest  stable  bootstrap
     script v2015.05.07 @ 2015-05-07T19:10:54Z

     * ISSUE #563: (chutz) pidfile support for minion and master daemons |
       refs: #23460

     * e331463      Merge       pull       request       #23460       from
       s0undt3ch/hotfix/bootstrap-script-2014.7

     * edcd0c4 Update to latest stable bootstrap script v2015.05.07

   * PR   #23439:   (techhat)   Add  wait_for_passwd_maxtries  variable  @
     2015-05-07T07:28:56Z

     * 7a8ce1a Merge pull request #23439 from techhat/maxtries

     * 0ad3ff2 Add wait_for_passwd_maxtries variable

   * PR #23422: (cro) $HOME should not be used, some shells don't set  it.
     @ 2015-05-06T21:02:36Z

     * 644eb75 Merge pull request #23422 from cro/gce_sh_home

     * 4ef9e6b Don't use $HOME to find user's directory, some shells don't
       set it

   * PR  #23425:  (basepi)  [2014.7]  Fix  typo   in   FunctionWrapper   @
     2015-05-06T20:38:03Z

     * ef17ab4 Merge pull request #23425 from basepi/functionwrapper_typo

     * c390737 Fix typo in FunctionWrapper

   * PR    #23385:    (rallytime)    Backport    #23346    to   2014.7   @
     2015-05-06T20:12:29Z

     * PR #23346:  (ericfode)  Allow  file_map  in  salt-cloud  to  handle
       folders.  | refs: #23385

     * 1b13ec0 Merge pull request #23385 from rallytime/bp-23346

     * 9efc13c more linting fixes

     * cf131c9 cleaned up some pylint errors

     * f981699  added  logic  to  sftp_file  and  file_map to allow folder
       uploads using file_map

   * PR #23414: (jfindlay) 2015.2 -> 2015.5 @ 2015-05-06T20:04:02Z

     * f8c7a62 Merge pull request #23414 from jfindlay/update_branch

     * 8074d16 2015.2 -> 2015.5

   * PR #23404: (hvnsweeting) saltapi cherrypy: initialize var  when  POST
     body is empty @ 2015-05-06T17:35:56Z

     * 54b3bd4       Merge       pull       request       #23404      from
       hvnsweeting/cherrypy-post-emptybody-fix

     * f85f8f9 initialize var when POST body is empty

   * PR #23409: (terminalmage) Update Lithium docstrings in 2014.7  branch
     @ 2015-05-06T16:20:46Z

     * 160f703       Merge       pull       request       #23409      from
       terminalmage/update-lithium-docstrings-2014.7

     * bc97d01 Fix sphinx typo

     * 20006b0 Update Lithium docstrings in 2014.7 branch

   * PR #23397: (jfindlay) add  more  flexible  whitespace  to  locale_gen
     search @ 2015-05-06T03:44:11Z

     * ISSUE  #17245: (tomashavlas) localemod does not generate locale for
       Arch | refs: #23307 #23397

     * aa5fb0a Merge pull request #23397 from jfindlay/fix_locale_gen

     * 0941fef add more flexible whitespace to locale_gen search

   * PR #23368: (kaithar) Backport #23367 to 2014.7 @ 2015-05-05T21:42:26Z

     * PR #23367: (kaithar) Put the sed insert statement back  in  to  the
       output.  | refs: #23368

     * PR  #18368:  (basepi)  Merge forward from 2014.7 to develop | refs:
       #23367 #23368

     * 0c76dd4 Merge pull request #23368 from kaithar/bp-23367

     * 577f419 Pylint fix

     * 8d9acd1 Put the sed insert statement back in to the output.

   * PR #23350: (lorengordon)  Append/prepend:  search  for  full  line  @
     2015-05-05T21:42:11Z

     * ISSUE  #23294: (variia) file.replace fails to append if repl string
       partially available | refs: #23350

     * 3493cc1      Merge       pull       request       #23350       from
       lorengordon/file.replace_assume_line

     * b60e224 Append/prepend: search for full line

   * PR   #23341:   (cachedout)   Fix   syndic  pid  and  logfile  path  @
     2015-05-05T21:29:10Z

     * ISSUE #23026: (adelcast) Incorrect salt-syndic logfile and  pidfile
       locations | refs: #23341

     * 7be5c48 Merge pull request #23341 from cachedout/issue_23026

     * e98e65e Fix tests

     * 6011b43 Fix syndic pid and logfile path

   * PR  #23272:  (basepi) [2014.7] Allow salt-ssh minion config overrides
     via master config and roster | refs: #23347 @ **

     * ISSUE #19114: (pykler) salt-ssh and gpg  pillar  renderer  |  refs:
       #23188 #23272 #23347

     * PR  #23188:  (basepi)  [2014.7]  Work  around  bug  in  salt-ssh in
       config.get for gpg renderer | refs: #23272

     * ea61abf      Merge       pull       request       #23272       from
       basepi/salt-ssh.minion.config.19114

     * c223309 Add versionadded

     * be7407f Lint

     * c2c3375 Missing comma

     * 8e3e8e0 Pass the minion_opts through the FunctionWrapper

     * cb69cd0  Match  the  master  config  template  in the master config
       reference

     * 87fc316 Add Salt-SSH section to master config template

     * 91dd9dc Add ssh_minion_opts to master config ref

     * c273ea1 Add minion config to salt-ssh doc

     * a0b6b76 Add minion_opts to roster docs

     * 5212c35 Accept minion_opts from the target information

     * e2099b6 Process ssh_minion_opts from master config

     * 3b64214 Revert "Work around bug in salt-ssh in config.get  for  gpg
       renderer"

     * 494953a Remove the strip (embracing multi-line YAML dump)

     * fe87f0f Dump multi-line yaml into the SHIM

     * b751a72 Inject local minion config into shim if available

   * PR      #23347:      (basepi)      [2014.7]     Salt-SSH     Backport
     FunctionWrapper.__contains__ @ 2015-05-05T14:13:21Z

     * ISSUE #19114: (pykler) salt-ssh and gpg  pillar  renderer  |  refs:
       #23188 #23272 #23347

     * PR #23272: (basepi) [2014.7] Allow salt-ssh minion config overrides
       via master config and roster | refs: #23347

     * PR #23188:  (basepi)  [2014.7]  Work  around  bug  in  salt-ssh  in
       config.get for gpg renderer | refs: #23272

     * 4f760dd       Merge       pull       request       #23347      from
       basepi/salt-ssh.functionwrapper.contains.19114

     * 30595e3 Backport FunctionWrapper.__contains__

   * PR  #23344:  (cachedout)  Explicitly  set  file_client  on  master  @
     2015-05-04T23:21:48Z

     * ISSUE #22742: (hvnsweeting) salt-master says: "This master address:
       'salt' was previously resolvable but  now  fails  to  resolve!"   |
       refs: #23344

     * 02658b1 Merge pull request #23344 from cachedout/issue_22742

     * 5adc96c Explicitly set file_client on master

   * PR   #23318:   (cellscape)  Honor  seed  argument  in  LXC  container
     initializaton @ 2015-05-04T20:58:12Z

     * PR #23311: (cellscape) Fix  new  container  initialization  in  LXC
       runner | refs: #23318

     * ba7605d       Merge       pull       request       #23318      from
       cellscape/honor-seed-argument

     * 228b1be Honor seed argument in LXC container initializaton

   * PR    #23307:    (jfindlay)    check    for     /etc/locale.gen     @
     2015-05-04T20:56:32Z

     * ISSUE  #17245: (tomashavlas) localemod does not generate locale for
       Arch | refs: #23307 #23397

     * 4ac4509 Merge pull request #23307 from jfindlay/fix_locale_gen

     * 101199a check for /etc/locale.gen

   * PR #23324: (s0undt3ch) [2014.7] Update to the latest  stable  release
     of the bootstrap script v2015.05.04 @ 2015-05-04T16:28:30Z

     * ISSUE  #580:  (thatch45)  recursive  watch not being caught | refs:
       #23324

     * ISSUE #552: (jhutchins) Support require and watch  under  the  same
       state dec | refs: #23324

     * PR  #589:  (epoelke) add --quiet and --outfile options to saltkey |
       refs: #23324

     * PR #567: (bastichelaar) Added upstart module | refs: #23324

     * PR  #560:  (UtahDave)  The  runas  feature  that   was   added   in
       93423aa2e5e4b7de6452090b0039560d2b13...  | refs: #23324

     * PR #504: (SEJeff) File state goodies | refs: #23324

     * f790f42       Merge       pull       request       #23324      from
       s0undt3ch/hotfix/bootstrap-script-2014.7

     * 6643e47 Update to the latest stable release of the bootstrap script
       v2015.05.04

   * PR  #23329:  (cro)  Require  requests  to verify cert when talking to
     aliyun and proxmox cloud providers @ 2015-05-04T16:18:17Z

     * 5487367 Merge pull request #23329 from cro/cloud_verify_cert

     * 860d4b7 Turn on ssl verify for requests.

   * PR #23311: (cellscape) Fix new container initialization in LXC runner
     | refs: #23318 @ 2015-05-04T09:55:29Z

     * ea20176       Merge       pull       request       #23311      from
       cellscape/fix-salt-cloud-lxc-init

     * 76fbb34 Fix new container initialization in LXC runner

   * PR #23298: (chris-prince) Fixed  issue  #18880  in  2014.7  branch  @
     2015-05-03T15:49:41Z

     * ISSUE  #18880:  (johtso)  npm  installed  breaks  when  a module is
       missing

     * c399b8f Merge pull request #23298 from chris-prince/2014.7

     * 0fa25db Fixed issue #18880 in 2014.7 branch

   * PR  #23292:  (rallytime)   Merge   #23151   with   pylint   fixes   @
     2015-05-02T03:54:12Z

     * ISSUE  #23148:  (cr1st1p)  virt  -  error handling bogus if machine
       image location is wrong

     * PR #23151: (cr1st1p) Fixes #23148 | refs: #23292

     * 16ecefd Merge pull request #23292 from rallytime/merge-23151

     * 8ff852a Merge #23151 with pylint fixes

     * 8ffa12e Fixes #23148

   * PR #23274: (basepi) [2014.7] Reduce salt-ssh debug  log  verbosity  @
     2015-05-01T20:19:23Z

     * ce24315       Merge       pull       request       #23274      from
       basepi/salt-ssh.debug.verbosity

     * ecee6c6 Log stdout and stderr to trace

     * 08f54d7 Log stdout and stderr to trace as well

     * 9b9c30f Reduce salt-ssh debug log verbosity

   * PR  #23261:  (rallytime)  Fix   tornado   websocket   event   handler
     registration @ 2015-05-01T18:20:31Z

     * ISSUE  #22605:  (mavenAtHouzz)  Tornado  websockets  event Handlers
       registration are incorrect | refs: #23261

     * 7b55e43 Merge pull request #23261 from rallytime/fix-22605

     * 4950fbf Fix tornado websocket event handler registration

   * PR #23258: (teizz) TCP keepalives on  the  ret  side,  Revisited.   @
     2015-05-01T16:13:49Z

     * 83ef7cb       Merge       pull       request       #23258      from
       teizz/ret_keepalive_2014_7_5

     * 0b9fb6f The fixes by cachedout which were backported into 2015_2
       were  missing  a  single  parameter  thus  not  setting  up the TCP
       keepalive for the ZeroMQ Channel by default.

   * PR #23241: (techhat) Move iptables  log  options  after  the  jump  @
     2015-05-01T01:31:59Z

     * ISSUE  #23224:  (twellspring) iptables.append --log parameters must
       be after --jump LOG | refs: #23241

     * 8de3c83 Merge pull request #23241 from techhat/issue23224

     * 87f7948 Move iptables log options after the jump

   * PR   #23228:   (rallytime)    Backport    #23171    to    2014.7    @
     2015-04-30T21:09:45Z

     * PR  #23171:  (skizunov)  Bugfix: 'clean_proc_dir' is broken | refs:
       #23228

     * f20210e Merge pull request #23228 from rallytime/bp-23171

     * e670e99 Bugfix: 'clean_proc_dir' is broken

   * PR   #23227:   (rallytime)    Backport    #22808    to    2014.7    @
     2015-04-30T21:09:14Z

     * ISSUE  #22703:  (Xiol)  salt-ssh  does not work with list matcher |
       refs: #22808

     * PR #22808: (basepi) [2015.2] Add list targeting  to  salt-ssh  flat
       roster | refs: #23227

     * 721cc28 Merge pull request #23227 from rallytime/bp-22808

     * d208a00 Dict, not list

     * a3f529e It's already been converted to a list

     * dd57f2d Add list targeting to salt-ssh flat roster

   * PR    #22823:    (hvnsweeting)   22822   file   directory   clean   @
     2015-04-30T15:25:51Z

     * 82c22af      Merge       pull       request       #22823       from
       hvnsweeting/22822-file-directory-clean

     * c749c27 fix lint - remove unnecessary parenthesis

     * cb3dfee refactor

     * 8924b5a refactor: use relpath instead of do it manually

     * d3060a5 refactor

     * 5759a0e  bugfix:  fix  file.directory  clean=True  when  it require
       parent dir

   * PR #22977: (bersace) Fix fileserver backends __opts__ overwritten  by
     _pillar @ 2015-04-30T15:24:56Z

     * ISSUE  #22941:  (bersace)  _pillar func breaks fileserver globals |
       refs: #22977 #22942

     * PR #22942: (bersace) Fix fileserver backends global overwritten  by
       _pillar | refs: #22977

     * f6c0728       Merge       pull       request       #22977      from
       bersace/fix-fileserver-backends-pillar-side-effect

     * 5f451f6 Fix fileserver backends __opts__ overwritten by _pillar

   * PR #23180: (jfindlay) fix  typos  from  36841bdd  in  masterapi.py  @
     2015-04-30T15:22:41Z

     * ISSUE  #23166:  (claudiupopescu)  "Error in function _minion_event"
       resulting in modules not loaded | refs: #23180

     * 34206f7 Merge pull request #23180 from jfindlay/remote_event

     * 72066e1 fix typos from 36841bdd in masterapi.py

   * PR  #23176:   (jfindlay)   copy   standard   cmd.run*   kwargs   into
     cmd.run_chroot @ 2015-04-30T15:22:12Z

     * ISSUE  #23153: (cr1st1p) cmdmod : run_chroot - broken in 2014.7.5 -
       missing kwargs | refs: #23176

     * b6b8216 Merge pull request #23176 from jfindlay/run_chroot

     * 7dc3417 copy standard cmd.run* kwargs into cmd.run_chroot

   * PR #23193: (joejulian) supervisord.mod_watch  should  accept  sfun  @
     2015-04-30T04:34:21Z

     * ISSUE  #23192:  (joejulian)  supervisord  mod_watch does not accept
       sfun | refs: #23193

     * effacbe      Merge       pull       request       #23193       from
       joejulian/2014.7_supervisord_accept_sfun

     * efb59f9 supervisord.mod_watch should accept sfun

   * PR   #23188:  (basepi)  [2014.7]  Work  around  bug  in  salt-ssh  in
     config.get for gpg renderer | refs: #23272 @ 2015-04-30T04:34:10Z

     * ISSUE #19114: (pykler) salt-ssh and gpg  pillar  renderer  |  refs:
       #23188 #23272 #23347

     * 72fe88e       Merge       pull       request       #23188      from
       basepi/salt-ssh.function.wrapper.gpg.19114

     * d73979e Work around bug in salt-ssh in config.get for gpg renderer

   * PR  #23154:  (cachedout)  Re-establish  channel  on  interruption  in
     fileclient @ 2015-04-29T16:18:59Z

     * ISSUE   #21480:   (msciciel)  TypeError:  string  indices  must  be
       integers, not str | refs: #23154

     * 168508e Merge pull request #23154 from cachedout/refresh_channel

     * 9f8dd80 Re-establish channel on interruption in fileclient

   * PR   #23146:   (rallytime)    Backport    #20779    to    2014.7    @
     2015-04-28T20:45:06Z

     * ISSUE  #20647: (ryan-lane) file.serialize fails to serialize due to
       ordered dicts | refs: #20779

     * PR #20779: (cachedout) Use declared yaml options | refs: #23146

     * 3b53e04 Merge pull request #23146 from rallytime/bp-20779

     * ffd1849 compare OrderedDicts in serializer unit test

     * a221706 Just change serialize

     * a111798 Use declared yaml options

   * PR   #23145:   (rallytime)    Backport    #23089    to    2014.7    @
     2015-04-28T20:44:56Z

     * PR  #23089:  (cachedout)  Stringify  version number before lstrip |
       refs: #23145

     * 8bb4664 Merge pull request #23145 from rallytime/bp-23089

     * 93c41af Stringify version number before lstrip

   * PR   #23144:   (rallytime)    Backport    #23124    to    2014.7    @
     2015-04-28T20:44:46Z

     * ISSUE  #16188:  (drawks)  salt.modules.parted has various functions
       with bogus input validation.  | refs: #23124

     * PR  #23124:  (ether42)  fix  parsing  the  output  of   parted   in
       parted.list_() | refs: #23144

     * c85d36f Merge pull request #23144 from rallytime/bp-23124-2014-7

     * 6b64da7 fix parsing the output of parted

   * PR #23120: (terminalmage) Don't run os.path.relpath() if repo doesn't
     have a "root" param set @ 2015-04-28T15:46:54Z

     * a27b158      Merge       pull       request       #23120       from
       terminalmage/fix-gitfs-relpath

     * 1860fff  Don't  run os.path.relpath() if repo doesn't have a "root"
       param set

   * PR #23132: (clinta) Backport b27c176 @ 2015-04-28T15:00:30Z

     * fcba607 Merge pull request #23132 from clinta/patch-2

     * a824d72 Backport b27c176

   * PR #23114: (rallytime) Adjust ZeroMQ 4 docs  to  reflect  changes  to
     Ubuntu 12 packages @ 2015-04-28T03:59:24Z

     * ISSUE  #18476: (Auha) Upgrading salt on my master caused dependency
       issues | refs: #23114 #18610

     * PR #18610: (rallytime) Make ZMQ 4 installation docs for ubuntu more
       clear | refs: #23114

     * b0f4b28       Merge       pull       request       #23114      from
       rallytime/remove_ubuntu_zmq4_docs

     * f6cc7c8 Adjust ZeroMQ 4  docs  to  reflect  changes  to  Ubuntu  12
       packages

   * PR    #23108:    (rallytime)    Backport    #23097    to   2014.7   @
     2015-04-28T03:58:05Z

     * ISSUE #23085: (xenophonf) Use "s3fs" (not "s3") in fileserver_roots
       | refs: #23097

     * PR  #23097:  (rallytime) Change s3 to s3fs in fileserver_roots docs
       example | refs: #23108

     * 399857f Merge pull request #23108 from rallytime/bp-23097

     * fa88984 Change s3 to s3fs in fileserver_roots docs example

   * PR #23112: (basepi) [2014.7] Backport #22199 to  fix  mysql  returner
     save_load errors @ 2015-04-28T03:55:44Z

     * ISSUE  #22171: (basepi) We should only call returner.save_load once
       per jid | refs: #22199

     * PR #22199:  (basepi)  [2015.2]  Put  a  bandaid  on  the  save_load
       duplicate issue (mysql returner) | refs: #23112

     * 5541537       Merge       pull       request       #23112      from
       basepi/mysql_returner_save_load

     * 0127012 Put a bandaid on the save_load duplicate issue

   * PR  #23113:  (rallytime)  Revert  "Backport  #22895  to   2014.7"   @
     2015-04-28T03:27:29Z

     * PR #22925: (rallytime) Backport #22895 to 2014.7 | refs: #23113

     * PR #22895: (aletourneau) pam_tally counter was not reset to 0 after
       a succesfull login | refs: #22925

     * dfe2066 Merge pull  request  #23113  from  saltstack/revert-22925-
       bp-22895

     * b957ea8 Revert "Backport #22895 to 2014.7"

   * PR  #23094: (terminalmage) pygit2: disable cleaning of stale refs for
     authenticated remotes @ 2015-04-27T20:51:28Z

     * ISSUE #23013:  (markusr815)  gitfs  regression  with  authenticated
       repos | refs: #23094

     * 21515f3 Merge pull request #23094 from terminalmage/issue23013

     * aaf7b04  pygit2:  disable  cleaning of stale refs for authenticated
       remotes

   * PR #23048: (jfindlay) py-2.6  compat  for  utils/boto.py  ElementTree
     exception @ 2015-04-25T16:56:45Z

     * d45aa21 Merge pull request #23048 from jfindlay/ET_error

     * 64c42cc py-2.6 compat for utils/boto.py ElementTree exception

   * PR    #23025:    (jfindlay)    catch   exceptions   on   bad   system
     locales/encodings @ 2015-04-25T16:56:30Z

     * ISSUE #22981:  (syphernl)  Locale  state  throwing  traceback  when
       generating not (yet) existing locale | refs: #23025

     * d25a5c1 Merge pull request #23025 from jfindlay/fix_sys_locale

     * 9c4d62b catch exceptions on bad system locales/encodings

   * PR #22932: (hvnsweeting) bugfix: also manipulate dir_mode when source
     not defined @ 2015-04-25T16:54:58Z

     * 5e44b59      Merge       pull       request       #22932       from
       hvnsweeting/file-append-bugfix

     * 3f368de do not use assert in execution module

     * 9d4fd4a bugfix: also manipulate dir_mode when source not defined

   * PR  #23055:  (jfindlay)  prevent  ps  module errors on accessing dead
     procs @ 2015-04-24T22:39:49Z

     * ISSUE #23021:  (ether42)  ps.pgrep  raises  NoSuchProcess  |  refs:
       #23055

     * c2416a4 Merge pull request #23055 from jfindlay/fix_ps

     * c2dc7ad prevent ps module errors on accessing dead procs

   * PR  #23031:  (jfindlay)  convert  exception  e.message  to  just  e @
     2015-04-24T18:38:13Z

     * bfd9158 Merge pull request #23031 from jfindlay/exception

     * 856bad1 convert exception e.message to just e

   * PR #23015: (hvnsweeting) if status of service is stop, there  is  not
     an error with it @ 2015-04-24T14:35:10Z

     * 7747f33       Merge       pull       request       #23015      from
       hvnsweeting/set-non-error-lvl-for-service-status-log

     * 92ea163 if status of service is stop, there is not an error with it

   * PR #23000: (jfindlay) set systemd service  killMode  to  process  for
     minion @ 2015-04-24T03:42:39Z

     * ISSUE  #22993:  (jetpak)  salt-minion  restart  causes  all spawned
       daemons to die on centos7 (systemd) | refs: #23000

     * 2e09789 Merge pull request #23000 from jfindlay/systemd_kill

     * 3d575e2 set systemd service killMode to process for minion

   * PR   #22999:   (jtand)   Added   retry_dns   to   minion   doc.     @
     2015-04-24T03:30:24Z

     * ISSUE  #22707: (arthurlogilab) retry_dns of master configuration is
       missing from the  documentation | refs: #22999

     * b5c059a Merge pull request #22999 from jtand/fix_22707

     * 8486e17 Added retry_dns to minion doc.

   * PR  #22990:  (techhat)  Use  the  proper  cloud   conf   variable   @
     2015-04-23T17:48:07Z

     * 27dc877 Merge pull request #22990 from techhat/2014.7

     * d33bcbc Use the proper cloud conf variable

   * PR   #22976:   (multani)   Improve   state_output   documentation   @
     2015-04-23T12:24:22Z

     * 13dff65 Merge pull request #22976 from multani/fix/state-output-doc

     * 19efd41 Improve state_output documentation

   * PR #22955: (terminalmage)  Fix  regression  introduced  yesterday  in
     dockerio module @ 2015-04-22T18:56:39Z

     * 89fa185       Merge       pull       request       #22955      from
       terminalmage/dockerio-run-fix

     * b4472ad Fix regression introduced yesterday in dockerio module

   * PR   #22954:   (rallytime)    Backport    #22909    to    2014.7    @
     2015-04-22T18:56:20Z

     * PR  #22909:  (mguegan)  Fix  compatibility with pkgin > 0.7 | refs:
       #22954

     * 46ef227 Merge pull request #22954 from rallytime/bp-22909

     * 70c1cd3 Fix compatibility with pkgin > 0.7

   * PR #22856: (jfindlay) increase timeout and decrease tries for route53
     records @ 2015-04-22T16:47:01Z

     * ISSUE  #18720:  (Reiner030) timeouts when setting Route53 records |
       refs: #22856

     * c9ae593 Merge pull request #22856 from jfindlay/route53_timeout

     * ba4a786 add route53 record sync wait, default=False

     * ea2fd50 increase timeout and tries for route53 records

   * PR #22946: (s0undt3ch) Test with a more recent pip version to avoid a
     traceback @ 2015-04-22T16:25:17Z

     * a178d44 Merge pull request #22946 from s0undt3ch/2014.7

     * bc87749 Test with a more recent pip version to avoid a traceback

   * PR     #22945:     (garethgreenaway)    Fixes    to    scheduler    @
     2015-04-22T16:25:00Z

     * ISSUE #22571: (BoomerB) same error message as  on  issue  #18504  |
       refs: #22945

     * de339be       Merge       pull       request       #22945      from
       garethgreenaway/22571_2014_7_schedule_pillar_refresh_seconds_exceptions

     * bfa6d25  Fixing  a  reported  issue when using a scheduled job from
       pillar with splay.  _seconds element that acted as a backup of  the
       actual  seconds  was  being  removed  when pillar was refreshed and
       causing exceptions.  This fix moves some splay related code out  of
       the if else condition so it's checked whether the job is in the job
       queue or not.

   * PR #22887: (hvnsweeting) fix #18843 @ 2015-04-22T15:47:05Z

     * ISSUE #18843: (calvinhp) State user.present  will  fail  to  create
       home if user exists and homedir doesn't

     * 12d2b91       Merge       pull       request       #22887      from
       hvnsweeting/18843-fix-user-present-home

     * 7fe7b08 run user.chhome once to avoid any side-effect when  run  it
       twice

     * 19de995 clarify the usage of home arg

     * d6dc09a  enhance  doc,  as  usermod on ubuntu 12.04 will not CREATE
       home

     * 0ce4d7f refactor: force to use boolean

     * 849d19e log debug the creating dir process

     * c4e95b9 fix #18843: usermod won't create a dir if old home does not
       exist

   * PR  #22930:  (jfindlay)  localemod.gen_locale  now  always  returns a
     boolean @ 2015-04-22T15:37:39Z

     * ISSUE #21140: (holms) locale.present state  executed  successfully,
       although originally fails | refs: #22930 #22829

     * ISSUE #2417: (ffa) Module standards | refs: #22829

     * PR  #22829:  (F30)  Always return a boolean in gen_locale() | refs:
       #22930

     * b7de7bd Merge pull request #22930 from jfindlay/localegen_bool

     * 399399f localemod.gen_locale now always returns a boolean

   * PR #22933: (hvnsweeting) add test for #18843 @ 2015-04-22T15:27:18Z

     * ISSUE #18843: (calvinhp) State user.present  will  fail  to  create
       home if user exists and homedir doesn't

     * 11bcf14 Merge pull request #22933 from hvnsweeting/18843-test

     * b13db32 add test for #18843

   * PR  #22925:  (rallytime)  Backport  #22895 to 2014.7 | refs: #23113 @
     2015-04-22T02:30:26Z

     * PR #22895: (aletourneau) pam_tally counter was not reset to 0 after
       a succesfull login | refs: #22925

     * 6890752 Merge pull request #22925 from rallytime/bp-22895

     * 3852d96 Pylint fix

     * 90f7829 Fixed pylint issues

     * 5ebf159 Cleaned up pull request

     * a08ac47  pam_tally  counter  was  not reset to 0 after a succesfull
       login

   * PR   #22914:   (cachedout)   Call   proper   returner   function   in
     jobs.list_jobs @ 2015-04-22T00:49:01Z

     * ISSUE  #22790:  (whiteinge)  jobs.list_jobs  runner  tracebacks  on
       'missing' argument | refs: #22914

     * eca37eb Merge pull request #22914 from cachedout/issue_22790

     * d828d6f Call proper returner function in jobs.list_jobs

   * PR #22918: (JaseFace) Add a note to the git_pillar docs stating  that
     GitPython    is    the    only   currently   supported   provider   @
     2015-04-22T00:48:26Z

     * 44f3409      Merge       pull       request       #22918       from
       JaseFace/git-pillar-provider-doc-note

     * 0aee5c2 Add a note to the git_pillar docs stating that GitPython is
       the only currently supported provider

   * PR #22907: (techhat) Properly merge cloud configs to create  profiles
     @ 2015-04-21T22:02:44Z

     * 31c461f Merge pull request #22907 from techhat/cloudconfig

     * 3bf4e66 Properly merge cloud configs to create profiles

   * PR #22894: (0xf10e) Fix issue #22782 @ 2015-04-21T18:55:18Z

     * f093975 Merge pull request #22894 from 0xf10e/2014.7

     * 58fa24c Clarify doc on kwarg 'roles' for user_present().

     * f0ae2eb Improve readability by renaming tenant_role

   * PR  #22902:  (rallytime)  Change  state example to use proper kwarg @
     2015-04-21T18:50:47Z

     * ISSUE   #12003:   (MarkusMuellerAU)   [state.dockerio]   docker.run
       TypeError:  run()  argument  after  ** must be a mapping, not str |
       refs: #22902

     * c802ba7 Merge pull request #22902 from rallytime/docker_doc_fix

     * 8f70346 Change state example to use proper kwarg

   * PR #22898: (terminalmage) dockerio: better error message  for  native
     exec driver @ 2015-04-21T18:02:58Z

     * 81771a7 Merge pull request #22898 from terminalmage/issue12003

     * c375309 dockerio: better error message for native exec driver

   * PR #22897: (rallytime) Add param documentation for file.replace state
     @ 2015-04-21T17:31:04Z

     * ISSUE #22825: (paolodina) Issue using file.replace in state file  |
       refs: #22897

     * e2ec4ec Merge pull request #22897 from rallytime/fix-22825

     * 9c51630 Add param documentation for file.replace state

   * PR   #22850:  (bersace)  Fix  pillar  and  salt  fileserver  mixed  @
     2015-04-21T17:04:33Z

     * ISSUE #22844: (bersace) LocalClient file cache confuse  pillar  and
       state files | refs: #22850

     * fd53889       Merge       pull       request       #22850      from
       bersace/fix-pillar-salt-mixed

     * 31b98e7 Initialize state file client after pillar loading

     * f6bebb7 Use saltenv

   * PR #22818: (twangboy) Added documentation regarding pip in windows  @
     2015-04-21T03:58:59Z

     * 1380fec Merge pull request #22818 from twangboy/upd_pip_docs

     * cb999c7 Update pip.py

     * 3cc5c97 Added documentation regarding pip in windows

   * PR  #22872: (rallytime) Prevent stacktrace on os.path.exists in hosts
     module @ 2015-04-21T02:54:40Z

     * b2bf17f      Merge       pull       request       #22872       from
       rallytime/fix_hosts_stacktrace

     * c88a1ea Prevent stacktrace on os.path.exists in hosts module

   * PR  #22853:  (s0undt3ch)  Don't assume package installation order.  @
     2015-04-21T02:42:41Z

     * 03af523 Merge pull request #22853 from s0undt3ch/2014.7

     * b62df62 Don't assume package installation order.

   * PR #22877: (s0undt3ch) Don't fail on  make  clean  just  because  the
     directory does not exist @ 2015-04-21T02:40:47Z

     * 9211e36       Merge       pull       request       #22877      from
       s0undt3ch/hotfix/clean-docs-fix

     * 95d6887 Don't fail on make clean just because  the  directory  does
       not exist

   * PR  #22873:  (thatch45) Type check the version since it will often be
     numeric @ 2015-04-21T02:38:11Z

     * 5bdbd08 Merge pull request #22873 from thatch45/type_check

     * 53b8376 Type check the version since it will often be numeric

   * PR #22870: (twangboy) Added ability to send a version with a space in
     it @ 2015-04-20T23:18:28Z

     * c965b0a Merge pull request #22870 from twangboy/fix_installer_again

     * 3f180cf Added ability to send a version with a space in it

   * PR    #22863:    (rallytime)    Backport    #20974    to   2014.7   @
     2015-04-20T19:29:37Z

     * PR    #20974:    (JohannesEbke)    Fix    expr_match    usage    in
       salt.utils.check_whitelist_blacklist | refs: #22863

     * 2973eb1 Merge pull request #22863 from rallytime/bp-20974

     * 14913a4          Fix          expr_match          usage          in
       salt.utils.check_whitelist_blacklist

   * PR #22578: (hvnsweeting) gracefully handle  when  salt-minion  cannot
     decrypt key @ 2015-04-20T15:24:45Z

     * c45b92b       Merge       pull       request       #22578      from
       hvnsweeting/2014-7-fix-compile-pillar

     * f75b24a gracefully handle when salt-minion cannot decrypt key

   * PR #22800: (terminalmage) Improve error logging for pygit2  SSH-based
     remotes @ 2015-04-18T17:18:55Z

     * ISSUE  #21979:  (yrdevops)  gitfs:  error  message  not descriptive
       enough when libgit2 was compiled without libssh2 | refs: #22800

     * 900c7a5 Merge pull request #22800 from terminalmage/issue21979

     * 8f1c008 Clarify that for pygit2, receiving 0 objects means repo  is
       up-to-date

     * 98885f7  Add  information  about libssh2 requirement for pygit2 ssh
       auth

     * 09468d2 Fix incorrect log message

     * 2093bf8 Adjust loglevels for gitfs errors

     * 9d394df Improve error logging for pygit2 SSH-based remotes

   * PR #22813:  (twangboy)  Updated  instructions  for  building  salt  @
     2015-04-18T04:10:07Z

     * e99f2fd Merge pull request #22813 from twangboy/win_doc_fix

     * adc421a Fixed some formatting issues

     * 8901b3b Updated instructions for building salt

   * PR  #22810:  (basepi)  [2014.7]  More  msgpack  gating for salt-ssh @
     2015-04-17T22:28:24Z

     * ISSUE #22708: (Bilge) salt-ssh file.accumulated  error:  NameError:
       global name 'msgpack' is not defined | refs: #22810

     * fe1de89       Merge       pull       request       #22810      from
       basepi/salt-ssh.more.msgpack.gating

     * d4da8e6 Gate msgpack in salt/modules/saltutil.py

     * 02303b2 Gate msgpack in salt/modules/data.py

     * d7e8741 Gate salt.states.file.py msgpack

   * PR #22803: (rallytime) Allow  map  file  to  work  with  softlayer  @
     2015-04-17T20:34:42Z

     * ISSUE  #17144: (xpender) salt-cloud -m fails with softlayer | refs:
       #22803

     * 11df71e Merge pull request #22803 from rallytime/fix-17144

     * ce88b6a Allow map file to work with softlayer

   * PR #22807: (rallytime) Add 2014.7.5  links  to  windows  installation
     docs @ 2015-04-17T20:32:13Z

     * cd43a95       Merge       pull       request       #22807      from
       rallytime/windows_docs_update

     * 5931a58 Replace all 4s with 5s

     * eadaead Add 2014.7.5 links to windows installation docs

   * PR #22795: (rallytime) Added release  note  for  2014.7.5  release  @
     2015-04-17T18:05:36Z

     * 0b295e2 Merge pull request #22795 from rallytime/release_notes

     * fde1fee Remove extra line

     * b19b95d Added release note for 2014.7.5 release

   * PR #22759: (twangboy) Final edits to the batch files for running salt
     @ 2015-04-17T04:31:15Z

     * ISSUE #22740: (lorengordon) New Windows installer assumes  salt  is
       installed to the current directory | refs: #22759

     * PR #22754: (twangboy) Removed redundant \ and " | refs: #22759

     * 3c91459       Merge       pull       request       #22759      from
       twangboy/fix_bat_one_last_time

     * 075f82e Final edits to the batch files for running salt

   * PR   #22760:   (thatch45)   Fix   issues   with    the    syndic    @
     2015-04-17T04:30:48Z

     * 20d3f2b Merge pull request #22760 from thatch45/syndic_fix

     * e2db624  Fix  issues  with the syndic not resolving the master when
       the interface is set

   * PR  #22762:  (twangboy)  Fixed  version  not  showing  in  Add/Remove
     Programs @ 2015-04-17T04:29:46Z

     * 54c4584 Merge pull request #22762 from twangboy/fix_installer

     * 4d25af8 Fixed version not showing in Add/Remove Programs

   Salt 2014.7.8 Release Notes
   Changes for v2014.7.7..v2014.7.8
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-03-11T21:18:48Z

   Statistics:

   * Total Merges: 7

   * Total Issue references: 3

   * Total PR references: 10

   Changes:

   * PR #28839: (cachedout) Revert #28740 @ 2015-11-12T22:54:28Z

     * PR #28740: (MasterNayru) Add  missing  S3  module  import  |  refs:
       #28777

     * 4b8bdd0 Merge pull request #28839 from cachedout/revert_28740

     * 215b26c Revert #28740

   * PR    #28777:    (rallytime)    Back-port    #28740   to   2014.7   @
     2015-11-11T18:00:00Z

     * PR #28740: (MasterNayru) Add  missing  S3  module  import  |  refs:
       #28777

     * 76e69b4 Merge pull request #28777 from rallytime/bp-28740-2014.7

     * da5fac2 Back-port #28740 to 2014.7

   * PR    #28716:    (rallytime)    Back-port    #28705   to   2014.7   @
     2015-11-10T16:15:03Z

     * PR #28705: (cachedout) Account for new headers class in tornado 4.3
       | refs: #28716

     * 45c73eb Merge pull request #28716 from rallytime/bp-28705

     * 32e7bd3 Account for new headers class in tornado 4.3

   * PR   #28717:   (cachedout)   Add   note  about  recommended  umask  @
     2015-11-09T23:26:20Z

     * ISSUE #28199:  (felskrone)  Non-standard  umasks  might  break  the
       master | refs: #28717

     * f4fe921 Merge pull request #28717 from cachedout/umask_note

     * 1874300 Add note about recommended umask

   * PR  #28461:  (cachedout) Wrap all cache calls in state.sls in correct
     umask @ 2015-11-02T17:11:02Z

     * ISSUE #28455: (zmalone)  highstate.cache  is  world  readable,  and
       contains secrets | refs: #28461

     * 4bf56ca Merge pull request #28461 from cachedout/issue_28455

     * 097838e Wrap all cache calls in state.sls in correct umask

   * PR  #28407: (DmitryKuzmenko) Don't request creds if auth with key.  @
     2015-10-29T16:12:30Z

     * ISSUE #24910: (bocig) -T, --make-token flag  does  NOT  work-  LDAP
       Groups | refs: #28407

     * f3e61db       Merge       pull       request       #28407      from
       DSRCompany/issues/24910_token_auth_fix_2014

     * b7b5bec Don't request creds if auth with key.

   * PR #27390: (JaseFace)  Ensure  we  pass  on  the  enable  setting  if
     present, or use the default of True if not in build_schedule_item() @
     2015-10-05T18:09:33Z

     * d284eb1      Merge       pull       request       #27390       from
       JaseFace/schedule-missing-enabled

     * 563db71 Ensure we pass on the enable setting if present, or use the
       default of True if not in build_schedule_item() Prior to this, when
       schedule.present  compares the existing schedule to the one crafted
       by this function, enabled will actually be  removed  at  each  run.
       schedule.present  sees a modification needs to be made, and invokes
       schedule.modify, which does so with  enabled:  True,  creating  and
       endless loop of an 'enabled' removal and addition.

   Salt 2014.7.9 Release Notes
   Changes for v2014.7.8..v2014.7.9
   Extended     changelog     courtesy     of     Todd     Stansell     (
   https://github.com/tjstansell/salt-changelogs):

   Generated at: 2016-03-11T20:58:58Z

   Statistics:

   * Total Merges: 3

   * Total Issue references: 1

   * Total PR references: 3

   Changes:

   * PR #31826: (gtmanfred)  Remove  ability  of  authenticating  user  to
     specify pam service @ 2016-03-11T20:41:01Z

     * c5e7c03 Merge pull request #31826 from gtmanfred/2014.7

     * d73f70e  Remove  ability  of  authenticating  user  to  specify pam
       service

   * PR #29392: (jacobhammons) updated version number to not  reference  a
     specific build from the lat... @ 2015-12-03T15:54:31Z

     * 85aa70a Merge pull request #29392 from jacobhammons/2014.7

     * d7f0db1  updated  version  number to not reference a specific build
       from the latest branch

   * PR #29296: (douardda) Use process KillMode on Debian systems  also  @
     2015-12-01T16:00:16Z

     * ISSUE  #29295:  (douardda)  systemd's  service  file should use the
       'process' KillMode option on Debian also | refs: #29296

     * d2fb210 Merge pull request #29296 from douardda/patch-3

     * d288539 Use process KillMode on Debian systems also

   Salt 2014.1.0 Release Notes - Codename Hydrogen
   NOTE:
      Due to a change in master to minion communication, 2014.1.0  minions
      are  not  compatible  with  older-version  masters.   Please upgrade
      masters first.  More info on  backwards-compatibility  policy  here,
      under the "Upgrading Salt" subheading.

   NOTE:
      A  change  in  the grammar in the state compiler makes module.run in
      requisites illegal syntax.  Its use is replaced simply with the word
      module.   In  other  words  you  will need to change requisites like
      this:

          require:
              module.run: some_module_name

      to:

          require:
              module: some_module_name

      This is a breaking change.  We apologize for the  inconvenience,  we
      needed to do this to remove some ambiguity in parsing requisites.

   release
          2014-02-24

   The  2014.1.0  release  of  Salt  is  a  major  release  which not only
   increases stability but also brings new capabilities in virtualization,
   cloud  integration,  and more. This release brings a great focus on the
   expansion of testing making roughly double the  coverage  in  the  Salt
   tests, and comes with many new features.

   2014.1.0  is  the  first  release  to follow the new date-based release
   naming system. See the version numbers page for more details.

   Major Features
   Salt Cloud Merged into Salt
   Salt Cloud is a tool for provisioning  salted  minions  across  various
   cloud  providers.  Prior  to  this  release,  Salt Cloud was a separate
   project but this marks its full integration with the Salt distribution.
   A Getting Started guide and additional documentation for Salt Cloud can
   be found here:

   Google Compute Engine
   Alongside Salt Cloud comes new support for the Google  Compute  Engine.
   Salt  Stack  can  now  deploy  and control GCE virtual machines and the
   application stacks that they run.

   For more information on Salt Stack and GCE, please see this blog post.

   Documentation for Salt and GCE can be found here.

   Salt Virt
   Salt  Virt  is  a  cloud  controller  that  supports  virtual   machine
   deployment, inspection, migration, and integration with many aspects of
   Salt.

   Salt Virt has undergone a major overhaul  with  this  release  and  now
   supports   many  more  features  and  includes  a  number  of  critical
   improvements.

   Docker Integration
   Salt now ships with states and an execution  module  to  manage  Docker
   containers.

   Substantial Testing Expansion
   Salt  continues  to  increase  its  unit/regression test coverage. This
   release includes over 300 new tests.

   BSD Package Management
   BSD package management has been entirely rewritten. FreeBSD 9 and older
   now  default  to  using  pkg_add,  while  FreeBSD 10 and newer will use
   pkgng. FreeBSD 9 can be forced to use pkgng, however, by specifying the
   following option in the minion config file:

      providers:
        pkg: pkgng

   In  addition,  support  for installing software from the ports tree has
   been added. See the documentation for the  ports  state  and  execution
   module for more information.

   Network Management for Debian/Ubuntu
   Initial  support  for  management of network interfaces on Debian-based
   distros has been added. See the documentation for the network state and
   the debian_ip for more information.

   IPv6 Support for iptables State/Module
   The  iptables  state  and module now have IPv6 support. A new parameter
   family has been  added  to  the  states  and  execution  functions,  to
   distinguish between IPv4 and IPv6. The default value for this parameter
   is ipv4, specifying ipv6 will use ip6tables to manage firewall rules.

   GitFS Improvements
   Several performance improvements have been made to the  Git  fileserver
   backend. Additionally, file states can now use any any SHA1 commit hash
   as a fileserver environment:

      /etc/httpd/httpd.conf:
        file.managed:
          - source: salt://webserver/files/httpd.conf
          - saltenv: 45af879

   This applies to the functions in the cp module as well:

      salt '*' cp.get_file salt://readme.txt /tmp/readme.txt saltenv=45af879

   MinionFS
   This new fileserver backend allows files which have  been  pushed  from
   the  minion to the master (using cp.push) to be served up from the salt
   fileserver. The path for these files takes the following format:

      salt://minion-id/path/to/file

   minion-id is the id of the "source" minion,  the  one  from  which  the
   files  were pushed to the master. /path/to/file is the full path of the
   file.

   The MinionFS Walkthrough contains a more thorough example of how to use
   this backend.

   saltenv
   To  distinguish between fileserver environments and execution functions
   which deal with environment variables, fileserver environments are  now
   specified  using  the saltenv parameter. env will continue to work, but
   is deprecated and will be removed in a future release.

   Grains Caching
   A caching layer has been added to the Grains  system,  which  can  help
   speed  up  minion  startup.  Disabled  by default, it can be enabled by
   setting the minion config option grains_cache:

      grains_cache: True

      # Seconds before grains cache is considered to be stale.
      grains_cache_expiration: 300

   If  set  to  True,  the  grains  loader  will  read  from/write  to   a
   msgpack-serialized file containing the grains data.

   Additional command-line parameters have been added to salt-call, mainly
   for testing purposes:

   * --skip-grains will completely bypass the grains loader when salt-call
     is invoked.

   * --refresh-grains-cache  will  force  the  grains loader to bypass the
     grains cache and refresh the grains, writing a new grains cache file.

   Improved Command Logging Control
   When using the cmd module, either on the CLI or  when  developing  Salt
   execution  modules,  a  new keyword argument output_loglevel allows for
   greater control over how (or even if) the command and  its  output  are
   logged. For example:

      salt '*' cmd.run 'tail /var/log/messages' output_loglevel=debug

   The package management modules (apt, yumpkg, etc.) have been updated to
   log the copious output generated from these commands at loglevel debug.

   NOTE:
      To keep a command from being logged,  output_loglevel=quiet  can  be
      used.

      Prior  to  this  release,  this could be done using quiet=True. This
      argument is still supported, but will be removed in  a  future  Salt
      release.

   PagerDuty Support
   Initial support for firing events via PagerDuty has been added. See the
   documentation for the pagerduty module.

   Virtual Terminal
   Sometimes the subprocess module is not good enough, and, in  fact,  not
   even  askpass  is.  This  virtual  terminal  is  still  in  it's infant
   childhood, needs quite some love, and was originally created to replace
   askpass,  but, while developing it, it immediately proved that it could
   do so much more. It's currently used by salt-cloud  when  bootstrapping
   salt on clouds which require the use of a password.

   Proxy Minions
   Initial   basic   support   for  Proxy  Minions  is  in  this  release.
   Documentation can be found here.

   Proxy minions are a developing feature in Salt that enables control  of
   devices  that  cannot  run a minion. Examples include network gear like
   switches and routers that run a proprietary OS but  offer  an  API,  or
   "dumb" devices that just don't have the horsepower or ability to handle
   a Python VM.

   Proxy minions can be difficult to write, so a simple REST-based example
   proxy  is  included.  A  Python  bottle-based webserver can be found at
   https://github.com/cro/salt-proxy-rest as an endpoint for this proxy.

   This is an ALPHA-quality feature. There are a number of issues with  it
   currently,  mostly  centering  around  process  control,  logging,  and
   inability to work in a masterless configuration.

   Additional Bugfixes (Release Candidate Period)
   Below are many of the fixes that were implemented in  salt  during  the
   release candidate phase.

   * Fix mount.mounted leaving conflicting entries in fstab (issue 7079)

   * Fix mysql returner serialization to use json (issue 9590)

   * Fix  ZMQError:  Operation  cannot  be  accomplished  in current state
     errors (issue 6306)

   * Rbenv and ruby improvements

   * Fix quoting issues with mysql port (issue 9568)

   * Update mount module/state to support multiple swap partitions  (issue
     9520)

   * Fix archive state to work with bsdtar

   * Clarify logs for minion ID caching

   * Add numeric revision support to git state (issue 9718)

   * Update master_uri with master_ip (issue 9694)

   * Add comment to Debian mod_repo (issue 9923)

   * Fix potential undefined loop variable in rabbitmq state (issue 8703)

   * Fix for salt-virt runner to delete key on VM deletion

   * Fix  for  salt-run -d to limit results to specific runner or function
     (issue 9975)

   * Add tracebacks to jinja renderer when applicable (issue 10010)

   * Fix parsing in monit module (issue 10041)

   * Fix highstate output from syndic minions (issue 9732)

   * Quiet logging when dealing with passwords/hashes (issue 10000)

   * Fix for multiple remotes in git_pillar (issue 9932)

   * Fix npm installed command (issue 10109)

   * Add safeguards for utf8 errors in zcbuildout module

   * Fix compound commands (issue 9746)

   * Add systemd notification when master is started

   * Many doc improvements

   Salt 2014.1.1 Release Notes
   release
          2014-03-18

   Version 2014.1.1  is  a  bugfix  release  for  2014.1.0.   The  changes
   include:

   * Various  doc  fixes,  including  up-to-date  Salt  Cloud installation
     documentation.

   * Renamed state.sls runner to state.orchestrate,  to  reduce  confusion
     with the state.sls execution function

   * Fix various bugs in the dig module (issue 10367)

   * Add retry for query on certain EC2 status codes (issue 10154)

   * Fix various bugs in mongodb_user state module (issue 10430)

   * Fix permissions on ~/.salt_token (issue 10422)

   * Add PyObjects support

   * Fix launchctl module crash with missing files

   * Fix saltutil.find_job for Windows (issue 10581)

   * Fix OS detection for OpenSolaris (issue 10601)

   * Fix broken salt-ssh key_deploy

   * Add support for multiline cron comments (issue 10721)

   * Fix timezone module for Arch (issue 10789)

   * Fix symlink support for file.recurse (issue 10809)

   * Fix multi-master bugs (issue 10732 and issue 10969)

   * Fix file.patch to error when source file is unavailable (issue 10380)

   * Fix  pkg  to  handle  packages  set  as purge in pkg.installed (issue
     10719)

   * Add zmqversion grain

   * Fix highstate summary for masterless minions (issue 10945)

   * Fix saltutil.find_job for 2014.1 masters talking to 0.17  minions  (
     issue 11020)

   * Fix file.recurse states with trailing slashes in source (issue 11002)

   * Fix pkg states to allow pkgname.x86_64 (issue 7306)

   * Make iptables states set a default table for flush (issue 11037)

   * Added  iptables  --reject-with  after final iptables call in iptables
     states (issue:10757)

   * Fix improper passing of "family" in iptables states (issue 10774)

   * Fix traceback in iptables.insert states (issue 10988)

   * Fix zombie processes (issue 10867 and others)

   * Fix batch mode to obey --return settings (issue 9146)

   * Fix localclient issue that was causing  batch  mode  breakage  (issue
     11094, issue 10470, and others)

   * Multiple salt-ssh fixes

   * FreeBSD: look in /usr/local/etc/salt for configuration by default, if
     installed using pip --editable.

   * Add a skip_suggestions parameter to pkg.installed states which allows
     pre-flight check to be skipped (issue 11106)

   * Fixed  tag-based  gitfs  fileserver  environments  regression  (issue
     10956)

   * Yum: fix cache of available pkgs not cleared when repos  are  changed
     (issue 11001)

   * Yum: fix for plugin-provided repositories (i.e. RHN/Spacewalk) (issue
     11145)

   * Fix regression in chocolatey.bootstrap (issue 10541)

   * Fix fail on unknown target in jobs runner (issue 11151)

   * Don't log errors for commands which are expected  to  sometimes  exit
     with non-zero exit status (issue 11154, issue 11090)

   * Fix test=True CLI override of config option (issue 10877)

   * Log sysctl key listing at loglevel TRACE (issue 10931)

   Salt 2014.1.10 Release Notes
   release
          2014-08-01

   NOTE:
      Version 2014.1.9 contained a regression which caused inaccurate Salt
      version detection, and thus was never packaged for general  release.
      This  version  contains  the version detection fix, but is otherwise
      identical to 2014.1.9.

   Version 2014.1.10 is another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Ensure  salt-ssh  will  not  continue  if  permissions on a temporary
     directory are not correct.

   * Use the bootstrap script distributed with Salt instead of relying  on
     an external resource

   * Remove unused testing code

   * Ensure salt states are placed into the .salt directory in salt-ssh

   * Use a randomized path for temporary files in a salt-cloud deployment

   * Clean any stale directories to ensure a fresh copy of salt-ssh during
     a deployment

   Salt 2014.1.10  fixes  security  issues  documented  by  CVE-2014-3563:
   "Insecure  tmp-file  creation  in  seed.py,  salt-ssh, and salt-cloud."
   Upgrading is recommended.

   Salt 2014.1.11 Release Notes
   release
          2014-08-29

   Version 2014.1.11 is another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Fix for minion_id with byte-order mark (BOM) (issue 12296)

   * Fix runas deprecation in at module

   * Fix trailing slash befhavior for file.makedirs_ (issue 14019)

   * Fix chocolatey path (issue 13870)

   * Fix git_pillar infinite loop issues (issue 14671)

   * Fix json outputter null case

   * Fix  for  minion  error  if  one  of multiple masters are down (issue
     14099)

   Salt 2014.1.12 Release Notes
   release
          2014-10-08

   Version 2014.1.12 is another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Fix scp_file always failing (which broke salt-cloud) (issue 16437)

   * Fix  regression  in  pillar  in masterless (issue 16210, issue 16416,
     issue 16428)

   Salt 2014.1.13 Release Notes
   release
          2014-10-14

   Version 2014.1.13 is another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Fix  sftp_file  by  checking the exit status code of scp (which broke
     salt-cloud) (issue 16599)

   Salt 2014.1.2 Release Notes
   release
          2014-04-15

   Version 2014.1.2 is another bugfix release for  2014.1.0.  The  changes
   include:

   * Fix username detection when su'ed to root on FreeBSD (issue 11628)

   * Fix minionfs backend for file.recurse states

   * Fix  32-bit packages of different arches than the CPU arch, on 32-bit
     RHEL/CentOS (issue 11822)

   * Fix bug with specifying alternate home dir on user creation (FreeBSD)
     (issue 11790)

   * Don't reload site module on module refresh for MacOS

   * Fix  regression with running execution functions in Pillar SLS (issue
     11453)

   * Fix some modules missing from Windows installer

   * Don't log an error for yum commands that return nonzero  exit  status
     on non-failure (issue 11645)

   * Fix bug in rabbitmq state (issue 8703)

   * Fix missing ssh config options (issue 10604)

   * Fix top.sls ordering (issue 10810 and issue 11691)

   * Fix salt-key --list all (issue 10982)

   * Fix win_servermanager install/remove function (issue 11038)

   * Fix  interaction  with  tokens  when  running commands as root (issue
     11223)

   * Fix overstate bug with find_job and **kwargs (issue 10503)

   * Fix saltenv for aptpkg.mod_repo from pkgrepo state

   * Fix environment issue causing file caching problems (issue 11189)

   * Fix bug in __parse_key in registry state (issue 11408)

   * Add minion auth retry on rejection (issue 10763)

   * Fix publish_session updating the encryption key (issue 11493)

   * Fix for bad AssertionError raised by GitPython (issue 11473)

   * Fix debian_ip to allow disabling and enabling networking on Ubuntu (
     issue 11164)

   * Fix  potential memory leak caused by saved (and unused) events (issue
     11582)

   * Fix exception handling in the MySQL module (issue 11616)

   * Fix environment-related error (issue 11534)

   * Include psutil on Windows

   * Add file.replace and file.search to Windows (issue 11471)

   * Add additional file module helpers to Windows (issue 11235)

   * Add pid to netstat output on Windows (issue 10782)

   * Fix Windows not caching new versions of installers in winrepo  (issue
     10597)

   * Fix hardcoded md5 hashing

   * Fix kwargs in salt-ssh (issue 11609)

   * Fix file backup timestamps (issue 11745)

   * Fix stacktrace on sys.doc with invalid eauth (issue 11293)

   * Fix git.latest with test=True (issue 11595)

   * Fix file.check_perms hardcoded follow_symlinks (issue 11387)

   * Fix certain pkg states for RHEL5/Cent5 machines (issue 11719)

   Salt 2014.1.3 Release Notes
   release
          2014-04-15

   Version  2014.1.3  is  another  bugfix  release  for  2014.1.0.  It was
   created as a hotfix for a regression found in 2014.1.2, which  was  not
   distributed.  The only change made was as follows:

   * Fix   regression  that  caused  saltutil.find_job  to  fail,  causing
     premature terminations of salt CLI commands.

   Changes in the not-distributed 2014.1.2, also included in 2014.1.3:

   * Fix username detection when su'ed to root on FreeBSD (issue 11628)

   * Fix minionfs backend for file.recurse states

   * Fix 32-bit packages of different arches than the CPU arch, on  32-bit
     RHEL/CentOS (issue 11822)

   * Fix bug with specifying alternate home dir on user creation (FreeBSD)
     (issue 11790)

   * Don't reload site module on module refresh for MacOS

   * Fix regression with running execution functions in Pillar SLS  (issue
     11453)

   * Fix some modules missing from Windows installer

   * Don't  log  an error for yum commands that return nonzero exit status
     on non-failure (issue 11645)

   * Fix bug in rabbitmq state (issue 8703)

   * Fix missing ssh config options (issue 10604)

   * Fix top.sls ordering (issue 10810 and issue 11691)

   * Fix salt-key --list all (issue 10982)

   * Fix win_servermanager install/remove function (issue 11038)

   * Fix interaction with tokens when  running  commands  as  root  (issue
     11223)

   * Fix overstate bug with find_job and **kwargs (issue 10503)

   * Fix saltenv for aptpkg.mod_repo from pkgrepo state

   * Fix environment issue causing file caching problems (issue 11189)

   * Fix bug in __parse_key in registry state (issue 11408)

   * Add minion auth retry on rejection (issue 10763)

   * Fix publish_session updating the encryption key (issue 11493)

   * Fix for bad AssertionError raised by GitPython (issue 11473)

   * Fix debian_ip to allow disabling and enabling networking on Ubuntu (
     issue 11164)

   * Fix potential memory leak caused by saved (and unused) events  (issue
     11582)

   * Fix exception handling in the MySQL module (issue 11616)

   * Fix environment-related error (issue 11534)

   * Include psutil on Windows

   * Add file.replace and file.search to Windows (issue 11471)

   * Add additional file module helpers to Windows (issue 11235)

   * Add pid to netstat output on Windows (issue 10782)

   * Fix  Windows not caching new versions of installers in winrepo (issue
     10597)

   * Fix hardcoded md5 hashing

   * Fix kwargs in salt-ssh (issue 11609)

   * Fix file backup timestamps (issue 11745)

   * Fix stacktrace on sys.doc with invalid eauth (issue 11293)

   * Fix git.latest with test=True (issue 11595)

   * Fix file.check_perms hardcoded follow_symlinks (issue 11387)

   * Fix certain pkg states for RHEL5/Cent5 machines (issue 11719)

   Salt 2014.1.4 Release Notes
   release
          2014-05-05

   Version 2014.1.4 is  another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Fix setup.py dependency issue (issue 12031)

   * Fix  handling  for  IOErrors under certain circumstances (issue 11783
     and issue 11853)

   * Fix fatal exception when /proc/1/cgroup is not readable (issue 11619)

   * Fix os grains for OpenSolaris (issue 11907)

   * Fix lvs.zero module argument pass-through (issue 9001)

   * Fix bug in debian_ip interaction  with  network.system  state  (issue
     11164)

   * Remove bad binary package verification code (issue 12177)

   * Fix traceback in solaris package installation (issue 12237)

   * Fix file.directory state symlink handling (issue 12209)

   * Remove external_ip grain

   * Fix file.managed makedirs issues (issue 10446)

   * Fix  hang on non-existent Windows drive letter for file module (issue
     9880)

   * Fix salt minion caching all users on the server (issue 9743)

   * Add strftime formatting for ps.boot_time (issue 12428)

   Salt 2014.1.5 Release Notes
   release
          2014-06-11

   Version 2014.1.5 is  another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Add function for finding cached job on the minion

   * Fix iptables save file location for Debian (issue 11730)

   * Fix for minion caching jobs when master is down

   * Bump  default  syndic_wait to 5 to fix syndic-related problems (issue
     12262)

   * Add OpenBSD, FreeBSD, and NetBSD support for  network.netstat  (issue
     12121)

   * Fix false positive error in logs for makeconf state (issue 9762)

   * Fix  for  yum  fromrepo  package  installs  when  repo is disabled by
     default (issue 12466)

   * Fix for extra blank lines in file.blockreplace (issue 12422)

   * Fix grain detection for OpenVZ guests (issue 11877)

   * Fix get_dns_servers function for Windows win_dns_client

   * Use system locale for ports package installations

   * Use correct stop/restart procedure for Debian networking in debian_ip
     (issue 12614)

   * Fix for cmd_iter/cmd_iter_no_block blocking issues (issue 12617)

   * Fix traceback when syncing custom types (issue 12883)

   * Fix cleaning directory symlinks in file.directory

   * Add    performance    optimizations    for    saltutil.sync_all   and
     state.highstate

   * Fix possible error in saltutil.running

   * Fix for kmod modules with dashes (issue 13239)

   * Fix possible race condition  for  Windows  minions  in  state  module
     reloading (issue 12370)

   * Fix  bug with roster for passwd option that is loaded as a non-string
     object (issue 13249)

   * Keep duplicate version  numbers  from  showing  up  in  pkg.list_pkgs
     output

   * Fixes for Jinja renderer, timezone module/state (issue 12724)

   * Fix timedatectl parsing for systemd>=210 (issue 12728)

   * Fix saltenv being written to YUM repo config files (issue 12887)

   * Removed   the   deprecated   external  nodes  classifier  (originally
     accessible by setting  a  value  for  external_nodes  in  the  master
     configuration  file).   Note  that this functionality has been marked
     deprecated for some time and was replaced by the more general  master
     tops system.

   * More robust escaping of ldap filter strings.

   * Fix trailing slash in gitfs_root causing files not to be available (
     issue 13185)

   Salt 2014.1.6 Release Notes
   release
          2014-07-08

   Version 2014.1.6 is  another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Fix extra iptables --help output (Sorry!)  (issue 13648, issue 13507,
     issue 13527, issue 13607)

   * Fix mount.active for Solaris

   * Fix support for allow-hotplug statement in debian_ip network module

   * Add sqlite3 to esky builds

   * Fix jobs.active output (issue 9526)

   * Fix the virtual grain for Xen (issue 13534)

   * Fix _ext_nodes unavailable on master (issue 13535)

   * Fix eauth for batch mode (issue 9605)

   * Fix force-related issues with tomcat support (issue 12889)

   * Fix KeyError when cloud mapping

   * Fix salt-minion restart loop in Windows (issue 12086)

   * Fix detection of service virtual module on Fedora minions

   * Fix traceback with missing ipv4 grain (issue 13838)

   * Fix issue in roots backend with  invalid  data  in  mtime_map  (issue
     13836)

   * Fix traceback in jobs.active (issue 11151)

   * Fix master_tops and _ext_nodes issue (issue 13535, issue 13673)

   Salt 2014.1.7 Release Notes
   release
          2014-07-09

   Version  2014.1.7  is  another  bugfix  release  for 2014.1.0.  Changes
   include:

   * Fix batch mode regression (issue 14046)

   This release was a hotfix release for the regression listed above which
   was  present in the 2014.1.6 release.  The changes included in 2014.1.6
   are listed below:

   * Fix extra iptables --help output (Sorry!)  (issue 13648, issue 13507,
     issue 13527, issue 13607)

   * Fix mount.active for Solaris

   * Fix support for allow-hotplug statement in debian_ip network module

   * Add sqlite3 to esky builds

   * Fix jobs.active output (issue 9526)

   * Fix the virtual grain for Xen (issue 13534)

   * Fix eauth for batch mode (issue 9605)

   * Fix force-related issues with tomcat support (issue 12889)

   * Fix KeyError when cloud mapping

   * Fix salt-minion restart loop in Windows (issue 12086)

   * Fix detection of service virtual module on Fedora minions

   * Fix traceback with missing ipv4 grain (issue 13838)

   * Fix  issue  in  roots  backend  with invalid data in mtime_map (issue
     13836)

   * Fix traceback in jobs.active (issue 11151)

   * Fix master_tops and _ext_nodes issue (issue 13535, issue 13673)

   Salt 2014.1.8 Release Notes
   release
          2014-07-30

   NOTE:
      This release contained a regression  which  caused  inaccurate  Salt
      version  detection, and thus was never packaged for general release.
      Please use version 2014.1.10 instead.

   Version 2014.1.8 is  another  bugfix  release  for  2014.1.0.   Changes
   include:

   * Ensure  salt-ssh  will  not  continue  if  permissions on a temporary
     directory are not correct.

   * Use the bootstrap script distributed with Salt instead of relying  on
     an external resource

   * Remove unused testing code

   * Ensure salt states are placed into the .salt directory in salt-ssh

   * Use a randomized path for temporary files in a salt-cloud deployment

   * Clean any stale directories to ensure a fresh copy of salt-ssh during
     a deployment

   Salt 2014.1.9 Release Notes
   release
          2014-07-31

   NOTE:
      This release contained a regression  which  caused  inaccurate  Salt
      version  detection, and thus was never packaged for general release.
      Please use version 2014.1.10 instead.

   NOTE:
      Version 2014.1.8 contained a regression which caused inaccurate Salt
      version  detection, and thus was never packaged for general release.
      This version contains the version detection fix,  but  is  otherwise
      identical to 2014.1.8.

   Version  2014.1.9  is  another  bugfix  release  for 2014.1.0.  Changes
   include:

   * Ensure salt-ssh will not  continue  if  permissions  on  a  temporary
     directory are not correct.

   * Use  the bootstrap script distributed with Salt instead of relying on
     an external resource

   * Remove unused testing code

   * Ensure salt states are placed into the .salt directory in salt-ssh

   * Use a randomized path for temporary files in a salt-cloud deployment

   * Clean any stale directories to ensure a fresh copy of salt-ssh during
     a deployment

   Salt 0.10.0 Release Notes
   release
          2012-06-16

   0.10.0  has  arrived!  This  release comes with MANY bug fixes, and new
   capabilities which greatly enhance performance  and  reliability.  This
   release  is  primarily  a  bug fix release with many new tests and many
   repaired bugs. This release also introduces  a  few  new  key  features
   which  were  brought  in  primarily to repair bugs and some limitations
   found in some of the components of the original architecture.

   Major Features
   Event System
   The Salt Master now comes equipped with a new event system. This  event
   system  has replaced some of the back end of the Salt client and offers
   the  beginning  of  a  system  which  will   make   plugging   external
   applications  into  Salt.  The  event  system  relies on a local ZeroMQ
   publish socket and other processes  can  connect  to  this  socket  and
   listen  for  events.  The  new  events can be easily managed via Salt's
   event library.

   Unprivileged User Updates
   Some enhancements have been added to Salt for running as a  user  other
   than  root. These new additions should make switching the user that the
   Salt Master is running as very painless, simply change the user  option
   in the master configuration and restart the master, Salt will take care
   of all of the particulars for you.

   Peer Runner Execution
   Salt has long had the peer communication system used to  allow  minions
   to  send  commands  via  the  salt master. 0.10.0 adds a new capability
   here, now the master can be configured to allow for minions to  execute
   Salt runners via the peer_run option in the salt master configuration.

   YAML Parsing Updates
   In  the  past  the YAML parser for sls files would return the incorrect
   numbers when the file mode was set with a preceding 0. The YAML  parser
   used  in  Salt has been modified to no longer convert these number into
   octal but to keep them as the correct value so that sls files can be  a
   little cleaner to write.

   State Call Data Files
   It  was requested that the minion keep a local cache of the most recent
   executed state run. This has been added and now  with  state  runs  the
   data is stored in a msgpack file in the minion's cachedir.

   Turning Off the Job Cache
   A  new  option  has  been  added  to  the master configuration file. In
   previous releases the Salt client would look over the Salt job cache to
   read  in  the minion return data. With the addition of the event system
   the Salt client can now watch  for  events  directly  from  the  master
   worker processes.

   This  means that the job cache is no longer a hard requirement. Keep in
   mind though, that turning off the job cache  means  that  historic  job
   execution data cannot be retrieved.

   Test Updates
   Minion Swarms Are Faster
   To  continue  our  efforts  with  testing  Salt's  ability to scale the
   minionswarm script has been updated. The minionswarm can now  start  up
   minions  much  faster than it could before and comes with a new feature
   allowing modules to be disabled, thus lowering the  minion's  footprint
   when making a swarm. These new updates have allows us to test

      # python minionswarm.py -m 20 --master salt-master

   Many Fixes
   To  get a good idea for the number of bugfixes this release offers take
   a look at the closed tickets for 0.10.0, this  is  a  very  substantial
   update:

   https://github.com/saltstack/salt/issues?milestone=12&state=closed

   Master and Minion Stability Fixes
   As  Salt deployments grow new ways to break Salt are discovered. 0.10.0
   comes with a number  of  fixes  for  the  minions  and  master  greatly
   improving Salt stability.

   Salt 0.10.1 Release Notes
   release
          2012-06-19

   Salt 0.10.2 Release Notes
   release
          2012-07-30

   0.10.2  is  out!  This  release  comes  with enhancements to the pillar
   interface, cleaner ways to access the  salt-call  capabilities  in  the
   API,  minion  data  caching and the event system has been added to salt
   minions.

   There have also been updates to the ZeroMQ functions, many  more  tests
   (thanks to sponsors, the code sprint and many contributors) and a swath
   of bug fixes.

   Major Features
   Ext Pillar Modules
   The ranks of available Salt modules directories sees a  new  member  in
   0.10.2.   With  the popularity of pillar a higher demand has arisen for
   ext_pillar interfaces to be more like regular  Salt  module  additions.
   Now  ext_pillar  interfaces  can  be  added  in  the  same way as other
   modules, just drop it into the pillar directory in the salt source.

   Minion Events
   In 0.10.0 an event system was added to the Salt master. 0.10.2 adds the
   event  system  to  the minions as well. Now event can be published on a
   local minion as well.

   The minions can also send events back up to the master. This means that
   Salt  is able to communicate individual events from the minions back up
   to the Master which are not associated with command.

   Minion Data Caching
   When pillar was introduced the landscape for available data was greatly
   enhanced. The minion's began sending grain data back to the master on a
   regular basis.

   The new config option on the master called minion_data_cache  instructs
   the  Salt  master to maintain a cache of the minion's grains and pillar
   data in the cachedir. This option is turned off  by  default  to  avoid
   hitting the disk more, but when enabled the cache is used to make grain
   matching from the salt command more powerful, since  the  minions  that
   will match can be predetermined.

   Backup Files
   By  default  all  files  replaced  by the file.managed and file.recurse
   states we simply deleted. 0.10.2 adds a  new  option.  By  setting  the
   backup  option  to  minion  the  files  are  backed  up before they are
   replaced.

   The backed up files are located in the cachedir under  the  file_backup
   directory.    On    a    default    system    this    will    be    at:
   /var/cache/salt/file_backup

   Configuration files
   salt-master and salt-minion automatically load additional configuration
   files    from    master.d/*.conf   respective   minion.d/*.conf   where
   master.d/minion.d is a directory in the  same  directory  as  the  main
   configuration file.

   Salt Key Verification
   A  number  of  users complained that they had inadvertently deleted the
   wrong salt authentication keys. 0.10.2 now displays what keys are going
   to be deleted and verifies that they are the keys that are intended for
   deletion.

   Key auto-signing
   If autosign_file is specified in the configuration file  incoming  keys
   will  be  compared  to  the  list of keynames in autosign_file. Regular
   expressions as well as globbing is supported.

   The file must only be writable by the user otherwise the file  will  be
   ignored.  To  relax the permission and allow group write access set the
   permissive_pki_access option.

   Module changes
   Improved OpenBSD support
   New modules for managing services and packages were provided by  Joshua
   Elsasser to further improve the support for OpenBSD.

   Existing  modules  like  the  disk module were also improved to support
   OpenBSD.

   SQL Modules
   The MySQL and  PostgreSQL  modules  have  both  received  a  number  of
   additions thanks to the work of Avi Marcus and Roman Imankulov.

   ZFS Support on FreeBSD
   A  new  ZFS  module  has  been  added  by  Kurtis  Velarde  for FreeBSD
   supporting various ZFS operations like creating, extending or  removing
   zpools.

   Augeas
   A  new  Augeas module by Ulrich Dangel for editing and verifying config
   files.

   Native Debian Service module
   The support for the Debian was further improved  with  an  new  service
   module for Debian by Ahmad Khayyat supporting disable and enable.

   Cassandra
   Cassandra support has been added by Adam Garside. Currently only status
   and diagnostic information are supported.

   Networking
   The networking support for RHEL has been improved and supports  bonding
   support as well as zeroconf configuration.

   Monit
   Basic monit support by Kurtis Velarde to control services via monit.

   nzbget
   Basic support for controlling nzbget by Joseph Hall

   Bluetooth
   Baisc  bluez  support  for  managing and controlling Bluetooth devices.
   Supports scanning as well as pairing/unpairing by Joseph Hall.

   Test Updates
   Consistency Testing
   Another testing script has been added. A bug was found in  pillar  when
   many minions generated pillar data at the same time. The new consist.py
   script is the tests directory was created to reproduce bugs where  data
   should always be consistent.

   Many Fixes
   To  get a good idea for the number of bugfixes this release offers take
   a look at the closed tickets for 0.10.2, this  is  a  very  substantial
   update:

   https://github.com/saltstack/salt/issues?milestone=24&page=1&state=closed

   Master and Minion Stability Fixes
   As Salt deployments grow new ways to break Salt are discovered.  0.10.2
   comes  with  a  number  of  fixes  for  the  minions and master greatly
   improving Salt stability.

   Salt 0.10.3 Release Notes
   release
          2012-09-30

   The latest taste of Salt has come, this  release  has  many  fixes  and
   feature   additions.  Modifications  have  been  made  to  make  ZeroMQ
   connections more reliable, the beginning of the ACL system is in place,
   a  new  command  line  parsing  system  has  been added, dynamic module
   distribution has become more environment aware, the  new  master_finger
   option and many more!

   Major Features
   ACL System
   The  new  ACL  system  has  been  introduced. The ACL system allows for
   system users other than root to execute salt  commands.  Users  can  be
   allowed  to  execute specific commands in the same way that minions are
   opened up to the peer system.

   The configuration value to open up the ACL system is called  client_acl
   and is configured like so:

      client_acl:
        fred:
          - test..*
          - pkg.list_pkgs

   Where fred is allowed access to functions in the test module and to the
   pkg.list_pkgs function.

   Master Finger Option
   The master_finger option has been added  to  improve  the  security  of
   minion   provisioning.   The   master_finger   option  allows  for  the
   fingerprint of the master public key to be  set  in  the  configuration
   file  to  double verify that the master is valid. This option was added
   in response  to  a  motivation  to  pre-authenticate  the  master  when
   provisioning  new  minions to help prevent man in the middle attacks in
   some situations.

   Salt Key Fingerprint Generation
   The ability to generate fingerprints of keys  used  by  Salt  has  been
   added to salt-key. The new option finger accepts the name of the key to
   generate and display a fingerprint for.

      salt-key -F master

   Will display the fingerprints for the master public and private keys.

   Parsing System
   Pedro Algavio, aka s0undt3ch, has added a  substantial  update  to  the
   command  line  parsing  system  that makes the help message output much
   cleaner  and  easier  to  search  through.  Salt   parsers   now   have
   --versions-report  besides  usual  --version info which you can provide
   when reporting any issues found.

   Key Generation
   We have reduced the requirements needed for salt-key to generate minion
   keys.   You're  no  longer  required  to  have salt configured and it's
   common directories created just to  generate  keys.  This  might  prove
   useful if you're batch creating keys to pre-load on minions.

   Startup States
   A  few  configuration options have been added which allow for states to
   be run when the minion daemon starts. This can  be  a  great  advantage
   when deploying with Salt because the minion can apply states right when
   it  first  runs.  To  use  startup  states   set   the   startup_states
   configuration option on the minion to highstate.

   New Exclude Declaration
   Some users have asked about adding the ability to ensure that other sls
   files or ids are excluded from a state run. The exclude statement  will
   delete  all  of  the  data  loaded  from the specified sls file or will
   delete the specified id:

      exclude:
        - sls: http
        - id: /etc/vimrc

   Max Open Files
   While we're currently unable to properly handle ZeroMQ's abort  signals
   when  the  max  open files is reached, due to the way that's handled on
   ZeroMQ's, we have minimized the chances of this  happening  without  at
   least warning the user.

   More State Output Options
   Some  major  changes  have been made to the state output system. In the
   past state return data was printed in a very verbose fashion  and  only
   states  that  failed  or  made changes were printed by default. Now two
   options can be passed to the master and minion configuration  files  to
   change  the  behavior  of  the state output. State output can be set to
   verbose (default) or non-verbose with the state_verbose option:

      state_verbose: False

   It is noteworthy that the state_verbose option used to be set to  False
   by  default  but  has  been changed to True by default in 0.10.3 due to
   many requests for the change.

   Te next option to be aware of new and called state_output. This  option
   allows for the state output to be set to full (default) or terse.

   The  full output is the standard state output, but the new terse output
   will print only one line per state making the  output  much  easier  to
   follow when executing a large state system.

      state_output: terse

   state.file.append Improvements
   The  salt  state  file.append()  tries  not  to  append  existing text.
   Previously the matching check was being made line by line.  While  this
   kind  of  check  might  be  enough  for  most  cases, if the text being
   appended was multi-line, the check would not work properly. This  issue
   is  now  properly  handled,  the  match is done as a whole ignoring any
   white space addition  or  removal  except  inside  commas.   For  those
   thinking  that,  in  order  to properly match over multiple lines, salt
   will load the whole file into memory, that's not true. For  most  cases
   this is not important but an erroneous order to read a 4GB file, if not
   properly handled, like salt does, could make salt chew that  amount  of
   memory.   Salt  has  a buffered file reader which will keep in memory a
   maximum of 256KB and iterates over the file in chunks of 32KB  to  test
   for  the  match,  more  than  enough,  if  not, explain your usage on a
   ticket.   With   this   change,   also    salt.modules.file.contains(),
   salt.modules.file.contains_regex(),   salt.modules.file.contains_glob()
   and salt.utils.find now do the  searching  and/or  matching  using  the
   buffered chunks approach explained above.

   Two  new  keyword arguments were also added, makedirs, and source.  The
   first, makedirs will create  the  necessary  directories  in  order  to
   append  to  the  specified  file,  of  course, it only applies if we're
   trying to append to a non-existing file on a non-existing directory:

      /tmp/salttest/file-append-makedirs:
          file.append:
              text: foo
              makedirs: True

   The second, source, allows one to append the contents of a file instead
   of specifying the text.

      /tmp/salttest/file-append-source:

      file.append:
          - source: salt://testfile

   Security Fix
   A timing vulnerability was uncovered in the code which decrypts the AES
   messages sent over the network. This has been fixed  and  upgrading  is
   strongly recommended.

   Salt 0.10.4 Release Notes
   release
          2012-10-23

   Salt  0.10.4  is  a  monumental release for the Salt team, with two new
   module systems, many  additions  to  allow  granular  access  to  Salt,
   improved platform support and much more.

   This  release is also exciting because we have been able to shorten the
   release cycle back to under a month. We are working hard to keep up the
   aggressive  pace  and  look  forward  to  having  releases  happen more
   frequently!

   This release also includes a serious security fix  and  all  users  are
   very  strongly  recommended  to  upgrade.  As usual, upgrade the master
   first, and then the minion to ensure that the process is smooth.

   Major Features
   External Authentication System
   The new external authentication system allows for Salt to pass  through
   authentication  to any authentication system to determine if a user has
   permission to execute a Salt command. The Unix PAM system is the  first
   supported system with more to come!

   The  external  authentication  system  allows  for specific users to be
   granted access to  execute  specific  functions  on  specific  minions.
   Access is configured in the master configuration file, and uses the new
   access control system:

      external_auth:
        pam:
          thatch:
            - 'web*':
              - test.*
              - network.*

   The configuration above allows the user thatch to execute functions  in
   the test and network modules on minions that match the web* target.

   Access Control System
   All   Salt   systems   can   now  be  configured  to  grant  access  to
   non-administrative users in  a  granular  way.  The  old  configuration
   continues  to  work.  Specific  functions  can be opened up to specific
   minions from specific users in the case of  external  auth  and  client
   ACLs, and for specific minions in the case of the peer system.

   Access controls are configured like this:

      client_acl:
        fred:
          - web\*:
            - pkg.list_pkgs
            - test.*
            - apache.*

   Target by Network
   A  new matcher has been added to the system which allows for minions to
   be targeted by network. This new matcher can be called with the -S flag
   on  the  command  line  and is available in all places that the matcher
   system is available. Using it is simple:

      $ salt -S '192.168.1.0/24' test.ping
      $ salt -S '192.168.1.100' test.ping

   Nodegroup Nesting
   Previously a nodegroup was limited by not being able to include another
   nodegroup,  this  restraint  has been lifted and now nodegroups will be
   expanded within other nodegroups with the N@ classifier.

   Salt Key Delete by Glob
   The ability to delete minion keys by glob has been added  to  salt-key.
   To delete all minion keys whose minion name starts with 'web':

      $ salt-key -d 'web*'

   Master Tops System
   The  external_nodes  system  has  been  upgraded  to  allow for modular
   subsystems to be used to generate the top file  data  for  a  highstate
   run.

   The  external_nodes  option  still  works but will be deprecated in the
   future in favor of the new master_tops option.

   Example of using master_tops:

      master_tops:
        ext_nodes: cobbler-external-nodes

   Next Level Solaris Support
   A lot of work has been put  into  improved  Solaris  support  by  Romeo
   Theriault.   Packaging  modules  (pkgadd/pkgrm and pkgutil) and states,
   cron support and user and group management  have  all  been  added  and
   improved  upon.  These  additions  along  with  SMF (Service Management
   Facility) service support  and  improved  Solaris  grain  detection  in
   0.10.3  add  up to Salt becoming a great tool to manage Solaris servers
   with.

   Security
   A vulnerability in the  security  handshake  was  found  and  has  been
   repaired,  old minions should be able to connect to a new master, so as
   usual, the master should be updated first and then the minions.

   Pillar Updates
   The pillar communication has been updated to add some extra  levels  of
   verification  so  that  the  intended minion is the only one allowed to
   gather the data. Once all minions and the master are  updated  to  salt
   0.10.4  please  activate pillar 2 by changing the pillar_version in the
   master config to 2. This will be set  to  2  by  default  in  a  future
   release.

   Salt 0.10.5 Release Notes
   release
          2012-11-15

   Salt  0.10.5  is  ready,  and comes with some great new features. A few
   more interfaces have been modularized, like the outputter  system.  The
   job  cache  system  has  been  made more powerful and can now store and
   retrieve jobs archived in external databases. The returner  system  has
   been  extended to allow minions to easily retrieve data from a returner
   interface.

   As usual, this is an exciting release, with many noteworthy additions!

   Major Features
   External Job Cache
   The external job  cache  is  a  system  which  allows  for  a  returner
   interface  to also act as a job cache. This system is intended to allow
   users to store job information in a central location for longer periods
   of  time  and  to  make  the  act  of  looking up information from jobs
   executed on other minions easier.

   Currently the external job cache is supported via the mongo  and  redis
   returners:

      ext_job_cache: redis
      redis.host: salt

   Once the external job cache is turned on the new ret module can be used
   on the minions to retrieve return information from the job cache.  This
   can be a great way for minions to respond and react to other minions.

   OpenStack Additions
   OpenStack integration with Salt has been moving forward at a blistering
   pace.  The  new  nova,  glance,  and  keystone  modules  represent  the
   beginning of ongoing OpenStack integration.

   The Salt team has had many conversations with core OpenStack developers
   and is working on linking to OpenStack in powerful new ways.

   Wheel System
   A new API was added to the Salt Master which allows the  master  to  be
   managed  via an external API. This new system allows Salt API to easily
   hook into the Salt Master and manage configs, modify  the  state  tree,
   manage the pillar and more. The main motivation for the wheel system is
   to enable features needed in the upcoming web UI so  users  can  manage
   the master just as easily as they manage minions.

   The  wheel  system  has also been hooked into the external auth system.
   This allows specific users to have granular access to manage components
   of the Salt Master.

   Render Pipes
   Jack  Kuan has added a substantial new feature. The render pipes system
   allows Salt to treat the render system like unix pipes. This new system
   enables  sls  files to be passed through specific render engines. While
   the default renderer is still recommended, different engines can now be
   more easily merged. So to pipe the output of Mako used in YAML use this
   shebang line:

   #!mako|yaml

   Salt Key Overhaul
   The Salt Key system was originally developed as only a  CLI  interface,
   but  as  time  went  on it was pressed into becoming a clumsy API. This
   release marks a complete overhaul  of  Salt  Key.  Salt  Key  has  been
   rewritten  to  function  purely  from  an  API and to use the outputter
   system. The benefit here is that the outputter system works  much  more
   cleanly  with  Salt  Key now, and the internals of Salt Key can be used
   much more cleanly.

   Modular Outputters
   The outputter system is now loaded in a modular way.  This  means  that
   output  systems can be more easily added by dropping a python file down
   on the master that contains the function output.

   Gzip from Fileserver
   Gzip compression has been added as an option  to  the  cp.get_file  and
   cp.get_dir  commands.  This will make file transfers more efficient and
   faster, especially over slower network links.

   Unified Module Configuration
   In past releases of Salt, the  minions  needed  to  be  configured  for
   certain  modules  to  function.  This was difficult because it required
   pre-configuring the minions. 0.10.5 changes this by making  all  module
   configs on minions search the master config file for values.

   Now  if  a  single database server is needed, then it can be defined in
   the  master  config  and  all  minions  will  become   aware   of   the
   configuration value.

   Salt Call Enhancements
   The  salt-call  command  has been updated in a few ways. Now, salt-call
   can take the --return option to send the  data  to  a  returner.  Also,
   salt-call now reports executions in the minion proc system, this allows
   the master to be aware of the operation salt-call is running.

   Death to pub_refresh and sub_timeout
   The old configuration values  pub_refresh  and  sub_timeout  have  been
   removed.   These  options  were in place to alleviate problems found in
   earlier versions of ZeroMQ which have since been fixed.  The  continued
   use  of these options has proven to cause problems with message passing
   and have been completely removed.

   Git Revision Versions
   When running Salt directly from git (for  testing  or  development,  of
   course)  it  has  been  difficult  to  know  exactly what code is being
   executed. The new versioning system will detect the git  revision  when
   building  and how many commits have been made since the last release. A
   release from git will look like this:

   0.10.4-736-gec74d69

   Svn Module Addition
   Anthony Cornehl (twinshadow) contributed a module that adds  Subversion
   support  to  Salt.   This  great  addition  helps  round out Salt's VCS
   support.

   Noteworthy Changes
   Arch Linux Defaults to Systemd
   Arch Linux recently changed to use systemd by default and  discontinued
   support  for  init  scripts.  Salt  has  followed  suit and defaults to
   systemd now for managing services in Arch.

   Salt, Salt Cloud and Openstack
   With the releases of  Salt  0.10.5  and  Salt  Cloud  0.8.2,  OpenStack
   becomes the first (non-OS) piece of software to include support both on
   the user level (with Salt Cloud) and the admin level  (with  Salt).  We
   are  excited  to  continue to extend support of other platforms at this
   level.

   Salt 0.11.0 Release Notes
   release
          2012-12-14

   Salt 0.11.0 is  here,  with  some  highly  sought  after  and  exciting
   features.  These features include the new overstate system, the reactor
   system, a  new  state  run  scope  component  called  __context__,  the
   beginning  of  the  search  system  (still needs a great deal of work),
   multiple package states, the MySQL returner  and  a  better  system  to
   arbitrarily reference outputters.

   It is also noteworthy that we are changing how we mark release numbers.
   For the life of the project we have been  pushing  every  release  with
   features  and  fixes  as point releases. We will now be releasing point
   releases for only bug fixes on a more regular basis and  major  feature
   releases  on  a  slightly  less regular basis. This means that the next
   release will be a bugfix only release with a version number of  0.11.1.
   The  next feature release will be named 0.12.0 and will mark the end of
   life for the 0.11 series.

   Major Features
   OverState
   The overstate system is a simple way to manage rolling state executions
   across  many minions. The overstate allows for a state to depend on the
   successful completion of another state.

   Reactor System
   The new reactor system allows for a reactive logic engine to be created
   which  can  respond  to events within a salted environment. The reactor
   system uses sls files to match events fired on the master with actions,
   enabling Salt to react to problems in an infrastructure.

   Your  load-balanced  group of webservers is under extra load? Spin up a
   new VM and add it to the group. Your fileserver is filling up?  Send  a
   notification to your sysadmin on call. The possibilities are endless!

   Module Context
   A  new component has been added to the module loader system. The module
   context is a data structure that can hold objects  for  a  given  scope
   within the module.

   This  allows  for  components  that  are  initialized to be stored in a
   persistent context which can  greatly  speed  up  ongoing  connections.
   Right now the best example can be found in the cp execution module.

   Multiple Package Management
   A  long  desired  feature  has  been  added  to  package management. By
   definition Salt States have always installed packages one at a time. On
   most  platforms  this  is not the fastest way to install packages. Erik
   Johnson, aka terminalmage, has modified the package  modules  for  many
   providers  and  added  new  capabilities to install groups of packages.
   These package groups can be defined as a list of packages available  in
   repository servers:

      python_pkgs:
        pkg.installed:
          - pkgs:
            - python-mako
            - whoosh
            - python-git

   or specify based on the location of specific packages:

      python_pkgs:
        pkg.installed:
          - sources:
            - python-mako: http://some-rpms.org/python-mako.rpm
            - whoosh: salt://whoosh/whoosh.rpm
            - python-git: ftp://companyserver.net/python-git.rpm

   Search System
   The  bones  to  the search system have been added. This is a very basic
   interface that allows  for  search  backends  to  be  added  as  search
   modules.  The  first  supported  search  module  is  the  whoosh search
   backend. Right now only the basic paths for the search  system  are  in
   place, making this very experimental.  Further development will involve
   improving the search routines and index routines for whoosh  and  other
   search backends.

   The  search  system has been made to allow for searching through all of
   the state and pillar files, configuration files  and  all  return  data
   from minion executions.

   Notable Changes
   All  previous versions of Salt have shared many directories between the
   master and minion. The default locations  for  keys,  cached  data  and
   sockets  has been shared by master and minion. This has created serious
   problems with running a master and a minion on the same systems. 0.11.0
   changes the defaults to be separate directories. Salt will also attempt
   to migrate all of the old key data into the  correct  new  directories,
   but  if  it  is not successful it may need to be done manually. If your
   keys exhibit issues after updating make sure that they have been  moved
   from /etc/salt/pki to /etc/salt/pki/{master,minion}.

   The old setup will look like this:

      /etc/salt/pki
      |-- master.pem
      |-- master.pub
      |-- minions
      |   `-- ragnarok.saltstack.net
      |-- minions_pre
      |-- minion.pem
      |-- minion.pub
      |-- minion_master.pub
      |-- minions_pre
      `-- minions_rejected

   With  the  accepted minion keys in /etc/salt/pki/minions, the new setup
   places the accepted minion keys in /etc/salt/pki/master/minions.

      /etc/salt/pki
      |-- master
      |   |-- master.pem
      |   |-- master.pub
      |   |-- minions
      |   |   `-- ragnarok.saltstack.net
      |   |-- minions_pre
      |   `-- minions_rejected
      |-- minion
      |   |-- minion.pem
      |   |-- minion.pub
      |   `-- minion_master.pub

   Salt 0.11.1 Release Notes
   release
          2012-12-19

   Salt 0.12.0 Release Notes
   release
          2013-01-15

   Another feature release of Salt is here! Some  exciting  additions  are
   included with more ways to make salt modular and even easier management
   of the salt file server.

   Major Features
   Modular Fileserver Backend
   The new modular fileserver backend allows for any external system to be
   used  as  a  salt  file server. The main benefit here is that it is now
   possible to tell the master to directly use a git remote  location,  or
   many  git remote locations, automatically mapping git branches and tags
   to salt environments.

   Windows is First Class!
   A new Salt Windows installer is now available! Much work has  been  put
   in  to improve Windows support. With this much easier method of getting
   Salt on your Windows  machines,  we  hope  even  more  development  and
   progress  will  occur.  Please file bug reports on the Salt GitHub repo
   issue tracker so we can continue improving.

   One thing that is missing on Windows that Salt uses  extensively  is  a
   software  package  manager  and a software package repository. The Salt
   pkg  state  allows  sys  admins  to  install  software   across   their
   infrastructure  and  across  operating systems. Software on Windows can
   now be managed in the same way. The  SaltStack  team  built  a  package
   manager  that interfaces with the standard Salt pkg module to allow for
   installing and removing software on Windows. In  addition,  a  software
   package  repository  has  been  built  on top of the Salt fileserver. A
   small YAML file provides the  information  necessary  for  the  package
   manager to install and remove software.

   An  interesting  feature  of  the  new  Salt  Windows  software package
   repository is that one or more remote git repositories  can  supplement
   the  master's local repository. The repository can point to software on
   the master's fileserver or on an HTTP, HTTPS, or ftp server.

   New Default Outputter
   Salt displays data to the terminal via the outputter system. For a long
   time  the  default  outputter for Salt has been the python pretty print
   library.  While this has been a generally reasonable outputter, it  did
   have  many  failings.  The new default outputter is called "nested", it
   recursively scans return data structures and prints them out cleanly.

   If the result of the new nested outputter  is  not  desired  any  other
   outputter can be used via the --out option, or the output option can be
   set in the master and minion configs to change the default outputter.

   Internal Scheduler
   The internal Salt scheduler  is  a  new  capability  which  allows  for
   functions  to  be  executed  at  given intervals on the minion, and for
   runners to be executed at given intervals on the master. The  scheduler
   allows  for  sequences  such  as  executing  state runs (locally on the
   minion or remotely via an overstate) or  continually  gathering  system
   data to be run at given intervals.

   The  configuration  is simple, add the schedule option to the master or
   minion config and specify jobs to run, this in the master  config  will
   execute the state.over runner every 60 minutes:

      schedule:
        overstate:
          function: state.over
          minutes: 60

   This  example  for  the  minion  configuration will execute a highstate
   every 30 minutes:

      schedule:
        highstate:
          function: state.highstate
          minutes: 30

   Optional DSL for SLS Formulas
   Jack  Kuan,  our  renderer  expert,  has  created  something  that   is
   astonishing.   Salt,  now comes with an optional Python based DSL, this
   is a very powerful interface that  makes  writing  SLS  files  in  pure
   python  easier  than it was with the raw py renderer. As usual this can
   be used with the renderer shebang line, so a single sls can be  written
   with  the  DSL  if  pure python power is needed while keeping other sls
   files simple with YAML.

   Set Grains Remotely
   A new execution function and state module have been added  that  allows
   for  grains to be set on the minion. Now grains can be set via a remote
   execution  or  via  states.  Use  the  grains.present  state   or   the
   grains.setval execution functions.

   Gentoo Additions
   Major  additions  to  Gentoo  specific  components  have been made. The
   encompasses executions modules and states ranging from  supporting  the
   make.conf file to tools like layman.

   Salt 0.12.1 Release Notes
   release
          2013-01-21

   Salt 0.13.0 Release Notes
   release
          2013-02-12

   The  lucky number 13 has turned the corner! From CLI notifications when
   quitting a salt command, to substantial improvements on  Windows,  Salt
   0.13.0 has arrived!

   Major Features
   Improved file.recurse Performance
   The  file.recurse  system has been deployed and used in a vast array of
   situations. Fixes to the file state and module have led towards opening
   up  new  ways  of  running  file.recurse  to  make  it  faster. Now the
   file.recurse state will download fewer files and will run substantially
   faster.

   Windows Improvements
   Minion  stability  on  Windows  has  improved.  Many  file  operations,
   including file.recurse, have  been  fixed  and  improved.  The  network
   module  works  better,  to  include  network.interfaces. Both 32bit and
   64bit installers are now available.

   Nodegroup Targeting in Peer System
   In the past, nodegroups were not available for targeting via  the  peer
   system.   This  has  been  fixed,  allowing the new nodegroup expr_form
   argument for the publish.publish function:
      salt-call publish.publish group1 test.ping expr_form=nodegroup

   Blacklist Additions
   Additions allowing more granular blacklisting are available in  0.13.0.
   The  ability  to  blacklist users and functions in client_acl have been
   added, as well as the  ability  to  exclude  state  formulas  from  the
   command line.

   Command Line Pillar Embedding
   Pillar  data  can  now  be  embedded  on  the command line when calling
   state.sls and state.highstate. This allows for on the  fly  changes  or
   settings to pillar and makes parameterizing state formulas even easier.
   This is done via the keyword argument:

      salt '*' state.highstate pillar='{"cheese": "spam"}'

   The above example will extend the existing pillar to  hold  the  cheese
   key with a value of spam. If the cheese key is already specified in the
   minion's pillar then it will be overwritten.

   CLI Notifications
   In the past hitting ctrl-C and quitting from  the  salt  command  would
   just  drop  to  a  shell  prompt,  this caused confusion with users who
   expected the remote executions to also quit. Now a message is displayed
   showing  what  command  can be used to track the execution and what the
   job id is for the execution.

   Version Specification in Multiple-Package States
   Versions can now be  specified  within  multiple-package  pkg.installed
   states. An example can be found below:

      mypkgs:
        pkg.installed:
          - pkgs:
            - foo
            - bar: 1.2.3-4
            - baz

   Noteworthy Changes
   The  configuration  subsystem  in  Salt has been overhauled to make the
   opts dict used by Salt applications more portable, the problem is  that
   this  is  an  incompatible  change with salt-cloud, and salt-cloud will
   need to be updated to the latest git to work  with  Salt  0.13.0.  Salt
   Cloud 0.8.5 will also require Salt 0.13.0 or later to function.

   The SaltStack team is sorry for the inconvenience here, we work hard to
   make sure these sorts of things  do  not  happen,  but  sometimes  hard
   changes get in.

   Salt 0.13.1 Release Notes
   release
          2013-02-15

   Salt 0.13.2 Release Notes
   release
          2013-03-13

   Salt 0.13.3 Release Notes
   release
          2013-03-18

   Salt 0.14.0 Release Notes
   release
          2013-03-23

   Salt  0.14.0  is  here!  This  release  was held up primarily by PyCon,
   Scale, and illness,  but  has  arrived!  0.14.0  comes  with  many  new
   features  and  is  breaking  ground  for  Salt  in  the  area  of cloud
   management  with  the  introduction  of  Salt  providing  basic   cloud
   controller functionality.

   Major Features
   Salt - As a Cloud Controller
   This  is the first primitive inroad to using Salt as a cloud controller
   is available in 0.14.0. Be advised that this is alpha, only tested in a
   few very small environments.

   The   cloud   controller  is  built  using  kvm  and  libvirt  for  the
   hypervisors.  Hypervisors are autodetected as minions and only need  to
   have libvirt running and kvm installed to function. The features of the
   Salt cloud controller are as follows:

      * Basic vm discovery and reporting

      * Creation of new virtual machines

      * Seeding virtual machines with Salt via qemu-nbd or libguestfs

      * Live migration (shared and non shared storage)

      * Delete existing VMs

   It is noteworthy that this feature is still  Alpha,  meaning  that  all
   rights  are  reserved  to  change  the  interface if needs be in future
   releases!

   Libvirt State
   One of the problems with libvirt is management of  certificates  needed
   for live migration and cross communication between hypervisors. The new
   libvirt state makes the Salt Master hold a CA and  manage  the  signing
   and  distribution  of  keys  onto  hypervisors,  just add a call to the
   libvirt state in the sls formulas used to set up a hypervisor:

      libvirt_keys:
        libvirt.keys

   New get Functions
   An easier way to manage data has been introduced. The  pillar,  grains,
   and  config  execution  modules  have  been  extended  with the new get
   function. This function works much in the same way as the get method in
   a  python  dict, but with an enhancement, nested dict components can be
   extracted using a : delimiter.

   If a structure like this is in pillar:

      foo:
        bar:
          baz: quo

   Extracting it from the raw pillar in an sls formula or file template is
   done this way:

      {{ pillar['foo']['bar']['baz'] }}

   Now  with  the  new  get function the data can be safely gathered and a
   default can be set allowing the template to fall back if the  value  is
   not available:

      {{ salt['pillar.get']('foo:bar:baz', 'qux') }}

   This  makes handling nested structures much easier, and defaults can be
   cleanly set. This new function is being used  extensively  in  the  new
   formulae repository of salt sls formulas.

   Salt 0.14.1 Release Notes
   release
          2013-04-13

   Salt 0.15.0 Release Notes
   release
          2013-05-03

   The  many  new  features of Salt 0.15.0 have arrived! Salt 0.15.0 comes
   with many smaller features and a few larger ones.

   These features range from better debugging tools to the new  Salt  Mine
   system.

   Major Features
   The Salt Mine
   First  there  was the peer system, allowing for commands to be executed
   from a minion to other minions to gather data live. Then there was  the
   external  job  cache  for storing and accessing long term data. Now the
   middle ground is being filled in with the Salt Mine. The Salt Mine is a
   system used to execute functions on a regular basis on minions and then
   store only the most recent data from the functions on the master,  then
   the data is looked up via targets.

   The  mine  caches  data that is public to all minions, so when a minion
   posts data to the mine all other minions can see it.

   IPV6 Support
   0.13.0 saw the  addition  of  initial  IPV6  support  but  errors  were
   encountered and it needed to be stripped out. This time the code covers
   more cases and must be explicitly enabled. But the support is much more
   extensive than before.

   Copy Files From Minions to the Master
   Minions  have  long  been  able to copy files down from the master file
   server, but until now files could not be easily copied from the  minion
   up to the master.

   A new function called cp.push can push files from the minions up to the
   master server. The uploaded files are then cached on the master in  the
   master cachedir for each minion.

   Better Template Debugging
   Template errors have long been a burden when writing states and pillar.
   0.15.0 will now send the compiled template data to the debug log,  this
   makes  tracking  down  the intermittent stage templates much easier. So
   running state.sls or state.highstate with -l debug will now  print  out
   the rendered templates in the debug information.

   State Event Firing
   The  state  system  is now more closely tied to the master's event bus.
   Now when a state fails the failure will be fired on  the  master  event
   bus so that the reactor can respond to it.

   Major Syndic Updates
   The  Syndic  system  has  been  basically  re-written. Now it runs in a
   completely asynchronous way and functions primarily as an event broker.
   This means that the events fired on the syndic are now pushed up to the
   higher level master instead of the old method used which waited for the
   client libraries to return.

   This  makes  the  syndic much more accurate and powerful, it also means
   that all events fired on the syndic master make it up the pipe as  well
   making  a  reactor  on the higher level master able to react to minions
   further downstream.

   Peer System Updates
   The Peer System has been updated to  run  using  the  client  libraries
   instead  of  firing  directly over the publish bus. This makes the peer
   system much more consistent and reliable.

   Minion Key Revocation
   In the past when a minion was  decommissioned  the  key  needed  to  be
   manually deleted on the master, but now a function on the minion can be
   used to revoke the calling minion's key:

      $ salt-call saltutil.revoke_auth

   Function Return Codes
   Functions can now be assigned numeric return codes to determine if  the
   function executed successfully. While not all functions have been given
   return codes, many have and it is an ongoing effort  to  fill  out  all
   functions that might return a non-zero return code.

   Functions in Overstate
   The  overstate  system  was  originally  created  to  just  manage  the
   execution  of  states,  but  with  the  addition  of  return  codes  to
   functions,  requisite  logic  can  now  be  used  with  respect  to the
   overstate. This means that  an  overstate  stage  can  now  run  single
   functions instead of just state executions.

   Pillar Error Reporting
   Previously  if errors surfaced in pillar, then the pillar would consist
   of only an empty dict. Now all  data  that  was  successfully  rendered
   stays  in pillar and the render error is also made available. If errors
   are found in the pillar, states will refuse to run.

   Using Cached State Data
   Sometimes states are executed  purely  to  maintain  a  specific  state
   rather  than to update states with new configs. This is grounds for the
   new cached state system. By adding cache=True to a state call the state
   will  not be generated fresh from the master but the last state data to
   be generated will be used.  If no previous state data is available then
   fresh data will be generated.

   Monitoring States
   The  new  monitoring states system has been started. This is very young
   but allows for states to be used to configure monitoring  routines.  So
   far  only  one monitoring state is available, the disk.status state. As
   more capabilities are added to Salt UI the monitoring  capabilities  of
   Salt will continue to be expanded.

   Salt 0.15.1 Release Notes
   release
          2013-05-08

   The  0.15.1  release  has been posted, this release includes fixes to a
   number of bugs in 0.15.1 and a three security patches.

   Security Updates
   A number of security issues have been resolved via the 0.15.1 release.

   Path Injection in Minion IDs
   Salt masters did not properly validate the id of a  connecting  minion.
   This can lead to an attacker uploading files to the master in arbitrary
   locations.  In particular  this  can  be  used  to  bypass  the  manual
   validation  of  new unknown minions. Exploiting this vulnerability does
   not require authentication.

   This issue affects all known versions of Salt.

   This issue was reported by Ronald Volgers.

   Patch
   The issue is fixed in Salt 0.15.1. Updated packages  are  available  in
   the usual locations.

   Specific commits:

   https://github.com/saltstack/salt/commit/5427b9438e452a5a8910d9128c6aafb45d8fd5d3

   https://github.com/saltstack/salt/commit/7560908ee62351769c3cd43b03d74c1ca772cc52

   https://github.com/saltstack/salt/commit/e200b8a7ff53780124e08d2bdefde7587e52bfca

   RSA Key Generation Fault
   RSA key generation was done incorrectly, leading to very insecure keys.
   It is recommended to regenerate all RSA keys.

   This  issue  can  be  used  to  impersonate Salt masters or minions, or
   decrypt any transferred data.

   This issue can only be exploited by attackers who are able  to  observe
   or modify traffic between Salt minions and the legitimate Salt master.

   A  tool  was included in 0.15.1 to assist in mass key regeneration, the
   manage.regen_keys runner.

   This issue affects all known versions of Salt.

   This issue was reported by Ronald Volgers.

   Patch
   The issue is fixed in Salt 0.15.1. Updated packages  are  available  in
   the usual locations.

   Specific commits:

   https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc

   Command Injection Via ext_pillar
   Arbitrary shell  commands  could  be  executed  on  the  master  by  an
   authenticated minion through options passed when requesting a pillar.

   Ext  pillar  options  have  been restricted to only allow safe external
   pillars to be called when prompted by the minion.

   This issue affects Salt versions from 0.14.0 to 0.15.0.

   This issue was reported by Ronald Volgers.

   Patch
   The issue is fixed in Salt 0.15.1. Updated packages  are  available  in
   the usual locations.

   Specific commits:

   https://github.com/saltstack/salt/commit/43d8c16bd26159d827d1a945c83ac28159ec5865

   Salt 0.15.2 Release Notes
   release
          2013-05-29

   Salt 0.15.3 Release Notes
   release
          2013-06-01

   Salt 0.16.0 Release Notes
   release
          2013-07-01

   The 0.16.0 release is an exciting one,  with  new  features  in  master
   redundancy, and a new, powerful requisite.

   Major Features
   Multi-Master
   This  new  capability  allows  for a minion to be actively connected to
   multiple salt masters at  the  same  time.  This  allows  for  multiple
   masters   to   send   out  commands  to  minions  and  for  minions  to
   automatically reconnect to masters that have gone down. A  tutorial  is
   available to help get started here:

   Multi Master Tutorial

   Prereq, the New Requisite
   The  new  prereq  requisite  is  very powerful! It allows for states to
   execute based on a state that  is  expected  to  make  changes  in  the
   future.  This  allows  for  a  change  on the system to be preempted by
   another execution. A good example is needing to  shut  down  a  service
   before  modifying  files  associated with it, allowing, for instance, a
   webserver to be shut down allowing a  load  balancer  to  stop  sending
   requests  while  server  side code is updated. In this case, the prereq
   will only run if changes are expected  to  happen  in  the  prerequired
   state, and the prerequired state will always run after the prereq state
   and only if the prereq state succeeds.

   Peer System Improvements
   The peer system has been revamped to make it more reliable, faster, and
   like the rest of Salt, async. The peer calls when an updated minion and
   master are used together will be much faster!

   Relative Includes
   The ability to include an sls relative to  the  defined  sls  has  been
   added, the new syntax id documented here:

   Includes

   More State Output Options
   The  state_output  option  in  the  past only supported full and terse,
   0.16.0 add the mixed and changes modes further refining how states  are
   sent to users' eyes.

   Improved Windows Support
   Support  for  Salt on Windows continues to improve. Software management
   on Windows  has  become  more  seamless  with  Linux/UNIX/BSD  software
   management.   Installed  software  is now recognized by the short names
   defined in the repository SLS. This makes it possible to run  salt  '*'
   pkg.version  firefox  and get back results from Windows and non-Windows
   minions alike.

   When templating files on Windows, Salt will now correctly  use  Windows
   appropriate line endings. This makes it much easier to edit and consume
   files on Windows.

   When using the cmd state the shell option  now  allows  for  specifying
   Windows  Powershell  as  an  alternate  shell  to  execute  cmd.run and
   cmd.script.  This opens up Salt to all the power of Windows  Powershell
   and its advanced Windows management capabilities.

   Several  fixes  and optimizations were added for the Windows networking
   modules, especially when working with IPv6.

   A system module was added that makes it easy to  restart  and  shutdown
   Windows minions.

   The  Salt  Minion  will now look for its config file in c:\salt\conf by
   default. This means that it's no longer necessary  to  specify  the  -c
   option  to  specify  the  location of the config file when starting the
   Salt Minion on Windows in a terminal.

   Multiple Targets for pkg.removed, pkg.purged States
   Both pkg.removed and pkg.purged now support the  pkgs  argument,  which
   allow  for multiple packages to be targeted in a single state. This, as
   in pkg.installed, helps speed up these states by reducing the number of
   times  that  the  package  management tools (apt, yum, etc.) need to be
   run.

   Random Times in Cron States
   The temporal parameters in cron.present states (minute, hour, etc.) can
   now  be  randomized  by  using  random instead of a specific value. For
   example, by using the random keyword in the minute parameter of a  cron
   state,  the  same  cron  job  can be pushed to hundreds or thousands of
   hosts, and they would each use a randomly-generated minute. This can be
   helpful  when  the  cron job accesses a network resource, and it is not
   desirable for all hosts to run the job concurrently.

      /path/to/cron/script:
        cron.present:
          - user: root
          - minute: random
          - hour: 2

   Since Salt assumes a value of * for  unspecified  temporal  parameters,
   adding  a  parameter  to the state and setting it to random will change
   that value from * to a randomized numeric value. However, if that field
   in  the cron entry on the minion already contains a numeric value, then
   using the random keyword will not modify it.

   Confirmation Prompt on Key Acceptance
   When accepting new keys with salt-key  -a  minion-id  or  salt-key  -A,
   there  is  now  a  prompt  that will show the affected keys and ask for
   confirmation before proceeding. This prompt can be bypassed  using  the
   -y or --yes command line argument, as with other salt-key commands.

   Support for Setting Password Hashes on BSD Minions
   FreeBSD,  NetBSD,  and  OpenBSD  all  now  support setting passwords in
   user.present states.

   Salt 0.16.1 Release Notes
   release
          2013-07-29

   Salt 0.16.2 Release Notes
   release
          2013-08-01

   Version 0.16.2 is a bugfix release for 0.16.0, and contains a number of
   fixes.

   Windows
   * Only  allow  Administrator's group and SYSTEM user access to C:\salt.
     This eliminates a race condition where a non-admin user could  modify
     a template or managed file before it is executed by the minion (which
     is running as an elevated user), thus avoiding a potential escalation
     of privileges. (issue 6361)

   Grains
   * Fixed detection of virtual grain on OpenVZ hardware nodes

   * Gracefully handle lsb_release data when it is enclosed in quotes

   * LSB grains are now prefixed with lsb_distrib_ instead of simply lsb_.
     The old naming is not preserved, so SLS may be affected.

   * Improved grains detection on MacOS

   Pillar
   * Don't try to load git_pillar if not enabled in master  config  (issue
     6052)

   * Functions   pillar.item   and  pillar.items  added  for  parity  with
     grains.item/grains.items. The old function pillar.data  is  preserved
     for backwards compatibility.

   * Fixed minion traceback when Pillar SLS is malformed (issue 5910)

   Peer Publishing
   * More  gracefully  handle  improperly  quoted  publish commands (issue
     5958)

   * Fixed   traceback   when   timeout   specified   via   the   CLI   fo
     publish.publish, publish.full_data (issue 5959)

   * Fixed unintended change in output of publish.publish (issue 5928)

   Minion
   * Fixed salt-key usage in minionswarm script

   * Quieted  warning  about  SALT_MINION_CONFIG  environment  variable on
     minion startup and for CLI commands run via salt-call (issue 5956)

   * Added minion config parameter random_reauth_delay to stagger  re-auth
     attempts  when  the  minion  is waiting for the master to approve its
     public key. This helps prevent SYN flooding in larger environments.

   User/Group Management
   * Implement previously-ignored unique option for user.present states in
     FreeBSD

   * Report  in  state output when a group.present state attempts to use a
     gid in use by another group

   * Fixed regression that  prevents  a  user.present  state  to  set  the
     password hash to the system default (i.e. an unset password)

   * Fixed multiple group.present states with the same group (issue 6439)

   File Management
   * Fixed file.mkdir setting incorrect permissions (issue 6033)

   * Fixed  cleanup  of  source  files  for  templates  when  /tmp  is  in
     file_roots (issue 6118)

   * Fixed caching of zero-byte files when a non-empty file was previously
     cached at the same path

   * Added HTTP authentication support to the cp module (issue 5641)

   * Diffs are now suppressed when binary files are changed

   Package/Repository Management
   * Fixed traceback when there is only one target for pkg.latest states

   * Fixed regression in detection of virtual packages (apt)

   * Limit    number    of    pkg   database   refreshes   to   once   per
     state.sls/state.highstate

   * YUM: Allow 32-bit packages with arches other than i686 to be  managed
     on 64-bit systems (issue 6299)

   * Fixed incorrect reporting in pkgrepo.managed states (issue 5517)

   * Fixed  32-bit  binary  package installs on 64-bit RHEL-based distros,
     and added proper support for 32-bit packages on  64-bit  Debian-based
     distros (issue 6303)

   * Fixed  issue  where  requisites were inadvertently being put into YUM
     repo files (issue 6471)

   Service Management
   * Fixed inaccurate reporting of results in service.running states  when
     the service fails to start (issue 5894)

   * Fixed  handling  of  custom initscripts in RHEL-based distros so that
     they are immediately available, negating the need for a second  state
     run to manage the service that the initscript controls

   Networking
   * Function   network.hwaddr   renamed   to   network.hw_addr  to  match
     network.ip_addrs and network.ip_addrs6. All three functions also  now
     work without the underscore in the name, as well.

   * Fixed  traceback  in bridge.show when interface is not present (issue
     6326)

   SSH
   * Fixed incorrect result  reporting  for  some  ssh_known_hosts.present
     states

   * Fixed  inaccurate reporting when ssh_auth.present states are run with
     test=True, when  rsa/dss  is  used  for  the  enc  param  instead  of
     ssh-rsa/ssh-dss (issue 5374)

   pip
   * Properly handle -f lines in pip freeze output

   * Fixed   regression   in   pip.installed   states  with  specifying  a
     requirements file (issue 6003)

   * Fixed use of editable argument in pip.installed states (issue 6025)

   * Deprecated runas parameter in execution function calls, in  favor  of
     user

   MySQL
   * Allow  specification  of  MySQL  connection  arguments  via  the CLI,
     overriding/bypassing minion config params

   * Allow mysql_user.present states to set a  passwordless  login  (issue
     5550)

   * Fixed endless loop when mysql.processlist is run (issue 6297)

   PostgreSQL
   * Fixed traceback in postgres.user_list (issue 6352)

   Miscellaneous
   * Don't allow npm states to be used if npm module is not available

   * Fixed  alternatives.install  states for which the target is a symlink
     (issue 6162)

   * Fixed traceback in sysbench module (issue 6175)

   * Fixed traceback in job cache

   * Fixed tempfile cleanup for windows

   * Fixed issue where SLS files using the pydsl renderer were  not  being
     run

   * Fixed  issue  where returners were being passed incorrect information
     (issue 5518)

   * Fixed traceback when numeric args are passed to cmd.script states

   * Fixed bug causing cp.get_dir to return more directories than expected
     (issue 6048)

   * Fixed   traceback   when  supervisord.running  states  are  run  with
     test=True (issue 6053)

   * Fixed tracebacks when Salt encounters problems running  rbenv  (issue
     5888)

   * Only  make  the  monit module available if monit binary is present (
     issue 5871)

   * Fixed incorrect behavior of img.mount_image

   * Fixed traceback in tomcat.deploy_war in Windows

   * Don't re-write /etc/fstab if mount fails

   * Fixed tracebacks when Salt encounters  problems  running  gem  (issue
     5886)

   * Fixed incorrect behavior of selinux.boolean states (issue 5912)

   * RabbitMQ:  Quote passwords to avoid symbols being interpolated by the
     shell (issue 6338)

   * Fixed tracebacks in extfs.mkfs and extfs.tune (issue 6462)

   * Fixed a regression with the module.run state  where  the  m_name  and
     m_fun arguments were being ignored (issue 6464)

   Salt 0.16.3 Release Notes
   release
          2013-08-09

   Version  0.16.3  is  another  bugfix  release  for  0.16.0. The changes
   include:

   * Various documentation fixes

   * Fix proc directory regression (issue 6502)

   * Properly detect Linaro Linux (issue 6496)

   * Fix regressions in mount.mounted (issue 6522, issue 6545)

   * Skip malformed state requisites (issue 6521)

   * Fix regression in gitfs from bad import

   * Fix for watching prereq states (including recursive requisite  error)
     (issue 6057)

   * Fix mod_watch not overriding prereq (issue 6520)

   * Don't allow functions which compile states to be called within states
     (issue 5623)

   * Return error for malformed top.sls (issue 6544)

   * Fix traceback in mysql.query

   * Fix regression in binary package installation for 64-bit packages  on
     Debian-based Linux distros (issue 6563)

   * Fix  traceback caused by running cp.push without having set file_recv
     in the master config file

   * Fix scheduler configuration in pillar (issue 6201)

   Salt 0.16.4 Release Notes
   release
          2013-09-07

   Version 0.16.4 is another bugfix release for 0.16.0, likely to  be  the
   last before 0.17.0 is released.  The changes include:

   * Multiple documentation improvements/additions

   * Added the osfinger and osarch grains

   * Properly handle 32-bit packages for debian32 on x86_64 (issue 6607)

   * Fix regression in yum package installation in CentOS 5 (issue 6677)

   * Fix  bug in hg.latest state that would erroneously delete directories
     (issue 6661)

   * Fix bug related to pid not existing for ps.top (issue 6679)

   * Fix regression in MySQL returner (issue 6695)

   * Fix IP addresses grains (ipv4 and ipv6) to include all  addresses  (
     issue 6656)

   * Fix regression preventing authenticated FTP (issue 6733)

   * Fix setting password for windows users (issue 6824)

   * Fix file.contains on values YAML parses as non-string (issue 6817)

   * Fix file.get_gid, file.get_uid, and file.chown for broken symlinks (
     issue 6826)

   * Fix comment for service reloads in service state (issue 6851)

   Salt 0.17.0 Release Notes
   release
          2013-09-26

   The 0.17.0 release is a very exciting release of Salt, this  brings  to
   Salt  some  very powerful new features and advances. The advances range
   from the state  system  to  the  test  suite,  covering  new  transport
   capabilities  and  making states easier and more powerful, to extending
   Salt Virt and much more!

   The 0.17.0 release will also be the last release of Salt to follow  the
   old  0.XX.X  numbering system, the next release of Salt will change the
   numbering to be date based following this format:

   <Year>.<Month>.<Minor>

   So if the release happens in  November  of  2013  the  number  will  be
   13.11.0, the first bugfix release will be 13.11.1 and so forth.

   Major Features
   Halite
   The  new  Halite web GUI is now available on PyPI. A great deal of work
   has been put into Halite to make it fully event  driven  and  amazingly
   fast.  The  Halite UI can be started from within the Salt Master (after
   being installed from PyPI), or standalone,  and  does  not  require  an
   external database to run.  It is very lightweight!

   This  initial  release  of Halite is primarily the framework for the UI
   and the communication systems, making it easy to extend and  build  the
   UI up. It presently supports watching the event bus and firing commands
   over Salt.

   At this time, Halite is not available as a  package,  but  installation
   documentation               is               available              at:
   http://docs.saltstack.com/topics/tutorials/halite.html

   Halite is, like the rest of Salt, Open Source!

   Much more will be coming in the future of Halite!

   Salt SSH
   The new salt-ssh command has been added to Salt. This system allows for
   remote execution and states to be run over ssh. The benefit here being,
   that salt can run relying only on the ssh agent, rather than  requiring
   a minion to be deployed.

   The  salt-ssh system runs states in a compatible way as Salt and states
   created and run with salt-ssh can be moved  over  to  a  standard  salt
   deployment without modification.

   Since  this is the initial release of salt-ssh, there is plenty of room
   for improvement, but it is fully  operational,  not  just  a  bootstrap
   tool.

   Rosters
   Salt  is  designed  to  have the minions be aware of the master and the
   master does not need to be aware of the location of  the  minions.  The
   new  salt  roster system was created and designed to facilitate listing
   the targets for salt-ssh.

   The roster system, like most of Salt, is a plugin system, allowing  for
   the list of systems to target to be derived from any pluggable backend.
   The rosters shipping with 0.17.0 are flat and  scan.  Flat  is  a  file
   which  is  read  in via the salt render system and the scan roster does
   simple network scanning to discover ssh servers.

   State Auto Order
   This is a major change in how states are evaluated in Salt. State  Auto
   Order  is a new feature that makes states get evaluated and executed in
   the order in which they are defined in the sls file. This feature makes
   it  very easy to see the finite order in which things will be executed,
   making Salt now, fully imperative AND fully declarative.

   The requisite system still takes precedence over  the  order  in  which
   states  are  defined,  so  no  existing  states  should break with this
   change.  But  this  new  feature  can  be   turned   off   by   setting
   state_auto_order: False in the master config, thus reverting to the old
   lexicographical order.

   state.sls Runner
   The state.sls runner has been created to  allow  for  a  more  powerful
   system  for orchestrating state runs and function calls across the salt
   minions.  This  new  system  uses  the  state  system  for   organizing
   executions.

   This allows for states to be defined that are executed on the master to
   call states on minions via salt-run state.sls.

   Salt Thin
   Salt Thin is an exciting new component of Salt, this is the ability  to
   execute Salt routines without any transport mechanisms installed, it is
   a pure python subset of Salt.

   Salt Thin does not have any networking capability, but can  be  dropped
   into  any system with Python installed and then salt-call can be called
   directly. The Salt Thin system, is used by the  salt-ssh  command,  but
   can still be used to just drop salt somewhere for easy use.

   Event Namespacing
   Events  have  been updated to be much more flexible. The tags in events
   have all been namespaced allowing easier tracking of event names.

   Mercurial Fileserver Backend
   The popular git fileserver backend has been  joined  by  the  mercurial
   fileserver  backend, allowing the state tree to be managed entirely via
   mercurial.

   External Logging Handlers
   The external logging handler system allows for Salt  to  directly  hook
   into  any  external  logging system. Currently supported are sentry and
   logstash.

   Jenkins Testing
   The testing systems in Salt have been greatly enhanced, tests for  salt
   are  now  executed,  via  jenkins.saltstack.com,  across many supported
   platforms. Jenkins calls out to salt-cloud to create  virtual  machines
   on  Rackspace,  then  the minion on the virtual machine checks into the
   master running on Jenkins where a state run is executed  that  sets  up
   the minion to run tests and executes the test suite.

   This  now  automates  the sequence of running platform tests and allows
   for continuous destructive tests to be run.

   Salt Testing Project
   The testing libraries for salt have been moved out  of  the  main  salt
   code  base  and  into a standalone codebase. This has been done to ease
   the use of the testing systems being used in salt based projects  other
   than Salt itself.

   StormPath External Authentication
   The  external  auth  system  now supports the fantastic Stormpath cloud
   based authentication system.

   LXC Support
   Extensive additions have been added  to  Salt  for  LXC  support.  This
   included  the  backend  libs for managing LXC containers. Addition into
   the salt-virt system is still in the works.

   Mac OS X User/Group Support
   Salt is now able to manage users and groups on Minions running  Mac  OS
   X.  However, at this time user passwords cannot be managed.

   Django ORM External Pillar
   Pillar data can now be derived from Django managed databases.

   Fixes from RC to release
   * Multiple documentation fixes

   * Add multiple source files + templating for file.append (issue 6905)

   * Support sysctl configuration files in systemd>=207 (issue 7351)

   * Add file.search and file.replace

   * Fix cross-calling execution functions in provider overrides

   * Fix locale override for postgres (issue 4543)

   * Fix Raspbian identification for service/pkg support (issue 7371)

   * Fix cp.push file corruption (issue 6495)

   * Fix ALT Linux password hash specification (issue 3474)

   * Multiple salt-ssh-related fixes and improvements

   Salt 0.17.1 Release Notes
   release
          2013-10-17

   NOTE:
      THIS  RELEASE  IS  NOT  COMPATIBLE  WITH  PREVIOUS VERSIONS.  If you
      update your master to 0.17.1, you must update your minions as  well.
      Sorry  for  the  inconvenience  --  this  is  a result of one of the
      security fixes listed below.

   The 0.17.1 release comes with a number  of  improvements  to  salt-ssh,
   many bugfixes, and a number of security updates.

   Salt  SSH  has  been  improved  to  be faster, more featureful and more
   secure.  Since the original release of Salt SSH was primarily  a  proof
   of  concept,  it  has  been very exciting to see its rapid adoption. We
   appreciate the willingness of security experts to review Salt  SSH  and
   help discover oversights and ensure that security issues only exist for
   such a tiny window of time.

   SSH Enhancements
   Shell Improvements
   Improvements to Salt SSH's communication have been added  that  improve
   routine execution regardless of the target system's login shell.

   Performance
   Deployment  of  routines  is  now  faster  and  takes fewer commands to
   execute.

   Security Updates
   Be advised that these security issues all apply to a  small  subset  of
   Salt users and mostly apply to Salt SSH.

   Insufficient Argument Validation
   This  issue  allowed  for  a  user  with  limited  privileges  to embed
   executions inside of  routines  to  execute  routines  that  should  be
   restricted. This applies to users using external auth or client ACL and
   opening up specific routines.

   Be advised that these patches  address  the  direct  issue.  Additional
   commits have been applied to help mitigate this issue from resurfacing.

   CVE
   CVE-2013-4435

   Affected Versions
   0.15.0 - 0.17.0

   Patches
   https://github.com/saltstack/salt/commit/6d8ef68b605fd63c36bb8ed96122a75ad2e80269
   https://github.com/saltstack/salt/commit/ebdef37b7e5d2b95a01d34b211c61c61da67e46a
   https://github.com/saltstack/salt/commit/7f190ff890e47cdd591d9d7cefa5126574660824
   https://github.com/saltstack/salt/commit/8e5afe59cef6743fe5dbd510dcf463dbdfca1ced
   https://github.com/saltstack/salt/commit/aca78f314481082862e96d4f0c1b75fa382bb885
   https://github.com/saltstack/salt/commit/6a9752cdb1e8df2c9505ea910434c79d132eb1e2
   https://github.com/saltstack/salt/commit/b73677435ba54ecfc93c1c2d840a7f9ba6f53410
   https://github.com/saltstack/salt/commit/07972eb0a6f985749a55d8d4a2e471596591c80d
   https://github.com/saltstack/salt/commit/1e3f197726aa13ac5c3f2416000089f477f489b5

   Found By
   Feth Arezki, of Majerti

   MITM SSH attack in salt-ssh
   SSH host keys were being accepted by default and not enforced on future
   SSH connections. These patches set SSH host key checking by default and
   can be overridden by passing the -i flag to salt-ssh.

   CVE
   CVE-2013-4436

   Affected Versions
   0.17.0

   Found By
   Michael Scherer, Red Hat

   Insecure Usage of /tmp in salt-ssh
   The initial release of salt-ssh used the /tmp directory in an  insecure
   way.   These  patches  not  only  secure  usage  of files under /tmp in
   salt-ssh, but also add checksum validation for all packages  sent  into
   the now secure locations on target systems.

   CVE
   CVE-2013-4438

   Affected Versions
   0.17.0

   Patches
   https://github.com/saltstack/salt/commit/aa4bb77ef230758cad84381dde0ec660d2dc340a
   https://github.com/saltstack/salt/commit/8f92b6b2cb2e4ec3af8783eb6bf4ff06f5a352cf
   https://github.com/saltstack/salt/commit/c58e56811d5a50c908df0597a0ba0b643b45ebfd
   https://github.com/saltstack/salt/commit/0359db9b46e47614cff35a66ea6a6a76846885d2
   https://github.com/saltstack/salt/commit/4348392860e0fd43701c331ac3e681cf1a8c17b0
   https://github.com/saltstack/salt/commit/664d1a1cac05602fad2693f6f97092d98a72bf61
   https://github.com/saltstack/salt/commit/bab92775a576e28ff9db262f32db9cf2375bba87
   https://github.com/saltstack/salt/commit/c6d34f1acf64900a3c87a2d37618ff414e5a704e

   Found By
   Michael Scherer, Red Hat

   YAML Calling Unsafe Loading Routine
   It has been argued that this is not a valid security issue, as the YAML
   loading that was happening was  only  being  called  after  an  initial
   gateway  filter  in  Salt  has already safely loaded the YAML and would
   fail if non-safe routines were embedded. Nonetheless, the CVE was filed
   and patches applied.

   CVE
   CVE-2013-4438

   Patches
   https://github.com/saltstack/salt/commit/339b0a51befae6b6b218ebcb55daa9cd3329a1c5

   Found By
   Michael Scherer, Red Hat

   Failure to Drop Supplementary Group on Salt Master
   If a salt master was started as a  non-root  user  by  the  root  user,
   root's  groups  would still be applied to the running process. This fix
   changes the process to have only the groups of the running user.

   CVE
   CVE not considered necessary by submitter.

   Affected Versions
   0.11.0 - 0.17.0

   Patches
   https://github.com/saltstack/salt/commit/b89fa9135822d029795ab1eecd68cce2d1ced715

   Found By
   Michael Scherer, Red Hat

   Failure to Validate Minions Posting Data
   This  issue  allowed a minion to pose as another authorized minion when
   posting data such as the mine data. All minions now pass through the id
   challenge before posting such data.

   CVE
   CVE-2013-4439

   Affected Versions
   0.15.0 - 0.17.0

   Patches
   https://github.com/saltstack/salt/commit/7b850ff3d07ef6782888914ac4556c01e8a1c482
   https://github.com/saltstack/salt/commit/151759b2a1e1c6ce29277aa81b054219147f80fd

   Found By
   David Anderson

   Fix Reference
   Version  0.17.1  is  the  first bugfix release for 0.17.0.  The changes
   include:

   * Fix symbolic links in thin.tgz (issue 7482)

   * Pass env through to file.patch state (issue 7452)

   * Service provider fixes and reporting improvements (issue 7361)

   * Add --priv option for specifying salt-ssh private key

   * Fix salt-thin's salt-call on setuptools installations (issue 7516)

   * Fix salt-ssh to support passwords with spaces (issue 7480)

   * Fix regression in wildcard includes (issue 7455)

   * Fix salt-call outputter regression (issue 7456)

   * Fix custom returner support for startup states (issue 7540)

   * Fix value handling in augeas (issue 7605)

   * Fix regression in apt (issue 7624)

   * Fix minion ID guessing to use socket.getfqdn() first (issue 7558)

   * Add minion ID caching (issue 7558)

   * Fix salt-key race condition (issue 7304)

   * Add --include-all flag to salt-key (issue 7399)

   * Fix custom grains in pillar (part of issue 5716, issue 6083)

   * Fix race condition in salt-key (issue 7304)

   * Fix regression in minion ID guessing, prioritize socket.getfqdn()  (
     issue 7558)

   * Cache minion ID on first guess (issue 7558)

   * Allow trailing slash in file.directory state

   * Fix  reporting  of  file_roots in pillar return (issue 5449 and issue
     5951)

   * Remove pillar matching for mine.get (issue 7197)

   * Sanitize args for multiple execution modules

   * Fix yumpkg mod_repo functions to filter hidden args (issue 7656)

   * Fix conflicting IDs in state includes (issue 7526)

   * Fix mysql_grants.absent string formatting issue (issue 7827)

   * Fix postgres.version so it won't return None (issue 7695)

   * Fix for trailing slashes in mount.mounted state

   * Fix rogue AttributErrors in the outputter system (issue 7845)

   * Fix for incorrect ssh key encodings resulting in incorrect key  added
     (issue 7718)

   * Fix  for  pillar/grains  naming  regression in python renderer (issue
     7693)

   * Fix args/kwargs handling in the scheduler (issue 7422)

   * Fix logfile handling for file://, tcp://, and udp:// (issue 7754)

   * Fix error handling in config file parsing (issue 6714)

   * Fix RVM using sudo when running as non-root user (issue 2193)

   * Fix client ACL and underlying logging bugs (issue 7706)

   * Fix scheduler bug with returner (issue 7367)

   * Fix user management bug related to default groups (issue 7690)

   * Fix various salt-ssh bugs (issue 7528)

   * Many various documentation fixes

   Salt 0.17.2 Release Notes
   release
          2013-11-14

   Version 0.17.2 is another  bugfix  release  for  0.17.0.   The  changes
   include:

   * Add ability to delete key with grains.delval (issue 7872)

   * Fix possible state compiler stack trace (issue 5767)

   * Fix architecture regression in yumpkg (issue 7813)

   * Use correct ps on Debian to prevent truncating (issue 5646)

   * Fix grains targeting for new grains (issue 5737)

   * Fix bug with merging in git_pillar (issue 6992)

   * Fix print_jobs duplicate results

   * Fix apt version specification for pkg.install

   * Fix possible KeyError from ext_job_cache missing option

   * Fix auto_order for - names states (issue 7649)

   * Fix regression in new gitfs installs (directory not found error)

   * Fix escape pipe issue on Windows for file.recurse (issue 7967)

   * Fix fileclient in case of master restart (issue 7987)

   * Try to output warning if CLI command malformed (issue 6538)

   * Fix --out=quiet to actually be quiet (issue 8000)

   * Fix for state.sls in salt-ssh (issue 7991)

   * Fix for MySQL grants ordering issue (issue 5817)

   * Fix traceback for certain missing CLI args (issue 8016)

   * Add ability to disable lspci queries on master (issue 4906)

   * Fail if sls defined in topfile does not exist (issue 5998)

   * Add ability to downgrade MySQL grants (issue 6606)

   * Fix ssh_auth.absent traceback (issue 8043)

   * Add upstart detection for Debian/Raspbian (issue 8039)

   * Fix ID-related issues (issue 8052, issue 8050, and others)

   * Fix for jinja rendering issues (issue 8066 and issue 8079)

   * Fix argument parsing in salt-ssh (issue 7928)

   * Fix some GPU detection instances (issue 6945)

   * Fix bug preventing includes from other environments in SLS files

   * Fix for kwargs with dashes (issue 8102)

   * Fix salt.utils.which for windows '.exe' (issue 7904)

   * Fix apache.adduser without apachectl (issue 8123)

   * Fix issue with evaluating test kwarg in states (issue 7788)

   * Fix regression in salt.client.Caller() (issue 8078)

   * Fix apt-key silent failure

   * Fix  bug  where cmd.script would try to run even if caching failed (
     issue 7601)

   * Fix apt pkg.latest regression (issue 8067)

   * Fix for mine data not being updated (issue 8144)

   * Fix for noarch packages in yum

   * Fix a Xen detection edge case (issue 7839)

   * Fix windows __opts__ dictionary persistence (issue 7714)

   * Fix version generation for when it's part of another git repo  (issue
     8090)

   * Fix  _handle_iorder stacktrace so that the real syntax error is shown
     (issue 8114 and issue 7905)

   * Fix git.latest state when a commit SHA is used (issue 8163)

   * Fix various small bugs in yumpkg.py (issue 8201)

   * Fix for specifying identify file in git.latest (issue 8094)

   * Fix for --output-file CLI arg (issue 8205)

   * Add ability to specify shutdown time for system.shutdown (issue 7833)

   * Fix for salt version using non-salt git repo info (issue 8266)

   * Add additional hints at impact of pkgrepo states  when  test=True  (
     issue 8247)

   * Fix for salt-ssh files not being owned by root (issue 8216)

   * Fix  retry  logic  and error handling in fileserver (related to issue
     7755)

   * Fix file.replace with test=True (issue 8279)

   * Add flag for limiting file traversal in fileserver (issue 6928)

   * Fix for extra mine processes (issue 5729)

   * Fix for unloading custom modules (issue 7691)

   * Fix for salt-ssh opts (issue 8005 and issue 8271)

   * Fix compound matcher for grains (issue 7944)

   * Improve error reporting in ebuild module (related to issue 5393)

   * Add dir_mode to file.managed (issue 7860)

   * Improve traceroute support for FreeBSD and OS X (issue 4927)

   * Fix for matching minions under syndics (issue 7671)

   * Improve exception handling for missing ID (issue 8259)

   * Fix grain mismatch for ScientificLinux (issue 8338)

   * Add configuration option for minion_id_caching

   * Fix open mode auth errors (issue 8402)

   Salt 0.17.3 Release Notes
   release
          2013-12-08

   NOTE:
      0.17.3 had some regressions which were promptly fixed in the  0.17.4
      release.  Please use 0.17.4 instead.

   Version  0.17.3  is  another  bugfix  release  for 0.17.0.  The changes
   include:

   * Fix some jinja render errors (issue 8418)

   * Fix file.replace state changing file ownership (issue 8399)

   * Fix state ordering with the PyDSL renderer (issue 8446)

   * Fix for new npm version (issue 8517)

   * Fix for pip state requiring name even with requirements  file  (issue
     8519)

   * Fix yum logging to open terminals (issue 3855)

   * Add sane maxrunning defaults for scheduler (issue 8563)

   * Fix states duplicate key detection (issue 8053)

   * Fix SUSE patch level reporting (issue 8428)

   * Fix managed file creation umask (issue 8590)

   * Fix logstash exception (issue 8635)

   * Improve argument exception handling for salt command (issue 8016)

   * Fix pecl success reporting (issue 8750)

   * Fix launchctl module exceptions (issue 8759)

   * Fix argument order in pw_user module

   * Add warnings for failing grains (issue 8690)

   * Fix  hgfs  problems  caused  by connections left open (issue 8811 and
     issue 8810)

   * Add Debian iptables default for  iptables-persistent  package  (issue
     8889)

   * Fix installation of packages with dots in pkg name (issue 8614)

   * Fix noarch package installation on CentOS 6 (issue 8945)

   * Fix portage_config.enforce_nice_config (issue 8252)

   * Fix salt.util.copyfile umask usage (issue 8590)

   * Fix rescheduling of failed jobs (issue 8941)

   * Fix pkg on Amazon Linux (uses yumpkg5 now) (issue 8226)

   * Fix conflicting options in postgres module (issue 8717)

   * Fix ps modules for psutil >= 0.3.0 (issue 7432)

   * Fix postgres module to return False on failure (issue 8778)

   * Fix argument passing for args with pound signs (issue 8585)

   * Fix pid of salt CLi command showing in status.pid output (issue 8720)

   * Fix rvm to run gem as the correct user (issue 8951)

   * Fix namespace issue in win_file module (issue 9060)

   * Fix masterless state paths on windows (issue 9021)

   * Fix timeout option in master config (issue 9040)

   Salt 0.17.4 Release Notes
   release
          2013-12-10

   Version  0.17.4  is  another  bugfix  release  for 0.17.0.  The changes
   include:

   * Fix file.replace bug when replacement str is numeric (issue 9101)

   * Fix regression in file.managed (issue 9131)

   * Prevent traceback when job is None. (issue 9145)

   Salt 0.17.5 Release Notes
   release
          2014-01-27

   Version 0.17.5 is another  bugfix  release  for  0.17.0.   The  changes
   include:

   * Fix user.present states with non-string fullname (issue 9085)

   * Fix virt.init return value on failure (issue 6870)

   * Fix reporting of file.blockreplace state when test=True

   * Fix network.interfaces when used in cron (issue 7990)

   * Fix  bug  in pkgrepo when switching to/from mirrorlist-based repo def
     (issue 9121)

   * Fix infinite recursion when cache file is corrupted

   * Add checking for rev and mirror/bare args in git.latest (issue 9107)

   * Add cmd.watch alias (points to cmd.wait) (issue 8612)

   * Fix stacktrace when prereq is not formed as a list (issue 8235)

   * Fix stdin issue with lvdisplay command (issue 9128)

   * Add pre-check function for range matcher (issue 9236)

   * Add exception handling for psutil for processes that  go  missing  (
     issue 9274)

   * Allow _in requisites to match both on ID and name (issue 9061)

   * Fix  multiple  client  timeout  issues  (issue  7157  and issue 9302,
     probably others)

   * Fix ZMQError: Operation  cannot  be  accomplished  in  current  state
     errors (issue 6306)

   * Multiple optimization in minion auth routines

   * Clarify logs for minion ID caching

   Salt 0.6.0 release notes
   The  Salt  remote  execution manager has reached initial functionality!
   Salt is a management application which can be used to execute  commands
   on remote sets of servers.

   The  whole  idea  behind  Salt  is  to create a system where a group of
   servers can be remotely controlled from a single master, not  only  can
   commands  be  executed  on remote systems, but salt can also be used to
   gather information about your server environment.

   Unlike similar systems, like Func and MCollective,  Salt  is  extremely
   simple  to  setup  and  use,  the  entire application is contained in a
   single package, and the master and minion daemons  require  no  running
   dependencies  in  the way that Func requires Certmaster and MCollective
   requires activeMQ.

   Salt also manages authentication and encryption. Rather than using  SSL
   for encryption, salt manages encryption on a payload level, so the data
   sent across the network is encrypted  with  fast  AES  encryption,  and
   authentication uses RSA keys. This means that Salt is fast, secure, and
   very efficient.

   Messaging in Salt is executed  with  ZeroMQ,  so  the  message  passing
   interface  is  built  into salt and does not require an external ZeroMQ
   server. This also adds speed to Salt since there is no additional bloat
   on the networking layer, and ZeroMQ has already proven itself as a very
   fast networking system.

   The remote execution in Salt is "Lazy  Execution",  in  that  once  the
   command is sent the requesting network connection is closed. This makes
   it easier to detach the execution  from  the  calling  process  on  the
   master,  it  also  means  that  replies are cached, so that information
   gathered from historic commands can be queried in the future.

   Salt also allows users to make execution modules in Python. Writers  of
   these  modules  should also be pleased to know that they have access to
   the   impressive   information   gathered   from   PuppetLabs'   Facter
   application,  making Salt module more flexible. In the future I hope to
   also allow Salt to group servers based on Facter information as well.

   All in all Salt is fast, efficient, and  clean,  can  be  used  from  a
   simple  command  line  client  or  through  an  API, uses message queue
   technology to make network execution extremely fast, and encryption  is
   handled  in a very fast and efficient manner. Salt is also VERY easy to
   use and VERY easy to extend.

   You can find the source code for Salt on my GitHub page,  I  have  also
   set  up  a few wiki pages explaining how to use and set up Salt. If you
   are using Arch Linux there is a package available  in  the  Arch  Linux
   AUR.

   Salt                            0.6.0                           Source:
   https://cloud.github.com/downloads/saltstack/salt/salt-0.6.0.tar.gz

   GitHub page: https://github.com/saltstack/salt

   Wiki: https://github.com/saltstack/salt/wiki

   Arch Linux Package: https://aur.archlinux.org/packages/salt-git/

   I am very open to contributions, for instance I need packages for  more
   Linux distributions as well as BSD packages and testers.

   Give  Salt  a try, this is the initial release and is not a 1.0 quality
   release, but it has been working well for me! I am eager  to  get  your
   feedback!

   Salt 0.7.0 release notes
   I am pleased to announce the release of Salt 0.7.0!

   This  release  marks  what  is  the first stable release of salt, 0.7.0
   should be suitable for general use.

   0.7.0 Brings the following new features to Salt:

   * Integration with Facter data from puppet labs

   * Allow  for  matching  minions  from  the  salt  client   via   Facter
     information

   * Minion  job  threading,  many jobs can be executed from the master at
     once

   * Preview of master clustering support - Still experimental

   * Introduce new  minion  modules  for  stats,  virtualization,  service
     management and more

   * Add extensive logging to the master and minion daemons

   * Add sys.reload_functions for dynamic function reloading

   * Greatly improve authentication

   * Introduce the saltkey command for managing public keys

   * Begin backend development preparatory to introducing butter

   * Addition of man pages for the core commands

   * Extended and cleaned configuration

   0.7.0 Fixes the following major bugs:

   * Fix crash in minions when matching failed

   * Fix configuration file lookups for the local client

   * Repair communication bugs in encryption

   * Numerous fixes in the minion modules

   The next release of Salt should see the following features:

   * Stabilize the cluster support

   * Introduce a remote client for salt command tiers

   * salt-ftp system for distributed file copies

   * Initial support for "butter"

   Coming  up  next is a higher level management framework for salt called
   Butter. I want salt to stay as a  simple  and  effective  communication
   framework,  and allow for more complicated executions to be managed via
   Butter.

   Right now Butter is being developed to act as a cloud controller  using
   salt  as  the  communication layer, but features like system monitoring
   and advanced configuration control (a puppet manager) are also  in  the
   pipe.

   Special  thanks  to Joseph Hall for the status and network modules, and
   thanks to Matthias Teege for tracking down some configuration bugs!

   Salt can be downloaded from the following locations;

   Source Tarball:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.7.0.tar.gz

   Arch Linux Package:

   https://aur.archlinux.org/packages/salt-git/

   Please enjoy the latest Salt release!

   Salt 0.8.0 release notes
   Salt 0.8.0 is ready for general consumption!   The  source  tarball  is
   available on GitHub for download:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.8.0.tar.gz

   A  lot  of  work has gone into salt since the last release just 2 weeks
   ago, and salt has improved a great deal. A swath of  new  features  are
   here along with performance and threading improvements!

   The main new features of salt 0.8.0 are:

   Salt-cp

   Cython minion modules

   Dynamic returners

   Faster return handling

   Lowered required Python version to 2.6

   Advanced minion threading

   Configurable minion modules

   Salt-cp
   The  salt-cp  command  introduces  the ability to copy simple files via
   salt to targeted servers. Using  salt-cp  is  very  simple,  just  call
   salt-cp  with  a  target specification, the source file(s) and where to
   copy the files on the minions.  For instance:

   # salt-cp '*' /etc/hosts /etc/hosts

   Will copy the local /etc/hosts file to all of the minions.

   Salt-cp is very young, in the future more  advanced  features  will  be
   added,  and  the  functionality  will much more closely resemble the cp
   command.

   Cython minion modules
   Cython is an amazing tool used to compile Python  modules  down  to  c.
   This  is  arguably  the fastest way to run Python code, and since pyzmq
   requires cython,  adding  support  to  salt  for  cython  adds  no  new
   dependencies.

   Cython  minion modules allow minion modules to be written in cython and
   therefore executed in compiled c.  Simply  write  the  salt  module  in
   cython  and use the file extension ".pyx" and the minion module will be
   compiled when the minion  is  started.  An  example  cython  module  is
   included in the main distribution called cytest.pyx:

   https://github.com/saltstack/salt/blob/develop/salt/modules/cytest.pyx

   Dynamic Returners
   By  default  salt returns command data back to the salt master, but now
   salt can return command data to any system. This is enabled via the new
   returners  modules  feature  for  salt.  The returners modules take the
   return data and sends it to a specific  module.  The  returner  modules
   work like minion modules, so any returner can be added to the minions.

   This  means that a custom data returner can be added to communicate the
   return data so anything from MySQL, Redis, MongoDB, and more!

   There are 2 simple stock returners in the returners directory:

   https://github.com/saltstack/salt/blob/develop/salt/returners

   The documentation on writing  returners  will  be  added  to  the  wiki
   shortly, and returners can be written in pure Python, or in cython.

   Configurable Minion Modules
   Minion modules may need to be configured, now the options passed to the
   minion configuration file can be accessed inside of the minion  modules
   via the __opt__ dict.

   Information  on  how  to use this simple addition has been added to the
   wiki: Writing modules

   The test module has an example of using the __opts__ dict, and  how  to
   set default options:

   https://github.com/saltstack/salt/blob/develop/salt/modules/test.py

   Advanced Minion Threading
   In  0.7.0  the  minion  would  block after receiving a command from the
   master, now the minion will spawn a thread or multiprocess. By  default
   Python  threads are used because for general use they have proved to be
   faster, but the  minion  can  now  be  configured  to  use  the  Python
   multiprocessing   module  instead.  Using  multiprocessing  will  cause
   executions that are CPU bound or would otherwise exploit  the  negative
   aspects  of  the Python GIL to run faster and more reliably, but simple
   calls will still be faster with Python  threading.   The  configuration
   option can be found in the minion configuration file:

   https://github.com/saltstack/salt/blob/develop/conf/minion

   Lowered Supported Python to 2.6
   The  requirement for Python 2.7 has been removed to support Python 2.6.
   I have received requests to take the minimum  Python  version  back  to
   2.4,  but  unfortunately  this  will  not be possible, since the ZeroMQ
   Python bindings do not support Python 2.4.

   Salt 0.8.0 is a very major update, it also changes the network protocol
   slightly  which makes communication with older salt daemons impossible,
   your master and minions need to be upgraded together!

   I could use some help bringing salt to the people!  Right  now  I  only
   have  packages  for  Arch Linux, Fedora 14 and Gentoo. We need packages
   for Debian and people willing to help test on more platforms.  We  also
   need help writing more minion modules and returner modules. If you want
   to contribute to salt please hop  on  the  mailing  list  and  send  in
   patches,  make  a fork on GitHub and send in pull requests! If you want
   to help but are not sure where you can, please  email  me  directly  or
   post tot he mailing list!

   I  hope  you  enjoy  salt,  while  it is not yet 1.0 salt is completely
   viable and usable!

   -Thomas S. Hatch

   Salt 0.8.7 release notes
   It has been a month since salt 0.8.0, and it has been a long month! But
   Salt is still coming along strong. 0.8.7 has a lot of changes and a lot
   of updates.  This update makes Salt's ZeroMQ back  end  better,  strips
   Facter  from the dependencies, and introduces interfaces to handle more
   capabilities.

   Many of the major updates are in the background, but the changes should
   shine  through to the surface. A number of the new features are still a
   little thin, but the back end to support expansion is in place.

   I also recently gave a presentation to the Utah Python users  group  in
   Salt  Lake  City, the slides from this presentation are available here:
   https://cloud.github.com/downloads/saltstack/salt/Salt.pdf

   The video from this presentation will be available shortly.

   The major new features and changes in Salt 0.8.7 are:

   * Revamp ZeroMQ topology on the master for better scalability

   * State enforcement

   * Dynamic state enforcement managers

   * Extract the module loader into salt.loader

   * Make Job ids more granular

   * Replace Facter functionality with the new salt grains interface

   * Support for "virtual" salt modules

   * Introduce the salt-call command

   * Better debugging for minion modules

   The new ZeroMQ topology allows for better  scalability,  this  will  be
   required  by  the  need  to  execute massive file transfers to multiple
   machines in parallel and state management. The new ZeroMQ  topology  is
   available in the aforementioned presentation.

   0.8.7  introduces  the capability to declare states, this is similar to
   the capabilities of Puppet. States in salt are declared via state  data
   structures.   This  system  is  very young, but the core feature set is
   available. Salt states work around rendering files which represent Salt
   high data. More on the Salt state system will be documented in the near
   future.

   The system for loading salt modules has been pulled out of  the  minion
   class  to be a standalone module, this has enabled more dynamic loading
   of Salt modules and enables many of the updates in 0.8.7 --

   https://github.com/saltstack/salt/blob/develop/salt/loader.py

   Salt Job ids are now microsecond precise, this was needed to  repair  a
   race  condition  unveiled  by  the speed improvements in the new ZeroMQ
   topology.

   The new grains interface replaces the functionality of Facter, the idea
   behind  grains differs from Facter in that the grains are only used for
   static system data, dynamic data needs to be derived from a call  to  a
   salt  module.  This  makes  grains much faster to use, since the grains
   data is generated when the minion starts.

   Virtual salt modules allows for  a  salt  module  to  be  presented  as
   something  other  than  its module name. The idea here is that based on
   information from the minion decisions  about  which  module  should  be
   presented  can  be  made.  The  best  example is the pacman module. The
   pacman module will only load on Arch Linux minions, and will be  called
   pkg.  Similarly the yum module will be presented as pkg when the minion
   starts on a Fedora/RedHat system.

   The new salt-call command allows for minion modules to be executed from
   the  minion.  This  means  that  on  the  minion  a  salt module can be
   executed, this is a great tool for testing Salt modules. The  salt-call
   command can also be used to view the grains data.

   In  previous  releases  when  a  minion  module threw an exception very
   little data was returned to the master. Now the stack  trace  from  the
   failure is returned making debugging of minion modules MUCH easier.

   Salt  is  nearing  the  goal  of  1.0,  where  the core feature set and
   capability is complete!

   Salt    0.8.7    can    be     downloaded     from     GitHub     here:
   https://cloud.github.com/downloads/saltstack/salt/salt-0.8.7.tar.gz

   -Thomas S Hatch

   Salt 0.8.8 release notes
   Salt  0.8.8  is  here!  This release adds a great deal of code and some
   serious new features.  The  latest  release  can  be  downloaded  here:
   https://cloud.github.com/downloads/saltstack/salt/salt-0.8.8.tar.gz

   Improved  Documentation has been set up for salt using sphinx thanks to
   the efforts of Seth House. This new documentation system  will  act  as
   the   back  end  to  the  salt  website  which  is  still  under  heavy
   development. The new sphinx documentation system has also been used  to
   greatly  clean  up the salt manpages.  The salt 7 manpage in particular
   now contains extensive information which was  previously  only  in  the
   wiki. The new documentation can be found at: http://docs.saltstack.com/
   We still have a lot to add, and when the domain is set up I  will  post
   another announcement.

   More  additions have been made to the ZeroMQ setup, particularly in the
   realm of file transfers. Salt 0.8.8 introduces a built  in,  stateless,
   encrypted  file server which allows salt minions to download files from
   the salt master using the same encryption system  used  for  all  other
   salt  communications.  The main motivation for the salt file server has
   been to facilitate the new salt state system.

   Much of the salt code has been cleaned up and  a  new  cleaner  logging
   system  has  been  introduced  thanks to the efforts of Pedro Algarvio.
   These additions will  allow  for  much  more  flexible  logging  to  be
   executed  by  salt,  and  fixed a great deal of my poor spelling in the
   salt docstrings! Pedro Algarvio has also cleaned up the API, making  it
   easier to embed salt into another application.

   The  biggest  addition  to salt found in 0.8.8 is the new state system.
   The salt module system has received a new front end which  allows  salt
   to  be  used  as  a  configuration management system. The configuration
   management system allows for system configuration to be defined in data
   structures.  The configuration management system, or as it is called in
   salt, the "salt state system" supports many of the  features  found  in
   other  configuration  managers,  but  allows  for  system  states to be
   written in a far  simpler  format,  executes  at  blazing  speeds,  and
   operates  via  the  salt  minion matching system. The state system also
   operates within the normal scope of salt, and  requires  no  additional
   configuration to use.

   The  salt  state system can enforce the following states with many more
   to come: Packages Files Services Executing commands Hosts

   The system used to define the salt states is based on a data structure,
   the  data  structure used to define the salt states has been made to be
   as easy to use as possible. The data structure is  defined  by  default
   using  a  YAML  file rendered via a Jinja template. This means that the
   state definition language supports all of the data structures that YAML
   supports,  and  all  of the programming constructs and logic that Jinja
   supports. If the user does not like YAML or Jinja  the  states  can  be
   defined  in  yaml-mako,  json-jinja,  or  json-mako. The system used to
   render the states is completely dynamic, and any rendering  system  can
   be  added  to  the  capabilities  of  Salt, this means that a rendering
   system that renders XML data in a cheetah template, or whatever you can
   imagine, can be easily added to the capabilities of salt.

   The  salt  state system also supports isolated environments, as well as
   matching code from several environments to a single salt minion.

   The feature base for Salt has grown quite a bit since my  last  serious
   documentation  push.  As  we approach 0.9.0 the goals are becoming very
   clear, and the documentation needs a lot of work. The  main  goals  for
   0.9.0 are to further refine the state system, fix any bugs we find, get
   Salt running on as many platforms as we can, and get the  documentation
   filled  out.  There  is  a  lot  more  to come as Salt moves forward to
   encapsulate a much larger scope, while  maintaining  supreme  usability
   and simplicity.

   If  you  would  like  a more complete overview of Salt please watch the
   Salt                       presentation:                        Slides:
   https://cloud.github.com/downloads/saltstack/salt/Salt.pdf

   -Thomas S Hatch

   Salt 0.8.9 Release Notes
   Salt 0.8.9 has finally arrived! Unfortunately this is much later than I
   had hoped to release 0.8.9, life has been  very  crazy  over  the  last
   month. But despite challenges, Salt has moved forward!

   This  release, as expected, adds few new features and many refinements.
   One of the most exciting aspect of this release is that the development
   community  for salt has grown a great deal and much of the code is from
   contributors.

   Also, I have filled out the documentation a great deal. So  information
   on  States  is  properly documented, and much of the documentation that
   was out of date has been filled in.

   Download!
   The Salt source can be downloaded from the salt GitHub site:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.8.9.tar.gz

   Or from PyPI:

   https://pypi.python.org/packages/source/s/salt/salt-0.8.9.tar.gz

   Here s the md5sum:

   7d5aca4633bc22f59045f59e82f43b56

   For instructions on how to set up  Salt  please  see  the  installation
   instructions.

   New Features
   Salt Run
   A  big feature is the addition of Salt run, the salt-run command allows
   for master side execution modules  to  be  made  that  gather  specific
   information or execute custom routines from the master.

   Documentation for salt-run can be found here

   Refined Outputters
   One problem often complained about in salt was the fact that the output
   was so messy. Thanks to help from Jeff Schroeder  a  cleaner  interface
   for  the  command  output  for  the  Salt  CLI  has been made. This new
   interface makes adding new printout formats easy and additions  to  the
   capabilities  of  minion  modules makes it possible to set the printout
   mode or outputter for functions in minion modules.

   Cross Calling Salt Modules
   Salt modules can now call each other, the __salt__ dict has been  added
   to  the  predefined  references  in minion modules. This new feature is
   documented in the modules documentation.

   Watch Option Added to Salt State System
   Now in Salt states you can set the watch option, this will allow  watch
   enabled states to change based on a change in the other defined states.
   This is similar to subscribe and notify statements in puppet.

   Root Dir Option
   Travis Cline has added the ability to define the option root_dir  which
   allows the salt minion to operate in a subdir. This is a strong move in
   supporting the minion running as an unprivileged user

   Config Files Defined in Variables
   Thanks again to Travis Cline, the master and minion configuration  file
   locations can be defined in environment variables now.

   New Modules
   Quite a few new modules, states, returners, and runners have been made.

   New Minion Modules
   apt
   Support  for  apt-get has been added, this adds greatly improved Debian
   and Ubuntu support to Salt!

   useradd and groupadd
   Support for manipulating users and groups on Unix-like systems.

   moosefs
   Initial support for  reporting  on  aspects  of  the  distributed  file
   system,   MooseFS.   For   more  information  on  MooseFS  please  see:
   http://www.moosefs.org

   Thanks to Joseph Hall for his work on MooseFS support.

   mount
   Manage mounts and the fstab.

   puppet
   Execute puppet on remote systems.

   shadow
   Manipulate and manage the user password file.

   ssh
   Interact with ssh keys.

   New States
   user and group
   Support for managing users and groups in Salt States.

   mount
   Enforce mounts and the fstab.

   New Returners
   mongo_return
   Send the return information to a MongoDB server.

   New Runners
   manage
   Display minions that are up or down.

   Salt 0.9.0 Release Notes
   release
          2011-08-27

   Salt 0.9.0 is here. This is an exciting release, 0.9.0 includes the new
   network  topology  features  allowing peer salt commands and masters of
   masters via the syndic interface.

   0.9.0 also introduces many more modules, improvements to  the  API  and
   improvements to the ZeroMQ systems.

   Download!
   The Salt source can be downloaded from the salt GitHub site:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.9.0.tar.gz

   Or from PyPI:

   https://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz

   Here is the md5sum:

   9a925da04981e65a0f237f2e77ddab37

   For  instructions  on  how  to  set up Salt please see the installation
   instructions.

   New Features
   Salt Syndic
   The new Syndic interface allows a master to be  commanded  via  another
   higher level salt master. This is a powerful solution allowing a master
   control structure to exist, allowing  salt  to  scale  to  much  larger
   levels then before.

   Peer Communication
   0.9.0  introduces  the capability for a minion to call a publication on
   the master and receive the return from another  set  of  minions.  This
   allows  salt to act as a communication channel between minions and as a
   general infrastructure message bus.

   Peer communication is turned off by default but can be enabled via  the
   peer  option in the master configuration file. Documentation on the new
   Peer interface.

   Easily Extensible API
   The minion and  master  classes  have  been  redesigned  to  allow  for
   specialized  minion and master servers to be easily created. An example
   on how this is done for the master can be found in the  master.py  salt
   module:

   https://github.com/saltstack/salt/blob/develop/salt/master.py

   The  Master  class extends the SMaster class and set up the main master
   server.

   The  minion  functions  can  now  also  be  easily  added  to   another
   application  via  the  SMinion  class,  this  class can be found in the
   minion.py module:

   https://github.com/saltstack/salt/blob/develop/salt/minion.py

   Cleaner Key Management
   This release changes some of the  key  naming  to  allow  for  multiple
   master keys to be held based on the type of minion gathering the master
   key.

   The -d option has also been added to the salt-key command allowing  for
   easy removal of accepted public keys.

   The  --gen-keys  option  is  now  available  as well for salt-key, this
   allows for a salt specific RSA key pair to be easily generated from the
   command line.

   Improved 0MQ Master Workers
   The  0MQ  worker  system has been further refined to be faster and more
   robust.  This new system has been able to handle  a  much  larger  load
   than  the  previous  setup. The new system uses the IPC protocol in 0MQ
   instead of TCP.

   New Modules
   Quite a few new modules have been made.

   New Minion Modules
   apache
   Work directly with apache servers,  great  for  managing  balanced  web
   servers

   cron
   Read out the contents of a systems crontabs

   mdadm
   Module to manage raid devices in Linux, appears as the raid module

   mysql
   Gather simple data from MySQL databases

   ps
   Extensive utilities for managing processes

   publish
   Used by the peer interface to allow minions to make publications

   Salt 0.9.1 Release Notes
   release
          2011-08-29

   Salt 0.9.2 Release Notes
   release
          2011-09-17

   Salt  0.9.2  has  arrived!  0.9.2  is  primarily  a bugfix release, the
   exciting component in  0.9.2  is  greatly  improved  support  for  salt
   states.  All  of  the  salt states interfaces have been more thoroughly
   tested and the new salt-states git repo is growing with example of  how
   to use states.

   This release introduces salt states for early developers and testers to
   start helping us clean up the states interface and make  it  ready  for
   the world!

   0.9.2 also fixes a number of bugs found on Python 2.6.

   Download!
   The Salt source can be downloaded from the salt GitHub site:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.9.2.tar.gz

   Or from PyPI:

   https://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz

   For  instructions  on  how  to  set up Salt please see the installation
   instructions.

   New Features
   Salt-Call Additions
   The salt-call command has received an overhaul, it now hooks  into  the
   outputter  system so command output looks clean, and the logging system
   has been hooked into salt-call, so the -l  option  allows  the  logging
   output from salt minion functions to be displayed.

   The  end  result  is  that  the salt-call command can execute the state
   system and return clean output:

      # salt-call state.highstate

   State System Fixes
   The state system has been tested and better refined. As of this release
   the  state  system is ready for early testers to start playing with. If
   you are interested in working with the state system  please  check  out
   the (still very small) salt-states GitHub repo:

   https://github.com/saltstack/salt-states

   This  git  repo  is the active development branch for determining how a
   clean salt-state database should look and act.  Since  the  salt  state
   system  is  still very young a lot of help is still needed here. Please
   fork the salt-states repo  and  help  us  develop  a  truly  large  and
   scalable system for configuration management!

   Notable Bug Fixes
   Python 2.6 String Formatting
   Python 2.6 does not support format strings without an index identifier,
   all of them have been repaired.

   Cython Loading Disabled by Default
   Cython loading requires a development tool chain to be installed on the
   minion,  requiring  this  by  default  can cause problems for most Salt
   deployments. If Cython auto loading is  desired  it  will  need  to  be
   turned on in the minion config.

   Salt 0.9.3 Release Notes
   release
          2011-11-05

   Salt  0.9.3  is  finally  arrived. This is another big step forward for
   Salt, new features range from proper FreeBSD support to  fixing  issues
   seen when attaching a minion to a master over the Internet.

   The  biggest  improvements  in  0.9.3  though can be found in the state
   system, it has progressed from something ready for early testers  to  a
   system  ready  to  compete  with platforms such as Puppet and Chef. The
   backbone of the state system has been  greatly  refined  and  many  new
   features are available.

   Download!
   The Salt source can be downloaded from the salt GitHub site:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.9.3.tar.gz

   Or from PyPI:

   https://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz

   For  instructions  on  how  to  set up Salt please see the installation
   instructions.

   New Features
   WAN Support
   Recently more people have been testing Salt minions connecting to  Salt
   Masters  over  the  Internet.  It was found that Minions would commonly
   loose their connection to the master when working  over  the  internet.
   The  minions  can  now  detect  if  the  connection  has  been lost and
   reconnect to the master, making WAN connections much more reliable.

   State System Fixes
   Substantial testing has gone into the state system and it is ready  for
   real  world usage. A great deal has been added to the documentation for
   states and the modules and functions  available  to  states  have  been
   cleanly documented.

   A  number  of State System bugs have also been founds and repaired, the
   output from the state system has also  been  refined  to  be  extremely
   clear and concise.

   Error  reporting  has  also  been introduced, issues found in sls files
   will now be clearly reported when executing Salt States.

   Extend Declaration
   The  Salt  States  have  also  gained  the  extend  declaration.   This
   declaration  allows  for  states  to  be  cleanly  modified  in  a post
   environment. Simply said, if there is an apache.sls file that  declares
   the apache service, then another sls can include apache and then extend
   it:

      include:
        - apache

      extend:
        apache:
          service:
            - require:
              - pkg: mod_python

      mod_python:
        pkg:
          - installed

   The notable behavior with the extend functionality is that it literally
   extends  or overwrites a declaration set up in another sls module. This
   means that Salt will behave  as  though  the  modifications  were  made
   directly  to  the  apache sls.  This ensures that the apache service in
   this example is directly tied to all requirements.

   Highstate Structure Specification
   This release comes with a clear specification  of  the  Highstate  data
   structure  that  is  used  to  declare  Salt States. This specification
   explains everything that can be declared in the Salt SLS modules.

   The specification is extremely simple, and  illustrates  how  Salt  has
   been  able  to  fulfill  the  requirements  of  a central configuration
   manager  within  a  simple  and   easy   to   understand   format   and
   specification.

   SheBang Renderer Switch
   It  came  to  our attention that having many renderers means that there
   may be a situation  where  more  than  one  State  Renderer  should  be
   available within a single State Tree.

   The  method chosen to accomplish this was something already familiar to
   developers and systems administrators,  a  SheBang.  The  Python  State
   Renderer displays this new capability.

   Python State Renderer
   Until  now  Salt  States  could  only be declared in yaml or json using
   Jinja or Mako. A new, very powerful, renderer has been added, making it
   possible to write Salt States in pure Python:

      #!py

      def run():
          '''
          Install the python-mako package
          '''
          return {'include': ['python'],
                  'python-mako': {'pkg': ['installed']}}

   This  renderer  is  used  by  making  a  run  function that returns the
   Highstate data structure. Any capabilities of Python  can  be  used  in
   pure Python sls modules.

   This example of a pure Python sls module is the same as this example in
   yaml:

      include:
        - python

      python-mako:
        pkg:
          - installed

   FreeBSD Support
   Additional support has been added for FreeBSD,  this  is  Salt's  first
   branch  out  of  the  Linux  world  and proves the viability of Salt on
   non-Linux platforms.

   Salt remote execution  already  worked  on  FreeBSD,  and  should  work
   without  issue on any Unix-like platform. But this support comes in the
   form of package management and user support, so Salt States  also  work
   on FreeBSD now.

   The  new  freebsdpkg  module  provides  package  management support for
   FreeBSD and the  new  pw_user  and  pw_group  provide  user  and  group
   management.

   Module and State Additions
   Cron Support
   Support  for  managing  the  system crontab has been added, declaring a
   cron state can be done easily:

      date > /tmp/datestamp:
        cron:
          - present
          - user: fred
          - minute: 5
          - hour: 3

   File State Additions
   The file state has been given a number of new features,  primarily  the
   directory, recurse, symlink, and absent functions.

   file.directory
          Make sure that a directory exists and has the right permissions.

             /srv/foo:
               file:
                 - directory
                 - user: root
                 - group: root
                 - mode: 1755

   file.symlink
          Make a symlink.

             /var/lib/www:
               file:
                 - symlink
                 - target: /srv/www
                 - force: True

   file.recurse
          The recurse state function will recursively download a directory
          on the master file server and place it on the minion. Any change
          in  the  files  on  the master will be pushed to the minion. The
          recurse function is very powerful and has been tested by pushing
          out the full Linux kernel source.

             /opt/code:
               file:
                 - recurse
                 - source: salt://linux

   file.absent
          Make  sure  that  the  file  is  not  on the system, recursively
          deletes directories, files, and symlinks.

             /etc/httpd/conf.d/somebogusfile.conf:
               file:
                 - absent

   Sysctl Module and State
   The sysctl module and state allows for sysctl components in the  kernel
   to  be  managed  easily.  the  sysctl  module  contains  the  following
   functions:

   sysctl.show
          Return a list of sysctl parameters for this minion

   sysctl.get
          Return a single sysctl parameter for this minion

   sysctl.assign
          Assign a single sysctl parameter for this minion

   sysctl.persist
          Assign and persist a simple sysctl parameter for this minion

   The sysctl state allows for sysctl parameters to be assigned:

      vm.swappiness:
        sysctl:
          - present
          - value: 20

   Kernel Module Management
   A module for managing Linux kernel modules  has  been  added.  The  new
   functions are as follows:

   kmod.available
          Return a list of all available kernel modules

   kmod.check_available
          Check to see if the specified kernel module is available

   kmod.lsmod
          Return  a  dict  containing  information  about currently loaded
          modules

   kmod.load
          Load the specified kernel module

   kmod.remove
          Unload the specified kernel module

   The kmod state can enforce modules be either present or absent:

      kvm_intel:
        kmod:
          - present

   Ssh Authorized Keys
   The ssh_auth state can distribute ssh authorized keys out  to  minions.
   Ssh authorized keys can be present or absent.

      AAAAB3NzaC1kc3MAAACBAL0sQ9fJ5bYTEyYvlRBsJdDOo49CNfhlWHWXQRqul6rwL4KIuPrhY7hBw0tV7UNC7J9IZRNO4iGod9C+OYutuWGJ2x5YNf7P4uGhH9AhBQGQ4LKOLxhDyT1OrDKXVFw3wgY3rHiJYAbd1PXNuclJHOKL27QZCRFjWSEaSrUOoczvAAAAFQD9d4jp2dCJSIseSkk4Lez3LqFcqQAAAIAmovHIVSrbLbXAXQE8eyPoL9x5C+x2GRpEcA7AeMH6bGx/xw6NtnQZVMcmZIre5Elrw3OKgxcDNomjYFNHuOYaQLBBMosyO++tJe1KTAr3A2zGj2xbWO9JhEzu8xvSdF8jRu0N5SRXPpzSyU4o1WGIPLVZSeSq1VFTHRT4lXB7PQAAAIBXUz6ZO0bregF5xtJRuxUN583HlfQkXvxLqHAGY8WSEVlTnuG/x75wolBDbVzeTlxWxgxhafj7P6Ncdv25Wz9wvc6ko/puww0b3rcLNqK+XCNJlsM/7lB8Q26iK5mRZzNsGeGwGTyzNIMBekGYQ5MRdIcPv5dBIP/1M6fQDEsAXQ==:
        ssh_auth:
          - present
          - user: frank
          - enc: dsa
          - comment: 'Frank's key'

   Salt 0.9.4 Release Notes
   release
          2011-11-27

   Salt 0.9.4 has arrived. This is a critical update that repairs a number
   of key bugs found in 0.9.3. But this  update  is  not  without  feature
   additions  as  well!  0.9.4  adds support for Gentoo portage to the pkg
   module and state system. Also there are 2 major  new  state  additions,
   the  failhard  option  and  the ability to set up finite state ordering
   with the order option.

   This release also sees our largest increase in community contributions.
   These  contributors  have and continue to be the life blood of the Salt
   project, and the team continues to grow. I want to put out a big thanks
   to our new and existing contributors.

   Download!
   The Salt source can be downloaded from the salt GitHub site:

   https://cloud.github.com/downloads/saltstack/salt/salt-0.9.4.tar.gz

   Or from PyPI:

   https://pypi.python.org/packages/source/s/salt/salt-0.9.4.tar.gz

   For  instructions  on  how  to  set up Salt please see the installation
   instructions.

   New Features
   Failhard State Option
   Normally, when a state fails Salt continues to execute the remainder of
   the  defined states and will only refuse to execute states that require
   the failed state.

   But the situation may exist, where you would want all  state  execution
   to stop if a single state execution fails. The capability to do this is
   called failing hard.

   State Level Failhard
   A single state can have  a  failhard  set,  this  means  that  if  this
   individual  state fails that all state execution will immediately stop.
   This is a great thing to do if there is a state that sets up a critical
   config  file and setting a require for each state that reads the config
   would be cumbersome.  A good example of this  would  be  setting  up  a
   package manager early on:

      /etc/yum.repos.d/company.repo:
        file:
          - managed
          - source: salt://company/yumrepo.conf
          - user: root
          - group: root
          - mode: 644
          - order: 1
          - failhard: True

   In  this situation, the yum repo is going to be configured before other
   states, and if it fails to lay down the  config  file,  than  no  other
   states will be executed.

   Global Failhard
   It  may  be  desired to have failhard be applied to every state that is
   executed, if this is the case, then failhard can be set in  the  master
   configuration  file.  Setting failhard in the master configuration file
   will result in failing hard when any minion gathering states  from  the
   master have a state fail.

   This  is  NOT the default behavior, normally Salt will only fail states
   that require a failed state.

   Using the global failhard is generally not recommended,  since  it  can
   result  in  states  not  being executed or even checked. It can also be
   confusing to see states failhard if an admin is not actively aware that
   the failhard has been set.

   To   use   the  global  failhard  set  failhard:  True  in  the  master
   configuration

   Finite Ordering of State Execution
   When creating salt sls files, it is often important to ensure that they
   run  in  a specific order. While states will always execute in the same
   order, that order is not necessarily defined the way you want it.

   A few tools exist in Salt to set up the correct state  ordering,  these
   tools consist of requisite declarations and order options.

   The Order Option
   Before  using  the  order  option,  remember that the majority of state
   ordering should be done with requisite statements, and that a requisite
   statement will override an order option.

   The  order  option  is  used  by  adding  an  order  number  to a state
   declaration with the option order:

      vim:
        pkg:
          - installed
          - order: 1

   By adding the order option to 1 this ensures that the vim package  will
   be  installed  in  tandem  with  any other state declaration set to the
   order 1.

   Any state declared without an order option will be executed  after  all
   states with order options are executed.

   But  this construct can only handle ordering states from the beginning.
   Sometimes you may want to send a state to the end of the  line,  to  do
   this set the order to last:

      vim:
        pkg:
          - installed
          - order: last

   Substantial  testing has gone into the state system and it is ready for
   real world usage. A great deal has been added to the documentation  for
   states  and  the  modules  and  functions available to states have been
   cleanly documented.

   A number of State System bugs have also been founds and  repaired,  the
   output  from  the  state  system  has also been refined to be extremely
   clear and concise.

   Error reporting has also been introduced, issues  found  in  sls  files
   will now be clearly reported when executing Salt States.

   Gentoo Support
   Additional  experimental  support  has  been  added for Gentoo. This is
   found in the contribution from Doug Renn, aka nestegg.

   Salt 0.9.5 Release Notes
   release
          2012-01-15

   Salt 0.9.5 is one of the largest steps forward in  the  development  of
   Salt.

   0.9.5  comes  with many milestones, this release has seen the community
   of developers grow out to an international team of 46 code contributors
   and  has  many  feature  additions, feature enhancements, bug fixes and
   speed improvements.

   WARNING:
      Be sure to read the upgrade instructions about the switch to msgpack
      before upgrading!

   Community
   Nothing  has  proven to have more value to the development of Salt that
   the outstanding community that has been growing at such  a  great  pace
   around  Salt.   This has proven not only that Salt has great value, but
   also the expandability of  Salt  is  as  exponential  as  I  originally
   intended.

   0.9.5 has received over 600 additional commits since 0.9.4 with a swath
   of new committers. The following individuals have  contributed  to  the
   development of 0.9.5:

   * Aaron Bull Schaefer

   * Antti Kaihola

   * Bas Tichelaar

   * Brad Barden

   * Brian Wagner

   * Byron Clark

   * Chris Scheller

   * Christer Edwards

   * Clint Savage

   * Corey Quinn

   * David Boucha

   * Eivind Uggedal

   * Eric Poelke

   * Evan Borgstrom

   * Jed Glazner

   * Jeff Schroeder

   * Jeffrey C. Ollie

   * Jonas Buckner

   * Kent Tenney

   * Martin Schnabel

   * Maxim Burgerhout

   * Mitch Anderson

   * Nathaniel Whiteinge

   * Seth House

   * Thomas S Hatch

   * Thomas Schreiber

   * Tor Hveem

   * lzyeval

   * syphernl

   This makes 21 new developers since 0.9.4 was released!

   To  keep  up  with  the  growing  community  follow  Salt  on  Ohloh (
   http://www.ohloh.net/p/salt), to join the Salt  development  community,
   fork      Salt      on      GitHub,      and      get     coding     (
   https://github.com/saltstack/salt)!

   Major Features
   SPEED! Pickle to msgpack
   For a few months now we have been talking about moving away from Python
   pickles for network serialization, but a preferred serialization format
   had not yet been found. After an extensive performance  testing  period
   involving  everything  from  JSON  to  protocol buffers, a clear winner
   emerged.  Message Pack (http://msgpack.org/) proved to not only be  the
   fastest  and  most compact, but also the most "salt like". Message Pack
   is simple, and the code involved is very small. The msgpack library for
   Python has been added directly to Salt.

   This  move  introduces  a  few  changes  to Salt. First off, Salt is no
   longer a "noarch" package, since the msgpack lib is written in C.  Salt
   0.9.5  will  also have compatibility issues with 0.9.4 with the default
   configuration.

   We have gone through great lengths  to  avoid  backwards  compatibility
   issues  with  Salt,  but changing the serialization medium was going to
   create issues regardless. Salt 0.9.5 is somewhat  backwards  compatible
   with  earlier  minions.  A  0.9.5 master can command older minions, but
   only if the serial config value in the master is set  to  pickle.  This
   will  tell  the  master  to  publish messages in pickle format and will
   allow the master  to  receive  messages  in  both  msgpack  and  pickle
   formats.

   Therefore  the  suggested  methods  for  upgrading  are  either to just
   upgrade everything at once, or:

   1. Upgrade the master to 0.9.5

   2. Set serial to pickle in the master config

   3. Upgrade the minions

   4. Remove the serial option from the master config

   Since pickles can be used as a  security  exploit  the  ability  for  a
   master  to  accept  pickles  from  minions  at all will be removed in a
   future release.

   C Bindings for YAML
   All of the YAML rendering is now done with the YAML  C  bindings.  This
   speeds up all of the sls files when running states.

   Experimental Windows Support
   David Boucha has worked tirelessly to bring initial support to Salt for
   Microsoft Windows operating systems. Right now the Salt Minion can  run
   as a native Windows service and accept commands.

   In the weeks and months to come Windows will receive the full treatment
   and will have support for Salt  States  and  more  robust  support  for
   managing  Windows  systems. This is a big step forward for Salt to move
   entirely outside of the Unix world, and proves Salt is a  viable  cross
   platform solution. Big Thanks to Dave for his contribution here!

   Dynamic Module Distribution
   Many  Salt  users  have  expressed  the  desire to have Salt distribute
   in-house  modules,  states,  renderers,  returners,  and  grains.  This
   support has been added in a number of ways:

   Modules via States
   Now  when salt modules are deployed to a minion via the state system as
   a file, then the modules will be automatically loaded into  the  active
   running  minion  -  no  restart  required - and into the active running
   state. So custom state modules can be deployed and  used  in  the  same
   state run.

   Modules via Module Environment Directories
   Under the file_roots each environment can now have directories that are
   used to deploy large groups of modules. These directories sync  modules
   at  the  beginning  of  a  state  run on the minion, or can be manually
   synced via the Salt module salt.modules.saltutil.sync_all.

   The directories are named:

   * _modules

   * _states

   * _grains

   * _renderers

   * _returners

   The modules are pushed to their respective scopes on the minions.

   Module Reloading
   Modules can now be reloaded without restarting the minion, this is done
   by calling the salt.modules.sys.reload_modules function.

   But wait, there's more! Now when a salt module of any type is added via
   states the modules will be automatically reloaded, allowing for modules
   to be laid down with states and then immediately used.

   Finally,   all  modules  are  reloaded  when  modules  are  dynamically
   distributed from the salt master.

   Enable / Disable Added to Service
   A great deal of demand has existed for adding  the  capability  to  set
   services to be started at boot in the service module. This feature also
   comes with an overhaul of  the  service  modules  and  initial  systemd
   support.

   This means that the service state can now accept - enable: True to make
   sure a service is enabled at boot, and - enable: False to make sure  it
   is disabled.

   Compound Target
   A new target type has been added to the lineup, the compound target. In
   previous versions the desired minions could  only  be  targeted  via  a
   single  specific target type, but now many target specifications can be
   declared.

   These targets can also be separated by  and/or  operators,  so  certain
   properties can be used to omit a node:

      salt -C 'webserv* and G@os:Debian or E@db.*' test.ping

   will  match  all  minions with ids starting with webserv via a glob and
   minions matching the os:Debian grain. Or minions that  match  the  db.*
   regular expression.

   Node Groups
   Often  the  convenience  of  having  a  predefined  group of minions to
   execute targets on is desired. This can be accomplished  with  the  new
   nodegroups feature. Nodegroups allow for predefined compound targets to
   be declared in the master configuration file:

      nodegroups:
        group1: '[email protected],bar.domain.com,baz.domain.com and bl*.domain.com'
        group2: 'G@os:Debian and foo.domain.com'

   And then used via the -N option:

      salt -N group1 test.ping

   Minion Side Data Store
   The data module introduces the initial approach into storing persistent
   data  on  the minions, specific to the minions. This allows for data to
   be stored on minions that can be accessed from the master or  from  the
   minion.

   The Minion datastore is young, and will eventually provide an interface
   similar to a more mature key/value pair server.

   Major Grains Improvement
   The Salt grains have been overhauled to include  a  massive  amount  of
   extra  data.   this  includes  hardware data, os data and salt specific
   data.

   Salt -Q is Useful Now
   In the past the salt query system, which would display  the  data  from
   recent  executions  would  be  displayed  in  pure  Python,  and it was
   unreadable.

   0.9.5 has added the outputter system to the -Q  option,  thus  enabling
   the salt query system to return readable output.

   Packaging Updates
   Huge  strides have been made in packaging Salt for distributions. These
   additions are thanks to our wonderful community where the work  to  set
   up packages has proceeded tirelessly.

   FreeBSD
   Salt on FreeBSD? There a port for that:

   http://svnweb.freebsd.org/ports/head/sysutils/py-salt/

   This  port was developed and added by Christer Edwards. This also marks
   the first time Salt has been included in an upstream packaging system!

   Fedora and Red Hat Enterprise
   Salt packages have been prepared for inclusion in  the  Fedora  Project
   and  in  EPEL  for  Red  Hat Enterprise 5 and 6. These packages are the
   result of the efforts made by Clint Savage (herlo).

   Debian/Ubuntu
   A team of many contributors have assisted in  developing  packages  for
   Debian and Ubuntu. Salt is still actively seeking inclusion in upstream
   Debian and Ubuntu and the package data that has been prepared is  being
   pushed through the needed channels for inclusion.

   These packages have been prepared with the help of:

   * Corey

   * Aaron Toponce

   * and`

   More to Come
   We  are  actively  seeking  inclusion  in more distributions. Primarily
   getting Salt into Gentoo, SUSE, OpenBSD, and preparing Solaris  support
   are all turning into higher priorities.

   Refinement
   Salt continues to be refined into a faster, more stable and more usable
   application. 0.9.5 comes with more debug logging, more  bug  fixes  and
   more complete support.

   More Testing, More BugFixes
   0.9.5  comes  with  more bugfixes due to more testing than any previous
   release.  The growing community and the introduction a a  dedicated  QA
   environment  have  unearthed  many  issues  that  were hiding under the
   covers. This has further  refined  and  cleaned  the  state  interface,
   taking  care of things from minor visual issues to repairing misleading
   data.

   Custom Exceptions
   A custom exception  module  has  been  added  to  throw  salt  specific
   exceptions.   This  allows  Salt  to  give  much  more  granular  error
   information.

   New Modules
   data
   The new data module manages a persistent datastore on the minion.   Big
   thanks to bastichelaar for his help refining this module

   freebsdkmod
   FreeBSD  kernel modules can now be managed in the same way Salt handles
   Linux kernel modules.

   This module was contributed thanks to the efforts of Christer Edwards

   gentoo_service
   Support has been added for managing  services  in  Gentoo.  Now  Gentoo
   services  can  be  started,  stopped, restarted, enabled, disabled, and
   viewed.

   pip
   The pip module introduces management for  pip  installed  applications.
   Thanks goes to whitinge for the addition of the pip module

   rh_service
   The  rh_service  module  enables  Red  Hat  and Fedora specific service
   management.  Now Red Hat like systems come with extensive management of
   the classic init system used by Red Hat

   saltutil
   The saltutil module has been added as a place to hold functions used in
   the maintenance and management of salt itself. Saltutil is used to salt
   the  salt  minion.  The  saltutil module is presently used only to sync
   extension modules from the master server.

   systemd
   Systemd support has been added to Salt, now  systems  using  this  next
   generation init system are supported on systems running systemd.

   virtualenv
   The  virtualenv  module  has been added to allow salt to create virtual
   Python environments.  Thanks goes to whitinge for the addition  of  the
   virtualenv module

   win_disk
   Support for gathering disk information on Microsoft Windows minions The
   windows modules come courtesy of Utah_Dave

   win_service
   The win_service module adds  service  support  to  Salt  for  Microsoft
   Windows services

   win_useradd
   Salt can now manage local users on Microsoft Windows Systems

   yumpkg5
   The yumpkg module introduces in 0.9.4 uses the yum API to interact with
   the yum package manager. Unfortunately, on Red Hat 5 systems salt  does
   not  have  access  to  the yum API because the yum API is running under
   Python 2.4 and Salt needs to run under Python 2.6.

   The yumpkg5 module bypasses this  issue  by  shelling  out  to  yum  on
   systems where the yum API is not available.

   New States
   mysql_database
   The  new  mysql_database  state  adds  the ability to systems running a
   mysql server to manage the existence of mysql databases.

   The mysql states are thanks to syphernl

   mysql_user
   The mysql_user state enables mysql user management.

   virtualenv
   The  virtualenv  state  can  manage  the  state   of   Python   virtual
   environments.  Thanks to Whitinge for the virtualenv state

   New Returners
   cassandra_returner
   A returner allowing Salt to send data to a cassandra server.  Thanks to
   Byron Clark for contributing this returner

   Salt 0.9.6 Release Notes
   release
          2012-01-21

   Salt 0.9.6 is a release targeting a  few  bugs  and  changes.  This  is
   primarily  targeting  an  issue  found  in the names declaration in the
   state system. But a few other bugs were  also  repaired,  like  missing
   support for grains in extmods.

   Due  to  a conflict in distribution packaging msgpack will no longer be
   bundled with Salt, and is required as a dependency.

   New Features
   HTTP and ftp support in files.managed
   Now under the source option in the file.managed state  a  HTTP  or  ftp
   address can be used instead of a file located on the salt master.

   Allow Multiple Returners
   Now the returner interface can define multiple returners, and will also
   return data back to the master, making the process less ambiguous.

   Minion Memory Improvements
   A number of modules have been taken out of the minion if the underlying
   systems  required by said modules are not present on the minion system.
   A number of other modules need to be stripped  out  in  this  same  way
   which should continue to make the minion more efficient.

   Minions Can Locally Cache Return Data
   A new option, cache_jobs, has been added to the minion to allow for all
   of the historically run jobs to  cache  on  the  minion,  allowing  for
   looking up historic returns. By default cache_jobs is set to False.

   Pure Python Template Support For file.managed
   Templates  in  the  file.managed  state  can now be defined in a Python
   script.  This script needs to have a  run  function  that  returns  the
   string that needs to be in the named file.

   Salt 0.9.7 Release Notes
   release
          2012-02-15

   Salt  0.9.7  is here! The latest iteration of Salt brings more features
   and many fixes. This release is a great refinement over  0.9.6,  adding
   many  conveniences  under  the hood, as well as some features that make
   working with Salt much better.

   A few highlights  include  the  new  Job  system,  refinements  to  the
   requisite system in states, the mod_init interface for states, external
   node classification, search path to managed files in  the  file  state,
   and refinements and additions to dynamic module loading.

   0.9.7  also  introduces  the long developed (and oft changed) unit test
   framework and the initial unit tests.

   Major Features
   Salt Jobs Interface
   The new jobs interface makes the management of running executions  much
   cleaner  and  more  transparent.  Building  on  the  existing execution
   framework the jobs system allows clear introspection  into  the  active
   running state of the running Salt interface.

   The  Jobs interface is centered in the new minion side proc system. The
   minions now store msgpack serialized files under  /var/cache/salt/proc.
   These files keep track of the active state of processes on the minion.

   Functions in the saltutil Module
   A  number of functions have been added to the saltutil module to manage
   and view the jobs:

   running - Returns the data of all running jobs that are  found  in  the
   proc directory.

   find_job - Returns specific data about a certain job based on job id.

   signal_job - Allows for a given jid to be sent a signal.

   term_job  -  Sends  a  termination  signal (SIGTERM, 15) to the process
   controlling the specified job.

   kill_job Sends a kill signal (SIGKILL, 9) to  the  process  controlling
   the specified job.

   The jobs Runner
   A  convenience  runner front end and reporting system has been added as
   well.  The jobs runner contains functions to make viewing  data  easier
   and cleaner.

   The jobs runner contains a number of functions...

   active
   The  active  function  runs saltutil.running on all minions and formats
   the return data about all running  jobs  in  a  much  more  usable  and
   compact  format.   The active function will also compare jobs that have
   returned and jobs that are still running, making it easier to see  what
   systems  have  completed  a job and what systems are still being waited
   on.

   lookup_jid
   When jobs are executed the return data is sent back to the  master  and
   cached.   By  default  is  is  cached  for  24  hours,  but this can be
   configured via the keep_jobs option in the master configuration.

   Using the lookup_jid runner will display the same return data that  the
   initial job invocation with the salt command would display.

   list_jobs
   Before  finding  a historic job, it may be required to find the job id.
   list_jobs will parse the cached execution data and display all  of  the
   job data for jobs that have already, or partially returned.

   External Node Classification
   Salt   can   now   use   external   node   classifiers  like  Cobbler's
   cobbler-ext-nodes.

   Salt  uses  specific  data  from  the  external  node  classifier.   In
   particular  the classes value denotes which sls modules to run, and the
   environment value sets to another environment.

   An external node classification can be set in the master  configuration
   file          via          the          external_nodes          option:
   https://salt.readthedocs.io/en/latest/ref/configuration/master.html#external-nodes

   External  nodes  are  loaded  in  addition  to  the top files. If it is
   intended to only use external nodes, do not deploy any top files.

   State Mod Init System
   An issue arose with the pkg state. Every time a package  was  run  Salt
   would  need  to  refresh  the  package database. This made systems with
   slower package metadata refresh speeds much slower  to  work  with.  To
   alleviate  this  issue  the  mod_init  interface has been added to salt
   states.

   The mod_init interface is a function that can be added to a state file.
   This function is called with the first state called. In the case of the
   pkg state, the mod_init function sets up a tag which makes the  package
   database only refresh on the first attempt to install a package.

   In a nutshell, the mod_init interface allows a state to run any command
   that only needs to be run once, or can be used to set up an environment
   for working with the state.

   Source File Search Path
   The  file state continues to be refined, adding speed and capabilities.
   This release adds the ability to pass a list to the source option. This
   list  is  then  iterated  over  until the source file is found, and the
   first found file is used.

   The new syntax looks like this:

      /etc/httpd/conf/httpd.conf:
        file:
          - managed
          - source:
            - salt://httpd/httpd.conf
            - http://myserver/httpd.conf: md5=8c1fe119e6f1fd96bc06614473509bf1

   The source option can take sources in  the  list  from  the  salt  file
   server  as  well  as an arbitrary web source. If using an arbitrary web
   source the checksum needs to be passed as well for file verification.

   Refinements to the Requisite System
   A few discrepancies were still lingering in the  requisite  system,  in
   particular, it was not possible to have a require and a watch requisite
   declared in the same state declaration.

   This issue has been alleviated, as well as making the requisite  system
   run more quickly.

   Initial Unit Testing Framework
   Because  of the module system, and the need to test real scenarios, the
   development of a viable unit testing system  has  been  difficult,  but
   unit  testing  has finally arrived. Only a small amount of unit testing
   coverage has been developed, much more coverage will be in place soon.

   A huge thanks goes out to those who have helped with unit testing,  and
   the  contributions  that have been made to get us where we are. Without
   these contributions unit tests would still be in the dark.

   Compound Targets Expanded
   Originally only support for and and or were available in  the  compound
   target. 0.9.7 adds the capability to negate compound targets with not.

   Nodegroups in the Top File
   Previously  the  nodegroups  defined  in  the master configuration file
   could not be used to match nodes for states. The nodegroups support has
   been  expanded  and  the nodegroups defined in the master configuration
   can now be used to match minions in the top file.

   Salt 0.9.8 Release Notes
   release
          2012-03-21

   Salt 0.9.8 is a big step forward, with many additions and enhancements,
   as well as a number of precursors to advanced future developments.

   This  version  of Salt adds much more power to the command line, making
   the old hard timeout issues a  thing  of  the  past  and  adds  keyword
   argument support. These additions are also available in the salt client
   API, making the available API tools much more powerful.

   The new pillar system allows for data to be stored on  the  master  and
   assigned  to  minions in a granular way similar to the state system. It
   also allows flexibility for users who want to keep data  out  of  their
   state tree similar to 'external lookup' functionality in other tools.

   A new way to extend requisites was added, the "requisite in" statement.
   This makes adding requires or watch statements to external  state  decs
   much easier.

   Additions  to requisites making them much more powerful have been added
   as well as improved error checking for sls files in the state system. A
   new  provider  system  has  been  added  to  allow for redirecting what
   modules run in the background for individual states.

   Support for openSUSE has been added and support for Solaris  has  begun
   serious development. Windows support has been significantly enhanced as
   well.

   The matcher and target systems have received a great deal of attention.
   The  default behavior of grain matching has changed slightly to reflect
   the rest of salt and the compound matcher system has been refined.

   A number of impressive features with keyword arguments have been  added
   to  both  the  CLI and to the state system. This makes states much more
   powerful  and  flexible  while  maintaining  the  simple  configuration
   everyone loves.

   The  new  batch  size  capability  allows  for  executions to be rolled
   through a group of targeted minions a percentage or specific number  at
   a  time.  This  was added to prevent the "thundering herd" problem when
   targeting large numbers of minions for things like service restarts  or
   file downloads.

   Upgrade Considerations
   Upgrade Issues
   There  was  a  previously  missed  oversight  which could cause a newer
   minion to crash an older master. That oversight has  been  resolved  so
   the  version incompatibility issue will no longer occur. When upgrading
   to 0.9.8 make sure  to  upgrade  the  master  first,  followed  by  the
   minions.

   Debian/Ubuntu Packages
   The  original  Debian/Ubuntu packages were called salt and included all
   salt applications. New packages in the ppa are split by function. If an
   old  salt  package  is installed then it should be manually removed and
   the new split packages need to be freshly installed.

   On the master:

      # apt-get purge salt
      # apt-get install salt-{master,minion}

   On the minions:

      # apt-get purge salt
      # apt-get install salt-minion

   And on any Syndics:

      # apt-get install salt-syndic

   The    official    Salt    PPA    for    Ubuntu    is    located    at:
   https://launchpad.net/~saltstack/+archive/salt

   Major Features
   Pillar
   Pillar  offers an interface to declare variable data on the master that
   is then assigned to the minions. The pillar data is made  available  to
   all modules, states, sls files etc. It is compiled on the master and is
   declared using the existing renderer system. This means  that  learning
   pillar  should  be  fairly  trivial to those already familiar with salt
   states.

   CLI Additions
   The salt command has received a serious overhaul and is  more  powerful
   than  ever. Data is returned to the terminal as it is received, and the
   salt command will now wait for  all  running  minions  to  return  data
   before  stopping.   This  makes  adding  very large --timeout arguments
   completely  unnecessary  and  gets  rid  of  long  running   operations
   returning empty {} when the timeout is exceeded.

   When  calling  salt via sudo, the user originally running salt is saved
   to the log for auditing purposes. This makes it easy  to  see  who  ran
   what by just looking through the minion logs.

   The  salt-key  command  gained  the  -D  and --delete-all arguments for
   removing all keys. Be careful with this one!

   Running States Without a Master
   The addition of running states without a salt-master has been added  to
   0.9.8.  This  feature  allows  for the unmodified salt state tree to be
   read locally from a minion. The result is  that  the  UNMODIFIED  state
   tree has just become portable, allowing minions to have a local copy of
   states or to manage states without a master entirely.

   This is accomplished via the new file client  interface  in  Salt  that
   allows  for the salt:// URI to be redirected to custom interfaces. This
   means that there are now two  interfaces  for  the  salt  file  server,
   calling the master or looking in a local, minion defined file_roots.

   This new feature can be used by modifying the minion config to point to
   a local file_roots and setting the file_client option to local.

   Keyword Arguments and States
   State modules now accept the **kwargs argument.  This  results  in  all
   data  in  a  sls  file  assigned to a state being made available to the
   state function.

   This passes data in a transparent way back to the modules executing the
   logic.   In particular, this allows adding arguments to the pkg.install
   module that enable more advanced and granular controls with respect  to
   what the state is capable of.

   An  example  of  this  along with the new debconf module for installing
   ldap client packages on Debian:

      ldap-client-packages:
        pkg:
          - debconf: salt://debconf/ldap-client.ans
          - installed
          - names:
            - nslcd
            - libpam-ldapd
            - libnss-ldapd

   Keyword Arguments and the CLI
   In the past it was required that all arguments be passed in the  proper
   order  to  the  salt  and  salt-call  commands.  As  of  0.9.8, keyword
   arguments can be passed in the form of kwarg=argument.

      # salt -G 'type:dev' git.clone \
          repository=https://github.com/saltstack/salt.git cwd=/tmp/salt user=jeff

   Matcher Refinements and Changes
   A number of fixes and changes have been applied to the Matcher  system.
   The  most  noteworthy  is  the  change  in the grain matcher. The grain
   matcher used to use a regular expression to match the passed data to  a
   grain,  but  now  defaults  to  a shell glob like the majority of match
   interfaces in Salt. A new option is available that still uses  the  old
   style  regex  matching  to  grain  data called grain-pcre. To use regex
   matching in compound matches use the letter P.

   For example, this would match any ArchLinux or Fedora minions:

      # salt --grain-pcre 'os:(Arch:Fed).*' test.ping

   And the associated compound matcher suitable for top.sls is P:

      P@os:(Arch|Fed).*

   NOTE: Changing the grains  matcher  from  pcre  to  glob  is  backwards
   incompatible.

   Support has been added for matching minions with Yahoo's range library.
   This is handled by passing range syntax with -R or --range arguments to
   salt.

   More                           information                          at:
   https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec

   Requisite in
   A new means to updating requisite statements has  been  added  to  make
   adding  watchers  and  requires to external states easier. Before 0.9.8
   the only way to extend the states that were watched by a state  outside
   of the sls was to use an extend statement:

      include:
        - http
      extend:
        apache:
          service:
            - watch:
              - pkg: tomcat

      tomcat:
        pkg:
          - installed

   But  the  new  Requisite  in  statement  allows  for easier extends for
   requisites:

      include:
        - http

      tomcat:
        pkg:
          - installed
          - watch_in:
            - service: apache

   Requisite in is part of the extend system, so still remember to  always
   include the sls that is being extended!

   Providers
   Salt  predetermines what modules should be mapped to what uses based on
   the properties of a system. These determinations are generally made for
   modules  that  provide  things like package and service management. The
   apt module maps to pkg on Debian and the yum  module  maps  to  pkg  on
   Fedora for instance.

   Sometimes in states, it may be necessary for a non-default module to be
   used for the desired functionality. For instance, an Arch Linux  system
   may have been set up with systemd support. Instead of using the default
   service module detected for Arch Linux, the systemd module can be used:

      http:
        service:
          - running
          - enable: True
          - provider: systemd

   Default providers can also be defined in the minion config file:

      providers:
        service: systemd

   When default providers are passed in  the  minion  config,  then  those
   providers will be applied to all functionality in Salt, this means that
   the functions called by the minion will use these modules, as  well  as
   states.

   Requisite Glob Matching
   Requisites  can  now be defined with glob expansion. This means that if
   there are many requisites, they can be defined on a single line.

   To watch all files in a directory:

      http:
        service:
          - running
          - enable: True
          - watch:
            - file: /etc/http/conf.d/*

   This  example  will  watch  all  defined  files  that  match  the  glob
   /etc/http/conf.d/*

   Batch Size
   The  new  batch  size  option  allows  commands  to  be  executed while
   maintaining that only so many hosts are executing the  command  at  one
   time. This option can take a percentage or a finite number:

      salt '*' -b 10 test.ping

      salt -G 'os:RedHat' --batch-size 25% apache.signal restart

   This  will  only  run test.ping on 10 of the targeted minions at a time
   and then restart apache on 25% of the minions matching os:RedHat  at  a
   time  and  work through them all until the task is complete. This makes
   jobs like rolling web server restarts behind a load balancer  or  doing
   maintenance on BSD firewalls using carp much easier with salt.

   Module Updates
   This  is  a  list  of  notable, but non-exhaustive updates with new and
   existing modules.

   Windows support has seen a flurry of support this release cycle.  We've
   gained  all  new  file,  network,  and shadow modules. Please note that
   these are still a work in progress.

   For our ruby users, new rvm and gem modules have been added along  with
   the associated states

   The virt module gained basic Xen support.

   The yum module gained Scientific Linux support.

   The pkg module on Debian, Ubuntu, and derivatives force apt to run in a
   non-interactive mode. This prevents issues  when  package  installation
   waits for confirmation.

   A pkg module for openSUSE's zypper was added.

   The service module on Ubuntu natively supports upstart.

   A new debconf module was contributed by our community for more advanced
   control over deb package deployments on Debian based distributions.

   The mysql.user state and mysql module gained a password_hash argument.

   The cmd module and state gained a shell keyword argument for specifying
   a shell other than /bin/sh on Linux / Unix systems.

   New  git  and mercurial modules have been added for fans of distributed
   version control.

   In Progress Development
   Master Side State Compiling
   While we feel strongly that the  advantages  gained  with  minion  side
   state  compiling  are  very  critical, it does prevent certain features
   that may be desired. 0.9.8 has support for initial  master  side  state
   compiling,  but  many more components still need to be developed, it is
   hoped that these can be finished for 0.9.9.

   The goal is that states can be compiled on  both  the  master  and  the
   minion  allowing for compilation to be split between master and minion.
   Why will this be great? It will allow storing  sensitive  data  on  the
   master and sending it to some minions without all minions having access
   to it. This will be good for handling ssl certificates on front-end web
   servers for instance.

   Solaris Support
   Salt  0.9.8  sees the introduction of basic Solaris support. The daemon
   runs well, but grains  and  more  of  the  modules  need  updating  and
   testing.

   Windows Support
   Salt states on windows are now much more viable thanks to contributions
   from our community! States for file, service,  local  user,  and  local
   group management are more fully fleshed out along with network and disk
   modules. Windows users can also now manage registry entries  using  the
   new "reg" module.

   Salt 0.9.9 Release Notes
   release
          2012-04-27

   0.9.9  is  out  and  comes  with  some  serious bug fixes and even more
   serious features. This release is the last major feature release before
   1.0.0 and could be considered the 1.0.0 release candidate.

   A  few  updates  include  more advanced kwargs support, the ability for
   salt states to more safely configure a running salt minion, better  job
   directory management and the new state test interface.

   Many  new tests have been added as well, including the new minion swarm
   test that allows for easier testing of Salt working with  large  groups
   of  minions.   This means that if you have experienced stability issues
   with Salt before, particularly in larger deployments, that  these  bugs
   have been tested for, found, and killed.

   Major Features
   State Test Interface
   Until  0.9.9  the only option when running states to see what was going
   to be changed was to print out the highstate with  state.show_highstate
   and  manually  look it over. But now states can be run to discover what
   is going to be changed.

   Passing the option test=True to many of the state  functions  will  now
   cause  the  salt  state  system  to  only check for what is going to be
   changed and report on those changes.

      salt '*' state.highstate test=True

   Now states that would have made changes report them back in yellow.

   State Syntax Update
   A shorthand syntax has been added to sls files,  and  it  will  be  the
   default  syntax in documentation going forward. The old syntax is still
   fully supported and will not be deprecated, but it  is  recommended  to
   move  to  the  new  syntax  in  the future. This change moves the state
   function up into the state name using a dot notation. This  is  in-line
   with how state functions are generally referred to as well:

   The new way:

      /etc/sudoers:
        file.present:
          - source: salt://sudo/sudoers
          - user: root
          - mode: 400

   Use and Use_in Requisites
   Two new requisite statements are available in 0.9.9. The use and use_in
   requisite and requisite-in allow for  the  transparent  duplication  of
   data  between  states.  When a state "uses" another state it copies the
   other state's  arguments  as  defaults.  This  was  created  in  direct
   response  to  the  new  network  state,  and  allows  for  many network
   interfaces to be configured in the same way easily. A simple example:

      root_file:
        file.absent:
          - name: /tmp/nothing
          - user: root
          - mode: 644
          - group: root
          - use_in:
            - file: /etc/vimrc

      fred_file:
        file.absent:
          - name: /tmp/nothing
          - user: fred
          - group: marketing
          - mode: 660

      /files/marketing/district7.rst:
        file.present:
          - source: salt://marketing/district7.rst
          - template: jinja
          - use:
            - file: fred_file

      /etc/vimrc:
        file.present:
          - source: salt://edit/vimrc

   This makes the 2 lower  state  decs  inherit  the  options  from  their
   respectively "used" state decs.

   Network State
   The  new  network state allows for the configuration of network devices
   via salt states and the ip salt module. This addition has been given to
   the project by Jeff Hutchins and Bret Palsson from Jive Communications.

   Currently  the  only network configuration backend available is for Red
   Hat based systems, like Red Hat Enterprise, CentOS, and Fedora.

   Exponential Jobs
   Originally the jobs executed were stored on the master in  the  format:
   <cachedir>/jobs/jid/{minion  ids} But this format restricted the number
   of jobs in the cache to the number of  subdirectories  allowed  on  the
   filesystem. Ext3 for instance limits subdirectories to 32000. To combat
   this       the       new       format       for        0.9.9        is:
   <cachedir>/jobs/jid_hash[:2]/jid_hash[2:]/{minion  ids} So that now the
   number of maximum jobs that can be run before the  cleanup  cycle  hits
   the job directory is substantially higher.

   ssh_auth Additions
   The  original ssh_auth state was limited to accepting only arguments to
   apply to a public key, and the key itself. This was restrictive due  to
   the  way  the  we learned that many people were using the state, so the
   key section has been expanded to accept options and  arguments  to  the
   key   that  over  ride  arguments  passed  in  the  state.  This  gives
   substantial power to using ssh_auth with names:

      sshkeys:
        ssh_auth:
          - present
          - user: backup
          - enc: ssh-dss
          - options:
            - option1="value1"
            - option2="value2 flag2"
          - comment: backup
          - names:
            - AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0111==
            - AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0222== override
            - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0333== override
            - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0444==
            - option3="value3",option4="value4 flag4" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0555== override
            - option3="value3" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlyE26SMFFVY5YJvnL7AF5CRTPtAigSW1U887ASfBt6FDa7Qr1YdO5ochiLoz8aSiMKd5h4dhB6ymHbmntMPjQena29jQjXAK4AK0500rMShG1Y1HYEjTXjQxIy/SMjq2aycHI+abiVDn3sciQjsLsNW59t48Udivl2RjWG7Eo+LYiB17MKD5M40r5CP2K4B8nuL+r4oAZEHKOJUF3rzA20MZXHRQuki7vVeWcW7ie8JHNBcq8iObVSoruylXav4aKG02d/I4bz/l0UdGh18SpMB8zVnT3YF5nukQQ/ATspmhpU66s4ntMehULC+ljLvZL40ByNmF0TZc2sdSkA0666==

   LocalClient Additions
   To follow up  the  recent  additions  in  0.9.8  of  additional  kwargs
   support,  0.9.9  also  adds the capability to send kwargs into commands
   via a dict.  This addition to the LocalClient api can be used like so:

      import salt.client

      client = salt.client.LocalClient('/etc/salt/master')
      ret = client.cmd('*', 'cmd.run', ['ls -l'], kwarg={'cwd': '/etc'})

   This update has been added to all cmd methods in the LocalClient class.

   Better Self Salting
   One problem faced with  running  Salt  states,  is  that  it  has  been
   difficult to manage the Salt minion via states, this is due to the fact
   that if the minion is called to restart while a state run is  happening
   then  the state run would be killed. 0.9.9 slightly changes the process
   scope of the state runs, so now when salt is executing  states  it  can
   safely restart the salt-minion daemon.

   In  addition  to  daemonizing  the  state  run,  the  apt  module  also
   daemonizes.  This update  makes  it  possible  to  cleanly  update  the
   salt-minion  package on Debian/Ubuntu systems without leaving apt in an
   inconsistent state or killing the active minion process mid-execution.

   Wildcards for SLS Modules
   Now, when including sls modules in include statements  or  in  the  top
   file,  shell  globs  can  be  used.  This  can greatly simplify listing
   matched sls modules in the top file and include statements:

      base:
        '*':
          - files*
          - core*

      include:
        - users.dev.*
        - apache.ser*

   External Pillar
   Since the pillar data is just, data, it does not need to come expressly
   from  the pillar interface. The external pillar system allows for hooks
   to be added  making  it  possible  to  extract  pillar  data  from  any
   arbitrary   external   interface.  The  external  pillar  interface  is
   configured via the ext_pillar option.  Currently  interfaces  exist  to
   gather external pillar data via hiera or via a shell command that sends
   yaml data to the terminal:

      ext_pillar:
        - cmd_yaml: cat /etc/salt/ext.yaml
        - hiera: /etc/hirea.yaml

   The initial external pillar interfaces  and  extra  interfaces  can  be
   added  to  the  file salt/pillar.py, it is planned to add more external
   pillar interfaces.  If the need arises a new  module  loader  interface
   will be created in the future to manage external pillar interfaces.

   Single State Executions
   The  new  state.single  function allows for single states to be cleanly
   executed.  This is a great tool for setting up a small group of  states
   on a system or for testing out the behavior of single states:

      salt '*' state.single user.present name=wade uid=2000

   The  test  interface  functions  here  as  well, so changes can also be
   tested against as:

      salt '*' state.single user.present name=wade uid=2000 test=True

   New Tests
   A few exciting new test interfaces have been added,  the  minion  swarm
   allows  not  only testing of larger loads, but also allows users to see
   how Salt behaves with large groups of minions without having to  create
   a large deployment.

   Minion Swarm
   The  minion  swarm test system allows for large groups of minions to be
   tested against easily without requiring large  numbers  of  servers  or
   virtual  machines. The minion swarm creates as many minions as a system
   can handle and roots them in the /tmp directory and connects them to  a
   master.

   The  benefit  here is that we were able to replicate issues that happen
   only when there are large numbers of minions. A number of elusive  bugs
   which  were  causing stability issues in masters and minions have since
   been hunted down.  Bugs that used to take careful watch by  users  over
   several  days  can  now be reliably replicated in minutes, and fixed in
   minutes.

   Using the swarm is easy, make sure a master is  up  for  the  swarm  to
   connect  to,  and  then  use  the  minionswarm.py  script  in the tests
   directory to spin up as many minions as you want. Remember, this  is  a
   fork bomb, don't spin up more than your hardware can handle!

      python minionswarm.py -m 20 --master salt-master

   Shell Tests
   The new Shell testing system allows us to test the behavior of commands
   executed from a high level. This allows for the high level  testing  of
   salt runners and commands like salt-key.

   Client Tests
   Tests have been added to test the aspects of the client APIs and ensure
   that the client calls work, and that they  manage  passed  data,  in  a
   desirable way.

   SEE ALSO:
      Legacy salt-cloud release docs

   SEE ALSO:
      Legacy salt-api release docs

AUTHOR

   Thomas  S.  Hatch  <[email protected]> and many others, please see the
   Authors file



Opportunity


Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.

Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.


Free Software


Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.

Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.


Free Books


The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.

Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.


Education


Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.

Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.